Bug 135783

Summary:	[FC5] rhgb shouldn't automatically switch to vt 1 after 35 seconds
Product:	[Fedora] Fedora	Reporter:	julia <julia>
Component:	rhgb	Assignee:	Ray Strode [halfline] <rstrode>
Status:	CLOSED RAWHIDE	QA Contact:
Severity:	medium	Docs Contact:
Priority:	medium
Version:	rawhide	CC:	eparis, tao
Target Milestone:	---
Target Release:	---
Hardware:	i386
OS:	Linux
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2005-10-31 21:09:57 UTC	Type:	---
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	---	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:

Description julia 2004-10-15 00:40:15 UTC

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2)
Gecko/20040809

Description of problem:
  The rhgb will get to the point where it is starting the network
(sending out DHCP on eth0 and eth1) It will drop into detailed mode,
while waiting for eth1 to come up. And then it will drop into a text
console that says "   Press 'I' to enter interactive startup."
"Starting udev:                                       [ OK ]"
[...]
"Enabling swap space:                                 [ OK ]"
... basically it's the original text console.

  If you press Alt-F8 you can get back into rhgb, or if you wait a few
minutes it will go back into rhgb automatically.



  

Version-Release number of selected component (if applicable):
rhgb-0.13.5-2

How reproducible:
Always

Steps to Reproduce:
1. Installed Prism54 firmware (isl3890) into /lib/firmware. 
2. Inserted Netgear Prism54 PCMCIA card. 
3. Rebooted, card detected by Kudzu. Interface it set to use DHCP, but
there's not WEP key entered yet so this will always fail (not a problem). 
4. Continue booting normally.
5. Shutdown normally.
6. Reboot
7. Above problem occurs on boot. (last 5 out of 5 boots)

Actual Results:    rhgb drops into the text console while waiting for
dhclient to timeout.

Expected Results:    Probabilly not dropped out of X, er rhgb. The
long wait for DHCP will be confusing to users enough as it is, but
this will just make people think that something broke badly.

Additional info:

  The Prism54 card works fine when setup manually with iwconfig.

  I suspect that the automatic firmware loader isn't running yet at
this point in the startup because I see SIOSCIFFLAGS errors and the
green LED on the Prism54 card never turns on (which it does only when
the firmware is loaded (and it's not in monitor mode))

  Unplugging eth0 so that it fails to start (get a DHCP lease) does
NOT cause this same problem.

Comment 1 Bill Nottingham 2004-10-15 03:34:09 UTC

Any erorr messages in the rhgb log, or kernel errors?

Comment 2 Daniel Veillard 2004-10-15 07:46:44 UTC

The boot process is stuck, the fact that rhgb switches back to 
console mode doesn't sounds an rhgb bug from my point of view
that's what I expect it to do. The problem is that the boot
process get stuck for more than 30 seconds,

Daniel

Comment 3 Eric Paris 2005-02-17 21:19:33 UTC

Why would we expect rhgb to drop to console mode on VT1?  This looks like 144359
which is quite possible to run into.  Simply let kudzu detect your network card,
get to the point where it wants IP/GATEWAY/DNS go down the hall to ask you local
network admin what those should be, come back, see that you are now on some text
login screen with no way to configure your network card because you don't know
to hit cntrl-alt-f8 to get back to the kudzu screen.  My question is why does a
~30 second pause cause the rhgb to switch virtual terminals?

Comment 4 Ray Strode [halfline] 2005-10-27 19:46:24 UTC

Hi Eric,

Yea, it seems rather broken to switch after 35 seconds...I'll look into it.

Comment 6 Ray Strode [halfline] 2005-10-31 21:09:57 UTC

This should be fixed in tomorrow's rawhide.