System Start-Up Issue
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.
Recommended
Recent Posts
- CentOS-announce Digest, Vol 218, Issue 2
- Problem 1: Package Resteasy-3.0.26-6.module_el8.4.0+595+e59c9af2.noarch From @System Requires Pki-servlet-4.0-api, But None Of The Providers Can Be Installed
- CentOS 7/8s EOL : Infrastructure Impacts (please Read)
- CentOS Virt SIG And Packages’ Priority Problems?
- CentOS-announce Digest, Vol 218, Issue 1
Recent Comments
- igor on LibGLU.so.1
- Hussein on NBDE, Clevis And Tang For Non-root Disk
- João M. S. Silva on CentOS 7.6 1810 Vs. VirtualBox : Bug With Keyboard Layout Selection
- Jim Plumb on Spamassassin Vs. SELinux Trouble
- woodiskingser on Off Topic – Need Help Registering To The Smplayer Forum
Archives
- March 2024
- February 2024
- January 2024
- December 2023
- November 2023
- September 2023
- August 2023
- July 2023
- June 2023
- May 2023
- April 2023
- March 2023
- February 2023
- January 2023
- December 2022
- November 2022
- October 2022
- September 2022
- August 2022
- July 2022
- June 2022
- May 2022
- April 2022
- March 2022
- February 2022
- January 2022
- December 2021
- November 2021
- October 2021
- September 2021
- August 2021
- July 2021
- June 2021
- May 2021
- April 2021
- March 2021
- February 2021
- January 2021
- December 2020
- November 2020
- October 2020
- September 2020
- August 2020
- July 2020
- June 2020
- May 2020
- April 2020
- March 2020
- February 2020
- January 2020
- December 2019
- November 2019
- October 2019
- September 2019
- August 2019
- July 2019
- June 2019
- May 2019
- April 2019
- March 2019
- February 2019
- January 2019
- December 2018
- November 2018
- October 2018
- September 2018
- August 2018
- July 2018
- June 2018
- May 2018
- April 2018
- March 2018
- February 2018
- January 2018
- December 2017
- November 2017
- October 2017
- September 2017
- August 2017
- July 2017
- June 2017
- May 2017
- April 2017
- March 2017
- February 2017
- January 2017
- December 2016
- November 2016
- October 2016
- September 2016
- August 2016
- July 2016
- June 2016
- May 2016
- April 2016
- March 2016
- February 2016
- January 2016
- December 2015
- November 2015
- October 2015
- September 2015
- August 2015
- July 2015
- June 2015
- May 2015
- April 2015
- March 2015
- February 2015
- January 2015
- December 2014
- November 2014
- October 2014
- September 2014
- August 2014
- July 2014
- June 2014
- May 2014
- April 2014
- February 2014
- January 2014
- April 2013
- December 2012
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 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
cycle.
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.
Is there a place (configuration file) where this can be made the default?
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