I replaced grub with systemd-boot
blog.bofh.it
blog.bofh.it
I also have a Python script for installing Ubuntu on native ZFS w/ encryption and using rEFInd. You can use this script from a live boot environment. If nothing else, can easily review for how to do it manually.
- https://www.rodsbooks.com/refind/
Also... It is very customizable with good a 100% graphic UI.
As an alternative to ventoy, can I use refind on a usb flash drive with iso images?
More a Dell thing than refined I believe.
I just have to remember to delete the UKIs manually when I uninstall the corresponding old kernel package, otherwise the EFI partition would fill up eventually. If my distro ever switches to UKIs by default then the postuninstall script would handle that automatically.
I noted recently that it also sees systemd-boot installations and will boot from those, if desired (in my case it was a fresh installation of Pop OS, which uses systemd-boot by default).
For me, it's unambiguously better (meaning easier, with no extra periodic steps required to maintain my ability to boot whatever bootable thing I want), but I am curious about what scenarios would make one want to use systemd-boot (or grub) instead.
I have Linux VMs which boots in ~2s (to ssh login; ~700ms to userspace). I use systemd-boot because it has nicer integration with my distro of choice than bare EFI stub, and it adds very minimal overhead in boot time.
Use linux-image-cloud; use a modern hypervisor with no legacy devices (only virtio etc); use tiny-initramfs; mask systemd-networkd-wait-online.service; add cryptomgr.notests noreplace-smp to kernel command line.
I think that's all, and use a moderately fast CPU (i7-8700K which is already 5 years old).
When you say modern hypervisor, do you mean, not KVM? How do you get around the UEFI/BIOS post time which is usually a few seconds by itself?
I'm talking about the time taken by OMVF/SeaBIOS or whatever equivalent in the VM; which is why I asked about the type of VM/Hypervisor because that might not apply.
Does anyone know why anyone would choose systemd-boot over something like efistub?
- the same disk is now impossible/harder to boot in another system/mainboard.
- no more choice between different kernels in case the newest one broke something
- to change the cmdline with kenel parameters you now need to run efibootmgr
Still, the quick boot can be worth it :-)
Ah, I see. That's a deal breaker for me. Switching to an older kernel has saved me many times, usually when I completely mess up my nvidia drivers.
It's the most simple boot setup I've ever used, and it doesn't have the mentioned issues:
> the same disk is now impossible/harder to boot in another system/mainboard.
Just go and select your UKI in the EFI boot-manger. Works on every modern system OOTB.
> no more choice between different kernels in case the newest one broke something
You can have more than one UKI around. You can, for example, have even one with a whole recovery system included in the initrd part!
> to change the cmdline with kenel parameters you now need to run efibootmgr
You only need to recreate the UKI with an updated command line. No change to the boot-manager needed.
Also a UKI has a better security story compared to all other options. You have only one signed EFI binary. No need for complex setups that validate the initrd after the fact, as everything is included in the UKI and signed as a whole.
Have this setup on my Debian box but used actually the superior documentation form the Arch wiki to get there.
I just recently switched all of my Arch boxes to this setup. The first was so I could enable Secure Boot on that machine, the rest just because it felt so much simpler and cleaner than Grub. Actually, the last one just stopped booting entirely with Grub but worked just fine with UKI.
> You can have more than one UKI around. You can, for example, have even one with a whole recovery system included in the initrd part!
Same! I was considering writing up how to do this for the Arch wiki since it’s handy and I couldn’t find any complete guides.
Lots of people dual boot without manually going through their UEFI. It's important enough that I can see why many distros wouldn't make it default.
Most devices out there will always boot the first entry (or BootNext) no questions asked. Some devices may allow reordering boot loader entries in their setup program. Almost no devices will actually a) pause booting whenever there are multiple valid entries b) show you a menu where you can choose one of alternatives c) respect your timeout value, choosing the first boot entry if the timeout expires. Incidentally these 3 happen to be the basic properties of what people usually demand from a boot manager.
I've only ever got those white in a blue screen firmwares.
It's not all flames of course. But the design of the firmware UI certainly got really flamboyant when UEFI hit the scene while quality of implementation really suffered.
It's gotten somewhat better, but now it's getting hard to buy non-enterprise hardware without over 9000 RGB LEDs on there. Sigh. At least the LEDs don't bother my bootloader.
> UEFI allows the consolidation of boot menus from the OS loader and platform firmware into a single platform firmware menu. These platform firmware menus will allow the selection of any UEFI OS loader from any partition on any boot medium that is supported by UEFI boot services. An UEFI OS loader can support multiple options that can appear on the user interface. It is also possible to include legacy boot options, such as booting from the A: or C: drive in the platform firmware boot menus.
EDIT: Anyway, I'd probably only ever rely on an external USB stick, but I don't know how that interacts with Secure Boot, tbh. I use Ventoy + loads of images of popular distros. Can fit quite a few distros on a 128 GiB USB stick! :D
Of course, the firmware may be configured to refuse to boot a USB drive as a matter of policy.
There are hardware solutions to that problem, but most regular PCs don't come with a remotely-accessible boot menu.
This was an MSI motherboard in case anyone's wondering.
For trivial setups (one kernel that keeps getting updated in-place), a boot manager is not required. For more sophisticated setups (version in kernel file name or Nix style system versions or whatever), a boot manager is very convenient.
Personally the only reason I have it in the loop is it makes it so much easier to switch the an lts kernel if say... zfs has failed to build on a kernel update and I didn't notice (not that THAT would ever happen). Could use multiple EFI entries for that, but systemd-boot is simpler.
Is this not exactly what GRUB is, on UEFI systems?
Simply put: It can boot Linux on EFI without EFISTUB.
With an UKI your whole boot setup is a self-contained and portable EFI executable.
I still use GRUB because IIRC my Gigabyte motherboard kept forgetting entries and/or associated settings.
Optimizing a few seconds off of something you seldom do isn't that useful. (Not that I haven't been guilty of that, again and again and again and...)
Disclaimer: I don't meet the 8 hour goal and the unattended boot of my office machine setup has been incomplete for 5 years...
Edit: We do also nightly builds, but they take between 5 minutes and less than 3 hours.
Actually it would be interesting to calculate whether frequent reboots don't use more energy in sum than putting the machine into sleep. Does anybody have numbers on that?
Discaimer: Have not worked with mobile phones for 10+ years.
Some kind of ideas are stupid and we must go back to reasoning about real problems, not fictional problems.
A computer that stays in sleep most of the times is the last problem we have in modern societies.
Meanwhile people set their home temperature at 30C in winter (when it's 10-15C outside) and the AC at 16C during summer (when it's 28-30C outside)
maybe just don't?
I want to enter a sane booting environment as soon as possible (gummiboot, refind, grub). Also why not? Its basically free and In my experience doesnt really complicate secure boot.
Then I have some distro-supplied kernels, with initram, modules, non-standard parameters AND grub, just for those times when I need something exotic. I have to stop the normal boot with Esc and select the second boot option from the UEFI menu, that points to grub. It's clumsy and slow but I just need it once in a blue moon.
The persistence of GRUB for x86-64 systems is both fascinating and irritating; the original driver for users paying the price of the complexity of GRUB was the idea that it would bring consistency across architectures and be an overall reduction in complexity for distro maintainers. Instead the bootloaders for non-x86 architectures are generally not-GRUB (zipl, various ARM options which are sometimes SoC specific, and so on), while x86 users are stuck with the byzantine complexity of GRUB.
You have so many different hardware vendors, but one common boot loader. Who can you rely on working every time for every vendor?
Also I use grub to select old deploys in Fedora Silverblue.
I'd love to use systemd-boot though.
It took me a long time to figure out what I did to change defaults by accident and how it stayed changed.
Jumped the gun and typed my LUKS unlock password a moment too soon.
https://wiki.archlinux.org/title/systemd-boot https://www.reddit.com/r/archlinux/comments/mxzfox/systemdbo... https://support.system76.com/articles/bootloader/
Pop!OS uses it on anything with a UEFI secure boot setup which was something of a surprise to me since I didn't notice anything except that I don't see the GRUB menu at boot time, and to dual boot I have to drop to the bios or use the Windows 11 restart bollocks to get back to Pop!OS
Although there is a reddit comment that I think was quite apropos: LILO got too complex so we got GRUB, now GRUB is a beast and we have systemd-boot. Not sure what other advantages it might have over GRUB other than perhaps it plays nicer with Windows/UEFI. I still prefer GRUB on my other machines where I'm still allowed to use it.
(But yes, booting remains a pain)
https://en.wikipedia.org/wiki/Das_U-Boot + https://en.wikipedia.org/wiki/Devicetree is an alternative, but it's a massive pain because you lose PnP.
And I'm still wondering about that and how text-mode/console output works.
I get it when I'm attached via a serial port, but... how many console rendering implementations for VGA output are on my system?
Load the first sector of the chosen boot device into memory at 7c00h, and jump to it.
That's how all PCs booted before the monstrosity known as UEFI came into existence.
Yeah, that's the literal handoff, but a LOT of things need to happen before that.
Even before UEFI, you still have to deal with ACPI and friends.
After CPU setup, memory training, dealing with ACPI shit, loading (and executing! [1]) Option ROM, and others?
There are things called "BIOS" doing this before UEFI came into existence.
Why can't we get rid of MMX instructions?
Regarding modern PCs: Even I think UEFI is in large parts over-engineered crap it made at least booting simpler and much more sane.
That is too say, the signed grub binary can be used to load literally anything. It can even chain load into another non-signed modified grub.
On the other hand, the crypt setup route ensures that you bios, grub, TPM, and many other measurements are correct.
Look at table one here: https://www.freedesktop.org/software/systemd/man/systemd-cry...
One of those measurements is secure boot, but I cannot for the life me figure out what value it is adding.
If you don't have secure boot enabled, someone could boot a malicious image that has access to the TPM's API before it's disabled, and therefore gain access to your storage. They would still need to get that image on your computer of course. As you say, though, the vast majority of software running once the OS is booted isn't necessarily secure.
Secure boot alone doesn't really help much for foiling bad actors with physical access, since you can just go into the bios settings and disable it. That's why bios typically have their own password protection. On some "embedded" computers, it's practically impossible to turn secure boot once it's been enabled; there's literal fuses inside the chip that get blown.
It also isn't something that any software can use to just spit out the secrets it stores. The whole point of the TPM is that it will only release information if the measurements of the system match. IE, if I chainload grub->window that will cause a different measurement then it the system just booted windows.
But again, secure boot will only run signed images, but a signed grub can run anything. Also grub and it's configuration must be on an unencrypted partition. You can easily tamper with its config to load whatever you want.
No, it implements the verifier API which needs to be disabled for this to be true. This should not be the case for distributions utilizing the shim+grub setup (Ubuntu/SUSE/Fedora/Debian/etc)
I think the critical point is that the measurements are made by the CPU, not the TPM. Malicious code running on the CPU can tell the TPM whatever it wants to tell it. The TPM is notionally just a peripheral hanging off a low speed serial bus. All the TPU can do is watch the sequence of measurements being fed to it, and decide whether or not it looks suspicious. The idea is that everything is chained off of an initial known to be trustworthy state. The initial known state is provided by boot-up, where the first code to run comes from ROM or an EEPROM or flash chip. Secure boot is the mechanism by which that boot-up code can load more code off a storage device and authenticate it. Secure boot is literally what keeps the system secure while booting, before the TPM is configured.
Your point about grub being insecure in some ways is likely true. It's been around a long time, and existed before secure boot. The grub image itself being on an unencrypted partition doesn't matter, though, because it is signed; secure boot won't run it if it isn't authentic. I don't think the configuration matters much either. Grub can be configured to give the TPM a measurement of what it's actually loading, i.e. the kernel and initrd and boot options. The TPM can then refuse to give up its secrets if that measurement doesn't match what it expects.
Booting is complicated, and when you're mucking around with stuff like grub, it's easy to accidently break the chain without realizing it. There's a reason why corporate IT tends to prefer Mac, Chrome OS, or Windows based computers; it's easier to say that the system is properly secured through boot until the corporate spyware is running. As a practical matter, though, a broken link or two doesn't mean that the whole chain is useless. Stuff like secure boot, TPM, etc. all decrease the attack surface. You shouldn't store nuclear detonation codes on a computer you know isn't perfectly secured, but it's probably fine for your tax return from 2015 and meme collection; no one's going to bother individually targeting you.
In such a case you can just disable it as it doesn't provide anything than additional hassle.
GCP looks like it does UEFI too. And Azure Gen2 instances use UEFI too.
It was a failed experiment overall, too much recompiling even for me, however one thing I did get out of it was that I discovered I didn't need a bootloader.
You can boot Linux as an EFI executable.
Granted, you cannot pass any dynamic boot arguments to it, and initramfs is out of the window it seems (or I just never got it working), but it was remarkably easy to add the commandline options I wanted into the kernel at compile time and just call it as an executable automatically from the EFI BIOS of my motherboard.
Mainly because I have an Optiplex micro hidden behind my monitor, where I use the keyboard to power on. Sometimes accidental power-ons happen so it's good to have that menu entry.
The UKI will contain kernel + initramfs to be able to mount your encrypted root partition as `/`, using regular cryptsetup, not the special low-perf code used by grub.
And to be clear, this is how UEFI boot would work even if you didn't have systemd-boot and had your firmware directly boot the UKI.
Because?
Why?
It's actually a whole operating system by now!
Only a very shitty one, and in comparison not well maintained…
Why?
If I understand correctly its cryptsetup luksChangeKey DEVICE --iter-time <time in ms>
Consult your manual and backup before making any changes to encrypted devices lest tragedy ensue.
2 things of note.
- Luks slots are tried in succession adding a second faster slot after a slow slot will be slower because it will try the slow one first fail then unlock with the fast slot.
- You should back up your luks header because a small amount of corruption in the right place can make the entire encrypted volume unrecoverable
I don't think there would be anything in your kernel or bootloader that needs to be confidential!
Would be the ultimate base OS.
But it's not so easy. I actually looked into all the dependencies of a Linux system and it turns out to be an extremely entangled monolith at the core. Everything depends on everything. So you actually can't have "just a kernel and systemd as 'user-land'".
Any resources for this ? Most books I've read/seen are either about Linux kernel internals or using userspace Linux. I'd like to know more about what actually goes into making a complete usable distro.
NOR flash guaranteed for a minimum of 100,000 complete rewrites of every cell, with no flash translation layer gimmickery. The downside is that it is very expensive, which is why a few dozen megabytes of NOR flash costs as much as many gigabytes of MLC NAND.
Typical NOR flash chip; "Minimum 100,000 Program/Erase Cycles":
https://www.gigadevice.com/flash-memory/gd25b127d/
https://www.kingston.com/en/blog/pc-performance/difference-between-slc-mlc-tlc-3d-nand