public inbox for devel@edk2.groups.io
 help / color / mirror / Atom feed
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 --]

       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