From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.0.1) Gecko/20060207 Fedora/1.5.0.1-2.1 Firefox/1.5.0.1 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 () from /usr/lib64/python2.4/site-packages/block/dmraidmodule.so 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): python-pyblock-0.13-1 device-mapper-1.02.02-3.1 How reproducible: Always 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 Additional info:
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 the problem...
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: http://fedoraproject.org/wiki/BugZappers/F9CleanUp 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: http://fedoraproject.org/wiki/BugZappers/HouseKeeping