Re: [ISSUE] [CLOSED] Ordering problem with XBPS updates can leave DKMS modules out of initramfs

Re: [ISSUE] [CLOSED] Ordering problem with XBPS updates can leave DKMS modules out of initramfs

[ahesford]

[-- Attachment #1: Type: text/plain, Size: 4094 bytes --]

Closed issue by ahesford on void-packages repository

https://github.com/void-linux/void-packages/issues/22817

Description:
### 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](https://gist.github.com/ahesford/8df10cf02c12a8c9306ea5a7a62c43ca) demonstrates the ordering issue, courtesy of user `w1kl4s` on the `#voidlinux` IRC channel.

cc: @ericonr @zdykstra @Duncaen