move ubuntu to a new drive does not work

[ItalOz]

I have an external USB drive with various partitions and I have installed Ubuntu 20.04 in one of them, updated grub (on the external and internal drives) and now I can boot from both my internal drive and my external one.
The external drive have several partitions and I have installed from the live stick on dev/sdb7 UUID=f3590ceb-cd80-40cc-8388-cc1797ab0b33
The autogenerated grub entry for this installation reads

menuentry 'Ubuntu 20.04 LTS (20.04) (on /dev/sdb7)' --class ubuntu --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-simple-f3590ceb-cd80-40cc-8388-cc1797ab0b33' {
	insmod part_msdos
	insmod ext2
	set root='hd1,msdos7'
	if [ x$feature_platform_search_hint = xy ]; then
	  search --no-floppy --fs-uuid --set=root --hint-bios=hd1,msdos7 --hint-efi=hd1,msdos7 --hint-baremetal=ahci1,msdos7  f3590ceb-cd80-40cc-8388-cc1797ab0b33
	else
	  search --no-floppy --fs-uuid --set=root f3590ceb-cd80-40cc-8388-cc1797ab0b33
	fi
	linux /boot/vmlinuz-5.4.0-26-generic root=UUID=f3590ceb-cd80-40cc-8388-cc1797ab0b33 ro quiet splash $vt_handoff
	initrd /boot/initrd.img-5.4.0-26-generic
}

and works fine.
Then I have copied the installation to another partition of the same drive (/dev/sdb5) UUID=adcdd044-5e77-44c2-9b52-55961254c3d9
When I update grub I get

menuentry 'Ubuntu 20.04 LTS (20.04) (on /dev/sdb5)' --class ubuntu --class gnu-linux --class gnu --class os $menuentry_id_option 'osprober-gnulinux-simple-adcdd044-5e77-44c2-9b52-55961254c3d9' {
	insmod part_msdos
	insmod ext2
	set root='hd1,msdos5'
	if [ x$feature_platform_search_hint = xy ]; then
	  search --no-floppy --fs-uuid --set=root --hint-bios=hd1,msdos5 --hint-efi=hd1,msdos5 --hint-baremetal=ahci1,msdos5  adcdd044-5e77-44c2-9b52-55961254c3d9
	else
	  search --no-floppy --fs-uuid --set=root adcdd044-5e77-44c2-9b52-55961254c3d9
	fi
	linux /boot/vmlinuz-5.4.0-26-generic root=UUID=f3590ceb-cd80-40cc-8388-cc1797ab0b33 ro quiet splash $vt_handoff
	initrd /boot/initrd.img-5.4.0-26-generic
}

I note that the --fs-uuid used the uuid of the new partition (/dev/sdb5) but the second last line still points to (/dev/sdb7) and if I boot using this entry I still boot into the system that is in fact in (/dev/sdb7)
So I have changed that line to read

	linux /boot/vmlinuz-5.4.0-26-generic root=UUID=adcdd044-5e77-44c2-9b52-55961254c3d9 ro quiet splash $vt_handoff

to match the UUID of the rest of the entry, (I have done this using 40_custom but it can be done also editing directly grub.cfg)
I have also updated the fstab in the partition that corresponds to (/dev/sdb5):

# / was on /dev/sdc7 during installation (changed to what now is sdb5)
UUID=adcdd044-5e77-44c2-9b52-55961254c3d9 /               ext4    errors=remount-ro 0       1
# swap was on /dev/sdc8 during installation
UUID=83dd8c27-711b-4f2c-865c-af056a37f968 none            swap    sw              0       0

Note that also swap is on the external USB drive.
But then when I boot using this entry it hangs, trowing a number of errors during boot.
I though that the installation was partition agnostic and in the past I have done it many times with older versions of Ubuntu. I do it when I want to install a new release, I first install in the external drive, I try it. Then I move my internal current version to the another partition of the external drive and check that I can boot it (this is where it now fails). And only then I move the installation of the new release to my internal drive.
As I said I have done this many times in the past but now clearly something changed and I am missing it.
Any clues?
Thanks

