[Bug 2083657] Re: Remove oem-flavour.cfg for the OEM kernel retirement

[Robie Basak]

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 Ubuntu
Sponsors, which is subscribed to the bug report.
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