Parallel fsck leads to unhelpful error message at login

[Chris Halse Rogers]

Binary package hint: sysvinit

It seems that it's a goal to parallelise the fsck on boot, and that this has started to be implemented in Intrepid.

This results in an unhelpful error message at login in its current state. When /home is being fsck'd, GDM comes up fine, but once a user tries to login a scary warning about /home being read-only is displayed, and login fails.

If we're going to do this then GDM should probably have a display of the current progress of the fsck (if it's running) instead of the normal login area. Certainly the error message on login should be friendlier.

[Jeremy Wilkins (wjeremy)]

I second that. I have had problems with that ever since I decided to try Intrepid. At first I thought my drive was failing, but when I checked the process list I noticed that fsck running. Waited for it to finish and rebooted. For me this happens quite often (every week almost) since I run a laptop and start and stop it several times a day. A progress indicator at KDM screen for me would be more helpful and graying out the login option if the necessary home partition for that user is busy makes more sense as well as a more useful message.

[Theodore Ts'o (tytso)]

It may be far worse than that. If you have separate partitions, and apache needs /var/www to be mounted in order for it to function correctly, letting the boot process proceed before the other partitions are fsck'ed and rebooted will cause apache to fail. Trying to run fsck in parallel is a very, very dangerous thing to do in general, since you don't know what partitions might be needed by system daemons during the boot-up process. That's dependent on how the system administrator may have set up the system. So it's not enough just to wait for the root partition to be fsck'ed; *all* partitions must be checked before the rest of the init scripts are allowed to proceed.

If you want fast fsck times, please see http://thunk.org/tytso/blog/2008/08/08/fast-ext4-fsck-times

Running fsck in parallel is not the answer.

[Martin Pitt (pitti)]

In fact I don't think we even deliberately enabled parallelized background fsck'ing. For this bug and bug 255563 I just plan to make the init scripts wait properly for fsck termination again. For now I have no idea why fsck suddenly runs in the background, the usplash scripts didn't change since Hardy. We probably inherited it from Debian with a new sysvinit merge, I'll track it down.