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

[fireon]

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:

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

 

[dcsapak]

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

 

[fireon]

 

[fireon]

Ok, versteh ich nicht. Ich bin jetzt live hochgefahren auf einer Univention VM (Domaincontroller). Hab die Laufwerke eingehängt.

/dev/sda2 on /mnt/ type ext4
/dev/sda1 on /mnt/boot/efi type vfat

Nun könnte ich das File kopieren:

root@xubuntu:/mnt/boot# cp efi/EFI/univention/grubx64.efi

Aber wohin?

Was ist gemeint mit \EFI\BOOT\BOOTX64.EFI ?

 

[dcsapak]

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

 

[fireon]

Ok, das Verzeichnis hab ich nicht. Es gibt auch 2 von den Files, die sind nicht gleich:

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:

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.

 

[dcsapak]

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)

 

[dcsapak]

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

 

[fireon]

Den Maschinentyp scheint es nicht mehr zu geben. Laut Manpage sieht es so aus:

(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

 

[dcsapak]

Den Maschinentyp scheint es nicht mehr zu geben

ups, ja bitte pc-i440fx-4.0 verwenden (habs oben editiert)

 

[dcsapak]

hi, du könntest auch noch versuchen das shimx64.efi zu kopieren...

 

[t.lamprecht]

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.





EFI -> fedora (oder debian, o.ä.)

 

[fireon]

Ok, Schritt weiter. Mit dem Maschinentyp komm ich hoch. Gut. So ein UEFI Eintrag sieht hier so aus:

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.

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:

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.

Boot0005* univention    HD(1,GPT,ae4a6cd4-cd37-454c-8a81-116724c7ab35,0x800,0x1dc800)/File(\EFI\univention\shimx64.efi)

 

[t.lamprecht]

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:



Danach kann man auch noch die Boot Priorität in "Boot Maintenance -> Boot Options -> Change Boot Order" ändern.

 

[fireon]

Das mit der UEFI Konsole ist ja MEGAhammer. Wusste ich noch nicht das es soooo einfach ist. Vielen Dank!
Habe für diesen Fall gleich ein Howto verfasst. Sehr gut, durfte ich wieder was lernen

https://deepdoc.at/dokuwiki/doku.ph...ht_mehr_-_nur_mehr_uefishell_-_was_ist_zu_tun

 

[fireon]

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