All of lore.kernel.org
 help / color / mirror / Atom feed
From: Glenn Washburn <development@efficientek.com>
To: Gerd Hoffmann <kraxel@redhat.com>
Cc: The development of GNU GRUB <grub-devel@gnu.org>,
	Daniel Kiper <dkiper@net-space.pl>
Subject: Re: [PATCH] grub-shell: Add flexibility in QEMU firmware handling
Date: Mon, 23 Jan 2023 14:09:47 -0600	[thread overview]
Message-ID: <20230123140947.7998a115@crass-HP-ZBook-15-G2> (raw)
In-Reply-To: <20230123092809.sycmpu4iu5hn6b6n@sirius.home.kraxel.org>

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


  reply	other threads:[~2023-01-23 20:10 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-01-21  6:15 [PATCH] grub-shell: Add flexibility in QEMU firmware handling Glenn Washburn
2023-01-23  9:28 ` Gerd Hoffmann
2023-01-23 20:09   ` Glenn Washburn [this message]
2023-01-24  8:16     ` Gerd Hoffmann
2023-01-26  5:23       ` Glenn Washburn
2023-01-24 21:21     ` Robbie Harwood
2023-01-26  4:53       ` Glenn Washburn

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230123140947.7998a115@crass-HP-ZBook-15-G2 \
    --to=development@efficientek.com \
    --cc=dkiper@net-space.pl \
    --cc=grub-devel@gnu.org \
    --cc=kraxel@redhat.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.