Intel wireless firmware updates for Ubuntu LTS

Fri Aug 8 10:47:14 UTC 2025

On Thu, 7 Aug 2025 17:02:54 +0000
"Grumbach, Emmanuel" <emmanuel.grumbach at intel.com> wrote:

> On Thu, 2025-08-07 at 18:25 +0200, Juerg Haefliger wrote:
> > On Wed, 6 Aug 2025 20:09:55 +0000
> > "Grumbach, Emmanuel" <emmanuel.grumbach at intel.com> wrote:
> >   
> > > Hi Ubuntu kernel team,
> > > 
> > > I am reaching out to you about the way to update the firmware for
> > > Intel
> > > wireless device in Ubuntu and more especially in Ubuntu LTS.
> > > 
> > > We maintain branches internally for the firmware in a way that is
> > > very
> > > similar to how linux-stable works.
> > > iwlwifi-cc-a0-77.ucode for example is getting bug fixes that are
> > > backward compatible towards the kernel: any kernel that worked with
> > > the
> > > old version can work with the new one.
> > > This is why we'd be interested in Ubuntu LTS getting those updates.
> > > 
> > > Same is true for all the other files as well of course.
> > > It makes total sense _not_ no include firmware files that cannot be
> > > supported by the kernel being shipper in Ubuntu LTS, for example
> > > iwlwifi-ty-a0-gf-a0-89.ucode is supported only starting from kernel
> > > 6.10. But we can still safely update -83.ucode which is supported
> > > by
> > > kernel 6.6.
> > > 
> > > Is there a way we could make this happen?
> > > 
> > > Maybe it already happens and I missed something?
> > > 
> > > Any help I can provide?
> > > 
> > > Thank your for your time!  
> > 
> > Thanks for reaching out but I'm not exactly sure what you're asking.
> > We try to
> > update our linux-firmware package to latest upstream as close to a
> > new
> > Ubuntu release as possible. From that point on we only update
> > firmwares if
> > there's a bug reported against it. We don't proactively update
> > firmwares
> > because a) we cannot test it and b) it could introduce regressions.  
> 
> This is problematic in my eyes.
> We fix a lot of issues that our validation teams and / or end users
> report. I understand you cannot test all our changes, but then it means
> that Ubuntu users can't benefit from our fixes.
> My mail was triggered by a bug report from a big customer using a
> distribution that forked from Ubuntu LTS and we discovered that they
> ship a very old firmware  while there is a fixed version upstream for a
> year.

Well, that customer should have reported the bug to their distro which then
should have reported it to us.

But this is how distros and specifically LTS's work. We don't update just
because there are newer bits available. We're not a rolling distro. Every
change in a stable release needs a bug report and (ideally) a surgical fix to
prevent unexpected consequences and side effects for other users.

Are we missing out on fixes because of that? Yes absolutely. But having to
justify to a customer why an unrelated firmware update brought down their
house is no fun either... Yes, I'm exaggerating ;-)

But again, this is Ubuntu SRU policy [1], nothing I can do about it other
than bending the rules a bit here and there which I'm already doing.

> 
> > 
> > Ubuntu LTS is a little special because it comes with 2 different
> > kernels. The
> > GA kernel and a rolling HWE kernel that will eventually settle on the
> > version
> > of the next LTS. So in Noble 24.04 we currently have 6.8 (the GA
> > kernel) and
> > HWE 6.14 (the version from Plucky). Later we will replace 6.14 with
> > 6.17 from
> > Questing [1] and then 6.20 (?) from R 26.04 which is the next LTS
> > hence that
> > kernel version will be the last to reach 24.04. If that makes sense
> > :-)  
> 
> You lost me here, but I don't believe we need to really that info to
> clarify the issue being discussed here :)

Heh. All I'm trying so say is that we have two different kernel versions in an
LTS which is sometimes problematic for firmware as well. For example when we
have to update firmware because the newer kernel needs it but that breaks the
older kernel. But yes, this is not related to this discussion.

> 
> > 
> > Obviously we need to add firmwares for those rolling HWE kernels
> > which we
> > tend to do in a bulk update before a point release (which is when new
> > HWE
> > kernel are introduced). As a matter of fact, today is 24.04.3 release
> > date
> > which introduces 6.14 in 24.04. Here's the bug [2] that adds missing
> > firmwares for that kernel (and yes, we probably missed a few which
> > we'll add
> > over time as bug reports come in).
> > 
> > The whole firmware update story is not great, mainly because they're
> > binary
> > blobs with no changelogs so no way for us to know what we're getting.
> > We have
> > to trust the firmware vendors to not introduce regressions with older
> > kernels
> > but it's not always working...  
> 
> I totally understand that, and I feel your pain.
> 
> > 
> > iwlwifi is also a little special in that it supports a range of
> > versions and
> > walks from newest to oldest until it finds one. That's great but hard
> > to
> > figure out what exact versions the kernel supports. It only
> > advertises the
> > max API but not the min and also some firmware names are dynamically
> > generated and not advertised at all (via modinfo/MODILE_FIRMWARE). If
> > I
> > remember correctly, please correct me if I'm wrong.  
> 
> I think we made some work to improve that, but I admit that it's not
> always easy for us to advertise our supported versions via
> MODULE_FIRMWARE accurately...

Understood. It's still on my todo list to figure out more reliably/better
from the kernel (source) what firmwares I need to package for a given kernel
version. Let me know if you have some ideas :-)

> 
> Now I'll try to explain my point:
> 
> We fork the development branch of the firmware every X weeks to release
> branches (that we call "core" branches). Once a core branch has forked,
> only bug fixes will get in. Once the validation is complete, we ship it
> to linux-firmware.git (well, not all the core branches are shipped, but
> you get the idea).
> From time to time, we remove devices from our main development branch.
> E.g. ax200/ax210 have been removed from our development branch, which
> is why you'll never see iwlwifi-cc-a0-78.ucode. In the driver, this
> translates to the MAX being advertised as 77 for ax200 and 89 for
> ax210.
> 
> NOW... the fact that we shipped -77.ucode once doesn't mean we won't
> update it. git log on -77.ucode has gotten a lot of updates as you can
> see here:
> https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/log/iwlwifi-cc-a0-77.ucode
> and this is what I'm really after.

OK.

> 
> How can we have you deploy the latest stable versions?

You'd have to follow the SRU process [1]. Basically open a bug report, fill
in the justification and other details and then verify the changes once they
land in -proposed. Yes it's painful.

Just to be clear, I'd love to always ship updated firmwares (at least the
ones from vendors we have confidence in) but it's against policy. Maybe we
can have an internal discussion to see if we can make exceptions for certain
firmwares.

...Juerg

[1] https://documentation.ubuntu.com/sru/en/latest/

> 
> 
> 
> > 
> > Hope that helps.
> > 
> > ...Juerg
> > 
> > 
> > [1]
> > https://discourse.ubuntu.com/t/announcing-6-17-kernel-for-ubuntu-25-10-questing-quokka/61484
> > [2] https://bugs.launchpad.net/bugs/2116729  

-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <https://lists.ubuntu.com/archives/kernel-team/attachments/20250808/01cee41b/attachment.sig>