Bug 135833

Created attachment 105269 [details]
result of firsboot error message

fixed in up2date-4.2.49

*** Bug 136224 has been marked as a duplicate of this bug. ***

*** Bug 136180 has been marked as a duplicate of this bug. ***

4.2.50 is building atm

btw, looks like the hardware detection step failing may have
been the root cause here.

Could the bug reporter try running:

python /usr/share/rhn/up2date_client/hardware.py 

and posting the result here? especially if it
results in a traceback.

Created attachment 105457 [details]
results from "python /usr/share/rhn/up2date_client/hardware.py"

4.2.51 should fix that traceback, but it seems something
is preventing that machine from reaching the url
specified in serverURL (does it need an http proxy
and not have one configured?)

Not sure how this is getting hit, but 4.2.51-1 should resolve the
problem (from a code analysis standpoint, as I can't replicate this
error either.)  This up2date version is included in the re1020.0 tree.

I am behind a proxy but at the point this problem occurs I have not
had a chance to set the proxy and I don't get a chance without
starting in single user mode and renaming S95firstboot in the rc3.d
and rc5.d directories in order to get past firstboot.

From Issue Tracker
Event posted 10-25-2004 09:48am by brian.b 
Suceess:  i performed a fresh installation, booted to single user
mode, applied all three updates using rpm -Uvh --force and rebooted
the system.  The server came up and firstboot loaded and ran without
error. 

Close this bug as RESOLVED per comment #14 ????

With latest beta:
After the first reboot firstboot is executed. At the Red Hat Login 
screen I set the proxy server, user name, password and clicked Next. 
An error was returned.
firstboot.py
An error occurred in the Red Hat Login Module.
Traceback (most recent call last):
  File "/usr/share/firstboot/firstbootWindow.py", line 275, in 
nextClicked
    result = module.apply(self.notebook)
  File "/usr/share/firstboot/modules/rhn_login_gui.py", line 157, in 
apply
    ret = self.loginPageApply()
  File "rhnregGui.py", line 133, in loginPageApply
    self.getCaps()
  File "rhnregGui.py", line 75, in getCaps
    caps = rhnreg.getCaps()
  File "rhnreg.py", line 204, in getCaps
    rpcServer.doCall(s.registration.welcome_message)
  File "rpcServer.py", line 315, in doCall
    raise up2dateErrors.CommunicationError(e.args[1])
CommunicationError: Error communicating with server. The message was:
Connection timed out

The install then continues to the Activate screen where a message 
says, "error registering username." Tried many differnet combinations 
to get past this but it always errored.
Workaround:
Reboot to single user mode. Create an /etc/sysconfig/firstboot file 
to prevent firstboot.py from running.

By latest beta, I mean with RH EL 3 U4.  Also, the platform should be 
all, and the severity should be high.

Brian, is this with the up2date in the latest drop or just latest ISO? 
What's the version of up2date on your system?

The version is 4.2.51-1

I got confirmation Jérôme hit same problems on RHEL4 beta release.

Unfortunately, Jérôme is out due to health problems and he won't be
back   before at least one week. I won't have detailled explanation.

However, from his note, we can see:
    - firstboot error in lines 498, 90, 83, 336.
    - Other errors in firstboot after "create login" (it seems several
time-out occured) : Is it due to proxy setting which was not yet done ?

Some errors we got on Jérôme's victim machine, if it may help a little
more ...

Traceback (most recent call last):
  File "/usr/share/firstboot/firstbootWindow.py", line 498, in loadModules
    vbox, pix, title = module.launch()
  File "/usr/share/firstboot/modules/rhn_activate_gui.py", line 90, in
launch
    self.setupScreen()
  File "/usr/share/firstboot/modules/rhn_activate_gui.py", line 83, in
setupScreen
    vbox  = self.activatePagePrepare()
  File "/usr/share/rhn/up2date_client/rhnregGui.py", line 336, in
activatePagePrepare
    if hostname:
UnboundLocalError: local variable 'hostname' referenced before assignment

This is what we saw, but we had already configured the proxy.

From User-Agent: XML-RPC

This comment sent by ltroan
----------Event posted 11-19-2004 02:01pm by kim.jensen with duration of
0.00 	

RHEL3U4 Beta (2.4.21-21) x86 & x86-64 both have up2date-4.2.51-1.

With x86-64, I see that it still takes a long time for firstboot to come up
(5-10 minutes) and during this time the system appears hung - but it is
not.

Same is true with x86.



When the system is sitting there for all this time (The screen is grey with
the mouse pointer visible in the middle of the screen), tty1 shows we are
on

   Starting firstboot:



/var/log/messages indicates "firstboot: succeeded"





Status set to: Waiting on Tech



New Event

There seems to be at least two seperate bugs, on two seperate
products mentioned in this single bug report. 

The first one, for rhel3-u4 is fixed in up2date-4.2.51.

The second one, for RHEL4-beta, is fixed in up2date-4.3.64
(actually, somewhere early, but thats whats currently header
for RHEL4, and includes the fix). 

I'm don't know what version of up2date is involved in either of
the two reports above  (while the error is seen in firstboot,
the code is reused from the up2date package). 

As per comments #16 and #19, up2date-4.2.51-1 (higher that recommanded
4.2.51 version) doesn't seem to fix this problem though.

On our side, we didn't test with a newer version (up2date-4.3.64 ?) on
RHEL4.

As soon as we'll get a newer RHEL3-U4 or RHEL4, beta or release
candidate versions, we'll be able to test and to see (hopefully) that
it has been fixed.

Event posted 01-06-2005 08:09pm by kim.jensen with duration of 0.00 	
Can we change the title to   "RHEL3U4 - firstboot 2-7 minute delay"

I straced 'firstboot --reconfig' and found what I believe the cause of the delay...

connect(3, {sa_family=AF_INET, sin_port=htons(422),
sin_addr=inet_addr("209.132.177.100")}, 16

which is xmlrpc.rhn.redhat.com.

We see this in two critical situations
1- when we preload systems and no networking information has been setup when
firstboot is initiated.
2- when we install a box set and no proxy has been defined (this is not a
required part of the install!).

Customers are going to see this as a DOA system

Created attachment 109620 [details]
strace of firstboot --reconfig

This is now fixed...

some of the fixes arein U5, but not all. Thats in u6-candidate
(basically, a backport of all the RHEL4 fixes for this).

This is not an issue in RHEL 3 U6.  Closing.