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.
Chris Olson wrote: <snip>
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
<snip> 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.
On Monday, July 3, 2017 5:58 AM, "m.roth@5-cent.us" m.roth@5-cent.us wrote:
Chris Olson wrote: <snip>
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
<snip> 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
_______________________________________________ CentOS mailing list CentOS@centos.org https://lists.centos.org/mailman/listinfo/centos
Chris Olson wrote:
On Monday, July 3, 2017 5:58 AM, "m.roth@5-cent.us" <m.roth@5-cent.us>wrote: Chris Olson wrote:
<snip> > 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 <snip> 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.
None of the previous kernels will boot properly.
Oh. That's very much not good. Have you run an fsck on /boot and /?
mark
On 07/03/2017 10:52 AM, m.roth@5-cent.us wrote:
Chris Olson wrote:
On Monday, July 3, 2017 5:58 AM, "m.roth@5-cent.us" <m.roth@5-cent.us>wrote: Chris Olson wrote:
<snip> > 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 <snip> 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.
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:
On 07/03/2017 10:52 AM, m.roth@5-cent.us wrote:
Chris Olson wrote:
On Monday, July 3, 2017 5:58 AM, "m.roth@5-cent.us"m.roth@5-cent.us wrote: Chris Olson wrote:
<snip> > 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
<snip> 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.
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.
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. <g> 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
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.
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.
On 07/03/2017 02:41 PM, Gordon Messmer wrote:
On 07/03/2017 05:07 AM, Chris Olson wrote:
A progress bar at the bottom of the start-up screen never reaches completion.
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?
On 07/03/2017 02:52 PM, ken wrote:
On 07/03/2017 02:41 PM, Gordon Messmer wrote:
On 07/03/2017 05:07 AM, Chris Olson wrote:
A progress bar at the bottom of the start-up screen never reaches completion.
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:
On 07/03/2017 02:41 PM, Gordon Messmer wrote:
On 07/03/2017 05:07 AM, Chris Olson wrote:
A progress bar at the bottom of the start-up screen never reaches completion.
Press "alt+d" on the keyboard to disable the graphical (or text) progress bar and view the console output of the startup sequence.
Or just hit <esc> and after the low-level, it'll display.
Is there a place (configuration file) where this can be made the default?
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
On Mon, 2017-07-03 at 15:16 -0400, m.roth@5-cent.us wrote:
ken wrote:
On 07/03/2017 02:41 PM, Gordon Messmer wrote:
On 07/03/2017 05:07 AM, Chris Olson wrote:
<snip>
Or just hit <esc> and after the low-level, it'll display.
I hit {F4} as soon as the rghb stuff starts to display and it shows messages as they occur.
<snip>
mark<snip>
Bill
-
Bill Maltby (C4B) -
Chris Olson -
Gordon Messmer -
ken -
m.roth＠5-cent.us -
Mark Haney -
Pete Biggs