[Bug]: EFI snapshot restore loads older NVRAM - VirtualBox 7.1.12

Aperta
  • Qualcosa non va?
#981 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 6 giorni

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
12/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
c
Ambito
operating-systems

Direzione di ricerca

The payload names no source files. Start by reproducing the issue on a VM with several snapshots, using the NVRAM paths the report lists (Snapshots/*.nvram) and the active NVRAM SHA-256 before and after a restore. Then find where snapshot restore copies NVRAM into the active VM file. Done when restoring the newest snapshot leaves the active NVRAM hash equal to that snapshot's NVRAM and Boot0004 is still present.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

bug
Version

7.1.12

Host OS Type

Linux

Host OS name + version

Ubuntu 20.04.5 LTS, x86-64, Intel Xeon E5-2667 v3

Host Architecture

x86

Guest OS Type

macOS

Guest Architecture

x86

Guest OS name + version

macOS Ventura 13.0, x86-64 - Configured guest type:** MacOS1013_64

Component

EFI

What happened?

Related issue: https://github.com/VirtualBox/virtualbox/issues/832
Restoring the newest snapshot of an EFI VM substitutes the active NVRAM with the contents of an unrelated, older snapshot.

This is demonstrated by byte-for-byte SHA-256 comparisons across four successive captures.

The newest snapshot, Ventura Automatic Boot, contains a valid EFI Boot0004 entry pointing to the macOS Ventura APFS Preboot loader. Automatic boot had been tested successfully.

After restoring this snapshot through VirtualBox Manager, Boot0004 disappears from the active NVRAM. The guest attempts the invalid Boot0002 hard-disk entry and fails to boot automatically.

The restored active NVRAM is byte-for-byte identical to the NVRAM belonging to the older Ventrua install stage 2 snapshot, rather than the selected Ventura Automatic Boot snapshot.

The selected snapshot's own NVRAM file remains correct and unchanged, and the .vbox configuration continues to identify the correct current snapshot and its NVRAM path.

Expected behavior

Restoring an EFI snapshot must restore the firmware state associated with that snapshot, including its EFI boot entries and boot order.

It must not load the NVRAM contents belonging to a different snapshot.

Actual behavior

The VM reports the correct current snapshot but has the wrong active NVRAM.

The resulting EFI boot error is:

BdsDxe: failed to load Boot0002 "UEFI VBOX HARDDISK"
Not Found
BdsDxe: No bootable option or device was found.

Querying the missing boot entry returns:

VBoxManage: error: Failed to query the attributes
of variable 'Boot0004': VERR_PATH_NOT_FOUND
How can we reproduce this?

Controlled reproduction

Four checkpoint archives were collected on November 13, 2026, in UTC.

UTC time Operation Active NVRAM SHA-256 prefix Boot0004
17:33:20 VM paused, initial state 1186f3c8 Present
17:39:56 Forced power-off, no saved state 824c20bf Present
17:41:31 Restore newest snapshot 41b59834 Missing
17:42:15 Change NAT to bridged and save 41b59834 Missing

The power-off operation changed the active NVRAM contents but preserved the Ventura boot entry.

The snapshot restoration is the first operation that removed Boot0004.

Changing the network configuration afterward did not change the active NVRAM.

Evidence of incorrect snapshot selection

Selected snapshot:

Name: Ventura Automatic Boot
UUID: d632ed51-1928-48ac-9314-9291a2377803
NVRAM: Snapshots/2026-11-13T07-13-03-052440000Z.nvram

Correct selected-snapshot NVRAM SHA-256:

1186f3c84b087ef166ca2d71c32ad219d0067497035c8c8618b057d232247183

Older snapshot:

Name: Ventrua install stage 2
NVRAM: Snapshots/2026-11-13T03-17-19-308073000Z.nvram

Older-snapshot NVRAM SHA-256:

41b59834c8054c092240267003c3fcbe624dfa81c68d3b452740730d42d228fb

Active NVRAM SHA-256 after restoration:

41b59834c8054c092240267003c3fcbe624dfa81c68d3b452740730d42d228fb

The hashes establish that the active NVRAM after restoration exactly matches the older snapshot.

All five snapshot NVRAM files remained unchanged during the controlled experiment. The .vbox file continued to reference the correct newest snapshot.

Confirmed workaround

With the VM powered off, copying the known-good NVRAM from the newest snapshot back over the active VM NVRAM restores the missing EFI boot entry.

Automatic boot was subsequently verified to work.

This confirms that the installed operating system and VDI were not responsible for the boot failure.

Related bug and investigation requested

Issue #832 reports EFI boot entries disappearing during snapshot creation with VirtualBox 7.2.16 on a Debian/Linux host with a Slackware guest.

This case concerns snapshot restoration with VirtualBox 7.1.12, Ubuntu host, and macOS guest.

The symptoms are similar, but this case demonstrates that an older snapshot's complete NVRAM state is substituted for the selected snapshot's state.

Please investigate how the active NVRAM source is selected or copied when restoring EFI VMs with multiple snapshots.

I can provide all four timestamped evidence archives, containing the active NVRAM, five snapshot NVRAM files, configuration XML, snapshot metadata, timestamps, and SHA-256 hashes.

The behavior has been confirmed on this five-snapshot VM. A fresh single-snapshot reproduction has not yet been tested.

Filename Checkpoint
20261113T173320.tgz Initial working state
20261113T173956.tgz After power-off
20261113T174131.tgz After snapshot restore — failure introduced
20261113T174215.tgz After bridged-adapter configuration

VirtualBox_EFI_NVRAM_Evidence_20261113.zip

Original log VBox.log
Session started November 13, 2026, 17:43:10 UTC
VirtualBox 7.1.12 r169651
NVRAM Active 6 Ventura 13.nvram
Network Bridged through eno1, Intel 82545EM
EFI failure 3.77 seconds after VM startup
Error VMBootFail

What's included
Original log Session opened (UTC) Lines
VBox.log.3 07:23:45 2,636
VBox.log.2 07:25:46 2,624
VBox.log.1 07:51:00 2,941
VBox.log 17:43:10 1,542
Total 9,743

The most important file is VBox.log.1. It covers the long-running VM session, including the pause and eventual power-off at approximately 17:38 UTC.

The final VBox.log captures the failed boot after snapshot restoration and the bridged-network change.
Additional contents

  • README.txt — chronology and explanation of the test.
  • MANIFEST.txt — SHA-256 hashes, file sizes and timestamps.
  • VBox-full-session-chronological.txt — all four logs concatenated chronologically.
  • logs/ — original individual logs, preserved unchanged.
    Important distinction
    The VirtualBox runtime logs do not record every GUI operation performed while the VM is powered off. The snapshot restoration and network-setting transitions are documented by the separate NVRAM/configuration evidence ZIP already uploaded.

VirtualBox_7.1.12_EFI_NVRAM_Full_Test_Session_Logs_20261113.zip

Did you upload all of your necessary log files, screenshots, etc.?
  • Yes, I've uploaded all pertinent files to this issue.
Lingua principale
C
Stelle
1.4k
Fork
219
Nessuna PR unita negli ultimi 30g

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di VirtualBox/virtualbox

Tutte le issue di VirtualBox/virtualbox

Issue simili

Altre issue su C

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.