Bug 141001 - anaconda, md and mdadm seem to think FC1 didn't make RAID1 superblock
anaconda, md and mdadm seem to think FC1 didn't make RAID1 superblock
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: mdadm (Show other bugs)
3
i686 Linux
medium Severity high
: ---
: ---
Assigned To: Doug Ledford
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2004-11-27 15:41 EST by Charlie Sauer
Modified: 2007-11-30 17:10 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-10-17 21:48:05 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Charlie Sauer 2004-11-27 15:41:47 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.5)
Gecko/20041107 Firefox/1.0

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):


How reproducible:
Always

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.

Additional info:

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
more detail.
/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
more detail.
/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
more detail.
/dev/md2: No md super block found, not an md component.

FC2 /etc/raidtab tells me
[root@mail log]# cat /etc/raidtab 
raiddev             /dev/md0
raid-level                  1
nr-raid-disks               2
chunk-size                  256
persistent-superblock       1
nr-spare-disks              0
    device          /dev/hda2
    raid-disk     0
    device          /dev/hdb2
    raid-disk     1
raiddev             /dev/md1
raid-level                  1
nr-raid-disks               2
chunk-size                  256
persistent-superblock       1
nr-spare-disks              0
    device          /dev/hda5
    raid-disk     0
    device          /dev/hdb5
    raid-disk     1
raiddev             /dev/md2
raid-level                  1
nr-raid-disks               2
chunk-size                  256
persistent-superblock       1
nr-spare-disks              0
    device          /dev/hda3
    raid-disk     0
    device          /dev/hdb3
    raid-disk     1
Comment 1 Doug Ledford 2005-10-17 21:48:05 EDT
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
device itself.

Note You need to log in before you can comment on or make changes to this bug.