Recommended Package updates completed, but now don't get login screen (port 10000)

Hi guys, I have been a bit late with running my recommended updates on my CentOS Linux 7.8.2003 server.

Like always I run the updates. But I saw it failed somewhere. I did not see the error.

Has anyone gotten the same response, or know about any updates that causes you not yo get the login screen, eg

Please assist urgently

Is this a metal server? There was a problem with one of the kernel updates for RH-based distros that prevented metal servers from rebooting after the update, but I think that’s been fixed.

I don’t know of any updates affecting the ability to log in to Virtualmin. Can you log in to the shell?


Its a VPS.

Sorry logging into to webmin.

Ok did /etc/init.d/webmin restart, and worked. But why?

(Its seems to be memory related.)

The server still needs to be rebooted though.

Restarted my VPS, but now it does not come back on…cant ssh into it!!!

Server guys says that my VPS… “kernel panic can be noticed”

So, I am in rescue mode, and mounted drives to get important info off.

Then boot back in normal mode.

Anyone experienced something similar when upgrading 1.954 to 1.955?

Booted into normal mode, but still cant ssh into it…???

Is there any log I can inspect, when rescue mode, why normal bootup dont work?

Had to revert to previous kernel. Not sure what is wrong with the latest kernel upgrade

This is the message from the server guys:

“We can inform you that it is possible that a query or process froze or became stuck during the upgrade process which caused the high RAM usage and possible caused the upgrade to fail.”

Virtualmin please confirm get back to me

Issue seems to be upgrading kernels from
Linux 3.10.0-1127.13.1.el7
Linux 3.10.0-1127.19.1.el7

1 Like

Thank you for the updates.

My update from 3.10.0-1127.13.1.el7 to 3.10.0-1127.19.1.el7 was uneventful, but I have Kernelcare installed and rarely do the kernel updates manually (nor reboot the server afterwards, or course) unless the kernel update is related to a zero-day security bug. Igor is usually pretty quick about patching things anyway, so it has to be a pretty extreme situation before I update the kernel manually.

I also haven’t read about any problems related to that specific upgrade.

In any event, I think it’s unlikely that Virtualmin would have anything to do with a problem that occurred during a CentOS kernel upgrade because I’m almost certain that all it does is run yum.

You can enable syslog kernel logging in /etc/rsyslog.conf by adding

kern.* /var/log/kernel.log

( kern.* TAB TAB TAB /var/log/kernel.log )

In the meantime, you can try poking around in

/var/log/dmesg (and /var/log/dmesg.old if it exists)


/var/log/boot.log (and older saved boot logs)

/var/log/yum.log (and older logs)

but it’s a crapshoot whether you’ll find anything useful.

You can get recent kernel update history with

rpm -q kernel --last

but it’s just a list.


Thanks Richard, For the detailed explanation, and the advise in using Kernelcare (I’ll research it later on). (Apologies in going crazy with messages last night, but I just needed to post what I was doing…)

I am not sure if the logs are still intact, when you revert to previous kernel. But I’ll check the logs anyway. I do KNOW seeing an error w.r.t. not enough memory.

I wonder by stacking up updates, and not doing within a certain timeframe, the os gets confused. I doubt this will be in the case of CentOS

Anyway, I running a version behind, and have another server, which I did not do, which also have to be updated.

Not sure how to proceed now with the upgrade:

  1. Do I increase my memory on the VPS
  2. Do each of upgrades (eg. I think there is 33 components to be upgraded) one by one, Virtualmin allows you to do it.

To my knowledge, all Virtualmin does is run yum. If there is a problem related to a kernel update, it’s almost certainly at the OS level, not the panel level.

I suppose there also could be some filesystem corruption. Maybe a FSCK is in order?

I have no idea whether you should increase the RAM because I have no idea how much RAM you have.

Does your host provide a way to make and restore snapshots? That may be the safest route to go at this point. You may also want to peruse this thread. Seems the OP had the same problem and it was an interruption in the kernel update.

As for Kernelcare, it’s not officially supported in Virtualmin (or at least wasn’t the last time I checked), but all that means is that you’re still presented with the kernel updates until Kernelcare patches them. I generally research the update and leave it be until Igor patches it if it’s a bugfix that doesn’t affect the particular server’s mission. If it’s a zero-day exploit or something horrid like that, then I’ll update it manually.

Personally, I think Kernelcare is well worth the low cost if for no reason other than the dramatic reduction in reboots.


I’m dealing with this (again) on an AWS instance, I have restore to a previous snapshot, but this is the 2nd time I’ve had to deal with this in the last few months.

I do believe it’s several factors that are causing this, not sure if Webmin has anything to do with it or not at this point. AWS’s documentation is a bit dated, so I’m going to have to take some time and sort his out. Last time was an easy fix, this time around is a touch harder, not sure exactly why just yet. Should known soon.

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.