Final round of removals

[evelikov]

This is the final set of removal/cleanups inspired by #158. In particular:

• remove moar dead code that I've forgot with Remove deb rpm and driverdisk commands #161
• removes some code for Suse 10 and earlier
• removes rpm based detection of distributions -> now we use os-release, falling-back to lsb
  • bonus point: derivative distros correctly pick the override directory
• removes support for 2.x era kernels, and no longer applicable no-{clean,prepare}-kernel toggles
• removes support/deprecates REMAKE_INITRD and MODULES_CONF*

Note: while I did have a close look at non-Arch distros, I would appreciate a confirmation from others - Debian, Fedora/RedHat and Suse. Specifically, do you ship dkms modules which:

• lack both os-release and lsb-release
• use REMAKE_INITRD and MODULES_CONF*

@jwrdegoede @adrelanos @rhertzog - team, any input on the above questions, plus testing would be greatly appreciated.

Thanks in advance

[evelikov]

I found one DKMS module, which sets REMAKE_INITRD="no". "No" is the default, so sent a MR to remove it.

[scaronni]

Can you please rebase? I had some conflicting commits already staged. Thanks.

[evelikov]

@scaronni I think you've removed the wrong hunks with 7472cbd. I suspect that you missed the ! in the if [[ (! ( $(VER $1) < $(VER 2.6... conditionals.

See for example how I've done it - with a6b6302

Is that correct? Double-checking so I know exactly how to resolve the lot.

Edit: in particular, prior to your commit above, my builds will consistently hit the "Kernel preparation/cleanup unnecessary for this kernel. Skipping...", which are now outright removed 🤔

[scaronni]

Right, I'm getting confused with your merge requests and the limited time I have, you're too quick 😄. I'll revert it so your applies cleanly. Sorry for that.

[evelikov]

I'm trying to be quick when I have maintainer's attention - sorry if it was too much.

NOTE: Please wait at least 1-2* weeks before merging this. I would love to double-check/hear from RedHat/Suse people if the deprecation/removal might cause problems for them.

[evelikov]

Found another REMAKE_INITRD user - sent MR to remove the toggle

[scaronni]

I will make some test for the RedHat / Fedora part. Thanks.

[scaronni]

All seems to be good, but I will merge in a few days due to holidays. Cheers!

[emilyst]

If you write a module that replaces an existing Linux kernel module, what's the recommended way to do that now? Add a custom preinstall script that removes the old module and blacklists it?

[evelikov]

@emilyst simple - make sure the new module (location) is searched first - see "search" directive in man depmod.d for details.
On my Arch box - cat /usr/lib/depmod.d/search.conf shows search updates extramodules built-in so modules in "updates" are picked before the normal kernel "built-in" ones.

The destination can be overridden in dkms override_dest_module_location() function. If needed you might need to extend it with a distro specific switch case.

[emilyst]

@emilyst simple - make sure the new module (location) is searched first - see "search" directive in man depmod.d for details. On my Arch box - cat /usr/lib/depmod.d/search.conf shows search updates extramodules built-in so modules in "updates" are picked before the normal kernel "built-in" ones.

The destination can be overridden in dkms override_dest_module_location() function. If needed you might need to extend it with a distro specific switch case.

Just to clarify, I was hoping for some mechanism within dkms.conf equivalent to the now-obsolete MODULES_CONF_OBSOLETES. It sounds like you're saying that's not possible anymore.

[evelikov]

Set DEST_MODULE_LOCATION to a higher priority location (see the depmod.d comment). Then the modprobe command (explicit or implicit) should load the new/dkms one, instead of the old/built-in.

[ebbcm]

Set DEST_MODULE_LOCATION to a higher priority location (see the depmod.d comment). Then the modprobe command (explicit or implicit) should load the new/dkms one, instead of the old/built-in.

This will help load the DKMS module, if its location is higher priority in the search path, but will not update the INITRD, so for any modules in the distro ramdisk, the DKMS installed module will not be automatically loaded at boot.

Without REMAKE_INITRD, any DKMS module with replaces distro built-in modules now has to make two distro-specific actions:

1. Use a possibly distro-specific installation location, or alter the system depmod.d conf file
2. Rebuild the initrd with distro-specific tools and options

I suggest re-adding REMAKE_INITRD and improving it if necessary.

Some drivers certainly escaped your survey of users of REMAKE_INITRD, including ours (https://www.broadcom.com/products/ethernet-connectivity/network-adapters/p2100g). We distribute DKMS drivers as updates to the in-box drivers, and since our drivers (bnxt_en) are usually included in the distro's ramdisk, we need to install to a higher priority depmod path AND rebuild the initrd.

I don't think the proper solution is each DKMS module implementing ramdisk management individually.

[ebbcm]

More information: We scanned our supported OS list for the in-box depmod configured search paths:

CentOS 7.9 search updates extra weak-updates kgraft built-in
RHEL 8.6 search updates extra built-in weak-updates
RHEL 9.0 search updates extra built-in weak-updates
SLES 12u4 search updates extra weak-updates kgraft built-in
SLES 15u3 search updates extra weak-updates kgraft built-in
Ubuntu 20.04 search updates ubuntu built-in

Clearly "updates" is the right target directory for drivers which wish to supersede the built-in version, so that's one less OS-specific decision. We still need to be able to update ramdisk images though.