RFC: SRU Exception for transitional hardware enablements (tHWE)

[Frank Heimes]

Hello Robie, sorry for the delay.
(And thanks Antoine for your help and opinion.)

The problem we face today is not only that some SRUs are blocked. It's also
that this problem exists now for years, and there are Ubuntu users that
have non-compliant installations.
We want to better support such setups, for example by adding more warnings
and safeguards in do-release-upgrade. We do not want to make such kind of
installations more frequent, nor want to preserve such cases. But we need a
better way to support our partner cases.

Some selected cases:

- Jetsons just got SRU 2127473 [1] in proposed. There are thousands of
jetsons users out there, stuck on Jammy until very recently. Yes, their
installation is not as proper as we would hope (yet), but we can still make
the experience of our users better, until we catch up and hopefully make
these device compatible with Vanilla Ubuntu. SRUs 2127100 [2] and 2095032
[3] were accepted too, but we would rather make the context of the
exception more formal.

- Mediatek new packages were rejected : 2107525 [4], 2107524 [5]. These
were put in the OEM archive [6] instead, because the team did not have much
of the choice. But it makes the support and upgrade journey even worse.
SRUs are generally accepted, like this 2126737 [7], when the testing can
happen on a forcely upgraded system.

- Qualcomm had most of its SRUs accepted: 2105425 [8], 2133787 [9], 2134514
[10], 2133923 [11]. Again we would rather make the context of the exception
more formal and well-defined.

- Nvidia Spark required SRUs 2111271 [12] and 2111723 [13]. Again, they
were thankfully accepted, without the process being official and
well-defined, we were lucky. Livecd-rootfs [14] was however rejected, but
the nature of livecd-rootfs allows us to run it from forks. So we are lucky
here.

All machines that have a partner-specific kernel in LTS may end up in these
situations. For example, Nvidia is shipping Ubuntu with their machines, but
with a -nvidia kernel. The -nvidia kernel for 26.04 will not be ready when
resolute is out, but will be later. And it was never in an interim release
until now. To improve the situation, we want to implement this mechanism in
do-release-upgrade to prevent the to upgrade until it's ready. In parallel,
we're are working on improving the situation and hopefully having these
kernels everywhere.
And we need a proper way to service existing installation where the kernel
is LTS only, but not yet in latest LTS.

[1] https://bugs.launchpad.net/bugs/2127473
[2] https://bugs.launchpad.net/bugs/2127100
[3] https://bugs.launchpad.net/bugs/2095032
[4] https://bugs.launchpad.net/bugs/2107525
[5] https://bugs.launchpad.net/bugs/2107524
[6]
http://oem.archive.canonical.com/updates/dists/jammy-baoshan/public/binary-arm64/Packages
[7] https://bugs.launchpad.net/bugs/2126737
[8] https://bugs.launchpad.net/bugs/2105425
[9] https://bugs.launchpad.net/bugs/2133787
[10] https://bugs.launchpad.net/bugs/2134514
[11] https://bugs.launchpad.net/bugs/2133923
[12] https://bugs.launchpad.net/bugs/2111271
[13] https://bugs.launchpad.net/bugs/2111723
[14] https://bugs.launchpad.net/bugs/2109822


On Tue, Jan 13, 2026 at 8:38 PM Robie Basak <racb at ubuntu.com> wrote:

> Hi Frank,
>
> In our meeting of 2025-11-18[1], you mentioned that some packages were
> already in the archive as a justification for your request. I asked what
> specific use cases are broken, eg. images that you've shipped that don't
> work, and require an SRU, that are blocked. You said you'd follow up,
> but I haven't heard from you since.
>
> What's the status of this request now, please? Do you consider it
> dropped?
>
> Thanks,
>
> Robie
>
> [1]: https://irclogs.ubuntu.com/2025/11/18/%23ubuntu-meeting.html#t20:22
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.ubuntu.com/archives/technical-board/attachments/20260126/4ab9a2af/attachment.html>