Replace GRUB2 with systemd-boot on Ubuntu 18.04 (2018)
blobfolio.com
blobfolio.com
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.
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.
Highly recommended.
Wow that's very nice! I may give systemd-boot another go due to this!
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...
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.
They should both die in a hot fire.
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
For 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:
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.