This is probably a duplicate question, but I'm not familiar enough with the login/boot process of CentOS (especially on a VM) to know what to search for.

I'm running CentOS 7 in VirtualBox. I accidentally appended gnome-terminal to the end of my ~/.bashrc file. So now a terminal window pops up when I log in. That terminal session executes .bashrc, which opens another window, etc. etc., and I'm flooded with a ton of gnome-terminal terminal windows.

I'm trying to log into a terminal session without the GUI login (so gnome-terminal fails), but I can't get it to boot without the GUI. I've tried using the answers to this question, with no success. I get a GUI login every time: How to Boot CentOS in CLI?. Is there another way to edit the grub configuration at boot, or a way to get to a new terminal instance from the GUI login, like Ctrl+Alt+F1 in Ubuntu? (Yes, I tried it. It either doesn't work in CentOS 7, or it doesn't work in a VirtualBox VM.) Or is there some other way I can get a terminal session without a GUI, so I can edit my .bashrc and fix this mess?

  • 4
    Is sshd up on that VM? Many ways. 1) Start as Single user mode (e.g. enter at boot time, select the kernel, press a, append single, enter...) 2) if in your VM system run sshd you can try to copy your .bashrc modify and it copy back (scp, sftp rsync ...). 3) you can log as another user and do su - ... 4) from another machine (even virtual) you can do ssh user@host mv .bashrc bashrcToModify then log, modify... 0) Before of all does CTRL ALT F1 work from the VM?
    – Hastur
    Commented Dec 14, 2017 at 1:40
  • 2
    When you say "accidentally appended gnome-terminal", how did that happen?
    – mcfedr
    Commented Dec 14, 2017 at 21:31
  • @mcfedr I was waiting for someone to ask XD . I misunderstood what .bashrc was for. I thought it was run once at login, but it's run every time any shell session is started. I wanted a terminal window to pop up every time I signed in, so I did echo 'gnome-terminal' >> ~/.bashrc. Bad idea. I guess I should put gnome-terminal in /etc/init.d or somewhere? I'm still trying to understand the boot process. Commented Dec 14, 2017 at 21:41

4 Answers 4


CtrlAltF1 might be getting captured by the host, or VirtualBox might not be passing it on correctly. A couple of quick tests tells me that you can use the Host key defined in VirtualBox instead of CtrlAlt (could be the left Ctrl, or the left on Macs). So, pressing F1 switched to TTY1 in VirtualBox for me (and similarly for F7 back to GUI).

  • 1
    Yup. That worked. Ctrl+F2 did the trick for me. It looks like Ctrl+F1 is the GUI session in CentOS, but it's the same principle. IMO this is the simplest solution- no need for extra media or editing boot configuration. I'm marking this as the answer. Commented Dec 14, 2017 at 16:28
  • 2
    @MichaelHoffmann yes, that would be an effect of a newer CentOS than I have. GDM behaviour changed between 6 and 7 to use the first available TTY instead of TTY 7.
    – muru
    Commented Dec 14, 2017 at 16:30
  • 2
    It's changing further in future releases: The login screen will be on vconsole 1, and each logged in graphical user will occupy each subsequent vconsole (when you log in, your session is on vconsole 2, if you user-switch the next user will be on vconsole 3, etc). Commented Dec 14, 2017 at 18:42

You could boot with a live Linux CD and then mount the CentOS filesystem, and edit the .bashrc file from there.

  • 2
    Simplest solution. Also works for misconfigurations that prevent logging on or even booting entirely (as long as you know what is wrong and how to reverse it.)
    – alexis
    Commented Dec 14, 2017 at 10:32
  • This is extremely simple, especially where a VirtualBox user is pretty much guaranteed to have an ISO of the guest OS sitting around. But I'm afraid I have to select muru's answer because it's even more simple. Thank you for the contribution. Commented Dec 14, 2017 at 16:27

Init /bin/sh from grub configuration

You can edit your grub configuration to load up a root shell instead of going to the GUI.

  1. Reboot your VM
  2. When the grub menu appears, select the first entry and press e to edit. If it doesn't appear, restart and hold Shift during boot
  3. Find the line beginning with linux16 or linux. Mine looks like this. Yours may differ slightly

    linux16 /vmlinuz-3.10.0-327.18.2.el7.x86_64 root=/dev/mapper/centos-root ro crashkernal=auto rd.lvm.lv=centos/root rd.lvm.lv=centos/swap rhgb quiet LANG=en_US.UTF8
  4. Change the ro to rw (readonly flag to readwrite so you can write changes) and append init=/bin/sh to the line. This tells linux to run /bin/sh instead of init on startup. Example for my entry

    linux16 /vmlinuz-3.10.0-327.18.2.el7.x86_64 root=/dev/mapper/centos-root rw crashkernal=auto rd.lvm.lv=centos/root rd.lvm.lv=centos/swap rhgb quiet LANG=en_US.UTF8 init=/bin/sh
  5. Press Ctrl-X to run the configuration. It won't be saved.

  6. A root shell will appear. Use it to edit your .bashrc and remove the offending line.

    Note that you shouldn't keep using the OS in this state as the shell will be running as PID 1, normally reserved for the init process. You can manually continue init with exec /sbin/init but I'd recommend just rebooting

  7. Reboot as normal. Your previous changes will be forgotten.

We're essentially editing the boot options passed to Linux from GRUB, which tell Linux to mount the root filesystem read-write and start /bin/sh for the init process

This works for me using Centos 7 and VirtualBox 4.3.12

  • Hm... that worked perfectly (and a little disturbingly- could someone do this to my laptop to get to a root shell with no credentials?). But it caused a kernel panic when I exited the shell, so I don't know if I can mark this as the answer... Can you explain why this works? what do ro and rw? Or better yet, is there a manpage for linux16? What am I doing here? Commented Dec 14, 2017 at 16:22
  • 5
    @MichaelHoffmann this is a standard, well known way to get root - you have to password protect the bootloader to block this. It causes a kernel panic because init is never supposed to exit, but the panic is harmless otherwise. You can continue boot by exec /sbin/init or whatever the actual init is. The ro and rw options mount root read-only or read-write. You're essentially editing the GRUB menu to tell it to boot Linux with these options, which tell Linux to mount the root filesystem read-write and start sh for init.
    – muru
    Commented Dec 14, 2017 at 16:35
  • 1
    @muru I added a few of your comments into the answer to help make things clearer.
    – lex
    Commented Dec 14, 2017 at 22:53

scp a repaired copy of .bashrc into place

If you have another machine to work from, grab a copy the broken file and fix the problem, then put it back where it came from. This avoids logging in and invoking any of the login commands.

user@backup ~ $ scp user@homehost:~/.bashrc busted.bashrc
user@backup ~ $ vim busted.bashrc # fix, fix
user@backup ~ $ scp busted.bashrc user@homehost:~/.bashrc
user@backup ~ $ rm busted.bashrc

Addendum: As OP points out below, this requires SSH access to homehost. If that is not an option but FTP/SFTP is available instead, any file-transfer method will do what you need, which is simply to install the corrected login file.

  • 1
    This works, but only if the VM has sshd running on it (which I'm not sure CentOS does by default), and if the network is configured correctly with VirtualBox and in the host and in the VM. Commented Dec 14, 2017 at 20:20

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .