FC6 upgrade stops at dmraid error

[devophl]

I'm upgrading a FC5 computer to FC6. I once set up the computer for software RAID but deleted it when I realized I wasn't gaining anything by having it. When I start the upgrade to FC6, the process aborts when its starts looking for an existing Fedora installation. The error is on the output of an ioctl right after querying for RAID devices.

When I run dmraid on FC5, it says no software RAID devices set up. When I boot in rescue mode off the FC6 install CD and run dmraid, it shows sda and sdb being ddf1 RAID devices. Humm... Clearly, the latest version of dmraid sees some that FC5's version doesn't. So the FC6 upgrade thinks there is a RAID setup on the hard drives and goes to mount the RAID partitions and finds out there isn't any and the anaconda script aborts.

I tried 'dmraid -r -E' but it errors trying to delete the metadata. I tried using mdadm but it goes nowhere since there isn't a md device set up.

I will try the nodmraid option on the upgrade bootup but from what I've read, this option doesn't get you very far.

So somewhere, there is a setting/flag on disk that says these are RAID disks and there must be a way of clearing that flag or this will happen again and again.

BTW, I was able to upgrade an identical system to FC6 without a problem. But at no time was that set up as a software RAID.

[stevea]

Do you still have a /etc/mdadm.conf ? Remove it.

[devophl]

Here's an update.

The nodmraid kernel option on the upgrade bootup did get me past the searching for existing Fedora installations screen. I have installed FC6 and am applying patches. On bootup, the

dmraid -r returns:

/dev/sda: ddf1, ".ddf1_disks", GROUP, ok, 156184464 sectors, data@ 0
/dev/sdb: ddf1, ".ddf1_disks", GROUP, ok, 156184464 sectors, data@ 0

If you try to erase the metadata:

# dmraid -r -E
Do you really want to erase "ddf1" ondisk metadata on /dev/sda ? [y/n] :y
ERROR: ddf1: seeking device "/dev/sda" to 40959999737856
ERROR: writing metadata to /dev/sda, offset 79999999488 sectors, size 0 bytes returned 0
ERROR: erasing ondisk metadata on /dev/sda

Doing anything with mdadm:

# mdadm --misc -Q /dev/md0
/dev/md0: is an md device which is not active

and there is no /etc/mdadm.conf file.

The system is now upgraded and has the latest patches. The dmraid situation doesn't seem to be affecting the running of the system, only the FC6 anaconda upgrade.

Here is a sample from the anacdump.txt file:

Traceback (most recent call first):
File "/usr/lib/python2.4/site-packages/block/__init__.py", line 18, in dm_log
raise Exception, message
File "/usr/lib/python2.4/site-packages/block/device.py", line 672, in get_map
self._RaidSet__map = _dm.map(name=self.name, table=self.rs.dmTable)
File "/usr/lib/python2.4/site-packages/block/device.py", line 765, in activate
self.map.dev.mknod(self.prefix+self.name)
File "/usr/lib/anaconda/dmraid.py", line 168, in startAllRaid
rs.activate(mknod=True)
...
Exception: device-mapper: reload ioctl failed: Invalid argument

Local variables in innermost frame:
message: device-mapper: reload ioctl failed: Invalid argument
line: 1574
file: ioctl/libdm-iface.c
level: 3
...
22:17:41 DEBUG : starting all dmraids on drives ['sda', 'sdb']
22:17:41 DEBUG : scanning for dmraid on drives ['sda', 'sdb']
22:17:42 DEBUG : got raidset <block.device.RaidSet instance at 0xb7c0322c> (sda sdb)
22:17:42 DEBUG : valid: True found_devs: 2 total_devs: 2
22:17:42 DEBUG : adding mapper/ddf1_Virtual Disk 1 to isys cache
22:17:42 DEBUG : adding sda to dm cache
22:17:42 DEBUG : removing sda from isys cache
22:17:42 DEBUG : adding sdb to dm cache
22:17:42 DEBUG : removing sdb from isys cache
22:17:42 DEBUG : starting raid <block.device.RaidSet instance at 0xb7c0322c> with mknod=True

[jpenix]

Did you mean to say that you originally set up the computer to use the "hardware" RAID provided by the BIOS? If so, then that's your problem. I just ran into this... I set up the in-BIOS hardware RAID on an Intel system (ICH8R), found that it wasn't recognized under Linux, and then went back into the BIOS and switched the drives to AHCI mode.

Note the missing step - I didn't "unconfigure" the drive set I created in the BIOS RAID. Apparently the metadata that it writes confuses device-mapper, and you wind up with your situation.

So go back into your BIOS and re-enable the hardware RAID. Then at the bootup RAID configuration screen, press Ctrl-E (or whatever key yours uses), and go in and explicitly delete the RAID set that was created. Then go back into the BIOS and turn the RAID off and then Fedora should be happy.

[devophl]

This is a Dell and I'm not sure if hardware RAID is supported by BIOS. We did have a hardware RAID card in the system but it was not supported by Fedora (was by RHEL). I then tried to set up software RAID but the result was unsatisfactory so I deleted the software RAID and repartitioned without RAID. We have mirrored backup computers so I felt there wasn't a need for RAID mirroring in the first place.

The problem seems to be between the dmraid output of FC5 and FC6. In FC5, dmraid shows no software RAID partitions. But in FC6, it does, despite not currently being configured as RAID. When I tried the upgrade, the anaconda session ran dmrain, saw RAID partitions and tried to start up RAID. Of course, without a RAID partition, this bombed and with it the install. Using nodmraid cured the problem and I was able to upgrade FC5 to FC6.

So somewhere on the disks (and I didn't modify BIOS), there is a flag that says the two drives are part of a ddf1 RAID1 setup. BTW, the partition table show only ext3 partitions, no RAID flags are set. Luckily the Linux bootup doesn't use this or I wouldn't be able to boot without a possible nodmraid switch.