fix(dracut): move hooks directory from /usr/lib to /var/lib

[aafeijoo-suse]

Since https://github.com/systemd/systemd/commit/ffc1ec73, /usr is mounted as read-only in the initramfs by default.

Checklist

• [X] I have tested it locally
• [X] I have reviewed and updated any documentation if relevant
• [ ] I am providing new code and test(s) for it

Fixes #2588

[aafeijoo-suse]

@lnussel I'm not sure if /var is a good long-term option, see https://github.com/systemd/systemd/blob/5a4631bd8fde4122bf6f25872df07229a6b3ed74/TODO#L966-L970

A specific directory outside the FHS (such as /.dracut) would not suffer these types of changes.

[lnussel]

That's talking about /sysroot/var IMO

[aafeijoo-suse]

That's talking about /sysroot/var IMO

Right, I was wrong. Thanks.

[johannbg]

@aafeijoo-suse did you look into how this change would affect non systemd based distributions and which locations those users/distro's might want to use instead since the scope of this change is not limited to systemd based distributions.

[aafeijoo-suse]

@aafeijoo-suse did you look into how this change would affect non systemd based distributions and which locations those users/distro's might want to use instead since the scope of this change is not limited to systemd based distributions.

No, I didn't. That's why upstream PRs are public, so people from other environments can comment whether this change suits their systems. What I know is that initrds generated by dracut don't work with the upcoming systemd-v256, but we are not in a hurry, the new place to save the hooks is something to discuss here.

[LaszloGombos]

Regardless of the new writable location, can dracut maintain a link from /lib/dracut/hooks to the new directory location for improved compatibility ?

[stale[bot]]

This issue is being marked as stale because it has not had any recent activity. It will be closed if no further activity occurs. If this is still an issue in the latest release of Dracut and you would like to keep it open please comment on this issue within the next 7 days. Thank you for your contributions.

[aafeijoo-suse]

@aafeijoo-suse did you look into how this change would affect non systemd based distributions and which locations those users/distro's might want to use instead since the scope of this change is not limited to systemd based distributions.

No, I didn't. That's why upstream PRs are public, so people from other environments can comment whether this change suits their systems. What I know is that initrds generated by dracut don't work with the upcoming systemd-v256, but we are not in a hurry, the new place to save the hooks is something to discuss here.

Bumping this topic again, systemd will tag v256-rc1 soon and dracut is broken without this fix.

@thesamesam @floppym @AndrewAmmerlaan @ahesford ping, I don't know if /var is a good idea on non-systemd systems, or an out-of-tree directory like /.dracut is better.

[ahesford]

I'll tag @zdykstra for further comment as the maintainer of Void's dracut package and fellow ZFSBootMenu author.

On the surface, this is probably irrelevant to ZFSBootMenu, because we should be using dracut's hook installation functions to put our stuff where it needs to go. We don't work with systemd in the initramfs and just exec into our own event loop anyway.

In the meantime, I'll grumble quietly, but loudly enough to say that this is yet another example of a questionable decision by systemd that produces no discernible benefit (why is /usr even a separate filesystem in the initramfs?!?!?) and makes the quest to incorporate systemd into initramfs images seem even more quixotic.

[LaszloGombos]

Regardless of the new writable location, can dracut maintain a link from /lib/dracut/hooks to the new directory location for improved compatibility ?

I do not see how we can maintain Compatibility without having a link from /lib/dracut/hooks.

Random (perhaps not the best) example that I think would break by this PR (from openshift) - https://github.com/openshift/installer/blob/master/pkg/asset/agent/image/agentartifacts.go#L164

[zdykstra]

There's nothing I can see on the Void side that will break because of this change. I seriously question the need for making /usr read-only in an initramfs, but that ship seems to have already sailed.