[oldfred]

How did you copy?
Post this in code tags to preserve formatting (# in Forum's advanced editor):
lsblk -o name,mountpoint,label,size,fstype,uuid,partuuid | egrep -v "^loop"

[ItalOz]

Hi oldfred

Thanks for looking into this

I always use this method, boot in my internal Ubuntu (for instance the one I am using at the moment from sda2),
then mount the source partition in /mnt/old_ubuntu using sudo mount /dev/sdb7 old_ubuntu
mount the target partition in /mnt/new_ubuntu using sudo mount /dev/sdb5 new_ubuntu

Then copy all files using: sudo cp -dpR /mnt/old_ubuntu/* /mnt/new_ubuntu/

it used to work so well, al least until ubuntu 17 if I recall correctly, and is my normal routine to upgrade my computers.

output of the code is below (there is one more drive connected in this moment sdc)

NAME   MOUNTPOINT                      LABEL      SIZE FSTYPE   UUID                                 PARTUUID
sda                                             167.7G                                               
├─sda1                                 Windows   48.8G ntfs     481ED1AD55D8C736                     4a57e468-01
├─sda2 /                               ub18.04   48.8G ext4     19380297-eb24-4cb7-9ac9-c08ca5da52a3 4a57e468-02
└─sda3 /media/fab/Dati                 Dati        70G ntfs     42227D890E07DEB4                     4a57e468-03
sdb                                             931.5G                                               
├─sdb1 /media/fab/viaggio              viaggio  488.3G ntfs     DAE8F045E8F02185                     a49fd7ee-01
├─sdb2                                              1K                                               a49fd7ee-02
├─sdb5 /media/fab/uno                  uno      146.5G ext4     adcdd044-5e77-44c2-9b52-55961254c3d9 a49fd7ee-05
├─sdb6 /media/fab/due                  due      146.5G ext4     6a86a205-05c8-41db-b36c-d047302ebc2c a49fd7ee-06
├─sdb7 /media/fab/tre                  tre      140.5G ext4     f3590ceb-cd80-40cc-8388-cc1797ab0b33 a49fd7ee-07
└─sdb8                                            9.8G swap     83dd8c27-711b-4f2c-865c-af056a37f968 a49fd7ee-08
sdc                                               2.7T                                               
└─sdc1 /media/fab/MMSENG_0             MMSENG_0   2.7T ntfs     3A50656C70C3BE47                     fe184978-9971-4e9f-9a63-2a5ad8889f0a
sr0                                              1024M

[oldfred]

If you have manually edited fstab and chrooted into it to update grub.
Or edited all UUID instances of one boot stanza, I would think that would work.

If UEFI you have have to edit /efi/EFI/ubuntu/grub.cfg with UUID of install you are booting.

[ItalOz]

as it turned out the problem was in the copying process, you put me in the right direction by asking the question

How did you copy?

So I did it again and this time instead of using sudo cp -dpR /mnt/old_ubuntu/* /mnt/new_ubuntu/ I have copied the source partition to the target one using Gparted (next time I will try with dd)
Gparted allows you to copy / paste partitions
Then you end up with two partitions that have the same UUID which would confuse GRUB, so you need to generate a new UUID for the copied partition, Gparted lets you do this as well.
I have then edited the grub.cfg file to update the entry with the correct UUID and voila! it worked!

I have to deduce then that the copy process somehow did not work using the command cp, why is that I would not know but I have had the same issue twice already as I have also copied another OS to verify the process.

Another note:
when I have tried to boot from the external drive on a different computer I had an error because the fstab did not find a disk that wasn't there (it is in the original computer) so I had to remove that entry from the fstab to make it really portable.
I do remember though that Ubuntu 14 when it booted and did not find a disk that was specified in the fstab came with an option to press 'S' and skip mounting the disk, I wonder why that does not happen anymore.

Anyway, now it works, I hope this helps others out there with similar issues