6

enter image description hereI was reading through all the things that are run during bootup and have seen that after mounting the rootfs, /sbin/fsck.ext4 is run and after that systemd is run. I was wondering where or how fsck is run, because I was searching for it in the kernel source code and couldn't find it and its not part of the init scripts. So what runs fsck? The distro I am using is mint.

EDIT: In this image it is shown that fsck is run after mounting the root file sytem

5

Edit 2: checked sources

I've found the ubuntu initramfs-tools sources. Here you can see clearly, the Begin: "Mounting root file system" message is printed first, but in the mount_root function fsck is run before the actual mounting. I have ommited some non-relevant code, just to indicate the order. (If you would inspect the linked sources you will find also the other reported scripts from the screenshot).

/init line 256

log_begin_msg "Mounting root file system"
# Always load local and nfs (since these might be needed for /etc or
# /usr, irrespective of the boot script used to mount the rootfs).
. /scripts/local
. /scripts/nfs
. /scripts/${BOOT}
parse_numeric ${ROOT}
maybe_break mountroot
mount_top
mount_premount
mountroot
log_end_msg

/scripts/local @line 244

mountroot()
{
    local_mount_root
}

/scripts/local @line 131

local_mount_root()
{
# Some code ommited
    # FIXME This has no error checking
    [ -n "${FSTYPE}" ] && modprobe ${FSTYPE}

    checkfs ${ROOT} root "${FSTYPE}"

    # FIXME This has no error checking
    # Mount root
    mount ${roflag} ${FSTYPE:+-t ${FSTYPE} }${ROOTFLAGS} ${ROOT} ${rootmnt}
    mountroot_status="$?"
    if [ "$LOOP" ]; then
        if [ "$mountroot_status" != 0 ]; then
            if [ ${FSTYPE} = ntfs ] || [ ${FSTYPE} = vfat ]; then
                panic "<Error message ommited>"
            fi
        fi

        mkdir -p /host
        mount -o move ${rootmnt} /host
# Some code ommitted
}

Original answer, retained for historical reasons

Two options:

  1. Root is mounted read-only during boot and the init implementation is running fsck. Systemd is the init implementation on mint, and since you already checked if it exists there, this option does not apply.
  2. /sbin/fsck.ext4 is run in the "early user space", set up by an initramfs. Which is most probably the case in your system.

Systemd

Even if you noticed that /sbin/fsck.ext4 was run before systemd, I want tot elaborate a bit. Systemd is perfectly capable of running fsck itself, on a read-only mounted filesystem. See systemd-fsck@.service documentation. Most probably this service is not enabled by default in mint, since it will be redundant with the early user space one.

Initramfs

I don't know which implementation of an initramfs mint is running, but I will use dracut as an example. (used in Debian, openSuse and more) It states the following in its mount preperation documentation:

When the root file system finally becomes visible:

  • Any maintenance tasks which cannot run on a mounted root file system are done.
  • The root file system is mounted read-only.
  • Any processes which must continue running (such as the rd.splash screen helper and its command FIFO) are hoisted into the newly-mounted root file system.

And maintenance tasks includes fsck. Further evidence, there is a possibility in dracut cmdline options to switch off fsck:

rd.skipfsck

skip fsck for rootfs and /usr. If you’re mounting /usr read-only and the init system performs fsck before remount, you might want to use this option to avoid duplication

Implementations of initramfs

An dynamic (udev based) and flexible initramfs can be implemented using the systemd infrastructure. Dracut is such an implementation and probably there are distro's out there that want to write their own.

Another option would be a script based initramfs. In such a case busybox ash is used as a scripting shell and maybe even replacing udev with mdev, or maybe just completely static. I found some people being dropped to a busybox shell due to some fsck error int mint, so this implementation could apply to mint.

If you really want to know for sure, try to decompress the initramfs file in /boot and see what's in there. It might also be possible to see it mounted under /initramfs.

  • dracut is available in Debian, but it isn’t used by default; Debian uses initramfs-tools. The general principle is the same. – Stephen Kitt Jul 1 '18 at 20:54
1

systemd-fsck@.service and systemd-fsck-root.service are services responsible for file system checks. They are instantiated for each device that is configured for file system checking. systemd-fsck-root.service is responsible for file system checks on the root file system, but only if the root filesystem was not checked in the initramfs. systemd-fsck@.service is used for all other file systems and for the root file system in the initramfs.

https://www.freedesktop.org/software/systemd/man/systemd-fsck@.service.html

It sounds like you also might be interested in this:

https://www.freedesktop.org/software/systemd/man/bootup.html

  • The question is talking about the fsck on the root filesystem that is run from the initramfs before executing /sbin/init//lib/sytemd/systemd. – JdeBP Jun 28 '18 at 7:47
  • 2
    The bootup link does contain some additional background info. dracut (mentioned in my asnwer) is in fact an implementation of a systemd based initramfs – Tim Jun 28 '18 at 7:54
  • The question is both under & over constrained. It asks where fsck is run, not specifically fsck of the rootfs. And it says that the root is fscked after being mounted - however, if you use e.g. dracut to mount the root filesystem, the fsck will happen before the root is mounted. It is fair to say that not everyone uses dracut though and they may use initramfs implementations which do not use systemd. (Also that most people do use an initramfs, I think I had not explicitly considered this, as i say because it conflicted with the question). – sourcejedi Jun 28 '18 at 8:39
  • You're overthinking the question. The questioner knows that fsck is run. On many systems one can see that happen, after all. Xe does not necessarily know when it is run relative to the mount, since that is part of what xe is asking about, so allow for that to be wrong. But xe is looking in the kernel code and in the rc scripts, and thus we can deduce that xe doesn't know to also look at the initramfs, or realize that there is early filesystem checking done there. – JdeBP Jun 28 '18 at 15:03

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.