Ubuntu Kernel team has an IRC channel on irc.libera.chat as ~ubuntu-kernel for general questions and chit chat about Ubuntu Kernels.
However, people frequently disconnect from IRC.
If you have any small questions, comments or requests about Ubuntu Kernels, feel free to leave them here. Canonical Kernel Team will monitor this thread and try to answer any questions raised, or redirect to an appropriate place.
Hi. The amd64 mainline test kernels (5.18-rc2 and rc3) weren’t built since two weeks ago because the build fails. I don’t know if it’s monitored or if it’s an automatic process and may be not fixed. Thanks and best regards.
I know! 
it is monitored and it is automatic process, but when builds fail manual intervention is needed to fix up those builds to change config and packaging to become compatible once again. We are currently preparing the Jammy Release and the first batch of linux kernel SRUs that will go right after Jammy is released. After that we will focus on fixing up mainline builds. My current estimate is that we should be back to having buildable mainline test kernels with rc4 ish.
Hi. One question about Ubuntu’s kernel version number.
Is it possible to know what is the particular base kernel used for a particular Ubuntu kernel?
For instance, I’m interested in kernel 5.15.35 (official version number) because it contains some backports related to Alder Lake processors performance. The current Ubuntu 22.04 kernel version number is 5.15.0-27.28. What is it’s base kernel number (5.15.0, 5.15.27, another…)? How can it be checked if it’s not as easy as parsing it’s Ubuntu’s version number?
Thanks and best regards.
on a running system you can check it with:
cat /proc/version_signature
the last part of the return value is the mainline base number … (not sure where to look in the source though)
An upcoming Ubuntu kernel update for jammy, and also focal 5.15 HWE kernel will contain that fix soon. I mean, it was I who submitted it to v5.15 stable 
Thank you very much!
That’s fantastic! 
I’ll check from time to time the proposed kernels. Thank you very much!.
Hi,
I use Ubuntu 20.04, and my question is, if possible, to know when:
This is to major bugs I’ve in 2 off my machines.
Regards
Miguel Pires
If your issues are similar to https://gitlab.freedesktop.org/drm/amd/-/issues/1772 then the solution will be available soon in focal with the 5.15 kernel. If you cannot wait to try it out, you can enable focal-proposed and opt into installing linux-generic-hwe-20.04-edge package. It should be available in focal-updates without need to enable focal-proposed soon, and then after a delay we will roll linux-generic-hwe-20.04 from 5.13 to 5.15.
I’m not sure what that could be. Could you please elaborate more? or point at any existing bug reports? Is it related to gnome-shell having interesting behavior with respect to number of mouse pointers and sensitivity. Or something else entirely?
Thks for the answer.
I will test the 20.04-edge kernel and see if it solve the problem.
About the the other bug, I think I type the wrong word, is the Touchpad that dont work. You can see this bug (others are similar)
Thks again
It looks like a manual fix is required on a daily base since 2 weeks? Kinetic is out now, but the bug persists since for long before the end of JJ.
which bug ? (you really have to be more specific)
it is obviously tagged for jammy in the last comment … so it will eventually be fixed …
Hi, can you tell about the oem kernels, when they are updated to a newer version, how supported they are and so on?
I’m also interested in oem kernels questions by @sonny.
I add this question: why there are two oem kernel packages for 22.04, linux-oem-22.04 and linux-oem-22.04a? What are the differences?
Thanks in advance.
That bug report is investigated, but there is no commitments from any of the involved teams as to how or when it will be fixed. Decisions on whether or not revert identified commit has not been made, as doing that will affect other platforms too.
@ogra incoming tags are not a commitment to fix, but a team internal method to schedule triage of issues.
Some of the information on kernel variants is available from here
In general, Canonical has many partnerships with many hardware vendors and OEMs. For example companies like Dell, Lenovo and so on. When Canonical and OEM teams get together to enable and certify a new range of laptops and desktop, it is usually attempted to do so using the GA/generic kernel, if not possible or sustainable using HWE kernel (aka ga/generic from a future series), and if that is not possible with OEM kernel.
OEM kernels are temporary stepping stones, that may be based on a kernel series behind or ahead of HWE one, and usually contain many patches and drivers from various “-tip” “-next” and hardware vendor trees, that may have been merged into mainline kernel or still undergoing rounds of reviews. In general OEM kernel is not meant for general consumption, because it has out-of-mainline patches, quirks and driver workaround that make a subset of SKUs work, whilst potentially regressing other platforms.
When using Ubuntu Desktop installer, sudo ubuntu-drivers list-oem is invoked to detect if a given hardware configuration is certified and supported by the Canonical HWE team with additional kernels or repositories. And depending on individual SKU requirements opt-in is made into either HWE or OEM kernel. With additional, per-sku repositories getting enabled to allow shipping targeted user-space updates.
After a period of time, various SKUs are rolled-off OEM kernel back onto generic or hwe kernels, as fixes for the required platforms make their way into the default kernels.
Thus OEM kernel is mostly about time-to-market for latest generation of laptops, which may not even be available for purchase yet. As often this kernel is used for factory preinstalled images, and it might be moved to HWE kernel by the time end-user can buy and boot the laptop.
That’s a great question. For most kernel variants we have two streams i.e. linux-generic-hwe-20.04 and linux-generic-hwe-20.04-edge. It allows us to ship two different kernel series at the same time (like 5.13 & 5.15 currently in focal) and quickly switch meta-packages to roll a given variant from one series, to next. I.e. we are able to respin metapackage only to make linux-generic-hwe-20.04 point at v5.15 kernel, without doing a new kernel build.
For oem kernel, we have a need to prepare and build more than two oem kernel variants at a time. And using alphabetical suffixes seemed like the easiest way for it. For example, early in jammy “oem-22.04” “oem-22.04-edge” “hwe-22.04” were all pointing at the v5.15 ga kernel. oem-22.04a was being prepared in the archive based on v5.17 kernel with many patches, but was not yet automatically selected or installed by the installer. But it was available from the archive for testing purposes. Then we moved oem-22.04-edge to point at oem-22.04a once it was edge quality, and I think currently we point both “oem-22.04” and “oem-22.04-edge” at oem-22.04a kernel, meaning it has stabilized enough to be used as the default OEM platform.
Eventually, oem-22.04a will be retired infavor of GA & HWE kenrels on per-flavour basis. And depending on the types of future platforms oem-22.04b, oem-22.04c, etc will be created.
In general, one should not install OEM kernels directly via any of these metapackages, unless sudo ubuntu-drivers list-oem suggests to install them. Using OEM kernels on hardware platforms they don’t target can lead to regressed hardware support and bugs that are unlikely to be addressed. I.e. one will get to keep all of the broken pieces =)
Last 5.18 rc7 https://kernel.ubuntu.com/~kernel-ppa/mainline/v5.18-rc7/ has a new deb:
amd64/linux-modules-iwlwifi-5.18.0-051800rc7-generic_5.18.0-051800rc7.202205160241_amd64.deb
what is it for? how to use?