Join Log in
Score:1
avatar Ubuntu

Select default boot partition after cloning a partition (Ubuntu 20.04)

us flag
João Pimentel Ferreira

I have two disks each with two partitions, one SSD (/dev/sdb) which had the main boot partition and another HDD (/dev/sda) for backup.

Then I cloned the SSD's main partition (which had the boot) with dd, within a USB live environment, to a partition in the backup HDD:

dd if=/dev/sdb2 of=/dev/sda2

Now, after I rebooted, the system is starting/booting from the cloned partition /dev/sda2!!!

How do I set which partition the system should startup/boot? I want to startup with /dev/sdb2 and NOT /dev/sda2, because SSDs are much faster than HDDs.

Further info:

Relevant output of fdisk -l for both disks:

Disk /dev/sda: 1,84 TiB, 2000398934016 bytes, 3907029168 sectors
Disk model: WDC WD20EZAZ-00L
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes
Disklabel type: gpt
Disk identifier: 350C6598-6531-43D3-9303-26B80124EDDA

Device          Start        End    Sectors   Size Type
/dev/sda1        2048 1953128447 1953126400 931,3G Linux filesystem
/dev/sda2  1953128448 3907028991 1953900544 931,7G Linux filesystem


Disk /dev/sdb: 931,53 GiB, 1000204886016 bytes, 1953525168 sectors
Disk model: Samsung SSD 870 
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 881AE800-FEC8-4EEA-B0C5-5CAE0E2B47F2

Device       Start        End    Sectors  Size Type
/dev/sdb1     2048    1050623    1048576  512M EFI System
/dev/sdb2  1050624 1953523711 1952473088  931G Linux filesystem

Relevant output of lsblk:

...
sda      8:0    0   1,8T  0 disk 
├─sda1   8:1    0 931,3G  0 part /mnt/backupA
└─sda2   8:2    0 931,7G  0 part /
sdb      8:16   0 931,5G  0 disk 
├─sdb1   8:17   0   512M  0 part /boot/efi
└─sdb2   8:18   0   931G  0 part
94
1 + 8
PonJar avatar
in flag
PonJar
You have cloned your root partition so the clone is identical in every way including the UUID. Chances are your fstab file uses the UUID to identify which partition is to be root. Now there are two it’s a lottery which gets mounted as root. Check your fstab file to confirm it’s using UUID. If it is then you can change the UUID of the clone as per these answers https://askubuntu.com/questions/132079/how-do-i-change-uuid-of-a-disk-to-whatever-i-want#132087 or you can specify the root partition with /dev/sdx notation in both fstab files (original and clone)
1
Reply
us flag
João Pimentel Ferreira
@PonJar thanks a lot, I think it's that, `/etc/fstab`, you got the point because `fstab` is mounting `/` using UUID. Just 1 question: if I want to use `/dev/sdx` notation on `fstab`, will the association between /dev/sdx and the physical disks/partitions be always preserved? Thanks again, and BTW if you want add your comment as answer for me to accept it.
1
Reply
Marco avatar
br flag
Marco
No, it is not preserved. That's why UUIDs are used. But UUIDs should by design be unique.
0
Reply
us flag
João Pimentel Ferreira
@marco, what about if I use `PARTUUID` in fstab, since I realized they are different between original and cloned partition?
0
Reply
oldfred avatar
cn flag
oldfred
Generally you do not use dd with gpt partitions. Gpt requires guid in primary partition table, backup partition table & the partition be in sync. You probably now have a bad gpt table. See what this says as best tool for gpt. `sudo gdisk -l /dev/sda` also check sdb. http://www.rodsbooks.com/gdisk/repairing.html More repair info use p, v & w to write the partition table. If not correct just use q to quit. : http://askubuntu.com/questions/386752/fixing-corrupt-backup-gpt-table/386802#386802 But you may have to change GUID & UUIDs.
0
Reply
us flag
João Pimentel Ferreira
@oldfred partition tables are good
0
Reply
us flag
João Pimentel Ferreira
@oldfred check my answer, I share my conclusions :)
0
Reply
us flag
João Pimentel Ferreira
@PonJar check my answer, I share my conclusions, thanks again for the tip :)
0
Reply
Score:1
avatar Ubuntu
us flag
João Pimentel Ferreira

After a full morning around the issue (Linux is challenging :), and thanks to users that commented, and also to share info to other users, I share my conclusions:

  • since there are two exact copies of the same data in two different partitions (/dev/sda2 and /dev/sdb2) thus also having the same UUID, the system was starting always with /dev/sda2 as root /

  • apparently /etc/fstab root / mounting point is ignored except when UUID is set. I tried setting /dev/sdb2 / ... in /etc/fstab in both partitions (original and cloned) and the system was always starting with /dev/sda2 instead. Therefore don't use /dev/sdbx in /etc/fstab for the root mounting point / because it does not work.

  • after investigation, I realized the UUID of the root partition was appearing at least in 3 different locations:

    A) /boot/efi/EFI/ubuntu/grub.cfg
    B) /proc/cmdline
    C) /etc/fstab

  • Therefore the safest solution, as also suggested in the comments, was to change the UUID of the cloned partition.

What I did

  1. I started the computer in live environment with USB stick since the partition whose UUID was to be amended must be unmounted

  2. Then I ran tune2fs /dev/sda2 -U random to alter the UUID of /dev/sda2 (cloned partition). Before running tune2fs I had to run also e2fsck /dev/sda2 -f -p because tune2fs demanded so.

  3. Confirm it with sudo blkid.

+ 2
oldfred avatar
cn flag
oldfred
Do you still have duplicate partUUID/GUIDs? `lsblk -e 7 -o name,fstype,size,fsused,label,partlabel,mountpoint,uuid,partuuid`
0
Reply
us flag
João Pimentel Ferreira
@oldfred no, `partuuid`s are all unique. I actually tried to use `PARTUUID` on `/etc/fstab` since the beginning because that ID was not cloned, but it was not working
0
Reply
ธงชาติไทย
Elon Musk
I sit in a Tesla and translated this thread with Ai:

mangohost

Post an answer

Most people don’t grasp that asking a lot of questions unlocks learning and improves interpersonal bonding. In Alison’s studies, for example, though people could accurately recall how many questions had been asked in their conversations, they didn’t intuit the link between questions and liking. Across four studies, in which participants were engaged in conversations themselves or read transcripts of others’ conversations, people tended not to realize that question asking would influence—or had influenced—the level of amity between the conversationalists.