Re: [Qemu-discuss] Kernel panic when booting from SCSI disk

[Thomas Oberhammer]

On 28/07/2012, at 7:50 AM, Mike Lovell wrote:

On 07/24/2012 11:15 PM, Thomas Oberhammer wrote:

The short version:

I'm trying to run a VMware image on qemu. Therefore I need to be able to attach the disks via SCSI interface in qemu.

Is there a possibility to do so?

Some background information:

The VMware image consists of 2 disks and has been successfully converted, so that I can boot it with qemu. I can attach the disks via IDE, but this causes that the image is not fully functional.

The problem comes from the fact, that the image originally was designed for VMware, and some part of its code relies on the condition as they are on VMware, e.g. that the disks are attached via SCSI interface and can therefore be found on /sys/class/scsi_device.

Or differently speaking, when I run the image, the disks are named hda & hdb, but the image requires them to be sda & sdb to provide the full functionality.

The image is linux based, the kernel version is 2.6.9. I am aware that the problem would vanish if this could be upgraded to 2.6.20 (since then both SCSI and IDE devices are named sda/sdb/...), but this is not possible.

The problem:

If I attach my disk with

kvm --enable-kvm -m 1024 \

-drive file=disk1_converted-flat.vmdk,if=scsi,index=0,format=raw,boot=on \

-drive file=disk2_converted-flat.vmdk,if=scsi,index=1,format=raw \

I can initiate the boot process, but at some point I end up with the message

Kernel panic - not syncing: Attempted to kill init!

But if I use

kvm --enable-kvm -m 1024 \

-boot c \

-drive file=image-disk1_converted-flat.vmdk,if=ide,index=0,format=raw \

-drive file=image-disk2_converted-flat.vmdk,if=ide,index=1,format=raw \

it works fine (at least concerning booting).

At the point when the first (i.e. SCSI) version crashes, the second (i.e. IDE) shows the following output:

EXT3-fs warning: maximal mount count reached, running e2fsck is recommended

EXT3 FS on hda5, internal journal

EXT3-fs: recovery complete.

EXT3-fs: mounted filesystem with ordered data mode.

-> it seems that the SCSI version crashes when it tries to mount the disks.

Does anyone have an idea, how this problem can be solved?

Please not that...

- the image cannot be modified

- the image has no virtio drivers installed

I am using QEMU Version 0.12.3, but I also tried 1.0.1 and it showed the same behaviour.

ummm. how did you do the conversion from vmware? cause it sounds like the guest image is in a different state than when it was running in vmware.

the kernel panic when using the SCSI interface is most likely due to the kernel trying to mount the root file system from a disk it can't find or use. the fact that it boots when using the IDE interface also points to this. it sounds like the boot loader in the virtual machine is configured to use hda (or similar) instead of sda. if the image came from a place that was using sda for the root filesystem, then the image got modified somewhere along the line and i would guess that the tool you used for the conversion is at fault.

if this is the case, you're going to need to modify the guest image at least some to change the boot loader parameters. you can test this by booting the guest with the SCSI interface and interrupting the boot loader and modifying its command line options for the guest. there should be a root=/dev/hda or similar option that you can change to /dev/sda or similar.

another thing you could try is just booting a copy of the original vmdk in qemu without any conversion. if you are using a recent version of qemu, it should be able to use most vmdk images just fine. i have seen a few issues of qemu not able to use a vmdk from an esxi 5 server though. i would definitely recommend using a copy of the vmdk though and not the original.

mike

I tried different things, but the situation is unchanged.

Conversion of the disks:

------------------------

I started with the vmdk files that were contained in the ova.

I was not able to boot them, neither with if=ide, nor with if=scsi.

(The error message was: no bootable devices found)

After that, I converted the disks:

vmware-vdiskmanager -r disk1.vmdk -t 0 disk1_t0.vmdk

Now, qemu found a bootable device, but the error was the same as described in the original post.

The next step was to convert the disk to qcow2 format:

qemu-img convert disk1_t0.vmdk -O qcow2 disk1.qcow2

But also after this, the situation was still the same.

Boot loader parameters:

-----------------------

The current boot loader parameters are:

root (hd0,1)

kernel /vmlinuz root=LABEL=ROOT1

initrd /initrd.img

I tried root=/dev/... with sda, sda1, sda5, hda, hda1, hda5, disk0p5

in combination with if=ide and if=scsi

The only combination that did not create a kernel panic was 

if=ide and root=/dev/hda5

I also enabled the debugging option, giving a little more insights what actually caused the kernel panic:

(as you said, it cannot find the root file system)

Setting up fail make_request

Freeing unused kernel memory: 200k freed

Mounted /proc filesystem

Mounting sysfs

Creating /dev

Starting udev

Waiting for root device

Waiting for ROOT filesystem to become available [ROOT1]

Waiting for ROOT filesystem to become available [ROOT1]

[...]

ERROR: Unable to find root device ROOT1

Creating root device

Mounting root filesystem

mount: Mounting /dev/root on /sysroot failed: No such file or directory

mount: Mounting /dev on /sysroot/dev failed: No such file or directory

mount: Mounting /proc on /sysroot/proc failed: No such file or directory

mount: Mounting /dev/root on /sysroot failed: Invalid argument

Switching to new root

switch_root: bad newroot /sysroot

Kernel panic - not syncing: Attempted to kill init!

I wonder what the right path would be to access a disk that is attached via

-drive file=diskname,if=scsi

Thomas