PDA

View Full Version : [SOLVED] move ubuntu to a new drive does not work



ItalOz
February 24th, 2021, 02:21 AM
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
February 24th, 2021, 04:46 AM
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
February 24th, 2021, 05:02 AM
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
February 24th, 2021, 03:13 PM
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
February 25th, 2021, 10:16 AM
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