Re: [PATCH 1/1] OvmfPkg PlatformBootManagerLib: Move TryRunningQemuKernel()


James Bottomley
 

On Tue, 2021-08-10 at 10:10 +1000, Christoph Willing wrote:
On 10/8/21 12:52 am, James Bottomley wrote:
On Mon, 2021-08-09 at 22:53 +1000, Christoph Willing wrote:
With soft feature freeze started, I wonder if this patch could be
reviewed and pushed for edk2-stable202108 tag? I think it has
languished because I didn't initially Cc appropriately - pls add
others as necessary.

This patch is a trivial (I think) change which fixes a long
standing
and annoying bug for those booting Qemu with UEFI using external
kernel & initrd.
I'm with Ard on this one: -kernel is working just fine for me and
the
team at IBM working on Kata containers. It sounds like this might
be a
problem local to your environment, so we need to debug it to
understand
the issue rather than blindly reverse existing commits.
Thanks for responding James & Ard.

Below is the script I'm using to create, then run, the VM. To verify
that it works normally with UEFI boot, it initially uses the internal
kernel & initrd.

The OVMF_CODE & my_VARS lines contain git hash to identify the build
from which OVMF_CODE.fd & OVMF_VARS.fd were taken; 97fdcg is from a
build of yesterday's git master.

After the OS has been installed, I can run the VM multiple times to
verify that it boots under UEFI OK (I see the TianoCore splash
screen)
with internal kernel.


#!/bin/bash

/usr/bin/qemu-kvm \
-name "UEFI Testing" \
-enable-kvm \
-cpu kvm64 \
-smp cores=4 \
-boot once=c \
-m 8192 \
-device intel-hda \
-device hda-duplex \
-vga virtio \
-drive if=pflash,format=raw,file=OVMF_CODE_97fdcb.fd,readonly=on \
-drive if=pflash,format=raw,file=my_VARS_97fdcb.fd \
-drive file=disk.img,format=raw,cache=none,index=0,media=disk \
-cdrom
/storage/iso/slackware/slackware64-15.0/slackware64-15.0-20210807.iso
\
-daemonize \
"$@"
There's no definition of a disk device in here.

To now use external kernel, I add the lines:

-kernel /var/cache/vmbuilder/boot/15.0/x86_64/vmlinuz \
-initrd /var/cache/vmbuilder/boot/15.0/x86_64/initrd \
-append "root=/dev/sda2 rootfstype=ext4 ro vga=0x386" \

to the script just after "-boot once=c" (but I doubt the exact
positioning makes any difference).

In this case, I see the kernel running and initrd unpacked and its
modules loaded but the root partition is unable to be mounted - the
disk
is not visible (running 'ls -l /dev/sd*' in recovery shell gives 'ls:
/dev/sd*: No such file or directory').

The last lines of the Qemu screen are:

/boot/initrd-5.13.8.gz: Loading kernel modules from initrd image:
insmod /lib/modules/5.13.8/kernel/fs/jbd2/jbd2.ko
insmod /lib/modules/5.13.8/kernel/fs/mbcache.ko
insmod /lib/modules/5.13.8/kernel/fs/ext4/ext4.ko
mount: mounting /dev/sda2 on /mnt failed: No such file or directory
Which looks like why this failed.

Where's the vmm supposed to get /dev/sda from? It sort of seems like
the CD rom boot script thinks it was mounted as a USB device in this
case.

In the working kernel dmesg Gerd requested, what does it mount as root?
sda? In which case what does the kernel say about where it got sda
from?

James

Join devel@edk2.groups.io to automatically receive all group messages.