no progress indication for fsck in recovery mode

[Martin Pool]

Binary package hint: sysvinit

This seems like a regression in lucid:

If you choose 'recovery mode' from the grub menu and the machine needs/wants to do a fsck, there is no indication that this is happening: it doesn't say it's doing a fsck and there is no progress indicator. It just sits there with the drive running. If you hit ctrl-alt-del then it does say something like 'fsck aborted'.

ProblemType: Bug
Architecture: i386
Date: Fri Feb 26 11:08:58 2010
DistroRelease: Ubuntu 10.04
Package: initscripts 2.87dsf-4ubuntu14
ProcEnviron:
 PATH=(custom, user)
 LANG=en_AU.UTF-8
 SHELL=/bin/zsh
ProcVersionSignature: Ubuntu 2.6.32-14.20-generic
SourcePackage: sysvinit
Uname: Linux 2.6.32-14-generic i686

[John S. Gruber (jsjgruber)]

This happens to me also.

From what I can tell, mountall is starting the fsck and is racing udev, which is started when mountall mounts the virtual files systems and emits the corresponding event.

On my system udev finds one of several framebuffer devices and initializes it. The starting module switches modes and clears the framebuffer, and the just issued fsck message with it.

There is a fraction of a second between the fsck message and the video screen clear. Sometimes I can just see the message before it disappears and sometimes I can't.

What's worse, if I run without a splash this will happen as well (1 out of 24 times the way my ext3 file system was set by default).

A couple of thoughts on addressing this:

Start udev on local-filesysytems rather than virtual-filesystems (upstart file /etc/init/udev.config). This is a very easy thing to change and allows one to see that fsck is running, but doesn't display the status that Martin was looking for. Since the delays the moment the login screen appears I measured the delay caused by such a change. They are below.

I don't know whether udev needs the root file system to be writeable for logging.

--

The other approach would be to have mountall output regular progress messages if it is not connected to a splash daemon. More work but a better solution.

When I read about plymouth I get the impression that plymouth should be running and the video set for good at the beginning of the boot process. I don't know if that means that there is something wrong with my set-up. (01:05.0 VGA compatible controller: ATI Technologies Inc RS690M [Radeon X1200 Series] on a Toshiba L355D-S7825 laptop).
---------

With no splash program installed I measured the time from the beginning of boot to when udev is started by upstart--measured with the system's boot clock in /var/log/syslog.

Starting at virtual-filesystems (current):
22.419
22.421
22.419
22.521
22.421
22.523
22.437
Average--22.450

Starting at local-filesystems:
22.821
22.864
22.981
22.807
22.934
Average--22.881
For a difference of .43 second delay (+5.5 minute delay for a full fsck on my file system)

--

If the no splash issue were to be ignored I guess the udev start check could include a runlevel test and the .43 second delay could be avoided.

[John S. Gruber (jsjgruber)]

When I boot the latest kernel versions released for lucid the screen is clearing within a couple of seconds of udev starting, 20 some seconds after the beginning of the boot process.

When I boot with an older kernel( 2.6.32-10) my initrd image contains both framebuffer and plymouth contents and my console switch to graphics happens much earlier. When this happens I can see the fsck message about having to check the disk and it stays on the screen (because there is no late probe of a framebuffer driver, I suppose).

No fsck progress is reported, however, which will make someone unfamiliar with Unix wonder if the system was hung.

[dino99 (9d9)]

There is no support on such deprecated version; that one has died long time ago.