It's used by tools like fsck, which is used by forcefsck and so on.
This is still missing in Fedora 15. Adding a symlink gets rid of an annoying boot-up message about missing fsck.btrfs. Is there a reason for not adding this? If not, it should be a trivial fix.
Created attachment 500144 [details] SPEC file patch to create fsck.btrfs -> btrfsck symlink
Josef Bacik, Let me know if I can pull this patch and do a build for Rawhide.
Who cares if fsck.btrfs doesn't actually do anything?
Maybe this should be merged with bug #689512.
The issue is that systemd-units includes a service file that forces an fsck. I think every boot. That is great except my /home partition is formatted with btrfs and is LUKS encrypted. When the system boots it forces a fsck.btrfs on the LUKS partition. When the fsck fails then I get no partition. No partition means it drops out to a root login and no matter what I can't get it to boot further because it won't go with out the home directory. So I end up rebooting and about one in 5 to 7 times it boots in an order where LUKS gets to decrypt the partition before fsck messes things up. As this is my laptop my battery is usually 3/4 dead from constantly rebooting before I can finally get to the desktop. If there isn't a working fsck.btrfs then systemd shouldn't be trying to force it. The forced relabel on systems that have selinux disabled is is in the same boat.
*** Bug 743777 has been marked as a duplicate of this bug. ***
Hmm, Josef mentioned, that no fsck should be done ever by systemd on btrfs devices. btrfsck should only be run by an administrator in case the mount fails. Same applies to xfs, IIRC.
You probably want to set the passno in /etc/fstab to 0 (see 'man fstab'). Btrfs filesystems are not supposed to be checked on bootup. I don't think there is a tool missing in this context, btrfsck is a manual repair tool. Are we sure this bug can't be closed?
(In reply to comment #9) > I don't think there is a tool missing in this context, btrfsck is a manual > repair tool. Can you expound on this statement a bit? > Are we sure this bug can't be closed? Does btrfsck actually do anything? If so, then I would think that the fsck.btrfs symlink should be present. If not, then why is it there?
Btrfs is usually not supposed to be checked by userspace before it is mounted. There is no tool to be called, and no tool should be hooked up here in the future. Userspace fsck for a COW filesystem sounds pretty much like backwards logic. A repair tool, which is run by the admin only, to help if things go really wrong is very useful though. This is the btrfs in-kernel stuff, which completes the picture: http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commitdiff;h=c975dd469d748ce619c510050d4fb407c2398591 For the background on fsck, you might want to read what the zfs guys have to say: http://www.osnews.com/story/22423
(In reply to comment #6) > The issue is that systemd-units includes a service file that forces an fsck. I > think every boot. That is great except my /home partition is formatted with > btrfs and is LUKS encrypted. When the system boots it forces a fsck.btrfs on > the LUKS partition. When the fsck fails then I get no partition. No partition > means it drops out to a root login and no matter what I can't get it to boot > further because it won't go with out the home directory. Shawn - Does setting passno to 0 for your /home partition fix your problem? If it does, I would be fine with closing this. (Although maybe fsck.btrfs could be a program that emits/logs some sort of explanatory message about why it shouldn't be used?)
Let's close this. (In reply to comment #6) > The forced relabel on systems that have selinux disabled is is in the same > boat. Indeed, I had exactly the same issue. Is there a bug report for that? It's one of the reasons I decided to stop using Fedora. Clearly, the move to systemd was rushed. But that's a separate bug that should be tracked separately, and it's a systemd issue. The system should boot even if there's no fsck.* A fsck.btrfs wrapper that explain why there isn't one would be nice, but nobody is stopping anybody from doing it *right now*.