From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:126.96.36.199) Gecko/20060207 Fedora/188.8.131.52-2.1 Firefox/184.108.40.206
Description of problem:
After I ask the installer to search for installed disks, it crashes. I attached gdb to it to figure out where:
Program received signal SIGSEGV, Segmentation fault.
0x00002b7ab4bcd408 in free_raid_set ()
I was able to install FC4 on this box that I got for myself just two days ago, but I've had no luck with FC5T2 or rawhide because of this problem.
The box has two SATA disks connected to the Promise Fasttrack controller built into the motherboard. They're configured in the BIOS as separate individual disks, not as an array.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1.Boot up FC5T2 or rawhide rescue CD in rescue or install mode
2.In rescue mode, proceed to the `scan for existing installations' screen
3.Click on `ok'
Actual Results: It crashes almost instantly
Expected Results: It shouldn't crash
As it turns out, free_raid_set is in dmraid, python-pyblock just happens to link
with it and pull it in because it's a static library.
Got the same error with the 32-bit rescuecd, so it's not some 64-bit error.
Further investigation shows the crash occurs on line 393 of
lib/metadata/metadata.c, because (elem)->next is NULL when we attempt to write
to it (elem)->next->prev. It's the second time free_raid_set is called in the
session, if it makes any difference.
This second time is called from group_set, FWIW.
Booting with nodmraid works around the problem entirely. Yay!
Hrm, if the list of RAID devices contains a mamber, it will be added to it
properly using list_add_tail() in list_add_sorted(), file metadata.c, which sets
up the double-linked list pointers fine.
Can I have a full backtrace of this, please.
group_set is called by Python native interfaces, and I've no idea of how to
decode that, nevermind within the limited environment that the installer offers.
FWIW, in FC5 it doesn't crash, but rather gets into some infinite loop. Maybe
there's a signal handler that tries to avoid the ugly crash but ends up leaving
the installer in an half-dead state, arguably much worse unless you know about
This is still broken in rawhide, and I know more people who trip into this.
I still need a backtrace of this.
Preferably a metadata dump using dd if not feasible with "dmraid -rD"
in order to reproduce this here.
Not much I can do without such.
Is this still an issue ?
Or do newer versions work ?
Anaconda still looped indefinitely last night, when I tried to install F7 on it.
nodmraid got it to work.
# dmraid -rD
/dev/sdc: pdc, "pdc_cghebjhaaa", stripe, ok, 490234624 sectors, data@ 0
/dev/sdd: pdc, "pdc_cgicgfbbee", stripe, ok, 490234624 sectors, data@ 0
Still a problem (infinite loop) in Fedora 8 :-(
What info do you need? Any idea how to get it, given that the installer just
freezes on me, unless I use nodmraid?
Based on the date this bug was created, it appears to have been reported
against rawhide during the development of a Fedora release that is no
longer maintained. In order to refocus our efforts as a project we are
flagging all of the open bugs for releases which are no longer
maintained. If this bug remains in NEEDINFO thirty (30) days from now,
we will automatically close it.
If you can reproduce this bug in a maintained Fedora version (7, 8, or
rawhide), please change this bug to the respective version and change
the status to ASSIGNED. (If you're unable to change the bug's version
or status, add a comment to the bug and someone will change it for you.)
Thanks for your help, and we apologize again that we haven't handled
these issues to this point.
The process we're following is outlined here:
We will be following the process here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping to ensure this
doesn't happen again.
Reported as still broken on Fedora 8. I'm pretty sure I got it with early 9
pre-alpha too, but I haven't re-installed ever since. I'll probably be able to
give it another try one of these days, maybe by the end of April or so.
Unfortunately, that's unlikely to be before the 20th :-(
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here: