Intel wireless firmware updates for Ubuntu LTS

Fri Aug 8 11:13:28 UTC 2025

On Fri, 2025-08-08 at 12:47 +0200, Juerg Haefliger wrote:
> 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 :-)

I'll take that internally and get back to you.
All I can say is that started to be more focused on reducing the range
of the firmware versions a specific kernel supports, in order to be
able to remove code in the driver:

If the MAX version of device X is Y, then, some reasonable time after
firmware Y has been released, we can move MIN to Y and remove all the
code that was handling versions <Y.
This should make your life easier as well. But that will happen for
newer kernel and it'll take time until you'll benefit from that...

> 
> 
> > 
> > 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.

Ok.. I understand. Just so that you know that in case people do have
issues like firmware crashes etc... you can file a bug on upstream
bugzilla. We monitor the component network-wireless-intel.
I'll be glad to get bugs from you which would make you update the
firmware bits, but without deviating from your SRU process ;)

Jokes aside, would it be helpful to send you the release notes so that
you can see what has been fixed between releases?

> 
> ...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  