Does not log fsck invocations in /var/log/fsck/

I am affected too.
'~$ uname -a; Linux T43 2.6.32-28-generic #55-Ubuntu SMP Mon Jan 10 21:21:01 UTC 2011 i686 GNU/Linux'

I'm affected by this bug too.

Linux gurke 2.6.32-29-generic #58-Ubuntu SMP Fri Feb 11 20:52:10 UTC 2011 x86_64 GNU/Linux

I'd also like to question the Importance category. For me, and maybe other server operators too, it's very important to be able to review the logs of bootup filesystem checks. My machine is running 24/7 and I regularly reboot it remotely, for example after installing updates, and I do not monitor the bootup, but check the logs later, when I have the time.

This affects me too, in precise (12.04.3). Just ran an fsck on three drives, which was carried out (I looked at the "xx% completed " message for each of the drives. Unfortunately /var/log/fsck only shows two default files that are only 31 characters long.

This also affects me.
Linux fs 3.2.0-35-generic #55-Ubuntu SMP Wed Dec 5 17:42:16 UTC 2012 x86_64 x86_64 x86_64 GNU/Linux

Over three years later and this is unassigned still?

I question the "wishlist" categorization of this as well. Ubuntu remains a sub-par choice for server distros because of bugs such as this.

Even watching the fsck logs on bootup, the messages disappear too quickly for you to see what happened.

Uh, how can this possibly be considered a 'wishlist' item? This is core functionality, and it's broken. Far as my company is concerned, this is an URGENT BUG. Please escalate.

Linux gr 3.0.0-13-virtual #22-Ubuntu SMP Wed Nov 2 17:10:19 UTC 2011 i686 i686 i386 GNU/Linux

Even on MS Windows you can dig out fsck messages with the eventviewer. This is stupid, lazy and arrogant.

This is a critical bug. One of those bugs you find when everything is in danger, and about to be lost. As I gently type, I'm trying to find ways to recover my server. I know there has to be a disk about to fail, I've seen the strange behavior on boot and because I was there I know something is wrong.

But there is no log about it.

If you are so insensitive to keep this bug as a wishlist, if you truly don't care that not having a good log about a critical event on boot is crushing our hearts, you will be hurting the sysadmin community.

And this is no good.

Because we know for sure this is easy to fix. A silly bug indeed.

Tristan, I agree with you, but unfortunately would have to recommend using Debian instead of Ubuntu for server applications. Not only was this bug the result of an oversight in switching to mountall, mountall itself made the system less admin-friendly by doing away with several boot-time shell scripts (which could be inspected and directly edited as necessary), in favor of a better consumer desktop startup experience. Server usage in general is an afterthought here.

Ehm, this bug is still here in trusty, more than four years after it was originally reported. And it does seem to be quite an essential thing, being able to see the output of your file system repair. Can it really be so hard to have fsck save the output somewhere?

Any workaround the user can do to force the results to be logged in any file?

Marcelo: You could make /sbin/fsck a shell script that wraps the real fsck binary, and logs the output as desired. Doing this with a dpkg diversion might even keep things from breaking when the util-linux package is upgraded....

How is this bug still here after 4.5 years?

I mean, I'd rather lose the whole rest of /var/log than my fsck logs -- and I may even be about to!

There is some terse fsck info being logged on my 14.04 Trusty desktop in /var/log/upstart/mountall.log. Usually, it says something like this:

fsck from util-linux 2.20.1
grubboot: clean, 520/51200 files, 98181/204800 blocks

When I force checking by setting "Maximum mount count" to 1, it looks like this:

fsck from util-linux 2.20.1
grubboot has been mounted 1 times without being checked, check forced.
grubboot: 520/51200 files (10.4% non-contiguous), 98181/204800 blocks

I'm assuming that it didn't find any errors, and hoping that it will be more verbose if it does.

I might try messing with mountall.conf to try to force it to use --verbose when calling mountall and see what that does.

Can confirm still present in 14.04 - NOT Triaged.

even windows store ntfs chkdsk boot logs in the logs db, is windows more professionnal than ubuntu?

This is Critical, not Wishlist... Please change the importance so that this gets fixed.

It's pretty ignorant to assume that this is a wishlist item. This is an essential log.

Bump

Oh, for God's sake and in the name of all that's holy.

Bump.

Critical bug, please fix!

Having a log would help a lot when doing remote check disk.

At the very least, telling why it's not important would be a first step instead of just ignoring this bug for the past 6 years.

I'm sorry, guys, but this sucks. Critical bug unsolved for six years - the responsible person should get spanked bare bottom.

Tested reboot with forcefsck file in root on Xenial [Ubuntu 16.04.1 LTS], with following results:

# cat /var/log/fsck/checkfs
(Nothing has been logged yet.)
# cat /var/log/fsck/checkroot
(Nothing has been logged yet.)
# cat /var/log/upstart/mountall.log
cat: /var/log/upstart/mountall.log: No such file or directory

The system has mountall version 2.54ubuntu1 (amd64) and kernel 4.4.0-34-generic #53-Ubuntu

After discussing the issue with Adam Blomberg (paradox606), he suggested enabling the verbose option to get more information regarding the scan.

He indicated that this can be done by modifying /etc/default/rcS to include "VERBOSE=yes", and that it is also possible to force the repair of errors with the "FSCKFIX=yes" option. This will result in additional detail in the logs SideShowFry (fry-n) was looking at.

Adam's suggested method:

12.04 Force FIlesystem Check:
-----------------------------------------
# tell system to force filesystem checks on startup for all filesystems in /etc/fstab with indications to do filesystem checks.
touch /forcefsck

# Tell system to be more verbose at startup
sudo sed -i "s/VERBOSE=no/VERBOSE=yes/" /etc/default/rcS

# Then, after reboot, examine /var/log/boot.log, the results of the filesystem check will be visible there.

# If you also want the filesystem check to perform all repairs, make this change:
sudo sed -i "s/FSCKFIX=no/FSCKFIX=yes/" /etc/default/rcS

14.04 Force FIlesystem Check:
-----------------------------------------
# tell system to force filesystem checks on startup for all filesystems in /etc/fstab with indications to do filesystem checks.
touch /forcefsck

# Tell system to be more verbose at startup
sudo sed -i "s/#VERBOSE=no/VERBOSE=yes/" /etc/default/rcS

# Then, after reboot, examine /var/log/upstart/mountall.log, the results of the filesystem check will be visible there.

# If you also want the filesystem check to perform all repairs, make this change:
sudo sed -i "s/#FSCKFIX=no/FSCKFIX=yes/" /etc/default/rcS

Performing this myself I find the following on a 14.04 system:

# cat /var/log/upstart/mountall.log
fsck from util-linux 2.20.1
/dev/vda1: clean, 248966/3670016 files, 2280909/14679040 blocks
fsck from util-linux 2.20.1
e2fsck 1.42.9 (4-Feb-2014)
Pass 1: Checking inodes, blocks, and sizes
Pass 2: Checking directory structure
Pass 3: Checking directory connectivity
Pass 4: Checking reference counts
Pass 5: Checking group summary information
/dev/vda1: 248988/3670016 files (0.2% non-contiguous), 2281324/14679040 blocks

Be sure to note the number sign that has been added in the 14.04 config file - the two sed commands are not interchangeable.

Also as per Adam, on 16.04 the /forcefsck functionality is not available, so the recommended method of triggering a filesystem check on boot is to use tune2fs, as this method will work on 12.04, 14.04 and 16.04:

sudo tune2fs -CCOUNT DEVICE

Setting the count to 1 will cause an fsck on each reboot, while -1 disables the scan.

Thank you k-doug for placing the suggested workaround here!

I would also like to mention that with regards to Xenial (16.04) and any Ubuntu release using systemd, the mechanism for forcing filesystem checks on startup is presently unable to display the results of the filesystem check on the rootfs in any logs or in journald, and I have recently opened a defect against systemd [1]. If you would agree with me that systemd-based Ubuntu's should have this visibility, please have a look at this new defect and upvote it if it is also effecting you.

Best regards,
-Adam (paradox606)

[1] - https://bugs.launchpad.net/bugs/1619753