Bug 15072

Summary: /forcefsck no longer checks all filesystems
Product: Mageia Reporter: Theodoros Kalamatianos <thkala>
Component: RPM PackagesAssignee: Colin Guthrie <mageia>
Status: NEW --- QA Contact:
Severity: normal    
Priority: Normal    
Version: Cauldron   
Target Milestone: ---   
Hardware: x86_64   
OS: Linux   
Whiteboard: MGA5TOO
Source RPM: CVE:
Status comment:

Description Theodoros Kalamatianos 2015-01-17 20:22:17 CET 
I recently tried the `touch /forcefsck` trigger to force all my filesystems to be checked - `mount' had been whining for quite some time about check time limits being reached. On the next reboot the `/forcefsck' file was (correctly) removed automatically, the root filesystem was checked, but none of the other filesystems was. All filesystems in question are Ext4 and `tune2fs -l` confirms that only `/' was checked.

I am not certain what the root cause is, but I consider this a regression, since it removes a very simple way for an administrator to check all filesystems.


Reproducible: 

Steps to Reproduce:
David Walser 2015-01-17 20:23:50 CET

Assignee: bugsquad => mageia

Comment 1 Theodoros Kalamatianos 2015-01-26 17:28:46 CET 
It seems that it is now possible to forcefully check all filesystems on boot by suppling the `fsck.mode=force' option at the kernel command line.

It's not quite the same, since it requires either access to the bootloader console or a modification of its configuration, but for most users it's simpler than checking all filesystems manually. That said, I'm not sure what happens if systemd decides that the root filesystem needs repairs that prevent the boot process from continuing. One of the two times that I used that option, my computer powered-down after checking the rootfs, rather than rebooting, and any messages scrolled by way too fast for me to read before the screen turned off.
Samuel Verschelde 2015-05-31 23:34:49 CEST

Whiteboard: (none) => MGA5TOO

Comment 2 Colin Guthrie 2015-06-01 10:47:27 CEST 
FWIW, it the case of the root filesystem, it's actually dracut that processes this file, not systemd.

It checks the root filesystem *before* the system boots, and it removes the file before systemd can then use that file as a trigger for all other filesystems.

There is a bit of a chicken and egg scenario here: e.g. if the initrd mounts the filesystem as ro and the system does NOT remount it rw (as is a sensible situation) then the system cannot remove the file and thus it will stay forever. Removing the file in the initrd therefore makes sense.

If I'm reading the code correctly, one way to prevent this is to add "ro" to the to kernel command line. This will make the initramfs mount the root filesystem readonly, which will prevent it from removing the file, then the system should have the file still around for it to be used as a trigger for other filesystems.

This chicken and egg problem is one of the reasons a file on one fs is a really bad idea as a global trigger. I you want a readonly fs, and it has this file on it, then it will be used every boot. Additionally if your filesystem is potentially corrupted, writing a file to it is a really bad idea. These reasons and more are why a command line option is a better idea.

I think the logic used in dracut is kinda sensible, but could be make a bit more intelligent. e.g. if it knows the filesystem will be made writable later by the system (by checking the fstab), then it could leave the file in place as a trigger for others.

But either way, this would likely be fixed by using systemd in the initramfs which is what we intend to do after MGA5 is out, so I suspect this won't actually get fixed.