After cloning OS, GRUB always boots from the source sda1 partition even when another partition is selected for booting

Question

I have a laptop that should be running two Debian 9's, one Debian 11 and one Windows 10 from two disks, one hard disk drive, /sda/, and a new solid state drive, /nvme0n1/.

I used gparted to clone and extend /sda1/'s Debian 9 onto the SDD's /nvme0n1p5/.

When I boot Debian 9 (/nvme0n1p5/) using GRUB2, which recognises all four operating systems, it always boots the source partition, /sda1/, on Legacy Boot Mode. The Debian 11 installed on /sda5/ boots just fine as does Windows on /nvme0n1p1/.

The newer SSD /nvme0n1/ is partitioned using GPT whereas the HDD still uses MBR.

After I cloned the source partition I had to reinstall grub2 as grub-efi-amd64 uninstalling grub-pc to accommodate UEFI dual-booting/multi-booting as suggested here.

I haven't yet tried removing the HDD with the source partition from the machine and seeing how GRUB reacts but I shouldn't have to do that.

---

EDIT 1

I tried giving /nvme0n1p5/ a new UUID and updating GRUB but this did not fix the problem.

Then I tried removing the HDD to see what would happen. The result is in the forth image. Windows on /nvme0n1p1/ is no longer visible. I can't boot into either /sda1/ or /nvme0n1p5/. The first is expected. The second is not.

---

Answer 1

Welcome to the Unix & Linux StackExchange!

I can think of several possible reasons why your Debian 9 boot option might behave as you described.

Your picture of Debian 11's GRUB indicates it has a "System setup" boot option, which indicates the UEFI version of GRUB is successfully starting. Also, you said Windows boots just fine from a GPT-formatted disk, and that can only happen in UEFI mode.

I don't think GRUB can switch from UEFI to legacy mode on its own, so your symptom of "always booting Debian 9 on Legacy Boot Mode using sda1" probably means the UEFI version of GRUB attempts to boot the Debian 9 kernel, but fails, and then the system firmware gets to decide what to do next. If there are no other valid UEFI boot options to try, it might start trying legacy boot options, and so end up finding a bootable MBR on sda, which will fire up a BIOS version of GRUB and ultimately Debian 9 on sda1.

When you cloned the Debian 9 installation to nvme0n1p5, did you change the filesystem UUID? If there are two filesystems with the same UUID, and if the firmware can boot from NVMe in UEFI mode only, that might explain why the UEFI-mode boot of Debian 9 fails but legacy mode works: the UEFI-mode bootloader will see two partitions with the UUID expected for the Debian 9's root filesystem, and the legacy-mode bootloader will only see sda1.

Once the Linux kernel starts up, it can support NVMe drives on its own regardless of the boot mode, so you might not notice any unusual symptoms other than being unexpectedly in legacy boot mode.

Another possibility would be if your Debian 9 installation is a 32-bit version. The legacy-mode boot starts in 16-bit mode(!), and one of the first tasks of the kernel in legacy-mode boot is to deactivate the compatibility functions to uncover the 32 and 64-bit capabilities of the processor. But UEFI boots in native 64-bit mode, and I'm not sure if it even allows booting a 32-bit kernel: I know a 32-bit UEFI can boot a 64-bit kernel, but I'm not sure if the opposite is supported. If the UEFI GRUB fails to boot because it's trying to load a 32-bit kernel, that might also cause the firmware to attempt a legacy-mode boot, which ends up using sda1.

And if you have Secure Boot enabled, Debian implemented Secure Boot compatibility only in Debian 10 and newer. (Of course, claiming to have Secure Boot enabled and then seamlessly falling back to legacy BIOS boot if the UEFI boot fails is not very secure...)

So, you'll need more information on why the UEFI boot of Debian 9 is failing. One of the first things you could do is to temporarily disabling the boot splash and enabling verbose boot messages. In the GRUB boot menu, move the highlight to the "Debian 9 on nvme0n1p5" boot option, and press the E key to (non-persistently) edit the boot entry. You'll see a number of lines. Find a line that begins with the words:

linux /boot/vmlinuz-<kernel version number here> <kernel boot options...>

