fix(network-manager): support nm-initrd-generator under NetworkManager

[LaszloGombos]

Upstream NetworkManager explicitly supports Debian. This PR proposes the same for the network-manager dracut module.

Upstream NetworkManager explicitly supports prefix for libexecdir here .

In network-manager/module-setup.sh nm-initrd-generator is already marked optional to accomodate different locations for nm-initrd-generator in different setups as the path is not stable between Linux installations and versions.

The file in Debian 12 is located in /usr/lib/NetworkManager/nm-initrd-generator .

The file location has been in stable Debian for about 4 years now (since Debian 10).

This issue impacts over 50 Linux distributions and blocks testing NetwrokManager for Debian on the upstream CI.

From FHS 3.0

Some previous versions of this document did not support /usr/libexec, despite it being standard practice in a number of environments. To accomodate this restriction, it became common practice to use /usr/lib instead. Either practice is now acceptable, but each application must choose one way or the other to organize itself.

CC @Mrfai @bdrung

[Mrfai]

This look very similar to the patch I use for the Debian version of dracut:
https://salsa.debian.org/debian/dracut/-/blob/master/debian/patches/nm-path

I will update my patch and decide if I still need it. I like the use of find_binary

IMO my patch has a better regex for inst_multiple

[Conan-Kudo]

@thaller, @lkundrak: are you folks aware that some put these binaries in /usr/libexec/NetworkManager? Have you considered making that the upstream default rather than dropping them directly in /usr/libexec?

[Conan-Kudo]

File locations for debian (and debian based distro's) - https://packages.debian.org/sid/amd64/network-manager/filelist

I fired off an email to ask about reconciling the paths with upstream NetworkManager since Debian adopted FHS 3.0 some time ago and allows /usr/libexec.

[LaszloGombos]

You're adding different checks for the same thing (NetworkManager) using different PRs... it's quite confusing.

@aafeijoo-suse asked to combine this PR with #2081 .

Closing this PR in favor of #2081 .

[LaszloGombos]

Since #2081 is stalled, reopening this PR.

[johannbg]

Different distro's place nm-initrd-generator in different locations. In network-manager/module-setup.sh nm-initrd-generator is already marked optional to accomodate different locations for nm-initrd-generator.

Hmm that's probably a historic/snug in bug as in we support standards and the effort of the people creating those standards and we do so by adhering to those standards not by support working around those standards ( but are open for a strong technical argument for deviating from the standards if such thing exist which is a bug in the standard then ) so workarounds for downstream that deviate from the standards is something we dont support and downstream has to carry the support for it, themselves and in the progress all the effort in trying to maintain that support that deviation in otherwords we should not have to call find to find a binary in which locations should already be standardized upon.
Us having to do so is either a bug upstream, in the standard or religions deviation downstream ( which we dont support ).

That said like @aafeijoo-suse I'm getting a bit confused about all this work it's like you are constantly trying to refactor our code to fit your test case for debian?

[LaszloGombos]

Closing with the conclusion that there is no interest to find a solution for current Debian and debian based distros upstream.

Debian and debian based distros should continue to carry this patch instead.

This of course means that dracut will not be able to test network-manager module for Debian container here upstream as it would all fail and have to instead invest time and effort to skip network-manager tests just for the Debian container.

I will try to find those standards for the file system location for nm-initrd-generator that are mentioned as a decisive factor for this PR yet not referenced. If somebody could help reference those standards for them, please drop a link on this PR.

[LaszloGombos]

Reopening based on recent policy changes and recent review feedbacks where it was suggested that the project should consider distro specific changes even if those changes are intentionally different than the corresponding upstream repo's for the purpose of networking related modules in dracut.

This PR is now only limited to find nm-initrd-generator on debian (and debian based distro's).

[LaszloGombos]

I wrote down a few of my thoughts on how to review distribution specific changes on the wiki. In the past there was very little consistency around the reviews of distribution specific changes.

https://github.com/dracutdevs/dracut/wiki/Dracut-development#reviews

[bdrung]

All four paths /usr/{lib,libexec}{,/NetworkManager} are FHS compliant and this change will support the path in Debian/Ubuntu. So +1 for this change from my side.

[stale]

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.

[bdrung]

This PR is still valid.

[pvalena]

LGTM.

[Conan-Kudo]

FYI, Debian 13 "Trixie" moves it to /usr/libexec