Bug 471741
Summary: | Can't install Fedora on precreated software RAID | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|
Product: | [Fedora] Fedora | Reporter: | m.cencora | ||||||||
Component: | mdadm | Assignee: | Doug Ledford <dledford> | ||||||||
Status: | CLOSED ERRATA | QA Contact: | Fedora Extras Quality Assurance <extras-qa> | ||||||||
Severity: | medium | Docs Contact: | |||||||||
Priority: | medium | ||||||||||
Version: | 10 | CC: | bill-bugzilla.redhat.com, dledford, fdc, gunnar_thielebein, leo, notting, pza, tjb | ||||||||
Target Milestone: | --- | ||||||||||
Target Release: | --- | ||||||||||
Hardware: | All | ||||||||||
OS: | Linux | ||||||||||
Whiteboard: | |||||||||||
Fixed In Version: | 2.6.9-1.fc10 | Doc Type: | Bug Fix | ||||||||
Doc Text: | Story Points: | --- | |||||||||
Clone Of: | Environment: | ||||||||||
Last Closed: | 2009-07-22 22:04:56 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: | |||||||||||
Attachments: |
|
Description
m.cencora
2008-11-15 13:25:28 UTC
*** Bug 471739 has been marked as a duplicate of this bug. *** To sum up there's are race condition (between kernel and anaconda) when assembling RAID devices Can you attach /tmp/anaconda.log and /tmp/syslog to this bug report? Thanks. I'm sorry I can't. I've already installed Fedora on normal partition, then migrated to RAID so I can't test it anymore. AFAICT, this mdadm auto-assembly failing when there's no mdadm.conf, or the device isn't listed there. I'll attach the mdadm runs on boot from an example case of this. In this case, I have a two-partition RAID-1 array (sda2 and sda3). After booting /proc/mdstat just shows: Personalities: md_d0: inactive sda3[1](S) Attempting to (post-boot) add the other partition yields: # /sbin/mdadm -I --auto=yes /dev/sda2 mdadm: failed to open /dev/md/d0: File exists Created attachment 324331 [details]
strace of incremental add of /dev/sda2 on boot
Created attachment 324332 [details]
strace of incremental add of /dev/sda3 on boot
This is with mdadm-2.6.7.1-1.fc10. This bug appears to have been reported against 'rawhide' during the Fedora 10 development cycle. Changing version to '10'. More information and reason for this action is here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping The md_d[0-n] devices are created by the udev-rule 70-mdadm.rules: SUBSYSTEM=="block", ACTION=="add|change", ENV{ID_FS_TYPE}=="linux_raid*", \ RUN+="/sbin/mdadm -I --auto=yes $root/%k" If you change auto=yes to auto=md, mdadm will autocreate md[0-n] style devices and automatically start the array using this device name. Having applied this modification, installation from a f10-live-cd works as expected. (At least on my system.) --leo Created attachment 326826 [details]
Patch to make udev create md[0-9] style raid devices
While this patch will make normal arrays auto assemble correctly, it will break assembly of partitionable arrays. I'm looking into a fix that will solve both cases. Please let me know if this should be reported as a different bug. I recenty installed rawhide, and reused my existing FC 10 software raid partitions: Raid-1 for /boot & / (reformatted during installation) Raid-0 /data Installation went fine, however it didn't boot. After a lot of screwing around, I worked out that it was because mkinitrd didn't include the raid1 driver so it couldn't find the root filesystem. I booted from a recovery CD and re-ran mkinitrd, then everything was fine. btw.... I found it extremly difficult to track this problem down, as the new boot process seems to hide error messages, even if you remove quiet & rhgb from the kernel command line. Very frustrating indeed. Another bug report. There are two causes for split array hysteresis that we found during the F11 development cycle: 1) specific to the install environment, running mdadm -I on array members fails because /var/run/mdadm/mdadm.map can't be written to. Unless mdadm can write to that file, it can not confirm that the first device already allocated to /dev/md0 and the device being added belong to the same array, so it fails with device already exists. 2) there is a race condition between mdadm -A and mdadm -I in the initscripts and udev files, in this situation mdadm -I is trying to start the array one device at a time, while mdadm -A is trying to start the array all in one go. mdadm -I will manage to get one or more of the devices prior to mdadm -A being able to lock them all down, and you end up with partially assembled arrays. I've built a new mdadm (2.6.9) with a new udev rules file that should address the second problem. However, the first problem would require respun install images to be solved and is beyond the scope of what I can do. mdadm-2.6.9-1.fc10 has been submitted as an update for Fedora 10. http://admin.fedoraproject.org/updates/mdadm-2.6.9-1.fc10 mdadm-2.6.9-1.fc10 has been pushed to the Fedora 10 testing repository. If problems still persist, please make note of it in this bug report. If you want to test the update, you can install it with su -c 'yum --enablerepo=updates-testing update mdadm'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-7263 mdadm-2.6.9-1.fc10 has been pushed to the Fedora 10 stable repository. If problems still persist, please make note of it in this bug report. Should problem #1 from comment #14 be filed a a separate bug to be addressed for F12? No, that problem was addressed already in mdadm-3.0 (problem + patch sent upstream prior to 3.0's release, slightly different implementation that still works was included upstream). Super, thanks Doug. |