Amazon (or perhaps Amazon's configuration of Xen) forces a machine to come up at run level 4, regardless of what's in /etc/inittab.
I've looked through /etc/rc.sysinit and /etc/rc.d/rc, to determine which (if any script) looks at /proc/cmdline and forces a particular run level, but to no avail.
It seems that /sbin/init does the forcing. Can anyone confirm that /sbin/init reads /proc/cmdline to overwrite /etc/inittab? I can't seem to find any reference in man pages or searching the web.
Thanks, Kurt
On Tue, Jan 26, 2010 at 2:48 PM, Kurt Newman knewman@globaldataguard.com wrote:
Amazon (or perhaps Amazon's configuration of Xen) forces a machine to come up at run level 4, regardless of what's in /etc/inittab.
I've looked through /etc/rc.sysinit and /etc/rc.d/rc, to determine which (if any script) looks at /proc/cmdline and forces a particular run level, but to no avail.
It seems that /sbin/init does the forcing. Can anyone confirm that /sbin/init reads /proc/cmdline to overwrite /etc/inittab? I can't seem to find any reference in man pages or searching the web.
You *can* override the initdefault in inittab via the kernel option, but if you're not seeing it in /proc/cmdline it's likely some other rc script. I saw some references to this being controlled via xen:
http://somic.org/2008/06/20/ec2-instances-always-boot-to-runlevel-4/
Alas, the links are dead... Another site shows:
http://www.novell.com/support/search.do?cmd=displayKC&docType=kc&ext...
---quote Xen para-virtual SLE (all versions), first method This method uses the legacy installation file. Any hardware changes made to a managed domain via "YaST", "virt-manager" or "xm commands" will not be present. Replace "DOMU" with the name of your DomU.
1. Go to /etc/xen/vm 2. Locate the installation file, usually the name of the Xen DomU 3. Use the "xm create" command. (The -c will connect to the console, and xencons=xvc0 will use the Xen frame buffer for SLES 10 SP1 and higher, and SLES 9 SP4. Use xencons=tty for SLES 10). xm create -c DOMU extra=" init 1 xencons=xvc0" 4. Shutdown the DomU after making changes 5. Start the DomU normally" ---quote
So it may be being passed through xen which might not show up in proc/cmdline (can't test right now).
Kwan Lowe wrote:
Kurt Newman wrote:
Amazon (or perhaps Amazon's configuration of Xen) forces a machine to come up at run level 4, regardless of what's in /etc/inittab.
I've looked through /etc/rc.sysinit and /etc/rc.d/rc, to determine which (if any script) looks at /proc/cmdline and forces a particular run level, but to no avail.
It seems that /sbin/init does the forcing. Can anyone confirm that /sbin/init reads /proc/cmdline to overwrite /etc/inittab? I can't seem to find any reference in man pages or searching the web.
You *can* override the initdefault in inittab via the kernel option, but if you're not seeing it in /proc/cmdline it's likely some other rc script. I saw some references to this being controlled via xen:
...
So it may be being passed through xen which might not show up in proc/cmdline (can't test right now).
Perhaps I mis-stated what I was asking. I'm well aware that Amazon (aka Xen) is passing run level 4 to the kernel because the number '4' is in /proc/cmdline. I can't change that since I cannot configure Xen or even ask Amazon to.
What I'm trying to figure out is at what point in the booting process is something looking at /proc/cmdline INSTEAD of /etc/inittab for the default run level.
Is it /sbin/init? I can't seem to find any reference of that in any man pages. Essentially, I'm trying to short-circuit this boot process to execute a run level of my choosing, and not be forced to use 4.
I've already looked at modifying /etc/rc.d/rc (since it's the one that uses /sbin/runlevel to execute various /etc/rcX.d scripts. I was hoping to have a more elegant way so that I don't have to maintain CentOS-specific bootstrap code.
Kurt Newman wrote:
Is it /sbin/init? I can't seem to find any reference of that in any man pages. Essentially, I'm trying to short-circuit this boot process to execute a run level of my choosing, and not be forced to use 4.
it's probably the kernel itself calling the value defined in /proc/cmdline
For example when I go to single user mode I often specify init=/bin/bash on the command line, which I'd expect would take /sbin/init completely out of the loop.
nate
nate wrote:
Kurt Newman wrote:
Is it /sbin/init? I can't seem to find any reference of that in any man pages. Essentially, I'm trying to short-circuit this boot process to execute a run level of my choosing, and not be forced to use 4.
it's probably the kernel itself calling the value defined in /proc/cmdline
For example when I go to single user mode I often specify init=/bin/bash on the command line, which I'd expect would take /sbin/init completely out of the loop.
I thought that as well, except that init is one of the kernel-defined boot parameters that it accepts (man bootparam, for more info), so the kernel can easily change what's called.
After a bit more research using different terms in google, I stumbled upon this page: http://www.nongnu.org/lpi-manuals/lpi-102/lpi102.html#id281730
I'm not exactly sure how the kernel determines what to pass to /sbin/init (or perhaps what init ignores), but it does some how distinguish what's a kernel module parameter, and what's not.
Regardless, /sbin/init does seem to be the culprit.
On Tue, Jan 26, 2010 at 03:48:45PM -0600, Kurt Newman wrote:
What I'm trying to figure out is at what point in the booting process is something looking at /proc/cmdline INSTEAD of /etc/inittab for the default run level.
Aren't these passed by the kernel to init as cmdline arguments and environment variables? Check out the kernel sources for init/main.c
I've already looked at modifying /etc/rc.d/rc (since it's the one that uses /sbin/runlevel to execute various /etc/rcX.d scripts. I was hoping to have a more elegant way so that I don't have to maintain CentOS-specific bootstrap code.
Well, it's not CentOS specific; it's Amazon specifc.
But, anyway, what differences are there between rc3 and rc4 ? On my machine they're minimal: % diff -r rc3.d rc4.d Only in rc4.d: K95firstboot Only in rc3.d: S99firstboot
If you build your rc files correctly so that they're chkconfig compatible then you just make your script get added to rc3 and rc4 eg # chkconfig: 2345 09 91 # description: my startup script
Alternatively, how about this inittab entry: 4:4:once:/sbin/init 3
May work. I've never tested!
Stephen Harris wrote:
On Tue, Jan 26, 2010 at 03:48:45PM -0600, Kurt Newman wrote:
What I'm trying to figure out is at what point in the booting process is something looking at /proc/cmdline INSTEAD of /etc/inittab for the default run level.
Aren't these passed by the kernel to init as cmdline arguments and environment variables? Check out the kernel sources for init/main.c
I've already looked at modifying /etc/rc.d/rc (since it's the one that uses /sbin/runlevel to execute various /etc/rcX.d scripts. I was hoping to have a more elegant way so that I don't have to maintain CentOS-specific bootstrap code.
Well, it's not CentOS specific; it's Amazon specifc.
I meant /etc/rc.d/rc being CentOS-specific (technically, RHEL-specific).
But, anyway, what differences are there between rc3 and rc4 ? On my machine they're minimal: % diff -r rc3.d rc4.d Only in rc4.d: K95firstboot Only in rc3.d: S99firstboot
If you build your rc files correctly so that they're chkconfig compatible then you just make your script get added to rc3 and rc4 eg # chkconfig: 2345 09 91 # description: my startup script
Alternatively, how about this inittab entry: 4:4:once:/sbin/init 3
May work. I've never tested!
The difference for a stock CentOS machine, is not much. However, I don't use a typical run-level system for my servers. I did try modifying /etc/inittab like you pointed out, so that it would use run level X start-up at run level Y, but when executing /sbin/runlevel, it still said '4'. Which, unfortunately, breaks my code (and there's a lot, so I don't want to change it).
In any event, it appears the easiest bet for me is to simply patch /etc/rc.d/rc and simply have it call some custom bootstrap code to ensure that it's in the correct run level when starting. Sucks, but probably the easiest way for what I need.
Thanks for the responses. Kurt
On Tue, Jan 26, 2010 at 05:35:37PM -0600, Kurt Newman wrote:
I meant /etc/rc.d/rc being CentOS-specific (technically, RHEL-specific).
You can still use the legacy names /etc/rc#.d (eg /etc/rc4.d is a symlink to /etc/rc.d/rc4.d; /etc/rc -> /etc/rc.d/rc).
In any event, it appears the easiest bet for me is to simply patch /etc/rc.d/rc and simply have it call some custom bootstrap code to
You should never need to touch /etc/rc.d/rc; if you do it might get overwritten if ever initscripts is updated.
-
Kurt Newman -
Kwan Lowe -
nate -
Stephen Harris