[HN Gopher] I replaced grub with systemd-boot
___________________________________________________________________
I replaced grub with systemd-boot
Author : pabs3
Score : 63 points
Date : 2023-02-16 09:59 UTC (13 hours ago)
(HTM) web link (blog.bofh.it)
(TXT) w3m dump (blog.bofh.it)
| smackeyacky wrote:
| For the lazy, here's a couple of links.
|
| 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.
| candiddevmike wrote:
| I wish systemd-boot had implemented a BIOS shim somehow, since
| we're still stuck with grub for most cloud providers and other
| non-UEFI capable setups. Basically something that BIOS boots into
| a UEFI loader-esque so it uses the same path for everything,
| similar to how ARM can "UEFI boot".
| secondcoming wrote:
| What difference does it make what boot loader cloud providers
| use?
| paulfurtado wrote:
| FWIW on AWS, all nitro instance types can boot as UEFI if the
| AMI has itself set to use UEFI and all arm64 instances only
| support UEFI. So if you stick to modern instance types, you can
| happily use UEFI in AWS.
|
| GCP looks like it does UEFI too. And Azure Gen2 instances use
| UEFI too.
| andrewstuart wrote:
| I find booting, grud, uefi and related technologies are one of
| the most complex and hard to make sense of parts of modern
| systems.
| yjftsjthsd-h wrote:
| I think UEFI actually helps; I do _not_ miss having to manually
| overwrite the first sector of my hard drive in order to make
| the bootloader work.
|
| (But yes, booting remains a pain)
| xxpor wrote:
| It's a genuinely complex problem. Booting x86-64 with arbitrary
| hardware attached while maintaining compatibility with boot
| modes from 30+ years ago is quite a feat.
|
| 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.
| aliqot wrote:
| Can you still use LiLo these days on a systemd enabled system?
| boomboomsubban wrote:
| Seems like it. https://wiki.archlinux.org/title/LILO
| klooney wrote:
| Fun fact about systemd-boot, you have to hold down the spacebar
| to get the boot prompt, and it remembers the last boot. So if you
| let your toddler bang on the keyboard while booting, and you're
| boot looping into the BIOS config screen, hold down space at the
| next boot and maybe everything will work out OK.
| MobiusHorizons wrote:
| Years ago on an arch system I would boot directly from UEFI to
| the kernel (using a feature known as EFISTUB[1]) Ever since then
| I have not understood why most distros don't switch to this
| setup. It would seem like removing an entire bootloader from the
| boot sequence would significantly improve boot times, which was
| my experience with that setup at the time.
|
| Does anyone know why anyone would choose systemd-boot over
| something like efistub?
|
| 1: https://wiki.archlinux.org/title/EFISTUB
| demindiro wrote:
| > Ever since then I have not understood why most distros don't
| switch to this setup
|
| I still use GRUB because IIRC my Gigabyte motherboard kept
| forgetting entries and/or associated settings.
| m4lvin wrote:
| EFISTUB can also be done on Debian [1]. I used this for a
| while, but it felt too fragile and inconvenient:
|
| - 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 :-)
|
| [1] https://wiki.debian.org/EFIStub
| candiddevmike wrote:
| systemd-boot presents a boot menu at startup. It can support
| different boot targets defined in files under the EFI
| directory, and it automatically detects Windows UEFI targets.
| boomboomsubban wrote:
| >Does anyone know why anyone would choose systemd-boot over
| something like efistub?
|
| 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.
| CorrectHorseBat wrote:
| One issue I have with it is that I can't snapshot it like the
| rest of my system, but I don't really know if any other
| bootloader solves this issue
| yjftsjthsd-h wrote:
| Well there's https://zfsbootmenu.org/ if you're on ZFS, but
| that's a whole different thing
| teo_zero wrote:
| I have my taylor-made kernel compiled with all and only the
| drivers I need, without an initram and with EFISTUB, directly
| called by the UEFI as its first boot option. That's how I
| manage to boot in 5 seconds.
|
| 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.
| dtgriscom wrote:
| How often do you actually reboot your machine? My office
| compile box is showing 17 days uptime, and that's quite low (I
| think I did an update).
|
| 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...)
| rodgerd wrote:
| > Ever since then I have not understood why most distros don't
| switch to this setup.
|
| 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.
| dezgeg wrote:
| Because having boot menu for stuff like older kernels, recovery
| mode, and access to kernel command line is pretty useful.
| MobiusHorizons wrote:
| Yeah, this was my one concern with the setup. But to be fair,
| it's not a flaw with efistub, it's a flaw with the kernel
| update logic in arch. I manually added an entry for a known
| good configuration which I periodically updated manually, but
| I know of no reason why the kernel update logic couldn't do
| that for me like it does in grub. And as a fallback you can
| install a UEFI shell option to boot into which works in
| emergencies.
| Asmod4n wrote:
| You don't need a boot manager for that except the one built
| into your motherboard.
| AshamedCaptain wrote:
| Most UEFI devices out there don't have any type of boot
| menu.
| Asmod4n wrote:
| Haven't seen one PC or Server mainboard without a UEFI
| boot menu no matter the price range and age. What devices
| are you referring to?
| [deleted]
| aesh2Xa1 wrote:
| https://uefi.org/specs/UEFI/2.10/02_Overview.html#boot-
| manag...
|
| https://uefi.org/specs/UEFI/2.10/03_Boot_Manager.html
| AshamedCaptain wrote:
| I didn't say boot loader, I said boot _menu_. The boot
| loader may be a mandatory part of UEFI (otherwise the
| entire thing wouldn't actually work...), but there is
| absolutely no mandate for having any type of GUI, not
| even a boot menu.
|
| 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.
| jeroenhd wrote:
| That's not my experience. I've only ever seen HP do an
| actual file browser in UEFI to pick an arbitrary .EFI
| file, but overall every computer and laptop I've seen has
| a button you can press to pick from a list of operating
| systems available to boot.
| Kwpolska wrote:
| The one in my Dell laptop takes quite long to get into and
| out of. It's not something you would want to use regularly.
| Quekid5 wrote:
| If it's for recovery, etc. then that may not be a real
| issue?
|
| 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
| greyw wrote:
| As a distro I wouldnt want to rely on uefi implementations that
| range from ok to garbage tier (no cmdline arguments, hidden
| boot selection menu etc)
|
| 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.
| noodlesUK wrote:
| I also am a huge fan of EFISTUB. EFISTUB is basically the only
| way of making secure boot work in a sane way for Linux -
| include the initramfs in the kernel and sign the whole thing
| with your secure boot keys. You don't even need to compile the
| kernel, you can use dracut to package everything up yourself.
| rwmj wrote:
| I think Fedora is moving to this? https://fedoraproject.org/w
| iki/Changes/Unified_Kernel_Suppor...
| fuzzy2 wrote:
| IIRC, systemd-boot relies on EFISTUB. It's just a boot manager,
| not a boot loader. One EFI application calling another.
|
| 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.
| Volundr wrote:
| Yeah, exactly. This is why you still need to sign kernel
| images if using Secure Boot with systemd-boot.
|
| 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.
| MobiusHorizons wrote:
| Fair enough this type of thing was my main worry with that
| setup, and I kept a backup known-good configuration around
| manually for this purpose. Any automation there seems
| useful.
| Asmod4n wrote:
| Only thing that comes to mind is if you swap disks between
| machines and want the same boot menu on all of them.
| rsyring wrote:
| I replaced Grub w/ rEFInd a few years ago and I've never looked
| back. The ability to just scan filesystems and boot images is so
| simple/easy compared to the Grub menu edit and "reinstall"
| process you have to go through every time you want to make a
| change. I've never used systemd-boot but highly recommend rEFInd
| over Grub.
|
| 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/
|
| - https://wiki.archlinux.org/title/REFInd
|
| - https://github.com/rsyring/zfs-on-root/blob/master/zor.py
| gbin wrote:
| I concur. Refind is pretty much universal for me: it detects
| Linux kernels automatically, windows, boots from USB or detect
| USB (I always have an emergency copy that will boot my systems
| if I screw up), it also runs on Intel macs...
|
| Also... It is very customizable with good a 100% graphic UI.
___________________________________________________________________
(page generated 2023-02-16 23:00 UTC)