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. event-compat-sysv-0.3.9-5.fc9
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 appropriate comments.
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?
Possibly. Jeremy - would you prefer anaconda edit the upstart event file, or store the config elsewhere?
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.
sorry. Fixed.
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 every boot)..
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 all).
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.