System76's Pop!_OS Switching From GRUB To Systemd-Boot

[R41N3R]

Technically I welcome this, systemd-boot is fast and easy and I switched all my new installs. Antergos offers systemd-boot optionally and together with encryption plus btrfs and zstd compression it works really well. Anyway I wonder what this means for a VM. Is there are better alternative then using OVMF combined with systemd-boot? On VM's i still use grub and the Bios boot.

[stikonas]

I believe he/she is referring to having the kernel and initrd stored on an encrypted partition. With GRUB, for example, I can have the kernel, initrd, grub.cfg, and GRUB modules on an encrypted boot partition and GRUB will prompt for the LUKS passphrase before it loads the menu. Combined with UEFI secure boot and a custom-signed grub.efi executable, you can have a fully verified or encrypted boot chain.

Thanks! This is exactly what I was referring to. I should have been more elaborate...

[starshipeleven]

Hope Debian will do it too, they switched to systemd, why not to systemd-boot?

it does not support BIOS (as it is basically a UEFI-only boot manager)

[starshipeleven]

It doesn't do everything you need. For example you can't boot from encrypted partition with systemd-boot. /boot has to be unencrypted. On the other hand, grub can easily unlock LUKS volume, find linux kernel image on LVM partition and successfully boot.

Nonsense, on UEFI you have EFI system partition anyway and without SecureBoot they can tamper with GRUB and you'd be screwed anyway.

[stikonas]

Nonsense, on UEFI you have EFI system partition anyway and without SecureBoot they can tamper with GRUB and you'd be screwed anyway.

Without secure boot yes, but that's a stupid comparison. Why would I turn secure boot off? I sign my grub executable with 4096 bit RSA key.

[starshipeleven]

Without secure boot yes, but that's a stupid comparison. Why would I turn secure boot off? I sign my grub executable with 4096 bit RSA key.

Then you could sign the kernel too and boot it fine from the UEFI partition https://chsh.moe/2017/08/use-secure-...arch-linux-en/

That's how systemd-boot is supposed to work. It has no drivers so it can't access outside of the UEFI partition anyway, if a distro uses it then it will have to move the kernel in the UEFI partition.

[stikonas]

Then you could sign the kernel too and boot it fine from the UEFI partition https://chsh.moe/2017/08/use-secure-...arch-linux-en/

That's how systemd-boot is supposed to work. It has no drivers so it can't access outside of the UEFI partition anyway, if a distro uses it then it will have to move the kernel in the UEFI partition.

Well, yes, you can sign the kernel. But still there is way more work. You probably want to include initramfs into the kernel then, so that's also signed.

On the other hand, my signed grub grubx64.efi is only 246 KB, so my EFI partition is just 1MiB FAT12. Its abuot 3 times larger than systemd-bootx64.efi but many times smaller than systemd-bootx64.efi + kernel + initramfs.

[starshipeleven]

Well, yes, you can sign the kernel. But still there is way more work. You probably want to include initramfs into the kernel then, so that's also signed.

Solved and automated long ago https://github.com/andreyv/sbupdate

On the other hand, my signed grub grubx64.efi is only 246 KB, so my EFI partition is just 1MiB FAT12. Its abuot 3 times larger than systemd-bootx64.efi but many times smaller than systemd-bootx64.efi + kernel + initramfs.

It's a matter of preference I guess. It's not like 100-256MB used by UEFI partition are going to make a massive difference with normal hard drives. I find debatable the choice of FAT16, as UEFI is using FAT32, but I guess it's close enough to not matter.

My main point was that systemd-boot does allow you to use encrypted partitions fine, you just have to sign the kernel+initramfs and keep the blob in the UEFI partition.

[starshipeleven]

Uefi can not live in a USB memory stick, so you can not test an Uefi version of a Linux distribution when your main SSD uses MBR.

Wrong.

When you power up the PC, press the button to enable boot selection menu, or press the button to get in UEFI settings and find the section "boot override" then select your UEFI usb stick from the list.
It will have "UEFI" or something similar in the name.
Like
UEFI:Jetflash Transcend 8GB

Then it will boot a UEFI liveCD from your USB drive.

If it does not work, disable any "fast boot" feature in the UEFI setup, as "fast boot" feature usually disables USB boot for the sake of being faster to boot from Sata. Check in the Boot settings that it can see your USB drive and can boot from USB (might be disabled through a separate "boot from USB" setting).

If it still does not, your UEFI firmware is buggy.

See this tutorial for Ubuntu about how to create a UEFI-bootable USB livecd. https://askubuntu.com/questions/3958...usb-live-media

If you are on Windows, just use rufus https://rufus.akeo.ie/

So "It doesn't do everything you need" is a fact. Grub is much simpler to use than uefi.

UEFI is the motherboard firmware, GRUB is a bootloader.

UEFI is starting GRUB from the UEFI partition, and then GRUB starts your Linux Debian XFCE testing.

Any drive can have a UEFI partition with a bootloader/bootmanager like GRUB or Windows's bootloader or rEFInd or Clover or systemd-boot anything else.

Plus winvirushoover overwrites Debian efi settings in a dual boot computer when it updates.

On my old PC where the UEFI firmware is crap and randomly resets the UEFI boot options I placed my bootloader (rEFInd) in /EFI/BOOT/bootx64.efi

That is the default UEFI bootloader path that the UEFI firmware always looks for. Place your GRUB in there and with that name and it will work.