Linux (CentOS 6.5 x86_64) Guest Kernel Panic on Reboot
Posted: 30. Apr 2014, 17:17
Unfortunately I've had problems related to kernel panics on reboot for Linux guest VMs for a few years now. I realize "Linux" encompasses a broad list of distros and I do recall having issues on many Linux distributions but I cannot absolutely confirm that or recall the specific details in those specific events.
This particular problem is happening on CentOS 6.5 x86_64 guest VM. I'm running Mac OS X 10.9.2 and VirtualBox 4.3.10 r93012. The problem occurs when I try to reboot the guest VM and is reproducible nearly 100% of the time. Upon a reboot the boot message reads:
Then it has the call trace with what look to be memory addresses.
The issue will persist after resetting the guest VM using the VirtualBox reset option. The only way I have determined to resolve it (and only for that one reboot) is to power off the guest and power it back on.
I've determined that this exact same error within the guest OS happens on other host OSes too. At first this happened years ago while running VirtualBox on top of Arch Linux with a Linux guest. I thought the issue perhaps was related to my LUKS encrypted HD that my host OS was running VirtualBox on/in but it kept happening even without LUKS encryption.
This issue seems to persist across different host operating systems and versions as well as different VirtualBox versions. I've hosted the VirtualBox guest virtual hard drive images on external Firewire drives, internal hard drives, internal SSDs, encrypted volumes, unencrypted volumes, etc. and nothing seems to make much difference.
As I mentioned above I have no hard evidence to absolutely prove this does or doesn't happen to every Linux guest distribution I've tried (I mostly use CentOS 6.x x86_64 inside VirtualBox) but I know for certain it has happened nearly every time with CentOS 6.x x86_64. One thing I have noticed is that I seem to have no problems when running Windows as the guest OS (I've tried multiple variants through the years including Windows XP through Windows 8 as well as multiple Windows Server versions of both the 32 and 64-bit variants).
This particular instance I'm writing about today is not running/does not have installed VirtualBox guest additions inside the guest OS. That being said, I do seem to recall that being irrelevant as to rather this happens or not.
Finally, one additional piece of information, I can confirm that this happens rather a VM is cloned, new install from an ISO, is linked from another VM, has a snapshot or has no snapshots at all.
Surely there's something obvious that I am doing that is not supported or at the very least against best practice that would cause this to keep happening, specifically across host OSes. I've tried other virtualization products (KVM, Parallels, etc.) and I've not encountered this same issue with any of them.
This particular problem is happening on CentOS 6.5 x86_64 guest VM. I'm running Mac OS X 10.9.2 and VirtualBox 4.3.10 r93012. The problem occurs when I try to reboot the guest VM and is reproducible nearly 100% of the time. Upon a reboot the boot message reads:
Code: Select all
RAMDISK: gzip image found at block 0
RAMDISK: incomplete write (20115 != 31588)
write error
VFS: Cannot open root device "mapper/VolGroup-lv_root" or unknown-block(0,0)
Please append a correct "root=" boot option; here are the available partitions:
Kernel panic - not syncing: VFS: Unable to mount root fs on unknown block(0,0)
Pid: 1, comm: swapper Not tainted 2.6.32-431.11.2.el6.x86_64 #1The issue will persist after resetting the guest VM using the VirtualBox reset option. The only way I have determined to resolve it (and only for that one reboot) is to power off the guest and power it back on.
I've determined that this exact same error within the guest OS happens on other host OSes too. At first this happened years ago while running VirtualBox on top of Arch Linux with a Linux guest. I thought the issue perhaps was related to my LUKS encrypted HD that my host OS was running VirtualBox on/in but it kept happening even without LUKS encryption.
This issue seems to persist across different host operating systems and versions as well as different VirtualBox versions. I've hosted the VirtualBox guest virtual hard drive images on external Firewire drives, internal hard drives, internal SSDs, encrypted volumes, unencrypted volumes, etc. and nothing seems to make much difference.
As I mentioned above I have no hard evidence to absolutely prove this does or doesn't happen to every Linux guest distribution I've tried (I mostly use CentOS 6.x x86_64 inside VirtualBox) but I know for certain it has happened nearly every time with CentOS 6.x x86_64. One thing I have noticed is that I seem to have no problems when running Windows as the guest OS (I've tried multiple variants through the years including Windows XP through Windows 8 as well as multiple Windows Server versions of both the 32 and 64-bit variants).
This particular instance I'm writing about today is not running/does not have installed VirtualBox guest additions inside the guest OS. That being said, I do seem to recall that being irrelevant as to rather this happens or not.
Finally, one additional piece of information, I can confirm that this happens rather a VM is cloned, new install from an ISO, is linked from another VM, has a snapshot or has no snapshots at all.
Surely there's something obvious that I am doing that is not supported or at the very least against best practice that would cause this to keep happening, specifically across host OSes. I've tried other virtualization products (KVM, Parallels, etc.) and I've not encountered this same issue with any of them.
