Hi, > /dev/nvme0n1p1 on /boot/efi type vfat > /dev/nvme0n1p2 on /boot type ext4
> Current Boot Loader: > Product: GRUB 2.12 > So what are you saying with "so with secure boot turned on this will not > work."? "not work" meaning that you can not access the filesystem using efi firmware functions. grub brings its own drivers for pretty much everything, including filesystems, but does not integrate very well with UEFI. So grub itself can access ext4 /boot just fine, but anything loaded by grub can not. Which kind-of blocks more wide UKI adoption in fedora, because UKIs actually can load additional stuff from disk (see 'COMPANION FILES' section in the system-stub man-page). But that doesn't work in the 'grub loads uki from ext4 /boot' case. More wide UKI adoption in Fedora (right now all we have is a cloud image) would be good for security (initrd + kernel cmdline are covered by secure boot signature). Also for robustness (generating the initrd on the installed system is fragile). But you can't change the kernel command line, so you need other ways to configure the system. Which why supporting UKI companion files is rather essential to move forward here, because that is one of those other ways. Coming somewhat back to $subject, one possible way to reduce storage consumption would be to store the firmware blobs in sysext files which could be shared by all UKIs. Which also depends on companion file loading working properly. > If we talk about changes for fresh installs (or reinstalls), we might as > well switch /boot to vfat now, though that is easier to to in-place than > resizing it. "now" as in "for F43", as part of the emergency change proposal? I'd feel quite nervous here doing it /that/ close to the release. "now" as in "now in rawhide?". Sure, I'm all for it. Gives us one full devel cycle to fixup any possible fallout. I've experimented with that in the past without running into problems, so I expect that going smooth overall, but the one or other broken corner case might show up. > But other than size and fs type of /boot (and, possibly, giving up on > the rescue entry), are there ways forward which would avoid the problem > all together and still support our typical use cases (including dual > boot, secure boot, encrypted root, bare metal firmware as well as > virtual)? Well, I think we should look at excluding GPU drivers and firmware from the initrd + run on simpledrm instead until the GPU drivers are loaded from the root filesystem. Will reduce the initrd size and speed up boot. Problem is that the prompt for the encryption password will only show up on displays lit up by the firmware then (see the blog post by Hans linked multiple times in this thread), so we'll need a config option for that I guess. dracut-config-fastboot.rpm anyone? And it also is not really a way around increasing the filesystem size because both cases (initrd with/without gpu drivers) must continue to work. Additional things to be aware of in this context: Boot loader team works on changing the way boot loaders are packaged[1]. This will -- among other things -- kill the hard-coded /boot/efi paths in boot loader RPMs. Which in turn will give us more flexibility on how we handle the ESP: * We can finally get rid of the nasty nested /boot/efi mount and use /efi instead. * We can also use the ESP as /boot, which we IMHO should do in case anaconda finds a blank disk and we can create an ESP big enough for our needs. take care, Gerd [1] https://fedoraproject.org/wiki/Changes/BootLoaderUpdatesPhase1 -- _______________________________________________ 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
