[PATCH v2 0/2] sandbox: add bootmethod EFI boot-manager
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. * Reduce the noisyness of the EFI sub-system if not ESP is available.
v2: Reduce the number of messages if there is no ESP to persist variables.
Heinrich Schuchardt (2): efi_loader: reduce noisiness if ESP is missing sandbox: add bootmethod EFI boot-manager
arch/sandbox/dts/test.dts | 4 ++++ lib/efi_loader/efi_var_file.c | 22 ++++++++++++++-------- test/boot/bootmeth.c | 28 +++++++++++++++++----------- 3 files changed, 35 insertions(+), 19 deletions(-)
EFI variables can be stored in a file on the EFI system partition. If that partition is missing we are writing two error messages per variable. This is too noisy.
Just warn once about the missing ESP.
Signed-off-by: Heinrich Schuchardt heinrich.schuchardt@canonical.com --- v2: new patch --- lib/efi_loader/efi_var_file.c | 22 ++++++++++++++-------- 1 file changed, 14 insertions(+), 8 deletions(-)
diff --git a/lib/efi_loader/efi_var_file.c b/lib/efi_loader/efi_var_file.c index 413e1794e88..ba0bf33ffbd 100644 --- a/lib/efi_loader/efi_var_file.c +++ b/lib/efi_loader/efi_var_file.c @@ -37,18 +37,16 @@ static efi_status_t __maybe_unused efi_set_blk_dev_to_system_partition(void) char part_str[PART_STR_LEN]; int r;
- if (efi_system_partition.uclass_id == UCLASS_INVALID) { - log_err("No EFI system partition\n"); + if (efi_system_partition.uclass_id == UCLASS_INVALID) return EFI_DEVICE_ERROR; - } + snprintf(part_str, PART_STR_LEN, "%x:%x", efi_system_partition.devnum, efi_system_partition.part); r = fs_set_blk_dev(blk_get_uclass_name(efi_system_partition.uclass_id), part_str, FS_TYPE_ANY); - if (r) { - log_err("Cannot read EFI system partition\n"); + if (r) return EFI_DEVICE_ERROR; - } + return EFI_SUCCESS; }
@@ -67,14 +65,21 @@ efi_status_t efi_var_to_file(void) loff_t len; loff_t actlen; int r; + static bool once;
ret = efi_var_collect(&buf, &len, EFI_VARIABLE_NON_VOLATILE); if (ret != EFI_SUCCESS) goto error;
ret = efi_set_blk_dev_to_system_partition(); - if (ret != EFI_SUCCESS) - goto error; + if (ret != EFI_SUCCESS) { + if (!once) { + log_warning("Cannot persist EFI variables without system partition\n"); + once = true; + } + goto out; + } + once = false;
r = fs_write(EFI_VAR_FILE_NAME, map_to_sysmem(buf), 0, len, &actlen); if (r || len != actlen) @@ -83,6 +88,7 @@ efi_status_t efi_var_to_file(void) error: if (ret != EFI_SUCCESS) log_err("Failed to persist EFI variables\n"); +out: free(buf); return ret; #else
On Fri, 18 Oct 2024 at 04:18, Heinrich Schuchardt heinrich.schuchardt@canonical.com wrote:
EFI variables can be stored in a file on the EFI system partition. If that partition is missing we are writing two error messages per variable. This is too noisy.
Just warn once about the missing ESP.
Signed-off-by: Heinrich Schuchardt heinrich.schuchardt@canonical.com
v2: new patch
lib/efi_loader/efi_var_file.c | 22 ++++++++++++++-------- 1 file changed, 14 insertions(+), 8 deletions(-)
diff --git a/lib/efi_loader/efi_var_file.c b/lib/efi_loader/efi_var_file.c index 413e1794e88..ba0bf33ffbd 100644 --- a/lib/efi_loader/efi_var_file.c +++ b/lib/efi_loader/efi_var_file.c @@ -37,18 +37,16 @@ static efi_status_t __maybe_unused efi_set_blk_dev_to_system_partition(void) char part_str[PART_STR_LEN]; int r;
if (efi_system_partition.uclass_id == UCLASS_INVALID) {log_err("No EFI system partition\n");
if (efi_system_partition.uclass_id == UCLASS_INVALID) return EFI_DEVICE_ERROR;
}
snprintf(part_str, PART_STR_LEN, "%x:%x", efi_system_partition.devnum, efi_system_partition.part); r = fs_set_blk_dev(blk_get_uclass_name(efi_system_partition.uclass_id), part_str, FS_TYPE_ANY);
if (r) {log_err("Cannot read EFI system partition\n");
if (r) return EFI_DEVICE_ERROR;
}
return EFI_SUCCESS;}
@@ -67,14 +65,21 @@ efi_status_t efi_var_to_file(void) loff_t len; loff_t actlen; int r;
static bool once; ret = efi_var_collect(&buf, &len, EFI_VARIABLE_NON_VOLATILE); if (ret != EFI_SUCCESS) goto error; ret = efi_set_blk_dev_to_system_partition();
if (ret != EFI_SUCCESS)goto error;
if (ret != EFI_SUCCESS) {if (!once) {log_warning("Cannot persist EFI variables without system partition\n");once = true;}goto out;}once = false; r = fs_write(EFI_VAR_FILE_NAME, map_to_sysmem(buf), 0, len, &actlen); if (r || len != actlen)@@ -83,6 +88,7 @@ efi_status_t efi_var_to_file(void) error: if (ret != EFI_SUCCESS) log_err("Failed to persist EFI variables\n"); +out: free(buf); return ret;
#else
2.45.2
Reviewed-by: Ilias Apalodimas ilias.apalodimas@linaro.org
On Fri, 18 Oct 2024 at 07:43, Ilias Apalodimas ilias.apalodimas@linaro.org wrote:
On Fri, 18 Oct 2024 at 04:18, Heinrich Schuchardt heinrich.schuchardt@canonical.com wrote:
EFI variables can be stored in a file on the EFI system partition. If that partition is missing we are writing two error messages per variable. This is too noisy.
Just warn once about the missing ESP.
Signed-off-by: Heinrich Schuchardt heinrich.schuchardt@canonical.com
v2: new patch
lib/efi_loader/efi_var_file.c | 22 ++++++++++++++-------- 1 file changed, 14 insertions(+), 8 deletions(-)
Reviewed-by: Simon Glass sjg@chromium.org
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(-)
diff --git a/arch/sandbox/dts/test.dts b/arch/sandbox/dts/test.dts index 9bf44ae3b0b..05388e73e7c 100644 --- a/arch/sandbox/dts/test.dts +++ b/arch/sandbox/dts/test.dts @@ -124,6 +124,10 @@ compatible = "u-boot,distro-efi"; };
+ efimgr { + compatible = "u-boot,efi-bootmgr"; + }; + theme { font-size = <30>; menu-inset = <3>; diff --git a/test/boot/bootmeth.c b/test/boot/bootmeth.c index 18ae6d7fe13..0beb57d5304 100644 --- a/test/boot/bootmeth.c +++ b/test/boot/bootmeth.c @@ -21,11 +21,13 @@ static int bootmeth_cmd_list(struct unit_test_state *uts) ut_assert_nextlinen("---"); ut_assert_nextline(" 0 0 extlinux Extlinux boot from a block device"); ut_assert_nextline(" 1 1 efi EFI boot from an .efi file"); - if (IS_ENABLED(CONFIG_BOOTMETH_GLOBAL)) - ut_assert_nextline(" glob 2 firmware0 VBE simple"); + if (IS_ENABLED(CONFIG_BOOTMETH_GLOBAL)) { + ut_assert_nextline(" glob 2 efimgr EFI bootmgr flow"); + ut_assert_nextline(" glob 3 firmware0 VBE simple"); + } ut_assert_nextlinen("---"); ut_assert_nextline(IS_ENABLED(CONFIG_BOOTMETH_GLOBAL) ? - "(3 bootmeths)" : "(2 bootmeths)"); + "(4 bootmeths)" : "(2 bootmeths)"); ut_assert_console_end();
return 0; @@ -56,11 +58,13 @@ static int bootmeth_cmd_order(struct unit_test_state *uts) ut_assert_nextlinen("---"); ut_assert_nextline(" 0 0 extlinux Extlinux boot from a block device"); ut_assert_nextline(" - 1 efi EFI boot from an .efi file"); - if (IS_ENABLED(CONFIG_BOOTMETH_GLOBAL)) - ut_assert_nextline(" glob 2 firmware0 VBE simple"); + if (IS_ENABLED(CONFIG_BOOTMETH_GLOBAL)) { + ut_assert_nextline(" glob 2 efimgr EFI bootmgr flow"); + ut_assert_nextline(" glob 3 firmware0 VBE simple"); + } ut_assert_nextlinen("---"); ut_assert_nextline(IS_ENABLED(CONFIG_BOOTMETH_GLOBAL) ? - "(3 bootmeths)" : "(2 bootmeths)"); + "(4 bootmeths)" : "(2 bootmeths)"); ut_assert_console_end();
/* Check the -a flag with the reverse order */ @@ -71,11 +75,13 @@ static int bootmeth_cmd_order(struct unit_test_state *uts) ut_assert_nextlinen("---"); ut_assert_nextline(" 1 0 extlinux Extlinux boot from a block device"); ut_assert_nextline(" 0 1 efi EFI boot from an .efi file"); - if (IS_ENABLED(CONFIG_BOOTMETH_GLOBAL)) - ut_assert_nextline(" glob 2 firmware0 VBE simple"); + if (IS_ENABLED(CONFIG_BOOTMETH_GLOBAL)) { + ut_assert_nextline(" glob 2 efimgr EFI bootmgr flow"); + ut_assert_nextline(" glob 3 firmware0 VBE simple"); + } ut_assert_nextlinen("---"); ut_assert_nextline(IS_ENABLED(CONFIG_BOOTMETH_GLOBAL) ? - "(3 bootmeths)" : "(2 bootmeths)"); + "(4 bootmeths)" : "(2 bootmeths)"); ut_assert_console_end();
/* Now reset the order to empty, which should show all of them again */ @@ -84,7 +90,7 @@ static int bootmeth_cmd_order(struct unit_test_state *uts) ut_assertnull(env_get("bootmeths")); ut_assertok(run_command("bootmeth list", 0)); ut_assert_skip_to_line(IS_ENABLED(CONFIG_BOOTMETH_GLOBAL) ? - "(3 bootmeths)" : "(2 bootmeths)"); + "(4 bootmeths)" : "(2 bootmeths)");
/* Try reverse order */ ut_assertok(run_command("bootmeth order "efi extlinux"", 0)); @@ -116,7 +122,7 @@ static int bootmeth_cmd_order_glob(struct unit_test_state *uts) ut_assert_nextline("Order Seq Name Description"); ut_assert_nextlinen("---"); ut_assert_nextline(" 0 1 efi EFI boot from an .efi file"); - ut_assert_nextline(" glob 2 firmware0 VBE simple"); + ut_assert_nextline(" glob 3 firmware0 VBE simple"); ut_assert_nextlinen("---"); ut_assert_nextline("(2 bootmeths)"); ut_assertnonnull(env_get("bootmeths"));
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.
Regards, Simon
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.
I expect the sandbox to behave as any other board and provide warnings when they are adequate.
Best regards
Heinrich
Hi Heinrich,
On Fri, 18 Oct 2024 at 11:26, Heinrich Schuchardt heinrich.schuchardt@canonical.com wrote:
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.
I expect the sandbox to behave as any other board and provide warnings when they are adequate.
Well, what I am supposed to do to fix this warning? I just don't want unactionable messages coming up in bootstd.
If it happens all the time and cannot be fixed, you could add an option to the driver to ignore it, which can be controlled from the devicetree node.
Regards, Simon
On Fri, Oct 18, 2024 at 02:17:36PM -0600, Simon Glass wrote:
Hi Heinrich,
On Fri, 18 Oct 2024 at 11:26, Heinrich Schuchardt heinrich.schuchardt@canonical.com wrote:
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.
I expect the sandbox to behave as any other board and provide warnings when they are adequate.
Well, what I am supposed to do to fix this warning? I just don't want unactionable messages coming up in bootstd.
If it happens all the time and cannot be fixed, you could add an option to the driver to ignore it, which can be controlled from the devicetree node.
So, you're scanning a disk image to boot from, and it lacks a system partition. Can you describe how you're creating this disk image? And are you testing something EFI related, or not? And then Heinrich, can we be checking for variables any later than we do today?
On 10/18/24 22:36, Tom Rini wrote:
On Fri, Oct 18, 2024 at 02:17:36PM -0600, Simon Glass wrote:
Hi Heinrich,
On Fri, 18 Oct 2024 at 11:26, Heinrich Schuchardt heinrich.schuchardt@canonical.com wrote:
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.
I expect the sandbox to behave as any other board and provide warnings when they are adequate.
Well, what I am supposed to do to fix this warning? I just don't want unactionable messages coming up in bootstd.
The user runs a system that tries to boot via EFI. He does not have an block device with an ESP. For sure that is an actionable warning:
The user should insert properly formatted media.
And your test should put an ESP on the image.
If it happens all the time and cannot be fixed, you could add an option to the driver to ignore it, which can be controlled from the devicetree node.
As said it can be easily fixed. Create an ESP on one of the block devices.
Do you really expect a user to change the device-tree to suppress a warning?
Wouldn't it be more plausible to remove the EFI boot method from the bootflow instead if that device is never to be booted via EFI?
So, you're scanning a disk image to boot from, and it lacks a system partition. Can you describe how you're creating this disk image? And are you testing something EFI related, or not? And then Heinrich, can we be checking for variables any later than we do today?
The EFI specification requires us to create non-volatile BOOT#### variables for each block device. Without an ESP we cannot persist these. We are already at the latest possible moment when we reach the boot manager.
Best regards
Heinrich
On Fri, Oct 18, 2024 at 10:49:16PM +0200, Heinrich Schuchardt wrote:
On 10/18/24 22:36, Tom Rini wrote:
On Fri, Oct 18, 2024 at 02:17:36PM -0600, Simon Glass wrote:
Hi Heinrich,
On Fri, 18 Oct 2024 at 11:26, Heinrich Schuchardt heinrich.schuchardt@canonical.com wrote:
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.
I expect the sandbox to behave as any other board and provide warnings when they are adequate.
Well, what I am supposed to do to fix this warning? I just don't want unactionable messages coming up in bootstd.
The user runs a system that tries to boot via EFI. He does not have an block device with an ESP. For sure that is an actionable warning:
The user should insert properly formatted media.
And your test should put an ESP on the image.
If it happens all the time and cannot be fixed, you could add an option to the driver to ignore it, which can be controlled from the devicetree node.
As said it can be easily fixed. Create an ESP on one of the block devices.
Do you really expect a user to change the device-tree to suppress a warning?
Wouldn't it be more plausible to remove the EFI boot method from the bootflow instead if that device is never to be booted via EFI?
Assuming that Simon is trying to test an image that won't be used with EFI, but we check EFI first, is there a call we can do to check for validity and if fails, move on?
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.
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...
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
participants (5)
-
Heinrich Schuchardt -
Ilias Apalodimas -
Mark Kettenis -
Simon Glass -
Tom Rini