[SOLVED] Nach Update auf 6.2 bootet eine einzige VM mehr mit UEFI

fireon

Distinguished Member
Oct 25, 2010
4,112
387
153
41
Austria/Graz
iteas.at
Hallo Leute,

seit dem Update heute in unserem Cluster bootet keine einzige VM mehr hoch die UEFI hat, sprich bis auf 3 alle. CT's tun normal. Die VM's bootet in die UEFI Shell. So ähnlich wie wenn keine Festplatte gefunden wird. Irgendwie komme ich hier nicht mal zu einem Ansatz einer Lösung. Ich meine, was könnte sich so stark verändern.

Viele dank schon mal für eure Hilfe.
pve-manager/6.2-4/9824574a (running kernel: 5.4.34-1-pve)

Das wäre eine VMconfig:

Code:
agent: 1
bios: ovmf
boot: dc
bootdisk: scsi0
cores: 8
cpu: host
cpulimit: 4
description: UCS Active Directory Master DC%0A%0A- Printserver%0A- Selfservice%0A- Radius Server%0A- Admintagebuch%0A- Software Installationsmonitor%0A- Druckserver Quota (pykota)
efidisk0: SSD-vmdata:vm-112-disk-0,size=4M
hotplug: disk,network,usb
ide2: none,media=cdrom
memory: 2560
name: dc1.tux.lan
net0: virtio=1C:92:41:F2:CA:C5,bridge=vmbr0,firewall=1
numa: 1
onboot: 1
ostype: l26
scsi0: SSD-vmdata:vm-112-disk-2,discard=on,size=20G,ssd=1
scsi1: SSD-vmdata:vm-112-disk-1,discard=on,size=8G,ssd=1
scsihw: virtio-scsi-pci
serial0: socket
smbios1: uuid=b19adb4b-b1e2-4419-9ace-9c4b7664d389
sockets: 1
startup: order=1,up=30
vga: qxl
vmgenid: 45029be9-19c6-4310-aa8b-0e4aab368975

glg
Fireon
 
Last edited:
siehe die release notes: https://pve.proxmox.com/wiki/Roadmap

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 need manual intervention.
  • 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).
  • After the upgrade, you can recreate the EFI boot entries (e.g. with efibootmgr) and delete the BOOTX64.EFI again(if it did not exist before).
  • If you already upgraded and it does not boot, either boot from a live cd, or via the integrated EFI shell (by selecting the EFI boot binary, e.g. \EFI\debian\grubx64.efi) and repair the EFI entries or by copying the boot binary to \EFI\BOOT\BOOTX64.EFI.
  • If your EFI disks is on qcow2 you do not have to do anything
 
Ok, versteh ich nicht. Ich bin jetzt live hochgefahren auf einer Univention VM (Domaincontroller). Hab die Laufwerke eingehängt.

Code:
/dev/sda2 on /mnt/ type ext4
/dev/sda1 on /mnt/boot/efi type vfat
Nun könnte ich das File kopieren:
Code:
root@xubuntu:/mnt/boot# cp efi/EFI/univention/grubx64.efi
Aber wohin?

Was ist gemeint mit \EFI\BOOT\BOOTX64.EFI ?
 
nach efi/EFI/BOOT/BOOTX64.EFI :)

bzw. besser erklärt:

der pfad bezieht sich auf die ESP die du nach /mnt/boot/efi gemountet hast
also (explizit) nach /mnt/boot/efi/EFI/BOOT/BOOTX64.EFI
 
Ok, das Verzeichnis hab ich nicht. Es gibt auch 2 von den Files, die sind nicht gleich:
Code:
a1c791c4f885e3bbabc915c6bfa0a087  grub/grubx64.efi
10d52d06dca77784836b2e56c9b64e7d  univention/grubx64.efi
Laut der Syntax vom Changelog sollte es dann eh "univention/grubx64.efi" sein.

Verzeichnisse habe ich diese:
Code:
root@xubuntu:/mnt/boot# tree efi
efi
├── EFI
│   ├── grub
│   │   ├── grub.cfg
│   │   ├── grub.efi
│   │   ├── grubx64.efi
│   │   └── shimx64.efi
│   └── univention
│       ├── grub.cfg
│       ├── grub.efi
│       ├── grubx64.efi
│       └── shimx64.efi
└── NvVars

3 directories, 9 files

Oder ist das Verzeichnis einfach zu erstellen?

hmm, ok fast richtig, ich bekomme nen Grub. Nun steht da aber das es nicht booten kann weil die Signatur des Kernels nicht passt.

Und nochwas ist mir aufgefallen. Ich habe ein Windows10 und ein Ubuntu 19.10 das schon lange auf UEFI lauft. Die starteten ganz normal. Betrifft anscheinend nur Debian.
 
Last edited:
Ok, das Verzeichnis hab ich nicht. Es gibt auch 2 von den Files, die sind nicht gleich:
mhmm... weiß nicht genau was univention so macht, aber ich schätze das univention das richtige ist

um korrekterweise das richtige herauszufinden, könntest du die vm mit einem alten machine type booten
(zb. pc-i440fx-4.0.1 ; qm set ID -machine pc-i440fx-4.0 ) und dann mit 'efibootmgr -v' nachschauen was
denn der korrekte boot eintrag ist

Oder ist das Verzeichnis einfach zu erstellen?
ja einfach erstellen oder alternativ mit efibootmgr die einträge erstellen (siehe oben wie man die original einträge bekommnt)
 
Last edited:
  • Like
