You are not logged in.
Hi all. I upgraded the following packages today: libsystemd (238.51-1 -> 238.76-1); libutil-linux (2.32-2 -> 2.32-3); util-linux (2.32-2 -> 2.32-3); systemd (238.51-1 -> 238.76-1).
When I rebooted, I noticed that the fsck hook at bootup was failing with error code 8. Examining journalctl, I found the following lines:
Apr 11 17:07:27 archlinux systemd[1]: Starting File System Check on /dev/disk/by-partuuid/b436a2f4-d159-4a14-bc5f-4323112d1859...
Apr 11 17:07:27 archlinux systemd-fsck[174]: fsck: /usr/local/bin/fsck.btrfs: execute failed: No such file or directory
Apr 11 17:07:27 archlinux systemd-fsck[174]: fsck failed with exit status 8.
Apr 11 17:07:27 archlinux systemd-fsck[174]: Ignoring error.
Apr 11 17:07:27 archlinux systemd[1]: Started File System Check on /dev/disk/by-partuuid/b436a2f4-d159-4a14-bc5f-4323112d1859.
Apr 11 17:07:27 archlinux systemd[1]: Mounting /sysroot...
Apr 11 17:07:27 archlinux kernel: BTRFS info (device sda6): disk space caching is enabled
Apr 11 17:07:27 archlinux kernel: BTRFS info (device sda6): has skinny extents
Apr 11 17:07:27 archlinux kernel: BTRFS info (device sda6): enabling ssd optimizations
Apr 11 17:07:27 archlinux systemd[1]: Mounted /sysroot.
Apr 11 17:07:27 archlinux systemd[1]: Reached target Initrd Root File System.However, /usr/local/bin is completely empty on my system. I verified that fsck.btrfs is installed in /usr/bin/fsck.btrfs.
The following is my mkinitcpio.conf:
MODULES=(i915)
HOOKS=(systemd sd-plymouth autodetect modconf block filesystems fsck shutdown)If anyone has any advice on how to point the systemd-fsck service to the right place, I would appreciate it. Let me know if there is any other relevant information I could provide. Thanks!
Last edited by aenda (2018-04-13 08:10:36)
Offline
/usr/local may be empty on your root filesystem, but it isn't in your initramfs where the root filesystem is checked (or it shouldn't be, mine isn't).
Last edited by Trilby (2018-04-11 23:22:31)
"UNIX is simple and coherent" - Dennis Ritchie; "GNU's Not Unix" - Richard Stallman
Offline
Why are you using the fsck hook with btrfs anyway? It's totally useless.
Offline
systemd-fsck@ is calling /usr/local/bin/fsck.btrfs which tries to execute `#!/bin/sh -f` which would be what actually fails?
has something in systemd-fsck changed that would cause its to behave differently with the latest release?
Agreed the fsck hook provides no functionality with btrfs and when systemd-fsck can not find /usr/local/bin/fsck.btrfs it should skip the fsck until it has pivoted to /sysroot and then systemd-fsck-root will try if the ro option was passed.
Offline
@Scimmia; I actually believe it was just enabled my default in my configuration, or I added it so long ago that I've forgotten. I do mount some other data partitions that it would be useful to check, but I suppose before the real root is mounted this fsck hook will only check my btrfs root partition (correct me if I'm wrong here). And I do have pass numbers greater than one for those partitions in my /etc/fstab, so systemd should be handling checking those anyways?
I wouldn't have any problem with disabling the hook (or honestly just ignoring the error, since it has no impact on my system), but I would like to try and fix this error at the source first just out of curiosity.
@Trilby: Thank you for catching that! Unzipping my initramfs.img, I found that fsck.btrfs does exist in the right location, so I am unsure what is going on and how to further investigate this.
Offline
If you downgrade the systemd packages does the issue continue? If not bisect between the two versions.
Offline
You've got it right, the hook runs fsck on partitions mounted in the initramfs only, usually just the root partition. All other partitions would be fscked by the init system. Since your root is btrfs, it does nothing.
Offline
The most I've been able to discover so far is that the error seems to occur when using the systemd hook instead of base and udev hooks along with fsck. I'm not sure if this is btrfs specific or not - in my case at least I don't mind disabling fsck on this partition, but other people might. I don't really plan on repartitioning my hard drive to further test though. Ascertaining the cause is tough because it happened after I upgraded those packages (namely systemd), changed to the systemd hook, and uninstalled the systemd-sysvcompat package, but I can't tell what combination exactly leads to reproduction. Going to mark this as solved since I'm not experiencing any issues - thanks for everyone's help.
Offline