Bug 141001
| Summary: | anaconda, md and mdadm seem to think FC1 didn't make RAID1 superblock | ||
|---|---|---|---|
| Product: | [Fedora] Fedora | Reporter: | Charlie Sauer <sauer> |
| Component: | mdadm | Assignee: | Doug Ledford <dledford> |
| Status: | CLOSED NOTABUG | QA Contact: | |
| Severity: | high | Docs Contact: | |
| Priority: | medium | ||
| Version: | 3 | ||
| Target Milestone: | --- | ||
| Target Release: | --- | ||
| Hardware: | i686 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Fixed In Version: | Doc Type: | Bug Fix | |
| Doc Text: | Story Points: | --- | |
| Clone Of: | Environment: | ||
| Last Closed: | 2005-10-18 01:48:05 UTC | Type: | --- |
| Regression: | --- | Mount Type: | --- |
| Documentation: | --- | CRM: | |
| Verified Versions: | Category: | --- | |
| oVirt Team: | --- | RHEL 7.3 requirements from Atomic Host: | |
| Cloudforms Team: | --- | Target Upstream Version: | |
| Embargoed: | |||
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. |
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