Created attachment 359655 [details] Bug report. Thanks to anaconda's scp. Description of problem: Anaconda crashes when detecting storage media. Version-Release number of selected component (if applicable): Fedora 11 install/live cd/dvd, Fedora 12/all rawhide anaconda releases. How reproducible: Every time I try to install Fedora, this crash occurs, basically, I can only install Fedora 10 and nothing newer. Steps to Reproduce: 1. Put in disk 2. Wait for anaconda to load 3. Click next 4. Choose English 5. Choose English 6. Crash Actual results: Unable to install Fedora 11+. Expected results: Anaconda should be able to detect my drives as it did in previous Fedora releases and also in every other Linux distribution. (Oh and Windows XP w/o drivers). Additional info: I have tried all versions past Fedora 10. Including Live CDs, Install DVDs, alpha's, beta's, nightly builds, etc. I believe I read somewhere that this occurred on some PPC systems; maybe not though. Also, I am using a Pentium 4, but have been using the i386 dvd's, nightlies, cd's, etc.
*** Bug 513666 has been marked as a duplicate of this bug. ***
It looks like your disk contains BIOS RAID / fake raid (LSI / ddf specifically) meta data. Is it supposed to contain that (iow is it part of a BIOS RAID set) ? Anyways even though it does that, anaconda should not crash. Can you please try again with F-12 alpha (or rawhide) and this updates.img: http://people.atrpms.net/~hdegoede/updates521033.img To use this add: updates=http://people.atrpms.net/~hdegoede/updates521033.img At the end of the cmdline in syslinux. If this stops the traceback, you will probably end up with anaconda not seeing one of your disks. This is deliberate as we simply ignore disks with invalid BIOS RAID metadata on them. To workaround this, use rawhide + the updates.img and then add nodmraid to the syslinux cmdline.
Wow, thank you for the quick response. Will the workaround be circumvented sometime soon? Can I do something to my drive (e.g. long format) to prevent the fake raid from appearing? Also, but why is this the only distribution of Linux that I have been running into this error with? Is there some kind of check that anaconda does that apparently no other distro does? I am giving the workaround a try a bit later today and will comment on the success or failure of it. Thanks again for the speedy response! -- Justin
(In reply to comment #3) > Wow, thank you for the quick response. > > Will the workaround be circumvented sometime soon? Can I do something to my > drive (e.g. long format) to prevent the fake raid from appearing? > So I guess the presence of this RAID metadata is unintentional ? in that case you can run: "dmraid -x" (from tty2 under the installer for example) to remove it, after that if you restart the installer it should be happy. dmraid -x should not touch the rest of the disk, but make backups first! > Also, but why is this the only distribution of Linux that I have been running > into this error with? Is there some kind of check that anaconda does that > apparently no other distro does? > This is due to the new way (using udev) anaconda probes drives since Fedora 11
(In reply to comment #4) > So I guess the presence of this RAID metadata is unintentional ? in that case > you can run: "dmraid -x" (from tty2 under the installer for example) to remove > it, after that if you restart the installer it should be happy. This is true. Could it be "left over" from when the device was attached to a raid controller card yet was never used as a raid device and the drive has been formated? If so, I guess if I ever use that hardware again (Adaptec Serial ATA II RAID 1420SA) I will just use dmraid -x on devices.
Created attachment 359707 [details] 521033 with updates521033.img Something changed with the updates img. I think the original issue was worked around, but a new one has come about.
I attempted the tty2 on the Fedora-12 Alpha dvd followed by dmraid -x on my two drives (sda and sdb), both failed with: ERROR: either the required RAID set not found or more options required no raid set and with names: "/dev/sda" --also-- no raid set and with names: "/dev/sdb" So I tried dmraid -r: /dev/sdb: ddf1, ".ddf1_disks", GROUP, ok, 48821574 sectors, data@ 0 /dev/sda: ddf1, ".ddf1_disks", GROUP, ok, 48821574 sectors, data@ 0 Then tried dmraid -x ddf1: ERROR: either the required RAID set not found or more options required no raid set and with names: "ddf1" Am I doing it wrong?
(In reply to comment #6) > Created an attachment (id=359707) [details] > 521033 with updates521033.img > > Something changed with the updates img. I think the original issue was worked > around, but a new one has come about. Ah that is bug 518971 (which is fixed in current rawhide) (In reply to comment #7) > I attempted the tty2 on the Fedora-12 Alpha dvd followed by dmraid -x on my two > drives (sda and sdb), both failed with: > AFAIK you can run "dmraid -x" without specifying any drives, that should do the trick I think.
(In reply to comment #8) > Ah that is bug 518971 (which is fixed in current rawhide) Current as in post Alpha 1 release? > AFAIK you can run "dmraid -x" without specifying any drives, that should do > the trick I think. I will give it a try in a bit. Thanks.
(In reply to comment #9) > (In reply to comment #8) > > > Ah that is bug 518971 (which is fixed in current rawhide) > Current as in post Alpha 1 release? > Yes, current as in fixed 2 days ago (by me :)
Awesome, I will grab a nightly build and try it. (I am working so it will be a bit).
(In reply to comment #2) I need to read closer, this works. Thanks for your help! > To workaround this, use rawhide + the updates.img and then add nodmraid to > the syslinux cmdline. If you need, let me know and I will post a dmraid -r -vvv . The dmraid detected something about the Adaptec device mentioned earlier, but that device is no longer in my machine and the hard drives are plugged directly into my motherboard.
Installation finished! However, a new problem: -------------------------------------------------------------- dracut: Scanning for dmraid devices dracut: Scanning for dmraid devices dracut: no raid sets dracut: no raid sets No root device found dracut: Scanning for dmraid devices dracut: ERROR: no RAID set found dracut: no raid sets No root device found Boot has failed, sleeping forever. -------------------------------------------------------------- This occurs with nodmraid passed or not passed during boot (from grub).
Created attachment 359747 [details] dmraid -r -vvv I booted the net install with the updates=http://people.atrpms.net/~hdegoede/updates521033.img and the nodmraid and ran dmraid -r -vvv; this is the output from that command.
(In reply to comment #13) > Installation finished! > > However, a new problem: > > -------------------------------------------------------------- > dracut: Scanning for dmraid devices > dracut: Scanning for dmraid devices > dracut: no raid sets > dracut: no raid sets > > No root device found > dracut: Scanning for dmraid devices > dracut: ERROR: no RAID set found > dracut: no raid sets > > No root device found > > Boot has failed, sleeping forever. > -------------------------------------------------------------- > > This occurs with nodmraid passed or not passed during boot (from grub). Ah yes, dracut our new initrd does not honor nodmraid, can you file a bug against dracut for this please, and assign it to me, thanks. Also did you try the just "dmraid -x" to remove the old stale adaptec raid metadata from the disks ?
python-pyblock-0.43.1, which contains the fix from the updates.img is on its way to rawhide. So I'm going to close this bug, as the backtrace is gone now. I'm afraid that unless "dmraid -x" works, you are stuck with the nodmraid workaround. There is nothing we can do at the installer level when the disks contain invalid BIOS RAID metadata, ignoring this can be dangerous (for example when it actually is valid, but there is a bug in dmraid, this happens from time to time), as we can then damage partitions in use by other operating systems. Like wise offering to remove the metadata is very dangerous. So our best cause of action really is to just ignore disks with BIOS RAID metadata which we do not grok. As for the nodmraid workaround not working for you, because dracut does not honor it, that is a different bug, and one which we need to fix, as said before please file a new bug for this.
*** Bug 505725 has been marked as a duplicate of this bug. ***
*** Bug 519527 has been marked as a duplicate of this bug. ***