I understand the benefits of this change. My own raspberry pi systems failed to upgrade to resolute because of a too small partition.
But I also understand the blast radius of a regression here, and it's not small. What can we do to make this safer, and worthwhile? At least the test plan needs to cover more ground. Some cases that come to mind: - test raspberry cases: upgrades to this package (of course), but also release upgrades from noble; - install all the packages that could possibly influence the initrd generation: luks, iscsi, other filesystems, nfs root, something ubuntu core perhaps, raid-on-root, lvm-on-root, etc. And see if something breaks to a) generate the initrd; b) boot from it. I suppose this is a much higher bar than what was applied when we switched TO rust-coreutils, but this is an SRU for our latest Ubuntu LTS, so the bar is higher on purpose. - while in a development release, such a change would have much more machinery testing it: generation of daily images, release snapshots, cloud image testing, and so on. Can we do any of it in the case of the SRU, before the package hits updates? - boot via the rescue option in the grub menu (what is it called again?) When did we switch to dracut, was it resolute? If yes, that means we never had the combination of dracut + busybox before? As for the actual release in updates, if/when that comes: - we could leave this in proposed for much longer, on purpose -> block-proposed tag - slow down phasing even more, like grub perhaps -- You received this bug notification because you are a member of Ubuntu Bugs, which is subscribed to Ubuntu. https://bugs.launchpad.net/bugs/2150657 Title: Use busybox instead of rust-coreutils in initrd To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/busybox/+bug/2150657/+subscriptions -- ubuntu-bugs mailing list [email protected] https://lists.ubuntu.com/mailman/listinfo/ubuntu-bugs
