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

["James Bottomley" <James.Bottomley@HansenPartnership.com>]

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