Katzj is testing a fix.

Looking at this some more...  are you creating the raid10 in anaconda or
post-install?  Or are you trying to upgrade something set up like this?

This was a fresh install.  Initially I tried to create the raid10 using
anaconda.  I wasn't sure
exactly what I wanted, so I ended up not creating a raid10 filesystem during the
install.

After the machine was up, I editted the /etc/raidtab file and did the mkraid
commands.  Then
did a mkfs and an e2label.  Added this to fstab using the label.  System booted
but didn't
"do the right thing" when it tried to mount the filesystem.  I quickly changed
to using /dev/mdX
in the fstab and all was well.

Sorry for my vagueness as to "do the right thing".  It failed, my instinct said
the fix was to use
/dev/mdX for mounting, which worked.  I did not spend much time playing around
to figure
out all the details of how it failed.

If it was created post-install and doesn't work, this is a mount problem, not
anaconda... reassigning.

Were the raid modules loaded when trying to mount the filesystem initially?

If not, this is not a bug: Accessing the /dev/mdX device auto-loads the 
required modules, after which the label could be found.

But mount is not supposed to auto-load modules just to see if there are any 
devices, so mounting an md device by label can't work if you didn't load the 
modules. It'll just probe the partitions belonging to the raid device (and 
obviously not do the right thing).

cruising through bugzilla and found that this was in limbo waiting for more info
from me.  oops.

I believe the issue is this:

mirror drive a and b; call this x
mirror drive c and d; call this y
stripe raidset x and y; call this z

now, if I put a filesystem label on z and try to mount it using labels, it
doesn't work.  the raid drivers are all loaded and operating.  however, when the
mount process goes and looks for the label written on the partition, it finds a
matching label on raid device x.  and then it mounts x.  but since this is part
of a stripe, things go wonky.


obviously, it has been a while and I'm going by memory.  the above description
seems suspect to me.  it may in fact have been

stripe drive a and b; call this x
stripe drive c and d; call this y
mirror raid set x and y; call this z

then it makes more sense to me that the mount would incorrectly access x using
the label instead of z.

mounting raid10 with /dev/md? instead of LABEL=foo works.

Assigning to util-linux, where mount lives these days.

Bleah, this bug sucks to fix. I'm going to add something that ignores a device
if it has a raid superblock at the end - hopefully that will fix it.