Unterschiede

Hier werden die Unterschiede zwischen zwei Versionen gezeigt.

--- virtualisierung:proxmox_kvm_und_lxc:proxmox_vm_bootet_nicht_mehr_-_nur_mehr_uefishell_-_was_ist_zu_tun [2020/05/12 21:35]
loma
+++ virtualisierung:proxmox_kvm_und_lxc:proxmox_vm_bootet_nicht_mehr_-_nur_mehr_uefishell_-_was_ist_zu_tun [2020/05/12 21:41] (aktuell)
loma
@@ Zeile 11: / Zeile 11: @@
   * 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 sich vorher nicht gründlich die Changelogs an, kann es sein das einige/viele VM's nicht mehr starten die UEFI verwenden!"
+__**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, viel mehr easy... wenn man weiß wo man was bewegen muss um sein Ziel zu erreichen.
+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 hatte 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.
+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
@@ Zeile 22: / Zeile 22: @@
 ===== Ganz einfach über die UEFI Konsole =====
-Die UEFI Konsole (beim Start der VM hat man ein paar Sekunden Zeit für ESC) kann man das Bootmenü voll bearbeiten, neue Einträge generieren, bearbeiten, Prioritäten festlegen.
+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 dann 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:
+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 speicher und Reseten. Fertig.
+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 geht dann dort wieder mit dem **UEFI Fileexplorer** bequem zu seinem Bootfile.
+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) =====
@@ Zeile 38: / Zeile 38: @@
 qm set 111 -machine pc-i440fx-4.0
 </code>
-Was man damit sehrwohl gut erreichen ist, 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:
+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:
 <code>
 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)
@@ Zeile 51: / Zeile 51: @@
 chroot /mnt
 </code>
-In der Chroot angekommen sieht man wieder mit ''efibootmgr -v'' alle Einträge. Unter anderem ein etwas komisch zerstörter, 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:
+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:
 <code>
 efibootmgr -b 0004 -B
 </code>
-Hiermit wurden nun der UEFI Booteintrag mit der Nummer 0004 gelöscht.
+Hiermit wurde nun der UEFI Booteintrag mit der Nummer 0004 gelöscht.
 Legen wir nun unseren neuen Eintrag an.
 <code>