Red Hat Bugzilla – Bug 141001
anaconda, md and mdadm seem to think FC1 didn't make RAID1 superblock
Last modified: 2007-11-30 17:10:55 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5)
Description of problem:
This will be longish, possibly involving problems in anaconda, md
and/or mdadm in FC1, FC2 and FC3. The most glaring problem is that FC3
anaconda crashes attempting to install on a machine with RAID1 devices
originally created by FC1 (via disk druid). Reverting to FC2 on this
machine works, but with warning messages that make me wonder if I can
trust md RAID1 devices there now. That there is potential loss of data
is why I have rated this high severity.
The FC3 anaconda crashes were both in graphical and text mode. The
graphical mode crash happened while I wasn't watching. X died and the
only message was about some Gtk error. Text mode crashed dumping a
couple of pages of undecipherable (to me) information, especially
since the first page went by so quickly. This seemed to happen when
the very first rpm install was starting. (I was watching.)
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. Install FC1 with RAID1 devices
2. Install FC2 reformatting /dev/md0 but not /dev/md1 or /dev/md2
3. Install FC3 reformatting /dev/md0 but not /dev/md1 or /dev/md2
4. Install FC2 reformatting /dev/md0 but not /dev/md1 or /dev/md2
Actual Results: Anaconda crash after step 3
"Scary" warning messages after step 4.
Expected Results: Everything AOK.
FC2 messages & boot.log tell me
Nov 27 13:00:54 mail kernel: md: personality 3 is not loaded!
Nov 27 13:01:31 mail mdmpd: mdmpd failed
FC2 df and adm tell me:
[root@mail log]# df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/md0 10080428 6706760 2861604 71% /
/dev/md1 27213796 20769420 5061992 81% /content
none 387924 0 387924 0% /dev/shm
/dev/md2 20161084 13924608 5212340 73% /home
[root@mail log]# mdadm --query /dev/md0
/dev/md0: 9.77GiB raid1 2 devices, 0 spares. Use mdadm --detail for
/dev/md0: No md super block found, not an md component.
[root@mail log]# mdadm --query /dev/md1
/dev/md1: 26.37GiB raid1 2 devices, 0 spares. Use mdadm --detail for
/dev/md1: No md super block found, not an md component.
[root@mail log]# mdadm --query /dev/md2
/dev/md2: 19.53GiB raid1 2 devices, 0 spares. Use mdadm --detail for
/dev/md2: No md super block found, not an md component.
FC2 /etc/raidtab tells me
[root@mail log]# cat /etc/raidtab
There are two distinct problem reports here.
1) FC3 (aka, 2.6 kernel based install) crashes when some raid devices are
created and some are reused.
2) Scary warning messages about md devices when inspected using mdadm.
The first problem is an anaconda bug and would need a separate bug report. The
most likely problem is a udev issue...basically that when restarting raid
arrays, anaconda attempts to open the raid array before the device node has been
created in the sysfs filesystem. The basic assumption that I think anaconda
makes (but I'm not sure) is that once a create ioctl on an array has completed,
then the array should be accessible. Due to changes in the 2.6 kernel and the
sysfs implementation, this is not necessarily true. If the ioctl to create a
raid array succeeds, then anaconda would need to keep checking for the device
file until it appears. Even if the device later goes offline, the device file
would still exist in the sysfs namespace, so waiting for it to appear is safe
from the possibility of spinning forever waiting for the file to appear.
The second problem is a usage issue. If you want mdadm to examine the
superblock of a raid array, then you can't tell it to examine the raid device
itself, it must examine one of the consituent devices of the array so that it
may read the superblock from the device and examine it. There is no bug nor
anything to worry about, it behaved exactly as expected when examining the raid