Bug 432384 - uses inittab for runlevel configuration
uses inittab for runlevel configuration
Product: Fedora
Classification: Fedora
Component: event-compat-sysv (Show other bugs)
All Linux
low Severity low
: ---
: ---
Assigned To: Casey Dahlin
Fedora Extras Quality Assurance
Depends On:
Blocks: upstart
  Show dependency treegraph
Reported: 2008-02-11 13:32 EST by Bill Nottingham
Modified: 2014-06-18 04:46 EDT (History)
7 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2008-04-04 10:10:17 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

  None (edit)
Description Bill Nottingham 2008-02-11 13:32:56 EST
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

seems strange.

Comment 1 Casey Dahlin 2008-02-11 14:31:23 EST
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?
Comment 2 Bill Nottingham 2008-02-11 14:42:15 EST
inittab is part of initscripts. We would control whether or not it goes away.
Comment 3 Casey Dahlin 2008-02-11 14:45:25 EST
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.
Comment 4 Scott James Remnant 2008-02-11 21:06:03 EST
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
Comment 5 Casey Dahlin 2008-02-14 00:29:48 EST
I don't know that we'll have a good answer to this by F9. Is this a blocker?
Comment 6 Bill Nottingham 2008-02-14 10:09:24 EST
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
appropriate comments.
Comment 7 Casey Dahlin 2008-02-23 12:33:28 EST
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?
Comment 8 Bill Nottingham 2008-02-25 12:13:11 EST
anaconda uses it and there's nothing to migrate on upgrades yet.
Comment 9 Casey Dahlin 2008-02-25 12:31:20 EST
Can we fix those?
Comment 10 Bill Nottingham 2008-03-10 23:45:39 EDT

Jeremy - would you prefer anaconda edit the upstart event file, or store the
config elsewhere?
Comment 11 Jeremy Katz 2008-03-11 08:35:11 EDT
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.
Comment 12 Bill Nottingham 2008-03-11 11:22:34 EDT
Hm, we could key off of the old 'GRAPHICAL=yes' in /etc/sysconfig/init.
Comment 13 Jeremy Katz 2008-03-11 11:25:34 EDT
Wasn't GRAPHICAL for rhgb?
Comment 14 Bill Nottingham 2008-03-11 11:44:02 EDT
Among other things, yes. (rhgb requires setting two different keys, and booting
into runlevel 5, and....)
Comment 15 Casey Dahlin 2008-03-17 02:14:02 EDT
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.
Comment 16 Ray Strode [halfline] 2008-03-17 12:44:46 EDT
Hi, it looks like you didn't actually add the patch to CVS.
Comment 17 Casey Dahlin 2008-03-17 12:55:20 EDT
sorry. Fixed.
Comment 18 Ray Strode [halfline] 2008-03-17 13:17:24 EDT
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.

Comment 19 Casey Dahlin 2008-03-18 23:56:27 EDT
As of build 11 of rhgb and event-compat-sysv, upstart has no dependency on
inittab. Anything else before we can remove it?
Comment 20 Valdis Kletnieks 2008-03-22 07:46:00 EDT
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
every boot)..
Comment 21 Bill Nottingham 2008-03-24 13:44:11 EDT
The other alternative is to have prefdm started on a pseudo-event that is only
emitted at runlevel 5 end.
Comment 22 Valdis Kletnieks 2008-03-24 14:51:01 EDT
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
Comment 23 Bill Nottingham 2008-03-24 14:59:54 EDT
There is the prefdm event file which can be customized in such a manner.
Comment 24 Bill Nottingham 2008-04-04 10:10:17 EDT
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.

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