SRU review. I appreciate the importance of fixing this and the general approach seems OK to me.
0. I do have some difficulty in understand the exact mechanism involved. Is it correct that in *all* cases it's now wrong in Jammy for /etc/default/grub.d/oem-flavour.cfg to point to `oem- somerville*-meta|oem-stella*-meta|oem-sutton*-meta` what about after the user upgrades to Noble? What should happen then? What assurances do we have that removing /etc/default/grub.d/oem-flavour.cfg will result in a still-working kernel? I think it would really help to document the technical mechanisms involved here in more detail so that reviewers and observers can get some more confidence in the fix, but I don't think that part is a blocker for SRU. 1. I understand that this currently only affects Jammy. But it's a general pattern that will eventually happen on every LTS, right? So from the SRU philosophy that we avoid future regressions by fixing the development release first, shouldn't there at least be a bug that tracks a long term solution to the general problem that, when fixed, will stop this problem recurring? 2. I appreciate that the severity of this bug and its ability to regress existing behaviour means that we shouldn't block on such a fix actually landing before we hack a fix for Jammy, but could that bug at least be created so that it is tracked, please? 3. I appreciate that this is both important and that some hack is going to have to go somewhere. But please could you get an ack for this from someone on the desktop team please, as they maintain this package and if we're going to do something as unusual as this then they should probably have input? 4. I think the "&& exit 0" lines are a bug, because they will preclude any #DEBHELPER# snippets from running. It looks like debhelper already has generated code in ubuntu-drivers.postinst so this seems like a real and immediate issue. Probably the easiest is to move this into a function and use `return`, but note that then you'll need to do explicit error checking since `set -e` will no longer work. But also, please add `set -e` anyway as is best practice. 5. Why is a previous debian/changelog entry being changed? If you're correcting a previous mistake then I guess it's subjective as to whether that's OK, but I can't distinguish between that and an inadvertent change. Please could you clarify? 6. Shouldn't you be triggering update-grub after touching /etc/default/grub.d, or is there a mechanism for that already in place? 7. I think some additional testing is warranted: specifically to test idempotency of the upgrade path, as well as correct handling for the common case of a non-OEM install. Please could you add to the Test Plan to test these paths? Due to point 4, I fairly sure that the current upload needs amending, so I'm rejecting it from the queue. -- You received this bug notification because you are a member of Desktop Packages, which is subscribed to ubuntu-drivers-common in Ubuntu. https://bugs.launchpad.net/bugs/2083657 Title: Remove oem-flavour.cfg for the OEM kernel retirement Status in OEM Priority Project: In Progress Status in ubuntu-drivers-common package in Ubuntu: Won't Fix Status in ubuntu-drivers-common source package in Jammy: In Progress Bug description: [ Impact ] * This issue affects all Ubuntu OEM preloaded systems that are still utilizing the OEM kernel, particularly those equipped with NVIDIA graphics drivers. * Systems may fail to boot properly due to an outdated OEM kernel conflicting with newer NVIDIA drivers, leading to a black screen on reboot. [ Test Plan ] * To verify the fix, ensure that the file `/etc/default/grub.d/oem-flavour.cfg` is successfully removed from the affected system after applying the update. * Additionally, after the system reboots, check that it boots into the general HWE kernel rather than the OEM kernel. [ Where problems could occur ] * Removing `/etc/default/grub.d/oem-flavour.cfg` may cause systems relying on the OEM kernel for specific hardware compatibility to lose access to certain OEM-specific optimizations. * There is a low risk that after removing the OEM kernel, some hardware features may not function as expected if the general HWE kernel does not fully support them. [ Other Info ] * This patch is targeted only for Ubuntu 22.04 and its associated OEM kernels. * The issue is specific to systems using NVIDIA drivers in conjunction with an outdated OEM kernel, which conflicts with updates to the HWE kernel and NVIDIA packages. 1) The release of Ubuntu you are using, via 'lsb_release -rd' or System -> About $ lsb_release -rd Description: Ubuntu 22.04.4 LTS Release: 22.04 $ ubuntu-report show | grep DCD "DCD": "canonical-oem-sutton-jammy-amd64-20240606-874" 2) The version of the package you are using, via 'apt-cache policy pkgname' or by checking in Software Center $ apt-cache policy ubuntu-drivers-common ubuntu-drivers-common: Installed: 1:0.9.6.2~0.22.04.6 Candidate: 1:0.9.6.2~0.22.04.7 Version table: 1:0.9.6.2~0.22.04.7 500 500 http://tw.archive.ubuntu.com/ubuntu jammy-updates/main amd64 Packages *** 1:0.9.6.2~0.22.04.6 100 100 /var/lib/dpkg/status 1:0.9.6.1 500 500 http://tw.archive.ubuntu.com/ubuntu jammy/main amd64 Packages 3) What you expected to happen * The system should seamlessly upgrade NVIDIA drivers and the HWE kernel without breaking the boot process. The system should boot into the latest supported HWE kernel without encountering compatibility issues with the NVIDIA drivers. 4) What happened instead * After unattended-upgrades, the system rebooted into the OEM kernel, which is outdated and incompatible with the new NVIDIA drivers. As a result, the screen remained black upon reboot. We need to remove /etc/default/grub.d/oem-flavour.cfg to avoid the system booting from deprecated OEM kernels. To manage notifications about this bug go to: https://bugs.launchpad.net/oem-priority/+bug/2083657/+subscriptions -- Mailing list: https://launchpad.net/~desktop-packages Post to : [email protected] Unsubscribe : https://launchpad.net/~desktop-packages More help : https://help.launchpad.net/ListHelp
