Description of problem: systemd-fsck incorrectly uses fsck.btrfs to check a btrfs subvolume Version-Release number of selected component (if applicable): F18 How reproducible: yes Steps to Reproduce: 1.boot 2. 3. Actual results: fsck.btrfs missing so that testing that file system fails Expected results: btrfsck is used Additional info: There are two potential fixes: systemd can change or btrfs-progs and add a symlink.
I think this is best fixed in btrfs-progs - attempting to special-case a command name per filesystem type doesn't scale.
It might not be as simple as just adding a symlink (which is what I did manually). It appears that btrfsck does not like being passed "-a"
AFAIK btrfsck is a debugging and repair tool, not really something that should be invoked during normal boots. Hence they do not provide the "fsck.btrfs" name. (If you ask me they should not have named it btrfsck really, to avoid this confusion, and picked a name like btrfs-repair or so, copying what XFS did...) Anyway, reassigning to btrfs-progs, as this really has nothing to do with systemd, but is between util-linux and btrfs-progs.
If btrfsck is not equivalent to the fsck for other file systems then I suspect that is because btrfs does not need one. I still believe that there is a systemd problem here and it should not be invoking fsck.btrfs, If they insist on ignoring it, then I guess the best bet is to add a dummy shell script so no errors occur.
Is the volume listed in /etc/fstab? Does it have "0 0" in it, like it should be, because there is no fsck supposed to run.
Mmmm ... NO! Looks like another update for anaconda. Is this (the fact that 0 0 should be in /etc/fstab) written somewhere? At the very least, this should go into the release notes. Is this a BLOCKER ... not in my opinion ... then again, if it is not fixed before F18 is released this is going to be there for the F18 lifetime.
*** This bug has been marked as a duplicate of bug 862871 ***