antiX-13.1-Full ISO burned to CD-ROM and used to boot PC.

F1-->

check fs
check the integrity of the file system used. This may take some time.

F4-->Select="check fs"

Main Menu
Boot Options box="quiet antiX=MLX"
Options F4 column="check fs"

Enter to begin bootup
The bootup proceeds to load antiX. An on screen report is not displayed that a check is/has been done. Is e2fsck (or similar) meant to check the internal disk before antiX is started?

Yes. We run e2fsck so it only works on ext2/3/4 file systems. It is meant to check the LiveUSB file system and the file system of the rootfs file (and maybe the homefs file) and the partition that holds the persistence files (if it is not the boot partition). These checks will also get performed automatically depending on how you set things with tune2fs. You can tell it to check after a certain amount of time has passed or after X many mounts. When you make a file system, the default is set to never check so in that case we check every 30 mounts but we leave the time limit so it never triggers a check. If you don't like this, use tune2fs and set it to a very large number.

Even on a LiveCD, this check isn't pointless although we never check the CDROM file system. You can easily set up persistence on a LiveCD by adding the label"antiXPersist" to a read-write partition then use the persist-makefs tool to create a rootfs and/or homefs file on that partition. Select one of the persistence options from the boot loader menu to enable persistence. When you select"check fs" then these file systems will be checked but only if persistence is enabled.

I'm not aware of any other LiveUSB that has this feature. This goes hand in hand with our new LiveUSB clean umount code.

Edit: There is a message that shows up in /var/log/live/bootstrap.log that says it can't perform a file check on an iso9660 file system. I admit this is extremely obscure. I could turn this into an error message instead of an info message so it is red and always prints while you boot. The reason I didn't do it that way is there are plenty of normal situations where we encounter file systems that we can't check. Did you really expect us to check the file system on your CDROM? Another situation is if a user has persistence files on an NTFS file system. If I generate an error message that we can't check the NTFS file system then I'm sure someone is going to be worried that something is terribly wrong.

ISTM the choice is between being rather quiet about not being able to check your CDROM or presenting the user with bogus error messages. Often we need to fine tune the messaging after all the code is working. I'm open to suggestions on how you think this condition should be reported.

Another approach was to let the user fine-tune exactly which file-systems they want checked. The code to do this isn't too bad but it adds a lot of complexity to the UX with very little gain. That's why I opted for a single on/off flag that says to check everything it can and then be rather quiet about file systems that can't be checked.

Since you just experienced this and found it unsatisfactory, your suggestions could be very helpful. That message was originally much louder but it seemed a bit like saying"hey, you idiot ..." so I toned it down. This is especially so because there are cases where people want to use"check fs" even though some of the file systems can't be checked.

I would prefer to not add a lot of complexity to this. The first check of the boot partition file system has to happen very early, while we are just opening our eyes, so to speak. I don't want to make that message conditional on whether we might be checking persistence file systems later in the boot process. I would prefer to just have a fixed message with a fixed level of"loudness". Still, I'd like to know what you think would work best for you.

To some extent, I was emulating how installed system check their root filesystem.

SamK, I changed the messages about not being able to check a filesystem into warnings so they are always printed to the screen and they stand out. If you want to see for yourself, send me an email or a PM and I can send you an initrd.gz file or an xdelta3 file that will modify a .iso file and put the new initrd.gz into it. In either case (especially with the xdelta3) I need to know the full name (as downloaded) of the iso file you are starting with.

I am also intrigued by your idea of having something pop up in X-windows that gives a brief report to the user. We had been toying around with an idea like this but we never got around to doing it. One challenge is knowing what to say because if anything really bad happens then we don't boot antiX and never get to X-windows. You can look in the files /var/log/live/bootstrap.log and /var/log/live/bootstrap.log.color to get an idea of what information is available. There is also some information that is put in files in /live/config/. These are intended as input to other programs.

It might be easy to make a program that pops up some information about the bootstrap process. Maybe it would only pop up if there was something interesting to report but it would also be available via the control center. The question is whether the value added would be worth the effort. The log file is pretty comprehensive. I can imagine a trimmed down version that is more useful to users.

