Could we have an option in Ubiquity to use systemd-boot instead of GRUB? With UEFI in all modern PCs it’s now possible to load kernels directly by adding manual entries in firmware’s menu, but systemd-boot provides simple menu with kernel versions and autoentries for Windows/etc. Moreover, Boot Loader Spec and systemd-boot depend only on simple text files + kernels on ESP. It would be nice, if Ubuntu could provide systemd-boot out of the box. There’re some example hooks like this one, but you need to install them manually. I think just using config files will be enough, but in the future it will be cool to build and sign .efi files on kernel install and go full Secure Boot mode. Thanks.
Is there a reason (other than reduced complexity for one class of machine, but increased complexity for the distro as a whole) why you feel this would be a desirable feature?
You mention “signing efi files on kernel install and going full Secure Boot”, but we ship signed kernels by default already, and enable Secure Boot end-to-end. Using a different bootloader wouldn’t change this.
I feel like people could take an advantage of a feature introduced 15 years ago and avoid update-grub, complicated scripts, gain faster boot speeds, easier kernel installation, boot management in firmware, etc. Not sure what you mean about “one class of machine”, but x86_64 is 98% of Ubuntu installs.
Signed kernel is a little bit different to a signed .efi package of kernel+initramfs+config as a whole which is loadable by UEFI itself without grub in between. This isn’t a mandatory feature, config file would be enough.
There is a good presentation and explanation of efi/grub situation in the first link in my original post.
Not all x86_64 is EFI. By “one class of machine”, I mean just that. If we supported another bootloader, we’d still have to support grub, increasing the complexity of things a fair bit to make sure both boot paths still work for everyone. While this might simplify things for people installing custom kernels, it would do exactly the opposite for our official kernel images.
45% of Ubuntu installs are on UEFI. I’m not sure if installing in legacy mode counts as UEFI, so it may be much more. And for the last 5 years you can’t even by a PC without UEFI. Installing an official kernel with systemd-boot is simpler too, because instead of running update-grub you will just add a text file with path to the kernel and a label. A script for doing this is small, examples are on github, and it doesn’t require much support.
1 Like
It would also then include none of the designed Ubuntu boot experience that we have today on grub, including displaying a menu on failed boot.
This is just not something we are going to invest in integrating into the distribution. It might reduce complexity for you as someone who has opted in to using systemd-boot, but for Ubuntu as a distribution it only adds complexity and maintenance costs and results in an inconsistent experience.
2 Likes
It brings user-visible improvements, namely faster boot. Moving to systemd-boot shaves of about 4 seconds from my boot (now systemd-analyze reports under one second spend in bootloader - grub2 takes over 4 seconds). Wouldn’t you reconsider?
And what is with all the user-visible deteriorations?
Why should the EFI-System-Partition (ESP) be abused as /boot partition? Almost every operating system installed in UEFI mode is using the ESP as the place for the bootloader and is not installing the kernel (and family photos) on it.
Having the kernel and initramfs et cetera on the ESP leads to another problem: The size of the ESP may or may be not big enough. There are a lot of systems, which have a 100 MB ESP partition. And using the ESP only for bootloaders, 100 MB are more than enough. Should the installer abort, because it does not make any sense to install or should the installer increase the size of the ESP? And if yes, how should the installer increase it? Or is the systemd-boot option only displayed under certain circumstances?
And even if the ESP is big enough during the installation, there are always the famous kernel collectors, having dozens of old kernels in the system.
Using the ESP as /boot means, that it is no longer possible to have full disk encryption, because the ESP cannot be encrypted. The unencrypted initramfs may contain sensitive information such as LUKS keys. (To be fair, Ubiquity does not support FDE yet, but could it support in the next few years)
As far as I understand it, systemd-boot is using the $ESP\loader\loader.conf file for the configuration. Every time, a system is installing systemd-boot, it will overwrite the configuration? And what happens, if Linux A has kernel package 5.8.0.34.39 and installs vmlinuz-5.8.0-34-generic and Linux B has kernel package 5.8.0.34.112 and installs vmlinuz-5.8.0-34-generic?
And how does systemd-boot work with systems installed in BIOS mode? Although there is not a lot of hardware using a real BIOS nowadays, there are a lot of systems with UEFI and CSM enabled. And there are a lot of virtual machines, which are emulating a BIOS.
1 Like
For all these, there could be Grub.
Though regarding the kernels, why could not just one be kept in there?
Though, actually, given all these problems, I would be happy if I could just do apt install systemd-boot (or do a dpkg-reconfigure thing) post-install and the system would switch from Grub to systemd-boot for me.
Though from reading this - https://manpages.debian.org/testing/systemd/systemd-boot.7.en.html
It supports having Kernels outside of the ESP (on so called “extended Boot Loader Partition”), which would solve most of the issues you raised.cd
Different kernels can have different configs (under ESP/loader/entries/*.conf )
Details are here: https://systemd.io/BOOT_LOADER_SPECIFICATION/
I think the only issue remaining is Legacy BIOS mode, which is not supported. That is why it should be an option and not a default.
Having only one kernel can lead to an unbootable system.
Which binary is missing in your Ubuntu installation? And how were you able to boot faster with systemd-boot without knowing how to install systemd-boot on Ubuntu?
Yes, if /boot is somewhere else, it would solve most of the mentioned problems.
And all share the same configuration file under $ESP\loader\loader.conf.
The issue wasn’t with multiple kernels, but hiding older installed versions of them while system boots successfully and showing them on failure. And it is already supported by systemd.
As for the installation of systemd. No binary was missing but I had to manually edit files in /boot and add some manual hooks to /etc/kernel/postinst.d and such. No fun stuff. Few people will replicate it and those who do not will all suffer from much slower boot (which is something one can live with, of course, but it is clearly a disadvantage).
I think this should cover your concerns:
- On disks with an MBR partition table:
- If the OS is installed on a disk with an MBR partition table, and a partition with the type id of 0xEA already exists it should be used as
$BOOT.- Otherwise, if the OS is installed on a disk with an MBR partition table, a new partition with type id of 0xEA shall be created, of a suitable size (let’s say 500MB), and it should be used as
$BOOT.- On disks with GPT (GUID Partition Table)
- If the OS is installed on a disk with GPT, and an Extended Boot Loader Partition or XBOOTLDR partition for short, i.e. a partition with GPT type GUID of
bc13c2ff-59e6-4262-a352-b275fd6f7172, already exists, it should be used as$BOOT.- Otherwise, if the OS is installed on a disk with GPT, and an EFI System Partition or ESP for short, i.e. a partition with GPT type UID of
c12a7328-f81f-11d2-ba4b-00a0c93ec93b) already exists and is large enough (let’s say 250MB) and otherwise qualifies, it should be used as$BOOT.- Otherwise, if the OS is installed on a disk with GPT, and if the ESP partition already exists but is too small, a new suitably sized (let’s say 500MB) XBOOTLDR partition shall be created and used as
$BOOT.- Otherwise, if the OS is installed on a disk with GPT, and no ESP partition exists yet, a new suitably sized (let’s say 500MB) ESP should be created and used as
$BOOT.
As for the shared configuration file,
- I do not think it needs to exist
- It specifies machine-wide settings, not OS-settings, see: https://www.freedesktop.org/software/systemd/man/loader.conf.html
Sounds like you could create a PPA and test it with different setups.
No idea how to make a PPA, actually. I came across this thread when I was researching how to use systemd-boot and I just thought I would mention its benefits. (which 900% increase in speed is, I think)
Didn’t Pop!_OS introduce as part of the installer a way of installing grub for legacy computers and systemd-boot for efi boards , couldn’t that be used?
2 Likes