Announcement

Collapse
No announcement yet.

Debian 10 "Buster" Working To Have UEFI SecureBoot In Good Shape

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

  • #11
    Originally posted by lucrus View Post
    Who on earth installs Debian stable on a notebook or otherwise SecureBoot-ed PC?
    I do (but I nowadays consider myself a weirdo in the Infurating Technologies realm) :-D

    Comment


    • #12
      Originally posted by debianxfce View Post
      Because you know better than the Internet, post clear and 100% working instructions how to clone an efi disk to a new one with dd
      Same disk size = same as copying a MBR drive.

      Different disk size (partitions can actually fit) use dd to copy it over, then run a GPT-aware disk partitioning tool to fix the secondary GPT partition table (as now you either have it in the wrong place, or is missing. fdisk or gdisk or parted or whatever. Just start them up and then have them "write the changes to disk" will fix the secondary GPT partition table.
      I use

      Code:
      gdisk /dev/sdX
      Then I see that it complains on startup about missing or misplaced secondary GPT partition table, I proceed with "w" and confirm with "y"

      As an aside, I use pv instead of dd as it can actually show progress and MB/s, while not requiring me to specify things like "block size" which make no sense at all outside of the ancient tape media that dd was originally designed for.

      and make it boot with grub.
      I guess this is your actual issue. The average GRUB install for Debian does not place GRUB in a standard location for the UEFI firmware (see here https://wiki.debian.org/UEFI ) and relies on setting up the UEFI to boot from their custom location, and the UEFI links this configuration to the drive's ID.
      Cloning the drive will break this as the new drive will have a different ID.

      Ubuntu, Fedora, OpenSUSE and others install their GRUB in the standard location for "removable media" so even if you clone a drive it will still boot from it automatically.

      Debian does not do it by default the last time I checked.

      While I never did it myself as all my remaining Debian systems are not even x86 devices at all, according to the Debian Wiki https://wiki.debian.org/GrubEFIReins...ack_bootloader
      you have to enable this functionality BEFORE you clone the drive by writing
      Code:
      echo "grub-efi-amd64 grub2/force_efi_extra_removable boolean true" | sudo debconf-set-selections
      and then reinstall grub so it is installed in the right place.
      Code:
      update-grub ; grub-install /dev/sdX
      Or you can also do it manually, you need to mount the EFI partition (by default this partition is mounted inside /boot/efi if you installed in UEFI mode), then copy /EFI/debian/grubx64.efi into /EFI/boot/bootx64.efi
      Assuming standard Debian installed as UEFI, you need to do this BEFORE you clone the drive with dd:
      Code:
      sudo cp -Rf --parents /boot/efi/EFI/debian/* /boot/efi/EFI/boot/
      Then after you booted successfully from this drive you have to reinstall grub with grub-install /dev/sdX so it sets the UEFI configuration to boot from this drive.

      I personally ditched GRUB on my x86 systems because it's prehistoric clunky trash and replaced it with rEFInd bootloader (with a beautiful theme) placed in the standard "removable media" location in the EFI partition.
      rEFInd is 0 mainteneance and does not need to be reconfigured and reinstalled every time you update your kernel. Also this setup will boot automatically in UEFI mode as it does not rely on setting the UEFI to boot from a specific file in a specific drive.
      Last edited by starshipeleven; 12 January 2019, 08:14 PM.

      Comment


      • #13
        Originally posted by starshipeleven View Post
        I guess this is your actual issue. The average GRUB install for Debian does not place GRUB in a standard location for the UEFI firmware (see here https://wiki.debian.org/UEFI ) and relies on setting up the UEFI to boot from their custom location, and the UEFI links this configuration to the drive's ID.
        Cloning the drive will break this as the new drive will have a different ID.

        Ubuntu, Fedora, OpenSUSE and others install their GRUB in the standard location for "removable media" so even if you clone a drive it will still boot from it automatically.

        Debian does not do it by default the last time I checked.

        While I never did it myself as all my remaining Debian systems are not even x86 devices at all, according to the Debian Wiki https://wiki.debian.org/GrubEFIReins...ack_bootloader
        you have to enable this functionality BEFORE you clone the drive by writing
        Code:
        echo "grub-efi-amd64 grub2/force_efi_extra_removable boolean true" | sudo debconf-set-selections
        and then reinstall grub so it is installed in the right place.
        Code:
        update-grub ; grub-install /dev/sdX
        Or you can also do it manually, you need to mount the EFI partition (by default this partition is mounted inside /boot/efi if you installed in UEFI mode), then copy /EFI/debian/grubx64.efi into /EFI/boot/bootx64.efi
        Assuming standard Debian installed as UEFI, you need to do this BEFORE you clone the drive with dd:
        Code:
        sudo cp -Rf --parents /boot/efi/EFI/debian/* /boot/efi/EFI/boot/
        Then after you booted successfully from this drive you have to reinstall grub with grub-install /dev/sdX so it sets the UEFI configuration to boot from this drive.

        I personally ditched GRUB on my x86 systems because it's prehistoric clunky trash and replaced it with rEFInd bootloader (with a beautiful theme) placed in the standard "removable media" location in the EFI partition.
        rEFInd is 0 mainteneance and does not need to be reconfigured and reinstalled every time you update your kernel. Also this setup will boot automatically in UEFI mode as it does not rely on setting the UEFI to boot from a specific file in a specific drive.
        That must explain why my dd instructions have failed... (his drives had similar size)

        Comment

        Working...
        X