53

When working remotely, I set a server to force an fsck at boot time with the command:

sudo touch /forcefsck

and rebooted.

After it restarted, I checked in /var/log/fsck for the results of the disk check. Both checkfs and checkroot said:

Nothing has been logged yet

So where are the results saved?

1
  • Having the same problem on Ubuntu 12.04 LTS. I found the fsck log in /var/log/boot.log.
    – user143312
    Mar 25, 2013 at 16:01

7 Answers 7

21

For Ubuntu 16.04 and 18.04 root partitions

You're likely looking for /run/initramfs/fsck.log.

An fsck of the root filesystem necessarily happens before the root filesystem has been mounted as writable, so the filesystem check occurs early in the boot process while the system is still running from the initramfs. An fsck log is written to a RAM-backed filesystem (tmpfs) that is available for writing at this time, and it continues to be available after boot at /run/initramfs/fsck.log. This is volatile storage, so fsck logs are lost once the system reboots. It would be nice if these logs were copied to non-volatile storage after the root filesystem is mounted as writable, but this does not appear to be the case.

Here's an example:

$ lsblk
NAME   MAJ:MIN RM   SIZE RO TYPE MOUNTPOINT
sda      8:0    0 238.5G  0 disk 
├─sda1   8:1    0   512M  0 part /boot/efi
└─sda2   8:2    0   238G  0 part /

$ cat /run/initramfs/fsck.log 
Log of fsck -C -a -V -t ext4 /dev/sda2 
Fri Nov 30 22:35:21 2018

fsck from util-linux 2.31.1
[/sbin/fsck.ext4 (1) -- /dev/sda2] fsck.ext4 -a -C0 /dev/sda2 
/dev/sda2: clean, 653295/15597568 files, 6658147/62383360 blocks

Fri Nov 30 22:35:21 2018
----------------
3
  • 1
    For root partitions, this appears to be the only correct answer for 16.04 + systemd. Mar 25, 2019 at 14:14
  • 1
    fyi, time logged is UTC time.
    – laviex
    Sep 17, 2020 at 4:17
  • Bingo, thanks for this!
    – Danijel
    Nov 9, 2022 at 9:10
18

Possibly you are affected by this bug: "Does not log fsck invocations in /var/log/fsck/".

Doug's comment on the bug suggests the following workaround (the formatting has been adjusted to this platform):

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
    
3
  • Most likely. Shouldn't be surprised anymore that it's probably not going to be addressed... May 22, 2012 at 15:33
  • This affects us in a very negative manner as well - we're on EC2 and when servers reboot we need details of things like this. How can this possibly be considered a 'wishlist' item? This is core functionality, and it's broken.
    – tamale
    Nov 13, 2013 at 15:11
  • @tamale You're fully right. I got hit by this too. My / partition had a nasty quirk, and when entering recovery mode, it forced an e2fsck on it. This is perfect, but as it's really hard to remember which files to replace from backup, one must be able to track down the file names reportedly corrupt. Aug 12, 2015 at 20:48
15

For Ubuntu 14.xx:

I found some fsck logs in /var/log/upstart/mountall.log.

6
  • 1
    Welcome to Ask Ubuntu. ;-) There used to be a bug in 11.10 at the time, so your answer on a new system right now doesn't add any value to this 3 year old question. For the future: look at a question's date and whether there already is an answer. ;-)
    – Fabby
    Mar 30, 2015 at 9:56
  • 5
    @Fabby but for future visitors it still might be useful, I think? The version is given (@Shay do you mean 14.04 or 14.10?) and therefore I would say it is a valid answer, although it might not help the OP (who found a solution 3 years ago...)
    – Byte Commander
    Mar 30, 2015 at 15:00
  • I've added a tag to help search engines show this as an old question.
    – NGRhodes
    Mar 30, 2015 at 15:18
  • Absolutely right! :-) That's why I just left a comment. For the record: I didn't down-vote! ;-)
    – Fabby
    Mar 31, 2015 at 7:38
  • 2
    @Byte Commander This supposedly "old" question helped me a LOT indeed! I would never have guessed that fsck logs would be hidden away in /var/log/upstart/mountall.log resp. /var/log/upstart/mountall.*.log.gz. Fairly illogical. HOWEVER, it seems that the file names reported to be corrupt were not logged, just their inodes. Aug 12, 2015 at 20:52
8

For Ubuntu 16.04

The command journalctl -b --no-pager | grep systemd-fsck

reports non root partition file system checks.similar to this:

Mar 22 15:06:26 64bitUbuntu systemd-fsck[750]: /dev/sdb1: clean, 146223/121454592 files, 356711795/485818368 blocks

For root partition checks at boot issue the command more /var/log/boot.log

Provides results similar to this:

/dev/sda2: clean, 349091/1954064 files, 2379983/7814912 blocks
5

For Ubuntu 18.04

The command journalctl -b --no-pager | grep systemd-fsck and grep systemd-fsck /var/log/syslog

both report non root partition file system checks.similar to this:

Sep 25 16:06:29 me-Z370-HD3P systemd-fsck[615]: Scratch: clean, 19/6520832 files, 555602/26081280 blocks
Sep 25 16:06:29 me-Z370-HD3P systemd-fsck[609]: /dev/sda1: clean, 47014/89374720 files, 294970235/357492992 blocks
Sep 25 16:06:29 me-Z370-HD3P systemd-fsck[613]: /dev/sda5: clean, 6707/32727040 files, 7464312/130885120 blocks

Checks of root partitions mounted by UUID results don't appear to be logged even if forced.

1
  • 2
    very nice, thank you, and I confirm it also works in 20.04 LTS
    – xCovelus
    Mar 11, 2021 at 18:01
2

Testing this with Ubuntu 12.04.5 LTS and I found the log on /var/log/boot.log

└❯ grep -A 1 fsck /var/log/*
/var/log/boot.log:fsck from util-linux 2.20.1
/var/log/boot.log-/dev/vda1: 209262/2621440 files (0.1% non-contiguous), 3239494/10485504 blocks
1

For Ubuntu Server 22.04 LTS

 /run/initramfs/fsck.log 

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .