Description of problem: Systemd installs a job to fsck btrfs volumes twice, even though the fstab says not to do this. No actual problem occurs, since later it figures out there is no fsck.btrfs, but it seems it shouldn't even attempt this once let alone twice. Version-Release number of selected component (if applicable): systemd-212-4.fc21.x86_64 How reproducible: Always with any btrfs fs in fstab. Actual results: systemd[1]: Installed new job systemd-fsck@dev-disk-by\x2duuid-d372e5d1\x2d386f\x2d460c\x2db036\x2d611469e0155e.service/start as 32 systemd[157]: Executing: /usr/lib/systemd/systemd-fsck /dev/disk/by-uuid/d372e5d1-386f-460c-b036-611469e0155e systemd-fsck[157]: /sbin/fsck.btrfs doesn't exist, not checking file system. Expected results: No attempt to even check it. Additional info:
Installed new job systemd-fsck@dev-disk-by\x2duuid-d372e5d1\x2d386f\x2d460c\x2db036\x2d611469e0155e.service/start as 32 Installed new job systemd-fsck@dev-disk-by\x2duuid-d372e5d1\x2d386f\x2d460c\x2db036\x2d611469e0155e.service/stop as 233 Not sure why it tries it a second time after failing the first time.
Created attachment 896830 [details] complete journal # journalctl -b -l -o short-monotonic --no-pager Includes boot parameters systemd.log_level=debug rd.debug rd.udev.log-priority=debug
Created attachment 896831 [details] fstab
(In reply to Chris Murphy from comment #1) Aha, the 2nd one is a stop job, not a start job. So the bug is why there's a job at all, not why are there two.
Created attachment 896858 [details] filtered journal for "fsck" journalctl -b -l -o short-monotonic --no-pager | grep fsck The first two entries in the journal are confusing. [ 1.489005] rawhide.localdomain systemd[1]: Failed to load configuration for systemd-fsck-root.service: No such file or directory [ 1.489905] rawhide.localdomain systemd[1]: Installed new job systemd-fsck@dev-disk-by\x2duuid-d372e5d1\x2d386f\x2d460c\x2db036\x2d611469e0155e.service/start as 32 But I note that their timestamps come before the ro mount at /sysroot so I don't see how it could have consulted fstab. [ 2.822771] rawhide.localdomain systemd[166]: Executing: /bin/mount /dev/disk/by-uuid/d372e5d1-386f-460c-b036-611469e0155e /sysroot -t auto -o subvol=root,ro So then I decided to see if there's an fstab in the initramfs: -rw-r--r-- 1 root root 0 May 18 12:59 etc/fstab.empty And if it's really empty, and yes it really is empty. I'm going to guess this is intentional because an fstab in initramfs can go stale; and better to assume the root UUID needs fsck before mounting ro. So it's probably not a bug.
/usr/sbin/fsck.btrfs is provided by btrfs-progs 3.14 now, but it's not in the initramfs. Should this be filed as a separate bug against dracut? systemd-fsck[157]: /sbin/fsck.btrfs doesn't exist, not checking file system. The fsck.btrfs is like fsck.xfs, it doesn't actually check the file system for consistency. It's a placeholder to prevent above error messages from happening, and if the user runs it, it tells them what program to run to check the file system.
Created attachment 907358 [details] journal and fstab for XFS system This happens for root on XFS with fs_passno 0 also. Basically it looks like fs_passno 0 is ignored for the / mountpoint.
(In reply to Chris Murphy from comment #5) > The first two entries in the journal are confusing. > [ 1.489005] rawhide.localdomain systemd[1]: Failed to load configuration > for systemd-fsck-root.service: No such file or directory > [ 1.489905] rawhide.localdomain systemd[1]: Installed new job > systemd-fsck@dev-disk-by\x2duuid- > d372e5d1\x2d386f\x2d460c\x2db036\x2d611469e0155e.service/start as 32 > > But I note that their timestamps come before the ro mount at /sysroot so I > don't see how it could have consulted fstab. Those are two separate issues. Let's discuss systemd-fsck-root.service in #1107818. Before /sysroot is mounted and the initramfs can read /sysroot/etc/fstab, it has no way of knowing whether it should check the device. Of course is assumes that it should, since that is the best moment, before the device is mounted at all. If you want to skip fsck on the root, you must specify that on the kernel commandline somehow. But I think its not possible right now.
Or alternatively effectively deprecate fs_passno for root? Is it sane for systemd to become aware (via kernel) what file system root is? If it's ext234, then always do fsck. If XFS or Btrfs never do it. For now it seems for ext234 fsck is always applicable (if not the every boot preen, then for sure the max-mount-counts and interval-between-checks requires periodic force). That implies always do it for ext. And XFS and Btrfs shouldn't have it done automatically ever anyway. They depend on journal/fsmetadata replay to determine consistency and make any repairs that can safely be automatically made and if that process fails then the fs does not mount and the user must manually intervene.
fsck.mode=skip can be used to skip all fscks. Since systemd-232 (commit https://github.com/systemd/systemd/commit/d7f69e16f1 specifically), rd.fsck.mode=skip can be used to skip fscks in the initramfs. I think this can be closed now ;)