Red Hat Bugzilla – Bug 135984
rhgb switched mode back to summary automatically
Last modified: 2007-11-30 17:10:52 EST
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4.1)
Description of problem:
While viewing the "show details" screen of rhgb, the display switches
back to "hide details" (summary) screen automatically. It dies this
several times in the sequence if you switch back to hte show details page.
Version-Release number of selected component (if applicable):
Steps to Reproduce:
1. rawhide install of 2004-10-15
2. switch to show details during bootup
Actual Results: screen switches back to "hide details" mode
automatically without user intervention.
Expected Results: I expect it to stay on "show details" unless *I*
tell it to "hide details"; it should not switch on its own.
this switch back to "hide details" occurs at several points in the
bootup sequence. One consistent switch is when it goes to initialize
the "lo" device of networking.
seeing this as well, when I switch to "show details" I get a few lines
of output then goes back to gui, a few lines of outout, back to gui,
Yes, agreed, I don't store whether going to detained view is
done based on user intereaction or automatically, that would
be an enhancement needed I agree.
BTW, sometimes I see it go automatically to detailed view, then switch
back *very* quickly (maybe after 1/4th of a second? it seems like
1/4th of a second anyway). This behavior seems ugly to me...
(I'm not sure if that's related to this bug at all. If it's not, I'll
comment on another bug or file my own later.)
I think it's the same bug. There is a serious lack of consistency in
the user experience of rhgb. There is no change in the rawhide for
2004-10-19 as far as this behaviour goes.
Per Daniel's HOW_IT_WORKS: "rhgb will switch to detailed view when
errors seems to be occurring. Basically if the initscripts didn't
report progresses for 10 seconds rhgb will switch to detailed view to
show what is happening, this can occur for example if a filesystem is
being checked, or if some timeout occurs (network/DNS for example),
once the timeout is over and further progresses are reported, then
rhgb will switch back to the normal view."
This behavior is a poor design decision. On my systems there are
several delays in the boot process. This causes rhgb to switch back
and forth between graphical mode and detail/text mode. The text mode
does not remain on screen not long enough for me to read the data.
This behavior is not useful and gives me the perception that the rhgb
The bug submitter has a valid point. If rhgb is in graphical mode it
should stay in graphical mode regardless of the existence / or
perception of errors. Once a user switches to "Detail" mode rhgb
should remain in "Detail" mode. The "Detail/Graphical" state should be
persistent and, it would be really great if it carried over through
the next boot. This way users do not have to modify grub.conf to
disable the utility.
Take a clue from SuSE's graphical boot utility. rhgb should be as good
as SuSE's utility or be replaced by it.
Okay, then WONTFIX,
An improvement would be to make that timeout a *lot* longer (say,
40-60 seconds). That way, DHCP stuff which can take well over 30
seconds in the real world wouldn't erroneously bring up the Details
view automatically (well, not in general, anyway).
This wouldn't be a 100% complete fix, but it would be a tremendous
improvement over the current situation.
And would miss kudzu which only waits 30 second. I see no reason why
a DHCP should need that long, even when coming from an ISP.
Why would DHCP take that long? Flaky (but still usable!!) 802.11b
wireless connections. I measured approx. 35 seconds for DHCP in my
case (I don't remember if that was my school's wireless network or the
one at home).
BTW, are you saying that the 10 second timeout is how rhgb decides to
go to detail mode for kudzu?? (I just want to make sure I'm not
10 seconds is the timeout after which it sounds normal to show
that something is going wrong and rhgb decide to go in detail mode.
It doesn't depends what is blocking, trying to put that logic in rhgb
is not the proper place. Any operation taking more than 10 seconds
without progress must be reported, that's the decision.