PDA

View Full Version : Fedora 9 Duplicate Labels due to Software RAID



turkstra
27th May 2008, 10:05 PM
I'm attempting to upgrade from Fedora 8->9 and am running into a problem. The installer complains about multiple devices on the system having duplicate labels. I can see this when I run blkid....
/dev/sdb1: UUID="f64f73ae-a7b8-c3f3-c99b-51f87ca65c04" TYPE="mdraid"
/dev/sdc1: UUID="f64f73ae-a7b8-c3f3-c99b-51f87ca65c04" TYPE="mdraid"
/dev/sdd1: UUID="f64f73ae-a7b8-c3f3-c99b-51f87ca65c04" TYPE="mdraid"
/dev/sde1: UUID="f64f73ae-a7b8-c3f3-c99b-51f87ca65c04" TYPE="mdraid"

The catch is that all 4 of these disks (partitions) correspond to components in md0, a Linux software RAID-5 array. Because of this they don't directly have a filesystem on them, and I am unable to use the usual tune2fs or e2label programs to change the UUID or Label.

I guess my question is: does anyone know how to change the UUID on a partition that has no file system (is a component of a software RAID array)?

Any responses are *greatly* appreciated. Right now the only solution appears to be to one by one reformat the disks and then let the array rebuild, which is going to be incredibly time consuming. I haven't had this problem with any earlier versions of Fedora either, so I'm hoping there's a way to resolve this nicely. Thanks!!!

- Jeff

A.Serbinski
27th May 2008, 10:55 PM
Congratulations! You've just discovered the reason why they try this stuff out in Fedora before adding it into the next version of RHEL.

I've heard of that problem before, but due to evil bill's OS always creating the same UUID. Anaconda chokes when it detects a duplicate UUID.

I see that you've already gone and posted a bug to bugzilla (448619 for anyone interested), thats a good step. This problem comes from the conversion from the use of filesystem labels to the use of the UUID.

The UUID's on the array components are necessary in order for the system to correctly reassemble the array when the system is started. Your mdadm.conf will specify the UUID so that mdadm can look for all partitions that have that UUID. That means that you CAN'T just go and change the UUID's around, you'll break the array if you do that.

Unfortunately, there doesn't appear to be an anaconda option applicable to the situation... http://fedoraproject.org/wiki/Anaconda/Options

I don't know the way you have your partitions laid out on your disks, so you'll forgive me if this suggestion is not possible; IFF the disks in the array are NOT specifically required during installation (i.e., the data you store on it is something that can be attached AFTER the OS is installed, such as home partition, etc.), then for the installation, simply UNPLUG all those disks and do the install. When the install is finished, plug them back in.

If thats not possible, then the only thing I can suggest is that you backup all your data and do it the slow way.

turkstra
27th May 2008, 11:08 PM
Congratulations! You've just discovered the reason why they try this stuff out in Fedora before adding it into the next version of RHEL.

I've heard of that problem before, but due to evil bill's OS always creating the same UUID. Anaconda chokes when it detects a duplicate UUID.
These drives have never been touched by windoze.

<snip>

The UUID's on the array components are necessary in order for the system to correctly reassemble the array when the system is started. Your mdadm.conf will specify the UUID so that mdadm can look for all partitions that have that UUID. That means that you CAN'T just go and change the UUID's around, you'll break the array if you do that.
It actually appears as though mdadm uses the UUID stored in the RAID superblock - you can see it using mdadm -E. This is different from the UUID reported by blkid. So, I'm not entirely sure this would break the array - but this is definitely a nonideal situation.

<snip>

I don't know the way you have your partitions laid out on your disks, so you'll forgive me if this suggestion is not possible; IFF the disks in the array are NOT specifically required during installation (i.e., the data you store on it is something that can be attached AFTER the OS is installed, such as home partition, etc.), then for the installation, simply UNPLUG all those disks and do the install. When the install is finished, plug them back in.
I've thought about this, and if I don't get any better ideas I'll probably go ahead and do it.


If thats not possible, then the only thing I can suggest is that you backup all your data and do it the slow way.
Thanks for the reply :-)

- Jeff

A.Serbinski
28th May 2008, 04:36 PM
I never suggested that your drives were touched by windoze, just that windoze causes the same problem.

I just looked at what you said about the UUIDs of the partitions not matching the UUID of the array, so I checked my array, and you're right. In fact on mine, the UUIDs of each component are all different. My array was created under F9, so perhaps the issue is that you used an old version of fdisk to create the partitions? Or an old version of mdadm to create the array?