Announcement

Collapse
No announcement yet.

GRUB 2.06 Should Be Released This Year, Cooperation Increasing With Distro Vendors

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

  • #41
    Originally posted by Old Grouch View Post

    No, GRUB 2.x does not force that. My setup (which took a bit of work) has two partitions: an unencrypted ESP and a single (large) encrypted partition with everything else. That 'everything else' starts with LVM. In the appropriate place on the ESP there is a grubx64.efi

    On power up, once UEFI does its stuff, grubx64.efi accesses the encrypted partition and requests the decryption string from the user. That string is used by the LUKS module in grubx64.efi to decrypt the key used to encrypt the partition, and that key is subsequently used to pass decrypted data from the encrypted partition to grubx64 for further processing.
    grubx64.efi then uses its LVM module for subsequent processing of the data from the encrypted partition. grubx64.efi then mounts the LVM volume /boot and loads initramfs and the kernel. Control is then passed to the kernel loaded from the /boot LVM volume on the LUKS encrypted partition.

    That kernel starts from scratch and has to go through the same process: so it has to request the decryption string again so it can access the LUKS encrypted partition, start LVM, mount all the volumes (including a swap volume, so I happen have an encrypted swap) and go through the rest of a normal boot process.

    It works fine, and updates to grub have worked automatically. The minor downside is needing to supply the decryption string twice. One can opt to store it in the (encrypted) Initramfs. Here is not the place to discuss the level of security this provides.

    The key points were to ensure that grubx64 had the appropriate modules - for LUKS, for LVM, and for the filesystems I use for /boot and /

    GRUB is extremely flexible, and many constraints that people blame on GRUB are actually constraints generated by the choices the distributions make - probably/possibly for ease of support.
    Interesting. However, why not use an efi bootloader for this specific usecase?
    What distro do you use and do you need anything particular (custom scripts?) to update kernels?
    I'm fairly sure Debian would break this with every update.

    Comment


    • #42
      Originally posted by mppix View Post

      Interesting. However, why not use an efi bootloader for this specific usecase?
      What distro do you use and do you need anything particular (custom scripts?) to update kernels?
      I'm fairly sure Debian would break this with every update.
      To be honest, I didn't look (much) into using an efi bootloader. I was using the project as a learning experience around GRUB. I have non-standard ideas about what 'fun' is.
      Distro is Lubuntu 18.04.5 LTS. No custom scripts. It needed setting up via chroot because I was using filesystems not supported by the standard installer. From memory, I needed to add a couple of entries to some GRUB config files to enable LUKS and some other modules, and after chrooting, make some changes to fstab and (almost certainly) crypttab. I download (unsigned) kernels from the ubuntu kernel ppa (because I can, currently on 5.10.13), so the kernel has been updated many, many times (via dpkg -i <blah>). Never had a problem with GRUB. The Lubuntu/Ubuntu updater does its stuff and installs a new kernel every so often and runs update-grub, no issues. So far, it just works.

      i won't say it was easy. I took far too long experimenting and learning, but I'm planning on moving to a different distro (probably Mint), so I'll have to do it all over again, as the Mint installer doesn't do what I want. Supergrub2 disk, SysrescueCD, rEFInd, and an ALT Linux LiveUSB distro helped me recover from some non-bootable systems. Often. until I got it working.

      I may have thrown some EFI filesystem drivers onto the ESP. It was a while ago, and my notebook is somewhere in my piling system.
      Last edited by Old Grouch; 12 February 2021, 02:17 PM. Reason: Edit: needing -> needed

      Comment


      • #43
        Originally posted by Old Grouch View Post

        To be honest, I didn't look (much) into using an efi bootloader. I was using the project as a learning experience around GRUB. I have non-standard ideas about what 'fun' is.
        Distro is Lubuntu 18.04.5 LTS. No custom scripts. It needed setting up via chroot because I was using filesystems not supported by the standard installer. From memory, I needed to add a couple of entries to some GRUB config files to enable LUKS and some other modules, and after chrooting, make some changes to fstab and (almost certainly) crypttab. I download (unsigned) kernels from the ubuntu kernel ppa (because I can, currently on 5.10.13), so the kernel has been updated many, many times (via dpkg -i <blah>). Never had a problem with GRUB. The Lubuntu/Ubuntu updater does its stuff and installs a new kernel every so often and runs update-grub, no issues. So far, it just works.

        i won't say it was easy. I took far too long experimenting and learning, but I'm planning on moving to a different distro (probably Mint), so I'll have to do it all over again, as the Mint installer doesn't do what I want. Supergrub2 disk, SysrescueCD, rEFInd, and an ALT Linux LiveUSB distro helped me recover from some non-bootable systems. Often. until I got it working.

        I may have thrown some EFI filesystem drivers onto the ESP. It was a while ago, and my notebook is somewhere in my piling system.
        Nice! Also, I second that the default Debian/Ubuntu/Mint default configuration with separate unencrypted /boot (ext2), and /boot/efi (fat) is not ideal..

        Comment

        Working...
        X