Tiny Core Base > Micro Core

Noautologin apparently doesn't work sometimes?

(1/3) > >>

adrianallen:
Sorry that my first post has to be somewhat complex - forgive me if the post seems overlong, I'm trying to include any details that might be relevant.

I've built a microcore-based recovery environment which installs into the boot partition on a large (several thousand) number of redhat based servers which are widely distributed geographically for remote management and recovery purposes - i.e. if the main OS gets hosed up somehow this gives us a chance to fix things. If you're interested in implementation details let me know and we can discuss in another topic.

In GRUB legacy (Redhat Enterprise distros aren't moving to GRUB2 until 7.x which we haven't updated to yet) the primary OS is option 0, and microcore is option 1.

Grub is configured by default to boot microcore in grub.cfg. When the main OS boots successfully, it runs a script from rc.sysinit which essentially does this:

echo  "savedefault --default=0 --once" | grub --batch

which causes the next boot attempt to again use the primary OS.

The idea here is that if the main OS fails to boot sometime between GRUB loading and completing all the init scripts, then all you have to do is power cycle the box and it will come back up in microcore, from where you can do disk diagnostics etc. - this all works fine and as expected.

However - for reasons unknown to me, if I manually set GRUB to boot microcore on the next boot attempt from within the primary OS, the "noautologin" option seems to have no effect. Microcore comes up normally and does everything it's supposed to do from within bootsync and bootlocal, but root is logged in instead of displaying a login prompt.

If I reboot from there, allowing the box to come up again in Microcore, noautologin works on the second attempt.  So far this seems to be very consistent but not 100% consistent, at least on my Intel motherboard test system - on a test box with an MSI motherboard it doesn't seem to happen (???). I have no idea why anything to do with hardware would affect how GRUB passes kernel options to Microcore?  It's possible the hardware difference is in my imagination and that the problem is actually random and just happens to have occurred in nearly all my tests on the Intel system and in nearly none of the tests on the MSI board but...

The fact that it works correctly on the second reboot seems to imply that the option is there and correctly configured. I have also added a line like echo "booting" > /etc/sysconfig/noautologin" to /opt/bootlocal.sh as well as verifying on the system once it has booted into a root shell instead of booting to a login prompt that "cat /proc/cmdline" shows noautologin as well as that /etc/sysconfig/noautologin exists (even without my change to bootsync.sh noted above) but somehow the system still comes up in a root shell.

 Any and all suggestions would be welcome - I'm extensively experienced with Redhat/Fedora variants but not as much with Gentoo (although I did run it as my desktop OS for a few months to get a feel for it).

I'm running Core 5.2 and the host OS is Scientific Linux 6.5.

gerald_clark:
It sounds like you have made some changes, as even without noautologin it would boot up and end up in a tc shell, not a root shell.
Also, I have no idea why you brought up Gentoo.

curaga:
Doublecheck what is in root's .profile if you've modified it, and perhaps try adding some debug statements in there to see what happens.

adrianallen:
Thanks for the replies.

Sorry about the Gentoo confusion, for some reason I had it in my head that Core was based on a stripped down version of Gentoo but I think that's actually the System Rescue CD which was the first distro I investigated for this project.

In response to the questions:

I have added a regular user as well as the root user. The tc user still exists also as well as the other default users.

My bootsync script has very minor modifications to do with setting the hostname based on the MAC address, updating resolv.conf and /etc/issue, and copying some files into place (I haven't incorporated these files into the base image because they change from time to time, so I keep them in /boot/opt on the host OS where I can use Puppet to update them, and then the updated versions get put into place during the boot process of Microcore - it's stuff like an authorized_keys file for ssh,  etc).

The bootlocal script is somewhat extensively modified as it loads kernel modules and drivers for some custom hardware like a small LCD screen which displays the unit's status to the users at the remote site, starts iptables with a predefined set of rules, brings up an openvpn tunnel so that I can remotely access the unit and then starts sshd, activates the local volume groups and performs an automated fsck on the main OS's volumes, etc. - but I don't understand how any of those actions would cause the system to log in as root?

The .profile file contains only two lines - one runs a script displaying the health of the box upon user login (with data gathered from smartctl etc.) and the other echos an information statement to the user.  In any case it's my understanding that .profile should not be executed until a user logs in, so that specific file shouldn't be able to influence the outcome of a boot attempt, should it?

The main thing I do not understand is the inconsistent behavior. This morning when I began testing, the Intel system booted just as expected - to a login prompt. On every subsequent boot attempt it has dumped me to a root shell.  Yesterday it booted to a root shell eight or nine times in a row and never booted correctly.  Each time, if I allow it to boot to the root shell and then simply reboot it again, it boots correctly (to a login prompt).

One thing I wonder - since I install Microcore on the target system via Puppet, as well as maintaining the state, ownership, and permissions of the config files and scripts in /boot/opt, is it possible that some file there has an incorrect permission or ownership which gets restored on the first Microcore boot attempt so that it subsequently works correctly, until the next time I boot to Scientific where Puppet runs and breaks it again?

This doesn't seem likely since the noautologin option appears to be passed to Microcore correctly (see my first post) and I don't think that scripts or files inside the OS would affect how the OS is loaded?

gerald_clark:
Since bootsync.sh and bootlocal.sh run before /etc/inittab is scanned, I suspect your problem is there.
Something is not running correctly and you land in a shell before login is executed.

Navigation

[0] Message Index

[#] Next page