Comment 24 for bug 2028366

On Thu, 31 Aug 2023 at 14:22, Andreas Hasenack
<email address hidden> wrote:
>
> I suppose it's possible that the particular dkms module that failed to
> build is essential for booting the system, so the new approach that
> hides this build failure could render the system unbootable without the
> user realizing it. A bit less catastrophic, but still very serious,
> would be for the machine to lose network access (wifi driver), which
> could pose a chicken an egg problem (need network to fix the problem).

I'm not sure that is possible. Because it means it was not possible to
boot the installer, or install the system. Because for example when
one assumes secureboot by default it is not possible to enroll a Mok
key without a reboot, and meaning having a successful install that at
least can boot (but might not have a weird wifi).

We haven't yet had any cases of drivers being dropped by a kernel,
that transition to be a 3rd party dkms. Or ability to complete install
with dkms module that is essential for boot (i.e. disk driver for disk
install, or network driver for network boot install).

To the point of, I am happy to assert that if dkms is required for
boot, the image for such a system was pre-built externally. And in
such cases, it should be possible to pre-built again.

>
> So what we have here is a balance between a system with an interrupted
> release-upgrade, requiring a lot of apt-foo to fix, or a system where
> dkms rebuilds might have failed, but otherwise upgraded successfully.
> Both cases could result in an unbootable system, but I tend to agree

Note quite. The completed upgrade system with missing dkms is bootable
with new kernel. Or also bootable with the old kernel (and old dkms
module) those are not purged and remain on disk.

So one can do successful boot using old kernel (and thus still have
access to weird wlan) to figure out how to update their 3rd party dkms
to be compatible with a new kernel.

So it is a massive improvement on the situation.

> that the first one (interrupted release-upgrade) is more likely to be
> much harder to recover (been there).
>

This is very true and the core point of this SRU.

> I would like some sort of commitment on the follow-up work for the
> release upgrader to check the status of dkms builds after the upgrade.
> Can we get an LP bug for it please?
>

That's this bug report that was opened in May and still being
discussed https://bugs.launchpad.net/ubuntu/+source/ubuntu-release-upgrader/+bug/2020406

--
okurrr,

Dimitri