Proxmox VM bootet nicht mehr - nur mehr UEFIshell - was ist zu tun?
Du möchtest dich gerne für unsere Hilfe erkenntlich zeigen . Gerne. Wir bedanken uns bei dir für deine Spende!
Hauseigenes Apt-Repo: https://apt.iteas.at
GITLAB Enterprise:
Beim Update von Proxmox 6.1 auf 6.2 gab es einige Änderungen. Vorallem dieser Ausschnitt.
Known Issues with OVMF/UEFI disks
An EFI disk on a storage which doesn't allow for small (128 KB) images (for example: CEPH, ZFS, LVM(thin)), was not correctly mapped to the VM. While fixed now, such existing setup may need manual intervention:
- If your EFI disks is on qcow2 you do not have to do anything.
- Before the upgrade, make sure that on your ESP, the EFI boot binary exists at \EFI\BOOT\BOOTX64.EFI (the default fallback when no EFI boot entries are set). Windows and some Linux VMs using systemd-boot should do that automatically
- After the upgrade, you can recreate the EFI boot entries (for example, with efibootmgr) and delete the BOOTX64.EFI again(if it did not exist before).
- If you already upgraded and it does not boot, Start-up the VM → press ESC to get into the OVMF menu. Then „Boot Maintenance Manager“ → „Boot From File“ → choose Disk with the EFI System Partition (ESP). Now you can navigate to the EFI executable, for example for Debian: EFI/debian/grubx64.efi or for Fedora: EFI/fedora/shimx64-fedora.efi. Once you found the correct one boot and after that restore the efiboot entry, see your Distribution's Documentation for this or use also the OVMF firmware „Boot Maintenance → Boot Options → Add Boot Option“ GUI.
Auf Deutsch: „schaut man sich vorher nicht gründlich die Changelogs an, kann es sein das einige/viele VM's nicht mehr starten die UEFI verwenden!“
An dieser Stelle darf ich dich beruhigen, es ist alles halb so wild, doch viel mehr easy… wenn man weiß wo man was bewegen muss, um sein Ziel zu erreichen.
Windows und Ubuntu hatten damit kein Problem. Univention (Debian) 4.4.4 schon. Das UEFI Boot liegt dort nicht im Recovery/Standardordner. Somit booten diese VM's nach dem Update auf PVE 6.2 nicht mehr. Es gibt nun mehrere Möglichkeiten das ganze zu fixen.
- Ganz einfach über die UEFI Konsole
- Ändern des Maschinentyps und booten der VM (Workaround nicht empfohlen)
- Booten mit einer LiveISO und neu setzen des Eintrages per efibootmgr
Ganz einfach über die UEFI Konsole
Mit der UEFI Konsole (beim Start der VM hat man ein paar Sekunden Zeit für ESC) hat man das Bootmenü voll im Griff, neue Einträge generieren, bearbeiten, Prioritäten festlegen.
Ist man in der UEFI Konsole wählt man im Menü: Boot Maintenance Manager → Boot Options → Add Boot Option
, wählt dann den nächsten Beitrag und man befindet sich im UEFI Fileexplorer. Dort hüpft man in der Ordnerhirachie bequem zum UEFI Bootile das man möchte und wählt es aus. In unserem Fall ist das:
EFI\univention\shimx64.efi
Danach speichert man und ändert noch die Bootreihenfolge mit „Change Boot Order“. Wieder speichern und danach Reseten. Fertig.
Direktes Booten über die UEFI Konsole
Man kann diese File womit wir oben gerade einen neuen Booteintrag erzeugt haben, auch ohne Booteintrag manuell starten. Als Beispiel betreten wir wieder die UEFI Konsole:
Boot Maintenance Manager → Boot From File
Und gehen dann dort wieder mit dem UEFI Fileexplorer bequem zu seinem Bootfile. Auswählen, und die VM startet schon.
Ändern des Maschinentyps und booten der VM (Workaround nicht empfohlen)
Ändert man den Maschinentyp der VM in Proxmox, bootet die VM wie gewohnt hoch. Eine Lösung ist es jedoch nicht, da dies ziemlich sicher irgendwann, wenn der Maschinentyp rausfällt nicht mehr funktionieren wird.
qm set 111 -machine pc-i440fx-4.0
Was man damit sehrwohl gut erreichen kann, wenn man nicht weiß welches File tatsächlich zum Booten verwendet wird, bootet man so die VM und liest mit efibootmgr -v
genau dies aus. In Univention könnte es so aussehen:
Boot0007* univention PciRoot(0x0)/Pci(0x5,0x0)/SCSI(0,0)/HD(1,GPT,c59de47c-8df8-43ad-a653-216309c0edf3,0x800,0x1dc800)/File(\EFI\univention\shimx64.efi)
Booten mit einer LiveISO und neu setzen des Eintrages per efibootmgr
Das ganze kann man natürlich auch mit einer LiveISO lösen. Hierzu bootet man das OS seiner Wahl und bindet sämtliche Partitionen die für eine Chroot notwendig sind ein.
mount /dev/sda2 /mnt mount /dev/sda1 /mnt/boot/efi for i in dev dev/pts proc sys sys/firmware; do mount --bind /$i /mnt/$i; done chroot /mnt
In der Chroot angekommen sieht man wieder mit efibootmgr -v
alle Einträge. Unter anderem ein etwas komisch zerstörter Eintrag, was mal unserer war. Du darfst dort Einträge löschen, musst aber nicht. Mit der Priorität kannst du deinen Eintrag auch schieben wie du möchtest. Löschen funktioniert so:
efibootmgr -b 0004 -B
Hiermit wurde nun der UEFI Booteintrag mit der Nummer 0004 gelöscht. Legen wir nun unseren neuen Eintrag an.
efibootmgr --create --disk /dev/disk/by-id/scsi-0QEMU_QEMU_HARDDISK_drive-scsi0 --part 1 --label "univention" --loader \\EFI\\univention\\shimx64.efi
Bei meinen Tests wurde der Beitrag automatisch nach oben gereiht. Sollte das nicht der Fall sein, oder möchtest du die Reihenfolge noch ändern, kannst du dich diesem Befehl bedienen.
efibootmgr -o 0005,0003,0004,0007
Das setzt die Prioritäten nach der Reihe.