A Kernel Panic and Resolution

While performing yum updates on CentOS 7 minimal install virtual servers, I came across a problem server.  The server needed a reboot after performing a hardware change.  It did not come back up. It had a Kernel Panic error.  I did so many things to that server, I didn’t know what the cause for the panic was, but fortunately I had a snapshot of it just prior to all my changes.  The snapshot reverted successfully and I nailed down the culprit and resolution.

Using top, I discovered that the server hadn’t been rebooted in 90 days.  Many yum updates have been performed on it in that 90 day span. The command uname -r identified the kernel version that the OS was using.  With the rpm -q kernel command, it can be seen that there were four more kernels on that box.  With that in mind, I rebooted the system into the newest kernel.  Kernel Panic.  Rebooted again, to the next kernel version. Kernel Panic.  The Kernel Panic continued with each of the four tested kernels. The system did successfully reboot into the original kernel (where we started from in the beginning).

The resolution to this Kernel Panic was simple, though the cause is still unknown to me.  The implication is that the unused and installed kernels were corrupt. There was plenty of diskspace as indicated by df -ThP. Now logged into the system, issuing the following commands shouldn’t effect the existing active kernel. If it should make you feel better, use uname -r to compare your active kernel to the other versions.

yum remove kernel
yum update kernel

Reboot into the new kernel. It was a success.