Bug 147910 - kudzu times out during config, aborting boot
kudzu times out during config, aborting boot
Status: CLOSED CANTFIX
Product: Fedora
Classification: Fedora
Component: rhgb (Show other bugs)
3
i386 Linux
medium Severity high
: ---
: ---
Assigned To: Ray Strode [halfline]
David Lawrence
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-02-12 12:09 EST by Bill
Modified: 2007-11-30 17:11 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2007-08-14 11:41:44 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Bill 2005-02-12 12:09:23 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.5)
Gecko/20041111 Firefox/1.0

Description of problem:
If kudzu detects new or removed hardware, it prompts you to press a
key.  If you press a key, but don't answer all its questions within a
fairly short period of time, it times out, kudzu disappears.  Boot
does not continue, but you are stuck on a text screen, with the last
message being about enabling swap.

Reboot is required at that point.

(The timeout is roughly 30 sec. or less, maybe per question.)

Version-Release number of selected component (if applicable):
kudzu-1.1.95-1

How reproducible:
Always

Steps to Reproduce:
1. Add or remove hardware that kudzu will notice.
2. Boot/reboot, and press a key when the initial kudzu prompt comes up.
3. When kudzu asks what do do with the hardware, don't do anything.

Actual Results:  After a short period of time (maybe 30 seconds, give
or take), the kudzu screen disappears, replaced by a black and white
text screen.  The last message on the screen is about enabling swap. 
Nothing more happens.  Boot does not continue, and a reboot is required.

Expected Results:  The system should wait until all the kudzu
questions have been answered.  Or, at least, the system should
continue to boot after the timeout.

Additional info:
Comment 1 Bill Nottingham 2005-02-14 13:45:05 EST
Are you using rhgb?
Comment 2 Bill 2005-02-14 16:31:02 EST
Yes, I'm using rhgb.
Comment 3 Bill Nottingham 2005-02-14 16:36:57 EST
Does it recur if you *don't* use rhgb?
Comment 4 Bill Nottingham 2005-03-14 12:54:40 EST
This is a rhgb bug; it's randomly switching to tty1.

(If you're in this situation, ctrl-alt-f7 or f8 should get you back to
rhgb.)
Comment 5 Matthew Miller 2006-07-10 18:47:15 EDT
Fedora Core 3 is now maintained by the Fedora Legacy project for security
updates only. If this problem is a security issue, please reopen and
reassign to the Fedora Legacy product. If it is not a security issue and
hasn't been resolved in the current FC5 updates or in the FC6 test
release, reopen and change the version to match.

Thank you!
Comment 6 Ray Strode [halfline] 2007-08-14 11:41:44 EDT
The information we've requested above is required in order
to review this problem report further and diagnose/fix the
issue if it is still present.  Since there haven't been any
updates to the report in quite a long time now after we've
requested additional information, we're assuming the problem
is either no longer present in our current OS release, or
that there is no longer any interest in tracking the problem.

Setting status to CANTFIX, however if you still
experience this problem after updating to our latest Fedora
Core release and are still interested in Red Hat tracking
the issue, and assisting in troubleshooting the problem,
please feel free to provide the information requested above,
and reopen the report.

Thank you in advance.

(this message is mass message)

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