Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 80742 - Firstboot runs every boot when initial default runlevel is 5
Summary: Firstboot runs every boot when initial default runlevel is 5
Keywords:
Status: CLOSED RAWHIDE
Alias: None
Product: Red Hat Public Beta
Classification: Retired
Component: firstboot
Version: phoebe
Hardware: i686
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Brent Fox
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks: 79578
TreeView+ depends on / blocked
 
Reported: 2002-12-30 18:43 UTC by Chris Ford
Modified: 2008-05-01 15:38 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2003-02-06 15:44:30 UTC


Attachments (Terms of Use)

Description Chris Ford 2002-12-30 18:43:01 UTC
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.3a) Gecko/20021204

Description of problem:
After installing and selecting graphical login, firstboot starts on every
subsequent boot.  It completed sucessfully the first time.  I completed it
sucessfully the second time as well.  On the third and later boots I killed X
with Ctrl-Alt-Backspace to get past it.  I then changed the default runlevel in
/etc/inittab to 3 and rebooted.  Firstboot did not run after making this change.
 I then changed my default runlevel back to 5 and firstboot did not run again.

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


How reproducible:
Always

Steps to Reproduce:
1.Install Phoebe and select graphical login
2.Reboot and sucessfully complete the firstboot setup.
3.Login and then reboot.  Firstboot will run again.

    

Actual Results:  Firstboot ran the initial setup procedure again.

Expected Results:  The system should have presented the graphical login screen

Additional info:

Comment 1 Mike Kuhnkey 2002-12-31 18:34:30 UTC
FWIW:
Inspection of my /etc/hosts file revealed missing localhost entries. This may be
related to insertion of optional hostname during initial install, or , was
instigated by editing of "Network Configuration=>DNS(Tab) for hostname.

This 'bug' was not seen when upgrading from Valhalla => phoebe, presumably
because existing /etc/hosts file was 'honored'? (...Wild Speculation on My Part...)

BUT:
When localhost entries were manually inserted into /etc/hosts file Firstboot did
not re-ocurr on restart. So, I'm assuming that editing actions on the "Network
Configuration" tabs caused corruption of /etc/hosts...or...insertion of hostname
on system utilizing DHCP services of ISP caused confusion/corruption of
configuration files?

Comment 2 Brent Fox 2003-01-14 02:59:07 UTC
Chris: Did you click on either the "Register with Red Hat Network" button or any
of the buttons in the "Additional CD" screen?  

Mike: I wouldn't expect /etc/hosts to affect firstboot in any way.

Comment 3 Chris Ford 2003-01-14 03:54:44 UTC
The first time I did an install I did register with RHN.  When I rebooted I
didn't register again. 

The second install I did, I can't remember with complete certainty, but I would
be williing to wager that I didn't register with RHN.  I didn't go to any of the
additional CD screens on either install or any of the subsequent reboots.

Comment 4 Brent Fox 2003-01-25 22:07:50 UTC
There was a bug in the firstboot that shipped with Phoebe in that closing the
popup dialogs would close all firstboot prematurely, causing the
/etc/sysconfig/firstboot file to not get written.  This would cause firstboot to
run again on the next boot.  

This bug was fixed soon after Phoebe was released and I have not been able to
reproduce this behavior in the Phoebe2 trees.  QA, you may want to double check
me with the latest tree, but I believe this problem to be fixed.

Comment 5 Jay Turner 2003-02-06 15:44:30 UTC
No longer seeing this with GinGin-re0206.nightly.


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