Bug 135984 - rhgb switched mode back to summary automatically
rhgb switched mode back to summary automatically
Product: Fedora
Classification: Fedora
Component: rhgb (Show other bugs)
i586 Linux
medium Severity low
: ---
: ---
Assigned To: Daniel Veillard
Depends On:
  Show dependency treegraph
Reported: 2004-10-16 01:20 EDT by G.Wolfe Woodbury
Modified: 2007-11-30 17:10 EST (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2004-11-28 16:21:25 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description G.Wolfe Woodbury 2004-10-16 01:20:41 EDT
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):

How reproducible:

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.

Additional info:

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.
Comment 1 Jon Savage 2004-10-16 03:35:08 EDT
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,
Comment 2 Daniel Veillard 2004-10-16 07:59:57 EDT
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.

Comment 3 Barry K. Nathan 2004-10-17 22:02:12 EDT
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.)
Comment 4 G.Wolfe Woodbury 2004-10-19 21:57:46 EDT
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.
Comment 5 Kam Leo 2004-11-28 00:07:09 EST
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
is buggy. 

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. 
Comment 6 Daniel Veillard 2004-11-28 16:21:25 EST
Okay, then WONTFIX,

Comment 7 Barry K. Nathan 2004-11-28 17:41:11 EST
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.
Comment 8 Daniel Veillard 2004-11-29 04:26:36 EST
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.

Comment 9 Barry K. Nathan 2004-11-29 06:06:50 EST
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).
Comment 10 Barry K. Nathan 2004-11-29 06:11:50 EST
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
misunderstanding you.)
Comment 11 Daniel Veillard 2004-11-29 08:09:34 EST
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.


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