Created attachment 526008 [details] picture of crash screen Description of problem: Upgraded from F15 to F16Beta on a system running software BIOS RAID, which means the system disk shows up md126. Something went wrong with the boot loader install in the upgrade, so I tried F16's Fedora rescue mode, using the F16Beta image installed onto a USB stick using livecd-tools. When examining the system looking for the disks, Anaconda explodes without giving me access to the mode where I can save the crash log etc. Photo of crash screen attached instead. Version-Release number of selected component (if applicable): Whatever is in F16Beta How reproducible: Every time Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Created attachment 526017 [details] anaconda.log from similar crash during install anaconda.log from trying a fresh install with F16Beta from a DVD
Please attach /tmp/program.log and /tmp/storage.log from the rescue or install attempt.
There's a problem in the interaction between anaconda and mdadm's new systemd service that activates all md devices it can find, this one specific to fwraid types handled by mdadm. I have a similar system here I can work on and will update the bug when I have news.
+1 blocker, per Beta criterion "The rescue mode of the installer must be able to detect and mount (read-write and read-only) LVM, encrypted, and RAID (BIOS, hardware, and software) installations".
I did an install of the beta by netinst-iso-on-usb and did not have any issues like this. My system uses imsm raid0 across two physical disks. The immediate problem I see in your logs is that the udevdb entry for md126 does not contain any of the information that would normally be imported via /lib/udev/rules.d/64-md-raid.rules. Is there something about your array that causes it to be in some non-standard state when it first gets started (eg: clear, inactive)? As soon as you seen the first anaconda screen, switch to tty2 and cat /proc/mdstat just in case there's anything that jumps out at us.
I spent all morning trying to reproduce this, but I cannot get it to go up in flames the same way as it did when I first tried. I did get it to crash though, so I will upload a fresh set of logfiles, including the mdstat output. Note that when I first had this problem, the system had just two disks, which I configured as one large IMSM raid in raid1 mode. It is likely the issue is related to the disks syncing in raid1 mode when they are first created. Have a look at the logfiles that I will upload in a minute. Cheers, Jes
The last logs are from a completely unrelated bug (bug 731356).
I was afraid of that :( I will try again later and see if I can reproduce it again. I do suspect it has to do with raid1 devices being in a dirty state when it happens.
Discussed at 2011-10-07 blocker review meeting. Rejected as a blocker as it's unreproducible and seems to be caused by dirty RAID state.
This message is a reminder that Fedora 16 is nearing its end of life. Approximately 4 (four) weeks from now Fedora will stop maintaining and issuing updates for Fedora 16. It is Fedora's policy to close all bug reports from releases that are no longer maintained. At that time this bug will be closed as WONTFIX if it remains open with a Fedora 'version' of '16'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version prior to Fedora 16's end of life. Bug Reporter: Thank you for reporting this issue and we are sorry that we may not be able to fix it before Fedora 16 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged to click on "Clone This Bug" and open it against that version of Fedora. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete. The process we are following is described here: http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Fedora 16 changed to end-of-life (EOL) status on 2013-02-12. Fedora 16 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. Thank you for reporting this bug and we are sorry it could not be fixed.