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 Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2069802 Title: [SRU] flash-kernel to support xilinx kria platforms with noble kernel To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/flash-kernel/+bug/2069802/+subscriptions -- ubuntu-bugs mailing list ubuntu-bugs@lists.ubuntu.com https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
