Bug 442492 - i686 LiveCD only succeeds if rhgb is omitted
i686 LiveCD only succeeds if rhgb is omitted
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: rhgb (Show other bugs)
9
i686 Linux
low Severity medium
: ---
: ---
Assigned To: Ray Strode [halfline]
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-04-14 23:35 EDT by Oisin C. Feeley
Modified: 2009-07-14 12:17 EDT (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-07-14 12:17:51 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 Oisin C. Feeley 2008-04-14 23:35:35 EDT
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9b5pre) Gecko/2008031714 Fedora/3.0-0.44.cvs20080315.fc9 Minefield/3.0b5pre

Description of problem:
Attempting to boot the Fedora-9-Beta-i686-20080319 appears to proceed through the initscripts but then hangs thrashing the CD and eventually becoming inert unless mouse/keyboard input is supplied in which case the CD thrashing resumes.  The screen is blank grey.  It is not possible to switch to a VT.

The i686 FedoraDesktop LiveCD appears to fail somewhere after
NetworkManagerDispatcher is started. The exact symptoms are that the
screen flickers, goes blank and the CD drive continues to spin for
minutes and then becomes inactive. Keyboard or touchpad input results
in the CD drive spinning up again but the screen remaining blank.

Attempts to see what's going on by switching to some other console via
Alt-Ctl-Fx appear to be ignored.

Attempts to selectively disable services are difficult because the
reading of the keyboard input appears to require two carriage returns and sometimes to be ignored. The prompt "<service name>
(C)ontinue/(Y)es/(N)o" (or something of that form) appears, but it's
necessary to enter at least two carriage-returns with the option, a
bit of what appears to be Python code for reading the option and
starting the services is printed and then the service is (possibly)
started anyway. This is a sample copied from the VT

Entering interactive startup
+confirm fedora-live
+ '[' -x /usr/bin/rhgb-client ']'
+ /usr/bin/rhgb-client --details=yes
+ :
+ echo -n 'Start service fedora_live (Y)es/(N)o/(C)ontinue? [Y]'
Start service fedora_live (Y)es/(N)o/(C)ontinue? [Y] + read answer
Y

+strstr yY ''
+ '[' yY = yY ''
+ return 0
+ rc=0
+ '[' 0=1 ']'
+ '[' 0=2 ']'
+ set +x

I was eventually able to boot to runlevel 3 and then telinit to runlevel 5 succesfully.

Following on from a suggestion from AndrewFarris on @fedora-devel I removed "rhgb" from the parameter list passed by default and the install/boot proceeded sucessfully.  

I'm not sure if this is a problem with rhgb, firstboot or anaconda.

I attach dmesg and lspci info for this Panasonic CF-Y5.

Version-Release number of selected component (if applicable):
rhgb-0.17.7-5.fc9.i386

How reproducible:
Always


Steps to Reproduce:
1.Boot from verified/checked F9 Beta Desktop Live CD (i686-20080319)
2.Watch it hang, then reboot and attempt to use interactive startup (press "I")
3.Attempt to pass "Y" or "N" to each service.  Sometimes two Carriage Returns or Enters following the option will work, othertimes it seems like one of these gets carried on to the next service.  Observe the apparent debug code.
4. Reboot, TAB to edit options, remove "rhgb", observe the apparently perfect boot

Actual Results:
#1 CD-drive thrashes for up to 13 minutes (at which point I lose patience) screen shows usual boot text scrolling by, I see the last services starting:
CUPS
HAL
NetworkManagerDispatcher
firstboot
rhgb-client

then the screen goes grey, sometimes I see the animated circular logo, then if left the machine just sits there with the CD spun down unless kbd or mouse it touched in which case it spins up but apparently does nothing.



Expected Results:
The machine should have booted through to the GDM login screen autoloaded with the test account, just like it does if "rhgb" isn't called.  Also during attempts to use interactive boot the python code should not be displayed and the entry of options should merely require a single "Y", "N" or "C" with not CR/Enter

Additional info:
Comment 1 Bug Zapper 2008-05-14 05:27:40 EDT
Changing version to '9' as part of upcoming Fedora 9 GA.
More information and reason for this action is here:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 2 Bug Zapper 2009-06-09 20:11:16 EDT
This message is a reminder that Fedora 9 is nearing its end of life.
Approximately 30 (thirty) days from now Fedora will stop maintaining
and issuing updates for Fedora 9.  It is Fedora's policy to close all
bug reports from releases that are no longer maintained.  At that time
this bug will be closed as WONTFIX if it remains open with a Fedora 
'version' of '9'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version prior to Fedora 9's end of life.

Bug Reporter: Thank you for reporting this issue and we are sorry that 
we may not be able to fix it before Fedora 9 is end of life.  If you 
would still like to see this bug fixed and are able to reproduce it 
against a later version of Fedora please change the 'version' of this 
bug to the applicable version.  If you are unable to change the version, 
please add a comment here and someone will do it for you.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events.  Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

The process we are following is described here: 
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 3 Bug Zapper 2009-07-14 12:17:51 EDT
Fedora 9 changed to end-of-life (EOL) status on 2009-07-10. Fedora 9 is 
no longer maintained, which means that it will not receive any further 
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of 
Fedora please feel free to reopen this bug against that version.

Thank you for reporting this bug and we are sorry it could not be fixed.

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