Description of problem: Dec 18 22:33:37 grepon systemd-fsck[566]: Unknown option: -a Dec 18 22:33:37 grepon systemd-fsck[566]: usage: btrfs [--help] [--version] <group> [<group>...] <command> [<args>] Dec 18 22:33:37 grepon systemd-fsck[566]: fsck failed with error code 129. Dec 18 22:33:37 grepon systemd-fsck[566]: Ignoring error. hidden in the middle of the logs. Sounds like a misprints in calling a btrfs checking? (if that exists) cheers. cat /etc/fstab # Entry for /dev/sda1 : UUID=0d37ca39-aeb5-4f7f-b71e-6a4a52cf8d21 / btrfs noatime 1 1 # Entry for /dev/sda6 : UUID=29e1bb79-a649-4883-b37a-71893167ae3a /boot ext4 acl,noatime 1 2 # Entry for /dev/sda7 : UUID=c6092962-8fd4-487d-b439-05ff6b0e17ed /home btrfs noatime 1 2 none /proc proc defaults 0 0 # Entry for /dev/sda5 : UUID=13944444-2234-4925-97f4-7d23a472ffe6 swap swap defaults 0 0 Reproducible: Steps to Reproduce:
CC: (none) => tmbAssignee: bugsquad => mageia
I'm pretty sure this is just a matter of removing the fsck.btrfs symlink in the btrfs package and systemd will be happy. Thomas you OK with this solution?
IIRC I added the symlink because of complaints of missing "fsck target" during boot... something atleast sysvinit / initscripts expected... I have not checked if it's still "expected" by systemd... I wonder if the "better option" would be to add a "dummy '-a'" to btrfs-progs that does nothing at this point... iirc it also used to have an "-a" option ... I will check it out soon-ish
(In reply to Thomas Backlund from comment #2) > > IIRC I added the symlink because of complaints of missing "fsck target" > during boot... something atleast sysvinit / initscripts expected... Yeah, I think this behaviour has been changed more recently to address this kind of problem. I believe upstream suggest not to run the fsck'er for btrfs, so systemd copes better with this situation these days. > I have not checked if it's still "expected" by systemd... This patch I added semi-recently should keep things less noisy: http://svnweb.mageia.org/packages/cauldron/systemd/current/SOURCES/0206-fsck-fstab-generator-be-lenient-about-missing-fsck.-.patch?revision=555953&view=markup > I wonder if the "better option" would be to add a "dummy '-a'" to > btrfs-progs that does nothing at this point... iirc it also used to have an > "-a" option ... > > I will check it out soon-ish I'll leave it to you to decide what's best but I think fedora no longer ship the symlink so that might be the easiest way to go.
Actually this is an upstream regression since they merged btrfsck into main btrfs program. I have a patch that I'll merge in our package now and will send it upstream too. This breakage also hit mga3 as btrfs-progs got updated as part of the big kernel-3.10.24 update (http://advisories.mageia.org/MGASA-2013-0371.html), so I will send an update build for that too
Assignee: mageia => tmbSource RPM: systemd-208-5.mga4.src.rpm => btrfs-progsWhiteboard: (none) => MGA3TOO
Cauldron package fixed as of: btrfs-progs-3.12-2.mga4 so switching this to a update request for mga3: SRPM: btrfs-progs-0.20-0.rc1.20130705.3.mga3.src.rpm i586: btrfs-progs-0.20-0.rc1.20130705.3.mga3.i586.rpm libbtrfs0-0.20-0.rc1.20130705.3.mga3.i586.rpm libbtrfs-devel-0.20-0.rc1.20130705.3.mga3.i586.rpm x86_64: btrfs-progs-0.20-0.rc1.20130705.3.mga3.x86_64.rpm lib64btrfs0-0.20-0.rc1.20130705.3.mga3.x86_64.rpm lib64btrfs-devel-0.20-0.rc1.20130705.3.mga3.x86_64.rpm Advisory: The btrfs-progs update as part of MGASA-2013-0371 broke the fsck.btrfs -a <device> as btrfsck function has been merged in main btrfs program. This update fixes the breakage. Testing: Setup: if you dont have a btrfs partititon, you can set up a loopback device to test on: dd if=/dev/zero of=/virtualfs bs=1024 count=102400 losetup /dev/loop0 /virtualfs mkfs.btrfs /dev/loop0 Before: # fsck.btrfs -a /dev/loop0 Unknown option: -a usage: btrfs [--help] [--version] <group> [<group>...] <command> [<args>] after: fsck.btrfs -a /dev/loop0 will provide same output as: btrfsck -a /dev/loop0 (output will be something like: Checking filesystem on /dev/loop0 UUID: afe796c5-9e06-43d2-a5f4-a2beca58e82a checking extents checking free space cache cache and super generation don't match, space cache will be invalidated checking fs roots checking csums checking root refs found 28672 bytes used err is 0 total csum bytes: 0 total tree bytes: 28672 total fs tree bytes: 8192 total extent tree bytes: 4096 btree space waste bytes: 23766 file data blocks allocated: 0 referenced 0 )
Hardware: x86_64 => AllVersion: Cauldron => 3Assignee: tmb => qa-bugsSummary: systemd-fsck fails at boot on btrfs => update request: btrfs-progs (was: systemd-fsck fails at boot on btrfs)Whiteboard: MGA3TOO => (none)
Thomas: I tried to test this using your procedure, but ran into a problem: # dd if=/dev/zero of=/virtualfs bs=1024 count=102400 102400+0 Datensätze ein (in) 102400+0 Datensätze aus (out) 104857600 Bytes (105 MB) kopiert (copied), 0,976869 s, 107 MB/s # losetup /dev/loop0 /virtualfslosetup: /dev/loop0: failed to setup loop device: Datei oder Verzeichnis nicht gefunden (file or directory not found) Indeed, there is no such file on my system (clean install of MGA3, 32 bits, all updates applied). How can I create it?
CC: (none) => wassiWhiteboard: (none) => has_procedure
Indeed one instruction seems missing in the procedure, before all other steps: modprobe -v loop However, here losetup /dev/loop0 /virtualfs does not fail :/ # fsck.btrfs -a /dev/loop0 Checking filesystem on /dev/loop0 UUID: 1b8334b5-b6e7-414f-a7d1-8d6b69324149 checking extents checking fs roots checking root refs found 28672 bytes used err is 0 total csum bytes: 0 total tree bytes: 28672 total fs tree bytes: 8192 btree space waste bytes: 23750 file data blocks allocated: 0 referenced 0 Btrfs v0.20-rc1 # rpm -qa | grep btrfs btrfs-progs-0.20-0.rc1.20130117.2.mga3 libbtrfs0-0.20-0.rc1.20130705.2.mga3 After installing the update [root@localhost ~]# fsck.btrfs -a /dev/loop0 Checking filesystem on /dev/loop0 UUID: 1b8334b5-b6e7-414f-a7d1-8d6b69324149 checking extents checking free space cache cache and super generation don't match, space cache will be invalidated checking fs roots checking csums checking root refs found 28672 bytes used err is 0 total csum bytes: 0 total tree bytes: 28672 total fs tree bytes: 8192 total extent tree bytes: 4096 btree space waste bytes: 23750 file data blocks allocated: 0 referenced 0 Btrfs v0.20-rc1 The second output contains more informations, but that's the only difference I can see. Is that OK?
CC: (none) => stormiWhiteboard: has_procedure => has_procedure feedback
Yeah, sorry I forgot to tell you to modprobe loop Before (it's almost always loaded on my system) as pointed out in comment 4, the regression was introduced with MGASA-2013-0371: so: btrfs-progs-0.20-0.rc1.20130117.2.mga3 from release should work btrfs-progs-0.20-0.rc1.20130705.2.mga3 from updates broke it btrfs-progs-0.20-0.rc1.20130705.3.mga3 from updates_testing fixes the breakage note also in comment 7 you only have updated libbrtfs0, not main program btrfs-progs as in "0.20-0.rc1.20130117.2.mga3" vs "0.20-0.rc1.20130705.2.mga3" <quote> # rpm -qa | grep btrfs btrfs-progs-0.20-0.rc1.20130117.2.mga3 libbtrfs0-0.20-0.rc1.20130705.2.mga3 </quote>
Whiteboard: has_procedure feedback => has_procedure
In reply to Thomas Backlund from comment #8) > btrfs-progs-0.20-0.rc1.20130117.2.mga3 from release should work > > btrfs-progs-0.20-0.rc1.20130705.2.mga3 from updates broke it > > btrfs-progs-0.20-0.rc1.20130705.3.mga3 from updates_testing fixes the > breakage # fsck.btrfs -a /dev/loop0 Unknown option: -a usage: btrfs [--help] [--version] <group> [<group>...] <command> [<args>] => Confirming the breakage with the version from Updates. This + comment #7 => Testing complete MGA3 32
Whiteboard: has_procedure => has_procedure MGA3-32-OK
Testing complete MGA3 64.
Whiteboard: has_procedure MGA3-32-OK => has_procedure MGA3-32-OK MGA3-64-OK
Keywords: (none) => validated_updateCC: (none) => sysadmin-bugs
Update validated, advisory uploaded. Please sysadmins push to 3/core/updates.
Whiteboard: has_procedure MGA3-32-OK MGA3-64-OK => has_procedure MGA3-32-OK MGA3-64-OK advisory
Update pushed: http://advisories.mageia.org/MGAA-2014-0012.html
Status: NEW => RESOLVEDResolution: (none) => FIXED