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

[dracutng]

Changes

Since systemd/systemd@ffc1ec73, /usr is mounted as read-only in the initramfs by default.

Fixes dracutdevs/dracut#2588

(cherry picked from dracutdevs/dracut#2591)

CC @aafeijoo-suse

[freswa]

It's just a feeling, but /var/lib is a directory which is used to store data and managed by the software itself.
Hook dirs imho belong to either /usr when another package provides them, or /etc if the administrator/user would like to create them.

Just my 2 cents :)

[bdrung]

I agree with @freswa, the hooks should live in /usr and or /etc. Generating dynamic configuration should be better placed in /run instead.

[LaszloGombos]

There are two tree's here..

hooks directory from /usr/lib to /var/lib

The "regular" rootfs and that we're booting into and the generated initramfs tree. Here the directory /usr/lib and /var/lib refers to the tree inside the generated initramfs only. This PR has no effect on how dracut gets installed on the "regular" rootfs. This is not to say that some of the feedback regrinding how directories are usually used is not valid, but I think they are less important inside the initramfs.

We need to resolve this one way or another by our next release to maintain compatibility with systemd.

[aafeijoo-suse]

You can read the old discussion which led us to choose /var as the "least bad option" here: https://bugzilla.opensuse.org/show_bug.cgi?id=1218068

[Conan-Kudo]

I am not sure this is a good change on its own. This will break backwards compatibility for anyone already using the existing hooks directory for packaged hooks, and the new path doesn't work on systems where /var is not available during transactions (e.g. RPM-OSTree).

[aafeijoo-suse]

I am not sure this is a good change on its own. This will break backwards compatibility for anyone already using the existing hooks directory for packaged hooks,

There is a compat symlink to the old location.

https://github.com/dracut-ng/dracut-ng/pull/114/files#diff-1a92fcdd8eaf1d31c9913c0e2f96022f82331a5ba7a2d89802927bae30484d1eR51

/usr is read-only in systemd git main, so a change is required.

and the new path doesn't work on systems where /var is not available during transactions (e.g. RPM-OSTree).

I you follow the discussion in https://bugzilla.opensuse.org/show_bug.cgi?id=1218068 and dracutdevs/dracut#2591, I initially suggested a directory like /.dracut, but we were trying to guess if /var could be used without breaking anything.

[LaszloGombos]

There is a compat symlink to the old location.

One option - that I am more and more considering - is to only add the compat symlink and do not change the documentation. This would make the compat symlink an implementation detail and we would still recommend out of tree dracut modules to use e.g. /usr/lib instead of /var/lib .

Any thoughts on this ?

[pvalena]

There is a compat symlink to the old location.

One option - that I am more and more considering - is to only add the compat symlink and do not change the documentation. This would make the compat symlink an implementation detail and we would still recommend out of tree dracut modules to use e.g. /usr/lib instead of /var/lib .

Any thoughts on this ?

Just to be clear, that would mean 2 locations:

• (1) for user-created (packaged) hooks; and
• (2) for runtime-created (generated) hooks

Those need to be then handled both - e.g. by copying all of the (1) to (2) prior to generating new ones. I'm fine with /var but IMHO if done correctly, we could use:

• /usr/lib for (1)
• /run/dracut for (2)

Is there some reason for not doing this? Is there some reason for not using /run that I've missed?

[aafeijoo-suse]

Just to be clear, that would mean 2 locations:

* (1) for user-created (packaged) hooks; and

* (2) for runtime-created (generated) hooks

Those need to be then handled both - e.g. by copying all of the (1) to (2) prior to generating new ones.

I didn't think about this copy before, but it doesn't seem like a bad idea...

[LaszloGombos]

Those need to be then handled both - e.g. by copying all of the (1) to (2) prior to generating new ones.

Just for clarity, as far as I can tell, this block

    # symlink to old hooks location for compatibility
    ln_r /var/lib/dracut/hooks /lib/dracut/hooks

takes care about both cases already (assuming /var is writable).

[pvalena]

    # symlink to old hooks location for compatibility
    ln_r /var/lib/dracut/hooks /lib/dracut/hooks

takes care about both cases already (assuming /var is writable).

Hmm I didn't realize this before, but now seeing it, I think it doesn't work in case there're some pre-existing files in /lib/dracut/hooks.

The original intent is to create a symlink /lib/dracut/hooks (to pointing to directory /var/lib/dracut/hooks), which is fine, but if there already is a directory /lib/dracut/hooks (empyty or not), then it will create a symlink in that directory instead (creating symlink /lib/dracut/hooks/hooks; test log).

[LaszloGombos]

The original intent is to create a symlink /lib/dracut/hooks (to pointing to directory /var/lib/dracut/hooks)

When dracut creates an initramfs, as far as I know it always starts empty and we need to populate it - https://github.com/dracut-ng/dracut-ng/blob/main/modules.d/99base/module-setup.sh#L46 .

Instead of creating a directory under /lib, we would create at under /var. This could be phase 1.

The benefit pf phase 1 is that it is a much simpler change and we can confirm compatibility with systemd new version and that buys us a lot of time to slowly more more things to /run after careful consideration.

[aafeijoo-suse]

    # symlink to old hooks location for compatibility
    ln_r /var/lib/dracut/hooks /lib/dracut/hooks

takes care about both cases already (assuming /var is writable).

Hmm I didn't realize this before, but now seeing it, I think it doesn't work in case there're some pre-existing files in /lib/dracut/hooks.

The original intent is to create a symlink /lib/dracut/hooks (to pointing to directory /var/lib/dracut/hooks), which is fine, but if there already is a directory /lib/dracut/hooks (empyty or not), then it will create a symlink in that directory instead (creating symlink /lib/dracut/hooks/hooks; test log).

FTR, we have been using the current proposal since systemd introduced the change, otherwise Tumbleweed with systemd from git main would not work. So, it works. That said, I think your idea of copying the hooks to /run at boot may also be valid, I could give it a try (maybe on a separate PR) if that's the desired path to follow.

[lnykryn]

This is probably a stupid idea, but shouldn't we just set ProtectSystem=no for the hooks unit files? I understand the reasoning behind the systemd change. If you build initrd with let's say mkosi-initrd you mostly don't need to touch /usr. But Dracut is unfortunately built in a way where it does a lot of "self-modifications" (I mean scripts that generate scripts....)

For the record, I really like Pavel's idea, /usr for hooks that exist when we build initrd, and the generated ones should go to /run. But I would not be surprised if it would brake stuff.

[LaszloGombos]

Can somebody help me/us understand if any of the dracut use-cases are broken by a subset of this PR that I uploaded to #186 ?

For the record, I really like Pavel's idea, /usr for hooks that exist when we build initrd, and the generated ones should go to /run. But I would not be surprised if it would brake stuff.

I like this ideas as well. I think "/usr for hooks that exist when we build initrd" is actually enough to resolve this issue and as a phase 2 we can move stuff to /run.

[Conan-Kudo]

I'm closing this as #186 was merged.

[aafeijoo-suse]

I'm closing this as #186 was merged.

That's a "good" way to end an ongoing discussion.

[AdamWill]

I think it'd be reasonable to re-open this, as #186 / #194 is really more of a band-aid than a long term "fix". It does seem like it would be much cleaner in the long term to really change dracut's fundamental idea of where the hooks go, not just kinda have it trick itself with a symlink. But it's also clearly more disruptive.