I hosed my login (bad script /etc/profile.d) and I can't SSH into my system or boot it into single. I append " single" to the end of the kernel boot parameters and it just keeps booting like normal. I've also tried " s" with no avail. However, " emergency" does work. I'm running RHEL 6.3. Any ideas on what I'm doing wrong?

  • Please confirm you're using these steps with CentOS/RHEL 6.3: itzgeek.com/how-tos/linux/centos-how-tos/… – slm Apr 25 '14 at 21:45
  • @slm i'm doing that verbatim – majikman Apr 25 '14 at 21:48
  • Those steps are identical to the official docs too: access.redhat.com/site/documentation/en-US/…. So there's got to be something more that you're not telling us? – slm Apr 25 '14 at 23:13
  • Was this change made to the system? electromech.info/index.php/… – slm Apr 25 '14 at 23:20
  • @slm i wish there was. i think my description of what i did in the original post pretty much exactly follows the steps in the redhat guide. and besides, it's not like the redhat guide is asking me to do something complicated. literally, it's edit kernel boot parameters and type " single". i don't know how anyone could possibly mess that up. as for switching the sulogin, no that change wasn't made. however, from the looks of the article, that change only disables passwords when booting into single user mode, not disabling single user mode itself. – majikman Apr 27 '14 at 3:35

My suspicion is that something in /root/.bashrc (or something being source'd by that file) is causing bash to immediate exit, resulting in the machine booting to the default runlevel. For more details about this suspicion, see the below.

Any kernel arguments that are not recognized by the kernel are passed onto init. According to bootparam(7):

Any remaining arguments that were not picked up by the kernel and were not interpreted as environment variables are then passed onto process one, which is usually the init(1) program. The most common argument that is passed to the init process is the word 'single' which instructs it to boot the computer in single user mode, and not launch all the usual daemons. Check the manual page for the version of init(1) installed on your system to see what arguments it accepts.

Since RHEL 6 runs upstart, you will likely want to inspect the upstart configuration files that relate to single-user mode:

  • /etc/init/rc.conf
  • /etc/init/rcS.conf
  • /etc/init/rcS-sulogin.conf
  • /etc/init/rcS-emergency.conf

On the Centos 6.5 system I have locally, /etc/init/rcS-sulogin.conf has the following upstart stanzas:

        . /etc/sysconfig/init
        plymouth --hide-splash || true
        [ -z "$SINGLE" ] && SINGLE=/sbin/sushell
        exec $SINGLE
end script
post-stop script
        if [ "$RUNLEVEL" = "S" ]; then
                [ -f /etc/inittab ] && runlevel=$(/bin/awk -F ':' '$3 == "initdefault" && $1 !~ "^#" { print $2 }' /etc/inittab)
                [ -z "$runlevel" ] && runlevel="3"
                exec telinit $runlevel
end script

The post-stop script brings the system up to the default run level after the shell started by sushell has terminated. /sbin/sushell is a simple script that starts either the value of $SUSHELL or bash. By default, the bash that is started is an interactive, non-login shell, meaning that it reads ~/.bashrc on startup.

If this file inadvertently terminated the shell, the system would proceed to boot to the default runlevel.

The emergency keyword likely works because it invokes /sbin/sulogin, which (according to the man page) falls back to /bin/sh if its attempt to execute the root user's shell fails.

Note, that for the most dire disasters, you can tell the kernel to boot to a shell directly appending init=/bin/sh. You will be booted to a shell running as root. If you need to make changes to the filesystem, you will also want to change the ro boot argument to rw so your root device is mounted for writes, or remount the device once booted.

  • unfortunately, i no longer have the system in that state anymore to test if this works. i wish i had enough points to mod this up, but i don't. thanks for the very informative response – majikman Sep 22 '14 at 17:44
  • @majikman Keep working for it, you'll make it – eyoung100 Nov 24 '14 at 16:47

If you have physical access to the machine there is relatively easy. Boot up a recovery CD into the root shell and then mount and repair the damage on the files. Once you are done you should be able to reboot without problems.....unless there is something else going on that you have not mentioned...:-)

  • Thanks. I've already done that, but I'm trying to solve this issue that I'm having with not being able to boot into single user mode. I don't want to have to rely on a recovery CD when I should be able to boot into single user mode. – majikman Apr 27 '14 at 3:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.