Bug 1278361

Discussion on the matter:

http://thread.gmane.org/gmane.comp.sysutils.systemd.devel/20572

fsck.xfs is a no-op anyway, so why bother?

While I agree that hard-coding a skip into systemd is a very bad idea, I also see no advantage to changing the fsck.xfs that we have today.

What does it gain?

fsck.xfs also informs the hapless user that they're using the wrong tool, if they invoke it in non-auto mode:

# fsck.xfs /dev/sdb1
If you wish to check the consistency of an XFS filesystem or
repair a damaged filesystem, see xfs_check(8) and xfs_repair(8).


so I see no compelling reason to change this to a symlink.  Can you convince me?

Also, I believe that fsck.xfs exists because on some systems, if an fs_passno is non-zero (or maybe even if it is zero?), a missing fsck.$FSTYPE will cause the system to fail boot.  I don't remember exactly, but in the back of my head that was the case, and was the original motivation for the helper script.

See also
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=750673

The gain is avoid pointless processes spawned at boot. But you raised the hapless user case, that is indeed valid. However I assume any competent admin would read a man page before interacting with the filesystem in use.

util-linux's fsck does not error out if fsck.xfs and fsck.btrfs are missing since version 2.25 and just returns 0:

https://git.kernel.org/cgit/utils/util-linux/util-linux.git/commit/?id=c7a96884eb10997286233527fcd4dcaa64d72853

Debian does not use systemd in its initramfs. In Wheezy they did not even used systemd at all (by default).

There is a problem in dracut unfortunately. It transforms an absolute symlink into a relative one in the initramfs and breaks systemd-fsck logic. Probably an easy fix.

Not sure I can convince you. Anyway, fsck.xfs(8) and true(1) are *very* similar. :-)

Thanks for the util-linux commit link, that's good to know.

But also - why is fs_passno == 0 not sufficient to avoid the fsck call in the first place?  systemd can recognize a link to /bin/true but doesn't parse fstab for fs_passno?

"If the sixth field is not present or zero, a value of zero is returned and fsck will assume that the filesystem does not need to be checked."

(I understand that Debian does not use systemd in initramfs; this just points out that all the world is not systemd, so we can't cater exclusively to its needs & desires)

> However I assume any competent admin would read a man page before interacting with the filesystem in use.

You're funny!  ;)

Anyway, fsck.xfs does 2 things; it returns an error if the device doesn't exist at all, and does the warning about using the wrong tool, if it seems to have been invoked by an admin.  I'm not sure about the historic reasons for the device check, either, to be honest.

I can't imagine that the overhead of spawning a trivial & short shell script is all that critical, is it?  Unless there is some actual *problem* which needs fixing here, I'm inclined to leave things as they are.  But, this could also be brought up on the XFS list for further discussion, if you'd like.

Hmm, yes, systemd is running fsck on my root filesystem in the intramfs with fs_passno 0. I will take a look at that.

I got it. Dracut, only for root= and usr= cmdline filesystems, always assumes fs_passno 1, as it does not carry (at least by default) an fstab copy. After systemd switched to the root filesystem, fstab-generator will interpret /etc/fstab for the remaining ones.

In the end, you are right. Let's keep things as they are now. Sorry for the noise.

(In reply to Marcos Mello from comment #8)
> I got it. Dracut, only for root= and usr= cmdline filesystems, always

The option is mount.usr= actually.