systemd-fsck does not show results of rootfs filesystem check in logs or journald

[Adam Blomberg]

Prior to the systemd paradigm shift, Ubuntu versions provided mechanisms to be able to see the results of a filesystem check performed on the root filesystem either in boot.log in 12.04 or in mountall.log in 14.04.

As of 16.04, there is no way to see the output of systemd-fsck when it is run on the root filesystem.

root@ubuntu-16-04-1:~# lsb_release -rd
Description: Ubuntu 16.04.1 LTS
Release: 16.04

root@ubuntu-16-04-1:~# apt-cache policy systemd
systemd:
  Installed: 229-4ubuntu7
  Candidate: 229-4ubuntu7
  Version table:
 *** 229-4ubuntu7 500
        500 http://us.archive.ubuntu.com/ubuntu xenial-updates/main amd64 Packages
        100 /var/lib/dpkg/status
     229-4ubuntu4 500
        500 http://us.archive.ubuntu.com/ubuntu xenial/main amd64 Packages

Steps to reproduce:

1) Force fsck on next reboot by altering linux boot commandline:
   Edit /etc/default/grub and add "fsck.mode=force" to the GRUB_CMDLINE_LINUX variable.
   If you also want to force repair behavior, also add "fsck.repair=yes" to the same variable.

# example:
GRUB_CMDLINE_LINUX="fsck.mode=force fsck.repair=yes"

Once the changes have been made, run "sudo update-grub" to update the boot info, then reboot.

2) After boot, journalctl does not report any filesystem repair details for the root fs, only for secondary filesystems such as /boot or others designated in /etc/fstab.

[Adam Blomberg (paradox606)]

Added milestone xenial-updates

[Launchpad Janitor (janitor)]

Status changed to 'Confirmed' because the bug affects multiple users.

[Martin Pitt (pitti)]

This is unrelated to systemd. Instead, fsck'ing the root file system got moved into the initrd. You can find the log in /run/initramfs/fsck.log.

[Adam Blomberg (paradox606)]

Thank you for the clarification Martin.

I was able to confirm that the fsck results are located in /run/initramfs/fsck.log on my test system as you described.

I found that if the /etc/default/grub file was modified to include:

GRUB_CMDLINE_LINUX="fsck.mode=force"

Then after running "sudo update grub" and rebooting, the basic result was shown in /run/initramfs/fsck.log:

Log of fsck -C -f -a -V -t ext4 /dev/mapper/ubuntu--16--04--1--vg-root
Wed Sep 7 14:42:05 2016

fsck from util-linux 2.27.1
[/sbin/fsck.ext4 (1) -- /dev/mapper/ubuntu--16--04--1--vg-root] fsck.ext4 -f -a -C0 /dev/mapper/ubuntu--16--04--1--vg-root
/dev/mapper/ubuntu--16--04--1--vg-root: 97274/689520 files (0.1% non-contiguous), 534347/2757632 blocks

Wed Sep 7 14:42:06 2016
----------------

If I modify /etc/default/grub to include:

GRUB_CMDLINE_LINUX="fsck.mode=force fsck.repair=yes"

Then after running "sudo update grub" and rebooting, the verbose result was shown in /run/initramfs/fsck.log:

Log of fsck -C -f -y -V -t ext4 /dev/mapper/ubuntu--16--04--1--vg-root
Wed Sep 7 14:38:19 2016

fsck from util-linux 2.27.1
[/sbin/fsck.ext4 (1) -- /dev/mapper/ubuntu--16--04--1--vg-root] fsck.ext4 -f -y -C0 /dev/mapper/ubuntu--16--04--1--vg-root
e2fsck 1.42.13 (17-May-2015)
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/mapper/ubuntu--16--04--1--vg-root: 97271/689520 files (0.1% non-contiguous), 534306/2757632 blocks

Wed Sep 7 14:38:20 2016
----------------

Best regards,

-Adam

[Ivan Baldo (ibaldo)]

But it should be persisted by default in /var/log, so there should be a unit somewhere that if the log has information then it appends it in a file and gets logrotated.

That way, if a server or PC is acting strange, one could look there to see if something strange happened to the filesystem and when it happened.

The log shouldn't be lost...