Red Hat Bugzilla – Bug 742888
F16Beta Anaconda crashes when trying to rescue install on BIOS RAID
Last modified: 2013-02-13 20:09:35 EST
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
Steps to Reproduce:
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
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
Have a look at the logfiles that I will upload in a minute.
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
I do suspect it has to do with raid1 devices being in a dirty state when
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:
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.