On Tue, 24 Jan 2023 09:16:26 +0100 Gerd Hoffmann <kra...@redhat.com> wrote:
> Hi, > > > > > 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)? > > Well, the firmware expects it can write to VARS flash. ovmf has for > historical reasons code to cope with non-flash or readonly VARS (so > -bios works), but armvirt has not. Which is why you see the failures. Well armvirt seems to cope fine if there's no VARS flash provided, it just dies when there is one provided which is readonly. > snapshot=on allows the guest write to a in-RAM throwaway snapshot, > which is the same as using a writable temporary copy of the vars > file, but without the need for a temporary file. Yeah, I get that, but armvirt doesn't even need the VARS file to run. You'll see in this patch that for 32-bit arm, no VARS flash is created when loading the firmware code from the system path or when loading the firmware code from the grub source directory and the VARS file doesn't exist. So what benefit is there to providing the system VARS as a flash device? I can't think of a benefit to using the VARS file if the tests all pass fine without it. I'd prefer to have as few dependencies on files not in the GRUB source as possible. So I like that I don't need to use the system VARS file on 32-bit arm. I wish I could do the same on the other platforms. This patch does no temporary copying of VARS files on any platform and all the QEMU tests run as expected. So using "snapshot=on" won't prevent any copying, which is the main benefit that I see. I do appreciate this suggestion as it might be useful in other work with QEMU, I just don't see how its beneficial here. Glenn _______________________________________________ Grub-devel mailing list Grub-devel@gnu.org https://lists.gnu.org/mailman/listinfo/grub-devel
