On Fri, Nov 21, 2025 at 04:23:48PM -0500, Neal Gompa wrote: > On Fri, Nov 21, 2025 at 4:22 PM Przemek Klosowski via devel > <[email protected]> wrote: > > > > On 10/6/25 4:13 AM, Zbigniew Jędrzejewski-Szmek wrote: > > > I have been using Fedora for … a few years now, and I have never used > > > one of those either. Is somebody is using the Rescue images, please > > > speak up. > > > > FWIW, I recently worked on an unbootable system and tried to use rescue. > > I think it came from the original install, several Fedora versions > > previous, with the old kernel and such. > > > > It didn't work. I think it failed for the same reason as the regular > > boot (bad labels that prevented the start of essential services like > > dbus, fixed by /.autorelabel)---but I didn't even investigate it, just > > rebooted with a Live USB. > > > > BTW, init=/bin/sh as a shortcut before grabbing a Live USB is awesome. > > Is it going to go away in the Secure Boot tightening progression? > > > > Yes, with locked down UKI-style stuff, custom command-line arguments > are not supported anymore. You need different images with different > arguments instead.
The situation is more complicated. People have realized that the original situation where "one uki == one commandline" is limiting, and various extensions mechanisms have been added. The current options: 1. multi-profile UKIs: the UKI contains e.g. two .cmdline sections and e.g. two .initrd sections, while the other sections are shared. The typical use of this would be add a 'debug' profile with additional kernel commandline options for debugging and possibly a bigger initrd with more tools. 2. UKI addons: this is a separate .efi file, using the same format as a UKI, also signed, that is merged with the UKI. 3+4. sysexts and confexts: code and config extensions for the host filesystem, also need to be signed. Option 1 would be managed by the distro building the kernel, options 2—4 can also be managed locally using shim MOK. Zbyszek -- _______________________________________________ devel mailing list -- [email protected] To unsubscribe send an email to [email protected] Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/[email protected] Do not reply to spam, report it: https://pagure.io/fedora-infrastructure/new_issue