BitJam wrote:It is meant to check the LiveUSB file system and the file system of the rootfs file (and maybe the homefs file) and the partition that holds the persistence files (if it is not the boot partition).

I did not pick up on that when booting from CD-ROM specifically to conduct a traditional hard disk installation. Perhaps an explanation of purpose in the main boot menu F1-->"* F4: Miscellaneous Options" would be sufficient.

BitJam wrote:Did you really expect us to check the file system on your CDROM?

No. I did wonder if it would conduct a check on the existing ext4 file systems on the disk. This was perhaps fanciful, beyond scope and of limited value.

BitJam wrote:There is a message that shows up in /var/log/live/bootstrap.log that says it can't perform a file check on an iso9660 file system. I admit this is extremely obscure. I could turn this into an error message instead of an info message so it is red and always prints while you boot.

I don't see anything other than the message in /var/log/live/bootstrap.log being useful.

BitJam wrote:I am also intrigued by your idea of having something pop up in X-windows that gives a brief report to the user.

My observation about there being no message was related to the possible check of an existing ext file system on disk. As I have not used the current antiX release from USB I can't really comment on the aspect of having an X-window pop-up report.

BitJam wrote:These [file system] checks will also get performed automatically depending on how you set things with tune2fs.

I've been intending to raise a post about the checks for a while. I'll open a separate topic about it.


I'll amend the title of the opening post to more accurate reflect that the topic is a query rather than a failure report.

Thanks SamK. I agree the F1 documentation of this feature needs to be improved. I will do that. It is always helpful to get the viewpoint of someone who is outside of the design process.

Maybe try to explain what the safe, very safe and such graphics options mean too? Irc, they had"real" names in beta, but were changed to easier titles in 13.1? but I don't remember what which one was what?

The"safe" option adds the nomodeset boot parameter. It also creates a minimal xorg.conf which helps some systems achieve a higher resolution by increasing the range of HorizSync and VertRefresh allowed. (side note: this increase could actually damage some ancient CRTs). The"very safe" option does the same except it doesn't create an xorg.conf at all so it uses all of the Xorg defaults.

I give the explanation here to see what you guys think of it. Should I also try to explain what nomodeset does?

well, I don't use any of them, but it might be good to have the info somewhere?

rust collector wrote:well, I don't use any of them, but it might be good to have the info somewhere?

I agree. I was just wondering about exactly what information should be included.

I'm reminded of a anecdote about George Bernard Shaw that ends with him saying"We are just haggling over the price."

lol, well, if I had some wierd... no... I have a wierd machine, that is why I use none of the options..
I don't now what modeset does really, as I can't use it anyway.
Maybe someone knows enough to comment with something useful.

rust collector wrote:Maybe try to explain what the safe, very safe and such graphics options mean too?

BitJam wrote:I give the explanation here to see what you guys think of it.

BitJam wrote:

rust collector wrote:well, I don't use any of them, but it might be good to have the info somewhere?

I agree. I was just wondering about exactly what information should be included.

rust collector wrote:I don't now what modeset does really...

This is slightly off-topic but for what it is worth these are some of the general princples I try to observe.

• Aim the information at a specific target audience.
  Technically competent users are more likely to understand both technical and non-technical guidance. They are also better equipped to research the things they don't understand. Non-technical users do not usually have the background knowledge to understand purely technical guidance.
• Indicate why the advice is being provided.
  e.g. in what circumstances it might be useful.
• Describe the expected outcome.
  Because of the limited knowlege of non-technical users, they often go through a subconcious"translation" process when faced with guidance. Something along the lines of"what does this mean to me" or"how will this affect me".
• Keep It Simple and Straightforward (KISS).
  Anything that attempts to make a task easier to complete is usually appreciated.
  e.g. jargon free (where possible) short sentences etc. (I hope the following saying is known in other countries. I didn't have enough time to write a short explanation, so I wrote a long one instead.

I freely admit that the above are difficult to do, particularly for techichnal users. They are accustomed to using technical terminolgy to describe technical matters. The antiX forum is proud of its friendliness towards users. It is a natural progression to extend that friendliness to guidance offered outside the forum.