fsck.ext3 > fsck for progress bar


I have a system running openSuSE 11.2 as a file server (no monitor). The files are stored on a ext3 file system, therefore it does a file check every 60 days.

So if the check is forced, the system “hangs” at boot without warning. On openSuSE 10.3 I could see the progress of this check when I switched on the monitor.

openSuSE 11.2 is using fsck.ext3 at boot, it has no progress function. I would like to switch back to the check command fsck:

fsck -a -C /dev/md0

Does anyone know where to change the fsck.ext3 command to fsck in openSuSE for this ext3 device only?

Thanks in advance, Fire

fsck.ext3 also supports the -C option.

man fsck:

In actuality, fsck is simply a front-end for the various file system checkers (fsck.fstype) available under Linux. The file system-specific checker is searched for in /sbin first, then in /etc/fs and /etc, and finally in the directories listed in the PATH environment variable. Please see the file system-specific checker manual pages for further details.

Changing fsck to fsck.ext3 will have no effect.

fsck thinks you are connected to a serial console and so doesn’t want to print a progress bar.

Have a look inside /etc/init.d/boot.rootfsck (line 85) and /etc/init.d/boot.localfs (line 190) to understand what’s going on. Modifying them as necessary should show the progress bar. Though it will get overwritten by updates.


fsck.ext3 also supports the -C option.

I tried that -C option in the cli, the check will start but there is no progress indication.
fsck -a -C /dev/md0 did give the progress bar.


Have a look inside /etc/init.d/boot.rootfsck (line 85) and /etc/init.d/boot.localfs (line 190) to understand what’s going on.

Thanks, I try this tomorrow. I know an update can undo any change, but the partition to check is 1,5T so the check takes 45min! The first time I did abort the check because it looked like the system was hanging (da** those silent HD drives…)

I will report (my) progress :wink:

Did you specify -C 0 to get the progress bar?

Maybe next time you need a root filesystem that’s faster to check.


Did you specify -C 0 to get the progress bar?

No, :shame: I forgot the 0, and yes the correct command does give the progress bar.

So back to the quote from MasterPatricko:

fsck thinks you are connected to a serial console and so doesn’t want to print a progress bar.

In the file boot.localfs I see that the progress bar is switched off (-C option is replaced by -V if /dev/tty1 is not used) There must be a good reason to do so.
Also in openSuSE 10.3 the code contains the same “switch” but fsck never failed to display the progress bar during boot time.

Does openSuSE 11.2 use another console during boot?
Is it safe to replace the -V option or the console number?

Many thanks again, Fire

In addition to my last post above I did a compare between the boot.msg log from SuSE 10.3 and 11.2 to find out witch console is used during boot.

Both files differ in layout but it looks like a bug:

10.3 uses TTY1

Boot logging started on /dev/tty1(/dev/console) at Sun Feb 28 13:46:10 2010

Creating device nodes with udev
Trying manual resume from /dev/sda4
Invoking userspace resume from /dev/sda4
resume: Could not stat configuration file
resume: libgcrypt version: 1.2.4
Trying manual resume from /dev/sda4
Invoking in-kernel resume from /dev/sda4
Waiting for device /dev/disk/by-id/scsi-SATA_TOSHIBA_MK8037G_Y7IOTEN9T-part5 to appear:  ok
fsck 1.40.2 (12-Jul-2007)
[/sbin/fsck.ext3 (1) -- /] fsck.ext3 -a -C0 /dev/disk/by-id/scsi-SATA_TOSHIBA_MK8037G_Y7IOTEN9T-part5 
/dev/disk/by-id/scsi-SATA_TOSHIBA_MK8037G_Y7IOTEN9T-part5: clean, 174369/1576832 files, 1347354/3148732 blocks
fsck succeeded. Mounting root device read-write.
Mounting root /dev/disk/by-id/scsi-SATA_TOSHIBA_MK8037G_Y7IOTEN9T-part5

11.2 uses TTY0???

<6>    0.000090] console [tty0] enabled
<6>    0.004015] Calibrating delay loop (skipped), value calculated using timer frequency.. 3320.37 BogoMIPS (lpj=6640740)
<4>    0.010535] kdb version 4.4 by Keith Owens, Scott Lurndal. Copyright SGI, All Rights Reserved
<6>    0.010631] Security Framework initialized
<6>    0.010664] AppArmor: AppArmor initialized
<4>    0.010690] Mount-cache hash table entries: 512

Like MasterPatricko noted, somehow any update will undo a change to boot.localfs.

I better leave this one to rest until a fix arrives with a future update.

Have you filed a bug for this? A fix won’t arrive unless a bug report has been submitted. Just a heads up. :wink:


Thanks for that link!

This bug was reported some time ago:
Bug 564325 - forced file-system check on boot should show progress indicator

They closed it on 22 feb 2010 so we can expect a fix soon…