If the kernel boot options include the words quiet and/or splash, remove them. For good measure, you might also write in the words verbose and nosplash. This should cause the Linux kernel to output a lot of details at boot. To boot with the temporarily altered boot options, press F10 or Control+X.

If you still see a regular Debian 9 boot splash screen and the system ends up in legacy mode, that suggests the failure and restart in legacy mode happens faster than your screen can switch display modes - and that would suggest the problem happens right when GRUB is trying to start the kernel.

Once you are in Debian 9, log in, open a command prompt and type uname -m. Does it respond with x86_64, or something like i386 or i686? The first means your OS has a 64-bit kernel, the others all indicate a 32-bit version.

Answer 2

At long last, I found out the problem was an UUID issue on /etc/fstab. Linux on the cloned partition /nvme0n1p5/ would load up the file system targeting the UUID of /sda1/.

I had to replace in my /etc/fstab file the old UUID of the original partition with the new UUID of the destination partition.

# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
# / was on /dev/sda1 during installation
UUID=002ae0f2-b6df-4502-8a0c-b9db279142b1 /               ext4    errors=remount-ro 0       1

to

# /etc/fstab: static file system information.
#
# Use 'blkid' to print the universally unique identifier for a
# device; this may be used with UUID= as a more robust way to name devices
# that works even if disks are added and removed. See fstab(5).
#
# <file system> <mount point>   <type>  <options>       <dump>  <pass>
# / was on /dev/sda1 during installation
UUID=248b6fec-3f9a-4e48-838f-cdea88cfe933 /               ext4    errors=remount-ro 0       1

During my tinkering, I updated grub a number of times a number of ways. I don't believe this second bit is part of the original problem but rather a fix to a second problem I might have created. I include this just in case. The grub menu entry pointed to the wrong partition for retrieving the file system but the right entry for retrieving the Linux kernel.

submenu "Advanced options for Debian GNU/Linux 9 (stretch) (on /dev/nvme0n1p5)"{
menuentry "Debian GNU/Linux (on /dev/nvme0n1p5)" --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-/boot/vmlinuz-4.9.0-13-amd64--248b6fec-3f9a-4e48-838f-cdea88cfe933' {
        insmod part_gpt
        insmod ext2
        if [ x$feature_platform_search_hint = xy ]; then
          search --no-floppy --fs-uuid --set=root  002ae0f2-b6df-4502-8a0c-b9db279142b1
        else
          search --no-floppy --fs-uuid --set=root 002ae0f2-b6df-4502-8a0c-b9db279142b1
        fi
        linux /boot/vmlinuz-4.9.0-13-amd64 root=UUID=248b6fec-3f9a-4e48-838f-cdea88cfe933 ro efi=runtime quiet
        initrd /boot/initrd.img-4.9.0-13-amd64
}

to:

submenu "Advanced options for Debian GNU/Linux 9 (stretch) (on /dev/nvme0n1p5)"{
menuentry "Debian GNU/Linux (on /dev/nvme0n1p5)" --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-/boot/vmlinuz-4.9.0-13-amd64--248b6fec-3f9a-4e48-838f-cdea88cfe933' {
        insmod part_gpt
        insmod ext2
        if [ x$feature_platform_search_hint = xy ]; then
          search --no-floppy --fs-uuid --set=root  248b6fec-3f9a-4e48-838f-cdea88cfe933
        else
          search --no-floppy --fs-uuid --set=root 248b6fec-3f9a-4e48-838f-cdea88cfe933
        fi
        linux /boot/vmlinuz-4.9.0-13-amd64 root=UUID=248b6fec-3f9a-4e48-838f-cdea88cfe933 ro efi=runtime quiet
        initrd /boot/initrd.img-4.9.0-13-amd64
}

This can be done with a GUI using grub-customizer available from Debian 10 or more. Otherwise just mount the EFI system partition and open /grub/grub.cfg. You will have to modify the Advanced Boot options as well as. Remember to copy a backup of the original /grub/grub.cfg in case something goes wrong.

Find your own correct UUID with sudo blkid. The correct UUID is that of the partition you want to boot to.