[Bug 2069802] Re: [SRU] flash-kernel to support xilinx kria platforms with noble kernel

[Loïc Minier]

Word of warning, this is a complex topic!

So as you know, flash-kernel gets triggered quite often: when the kernel
gets updated, when packages participating in the contents of the
initramfs get updated (initramfs-tools, packages shipping modules), it
should probably also run  when f-k gets updated but I think it doesn't
right now. This happens through hooks in other packages when they are
doing certain things (kernel post-installation runparts, initramfs post-
generation runparts), and/or dpkg triggers, and/or regular package
maintainer scripts.

I /think/ Breaks should do the right thing in preventing most of these
runs until the new files are in place.

In general, the risks you're trying to manage:
- system is unbootable after attempting an upgrade
- system can't complete its upgrade and requires admin intervention
- windows of time where the system would be unbootable if we pulled the cord

One thing I'm worried about when I see kernel-flavor checks is that a
"strict" f-k flavor check kicks in while in the middle of upgrading
between flavors, resulting in the upgrade being aborted and/or leaving
the system in an unbootable state. This could either be the old f-k
being triggered with the new flavor, or it could also be the new f-k
being triggered while the old flavor is still there. I think it's easy
to kill the second case by listing both flavors in new f-k

There are other things that can happen: both old and new flavors being
on disk, and f-k being called to install the wrong, old one (I haven't
looked at how the two would get sorted; would the highest version win,
or would the name be preponderant?).

In general with updates and upgrades, you can assume:
- system might be updating from older packages in one series to newer packages in the same series
- system might be upgrading from one series to the next, or for one LTS to the next, but a) latest updates must be installed before upgrading, b) can't jump a series or jump an LTS in an upgrade
- system might be half-updated or half-upgraded and lose power, ideally we want this system to still boot and later continue with the update/upgrade
- you can only count on enforcing the order of updates/upgrades through versioned dependencies such as depends/breaks/conflicts


All of these scenarios are already quite hairy; let's say we have managed all of these perfectly in our packaging. We might also want to do backports:
- backport a new kernel to an older Ubuntu (not sure we're planning this), but perhaps the f-k in that older Ubuntu doesn't support that flavor
- backport a new f-k to an older Ubuntu (I think this is rare, but might be needed when you want to support a new flavor in an older and the f-k version in the older series didn't support it) but perhaps the new f-k is not ready to support the old kernel flavor

The hardest stretch in backwards compat is when we are backporting a
version of a package from one LTS to the previous LTS, then this package
might be around from old LTS to next LTS, spanning 2 LTSes.

You can probably ignore the backports scenarios for this work, just
wanted to share them for completeness.

-- 
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/2069802

Title:
  [SRU] flash-kernel to support xilinx kria platforms with noble kernel

Status in flash-kernel package in Ubuntu:
  In Progress

Bug description:
  [ Impact ]

   * With the current version of flash-kernel, users wont be able to
  boot into xilinx devices using optimised noble kernel because of the
  renaming of device-trees in kernel and cma configuration changes.

   * We need to fix this issue to keep support for xilinx devices in
  noble as well. This must not be back-ported into jammy since the
  kernel in jammy keeps the old names for device-trees and cma
  configuration in there didn't change

   * Patch will fix the issue by updating bootscript and `its` file to
  point correct device-tree files.

  [ Test Plan ]

   * Flash the new image generated with new flash-kernel that has this fix
   * Try booting with new image
   * You should be able to reach the login prompt and be able to login using default username and password
   * This must work for all Kria devices listed below:
    - KV260
    - KR260
    - KD240

  [ Where problems could occur ]
   * This change could only impact Xilinx Kria devices since it will only touch the files used by Xilinx Kria platforms including the ones listed above in test plan
   * Since this is an enablement patch for Ubuntu Noble image on Xilinx Kria platforms, there shouldnt be an impact to devices in the field.
   * If the patch is broken then the devices listed above will still continue to not work.

  [ Other Info ]
   
   * This is based on changes in new optimised kernel: https://code.launchpad.net/~canonical-kernel/ubuntu/+source/linux-xilinx/+git/noble

To manage notifications about this bug go to:
https://bugs.launchpad.net/ubuntu/+source/flash-kernel/+bug/2069802/+subscriptions