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):
Steps to Reproduce:
1. Do a default boot
system stays at graphical boot page forever
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]
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
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).
Compaq Armada E500
I believe it has some Intel chipset and is "Microsoft ACPI compliant" -
whatever that means...
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:
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:
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)