fsck does not show progress during boot

[Katsudon]

Binary package hint: e2fsprogs

Every time during startup, screen is in the text mode (will be filed as a separate bug report).
During the run of fsck there is no information about the progress of the scan and the user may think that the machine hangs.

This bug seems to be rather similar to Bug #110373.

System is setup on LVM with separate partitions for root and home.

ProblemType: Bug
Architecture: i386
Date: Thu Oct 8 20:51:21 2009
DistroRelease: Ubuntu 9.10
Package: e2fsprogs 1.41.9-1ubuntu1
ProcEnviron:
 LANGUAGE=pl_PL.UTF-8
 LANG=pl_PL.UTF-8
 SHELL=/bin/bash
ProcVersionSignature: Ubuntu 2.6.31-12.41-generic
SourcePackage: e2fsprogs
Uname: Linux 2.6.31-12-generic i686

[Katsudon (katsudon)]

After recent upgrades, the screen is no longer in the text mode but the new splash screen still does not show fsck progress indicator (I know that it must be fsck since some reboots were after a very unclean shutdown).

[Richard Hansen (rhansen)]

In addition to showing fsck progress, Jaunty allows the user to cancel the fsck. It would be nice if Karmic allowed the same.

[Luke (lukekuhn)]

   As of now, usplash will show the console when killed for a manual fsck run, but is nonreponsive during a forced check. It will of course time out on a long enough check.

  There is also a console bug at this part of the boot process that may complicate a fix. When I was playing with temporary mountall scripts, I found that I could not echo messages to the console-they would not show up, no matter what the verbosity status. If I ran usplash, I could get them by using usplash_write in the script, but could not echo them to a console.

  I am about to set a forced check with no usplash to see if the console as of now will show anything without usplash. If not, we've got bigger problems than usplash integration and need to fix them together.

[Luke (lukekuhn)]

  Just ran forced check of /dev/sda1 without usplash on the boot, not a peep on the console from mountall or fsck. If an inexperienced end user hits a forced check on a big drive, maybe a 1TB drive, they will surely conclude the machine has hung up-and will again on subsequent boots. This will be a problem both with and without usplash, as the console doesn't seem to work between the start of init after / is mounted read-only and the remounting of / rw .

For end users straight from the world of Windoze, with big disks, this means real trouble...

[Jesse Michael (jesse.michael)]

Even with only a 50G / partition, I was convinced that my laptop was hanging and it was only on the third reboot when I tried booting up in "recovery" mode that I figured out it was because it was fscking because it'd reached the mount limit. And I've been using Linux primarily for over a decade now.

[Scott James Remnant (Canonical) (canonical-scott)]

I've uploaded a new version of mountall (0.2.5) to the ubuntu-boot PPA, as usual I would appreciate a little testing before I upload it to the archive proper.

Thanks

[elrond (elrond.)]

I can confirm that version 0.2.5 of mountall resolves the problem (I have karmic, ext3 file system on an i686 machine): now appears this progress bar
[------------------------------------------]
with # to indicate the progress:
[##########--------------------------------]

I had to modify the max-mount-counts in tune2fs because due to bug #363271 I cannot run fsck in recovery mode :(

[Martin Pitt (pitti)]

Closing manually, changelog typo.

mountall (0.2.5) karmic; urgency=low

  * Filesystem check progress reporting, including cancellation. LP: 446596.
  * When we're waiting for a mountpoint, if a few seconds of inactivity
    passes, report what we're waiting for and allow Escape to drop you to
    a recovery shell.
  * Start usplash for filesystem check progress reporting or when we've
    been waiting for more than a few seconds. LP: #431184.

  * Hide error removing /forcefsck, people mis-report this as a bug and
    don't tell us the error above it.
  * Don't call mount.ecryptfs or mount.aufs when adding an entry for
    /etc/mtab; these helpers are broken and do not support the -f argument.
    This means your passphrase may end up in /etc/mtab, blame them not me.
    LP: #431954, #443080.
  * Unlink /etc/mtab~ after creating/truncating /etc/mtab and before writing
    mtab entries. LP: #431865.
  * Stop the recovery shell if the user runs shutdown within it, so we
    don't run mountall again. LP: #452196.
  * If the root filesystem check fails, we'll need to reboot, so just have
    the recovery shell script do that.

  * Post-review logic fixes.

 -- Scott James Remnant < <email address hidden>> Tue, 20 Oct 2009 12:19:16 +0100

[Chihiro Kuroki (9nzj7bot)]

> * Filesystem check progress reporting, including cancellation. LP: 446596.
  * Filesystem check progress reporting, including cancellation. LP: #446596.
Please write in the proper format for LP.

[Jarmo (jjarven)]

Ubuntu 12.04.1 LTS (precise) has still this problem, no visual indication of fsck process.

With even small raid setup, fsck takes easily 10 min or more.