In /boot/efi/EFI/ubuntu/grub.cfg
, there is a filesystem UUID referencing whatever partition contains the /boot
directory/filesystem. This is used by GRUB to find the real /boot/grub/grub.cfg
, which contains further UUID-based references to the Ubuntu filesystem.
When you copied the Ubuntu partition to the SSD, it also copied the filesystem UUID. So you have two filesystems with the same UUID, and when searching for that UUID, GRUB happens to look at the HDD first.
If you no longer need the copy on the HDD, you should change the UUID of the copy on the HDD so it will no longer match what GRUB is looking for. The command to change the filesystem UUID is specific to each filesystem type: see this question for the appropriate commands for several filesystem types.
Alternatively, you could change the UUID of the Ubuntu filesystem on the SSD instead, and then replace all the references to that UUID with the new UUID on the SSD-based installation. You would have to edit at least /boot/efi/EFI/ubuntu/grub.cfg
, /boot/grub/grub.cfg
, /etc/fstab
and possibly also /etc/initramfs-tools/conf.d/resume
, then regenerate your initramfs file on the SSD. This is more work, but by keeping the original unchanged on the HDD you will be able to try the copying again if you make a bad mistake.
lsblk -o name,mountpoint,label,size,fstype,uuid,partuuid | egrep -v "^loop"
As I posted in your link, I did new install in about 10 min to SSD, copied /home so I had my settings. I do have all data in another data partition, so I only had to set those links up. About an hour for a full working install that was at least 90% of install on HDD. Installing apps from list would add a bit, but I had not installed much in my test install on HDD. – oldfred Aug 10 '20 at 14:36