Red Hat Bugzilla – Bug 186870
firstboot exception in getRunlevel()
Last modified: 2007-11-30 17:11:28 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):
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)
Kadischi fails during post installation if the target system's firstboot is used.
Target system's firstboot runs, choose all config options desired, and exit.
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.
Created attachment 126792 [details]
Firstboot exception in getRunlevel()
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
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
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.
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
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 @@
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
+ tokens = string.split(line)
+ return int(tokens[-1])
return os.access("/usr/bin/rhgb-client", os.R_OK|os.X_OK) and
os.system("/usr/bin/rhgb-client --ping") == 0
The only change I needed to make was here:
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.
Thanks for testing.