On Thu, 28 Oct 2021 12:00:09 -0600 dann frazier <da...@dannf.org> 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 <da...@dannf.org> 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. I'm guessing this code assumes a debian system and that the paths won't change much. 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. 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? 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. > > 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? Glenn [1] https://www.virtualbox.org/svn/vbox/trunk/src/VBox/Devices/EFI/Firmware/OvmfPkg/README
