Bug 742888

Summary: F16Beta Anaconda crashes when trying to rescue install on BIOS RAID
Product: [Fedora] Fedora Reporter: Jes Sorensen <Jes.Sorensen>
Component: anacondaAssignee: David Lehman <dlehman>
Status: CLOSED WONTFIX QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 16CC: awilliam, jonathan, vanmeeuwen+fedora
Target Milestone: ---   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard: RejectedBlocker
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-02-13 20:09:31 EST Type: ---
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
Description Flags
picture of crash screen
anaconda.log from similar crash during install none

Description Jes Sorensen 2011-10-03 05:42:26 EDT
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:
Actual results:

Expected results:

Additional info:
Comment 1 Jes Sorensen 2011-10-03 06:46:32 EDT
Created attachment 526017 [details]
anaconda.log from similar crash during install

anaconda.log from trying a fresh install with F16Beta from a DVD
Comment 3 David Lehman 2011-10-03 11:21:51 EDT
Please attach /tmp/program.log and /tmp/storage.log from the rescue or install attempt.
Comment 6 David Lehman 2011-10-03 13:00:00 EDT
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.
Comment 7 Adam Williamson 2011-10-04 16:46:10 EDT
+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".
Comment 8 David Lehman 2011-10-05 16:03:32 EDT
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.
Comment 9 Jes Sorensen 2011-10-06 06:35:15 EDT
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.

Comment 16 David Lehman 2011-10-06 10:16:29 EDT
The last logs are from a completely unrelated bug (bug 731356).
Comment 17 Jes Sorensen 2011-10-06 10:27:11 EDT
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.
Comment 18 Adam Williamson 2011-10-07 13:37:36 EDT
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.
Comment 19 Fedora End Of Life 2013-01-16 17:36:31 EST
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: 
Comment 20 Fedora End Of Life 2013-02-13 20:09:35 EST
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.