From: "Het Gala" <het.gala@nutanix.com>
To: devel@edk2.groups.io
Cc: lersek@redhat.com, "Kallol Biswas [C]" <kallol.biswas@nutanix.com>
Subject: [edk2-discuss][edk2-devel] UEFI variables not getting stored in nvram disk
Date: Fri, 8 Sep 2023 01:54:01 +0530 [thread overview]
Message-ID: <5e081f07-8049-cf42-86ab-49c204c4e9ea@nutanix.com> (raw)
In-Reply-To: <3e129930-93a2-01e9-f7a3-f76d19fbe53c@nutanix.com>
[-- Attachment #1.1: Type: text/plain, Size: 7382 bytes --]
-------- Forwarded Message --------
Subject: [edk2-discuss] UEFI variables not getting stored in nvram disk
Date: Mon, 17 Jul 2023 23:24:45 +0530
From: Het Gala <het.gala@nutanix.com>
To: discuss@edk2.groups.io
CC: Kallol Biswas [C] <kallol.biswas@nutanix.com>
Hi edk2 community,
We have a scenario - testcase1, with uefi enabled VM having an Empty
CDROM. PxE boot, EFI internal Shell (already mentioned by default by
UEFI) and CDROM are the boot options. We also have a pflash / nvram disk
by default attached if it is an uefi enabled VM. So, we have a nvram
disk attached to the system.
In testcase1, (opened the UEFI Boot Manager --> changed Boot Order -->
saved Boot Order --> continue --> Guest reboot followed by power cycle
--> again open UEFI Boot Manager) changed Boot Order is not persisted
and falls back to the default Boot Order. Same observation is seen for
other uefi variables (ex. autoboot timeout / Next Boot / Display
resolution changes) too. None of the modified / changed uefi variables
are persisted after guest reboot followed by power cycle.
On the other hand, when we have a similar scenario testcase2, but
instead of an empty CDROM, we have a vdisk (~ 10G) with an guest OS
image (~ 1.7G) mounted on that disk. We observed that, the modified uefi
variables (ex. change in Boot order / change in display resolution) are
persisted after modifying uefi variable value followed by guest reboot
and power cycle. The modified variables are stored inside NvVars file (~
200 MB). This file is inside efi/boot partition, which is made on the
same vdisk where guest OS image is also mounted, because the vdisk is
having space left.
IIUC, if SMM driver enabled while building OVMF binary, and have an
external pflash drive to save the uefi variables (nvram disk), the
modified uefi variables are stored inside the nvram disk, otherwise in
absence of SMM driver stack, the NvVars file gets mounted on the OS disk
if enough space is available.
In testcase2, SMM driver option (-D SMM_REQUIRE) is present in the OVMF
binary file, and also has external nvram disk attached to the VM, even
then the uefi variables are stored on the vdisk instead of nvram disk.
Question is : How can we make Boot Order (and other modified uefi
variables) persistent when a OS vdisk is not mounted to the uefi enabled
VM ?
---------------------------------------------------------------------------------------------------------------------------------------------------
(Attaching references for testcase1 and testcase2 below)
For testcase1 : attaching some debug statements here of the default Boot
order (1.a), the changed boot order (1.b), and the boot order followed
by guest reboot and power cycle (1.c).
(1.a) Here it shows the default initial Boot order
[Bds]OsIndication: 0000000000000000^M
[Bds]=============Begin Load Options Dumping ...=============^M
Driver Options:^M
SysPrep Options:^M
Boot Options:^M
Boot0000: UiApp 0x0109^M
Boot0001: UEFI QEMU DVD-ROM QM00005 0x0001^M
Boot0002: UEFI PXEv4 (MAC:506B8D83F4DB) 0x0001^M
Boot0003: EFI Internal Shell 0x0001^M
PlatformRecovery Options:^M
PlatformRecovery0000: Default PlatformRecovery 0x0001^M
[Bds]=============End Load Options Dumping=============^M
[Bds]BdsWait ...Zzzzzzzzzzzz...^M
[Bds]Exit the waiting!^M
ValidateSetVariable - Variable
(8BE4DF61-93CA-11D2-AA0D-00E098032B8C:BootCurrent) returning Success.^M
(1.b) Changed the order from 1->2->3 to 1->3->2 from the UEFI Boot
Manager Menu. To verify whether the Boot order has actually changed or
not after saving the Boot order from uefi GUI, added some debug
statments after
https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Library/BootMaintenanceManagerUiLib/Variable.c#L614
<https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Library/BootMaintenanceManagerUiLib/Variable.c#L614>.
DEBUG((EFI_D_INFO, "Printing the boot Order here.\n"));
for (Index = 0; Index < BootOrderSize / sizeof (UINT16); Index++) {
DEBUG ((
EFI_D_INFO, " BootOption %u: %04x\n",
Index,
BootOrder[Index]
));
}
And the log files printed the changed Boot order, below and that
confirmed that the modified Boot Order has been set
https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Library/BootMaintenanceManagerUiLib/Variable.c#L624
<https://github.com/tianocore/edk2/blob/master/MdeModulePkg/Library/BootMaintenanceManagerUiLib/Variable.c#L624>.
Printing the boot Order here.^M
BootOption 0: 0001^M
BootOption 1: 0003^M
BootOption 2: 0002^M
BootOption 3: 0000^M
(1.c) On Guest reboot followed by power cycle, on reopening the UEFI
Boot Maintainance Manager GUI, found the Boot Order to fall back to the
default order. (Attaching a screenshot of the Boot Order as attachment).
-------------------------------------------------------------------------------------------------------------------------------------------------------
For testcase2 : attaching the partition made by efi/boot on the guest,
with a proof that the modified uefi variables are stored in the NvVars file.
(2.a) On the Guest OS, /boot/efi made a partition of 200MB
[root@localhost <mailto:root@localhost>~]$ lsblk -l
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 12G 0 disk
sda1 8:1 0 200M 0 part /boot/efi
sda2 8:2 0 1G 0 part /boot
sda3 8:3 0 10.8G 0 part
cl-root 253:0 0 9.6G 0 lvm /
cl-swap 253:1 0 1.2G 0 lvm [SWAP]
sr0 11:0 1 1024M 0 rom
(2.b) Inside the /boot/efi partition, there is the NvVars file. After
this, the uefi variables were modified / changed.
[root@localhost <mailto:root@localhost>~]$ ls -al /boot/efi
total 36
drwx------. 3 root root 16384 Dec 31 1969 .
dr-xr-xr-x. 5 root root 4096 Oct 23 2019 ..
drwx------. 4 root root 4096 Oct 23 2019 EFI
-rwx------. 1 root root 11019Jun 915:51 NvVars
(2.c) After guest reboot followed by power cycle, the change in uefi
variables was persistent. And to verify, where the modified variables
were stored, we could see the date change in the NvVars file ->
signifying the latest change in UEFI boot manager menu.
[root@localhost <mailto:root@localhost>~]$ ls -la /boot/efi
total 36
drwx------. 3 root root 16384 Dec 31 1969 .
dr-xr-xr-x. 5 root root 4096 Oct 23 2019 ..
drwx------. 4 root root 4096 Oct 23 2019 EFI
-rwx------. 1 root root 11019Jun 1206:56 NvVars
[root@localhost <mailto:root@localhost>~]$ date
Mon Jun 12 06:58:13 EDT 2023
Thanks,
Het Gala
-=-=-=-=-=-=-=-=-=-=-=-
Groups.io Links: You receive all messages sent to this group.
View/Reply Online (#108417): https://edk2.groups.io/g/devel/message/108417
Mute This Topic: https://groups.io/mt/101223763/7686176
Group Owner: devel+owner@edk2.groups.io
Unsubscribe: https://edk2.groups.io/g/devel/unsub [rebecca@openfw.io]
-=-=-=-=-=-=-=-=-=-=-=-
[-- Attachment #1.2: Type: text/html, Size: 63499 bytes --]
[-- Attachment #2: Screenshot 2023-07-13 at 2.23.49 AM.png --]
[-- Type: image/png, Size: 67282 bytes --]
next parent reply other threads:[~2023-09-07 20:25 UTC|newest]
Thread overview: 2+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <3e129930-93a2-01e9-f7a3-f76d19fbe53c@nutanix.com>
2023-09-07 20:24 ` Het Gala [this message]
2023-09-07 21:23 ` [edk2-discuss][edk2-devel] UEFI variables not getting stored in nvram disk Laszlo Ersek
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-list 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=5e081f07-8049-cf42-86ab-49c204c4e9ea@nutanix.com \
--to=devel@edk2.groups.io \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox