(sorry for the late response) On Fri, Oct 29, 2021 at 01:03:32PM -0500, Glenn Washburn wrote: > On Thu, 28 Oct 2021 12:00:09 -0600 > dann frazier <[email protected]> wrote: > > > On Thu, Oct 28, 2021 at 11:19:06AM -0500, Glenn Washburn wrote: > > > On Thu, 28 Oct 2021 07:46:11 -0600 > > > dann frazier <[email protected]> wrote: > > > > On Tue, Oct 26, 2021 at 07:31:38PM -0500, Glenn Washburn wrote: > > > > > Package: ovmf-ia32 > > > > > Version: 2020.11-4 > > > > > > > > > > Hello Maintainers, > > > > > > > > > > I'd like ovmf-ia32 to install a file useable by QEMU's -bios option. > > > > > Currently the package only installs OVMF32_CODE_4M.secboot.fd and > > > > > OVMF32_VARS_4M.fd, but I believe I need a file that combines both code > > > > > and vars. According to the wiki[1], I believe I can use the existing > > > > > files using "-drive if=pflash,..." options, but that is not a great > > > > > option for me. > > > > > > > > Can you elaborate more on your use case? While we do provide such an > > > > image for X64, that is for backwards-compatibility only. > > > > > > I'm working on GRUB2's test suite and it has tests that use QEMU for > > > many of its tests. > > > > edk2's autopkgtest has a testing framework that tests OVMF32, and all > > the other archs, using -pflash. It also does tests with GRUB images > > (e.g. making sure signed versions work w/ SecureBoot enabled, unsigned > > versions do not). Let me know if it'd be useful to collaborate on that > > framework. Here's the main bit: > > > > https://salsa.debian.org/qemu-team/edk2/-/blob/debian/debian/python/UEFI/Qemu.py > > Thanks for the reference, this will be helpful in converting grub tests > to use the pflash instead of -bios option. I'm wondering by the paths > are hard-coded, when it seems that the purpose of the json files in > /usr/share/qemu/firmware is to provide these paths.
That's a good point, parsing the descriptors would be more portable (and also let us test the descriptors). > code assumes a debian system and that the paths won't change much. Yes to both > Using the json files in the grub tests is more problematic because they > are in bash. And yes, I could use jq, but I'm reluctant to add another > dependency. I'm still mulling it over. > > > > Specifically, I need the combined firmware file when testing the > > > i386-efi target. > > > > Why? I mean, why can't that testing use a throw-away pflash image for > > VARS like we do in edk2 autopkgtesting? > > Ok, actually, I can use the pflash. I was wanting to avoid that because > it makes things more complicated. I thought it might be easier to get > the combined file included and that it might be useful to others. I > have now tesed using pflash and it does work. > > The issue is that I'd like to have the tests use paths standardized > across distros. When using -bios, the -L option can be used to add to a > search path to find the firmware file. Of course, this doesn't work if > the filenames of the firmware aren't standardized. For ARM/ARM64, it > looks like debian's path for the code and vars is fairly standard > across distros, and to a lesser extent x86_64, but for i386 it looks > like filenames and where they are on the filesystem vary widely. > > I'm seeing now that a good resolution to my issue may lie at the > conjunction of QEMU, OVMF, and distro packaging. > > > > Perhaps, I don't need a binary with combined code and vars. On the ARM > > > and ARM64 EFI targets, I can pass the AAVMF32_CODE.fd to -bios just > > > fine. So perhaps the IA32 firmware is built in such a way that the code > > > file requires the vars, but could be build to not require it? IOW, why > > > can't I just send the firmware CODE file to QEMU using -bios like I can > > > with ARM and ARM64? > > > > I don't know if or why OVMF*_CODE doesn't work with -bios. Separate > > CODE/VARS is the most flexible build (and what people should use > > in production), so that's what we provide. I'd need to be convinced > > that there's a good reason to increase the size of the ovmf-ia32 deb > > for all users to support -bios mode. > > The best of both worlds would be to get a version of OVMF*_CODE that > works with -bios. According to this (old?) document[1], builds using -D > SECURE_BOOT_ENABLE, which I presume is the case here, must use > pflash. Yes, we do build w/ SECURE_BOOT_ENABLE, so that makes sense. > So perhaps the best of both worlds isn't possible now. Is a build > without secureboot equivalent to the file released in the original bug > report? RELEASEIA32_OVMF.fd? Yeah, that'd be my guess. > Yes the pflash mechanism is more flexible, and thus good to have, but > the -bios option was nice because it was easier to use from a user > perspective. Perhaps, QEMU really needs a -uefi option that's like the > -bios option, which would set everything up based on defaults and > looking through a search path like -bios. (yes, not a Debian issue) > > For my purposes, I don't need a writable vars, which I've tested by > setting readonly to "on" for the vars pflash. So while adding extra > flexibility, it also adds extra complexity (ie another point of > failure). > > I'm not sure what you might need to be convinced, but I notice that > both Arch and Fedora are shipping a 32-bit OVMF with and without > secureboot. My concern is about increasing the size of the package to satisfy a use case that already has an alternative - and TBH - the extra time it takes to test build edk2 w/ yet another image. The ease of using -bios vs. -pflash w/ qemu isn't overly convincing - qemu's syntax is complicated and tools like libvirt can abstract those But I'm not strongly opposed - if it would make testing GRUB on Debian more convenient, that may be a good enough reason to do it. > > > Also, I don't need the secure boot feature of the firmware. The wiki > > > leaves me with the suspicion that I may need to configure some of the > > > firmware variables before I can boot successfully. Perhaps that would > > > only be the case if I were wanting to boot with secure boot enabled. > > > > > > I'm also curious about the 4M in the file name. My guess is that it > > > indicates a build option. Could this be part of the equation? > > > > Please read through the README.Debian file (latest one from > > unstable). If that doesn't answer the above 2 points, let me know so I > > can clarify it there. > > I'm not seeing that in the ovmf-ia32 package (version 2021.08-3). Which > packages should that be in? I should fix that. We're only providing that file in the ovmf package, even though it also describes the images in the ovmf-ia32 package. -dann
