Bug 186870 - firstboot exception in getRunlevel()
firstboot exception in getRunlevel()
Status: CLOSED RAWHIDE
Product: Fedora
Classification: Fedora
Component: firstboot (Show other bugs)
5
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Chris Lumens
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-03-27 01:36 EST by Jasper O. Hartline
Modified: 2007-11-30 17:11 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-03-28 13:16:20 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
Firstboot exception in getRunlevel() (469 bytes, text/plain)
2006-03-27 01:36 EST, Jasper O. Hartline
no flags Details

  None (edit)
Description Jasper O. Hartline 2006-03-27 01:36:08 EST
Description of problem:
Firstboot exception when runlevel cannot be determined in getRunlevel().
Using firstboot from Kadischi, in a post installation script shows that
firstboot will try to run in the target system and perform some configuration
but fail to do so since the target system's utmp file has never been written.
Thus the runlevel cannot be determined. (Not surprising.)
Kadischi is Fedora Core's LiveCD utility for end users.

 

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

How reproducible:
Try running /usr/sbin/firstboot on target system, during Kadischi post installation.

Steps to Reproduce:
1. As Kadischi post_install_script (chroot system-target /usr/sbin/firstboot)
2.
3.
  
Actual results:
Kadischi fails during post installation if the target system's firstboot is used.

Expected results:
Target system's firstboot runs, choose all config options desired, and exit.
Kadischi continues.

Additional info:
This eliminates needing to write specialized, Kadischi specific scripts to do
such tasks, which in the future may be done. This also eliminates firstboot
actually running during every bootstrap of generated user CDs.
Short history and explanation:
If we can run firstboot on the target system under Kadischi during post install
if and only if the user has not specified kickstart, or cmdline options to
Kadischi and Anaconda, we eliminate needing to actually run firstboot -every-
time a user CD is made and it is booted. One thing I believe that kickstart
doesn't provide that firstboot does, is services configuration which can be done
during firstboot anyways, however we don't if kickstart is used.
During the continuous development of Kadischi and Anaconda concerning having
a %livecd section in kickstart files (If that happens) this may be deprecated.
A small exception text will be attached to this report.
Comment 1 Jasper O. Hartline 2006-03-27 01:36:08 EST
Created attachment 126792 [details]
Firstboot exception in getRunlevel()
Comment 2 Chris Lumens 2006-03-27 13:15:46 EST
What's the desired mode of operation here?  Do you want this running in X or
through the text interface?  What's the output of "/sbin/runlevel r" in your
chroot environment?
Comment 3 Jasper O. Hartline 2006-03-27 16:36:15 EST
This is the output of a fully installed, chroot'able system, using:
chroot system /sbin/runlevel r

[user@SMP-NODE-1 livecd-build_no20]# chroot system /sbin/runlevel r
unknown
[user@SMP-NODE-1 livecd-build_no20]#

Theoretically either method, text console or graphical UI would be sufficient.
The time of this report I was aiming for simple text console.
Looking into it further I see firstboot tries to read the utmp file.

This may be the strangest attempt of running firstboot you guys have seen and
although firstboot is specifically targeted to run at the first bootstrap..
I'd imagine we could handle an exception here, or make a special case maybe.

I'm curious how doing this in either modes would affect the host system, or X
server. The text console modes would probably not generate any fodder.
If this isn't possible to work out, a Kadischi specific tool could be written
here instead. I just imagine using already established Fedora Core utilities and
scripts would be better.. I don't know.
Comment 4 Chris Lumens 2006-03-28 10:04:22 EST
Yes, this is one of the stranger uses of firstboot I've seen in the short time
I've been maintaining it.  I don't think any of the config utilities should have
a problem running inside a chroot environment.  firstboot is just special. 
Anyway, this is a possible error condition so I should be handling it.

Could you please try the following patch to /usr/sbin/firstboot and see if it
fixes your problem?  This should force firstboot into running in text mode in
these circumstances.

RCS file: /usr/local/CVS/firstboot/src/firstboot,v
retrieving revision 1.18
diff -u -r1.18 firstboot
--- firstboot   27 Jan 2006 14:35:15 -0000      1.18
+++ firstboot   28 Mar 2006 15:05:54 -0000
@@ -30,8 +30,12 @@
 def getRunlevel():
     line = os.popen('/sbin/runlevel', 'r').readline()
     line = string.strip(line)
-    tokens = string.split(line)
-    return int(tokens[-1])
+
+    if line.lower.startswith("unknown"):
+        return 3
+    else:
+        tokens = string.split(line)
+        return int(tokens[-1])

 def rhgbIsRunning():
     return os.access("/usr/bin/rhgb-client", os.R_OK|os.X_OK) and
os.system("/usr/bin/rhgb-client --ping") == 0
Comment 5 Jasper O. Hartline 2006-03-28 12:15:10 EST
Most definitely.

The only change I needed to make was here:
-if line.lower.startswith("unknown"):
+if line.startswith("unknown"):

Other than that, it looks good.
A trial run showed no instances of failure running the tools provided with the
firstboot UI in that environment.



Comment 6 Chris Lumens 2006-03-28 13:16:20 EST
Thanks for testing.

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