Description of problem: I used currently available files from 'isolinux' directory and tried to start anaconda booting over a network. I see on my screen: ..... anaconda installer init version 11.2.0.25 starting .... mounting /tmp as ramfs... done running install... running /sbin/loader Now I would expect to see that usb-storage module is loaded followed, in my case, by ahci. Nothing happens. Anaconda just sits there. On other screens I see, as the last thing, "USB hub found" and "2 ports detected" which follows messages for other USB ports. FC6 installer does boot on the same hardware although it requires considerable coaxing (pci=nommconf irqpoll all-generic-ide). Adding such options does not change a picture here. Version-Release number of selected component (if applicable): How reproducible: on every try Additional info: Files used have dates from 2007-Feb-21 and this is x86_64 hardware and 2.6.20-1.2936.fc7 kernel.
Does this happen with today's rawhide?
> Does this happen with today's rawhide? I am afraid so. The only difference is that now I see anaconda installer init version 11.2.0.26 starting and a kernel version used is 2.6.20-1.2947.fc7 but the rest looks exactly the same as before. I see that I did not mention that before - this is x86_64 machine I am trying to boot that way.
I will be not able to hold to that machine which refuses to boot for too long. Hence I tried the same experiment with quite a bit older box (my regular test machine). This one boots; at least well enough that a server directory which I try to feed it for further loading is of a wrong version - which is correct. :-) But a machine which boots is using sata_via and sata_promise controllers. While trying to boot a machine which gets into trouble when I look what I ended with on "INFO" screen I see this: found USB controller ehci-hcd modules to insert ehci-hcd loaded ehci-hcd from /modules/modules.cgz inserted /tmp/ehci-hcd.ko load module set done found USB controller ohci-hcd modules to insert ohci-hcd loaded ohci-hcd from /modules/modules.cgz inserted /tmp/ohci-hcd.ko load module set done found USB controller ohci-hcd modules to insert load module set done found USB controller ohci-hcd modules to insert load module set done found USB controller ohci-hcd modules to insert load module set done found USB controller ohci-hcd modules to insert load module set done After that the boot is stuck. On that other machine, if I will stop boot in the right moment, I can see on "INFO" screen roughly the same thing as above but with "uhci-hcd" replacing "ohci-hcd". That is followed by modules to insert hid keybdev load module set done no firewire controller found modules to insert mii e100 skge libata sata_via sata_promise pata_via followed by correspondig "loaded" and "inserted" messages for all modules on that list and "load module set done" and we are on a merry way to continue that process. An attempt to boot with "nousb" passed to a rawhide kernel changes the picture somewhat. It looks like that: .... no firewire controller found modules to insert skge libata ahci pata_atiixp loaded skge from /modules/modules.cgz loaded libata from /modules/modules.cgz loaded ahci from /modules/modules.cgz loaded pata_atiixp from /modules/modules.cgz inserted /tmp/skge.o inserted /tmp/libata.o and I am stuck again with "Loading ahci driver ..." displaying on a main screen. On "syslog" screen I have a bunch of "failed to IDENTIFY (I/O error, err_mask=0x104) and "SATA link down (SStatus 0 SControl 300)" even if there was "SATA link up 3.0 Gbps" a number of times earlier on that screen. If I will pass "irqpoll", which was required on that machine to install FC6, then everything locks up including a keyboard. Option "all-generic-ide" seems to be ignored. I am getting with it the same "SATA link down" errors like above. BTW - the current kernel-2.6.19-1.2911.fc6 from FC6 just boots and runs on this machine without a need for any additional boot parameters (a need to turn off MMCONF is autodetected).
Created attachment 148843 [details] dmesg from 2.6.19-1.2911.fc6 Before will anybody ask. :-) Attached are dmesg from a succesful boot, an ouput from 'lscpi -tv' and an output of dmidecode for the system in question
Created attachment 148844 [details] tree of PCI devices
Created attachment 148845 [details] dmidecode output
I also tried to boot as described earlier using 'pci=nomsi'. It did not help. It does not go away like with 'irqpoll' but I could not squeeze past 'ahci' driver either.
I checked how far I can get with booting kernel-2.6.20-1.2949.fc7.x86_64 on the hardware in question. With various boot options I can think of, or without, I see on my screen: ..... Setting up hotplug. logips2pp: Detected unknown logitech mouse model 1 input: PS/2 Logitech Mouse as /class/input/input1 and nothing after that. It just sits and waits. Alt-Ctr-Del at that moment gives "md: stopping all md devices" and reboots.
Created attachment 149228 [details] 2.6.20-1.2962.fc7 booting with 'acpi=off irqpoll' With anaconda-11.2.0.28-1 boot images (after raid.py) got fixed, which are using kernel-2.6.20-1.2962.fc7, I can boot the hardware in question __provided__ I will use 'acpi=off irqpoll'. A kernel will lock up without 'acpi=off' and if I will skipp 'irqpoll' then disks are invisible. Disks in question now show up as /dev/sda and /dev/sdb. I attach a full anaconda syslog from such boot (and another one with 'irqpoll' taken out).
Created attachment 149229 [details] 2.6.20-1.2962.fc7 booting with only 'acpi=off' - no disks This is an excerpt from anaconda.log from this boot 22:58:53 INFO : inserted /tmp/libata.ko 22:58:55 INFO : inserted /tmp/pata_atiixp.ko 23:02:06 INFO : inserted /tmp/ahci.ko 23:02:06 INFO : modules to insert usb-storage Note over three minutes gap between inserting pata_atiixp.ko and ahci.ko. It corresponds to 'ahci' module probing interfaces and getting nowhere. That corresponds to lines in syslog like: <6>ata3: SATA link up 3.0 Gbps (SStatus 123 SControl 300) <4>ata3.00: qc timeout (cmd 0xec) <4>ata3.00: failed to IDENTIFY (I/O error, err_mask=0x104) and more of the same kind.
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.
That is really related to bug 436591. I have doubts about NOTABUG resolution there but no better ideas.