Description of problem: as per the release notes, my system hangs during the graphical boot (about 1/3 of the way thru at 'Probing for new hardware'). Toggling to VC 1 the last message I see is: Enabling swap space.. whereas, using the nogui boot option, I would next see something about 'enabling IA-32 microcode update' Version-Release number of selected component (if applicable): How reproducible: always Steps to Reproduce: 1. Do a default boot 2. 3. Actual results: system stays at graphical boot page forever Expected results: normal bootup Additional info: I see the following earlier in VC 1 also (in case it is related in any way) Unmounting initrd: umount /initrd: device is busy [FAILED] # lspci 00:00.0 Host bridge: Intel Corp. 440BX/ZX/DX - 82443BX/ZX/DX Host bridge (rev 03) 00:01.0 PCI bridge: Intel Corp. 440BX/ZX/DX - 82443BX/ZX/DX AGP bridge (rev 03) 00:07.0 ISA bridge: Intel Corp. 82371AB/EB/MB PIIX4 ISA (rev 02) 00:07.1 IDE interface: Intel Corp. 82371AB/EB/MB PIIX4 IDE (rev 01) 00:07.2 USB Controller: Intel Corp. 82371AB/EB/MB PIIX4 USB (rev 01) 00:07.3 Bridge: Intel Corp. 82371AB/EB/MB PIIX4 ACPI (rev 02) 00:0d.0 Multimedia audio controller: Aureal Semiconductor Vortex 1 (rev 02) 00:0f.0 PCI bridge: Digital Equipment Corporation DECchip 21152 (rev 03) 00:11.0 Ethernet controller: 3Com Corporation 3c905B 100BaseTX [Cyclone] (rev 24) 01:00.0 VGA compatible controller: ATI Technologies Inc 3D Rage Pro AGP 1X/2X (rev 5c)
kernel-2.6.0-0.test2.1.29 kernel-2.4.21-20.1.2024.2.1.nptl Severn with these two kernels consistently get stuck after "Probing for hardware" during the graphical boot. The system does not lockup, I can still move mouse and change to VT1, but it does not proceed further. The same kernels booting in text mode work fine. Hardware: Athlon Palomino 1GHz 256KB cache Sony Vaio FXA-36 VIA KT133A chipset 01:00.0 VGA compatible controller: ATI Technologies Inc Rage Mobility P/M AGP 2x (rev 64) 01:00.0 Class 0300: 1002:4c4d (rev 64)
If it matters, I experienced this hang after initial install, however, upon rebooting and going into single user mode a single time I am now able to boot "normally" (i.e. graphical works). Hardware details: Compaq Armada E500 I believe it has some Intel chipset and is "Microsoft ACPI compliant" - whatever that means... Don
Does the hang go away if you boot with 'linux pci=noacpi' or 'linux acpi=off'
This comment relates to the first system in the list, with the 'lspci' listing. I probably can't be of much further help on this bug, since I now believe that my hardware is flakey - which is to say that flakey hardware may result in the graphical boot screen blocking normal startup. That isn't very helpful. I can no longer reproduce the problem when I re-install Severn. But at the same time, the on-board sound card is no longer visible (despite being enabled in the bios). When I first installed Severn and was playing around the on-board sound capability WAS seen and showed up in modules.conf, though it did not work when configured by the installer or by config-redhat-soundcard. Another flakey aspect of the machine is that the mouse insists on behaving badly when firstboot runs - one has to toggle out and back into graphics to get the mouse to behave. By comparison, I have another oldish, almost identical node that I dug out and installed with Severn. It is the same model, with the same 'lspci' listing. (The only difference is an additional ide-zip device instead of the additional ide-cdwriter device.) I have no problems with this machine at all - it sees the onboard sound card, and the exact same mouse on it does not exhibit strange firstboot behaviour. There is no graphical boot hang when doing a default, fresh workstation install. Both machines are Dell Optiplex GX1's. Additional info: BIOS settings are and always have been: ACPI: off Power Mngt: disabled As a side note, this onboard sound card is only configured properly by sndconfig. I'll search through bugzilla to see if this already reported for this sound card. The second pci sound card (vortex) which shows up in the lspci listing isn't supported, I believe. Removing it from the system doesn't change the behaviour of the systems with respect to this bug id. So I guess I will salvage parts from it, and throw the box and motherboard on the junk heap.
I have seen this happen on two other machines, a Compaq Pro(whatever) desktop with a fast P4 and a Whitebox with an MSI motherboard and a Celeron. I never saw it happen when doing a full power cycle, just when doing a shutdown -r
I figured out something... this happens 100% in cases where kudzu's text menu would appear. If this happens, then I CTRL-ALT-Backspace to kill X, then ALT-F7, I see a very corrupted looking kudzu window that is frozen. This behavior persists through current Rawhide on two of my systems.
I can confirm the same behavior as described in previos comment. I managed to read what the corrupted looking kudzu window says: The following mouse has been removed from your system: Generic Mouse (PS/2) You can choose to: 1) ... 2) ... 3) ... ...... ------------------------- I never get that kudzu window when I boot with "nogui" kernel command line option.
Yes, it's running on the same tty as X.
*** Bug 106183 has been marked as a duplicate of this bug. ***
For me it doesn't get stuck, kudzu just takes a very long time (30+sec) in rhgb compared to ~10 in text mode.
Works normally for me now with rhgb-0.10.2-1, kudzu-1.1.32-1 and initscripts-7.36-2 I still have the issue of PCMCIA 3c59x w/ rhgb, but that's another bug (#100470 perhaps, or maybe I should open a new one)
Same here?: https://bugzilla.redhat.com/bugzilla/show_bug.cgi?id=121859