Bug 888747

Summary:	btrfs-progs does not provide fsck.btrfs
Product:	[Fedora] Fedora	Reporter:	Gene Czarcinski <gczarcinski>
Component:	btrfs-progs	Assignee:	Josef Bacik <josef>
Status:	CLOSED DUPLICATE	QA Contact:	Fedora Extras Quality Assurance <extras-qa>
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	18	CC:	johannbg, josef, lnykryn, metherid, mmahut, msekleta, notting, plautrba, systemd-maint, vpavlin
Target Milestone:	---
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2012-12-24 17:31:23 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description Gene Czarcinski 2012-12-19 12:02:26 UTC

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.

Comment 1 Bill Nottingham 2012-12-19 13:19:57 UTC

I think this is best fixed in btrfs-progs - attempting to special-case a command name per filesystem type doesn't scale.

Comment 2 Gene Czarcinski 2012-12-19 17:20:16 UTC

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"

Comment 3 Lennart Poettering 2012-12-22 09:29:09 UTC

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.

Comment 4 Gene Czarcinski 2012-12-22 13:33:37 UTC

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.

Comment 5 Kay Sievers 2012-12-22 13:58:30 UTC

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.

Comment 6 Gene Czarcinski 2012-12-22 15:42:07 UTC

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.

Comment 7 Gene Czarcinski 2012-12-24 17:31:23 UTC


*** This bug has been marked as a duplicate of bug 862871 ***