Re: [PATCH] grub-shell: Add flexibility in QEMU firmware handling

[Glenn Washburn]

On Mon, 23 Jan 2023 10:28:09 +0100
Gerd Hoffmann <kraxel@redhat.com> wrote:

> On Sat, Jan 21, 2023 at 12:15:20AM -0600, Glenn Washburn wrote:
> > The current qemu firmware paths for arm-efi and arm64-efi are not
> > available on Ubuntu/Debian but are hardcoded. Switch to first
> > looking for firmware files in the source directory and if not
> > found, look for them in locations where Debian installs them.
> 
> I'd suggest to inspect the *.json files in /usr/share/qemu/firmware/
> to find distro-installed firmware files.

Yes, I know about this, but decided against it so as not to do real or
hacked up json parsing and add another dependency (eg. jq). I think
right now the unstated GRUB policy is that these tests are only
officially supported to run on (newer) debian systems, so I felt that
hard coding was reasonable. It occurs to me that its possible (though I
suspect very improbable), that Redhat based distros run the tests when
building the official RPM. Is there a reason that redhat would be very
interested in the change you're suggesting?

Since building GRUB already has a dependency on Python, a tiny script
could be used to extract needed info from the json file. But I still
find that kinda ugly cause the grub-shell script is a shell script. I'm
inclined to say this is good enough as is for now, and if anyone
wants to submit a patch to change it I'm open to endorsing it.

> > Do not load the system 32-bit ARM firmware VARS file because it
> > must be writable to prevent a data exception and boot failure. So
> > in order to use the VARS file, it must be copied to a writable
> > location, but its quite large at 64M and is not needed to boot
> > successfully.
> 
> You can load the VARS file with snapshot=on (and drop readonly=on) to
> make things work without copying the file.

Good to know. Do you know of any benefit to doing this (ie. using the
installed VARS file)?

Thanks for the feedback,
Glenn