Red Hat Bugzilla – Bug 100925
Should kudzu really run with a 30 second timeout if rhgb prevents user from providing feedback?
Last modified: 2014-03-16 22:37:40 EDT
While trying to debug Bug #58201 a little bit, I'm coming to this question:
Should /etc/rc.d/init.d/kudzu really run with the '-t 30' argument when rhgb is
part of the boot process? If I understand this proprerly, rhgb (appears to)
prevent a user from providing any feedback during boot.
Wouldn't the '-q' argument be more appropriate than the timeout, so that kudzu
can run and do something useful? I don't see anything in hwconf.c to make it
clear why kudzu wouldn't always timeout in this case.
Am I missing something here? I feel like I must, because if I were right, I
would expect a timeout to occur every time kudzu runs during the initscripts,
and then I'd expect to see a record of it via the "initlog" function call from
/etc/rc.d/init.d/kudzu, which I'm not. Still, better to ask than not, since
sometimes rhgb seems to sit a while without updating its progress bar. Things
were pretty snappy on my last reboot though - I wonder if this has something to
do with the push I gave kudzu when looking at Bug #58021?
Oops - I meant Bug #58021...
Actually, the plan is to have GUI windows from kudzu pop up.
Ah, cool. Is anything in CVS? I took a look at the pserver access on rhl and
didn't see anything obvious, at least not on the head branch.
Nope, no code in CVS yet.
*** Bug 101602 has been marked as a duplicate of this bug. ***
It's there now. I'm not really happy w/ the kudzu screen, but it'll do until we