Ordering problem with XBPS updates can leave DKMS modules out of initramfs

[ahesford]

Description

[This is more of a tracking issue than anything else; my hope is to start a discussion about the right path forward to prevent arbitrary ordering issues in package configuration.]

All systems are affected. Whenever xbps-install -u updates both a Linux kernel package and a DKMS package, the kernel module provided by the DKMS package will not be available for inclusion in the initramfs produced by the kernel update if the DKMS package name follows the linux package name lexicographically. The issue is as follows:

1. XBPS unpacks the files for all packages it updates in alphabetical order on the package name.

2. During the unpacking, XBPS fires the removal trigger for any DKMS package it updates, removing the modules provided by that package.

3. XBPS reconfigures every package it updated, again in alphabetical order.

• For DKMS packages, the reconfiguration triggers dkms add to make DKMS aware of the module(s) provided by the package.
• When linuxX.Y is updated, it will trigger a DKMS build hook to recompile any known DKMS packages for the new kernel, followed by a dracut (or other initramfs generator) hook to produce an initramfs for the new kernel.
  • Any DKMS packages that were not updated in this round are already known by DKMS and will be rebuilt for the updated kernel.
  • Any DKMS packages that were updated, but were reconfigured before linuxX.Y because their names come lexicographically before linuxX.Y, will be known by DKMS and will be rebuilt.
  • Any DKMS packages that were updated but follow linuxX.Y lexicographically will not have been reconfigured and are therefore unknown to DKMS and not rebuilt for the updated kernel.

Expected behavior

The linuxX.Y reconfiguration should be deferred until all DKMS modules have been properly added, so the dkms kernel hook can rebuild them properly before creating an initramfs.

To reproduce

A good example is to enable the zfs module for dracut, then simultaneously update linuxX.Y and zfs. The zfs.ko.gz module should be included in the initramfs generated during the kernel reconfiguration, but it will not be included. (Note that some of the ZFS binaries will be included in the initramfs, because the unpacking stage has already completed for all updated packages, and all but the DKMS kernel module is already in place.) A subsequent xbps-reconfigure -f linuxX.Y will be required after the update to properly include the kernel module in the initramfs.

What is to be done?

I see three obvious paths, with varying degrees of complexity:

1. Elevate kernel packages to "special" status, making sure that XBPS configures them after all other packages in an update. (I'm guessing this requires special metadata that probably doesn't exist at the moment.)

2. Add a "pre-configure" stage to XBPS; this will allow DKMS packages to do dkms add in the "pre-configure" stage and do the build/install in the "configure" stage. XBPS updates can then run the "pre-configure" stage for all packages after the "unpack" and before the "configure" stages, making sure that DKMS is aware of all modules before any package is configured. (The key distinction between "pre-configure" and "configure" should be that "configure" may involve interactions between packages, but "pre-configure" should never involve interactions between packages. dkms add might be the only compelling use-case for "pre-configure".)

3. Add support for arbitrary reconfiguration dependency tracking, so packages can declare that they must be reconfigured before or after any other packages. This is probably a mess, and I really don't have a specific theory of operation for this.

Edit: Example output demonstrates the ordering issue, courtesy of user w1kl4s on the #voidlinux IRC channel.

cc: @ericonr @zdykstra @Duncaen

[ahesford]

zfs is probably the most painful manifestation of this issue and #23013 works around it, so this is now a bit less critical.

[ahesford]

There is no obviously superior solution to this problem and I've worked around it for ZFS by adding a post-install hook.