Created attachment 432867 [details]
Description of problem:
- Anaconda show error: "Disk sdb contains BIOS RAID metadata, but is not part of any recognized BIOS RAID sets. Ignoring disk sdb."
- IMSM RAID volume does not start (only container is assembled but not RAID volume).
- mdmon is not running (see syslog with crash info)
Steps to Reproduce:
1. Clear all metadata on drives using command: mdadm --zero-superblock /dev/sd[a-f]
2. Create RAID1 in Intel OROM on 2 HDDs
3. Start kickstart installation using config file like:
nfs --server=172.28.58.30 --dir=/pxe/auto-installation
firewall --enable --ssh
authconfig --enableshadow --enablemd5
timezone --utc America/New_York
bootloader --location=boot --driveorder=md127 --append="pci=nommconf rhgb quiet"
part pv.039936 --size=1 --grow --ondisk=md127
volgroup lvmvolgroup0 --pesize=32768 pv.039936
logvol / --fstype ext3 --size=37274 --name=lvm_root --vgname=lvmvolgroup0
logvol swap --fstype swap --size=2662 --name=lvm_swap --vgname=lvmvolgroup0
part /boot --fstype ext2 --size=2662 --ondisk=md127
echo 1279539657 > /tmp/os_stamp
4. Installation passes and OS is bootable
5. Delete RAID in OROM and create it again (the same volume as before)
6. Start installation again with the same config file and installation process will be interrupted.
# cat /proc/mdstat
Personalities : [raid0] [raid1] [raid6] [raid5] [raid4] [raid10] [linear]
md0 : inactive sdb(S)
2257 blocks super external:imsm
unused devices: <none>
RAID volume is not assembled, mdmon crashes
RAID volume should be assembled properly during installation
SW: RHEL 6.0 Snapshot 7 x64
HW: DQ35JOE - ICH9 chipset
Manually delete metadata from drives using mdadm --zero-superblock command.
Created attachment 432868 [details]
Created attachment 432869 [details]
Created attachment 432870 [details]
Created attachment 432871 [details]
This issue has been proposed when we are only considering blocker
issues in the current Red Hat Enterprise Linux release. It has
been denied for the current Red Hat Enterprise Linux release.
** If you would still like this issue considered for the current
release, ask your support representative to file as a blocker on
your behalf. Otherwise ask that it be considered for the next
Red Hat Enterprise Linux release. **
when I created IMSM (Intel) RAID 1, the installer found BIOS RAID 0MB size, ddf1_raidddf. Can you point me more closely to the place in anaconda code that that is doing RAID discovery.
anaconda does not activates degraded array, therefore in case when some array member is missing the array is not activated, and the system is not installed.
In the this particular reproduction method, it could happen that /dev/sda was part of array, and kickstart instructed anaconda to ignore the RAID member disk (*ignoredisk --drives=sda*).
In general, all disks must be present in system, and it is suggested that IMSM metadata is the only one on the disks that are part of RAID volume on which the system is going to be installed.
Lowering priority of the bug.
In general, even if we are going to support installing on existing raid devices that are degraded, it's going to be up to anaconda to force their degraded assembly. As such, I'm changing the component to anaconda on this bug as I don't think mdadm has anything it needs to do.
anaconda has never supported installation to degraded arrays. It's not something we intend to support.
(In reply to comment #10)
> anaconda has never supported installation to degraded arrays. It's not
> something we intend to support.
I think that the information that user receives in the situation of not activating/using degraded array is not clear; maybe anaconda could display more specific information like: list of disk that are taken into account when trying activate and the information that RAID device is not going to be activated because it is in degraded or failed state.
Is it possible to display the name of BIOS raid: like DDF or IMSM, etc.
Current information: "Disk sdb contains BIOS RAID metadata, but is not part
of any recognized BIOS RAID sets. Ignoring disk sdb."
Not reproducible on RHEL6.0 Snapshot 10 x86_64.