Copying a non-EFI/GPT installation to a EFI/GPT installation

Question

I recently purchased 2 SSDs (my first), and will be moving my system there. I'm using MD RAID 1 + LVM. I haven't yet decided whether I will be setting up a new stretch installation, or copying my jessie installation to the new disks, if that is possible.

I'd like to make the new installation UEFI/GPT. I've already done a test stretch install on the new disks, but was thinking of copying my current jessie installation (the /, /home, and /boot filesystems) onto the new installation, but without touching the EFI system partitions. The question is whether this will work. Are non-EFI/GPT and EFI/GPT installations compatible?

My sketchy knowledge of how GRUB2 works, is that the "normal" BIOS setup normally has the first stage of GRUB in the MBR, and the second stage normally in the /boot partition. Whereas in the UEFI/GPT setup, it's presumably all in the ESP.

Answer 1

Copying should be relatively easy; Linux installations are (almost entirely) just files. The biggest (only?) exception is the bootloader for BIOS; it is installed to the master boot record and the sectors between that and the first partition. UEFI actually gets rid of that exception; the bootloader is now just a file as well.

BIOS boot works (in brief) that the BIOS reads the first sector from the disk (MBR), and executes the code out of that sector. That code has BIOS functions to read sectors available to it, and in the case of grub, it reads the rest of itself out of the remaining sectors between the MBR and the first partition. That needs to provide enough code to let GRUB understand filesystems, so it can read the config and the rest of itself from /boot. It does that, then also reads the kernel and initramfs from there. Then it fires up the kernel.

UEFI boot works (in brief) that the firmware understands partitions (at least GPT, and probably DOS as well) and filesystems (at least FAT). It has NVRAM of some sort (the EFI variables) that stores a command to run—think shell command (UEFI includes a shell). That is, path (disk, partition, path on filesystem) and arguments. It runs that command. In the case of Linux, that'd be one of:

• a bootloader like GRUB (under Debian, probably at EFI/debian/grubx64.efi) or several others (refind, systemd-boot, etc.)
• a Linux kernel (supported in Debian since Wheezy)
• a Microsoft-signed shim for secure boot, which then loads one of the above.

The command has full access to the UEFI stack, which includes reading files, network, etc. In the case of GRUB, it includes its own filesystem support which is uses for things like ext4, mdraid, LVM, etc.

Ultimately, from your Linux install, that means the difference it sees is: instead of GRUB being installed in a few special sectors at the start of the disk, its a file in /boot/efi/. Note that this is a different build of GRUB; under Debian it's grub-efi-amd64 (or -ia32) instead of grub-pc. You'll need to switch out which grub package you have installed.

The only thing that I expect you may run into is that manipulating the EFI variables typically requires you already be booted via UEFI. So it can be hard to get that grub-install to work. A few workarounds:

1. After copying the system and changing the grub package out, boot to an UEFI-enabled rescue disc (such as the Stretch installer, running in rescue mode) and run grub-install or efibootmgr.

2. If your system has a boot selection menu, it might find the Debian install even without it being set up as a boot option via the EFI variables.

3. Copy grub to /boot/efi/EFI/debian/grubx64.efi to /boot/efi/EFI/BOOT/bootx64.efi — that's the official UEFI fallback path (at least for 64-bit machines). That might be enough to get it to show up in the firmware boot menu.

4. If your system makes it available, use the UEFI shell to boot the system. Then you can update the EFI variables with grub-install or efibootmgr.

After you've done that, there shouldn't be anything different between your copied/converted system and one that was installed with UEFI originally.

Answer 2

@derobert's answers covers a number of different options. I wound up using something along the lines of his no. 3, but I'll go into some detail about this.

As per the approach described in Move a logical volume from one volume group to another, I copied some logical volumes containing an existing Debian 9 system using BIOS over to some new disks I purchased. I also did a new, from scratch, UEFI installation of Debian 9 on those disks.

Then the issue was how to get the copy of my system on those disks to boot. As it happened, I was able to use the GRUB boot menu from the new/from-scratch/UEFI installation. When I hit e on the GRUB menu entry for the new installation, I was able to change the device names in the GRUB script to that of the copied LVs, using the form (lvm/debian-root) where debian is the name of the volume group, and root is the name of the logical volume. That way I was able to boot into the copy of my existing system.

However, I still had to make the system bootable. With some assistance from @debrobert, I did the following:

1. Switched from grub-pc to grub-efi
2. Mounted the existing EFI system partition belonging to the new installation as /boot/efi.

3. Ran

   grub-install --efi-directory=/boot/efi --bootloader-id=origdebian --force-extra-removable
   

   This did two things.

   • It installed an EFI executable grubx64.efi in the directory /boot/efi/EFI/origdebian. The new install already had an executable grubx64.efi in the directory /boot/efi/EFI/debian.

     The EFI firmware was able to then see an entry origdebian in the firmware boot menu.

   • It installed an EFI executable BOOTX64.EFI in the directory /boot/efi/EFI/BOOT. This is the so-called "removable media path". As described in the Debian Wiki,

All firmware implentations have to use this path to be able to run an OS installer.

So this path is intended to function as a temporary fallback. After the system is bootable, it can be removed.