On Fedora with systemd 256 dracut cannot write hooks to `/lib/dracut/hooks` during boot because `/lib` is `/usr/lib`, which is read-only with new ProtectSystem feature about systemd

[AdamWill]

This is a bit fuzzy because there is also a Failed to start systemd-modules-load.service - Load Kernel Modules. error which points to a different problem (see #32508 (comment) ). It's not clear whether either the read-only filesystem problem or the missing libkmod problem alone breaks the boot, since we encounter both at once. At a guess, though, I would expect both of them to break boot, so we need to fix both.

I'm going to try doing a scratch build of systemd patched so ProtectSystem default to off in initramfs environments, and see what happens with that.

edit - to be clear, @poettering pointed out that the cause of these errors is likely the new ProtectSystem feature, which makes /usr read-only in initramfs environments by default. On Fedora, /lib is a symlink to /usr/lib, so dracut's hook dir - which is /lib/dracut/hooks - is on a read-only file system.

[AdamWill]

Some testing suggests this bug doesn't prevent boot, at least of a simple default Fedora install in a VM; patching ProtectSystem to default to off for initramfses doesn't get the system booting again, but patching dracut to pull in the kmod library does get it booting again.

Surely the inability to write hooks must have some fairly significant consequences in some cases, though.

[poettering]

Fix dracut to not write around in /usr/ or turn off the feature in systemd if you need a quick workaround. This is not a bug in systemd but intended behaviour, really. What dracut is doing there is just wrong and should be fixed.

[poettering]

We probably should add a bigger note about this to NEWS however.

(And about the libkmod pitfall too I guess)

[keszybz]

This is fixed in dracut: dracut-ng/dracut-ng@a45048b