When booting just now, I noticed that my root partition's maximum mount count had been reached, and the filesystem underwent a thorough check. At completion, I noticed fsck print the message "**** REBOOT LINUX ****" on the console, but the status was labelled as "[ ok ]" and the bootup process continued. According to the fsck man page, that message should have been accompanied by a return code of 2. I've looked at the checkroot script, and it looks like that SHOULD have caused 'sulogin' to be run. However, it didn't; I'm not sure why, but I think this needs investigating - it was only by chance that I happened to be watching the messages at that point. ----- On another note, looking at the checkroot script, the message that would have been printed before 'sulogin' was run reads "Filesystem couldn't be fixed :(" - this is incorrect, since error 2 means "Filesystem errors corrected; system should be rebooted". Error codes >=4 mean that the filesystem wasn't fixed.
Ok, scripts choose the easiest way, and just drop to sulogin for anything not ok, or 100% fixed. We can enhance this if really needed. Then, the fsck issue ... its either going to be a bash issue (not returning the correct return code for commands executed), or glibc (as it have the exec*() functions), or fsck issue specific. Any chance you can try to get it to return 2 again in console, and check with 'echo $?' if it really did return 2 ? Far fetched, I know :/ I will try to have a look at fsck's source some time, and have a look if it is fine. What version of e2fsutils ?
Umm, without attacking my hard disk with an axe? :-) I'll see what I can do... I'm using e2fsprogs-1.32-r2 .
Sorry, but much I ask, I know :/ Iike I said, ill to check the source for problems as soon as I get a chance ...
Just had a thought ... what filesystem ? It could be that its not ext2/3, and the real binary fsck calls do not return the correct return code ...
It's ext3.
Aha! Got it. The fault is with the checkroot/checkfs scripts, in the section where the code reads: if [ "$?" -eq 0 ] then eend 0 elif [ "$?" -eq 1 ] then ewend 1 "Filesystem repaired" else The first 'if' statement causes the value of '$?' to change to either 0 or 1, depending on whether the first 'if' test was successful. So the program will never enter the 'else' section. The following fixes it: return=$? if [ $return -eq 0 ] then eend 0 elif [ $return -eq 1 ] then ewend 1 "Filesystem repaired" else I'll attach patches for both files shortly.
Created attachment 7647 [details, diff] Patch for checkfs
Created attachment 7648 [details, diff] Patch for checkroot
Bleh, you are right. Good eye, thanks! Fixed in CVS.
This change doesn't seem to have made it into baselayout-1.8.6.2 ...
Martin: > Ok, scripts choose the easiest way, and just drop to sulogin for anything > not ok, or 100% fixed. We can enhance this if really needed. I think it *is* needed. The wrong message "Filesystem couldn't be fixed" is shocking and misleading many people, when it actually just requires a reboot. For some people, ext3 seems to produce this message on *each* check (there are some threads in the forums about it, e.g. <http://forums.gentoo.org/viewtopic.php?t=51324>). Just printing another message if the return code is 2 would be enough, IMO.
