Hacker News new | ask | show | jobs
by usr1106 803 days ago
So assuming your machine supports UEFI, what are the common use cases that systemd-boot would not support, requiring you to use grub?

Encrypted boot partition I'd guess? I tried that once with grub, but it was unbearingly slow, because grub did not / could not use modern x86 extensions to do the decryption. So not a common use case either, maybe a desirable one.

4 comments

I shifted to using systemd-boot as default years ago and don't look back.

Granted, prior to Debian Bookworm I had to roll my own initramfs- and kernel-hooks, but there were blog posts and I didn't need to develop them.

I even tried directly booting into Linux EFISTUB, but thats uselessly annoying compared to a proper bootloader.

One of the use cases is booting into btrfs snapshots automatically. AFAIK systemd-boot still does not support this.
> So not a common use case either, maybe a desirable one.

it's a literal checkbox install option on Ubuntu at least a few versions back (i'm not up to date), so I wouldn't call it uncommon.

For root partition sure. But for boot? Normally when you choose an encrypted root partition you get an extra boot partition without encryption. Unless that has changed rather recently.
Depends on the distro. openSuse encrypts all, and has (or had?) slow boot as consequence. I think Tumbleweed just switched away from Grub.

The theory is that messing with boot can compromise your system and leave you vupnarable despite encryption.

I mean, something still accepts your password that's unencrypted. The solution for this is, yay I get to say it, Secureboot.
> Encrypted boot partition I'd guess? I tried that once with grub, but it was unbearingly slow, because grub did not / could not use modern x86 extensions to do the decryption

Isn't it deliberately slow to resist brute forcing? At least at one point, the default number of rounds in cryptsetup was decided by counting how many rounds it could do in 10s as part of the setup process on your specific machine

You want key operations to be slow for those reasons, but not the encryption once the key is unlocked.