On 9/7/23 22:24, Het Gala wrote: > > > > -------- 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.g...@nutanix.com> > To: disc...@edk2.groups.io > CC: Kallol Biswas [C] <kallol.bis...@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 ?
There are too many disparate things going on in your setup: - controlling the boot order from within the guest as opposed to via fw_cfg - using pflash vs. not using pflash - building with SMM_REQUIRE or not. Short suggestion: - always use pflash; if you see an NvVars file, your setup is broken (we can safely say this in 2023). In fact use *two* pflash chips, one for code, one for varstore. - if your QEMU command line includes the "bootorder" property for any device, then OVMF BDS will filter and reorder the UEFI boot options, most likely overriding or otherwise masking your earlier in-guest settings. This is intentional. - SMM_REQUIRE or not is not relevant for the Boot#### and BootOrder variables. Please provide your QEMU and edk2 versions, your edk2 build command, and the QEMU command line. Laszlo > > > --------------------------------------------------------------------------------------------------------------------------------------------------- > > (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 11019 Jun 9 15: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 11019 Jun 12 06: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 (#108419): https://edk2.groups.io/g/devel/message/108419 Mute This Topic: https://groups.io/mt/101223763/21656 Group Owner: devel+ow...@edk2.groups.io Unsubscribe: https://edk2.groups.io/g/devel/leave/9847357/21656/1706620634/xyzzy [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
