On 10/19/24 01:01, Mark Kettenis wrote:
Date: Fri, 18 Oct 2024 19:26:01 +0200 From: Heinrich Schuchardt heinrich.schuchardt@canonical.com
Hi Heinrich,
On 10/18/24 19:21, Simon Glass wrote:
Hi Heinrich,
On Thu, 17 Oct 2024 at 19:18, Heinrich Schuchardt heinrich.schuchardt@canonical.com wrote:
The EFI boot-manager is the default method to boot EFI binaries. We should be able to use it on the Sandbox.
- Enable EFI boot-manager bootmethod on the sandbox.
- Adjust unit tests to reflect the additional boot method.
Signed-off-by: Heinrich Schuchardt heinrich.schuchardt@canonical.com Reviewed-by: Simon Glass sjg@chromium.org Reviewed-by: Mattijs Korpershoek mkorpershoek@baylibre.com
v2: no changes
arch/sandbox/dts/test.dts | 4 ++++ test/boot/bootmeth.c | 28 +++++++++++++++++----------- 2 files changed, 21 insertions(+), 11 deletions(-)
This is better, but I still see this.
=> bootflow scan efi_var_to_file() Cannot persist EFI variables without system partition
Please find a way to get rid of it. I can give some suggestions if you like.
Would you, please, mind providing a rationale why you want this correct message not to be written.
To me, warning about persisting EFI variables only makes sense if you're actually trying to persist an EFI variable. But all we're doing here is scanning for possible bootflows.
The UEFI specification requires to create Boot#### variables which are non-volatile.
As the variables have to be non-volatile we try to persist them in a file. And the message describes that this fails.
I expect the sandbox to behave as any other board and provide warnings when they are adequate.
The warning doesn't make sense to me on non-sandbox boards either.
I suspect this is the code that autogenerates EFI Boot options, so code that sets Boot#### EFI variables. But do we really care that we can't make those persistent? The code will just regenerate them upon the next boot...
The same warning is written for any variable that cannot be persisted, e.g. for the Boot#### variables that you create manually.
Persisting auto-generated Boot#### makes sense as you may refer to these in the BootOrder or BootNext variables.
Best regards
Heinrich