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

["Christoph Willing" <chris.willing@linux.com>]

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 \
"$@"


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
ERROR: No /sbin/init found on rootdev (or not mounted). Trouble ahead.
       You can try to fix it. Type 'exit' when things are done.

At that point I'm dropped into a recovery shell to try fixing something
but there's nothing that can be done since the disk containing the OS is
not visible.


However if I now change the script's OVMF files to those built from a
patched git master, the VM boots all the way to login prompt.

I'm using qemu-6.0.0 on SLackware64 but I've found exactly the same
behaviour using other OS's (Ubuntu 20.04 with 4.2-3ubuntu6.17 and Clear
Linux with 5.2.0)

I've also tried using OVMF files from Ubuntu hirsute's ovmf package
(2020.11-4) with same bad result. Of course, in this case, I was unable
to use a patched version.

>From the above, I think I've done everything possible to verify the
problem and a possible fix. Is there something fundamentally wrong in
the way I'm going about this?

chris