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.


** Changed in: sysvinit (Ubuntu)
       Status: New => Confirmed

-- 
no progress indication for fsck in recovery mode
https://bugs.launchpad.net/bugs/528128
You received this bug notification because you are a member of Ubuntu
Bugs, which is subscribed to Ubuntu.

-- 
ubuntu-bugs mailing list
[email protected]
https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs

Reply via email to