Linux (CentOS 6.5 x86_64) Guest Kernel Panic on Reboot

[nnelson]

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:

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 #1

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.

[noteirak]

Please attach as zip a full log file from VM poweredoff to the issue and back to poweroff again - file details are located in Minimum information needed for assistance.

[nnelson]

I should have learned by now to consult the FAQ for minimum required information when asking for help.

For this particular attached log file I had to reboot the guest twice to make it crash. I've seen it not crash on reboot before (seldom) but it does happen. This seemed to be one (or two) of those seemingly rare times.

The first test I logged in via the console, rebooted (successfully), waited for it to come back up, SSH'd in, used dd to create a 1GB zero filled file (thinking it had to do with disk not syncing on a sizable write or something), rebooted. This resulted in the panic.

The second test I logged in via SSH, rebooted (successfully), waited for it to come back up, SSH'd in again, immediately rebooted. This resulted in the same panic as the first test (minus any extra sizable writes to the disk). This particular test is the one that I've posted the log for.

Also, if it helps track where the error occurred, these are the last 5 lines of the VBox.log file immediately after the panic in the guest OS occurred and just before powering off the guest (which appears to have added an additional 446 lines to the end of the log):

Code: Select all

00:01:11.972062 Guest Log: int13_harddisk: function 02, unmapped device for ELDL=8f
00:01:12.206950 PIT: mode=2 count=0x4a9 (1193) - 1000.15 Hz (ch=0)
00:01:12.484228 PIT: mode=0 count=0x10000 (65536) - 18.20 Hz (ch=0)
00:01:13.004813 OHCI: Software reset
00:01:13.004864 OHCI: USB Operational

Edit: I also attached a screenshot of the guest VM in the panicked state after the second reboot if that helps at all.