Bug 135783 - [FC5] rhgb shouldn't automatically switch to vt 1 after 35 seconds
Summary: [FC5] rhgb shouldn't automatically switch to vt 1 after 35 seconds
Alias: None
Product: Fedora
Classification: Fedora
Component: rhgb   
(Show other bugs)
Version: rawhide
Hardware: i386 Linux
Target Milestone: ---
Assignee: Ray Strode [halfline]
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2004-10-15 00:40 UTC by julia
Modified: 2007-11-30 22:10 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2005-10-31 21:09:57 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

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)

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):

How reproducible:

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,


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.

Note You need to log in before you can comment on or make changes to this bug.