README_RAID.TXT unexpectedly clones disk identifier

guanx · 03-05-2021, 02:02 AM

The command provided for convenience to clone partitions of member disks:

Code:

Now that /dev/sda is partitioned as appropriate, copy the partitions to all
the other drives to be used in your RAID arrays.
   
An easy way to do this is:
  sfdisk -d /dev/sda | sfdisk --Linux /dev/sdb

This will destroy all partitions on /dev/sdb, and replicate /dev/sda's
partition setup onto it.

also clones the disk identifier, which causes management problems. It would be nice to add a command here to reset the disk identifier to some other random value, or just don't clone that.

smallpond · 03-05-2021, 09:25 AM

AFAIK that sfdisk command just copies the MBR partition table in the first block of the disk, which does not contain any identifiers. It will not work for GPT disks. Please explain what identifier you are seeing.

guanx · 03-05-2021, 11:08 AM

Quote:

Originally Posted by smallpond

//snip
Please explain what identifier you are seeing.

By "Disk Identifier" I mean

Code:

# fdisk -l /dev/sda

Disk /dev/sda: 479.6 GB, 479559942144 bytes, 936640512 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 65536 bytes / 65536 bytes
Disk label type: dos
Disk identifier: 0x000bf03e

   Device Boot      Start         End      Blocks   Id  System

"Disk identifier" here, 0x000bf03e for example.

smallpond · 03-07-2021, 09:36 AM

I was wrong, Looks like there can be an identifier in the MBR. It seems totally unexpected that copying the partition table would also copy the identifier. Seems like a bug in sfidsk as it's not stated on the sfdisk man page.

Emerson · 03-07-2021, 02:05 PM

The workaround is to dump into a file, edit the identifier and use this file to set up the other drive.