Re: btrfs check, btrfsck, fsck.btrfs
On Tue, 20 May 2014 18:26:59 -0600 Chris Murphy li...@colorremedies.com wrote: That ought to be true, but at least on a systemd 212-4 system, it assumes the system root needs to be fsck'd before mounting it. Since the fs isn't mounted, fstab isn't available. And the fstab.empty file I found in the initramfs is in fact empty. So even with fs_passno set to 0, systemd is trying to run fsck.btrfs, which it fails to find, warns about, then moves on. I filed that bug here: https://bugzilla.redhat.com/show_bug.cgi?id=1098799 [@ Chris M, I sent this to you only first. So this one's to the list only, but it'll have a different message-id, so you'll probably get it as two different messages, one to the list, one direct to you.] Hmm... it isn't doing so here. dracut-037, systemd-212-r4 (the -r4 indicating four gentoo package level revision bumps since the initial in-tree release of the upstream 037 version). But I have an install-customized dracut config (tho I no longer use host-only as explained in my last post, to the degraded boot and systemd thread), all kernel modules built-in, etc. If you're running a generic everything-including-the-kitchen-sink dracut, that might explain it, since I guess on most filesystems (not reiserfs/xfs/btrfs, however) it would need to be run. -- Duncan - No HTML messages please, as they are filtered as spam. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: btrfs check, btrfsck, fsck.btrfs
On May 21, 2014, at 4:47 AM, Duncan 1i5t5.dun...@cox.net wrote: On Tue, 20 May 2014 18:26:59 -0600 Chris Murphy li...@colorremedies.com wrote: That ought to be true, but at least on a systemd 212-4 system, it assumes the system root needs to be fsck'd before mounting it. Since the fs isn't mounted, fstab isn't available. And the fstab.empty file I found in the initramfs is in fact empty. So even with fs_passno set to 0, systemd is trying to run fsck.btrfs, which it fails to find, warns about, then moves on. I filed that bug here: https://bugzilla.redhat.com/show_bug.cgi?id=1098799 Hmm... it isn't doing so here. dracut-037, systemd-212-r4 (the -r4 indicating four gentoo package level revision bumps since the initial in-tree release of the upstream 037 version). systemd 212 and dracut 037 here also. But I have an install-customized dracut config (tho I no longer use host-only as explained in my last post, to the degraded boot and systemd thread), all kernel modules built-in, etc. If you're running a generic everything-including-the-kitchen-sink dracut, that might explain it, since I guess on most filesystems (not reiserfs/xfs/btrfs, however) it would need to be run. I've tried both types of initramfs's. The fsck on root is always called, the difference being fsck.btrfs is not in the host-only initramfs, but is in the no-host-only one. [1.779007] localhost systemd[1]: Failed to load configuration for systemd-fsck-root.service: No such file or directory […snip…] [1.780811] localhost systemd[1]: Installed new job initrd-root-fs.target/start as 30 [1.780818] localhost systemd[1]: Installed new job sysroot.mount/start as 31 [1.780826] localhost systemd[1]: Installed new job dev-disk-by\x2duuid-d372e5d1\x2d386f\x2d460c\x2db036\x2d611469e0155e.device/start as 32 [1.780834] localhost systemd[1]: Installed new job systemd-fsck@dev-disk-by\x2duuid-d372e5d1\x2d386f\x2d460c\x2db036\x2d611469e0155e.service/start as 33 The first and last entries are mysteries. There is a /usr/lib/systemd/system/systemd-fsck-root.service so I don't know why it fails to load. The last entry looks like it occurs not by systemd-fsck-root.service but rather /usr/lib/systemd/system/systemd-fsck@.service, which is in the same directory. It reads: [Unit] Description=File System Check on %f Documentation=man:systemd-fsck@.service(8) DefaultDependencies=no BindsTo=%i.device After=systemd-readahead-collect.service systemd-readahead-replay.service %i.device systemd-fsck-root.service Before=shutdown.target [Service] Type=oneshot RemainAfterExit=yes ExecStart=/usr/lib/systemd/systemd-fsck %f StandardOutput=journal+console TimeoutSec=0 So I'm not sure what's going on. Chris Murphy -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: btrfs check, btrfsck, fsck.btrfs
Chris Murphy posted on Tue, 20 May 2014 10:56:26 -0600 as excerpted: Should the initrd/initramfs no longer include btrfsck, and instead include btrfs and fsck.btrfs? btrfs (the program) should be included in any case as btrfs device scan should be run (normally triggered via udev rules when a btrfs filesystem block device is detected) to enable mounting multi-device btrfs' (the filesystem) from within the initr*. That's already the case with dracut's btrfs module, anyway, and has been for some time. In btrfs-progs 3.14 there is now a 1K /sbin/fsck.btrfs placeholder file. To be more exact, it's a nearly noop shell-script (basically copied from fsck.xfs) that simply verifies that the passed in filename exists. If it does, in auto-mode (if called automatically via a passno 0 in fstab), it exits without error. In non-auto-mode, it simply points the user at btrfs check. If the device doesn't exist, it exits with 8 as the error status. No check other than that the last parameter passed in is actually an existing file, not even whether it's actually a device or not, is done. As btrfs (the filesystem) doesn't need a pre-mount check, the recommendation is to set passno to 0 for btrfs in any case, in which case fsck.btrfs shouldn't be needed at all. As such, fsck.btrfs really shouldn't be needed in an initr*, since whatever's creating the initr* shouldn't be running a pre-mount auto-fsck against btrfs in any case, as to do so is certainly a bug. (Tho with compression the incremental size of a single shell-script just over 1 KiB in size before compression should be trivial.) btrfs and btrfsck files are the same binary, the difference is btrfsck only can do check/repair. Including btrfs instead allows more flexibility to use additional subcommands, and it's also consistent with fsck.btrfs which references btrfs not btrfsck. Ideally, btrfsck would be a symlink to btrfs in btrfs-progs, and potentially not included in an initr* at all, or if included, likewise included as a symlink. -- Duncan - List replies preferred. No HTML msgs. Every nonfree program has a lord, a master -- and if you use the program, he is your master. Richard Stallman -- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: btrfs check, btrfsck, fsck.btrfs
On May 20, 2014, at 5:02 PM, Duncan 1i5t5.dun...@cox.net wrote: Chris Murphy posted on Tue, 20 May 2014 10:56:26 -0600 as excerpted: Should the initrd/initramfs no longer include btrfsck, and instead include btrfs and fsck.btrfs? btrfs (the program) should be included in any case as btrfs device scan should be run (normally triggered via udev rules when a btrfs filesystem block device is detected) to enable mounting multi-device btrfs' (the filesystem) from within the initr*. That's already the case with dracut's btrfs module, anyway, and has been for some time. Yes you're right. And lsinitrd confirms that both btrfs and btrfsck are in the initramfs. In btrfs-progs 3.14 there is now a 1K /sbin/fsck.btrfs placeholder file. To be more exact, it's a nearly noop shell-script (basically copied from fsck.xfs) that simply verifies that the passed in filename exists. If it does, in auto-mode (if called automatically via a passno 0 in fstab), it exits without error. In non-auto-mode, it simply points the user at btrfs check. If the device doesn't exist, it exits with 8 as the error status. No check other than that the last parameter passed in is actually an existing file, not even whether it's actually a device or not, is done. As btrfs (the filesystem) doesn't need a pre-mount check, the recommendation is to set passno to 0 for btrfs in any case, in which case fsck.btrfs shouldn't be needed at all. As such, fsck.btrfs really shouldn't be needed in an initr*, since whatever's creating the initr* shouldn't be running a pre-mount auto-fsck against btrfs in any case, as to do so is certainly a bug. That ought to be true, but at least on a systemd 212-4 system, it assumes the system root needs to be fsck'd before mounting it. Since the fs isn't mounted, fstab isn't available. And the fstab.empty file I found in the initramfs is in fact empty. So even with fs_passno set to 0, systemd is trying to run fsck.btrfs, which it fails to find, warns about, then moves on. I filed that bug here: https://bugzilla.redhat.com/show_bug.cgi?id=1098799 (Tho with compression the incremental size of a single shell-script just over 1 KiB in size before compression should be trivial.) btrfs and btrfsck files are the same binary, the difference is btrfsck only can do check/repair. Including btrfs instead allows more flexibility to use additional subcommands, and it's also consistent with fsck.btrfs which references btrfs not btrfsck. Ideally, btrfsck would be a symlink to btrfs in btrfs-progs, and potentially not included in an initr* at all, or if included, likewise included as a symlink. Yeah it seems to me we should only need btrfs in the initrd/ramfs. It doesn't show up as a link but the Rawhide initramfs, using lsinitrd, lists btrfsck as a 0 byte file. Chris Murphy-- To unsubscribe from this list: send the line unsubscribe linux-btrfs in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
