Replicate MBR disk with random UUIDs?

Rocky Linux Tech Help
1

Hi,

First a little bit of context. Let’s say I have a server with several identical hard disks, and I want to setup a software RAID array. In that case I partition the first disk, and then I replicate my partitioning scheme. Here’s what this would look like with two disks with a GPT partitioning scheme:

# sgdisk /dev/sda --replicate /dev/sdb
# sgdisk --randomize-guids /dev/sdb
# gdisk -l /dev/sdb

Now how would I do that with an MBR-based partitioning ? Here’s how I can clone my disk:

# sfdisk --dump /dev/sda | sfdisk /dev/sdb
# fdisk -l /dev/sdb

Unfortunately my second disk will have the exact same UUIDs as the first one. And the sfdisk command doesn’t seem to have an equivalent option for --randomize-guids like sgdisk.

Any suggestions ?

2

You can do it like this:

/dev/vdb1: PARTUUID="88da3c19-01"
/dev/vdc1: PARTUUID="88da3c19-01"

I ran blkid so that you could see I did the sfdisk commands just like you.

[root@rocky ~]# fdisk -l /dev/vdc
Disk /dev/vdc: 20 GiB, 21474836480 bytes, 41943040 sectors
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: dos
Disk identifier: 0x88da3c19

Device     Boot Start      End  Sectors Size Id Type
/dev/vdc1        2048 41943039 41940992  20G fd Linux raid autodetect

note the disk identifier 0x88da3c19, and I will change this to 0x88da3c20

[root@rocky ~]# fdisk /dev/vdc

Welcome to fdisk (util-linux 2.32.1).
Changes will remain in memory only, until you decide to write them.
Be careful before using the write command.


Command (m for help): x

Expert command (m for help): i

Enter the new disk identifier: 0x88da3c20

Disk identifier changed from 0x88da3c19 to 0x88da3c20.

Expert command (m for help): r

Command (m for help): w

The partition table has been altered.
Calling ioctl() to re-read partition table.
Syncing disks.

And with blkid:

[root@rocky ~]# blkid
/dev/vdb1: PARTUUID="88da3c19-01"
/dev/vdc1: PARTUUID="88da3c20-01"

then when you start creating the array:

mdadm --create /dev/md0 --level=1 --raid-devices=2 /dev/vdb1 /dev/vdc1

and now, blkid:

/dev/vdb1: UUID="debb8a3c-82ba-0da3-bcb5-925473ec1193" UUID_SUB="4bee41a8-5188-1f44-578f-52d4591cdd8f" LABEL="rocky:0" TYPE="linux_raid_member" PARTUUID="88da3c19-01"
/dev/vdc1: UUID="debb8a3c-82ba-0da3-bcb5-925473ec1193" UUID_SUB="c71fbc20-5722-3310-c7a8-2e15958b76e4" LABEL="rocky:0" TYPE="linux_raid_member" PARTUUID="88da3c20-01"
1 Like
3

I think I just found a nifty little hack that’s dead simple. When cloning the disk partitioning scheme, I just leave out the UUID information:

# sfdisk --dump /dev/sda | grep -v ^label-id | sfdisk /dev/sdb
# fdisk -l /dev/sdb

I just gave it a spin, and it works like a charm.

2 Likes
4

Cool, nice workaround. To be honest, when I created arrays before, never even thought about the PARTUUID. Even today, I created the array straight after the sfdisk, and it worked just fine. Obviously the standard UUID for the partitions were different which was probably more important. Although these were commands I used years ago, like around 2007-2010 when I decided to convert my system from standard partitions to raid array without having to reinstall from scratch. This was even before I encountered UUID’s in fstab or even using blkid, so perhaps that was why I didn’t even take it into account up until now :slight_smile:

1 Like
5

Same here. I only looked at this stuff more closely because the Rocky Linux 8.4 installer loudly complained about identical UUIDs on my hard disks and then exited.