Improvements for hardware support in Ubuntu Desktop installation media

Desktop
1

Ubuntu has a long history of shipping preinstalled Ubuntu Desktop laptops and workstations with many OEMs (e.g. Dell, HP, Lenovo to name drop a few in alphabetical order). This has been made possible due to the extensive engineering efforts of the Canonical Kernel Team to introduce support for bleeding-edge hardware, and to create bespoke kernel flavours on the LTS releases. However, prior to Ubuntu 20.04 LTS one typically had to keep the preinstalled version of Ubuntu that came with the machine, or to install using bespoke per-SKU Ubuntu Desktop OEM installation media.

Furthermore, in the past there were behavioural differences between .0, .1 & .2+ installation media, such that installations using .0 and .1 media resulted in different hardware support than installations made using .2+ media.

For the Ubuntu 20.04 LTS development cycle, the Desktop, Certification, and Foundations teams made an engineering effort to unify the installation experience that results from using any version of the Desktop installation media.

Subsequently, when using any Ubuntu Desktop 20.04 LTS installation medium the best kernel for your hardware is chosen and installed automatically. Additionally, once your hardware is fully supported and certified in a newer version of the hardware enablement kernel, your system is automatically rolled and switched from the OEM kernel to the HWE kernel. Ubuntu recommends to stay on track with the kernel flavour chosen by the installer. Manually changing to other available kernel flavours may result in degradation of performance and lack of support for certified hardware.

The in-archive switch from v5.4 to v5.8 coincided with a CRD (coordinated release date) for several security vulnerabilities. And while automated testing passed for all drivers, we now know that at least three tests returned false positives (tests reporting a pass, while in fact failing). Our mistake has been identified, the tests rectified, and fixes for three[1,2,3] of the kernel bugs have already been rolled out in Ubuntu 20.04 LTS. Unfortunately, rolling the kernels back was not an option due to the fixes for security vulnerabilities.

We hope this update explains the installer changes that were designed and implemented between Ubuntu 18.04 LTS and Ubuntu 20.04 LTS, which are now bearing tangible benefits.

[1] virtualbox
[2] nvidia-graphics-drivers-340
[3] bcmwl

12 Likes
2

Whoa, that is quite a bit more complicated than I had imagined it might be. Thank you (and the rest of the people involved) for wading through all that and getting it sorted.

There are a couple things that might be good to add to this:

  1. Is there a master list of all the bugs that we could use to track the resolution of the remaining bugs? Or are they all resolved?
  2. I know some folks lost networking (including Ethernet) as a result of this, making getting updates to drivers quite a bit difficult. Perhaps providing documentation about resolving that would be wise? Maybe something like rolling back to the previous kernel by changing GRUB_DEFAULT?

Also, I have another question looking forward. Is there a plan to enforce this behavior on other flavors or Server? If not, why? Just curious, really.

5 Likes
3

I’ve added a list of bugs to the post which we are aware of and have resolved at this point in time. Additionally, we’d be interested to see bug reports about any other issues people encountered including your anecdote about people losing Ethernet connections.

4

Thanks for the addition of the bugs. So does that mean that all the bugs you’re aware of are those three?

Regarding the Ethernet issue, when I first was made aware of this situation, I did some rather exhaustive searching. Unfortunately, I didn’t really keep a record of it because what I was looking for was actually something like this topic. That said, I know that AskUbuntu had a bunch of support queries. A quick search popped this up rather quickly. That seems to be the atl1c module. I’ll just ping @guiverc since I know he’s very active on AskUbuntu and may have some additional suggestions.

Also, since you didn’t respond on my last comment, are there any plans to apply this same policy (which, as you said, is admittedly a positive one) to other flavors? If not, why? It seems like it would make sense for it to apply everywhere but I may not be thinking it through.

1 Like
5

Yes, those three bugs are the ones which the release team is aware of and which required packages to be updated in Ubuntu 20.04 LTS due to the newer kernel version. However, its also possible systems that had packages from -security installed but not packages from -updates installed could have ended up in an awkward state.

With regards to your question about other flavors, I can only speak to the server version of the Ubuntu installation media. The server version is continuing to stay with the generic kernel (as it has done for previous LTS releases); however, the hardware enablement kernel is an available option on the installation media. The generic kernel is the default as server workloads are typically optimized and tuned for a specific kernel.

2 Likes
6

Thank you for acknowledging and explaining the driver oversights! Mistakes happen, it’s understandable; the concern is just avoiding them in the future. :slightly_smiling_face:

To work around the Broadcom wireless bug on an old Dell XPS M1530, I had intentionally used older 20.04 desktop installation media and installed without connecting to the Internet, then installed updates afterwards. It seemed to stay on the 5.4 kernel instead of auto-upgrading to the (at the time broken with bcmwl) 5.8 kernel.

Will the standard Ubuntu Software Updater switch to 5.8 if run later, or is manual intervention needed? As far as I can recall, I did not switch kernel tracks using apt commands (as shown in the HWE wiki page).

1 Like
7

bcmwl dkms module has been fixed in Ubuntu 20.04 to support both 5.4 and 5.8 kernels. Thus you should not have any worries about upgrading and staying on the HWE track.

I would recommend for you to have linux-generic-hwe-20.04 installed with bcmwl-kernel-source

It would be helpful for you to check which kernels you are on, and which drivers you have, and which kernel you want to track.

uname -a
dpkg-query -W linux-generic linux-generic-hwe-20.04
ubuntu-drivers list

On my machine I have

$ uname -a
Linux ottawa 5.8.0-41-generic #46-Ubuntu SMP Mon Jan 18 16:48:44 UTC 2021 x86_64 x86_64 x86_64 GNU/Linux

$ dpkg-query -W linux-generic linux-generic-hwe-20.04
linux-generic-hwe-20.04	5.8.0.41.45
dpkg-query: no packages found matching linux-generic

$ ubuntu-drivers list
nvidia-driver-460, (kernel modules provided by linux-modules-nvidia-460-generic-hwe-20.04)
nvidia-driver-450, (kernel modules provided by linux-modules-nvidia-450-generic-hwe-20.04)
nvidia-driver-450-server, (kernel modules provided by linux-modules-nvidia-450-server-generic-hwe-20.04)

So I am tracking HWE kernel track, have 3 options to install nvidia drivers, and my machine doesn’t need broadcom drivers.

In ideal scenario you should either have:

  • linux-generic-hwe-20.04 bcmwl-kernel-source nvidia-driver-460 linux-modules-nvidia-460-generic-hwe-20.04
  • linux-generic bcmwl-kernel-source nvidia-driver-460 linux-modules-nvidia-460-generic

Now depending on which installer image you have used, with which combination of bugs, on which hardware one or more things from above could be missmatched - i.e. wrong default kernel metapackage, missmatched nvidia metapackage, and hopefully always the right bcmwl package.

4 Likes