Red Hat Bugzilla – Bug 506861
Anaconda must warn (print (kickstart) or dialog) when ignoring BIOS RAID disks
Last modified: 2010-02-18 09:49:26 EST
In Fedora11, I tried to perform an installation. I was very surprised when anaconda didn't provide me with any disks. It just seemed like the installer didn't think there were any. So I tried various options to the kernel command line to try to work around this. I later found that, when I shelled out while anaconda was running (hit ENTER on the terminal window when using the vnc install mode).... That the disk was indeed present to the install environment. I could use parted on it, I could re-partition it, etc. However, anconda just seemed blind to it. At that point, I started sniffing around the logs. I saw this: [2009-06-16 20:31:17,816] DEBUG: type detected on 'sdb' is 'ddf_raid_member' [2009-06-16 20:31:17,817] DEBUG: getFormat('ddf_raid_member') returning DMRaidMember instance I could further confirm it by shelling out from anaconda and typing this: sh-4.0# dmraid -r /dev/sda: ddf1, ".ddf1_disks", GROUP, ok, 285155328 sectors, data@ 0 However, simply using dmrraid with -r and -E didn't work, it produced errors! So I couldn't even use dmraid to clear the problem: sh-4.0# dmraid -E -r Do you really want to erase "ddf1" ondisk metadata on /dev/sda ? [y/n] :y ERROR: ddf1: seeking device "/dev/sda" to 75169657520128 ERROR: writing metadata to /dev/sda, offset 146815737344 sectors, size 0 bytes returned 0 ERROR: erasing ondisk metadata on /dev/sda So now I was perplexed. Here I had discovered there was indeed dmraid metadata on it... But I couldn't even erase it using dmraid. What I finally did was start up parted and change the partition label on the problem disk from msdos to gpt. I then switched it back to msdos. I did this knowing that gpt stores label info at the front and back so I suspected it might wipe out the errant raid label. This indeed worked. After doing that, anaconda properly allowed me to choose the storage. (That was a quick hack, I was going to try dding the front and back if parted msdos->gpt->msdos didn't wipe it, I was just too lazy to figure out the syntax). My guess is this disk came out of a system that had bios-assisted software raid. They just tossed that drive in to the system for me to use not knowing that it had metadata poison. I'd like to be careful here, however. It's important that we don't BLINDLY consider disks with dmraid metadata for re-installation, at least in my opinion. We don't want to accidentally destroy any dmraid's that are legit. My suggestion would be -- especially when anaconda is presented with a system where no disks are found -- to tell the customer that one or more disks with dmraid metadata was found and if those disks wish to be used by the install program, you should clean them. It might be nice to mention how -- perhaps a couple dd commands that erase the front and back of the disk to truly clean that stuff out. Finally, we do want to be careful to not cause trouble in situations where there could be hundreds of disks attached. Thanks for your consideration.
Created attachment 348581 [details] anaconda.log
Created attachment 348582 [details] program.log
Created attachment 348583 [details] storage.log
I am currently planning to add a prompt when anaconda encounters incomplete biosraid arrays to offer the opportunity to reinitialize the disk(s). I expect to have a patch sometime next week.
Erik, We (me and Dave Lehman) have just discussed this, and for a number of reasons for now we will be sticking to ignoring the disks, for a number of reasons 1) All these metadata formats are manufacturer specific and tend to get extended over time, so sometimes we fail to properly bring up a proper valid BIOS RAID set due to not completely understanding the format. In the past this has happened quite often, in this case we don't want user to start clicking the "sure go ahead" button and then later finding out all their data is "gone" 2) As you've discovered yourself dmraid's metadata removal is not all that solid. We do however plan to add a warning dialog whenever one or more disks where ignored because of this and users can workaround the problem by specifying nodmraid on the installer cmdline when starting it, this will cause all BIOS RAID data to be ignored during installation time, and during subsequent boots of that installation. Keeping this bug open to track the addition of the warning dialog.
*** Bug 547560 has been marked as a duplicate of this bug. ***
This is fixed in anaconda-13.27-1 by this commit: http://git.fedorahosted.org/git/?p=anaconda.git;a=commitdiff;h=2cb900c168a536336b89a3b5312d6e7991236721 Closing.