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

[Christoph Willing]

On 11/8/21 9:24 am, James Bottomley wrote:
> On Wed, 2021-08-11 at 09:04 +1000, Christoph Willing wrote:
>> On 11/8/21 12:26 am, James Bottomley wrote:
>> [...]
>>> 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?
>>>
>> Yes it mounts /dev/sda2 as root.
>>
>> The boot logs are are now attached at
>> https://bugzilla.tianocore.org/show_bug.cgi?id=3504 as well a diff
>> between good and bad boots (patched & unpatched code). There's
>> nothing obvious (to me) as to why the unpatched code can't find the
>> virtual disk.
>>
>> My simple minded guess is that PlatformBdsConnectSequence() performs
>> some preparatory work that enables the kernel to have access to the
>> vm (therefore to the virtual disk) by the time TryRunningQemuKernel()
>> is called. At the moment however, TryRunningQemuKernel() is called
>> before PlatformBdsConnectSequence() so that preparatory work hasn't
>> been done and the disk can't be found.
> 
> I suspect the problem is that it no longer creates default devices if
> you don't specify them.  If I look at my working version of a command
> line boot, it's this:
> 
> qemu-kvm \
>     -drive if=pflash,format=raw,unit=0,file=/home/jejb/git/edk2/Build/OvmfX64/DEBUG_GCC5/FV/OVMF.fd,readonly \
>     -debugcon file:debug.log -global isa-debugcon.iobase=0x402 \
>     -kernel bzImage \
>     -initrd initrd.img \
>     -append "console=ttyS0 rd.driver.pre=virtio_scsi,9p,9pnet_virtio root=/dev/sda1" \
>     -m 2048 \
>     -serial stdio \
>     -drive if=none,id=sd00,file=debian.img,format=qcow2 \
>     -fsdev local,security_model=passthrough,id=modules,path=/tmp/lib/modules \
>     -fsdev local,security_model=passthrough,id=home,path=/home/jejb \
>     -device virtio-scsi-pci,id=scsi \
>     -device virtio-9p-pci,fsdev=modules,id=sd01,mount_tag=modules \
>     -device virtio-9p-pci,fsdev=home,id=sd02,mount_tag=home \
>     -device scsi-hd,bus=scsi.0,drive=sd00 \
>     -device e1000,netdev=net0 \
>     -netdev user,id=net0,hostfwd=tcp::5555-:22 \
>     -display vnc=:5 \
> 
> 
> #    -chardev socket,id=chrtpm,path=`pwd`/tpmdev/swtpm-sock \
> #    -tpmdev emulator,id=tpm0,chardev=chrtpm \
> #    -device tpm-tis,tpmdev=tpm0 \
> 
> You can ignore all the TPM stuff and my 9p pass throughs for home
> directory and /tmp modules directory (to make it easy to boot any
> kernel I build).  The relevant lines for you are:
> 
>     -drive if=none,id=sd00,file=debian.img,format=qcow2 \
>     -device virtio-scsi-pci,id=scsi \
>     -device scsi-hd,bus=scsi.0,drive=sd00 \
> 
> Which is how I connect /dev/sda to the qcow2 debian image I use to
> boot.  You have the drive line but no device lines giving the driver
> ... if you add device lines can you then get it to boot?
> 
Thanks for the suggestion James,

I amended my script to have:

-drive if=none,id=sd00,file=disk.img,format=raw \
-device virtio-scsi-pci,id=scsi \
-device scsi-hd,bus=scsi.0,drive=sd00 \

but no joy unfortunately.

I also stripped out some other qemu options like -enable-kvm,-cpu,-cores
etc., in case they caused some weird impacts during boot but that also
had no effect.

chris


-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#79068): https://edk2.groups.io/g/devel/message/79068
Mute This Topic: https://groups.io/mt/84767423/1813853
Group Owner: devel+owner at edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [edk2-devel-archive at redhat.com]
-=-=-=-=-=-=-=-=-=-=-=-