Reactions: fireon
Und nochwas ist mir aufgefallen. Ich habe ein Windows10 und ein Ubuntu 19.10 das schon lange auf UEFI lauft. Die starteten ganz normal. Betrifft anscheinend nur Debian.
die kopieren wahrscheinlich das binary schon direkt zum default pfad
 
  • Like
Reactions: fireon
Den Maschinentyp scheint es nicht mehr zu geben. Laut Manpage sieht es so aus:
Code:
(pc|pc(-i440fx)?-\d+(\.\d+)+(\+pve\d+)?(\.pxe)?|q35|pc-q35-\d+(\.\d+)+(\+pve\d+)?(\.pxe)?|virt(?:-\d+(\.\d+)+)?(\+pve\d+)?)
Wobei ich dabei völlig aussteige.

Von den Files her ist es egal was für eines ich verwende. Die Fehlermeldung ist immer die selbe (siehe Anhang). Ich versuche jetzt mal das ich in einer Chroot reinkomme und möglicherweise kann ich dort mit efibootmgr etwas ausrichte. Muss ja gehen. Ist ja eh Debian.

glg :)
 

Attachments

  • Screenshot_20200512_170259.png
    Screenshot_20200512_170259.png
    127.9 KB · Views: 11
hi, du könntest auch noch versuchen das shimx64.efi zu kopieren...
 
Weitaus einfacher als mit Live CDs zu arbeiten sollte der File Browser den OVMF selbst mitbringt sein.

Start-up -> ESC um ins OVMF menu zu kommen.

Dann "Boot Maintenance Manager" -> "Boot From File" -> Disk mit ESP auswählen.

Screenshot_2020-05-12 nina - Proxmox Virtual Environment.png
Screenshot_2020-05-12 nina - Proxmox Virtual Environment(1).png
Screenshot_2020-05-12 nina - Proxmox Virtual Environment(3).png

EFI -> fedora (oder debian, o.ä.)
Screenshot_2020-05-12 nina - Proxmox Virtual Environment(4).png
 

Attachments

  • Screenshot_2020-05-12 nina - Proxmox Virtual Environment(2).png
    Screenshot_2020-05-12 nina - Proxmox Virtual Environment(2).png
    74.9 KB · Views: 13
Last edited:
Ok, Schritt weiter. Mit dem Maschinentyp komm ich hoch. Gut. So ein UEFI Eintrag sieht hier so aus:
Code:
Boot0006* univention    HD(1,GPT,8c5296c9-5792-433f-870f-37af53aada38,0x800,0x1dc800)/File(\EFI\univention\shimx64.efi)
Nun habe ich noch das File kopiert, einmal so wie es heißt. Einmal als BOOTX64.EFI, einmal zusätzlich. In allen Varianten. Wenn ich des als BOOTX64.EFI setzte kommt nur die EFI Shell.

Wie kann/muss ich nun die neuen EFI Einträge setzen. Ich hab das hier gefunden:
https://wiki.ubuntuusers.de/efibootmgr/

Das heißt aber ich den alten Eintrag zuerst löschen muss, richtig? Dann denn neuen erstellen.
z.B. "efibootmgr -b 0006 -B"

Wenn ich mit einer LIvedisk und Chroot boote, und ich "efibootmgr -v", besteht der Pfad zum UEFI File nur als komischen Zeichenfolgen.
Code:
Boot0002* UEFI QEMU QEMU HARDDISK       PciRoot(0x0)/Pci(0x5,0x0)/SCSI(0,0)N.....YM....R,Y.
Das setzten des neuen Eintrages könnte vielleicht so aussehen:

Code:
efibootmgr --create --disk /dev/disk/by-id/scsi-0QEMU_QEMU_HARDDISK_drive-scsi0 --part 1 --label "univention" --loader \\EFI\\univention\\shimx64.efi
Ok, ich check das mal ab, so sehe es ja theoretisch gut aus.
Code:
Boot0005* univention    HD(1,GPT,ae4a6cd4-cd37-454c-8a81-116724c7ab35,0x800,0x1dc800)/File(\EFI\univention\shimx64.efi)
 
Last edited:
Wie kann/muss ich nun die neuen EFI Einträge setzen. Ich hab das hier gefunden:
https://wiki.ubuntuusers.de/efibootmgr/

efibootmgr kann OK sein, alte löschen muss man nicht, den neuen einfach mit höherer Priorität ausstatten.

Aber ich würde persönlich auch hier direkt OVMF verwenden:
Wieder ins OVMF firmware menu mit ESC, dann zum "Boot Maintenance -> Boot Options -> Add Boot Option" GUI. Sieht z.B so aus:

Screenshot_2020-05-12 nina - Proxmox Virtual Environment(5).png

Danach kann man auch noch die Boot Priorität in "Boot Maintenance -> Boot Options -> Change Boot Order" ändern.
 
Achja, da muss ich gleich nochmal das wichtigste überhaupt loswerden. Mein Wiki hat auf der Startseite auch ein "Spenden Button". Und das coole drann, der geht auch ohne Anmeldung ;) https://deepdoc.at/dokuwiki/doku.php Aus diesem Grund am besten gleich austesten!

Vielen Dank :) :)
 

About

The Proxmox community has been around for many years and offers help and support for Proxmox VE, Proxmox Backup Server, and Proxmox Mail Gateway.
We think our community is one of the best thanks to people like you!

Get your subscription!

The Proxmox team works very hard to make sure you are running the best software and getting stable updates and security enhancements, as well as quick enterprise support. Tens of thousands of happy customers have a Proxmox subscription. Get yours easily in our online shop.

Buy now!