Description of problem: While trying to install using a boot disk from FC5t3 I am getting a consistent segfault right after installation language and keyboard choice screens. The whole screen goes blank with an "underscore" cursor blinking in the left upper corner and that is about it. What is worse a keyboard also stops responding save console switch keys so I cannot look at or save logs even if I am seeing 'sh-3.1#'. SysRQ keys sort of work although responses are somewhat random, so it is hard to tell what was really requested, and if something does happen then most of information scrolls of a screen. (At some moment I got what looks like a register dump but after that a keyboard froze completely and I cannot tell if this is even related to the original program - a picture of a screen attached). This is what I copied of screens: ....... Starting graphical installation install exited abnormally .... (folllowed by regular "unmounting" and "you can reboot") and on another screen: <6> anaconda [642]: segfault at 0000000000000008 rip 00002ae89211abdb rsp 00007ffffffa17e60 error 6 A video card is Radeon 9500 (r300) but attempts to add to a kernel extra boot parameters like 'acpi=off' or 'nofb', separately or in combinations, do not change anything in this picture. Doing 'linux text' also ends up with the same crash and with this added attraction that the moment installation process takes over a screen is garbled to such extent that practically unusable and it would be really scary to try to handle file systems using that. How reproducible: always
Created attachment 125050 [details] some kind of a register dump after anaconda crashed
If you hit ctrl-s at "Starting anaconda" and switch to tty2 and run ddcprobe, does it segfault?
No, it does not segfault. It prints: Videocard autoprobe results Description: ATI Technologies Inc. R300 Memory (MB): 64 Monitor autoprobe results Monitor autoprobe failed. The last line is not the great surprise. This monitor happens to be a pretty old KDS; but it works well enough. Like I wrote - initial screens do show up and crash happens only a bit later. Also ddc-fu.2 from http://people.redhat.com/notting/ does work and prints - class: VIDEO bus: DDC detached: 0 desc: "ATI Technologies Inc. R300" mem: 65536 although this one was about kudzu problems.
I have an almost identical problem with my x86_64 machine, but I can proceed with a successful installation provided I unplug my SATA drives during the installation. After install, I can reattach the SATA drives and everything works successfully. The motherboard is an Asus A8N32-SLI Deluxe with nForce 4 chipset.
Re comment #4: Thanks, that could be it. With this exception that I cannot unplug my SATA drives. There are no other drives in my test machine. :-)
Can you try it and at least see if it resolves the segfault? Although you won't be able to complete the install, you should be able to at least get into the second stage
Can you help with how to run that in a testing mode? With anaconda-10.92.11-1 when I am trying to run it, from a disk, like that: anaconda --test --method=cdrom://mnt/cdrom while booted as single-user, then I see "...probing..." followed by "starting X server" (or something to that effect) and then everything goes blank and a keyboard is dead and I have to power down. An attempt to run as anaconda --test --text --method=cdrom://mnt/cdrom ends up with a traceback (reformatted): Traceback (most recent call last): File "/usr/sbin/anaconda", line 1092, in ? methodobj = CdromInstallMethod(method, rootPath, intf) File "/usr/lib/anaconda/image.py", line 358, in __init__ (self.device, tree) = string.split(url, ":", 1) ValueError: need more than 1 value to unpack Actually this "dead after trying to start X" makes me to scratch my head. That part used to work.
It needs to be --method=cdrom::hdc:/mnt/cdrom now. As a thought, do you have any USB storage devices?
> It needs to be --method=cdrom::hdc:/mnt/cdrom now. I am afraid that this does not work. Every time this method string does not start with "cdrom://" then I see "CRITICAL: unknown install method" and a corresponding alert. Some variations with ":hdc" appended also do not seem to go anywhere. > As a thought, do you have any USB storage devices? Big enough? Only eight time zones away at the moment.
Err, wow. I can't type today :/ That should have been --method=cdrom://hdc:/mnt/cdrom The question about USB storage devices is because I just found a segfault which could get triggered if you have some classes of USB storage devices attached to the system.
> That should have been --method=cdrom://hdc:/mnt/cdrom I tried that already as one of posibilities. :-) With 'anaconda --test --text --method=cdrom://hdc:/mnt/cdrom' while at level 1 I just get a blue screen and nothing happens. While at level 3 I see three lines of garbage dumped at the top of this blue screen and attaching 'strace' shows a tight loop of that sort: ..... --- SIGSEGV (Segmentation fault) @ 0 (0) --- rt_sigaction(SIGSEGV, {0x3712abbab0, [], SA_RESTORER, 0x370ef0cd80}, {0x3712abbab0, [], SA_RESTORER, 0x370ef0cd80}, 8) = 0 rt_sigreturn(0xb) = 0 --- SIGSEGV (Segmentation fault) @ 0 (0) --- rt_sigaction(SIGSEGV, {0x3712abbab0, [], SA_RESTORER, 0x370ef0cd80}, {0x3712abbab0, [], SA_RESTORER, 0x370ef0cd80}, 8) = 0 rt_sigreturn(0xb) = 0 --- SIGSEGV (Segmentation fault) @ 0 (0) --- rt_sigaction(SIGSEGV, {0x3712abbab0, [], SA_RESTORER, 0x370ef0cd80}, {0x3712abbab0, [], SA_RESTORER, 0x370ef0cd80}, 8) = 0 rt_sigreturn(0xb) = 0 --- SIGSEGV (Segmentation fault) @ 0 (0) --- rt_sigaction(SIGSEGV, {0x3712abbab0, [], SA_RESTORER, 0x370ef0cd80}, {0x3712abbab0, [], SA_RESTORER, 0x370ef0cd80}, 8) = 0 ..... > The question about USB storage devices is because I just found a segfault No USB devices are attached at this moment. 'lsusb' shows though: Unknown line at line 5924 Unknown line at line 5925 Unknown line at line 5926 Unknown line at line 5927 Unknown line at line 5928 Unknown line at line 5929 Unknown line at line 5930 Unknown line at line 5931 Unknown line at line 5932 Unknown line at line 5933 Unknown line at line 5934 Unknown line at line 5935 Bus 002 Device 001: ID 0000:0000 Bus 005 Device 001: ID 0000:0000 Bus 004 Device 001: ID 0000:0000 Bus 003 Device 001: ID 0000:0000 Bus 001 Device 001: ID 0000:0000 and I do not recall ever seeing this "Unknown" (which does not show up with 'lsusb -v' unless I will remove USB modules). Without USB modules loaded this SIGSEGV loop is still there.
I also have no usb devices attached at the time of install and the segv. Let me know if there is any testing I can do to help you out. The machine in question is running FC5T2 at the moment, and I overlaid the FC5T3 install with an FC4 install, but I can put back again, no problem.
With anaconda-10.92.14-1 and after booting with 'nousb', so no USB modules are loaded at all, I still see "SIGSEGV loop" as described in comment #11.
Is this any better in FC5 final?
As I recall, I had to unplug my SATA drives in order to get FC5 final to install successfully on my IDE drive, then plug them back in again. Is there an easier test than re-installing ? I can re-install on an unused partition and provide some additional information.
> Is this any better in FC5 final? I am afraid that I do not have a good answer to that question. I did install FC5 on various machines but not on that particular hardware. Comment #15 suggests that not much really changed.
No activity in 8 months, FC5 respins aren't available to test AFAIK.