@corradoventu great question!
I have an Intel® Wi-Fi 6E AX211 adapter that is managed by the iwlwifi driver. It’s not working since several mainline versions even using the backport-iwlwifi-dkms package. When I saw that new package I hoped it fixes the problem… Unfortunately it doesn’t.
So I’m also interested in the question you asked. Thanks.
nothing to see here… the next mainline build will not produce that.
but, yes we are starting to prebuild and offer as optional installation of the backport-iwlwifi-dkms package : Ubuntu package for some of our kernels. But the version we are building is 9858-0ubuntu4 which is the one from the Ubuntu Archive, and is generally behind what’s in the mainline anyway. Thus it useful to build that for v5.14/v5.15 and the like kernels, but doesn’t make sense to build it for v5.18 mainline. It was a packaging bug that we produced that for the mainline build. I fixed this today.
I am sorry to hear that some of your iwlwifi devices are not working. Even when using 9858-0ubuntu4 with like v5.15 kernel, it doesn’t really enable any additional or new cards, but only brings support to load slightly newer versions of wifi card firmware and improve some stability. So minor things, and doesn’t resolve cases where it didn’t at all work before.
If you can please try running:
sudo fwupdmgr refresh
sudo fwupdmgr update
There might be manufacturer issued firmware updates that may improve things. Apart from that, there are no other news w.r.t. any non-mainline available iwlwifi improvements.
It worked! After reboot wifi is now working with 5.18.0-051800rc7 mainline kernel (‘backport-iwlwifi-dkms’ and ‘linux-modules-iwlwifi-5.18.0-051800rc7-generic_5.18.0-051800rc7.202205160241_amd64’ packages NOT installed).
I’ll take note for the next time 
Thank you very much!
Kernel { 5.18-rc7] at https://www.kernel.org/ is unstable not long term.
This kernel has not been released yet as stable.
Ubuntu only deals with long term ‘supported kernels’ as for for precautions… Currently This kernel is stable.
The latest kernel release that is stable is: 5.17.9 the
The latest long term currently “kernel” is:
5.15.41 Long term 2022-05-18 Stable kernel
Currently look at:
https://www.kernel.org/
Hi,
Canonical Kernel team provides builds of pretty much every upstream tagged releases, of bleeding edge Linus trees as well as stable ones. The discussion here is about those builds, which is known as Canonical Kernel PPA Mainline builds from Index of /mainline
It is not true that Ubuntu only deals with long term kernels… We ship the best kernels available for a given platform. For example, today 20.04 LTS users in majority of public clouds boot into v5.13 kernel, most 22.04 LTS users are using v5.15, but some OEM platforms already use v5.17 kernel, whilst kinetic has early editions of v5.18-rc kernel packaged as linux-unstable.
Really, that is great news.
I did not know this. I have only seen the long term used
in the past. I stand corrected. Thank you for the valuable
information. I know that a large amount of testing
is involved when selecting a kernel.
It really depends on context. For example, users of obsolete Ubuntu LTS releases that are under ESM, or opt into using FIPS certified kernels, or are using Realtime BETA, will in fact observe that only kernels based of longterm-kernel.org upstream releases are offered. But that is coincidence, rather than the rule. Because Canonical Kernel team continues to backport bugfixes & security features to those kernels, long after said kernel version stops being longterm supported from kernel.org.
Getting “Newer kernel available” message
after apt update & upgrade
but reboot does not load the new kernel
Multipass 1.9.0, Mac 11.6.5, launch jammy
I think that this may be a bug or me not knowing the correct commands, probably me.
Please point me to correct chat for this question.
Hey @tech-netharmonix,
I’m the Multipass Engineering Manager and @xnox made me aware of your issue here. I’ll explain why you are seeing this.
I assume you have an Intel Mac and as such, hyperkit is the default driver at this time. The way Hyperkit works is that it boots the kernel directly via grub, so when you update the kernel inside the instance, it won’t boot the newer kernel since the kernel that is booted lives outside the instance. This is just a limitation of Hyperkit unfortunately.
That said, we now support qemu on macOS 10.15 and greater and this is a much better solution for macOS. QEMU boots via UEFI, so no need for booting the kernel directly and thus, kernel upgrades in the instance will work.
You can switch to the qemu driver via $ multipass set local.driver=qemu. There is one big caveat to this though- switching to qemu will make any existing hyperkit instances unavailable, but not deleted. We will soon be working on a way to seemlessly update hyperkit instances to qemu instances and make qemu default on macOS, but we aren’t there yet 
If you have any other Multipass related issues/questions, please feel free to open a new issue at https://github.com/canonical/multipass/issues/ or post to Multipass - Ubuntu Community Hub .
Thanks!
Thank you very much, great explanation,
I was going in circles.
I’ll reconfigure my multipass config.
The bug persists:
Daily Kernel is broken for amd64 and requires a manual intervention on a steady basis. It is important when submitting a bug report if a correction patch is available. Otherwise, 5.18 is since day one, bug free (Debian andor Arch)…
Thanks for the information all over,
Hi,
What is the proper procedure to install the latest mainline ppa kernels ? I use mainline command line tool. https://ubuntuhandbook.org/index.php/2020/08/mainline-install-latest-kernel-ubuntu-linux-mint/
When I install 5.17.9 or 5.17.8 I get unknown symbols from Intel wifi iwlwifi module . If I remove the lwlwifi package ie. [amd64/linux-modules-iwlwifi-5.17.9-051709-generic_5.17.9-051709.202205180947_amd64.deb] package then wifi works fine.
Note 5.17.7 worked fine but it does not have iwlwifi package.
Clearly the Intel wifi firmware version and the corresponding iwlwifi module are out of sync. Is there a new firmware deb that should be included in the mainline debs ?
I saw your post about fixing this issue with 5.18-rc7 but what about 5.17.X kernels ? The RC kernels tend to be a bit too buggy for me and have been to known in the past to cause unrecoverable data corruption issues.
As a user I would expect to just be able to download all the debs and install them (ie use mainline). The reason I use Ubuntu is I want recent mainline kernels without the hassle of maintaining a build environment / compiling / fiddling with DKMS etc…
Hi, i’m not sure what issues you are experiencing with the kernel PPA.
If you look at
https://kernel.ubuntu.com/~kernel-ppa/mainline/
we have the builds for all the mainline tags…
v5.17-rc1/ 2022-01-23 09:53 -
[DIR] v5.17-rc2/ 2022-01-30 15:08 -
[DIR] v5.17-rc3/ 2022-02-06 22:07 -
[DIR] v5.17-rc4/ 2022-02-13 22:07 -
[DIR] v5.17-rc5/ 2022-02-20 23:08 -
[DIR] v5.17-rc6/ 2022-02-27 23:57 -
[DIR] v5.17-rc7/ 2022-03-06 23:57 -
[DIR] v5.17-rc8/ 2022-03-13 21:58 -
[DIR] v5.17.1/ 2022-03-28 10:32 -
[DIR] v5.17.2/ 2022-04-08 14:15 -
[DIR] v5.17.3/ 2022-04-13 19:28 -
[DIR] v5.17.4/ 2022-04-20 10:27 -
[DIR] v5.17.5/ 2022-04-27 16:43 -
[DIR] v5.17.6/ 2022-05-09 09:22 -
[DIR] v5.17.7/ 2022-05-12 13:53 -
[DIR] v5.17.8/ 2022-05-15 20:29 -
[DIR] v5.17.9/ 2022-05-18 10:43 -
[DIR] v5.17/ 2022-03-20 21:57 -
[DIR] v5.18-rc1/ 2022-04-03 22:59 -
[DIR] v5.18-rc2/ 2022-04-11 02:03 -
[DIR] v5.18-rc3/ 2022-04-17 22:55 -
[DIR] v5.18-rc4/ 2022-04-24 23:59 -
[DIR] v5.18-rc5/ 2022-05-01 22:52 -
[DIR] v5.18-rc6/ 2022-05-08 21:57 -
[DIR] v5.18-rc7/ 2022-05-16 03:21 -
[DIR] v5.18/ 2022-05-22 20:57 -
The linux-modules-iwlwifi package was produced in error, and should not be installed.
Most recent builds have been fixed up to not produce it, ie. Index of /mainline/v5.18
I made a request, and the iwlwifi .deb packages have now been renamed to end with .backup suffixes in any existing builds that produced it in error. This should prevent any automated scripts to attempt to download or install those packages.
It is correct action to skip installing this packages / remove it, if it was installed.
Hi,
The 5.18.1 and 5.17.12 ppa builds are broken as they either show no packages or some architectures show 5.15 kernel packages ? Could you please check ? Thanks.
we are trying to figure out where robots went rogue.
I’m late to the party in asking a question, but here’s mine: what’s the status and effort being applied to get the Ubuntu Sauce patches to AppArmor that are required in addition to upstream AppArmor in the kernel so that snapd is able to enable strict confinement out of the box. I ask because as the kernel currently stands upstream, I believe there are bits missing that snapd requires. Certainly the WSL2 kernel which is based on upstream 5.10 does not have enough Ubuntu Sauce (as it is directly forked from upstream by Microsoft, without adding any Ubuntu patches because MS has no reason to do so) to enable strict confinement.
AppArmor development in Ubuntu has more features than vanilla upstream kernel. And this will remain to be so in the foreseeable future, as we have more resources to include, test, support and use new AppArmor features in Ubuntu kernels ahead of inclusion in the vanilla releases. We do not limit ourselves to using vanilla-only features in obsolete kernel versions.
Separately, there is ongoing work to make systemd and snapd, and hence snaps work on top of WSL2 with the Microsoft provided kernel. This is possible because snapd is able to adapt to the available confinement features to still offer snaps. Also we are open in providing and supporting Microsoft to integrate more up to date features of Linux to their WSL offering than they currently provide.
You missed the point I was making. By adding Ubuntu-only AppArmor extensions to the kernel and using those within snapd we are seriously limiting the functionality and security story of Snap Packages in other native distros and WSL2. By not pushing the AppArmor patches upstream quickly enough there will never be a time that a third-party distro can be supported by snapd, which will (and currently does) always report “partial confinement” and therefore not apply the Strict Confinement rules on those distros meaning that any Snap package will be able to escape the sandbox easily.