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.
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 chroot environment?
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.
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
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.
Thanks for testing.