Titel: KVM/EDK-II-VM: UEFI efivarfs/NVRAM wird mit jedem Reboot voller, obwohl sichtbare EFI-Variablen praktisch unverändert bleiben
Ich habe ein ungewöhnliches Problem mit dem UEFI-NVRAM einer virtuellen Debian-Maschine (efivarfs wird mit jedem Reboot weiter voller und ist schon fast bei 90%) und suche Hinweise, wie sich die Ursache weiter eingrenzen bzw. der Varstore sicher bereinigen lässt.
Die betroffene Umgebung ist ein (netcup-)Root-Server (RS 2000 G12 Pro) mit Standort VIE, daneben habe ich eine praktisch identische Instanz auf einem virtuellen Server (VPS 2000 G11) mit Standort NUE laufen, bei der das Problem nicht auftritt.
Umgebung
- Virtueller Server / KVM
- Debian 13
- Kernel: 6.12.100+deb13-amd64
- UEFI-Boot
- Firmware laut Kernel:
efi: EFI v2.7 by Ubuntu distribution of EDK II
- VirtIO-Systemdisk
- EFI-Systempartition: /dev/vda1, VFAT, gemountet auf /boot/efi
- Boot erfolgt über:
Boot0008* debian ... File(\EFI\debian\shimx64.efi)
- GRUB 2.12 / shim 16.1
- Secure Boot wird von der VM nicht unterstützt (mokutil: This system doesn't support Secure Boot)
Problem
efivarfs wird mit jedem Reboot weiter voller.
Anfangs z.B.:
efivarfs 256K 188K 64K 75%
Nach einigen weiteren Reboots inzwischen:
Dateisystem 1B-Blöcke Benutzt Verfügbar Verw%efivarfs 262044 227164 29760 89%
statfs liefert aktuell:
Blockgröße=1 Gesamt=262044 Frei=34880 Verfügbar=29760
Die Belegung steigt reproduzierbar nach Reboots. Ein vollständiges Poweroff statt Reboot hat daran nichts geändert.
Während das Debian-System läuft, bleibt der Wert dagegen stabil. Ich habe ihn über ca. 8 Stunden beobachtet:
frei=34880 verfügbar=29760
ohne jegliche Veränderung.
Vergleich mit zweiter ähnlicher VM
Ich habe eine zweite, sehr ähnlich konfigurierte VM beim gleichen Provider.
Dort liegt efivarfs nur bei ca. 36 % Belegung.
Verglichen wurden auf beiden Maschinen:
- Anzahl der sichtbaren EFI-Variablen
- Namen
- Attribute
- Dateigrößen
- SHA256 der Variableninhalte
Anzahl/Namen/Größen sind gleich. Die Inhaltsunterschiede betreffen im Wesentlichen erwartbare VM-spezifische Werte wie:
- PXE-/HTTP-Bootoptionen mit MAC-/Device-Informationen
- Debian-Bootoption bzw. GPT-UUID
- LoaderDevicePartUUID
- MTC
Die großen MokListRT/MokListXRT sind auf beiden Maschinen identisch und haben nur BootService + Runtime (0x06), also kein NON_VOLATILE.
Die tatsächlich sichtbaren persistenten (0x07 = NV+BS+RT) Variablen enthalten insgesamt nur sehr wenig Nutzdaten und erklären die ca. 227 KB gemeldete Belegung bei weitem nicht.
Auffällige EDK-II-Variablen
VarErrorFlag ist vorhanden und hat:
0xff
also bislang keinen von EDK II registrierten Variable-Store-Fehler.
MTC (Monotonic Counter) ist eine persistente NV+BS+RT-Variable:
betroffene VM: MTC = 30gesunde VM: MTC = 44
Die Vergleichs-VM (vServer, G11, NUE) hat also trotz höherem Monotonic Counter deutlich weniger NVRAM-Belegung.
pstore untersucht
efi_pstore ist zwar registriert:
pstore: Registered efi_pstore as persistent store backend
aber:
efi_pstore.pstore_disable = Nprintk.always_kmsg_dump = Ncrash_kexec_post_notifiers = N
Außerdem sind sowohl
/sys/fs/pstore/var/lib/systemd/pstore
leer.
Bei allen untersuchten Boots wurde systemd-pstore.service übersprungen:
ConditionDirectoryNotEmpty=/sys/fs/pstore
Es gibt also keinen Hinweis darauf, dass bei normalen Reboots pstore-Dumps geschrieben und anschließend wieder gelöscht werden.
Weitere Versuche
- vollständiges Poweroff und erneuter Start: keine Bereinigung
- die von netcup im SCP angebotene „Speicheroptimierung“ der VM durchgeführt: keine Änderung
- keine EFI-Variablen manuell gelöscht
- keine MOK-/GRUB-/Boot-Einträge verändert
- netcup-Support kontaktiert; laut dessen Rückmeldung liege das Problem nicht am Hypervisor
Ich vermeide derzeit weitere Reboots, da nur noch etwa 30 KB für EFI-Variablen verfügbar sind.
Meine aktuelle Vermutung
Mir ist bewusst, dass df bei efivarfs nicht einfach die sichtbaren Dateien aufsummiert, sondern die von UEFI QueryVariableInfo() gemeldeten Werte verwendet.
Daher vermute ich derzeit entweder:
- alte/obsolete Variable Records im persistenten EDK-II/OVMF-Varstore, die nicht reclaimed werden,
- Boot-Service-only-Variablen, die während der UEFI-Bootphase existieren, nach ExitBootServices() für Linux aber nicht mehr sichtbar sind,
- ungewöhnlich viele Schreibvorgänge während der EDK-II-/Bootmanager-Phase,
- oder einen beschädigten bzw. nicht korrekt garbage-collected persistenten UEFI-Varstore.
Interessant ist dabei, dass EDK II grundsätzlich einen Reclaim-Mechanismus für den Variable Store besitzt. Bei einem inzwischen so vollen Store hätte ich daher erwartet, dass alte Records irgendwann zurückgewonnen werden.
Fragen
Hat jemand dieses Verhalten bei OVMF/EDK II unter KVM schon gesehen?
Insbesondere interessieren mich:
- Wie kann man feststellen, welche EFI-Variablen während der Boot-Services-Phase existieren bzw. geschrieben werden, die Linux später nicht mehr sieht?
- Gibt es eine sichere Möglichkeit, den EDK-II-Variable-Store bzw. dessen Garbage Collection/Reclaim gezielt zu untersuchen oder auszulösen?
- Kann ein dauerhaft wachsender Store trotz gleichbleibender sichtbarer Variablen auf obsolete Variable Records hindeuten?
- Gibt es bekannte OVMF/EDK-II-Konstellationen, bei denen der Varstore bei jedem Boot anwächst, ohne korrekt reclaimed zu werden?
- Falls ein Reset/Neuaufbau des persistenten UEFI-NVRAM nötig ist: Wie macht man das bei einer gehosteten KVM-VM am sichersten, ohne anschließend die UEFI-Bootfähigkeit zu verlieren?
Auf der ESP existiert neben \EFI\debian\shimx64.efi auch der Standard-Fallback-Pfad \EFI\BOOT\BOOTX64.EFI.
Ich möchte momentan bewusst keine Variablen testweise löschen oder große Testvariablen schreiben, da der Store bereits bei 89 % liegt.
Danke vielmals für irgendwelche Hinweise oder Hilfestellung...!!