Announcement

Collapse
No announcement yet.

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

Collapse
X
  • Filter
  • Time
  • Show
Clear All
new posts

  • #11
    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.

    Comment


    • #12
      Yet another reason to buy a rebranded Clevo from Sager or Prostar. I do like that they said they were cleaning Intel ME off them tho. With all the Meltdown and Spectre nonsense everyone seems to have forgotten about ME... and nobody here is even talking about AMD-SP... just like Building 7 and Israeli meddling in elections... hmm

      Comment


      • #13
        Originally posted by chenxiaolong View Post

        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...
        Last edited by stikonas; 02-06-2018, 10:37 AM.

        Comment


        • #14
          Originally posted by SvenK View Post
          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)

          Comment


          • #15
            Originally posted by stikonas View Post
            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.

            Comment


            • #16
              Originally posted by starshipeleven View Post
              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.
              Last edited by stikonas; 02-06-2018, 10:48 AM.

              Comment


              • #17
                Originally posted by stikonas View Post
                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.

                Comment


                • #18
                  Originally posted by starshipeleven View Post
                  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.

                  Comment


                  • #19
                    Originally posted by stikonas View Post
                    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.

                    Comment


                    • #20
                      Originally posted by starshipeleven View Post
                      Nonsense, on UEFI you have EFI system partition anyway and without SecureBoot they can tamper with GRUB and you'd be screwed anyway.
                      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. So "It doesn't do everything you need" is a fact. Grub is much simpler to use than uefi. Plus winvirushoover overwrites Debian efi settings in a dual boot computer when it updates. After every update you need to do:
                      https://wiki.debian.org/UEFI
                      Log into Windows and start an administrative command prompt:
                      Press Windows key
                      Search for cmd
                      Right click --> Run as Administrator

                      Type this command:
                      bcdedit /set "{bootmgr}" path \EFI\debian\grubx64.efi

                      Comment

                      Working...
                      X