In that case, we already have a UEFI-UKI flavor, and I’d rather if you want to make an Azure flavor for that, to expand on that configuration.
I’m not sure why we’d want to offer two flavors of Azure images though? I certainly don’t want to test and support both.
Because the UKI flavor is inherently limiting. No driver expansion, limited boot partition space, and so on. I certainly wouldn’t want to use it, and I don’t think most people would either.
But for some classes of workloads with particular deployment architectures, it’s probably okay. I just don’t ever expect it to be the dominant one.
It’s possible I’ll give it a try and find out it doesn’t work well and for some reason can’t ever work well. I’m not sure what you mean by driver expansion?
However, I’ve used UKIs exclusively on my personal devices for over a year and been very pleased with the experience. Images do need to take some hardware details into account, but the hardware is slightly more predictable on Azure than the world generally so it’s not like the initramfs needs to include the kitchen sink.
GPU accelerated instances require the NVIDIA proprietary driver, and that is complicated with UKIs. Even with extended images to load more drivers, it’s still complicated and results in a lot more disk space being used, which create problems with space contention.
And of course, bare metal instances exist, which have some level of the issues similar to regular systems.
Sure, you’ve got to sign the modules and the current experience of enrolling keys for Azure isn’t as smooth as I’d like it to be, but why would we put the NVIDIA driver in the initramfs? Since I’ve not built this out and tested it on the full set of SKUs I’m not sure what problems I need to solve yet, but I suspect I can solve the problems.
Yes, bare metal instances exist, although in Azure as far as I know it only supports RHEL and SLES. But my laptop is also bare metal and UKIs work fine for it.
This seems a bit alarming. Given that AIUI the most important BLS implementation is, for better or worse, Grub, for clarity who actually decides on changes to the BLS spec? Do representatives of all implementers get an input and a vote?
I think this phrasing just creates confusion. The BLS is a specification that has a canonical location and a set of people working on it. Any changes are done following the usual open source review process where any interested parties can make comments and ask for changes. Grub2 does not implement all of the spec, and in other places implements it strangely, sometimes with downstream incompatible extensions. So that implementation is not — from the upstream PoV — particularly important. That said, for the spec, input from anyone is welcome. Just subscribe to the uapi repo and comment on any issues and pull requests as they happen.
1 Like
I am against it… because I say that sd-boot is better that GRUB for cloud deployments, as it is less prone to breakage.
And I don’t think btrfs will be a good idea for /boot esp. for “cloud” usage.
A smaller /boot? Slimming the bootloader (on the ESP)? more space saved.
(Of course, sd-boot could easily load an EFI driver \EFI\systemd\drivers\whateverx64.efi and support btrfs like GRUB, but my point isn’t to support sd-boot… It’s against btrfs for booting)
You are free to convince me otherwise.
This change has been approved by FESCo and will be included in Fedora Linux 44.
To find out more about how our changes policy works, please visit our docs site.
FESCo Issue: Making sure you're not a bot!