System Start-Up Issue

Home » CentOS » System Start-Up Issue
CentOS 11 Comments

We run several Intel-based CentOS machines.  They are all at 6.9 or 7.x. One of each OS is Oracle VirtualBox hosted on an up to date Windows 7 system. We use these virtual machines for checkout of new applications before they are loaded on native CentOS platforms.  Regular weekly updates are run on all of our CentOS machines.

I went on vacation right after an update to one of our virtual CentOS 6.9
systems so it was not restarted for a period of time.  Now it will not complete boot-up with the gnome display never fully launched.  A progress bar at the bottom of the start-up screen never reaches completion. We have not been able to detect a running system on the network.

Two options for stopping the CentOS 6.9 virtual machine have been tried. One is to “power off” and the other is to “send the shutdown message“. Both of these options appear to work properly.  The shutdown output scrolls by very fast but it looks reasonable and the virtual machine eventually closes.

We have also tried suspending boot-up and selecting two previous working kernels.  This yields the same result of an incomplete start up.  Shutdown of these old kernel systems appears the same as shutdown of the newest kernel.  However, we have not been able to determine from any of the shutdown sequences exactly how much of the system was actually running.

Having very little experience with such start-up issues, we are at a loss to determine how to salvage the CentOS 6.9 virtual machine.  Is there a standard way to start up a system without any extras like gnome to see if we can get a running system?  Would it be wise to attempt using yum update after we get a running system to see if issues are corrected?  Thanks.

11 thoughts on - System Start-Up Issue

  • Chris Olson wrote:


    Suggestion: boot to the previous kernel. If that works, reinstall the update, then reboot to it.

    We had real issues months back, where a yum-cron appeared to half-ignore the exclude=kernel line in yum.conf, and it would consistently fail to boot, but once the above was done, reinstalling the latest kernel, *then*
    it rebooted with no problem.

    mark

  • None of the previous kernels will boot properly.



    Suggestion: boot to the previous kernel. If that works, reinstall the update, then reboot to it.

    We had real issues months back, where a yum-cron appeared to half-ignore the exclude=kernel line in yum.conf, and it would consistently fail to boot, but once the above was done, reinstalling the latest kernel, *then*
    it rebooted with no problem.

        mark

  • Interrupt the boot process in the same way as you do when booting into a previous kernel and then edit the grub boot line to add a run level at the end – so ‘3’ to boot multiuser without a gui or ‘1’ to boot into single user mode. The line you want to edit is the one that has ‘rhgb quiet’ in it – you might want to remove those as well so that you can see what’s happening (although you will get ALOT of output).

    P.

  • Chris Olson wrote:
    Oh. That’s very much not good. Have you run an fsck on /boot and /?

    mark

  • Okay, stupid question, if yum-cron was jacked up months back are you still using it? And if so, why? Never in my life have I ever scheduled updates on any server for any reason. Mostly because I don’t trust it to do it right. Also mostly because I use ansible to manage that, and that playbook is always manually run just in case there’s an issue.

    But yeah, you might be hosed. If this is a VM, do you not have a snapshot handy? (I know, I’m late to the party but was camping this weekend.

  • Mark Haney wrote:
    network.

    I think you’re mixing up the OP and me. The issue for us seems to have been fixed – I suspect it was an issue with yum – it was as though it updated the kernel, but then didn’t run the postinstall scripts. Haven’t had that happen in a while.

    And no, not a VM. We only have a few VMs; most are bare metal. But then, our servers are for scientific computing, and we need every bloody CPU
    cycle. I’ve got users who may be the only one on a server, or a server with *two* Tesla cards, or a cluster of 23 or 24 servers, with over 1100
    or 512 cores, whose jobs run, literally, for weeks.

    mark

  • Press “alt+d” on the keyboard to disable the graphical (or text)
    progress bar and view the console output of the startup sequence.

  • Edit grub and remove ‘rhgb’ from the kernel line. Alternatively, you can boot to runlevel 3, which, I think, used to not have the graphical boot display.

  • ken wrote:

    Or just hit and after the low-level, it’ll display.

    Edit the menu before booting. You’ll want to put your parms on the linux16
    line. Servers should be runlevel 3 anyway. And it’s always annoyed me that a server install puts rhgb quiet in grub.

    mark

  • I hit {F4} as soon as the rghb stuff starts to display and it shows messages as they occur.

    Bill