Red Hat Bugzilla – Bug 432384
uses inittab for runlevel configuration
Last modified: 2014-06-18 04:46:09 EDT
I understand why it's doing this. However, having a configuration file from the
old system that is:
- used to determine the default runlevel
- ignored for anything else
Could this potentially be more serious? i.e. is the upstart package set still
laying down a default /etc/inittab or might a fresh install drop this file entirely?
inittab is part of initscripts. We would control whether or not it goes away.
Ahh. Well that solves today's disaster scenario :) I'll poke Scott to weigh in
on this if he doesn't find it himself by tonight.
Yeah, it's definitely strange.
I didn't want to introduce an Upstart config file for runlevels though, since
they're not really part of the system.
Runlevel customisation is a lot rarer in Ubuntu/Debian (we don't have the 2/3/5
split you have), so it hasn't ever really caused us an issue before
I don't know that we'll have a good answer to this by F9. Is this a blocker?
Probably not, but it gives off the idea that the rest of the file will be read.
I suppose once we make a final switch, we can neuter the rest of inittab with
Now that I look at this again, why don't we just hard-code the default in
rc-default? We can explain the change to human sysadmins, are there any
automated tools that this would screw up?
anaconda uses it and there's nothing to migrate on upgrades yet.
Can we fix those?
Jeremy - would you prefer anaconda edit the upstart event file, or store the
Simple config files that are less likely to have breakage on automated editing
is always preferred. rc-default looks like the edit could be prone to
errors/problems over time.
And livecd-tools is going to have to be updated also for whatever we decide.
Hm, we could key off of the old 'GRAPHICAL=yes' in /etc/sysconfig/init.
Wasn't GRAPHICAL for rhgb?
Among other things, yes. (rhgb requires setting two different keys, and booting
into runlevel 5, and....)
Just built event-compat-sysv to use GRAPHICAL to determine if default runlevel
is 3 or 5. Issue now is that rhgb is refusing to start without /etc/inittab
present. I checked a patch to the rhgb package into CVS that should remove the
check, but its still not running. Ideas welcome.
Hi, it looks like you didn't actually add the patch to CVS.
so it looks like rc gets initialized to -1 and then never gets changed to 0?
(I'll refrain comment on the fact that the function has a boolean return type
and -1 gets stuffed into it and FALSE means success)
Anyway, easiest fix is probably to return 0 if rc is -1.
As of build 11 of rhgb and event-compat-sysv, upstart has no dependency on
inittab. Anything else before we can remove it?
Just as a side comment - the sudden use of $GRAPHICAL to forcibly imply either
runlevel 3 or 5 broke a machine of mine that actually uses runlevel 4 as a
"stripped-down" 5 (no VMWare/nessus/snort/ and 4-5 local daemons I don't need
The other alternative is to have prefdm started on a pseudo-event that is only
emitted at runlevel 5 end.
I suppose having a separate prefdm pseudo-event would be better, at least then
I'd have only one place to worry about changing a '5' to a '45' (remember that I
noticed this when I suddenly had a boot in to 5, which is prefdm plus all the
daemons, expecting 4, which on my box is prefdm and most of the daemons (but not
There is the prefdm event file which can be customized in such a manner.
OK, upon further consideration:
- We're still supporting SysV runlevels in F9
- Given that, we need to support people who customize it beyond 3 and 5
- Rather than invent a new file/key for that (as GRAPHICAL= doesn't cut it), it
probably makes sense to just leave it in inittab for now, and revisit when we've
done more migration
Hence, I'll flip things back in event-compat-sysv, and anaconda. Will add
commentary to initscripts in /etc/inittab that describes how the rest of the
file is ignored.
I suppose that makes this NOTABUG.