Ease of maintenance by the same group of people who already work in that repo? Reuse of shared, low-level components residing in the systemd repository?
It's similar to why drivers are preferably merged upstream into the linux kernel source tree. Doing so ensures they continue to work as the kernel evolves, it also makes them more likely to get maintained in the long-term in general.
I haven't audited systemd-boot specifically but just look at bootctl.c's "" includes [0], those come from the systemd source tree, and very little is in the src/boot/ subdir.
Consider the fact that the project is all relatively low-level C code without any external bloaty dependency like glib bringing simple data structures like linked lists and hash tables to the party. There's heaps of useful stuff in-tree, and its being maintained as a whole and kept in sync, in a similar style to the kernel.
Poke around [1] [2] [3] for some idea of what's there.
Whatever magic is powering the ability to just run ``systemctl kexec`` and have it automatically reboot into the same kernel you selected at boot without going through UEFI again.
kexec works fine if you invoke it directly and tell it what kernel+initrd to use, regardless of bootloader; if anything, I'd consider it a failing that systemd can't manage to control a kexec without controlling the bootloader as well
Do you mean the component that actually implements the boot loader? I'm not sure if there's any sharing there at this time, it's probably largely as-is from the gummiboot import. This isn't an area I've worked on personally, but you can poke around if you want:
> Ease of maintenance by the same group of people who already work in that repo? Reuse of shared, low-level components residing in the systemd repository?
I think this is the exact reason why the people who hate it, hate it.
You put everything together like that and it encourages mutual interdependencies. It becomes an ordeal to make a thing to replace a part of systemd that isn't in that repository because they could break any interface at any time and easily update their own version of it everywhere while breaking yours.
Worse, even if your version of a thing systemd does doesn't depend on other parts of systemd, other parts of systemd start to depend on the systemd version of what your program does, which pushes people to use it instead of yours. It somehow feels like something old school Microsoft would do.
> It's similar to why drivers are preferably merged upstream into the linux kernel source tree. Doing so ensures they continue to work as the kernel evolves, it also makes them more likely to get maintained in the long-term in general.
That's because drivers inherently are tightly coupled to kernel interfaces. And drivers are special because hardware never really ceases to exist. The drivers for some 100Mbps network card from 1997 from a defunct vendor still work, and you want them to still work, but the only changes that will ever get made to them is updating them to use newer kernel interfaces as they change.
In other words, you don't have a third party who is going to release a newer version anyway and can use that as an opportunity to switch to the newer interfaces. The only reason to modify most of the existing legacy drivers is to switch to newer kernel interfaces, which has to be done for most all of them if you're ever going to remove the old interfaces, which gives the kernel developers the largest incentive to be the ones to do it. It's also uncommon to have multiple independent third party open source drivers for the same piece of hardware, so having more-and-better competing third party driver implementations was not a thing that was going to happen in the alternative.
Naturally this doesn't apply to most other system components, which benefit from being modular and having clean stable interfaces between them and the opportunity for third party developers to establish a new implementation if the existing ones don't suit them.
So you're saying I can pull an SSD with a working Windows 10 installation from another computer and plug it into a GNU/Linux system running systemd-boot and it will boot Windows 10? (Ignoring any potential driver issues that may arise from the difference in hardware and [most likely] violating the Microsoft EULA)
I am not sure why you would want to start with an install of windows from a different machine, but yes booting to a different hard drive has been supported for a long time.
You just chainload to the windows boot manager on the other disk, I think that if you point bootctl at the new disk it will even add an appropriate entry for you automatically.
Clearly this is a change of pace, though. While adding a bootloader to your init/RPC message bus/syslog/cron-system might add a bit of bloat to that lean (modular) megolith - this here is presumably more about adding init into your bootloader - which probably will add quite a bit of bloat and unwanted tight coupling...
I liked the old grub, personally; it, too, felt like a system that you could actually wrap your head around. While grub2 is probably more capable and better supported in terms of hooking into the system (since it's meant to regenerate the config out of scripts every time it needs to be configured), I personally moved on to syslinux, which is very much like the old grub was, albeit more capable.
I’m surprised that most people even bother with bootloaders like grub... On all the machines I’ve used recently, the UEFI boot manager works fine, and you can just use a kernel with an EFI stub and initramfs built in. It’s obviously a bit much for most users, but you’d think Linux distros could just package it all up.
It's faster, and accidentally hitting a hotkey for grub or whatever on boot is just one more problem. These are both material advantages, for a certain cohort.
"the user" varies from highly technical people like you or i to low income people with laptops wiped to install ubuntu by foundations that can't afford windows licenses.
And, if I'm dual booting, I'm probably confident enough to configure UEFI to support dual booting.
grub provides a nice interface for adjusting kernel parameters before booting, which is essential for some installs on twitchy hardware. I don't know of a way to do this in the UEFI boot manager.
I've found it even easier to manage kernel parameters and boot entries in systemd-boot. You can just create another boot entry by making a copy of a text file, and changing the `title` line of the file. Grub is much more complex to manage. systemd-boot entries are very simple text files, so editing kernel parameters is far easier than grub.
What's the recovery situation? Say my machine is unbootable and I need to tweak the kernel commandline or something to get things working again? Can I do that from the systemd-boot menu like I can with grub?
You don't even need twitchy hardware. Ubuntu goes into an unescapable X server restart loop if you are out of space on the root partition when booting, and has no other obvious remedy than booting to rescue mode.
I consider myself an advanced user. I used to play with refitsomething loader to boot win7/10 on an older imac, I still have shivers about the dreaded LI... of my youth so I tend to stick to whatever Ubuntu installs and then make sure I can boot stea... windows easily.
Anything else is madness I don't need nor want to fiddle with.
FWIW: systemd-boot is just a generic EFI bootloader, originally it was called gummiboot before being merged into the systemd project. Like many things in systemd, it has no direct relation to the init daemon. It does not have an enormous featureset like GRUB, but it is fast and gets out of the way. It has been my preferred bootloader since before it was part of systemd.
As for why one would prefer this over just using EFI itself to manage boot entries, well, that comes down to sensibility, but traditionally Ubuntu has provided a UI at boot for selecting OSes so it would be weird to get rid of it now. I also currently use NixOS where you can select generations via the boot menu, which would be cumbersome at best if you try to implement it with EFI directly.
Years ago, NixOS was my first gummiboot experience. I noticed systemd-boot was being used now, but I did not realize it was the same thing under the hood. Thanks for that information.
> As for why one would prefer this over just using EFI itself to manage boot entries
If you dual boot then you can't effectively use the EFI. Doing so would involve spamming a Fx key to go into the bios and then going through all the menu options to choose a manual boot override.
Instead I have the EFI configured to use systemd-boot as the default, and systemd-boot presents a menu with the OS options, with Linux as the default choice. This still involves spamming the down arrow to select Windows before the auto-boot-default-choice timeout (configurable) finished, but is a lot easier than using the EFI.
The nice thing about systemd-boot is that is is simple, lightweight, fast, and easy to configure. The first time I installed it in Arch it took about 5 minutes to get it working with entries for linux, linux-lts, and linux-zen kernels, with Windows being autodetected at boot time.
However, if you are booted into an OS, then using the EFI to configure boot is much easier. On Linux you can do `sudo efibootmgr --bootnext 0001` to boot EFI entry 0001 only on the next boot (list entries with just `efibootmgr`; in my case 0001 was Windows). And on Windows there's a "WinToLinux" program on GitHub which will graphically let you set a oneshot EFI boot override to reboot into Windows instead of systemd-boot.
most modern firmwares ("go into the bios", ugh) provide a key to directly enter the boot option selection screen. this is one of the core functions of the firmware, and although I have pretty low expectations of AMI/Insyde/Phoenix, I'm pretty sure they can at least get that part right.
Yes but at least on my new high end Lenovo, it’s not ergonomic. You don’t see a menu or a prompt, you just need to hit the magic key during a short window.
Then you need a password, because I don’t want to allow booting usb thumbdrives.
I don't think many people care what boot loader they have or what firmware they run. If you want something that always works, grub is a good standard to stick to. For everyone else there is the many options like this gummiboot integration, bare EFI, LILO, NTLDR, SYSLINUX and all the others.
Ironically, most linux installs are not using any of those because most installs aren't desktop installs; clouds usually don't have an emulated EFI stack at all, and embedded uses things like u-boot.
While it has nothing directly do do with init, there is a lot of cooperation that goes on between systemd and systemd-boot, that does not work with other grub for example.
You can from systemd control the reboot and tell it what to reboot and stuff like that. Lennards talks about this are quite informative.
The other advantage it has, is that it uses a simple single file per OS based standard. I would love if GRUB adopted this model too.
I was consolidating a lot of backup media over the winter break a few months back and I actually saw some "XF86Config.good" files that I saved from the early 1990s...
Been using systemd-boot on Arch Linux for a couple of years now, works flawlessly, minimal tinkering needed. It's just set and forget. Surprised GRUB is still being shipped in noob-friendly distros like Ubuntu, you'd think they'd try to make it as simple as possible
But to be fair, most of these systemd-[something] (sub)projects are part of "systemd", but not the systemd init system, which are different, apparently.
system76's pop_os 18.04 (based on ubuntu18.04) uses systemd-boot.
It works flawlessly except when ubuntu automatically updates from the ppa and then reinstalls grub and then you try to manually debug / fix it and get caught in a boot loop and have to reinstall the os... yeah...
I use Syslinux (Extlinux) even with UEFI BIOS. I don't care about UEFI, dual boot or secure boot. I just want to get from BIOS to Linux as easily is possible. For disks with up to 3 partitions with single operating system there's no need to invoke EFI/GPT. You just have to enable Comaptibility Support Modules in BIOS to enable boot from MBR.
> The boot manager optionally reads a random seed from the ESP partition, combines it with a 'system token' stored in a persistent EFI variable and derives a random seed to use
by the OS as entropy pool initializaton, providing a full entropy pool during early boot.
Wow that's very nice! I may give systemd-boot another go due to this!
85 comments
[ 2.2 ms ] story [ 175 ms ] threadFor normal people, that is its greatest feature.
It's similar to why drivers are preferably merged upstream into the linux kernel source tree. Doing so ensures they continue to work as the kernel evolves, it also makes them more likely to get maintained in the long-term in general.
Consider the fact that the project is all relatively low-level C code without any external bloaty dependency like glib bringing simple data structures like linked lists and hash tables to the party. There's heaps of useful stuff in-tree, and its being maintained as a whole and kept in sync, in a similar style to the kernel.
Poke around [1] [2] [3] for some idea of what's there.
[0] https://github.com/systemd/systemd/blob/master/src/boot/boot...
[1] https://github.com/systemd/systemd/tree/master/src/basic
[2] https://github.com/systemd/systemd/tree/master/src/libsystem...
[3] https://github.com/systemd/systemd/tree/master/src/shared
Edit:
Do you mean the component that actually implements the boot loader? I'm not sure if there's any sharing there at this time, it's probably largely as-is from the gummiboot import. This isn't an area I've worked on personally, but you can poke around if you want:
https://github.com/systemd/systemd/tree/master/src/boot/efi
I think this is the exact reason why the people who hate it, hate it.
You put everything together like that and it encourages mutual interdependencies. It becomes an ordeal to make a thing to replace a part of systemd that isn't in that repository because they could break any interface at any time and easily update their own version of it everywhere while breaking yours.
Worse, even if your version of a thing systemd does doesn't depend on other parts of systemd, other parts of systemd start to depend on the systemd version of what your program does, which pushes people to use it instead of yours. It somehow feels like something old school Microsoft would do.
> It's similar to why drivers are preferably merged upstream into the linux kernel source tree. Doing so ensures they continue to work as the kernel evolves, it also makes them more likely to get maintained in the long-term in general.
That's because drivers inherently are tightly coupled to kernel interfaces. And drivers are special because hardware never really ceases to exist. The drivers for some 100Mbps network card from 1997 from a defunct vendor still work, and you want them to still work, but the only changes that will ever get made to them is updating them to use newer kernel interfaces as they change.
In other words, you don't have a third party who is going to release a newer version anyway and can use that as an opportunity to switch to the newer interfaces. The only reason to modify most of the existing legacy drivers is to switch to newer kernel interfaces, which has to be done for most all of them if you're ever going to remove the old interfaces, which gives the kernel developers the largest incentive to be the ones to do it. It's also uncommon to have multiple independent third party open source drivers for the same piece of hardware, so having more-and-better competing third party driver implementations was not a thing that was going to happen in the alternative.
Naturally this doesn't apply to most other system components, which benefit from being modular and having clean stable interfaces between them and the opportunity for third party developers to establish a new implementation if the existing ones don't suit them.
You just chainload to the windows boot manager on the other disk, I think that if you point bootctl at the new disk it will even add an appropriate entry for you automatically.
Isn't this impossible with bitlocker?
Hm, is it still April 1st?
It's a standalone program. I'm looking forward for systemd-x11. I think in the future we will get rid of GNU/Linux. We will have systemd-linux.
The first Linux distro I used still had LILO when it was being phased out. I felt that I mastered LILO in a very short time.
I've never had that feeling with grub, which is a small OS with slightly chaotic config files spread out over many directories.
I found it easier to set up a direct EFIstub boot than reinstall grub via live CD when my BIOS somehow had broken the Debian install.
It's not a very nice dual booting UI, like a menu with a timeout. And no way to set passwords on certain items or enter kernel boot parameters.
It really depends who "the user" is.
It's faster, and accidentally hitting a hotkey for grub or whatever on boot is just one more problem. These are both material advantages, for a certain cohort.
"the user" varies from highly technical people like you or i to low income people with laptops wiped to install ubuntu by foundations that can't afford windows licenses.
And, if I'm dual booting, I'm probably confident enough to configure UEFI to support dual booting.
This doesn't really fit with the oft-repeated advice to windows user looking to try out linux that you can start with a dual boot.
https://forums.gentoo.org/viewtopic-p-8439822.html?sid=b07b8...
So are GRUB 2 configuration files but for some reason a "framework" was built around it to generate the final configuration file from parts.
https://wiki.archlinux.org/index.php/Systemd-boot#Keys_insid...
(Reported as a bug, the response was "your laptop manufacturer needs to fix its firmware". Ugh).
Anything else is madness I don't need nor want to fiddle with.
As for why one would prefer this over just using EFI itself to manage boot entries, well, that comes down to sensibility, but traditionally Ubuntu has provided a UI at boot for selecting OSes so it would be weird to get rid of it now. I also currently use NixOS where you can select generations via the boot menu, which would be cumbersome at best if you try to implement it with EFI directly.
If you dual boot then you can't effectively use the EFI. Doing so would involve spamming a Fx key to go into the bios and then going through all the menu options to choose a manual boot override.
Instead I have the EFI configured to use systemd-boot as the default, and systemd-boot presents a menu with the OS options, with Linux as the default choice. This still involves spamming the down arrow to select Windows before the auto-boot-default-choice timeout (configurable) finished, but is a lot easier than using the EFI.
The nice thing about systemd-boot is that is is simple, lightweight, fast, and easy to configure. The first time I installed it in Arch it took about 5 minutes to get it working with entries for linux, linux-lts, and linux-zen kernels, with Windows being autodetected at boot time.
However, if you are booted into an OS, then using the EFI to configure boot is much easier. On Linux you can do `sudo efibootmgr --bootnext 0001` to boot EFI entry 0001 only on the next boot (list entries with just `efibootmgr`; in my case 0001 was Windows). And on Windows there's a "WinToLinux" program on GitHub which will graphically let you set a oneshot EFI boot override to reboot into Windows instead of systemd-boot.
Then you need a password, because I don’t want to allow booting usb thumbdrives.
Ironically, most linux installs are not using any of those because most installs aren't desktop installs; clouds usually don't have an emulated EFI stack at all, and embedded uses things like u-boot.
You can from systemd control the reboot and tell it what to reboot and stuff like that. Lennards talks about this are quite informative.
The other advantage it has, is that it uses a simple single file per OS based standard. I would love if GRUB adopted this model too.
Highly recommended.
The same way that a good case of food poisoning brings back memories of past travel abroad.
It's actually quite amazing how far we've come.
But this is just nostalgia, not about missing.
it's not all roses, even now.
But to be fair, most of these systemd-[something] (sub)projects are part of "systemd", but not the systemd init system, which are different, apparently.
* UUIDs instead of process IDs
* a "systemctl top"
* closer integration with GNOME Terminal, in particular its PTY helper
* several PAM tweaks that, taken together, I suspect will eventually lead to a PAM replacement
It works flawlessly except when ubuntu automatically updates from the ppa and then reinstalls grub and then you try to manually debug / fix it and get caught in a boot loop and have to reinstall the os... yeah...
They should both die in a hot fire.
Wow that's very nice! I may give systemd-boot another go due to this!