Wir sind unabhängig, neutral und finanzieren uns teilweise über Werbung und Partnerprovisionen.
Danke wenn du uns unterstützt. Weitere Infos zum Bedanken findest Du hier. Diese Seite verwendet hierzu Cookies & Tracking-Cookies, weitere Informationen findest du hier. Wenn du diese Seite weiterhin besuchst, erklärst du dich damit einverstanden.

Diese seite ist neutral und unabhängig. Die Finanzierung erfolgt teilweise über Werbung und Partnerprovisionen. Danke wenn Du mich unterstützt.
Diese Seite verwendet Cookies & Tracking-Cookies, weitere Informationen findest Du hier. Wenn du diese Seite weiterhin besuchst, erklärst du dich damit einverstanden.

(x) Hinweise ausblenden/einblenden.
Diese Seite ist neutral und unabhängig.
Alle Anleitungen stehen zu 100 %
kostenlos zur Verfügung.
Die Finanzierung erfolgt teilweise
über Werbung und Partnerprovisionen.
Danke wenn Du mich dabei unterstützt.

Alle Infos zum Bedanken findest Du hier.

Besuche Amazon vor Deinem nächsten
Einkauf über diesen Danke Affiliate Link.


Hier kannst Du mir mit PayPal Danken.
Du kannst den Betrag auch anpassen.

Gefällt Dir meine Anleitung?
Hier kannst Du mich Bewerten.
5-Stars



_ _ _ _ ____ ____ ____ _ _ ______ ____ _ _ __ __ |.|_|.||.\_/.||: _ \|:___)|: _ \( \/ ) / .___/|:___)|:\| | / | |\ (_ \ |: _ :| \ : / |:___/|:__) |: / \::/ |:(_\ \|:__) |: | (/|.| |/ /:/ |_| |_| |_| |_| |____)|_|\_) \/ \_____/|____)|_|\_| |_| (___)
_ _ _ _ ____ ____ ____ _ _ ______ ____ _ _ __ __ |.|_|.||.\_/.||: _ \|:___)|: _ \( \/ ) / .___/|:___)|:\| | / | |\ (_ \ |: _ :| \ : / |:___/|:__) |: / \::/ |:(_\ \|:__) |: | (/|.| |/ /:/ |_| |_| |_| |_| |____)|_|\_) \/ \_____/|____)|_|\_| |_| (___)

convert HyperV Ubuntu/Debian Linux
from Generation 1 to Generation 2
2022-07-19 © ctaas.de, Arno Schröder § Impressum



Diese Anleitung beschreibt Schritt-für-Schritt wie man eine HyperV VM Ubuntu basierende Linux VM in der Generation 1 in eine HyperV VM in der Generation 2 konvertieren kann.
Diese Anleitung funktioniert mehr oder weniger mit allen vergleichbaren Linux Distributionen wie Xubuntu, Mate, Debian usw.
Kleinere Systemspezifische Abweichungen sind ggf. möglich. Grundsätzlich sind die Schritte aber auf praktisch alle anderen Linux Systeme so übertragbar.


Wichtiges vorab:
Ubuntu Versionen ab der Version 22.04 mit einem grafischen Desktop funktionieren unter HyperV nur dann, wenn diese HyperV VM als Generation 2 vorliegt.
Eine Ubuntu Server 22.04 Version die nur Terminal bzw. Konsolen basierte Version läuft (also ohne grafischen Desktop) funktioniert auch so nach wie vor unter HyperV als Generation 1.

Ich rate trotzdem geade bei bestehenden Linux VMs zu einem Wechsel der VM Generation 1 zur Generation 2 und zwar aus folgenden Gründen:
Die Generation des virtuellen Computers kann man beim Erstellen einer neuen VM entsprechend auswählen:
Windows HyperV Generation 2 erstellen

Um nun eine bestehende Virtuelle Maschine (VM) umzuwandeln sind folgende Schritte notwendig:

Hinweis vorab:
Alle nachfolgenden Befehle in der Anleitung werden in der Regel als Superuser root verwendet.

  1.
Zuerst sollten Sie eine komplette Datensicherung der zu konvertierenden VM durchführen (z. B. einen 'Export' der VM durchführen).

Disclaimer vorab:
Die Nutzung der Anleitung erfolgt auf eigene Gefahr, für jegliche Schäden wird keine Garantie/Haftung übernommen.
Die Dokumentation entstand aus verschiedenen Tests, sowie produktiven Installationen und stellt eine Zusammenfassung wichtiger und empfohlener Schritte dar.

  2.
Zuerst solltet ihr die zu konvertierende VM auf einen aktuellen Stand bringen.
sudo passwd root # User 'root' Passwort festlegen (sofern noch nicht vorhanden).
su               # Zur 'root' Umgebung wechseln.
apt update       # Paketquellen aktualisieren (vor jedem Update notwendig).
apt dist-upgrade # Auch neue Programmpakete/Programm Versionen installieren (empfohlen).

Ergänzender Hinweis:
Empfehlen würde ich die den Stand Ubuntu Version 20.04 LTS (Long Term Support).
Die Anleitung sollte aber auch mit den Versionen Ubuntu 21.04 und 21.10 funktionieren.
Auf keinen Fall sollten Sie schon vorab zur Version 22.04 wechseln.

  3.
In der zu konvertierenden Linux VM werden zunächst die für EFI notwendigen Pakete installiert.
apt install -y grub-efi # GRand Unified Bootloader (GRUB) EFI Pakete installieren.

Ergänzender Hinweis:
Die Boot Fähigkeit zum Booten von normalen legacy BIOS Systemen wird hierzu nicht beeinträchtigt, allerdings wird erst so später bei der Generation 2 der Start über den EFI-Boot-Manger möglich.
Diese Installation ist also zwingend notwendig. Bei anderen Linux-Systemen kann der Paketname abweichen.

  4.
Nun sichert man alle für den Start notwendige Dateien.
mkdir -p /boot2      # Erstellt ein extra Verzeichnis '/boot2' in der Root-Verzeichnisebene.
cp -r /boot/* /boot2 # Kopiert rekursiv alle für den Start benötigten Dateien nach '/boot2'.

Ergänzender Hinweis:
Das sichern der der Startpartitionen kann man auch überspringen wenn alle Daten zum Start auf einer Partition gespeichert sind.
Es muss dann später nur der Parameter zum kopieren entsprechend angepasst werden.
  5.
Das zu konvertierende System muss man nun ausschalten.
shutdown -h now # Den PC herunterfahren.

Ergänzender Hinweis:
Vorhandene Snapshots sollte man soweit wie möglich vorher löschen.

  6.
Nun legt man eine neue HyperV VM an die 1:1 die gleichen Einstellungen hat wie das vorherige zu konvertierende System.
Es wird also ein komplett neuer virtueller PC erstellt.
Die Schritte werden hier als kurze Animation dargestellt:
Windows HyperV neuen virtuellen Computer (VM) anlegen
Ergänzende Hinweise:
Der Name der VM muss entsprechend vom original Namen abweichen, hängt hier z. B. an den neuen Namen ein Kürzel wie '_Gen2' oder '_G2' an. Man erkennt dann später gleich um was für eine VM-Art es sich handelt.
Den Speicherort des Virtuellen Computers kann man beliebig anpassen, oder auch einfach unverändert übernehmen (wie ihr wollt/ist also egal).
Wichtig ist natürlich die Auswahl der Generation 2, Standardmäßig steht dies immer auf Generation 1.
Klickt also den Assistenten zum Anlegen des Systems immer erst bis zum Ende durch bevor Ihr auf 'Fertig stellen' klickt.
Den Arbeitsspeicher der VM kann man auch im Nachgang jeder Zeit anpassen. Natürlich macht es Sinn der Maschine wieder gleich viel RAM zu geben wie bisher.
Wichtig wäre hier nur in dem Zusammenhang, da Anfangs das System noch von einem Live-Medium gestartet wird. Sollte der RAM wohl nicht unter 1024 MB liegen (so das der Start eines Live-Systems möglich ist).
Die hier in der Slideshow gezeigten Netzwerk Verbindungen (virtuelle Switche) sind individuell, diese müssen zuvor selbst angelegt werden. Dies ist eine Voraussetzung. Diese Anleitung geht hier nicht auf das Anlegen von HyperV-Switchen ein.
Die Namen und Anzahl der vorhanden Switche unterscheidet sich hier daher bei jedem System individuell.
Wichtig ist hier nur: Das System benötigt Anfangs zur Konvertierung auf jeden Fall Internetzugang es sollte also ein entsprechender virtueller Switch/Zugang vorhanden sein der dies ermöglicht.
Nach der Konvertierung kann dieser virtuelle Netzwerk-Zugang natürlich wieder jederzeit entsprechend umkonfiguriert oder entfernt werden.
Wichtig: Bei der Auswahl der virtuellen Festplatten wählt man hier den Punkt: 'Virtuelle Festplatte später zuordnen'.
Erzeugt hier beim Anlegen des neuen virtuellen Computers auf jeden Fall keine neue virtuelle Festplatte.

  7.
Nun kopiert man unter Windows die vorhandene Festplatte auf Dateisystem-Ebene unter einem anderen Namen in das gleiche Verzeichnis.

Beachtet dabei:
Die zu konvertierende Virtuelle Maschine sollte dabei möglichst keine Snapshots haben.
Da ein zurücksetzen auf eine vorherige Version keinen Sinn machen würde, da das System mit einem alten Snapshot nicht von der Generation 2 starten würde.
Man sollte daher vorher alle Snapshots ordentlich über den Hyper-V-Manager wie gewohnt löschen.

Die Schritte werden hier als kurze Animation dargestellt:
Windows HyperV Festplatte kopieren
Ergänzende Hinweise:
Meist liegen diese virtuellen Festplatten unter: C:\HyperV\HDs\ alternativ kann man den Pfad auch über die Eigenschaften des vorhandenen alten virtuellen Computers einsehen.
Die Festplatten tragen immer die Endung: '.vhdx'

Hier im Beispiel wird eine Linux System angepasst dessen Festplatten-Name 'Packer.vhdx' lautet, der Festplatten-Name ist natürlich individuell vom System unterschiedlich.
Der eine oder andere wird sich hier auch mehrere virtuelle Festplatten vorfinden. Schaut daher genau auf die Namen und vor allem auf die Endungen.
Verwechselt die tatsächliche Festplatte nicht eventuell vorhandenen Snapshots. Ein Hinweis kann ggf. auch die Dateigröße sein (in der Regel sind es größere Dateien/natürlich Systemabhängig).

  8.
Als nächstes muss man nun verschiedenste Einstellungen an der neu angelegten HyperV VM anpassen.
Öffnet hierzu die Einstellungen und ändert hier die folgenden Punkte:

Die Schritte werden hier als kurze Animation dargestellt:
Windows HyperV Generation 'Einstellungen' anpassen.
  9.
Startet nun das zu konvertierende System von einem Live-Medium.
Bevorzugt solltet ihr hier ein gleichwertiges System verwenden, welches aktuell installiert ist.
Ich empfehle hierzu Xubuntu 20.04.

Die Xubuntu 20.04 Live-Umgebung startet mit einem englischen Tastaturlayout.
Wer möchte kann dies entsprechend auf eine deutsche Tastaturbelegung umändern (siehe Animation).

Bevor man weiter macht empfehle ich die Energiesparoptionen im Live-System zu deaktivieren.
Dies verhindert ein hängenbleiben des Systems falls man etwas mehr Zeit benötigt.
Gebt zum Deaktivieren hier folgenden Befehl in einem grafischen Terminal ein:
xset s off -dpms


Ein weiterer wichtiger Punkt vorab:
Ein Linux System welches in einer HyperV Generation 2 starten soll benötigt zwingend eine 'EFI-Partition'.

Sollte eine vorhandene alte 'bios, grub' Partition vorhanden sein, dann muss man diese entsprechend umwandeln oder entsprechend eine neue 'EFI-Partition' anlegen.
Die 'EFI-Partition' sollte dabei mindestens 100 MB groß sein. Ich empfehle hier mind. 500 MB (etwas Reserve).

Wenn nun die erste Partition zu klein ist muss man die Partitionsgrößen z. B. mittels GParted anpassen.
Hierzu verkleinert man zuerst die nachfolgende Partition um 500 MB und verschiebt diese dann im Anschluss nach rechts,
sodass im Startbereich (am Anfang des Datenträgers) für die 'EFI-Partition' entsprechend mindestens 100 MB (besser 500 MB) Speicherplatz zur Verfügung steht.

Beachtet hierbei noch folgendes:
Gparted lässt ggf. keine Größenänderung der 'bios, grub' (legacy-Boot-Partition) zu.
Bei mir ließ sich die Größe die hier auf 1 MB festgesetzt war nicht verändern. Vermutlich lag dies an den gesetzten Flags.
Löscht in diesem Fall einfach die vorhandene 'bios, grub' Partition und erzeugt in dem frei gewordenen Speicherbereich eine neue FAT32-Partition.

Wichtig:
Die neue FAT32-Dateisystem angelegte 'EFI-Partition' benötigt hierzu noch die folgenden Flags (Kennzeichen): boot und esp.
boot = Kennzeichnet die Partition dabei als Boot-Partition.
esp = Bedeutet dabei das dieses Laufwerk als EFI-Systempartition verwendet wird.

Die Schritte werden hier als kurze Animation dargestellt:
HyperV Generation 2 Linux EFI-Partition (boot, esp) vorbereiten mit Gparted
  10.
Startet nun im Live System ein Terminal und arbeitet die folgenden Befehle ab:
mkfs -t vfat /dev/sda1 # Formatiert die erste (boot) Partition mit dem FAT32-Dateisystem für die EFI-Partition (sofern noch nicht geschehen).
Die EFI-Partition kann dabei eine FAT12, FAT16 oder FAT32 Partition sein.

Und setzt für diese Partition die entsprechend notwendigen boot und esp Flags (sofern noch nicht geschehen):
sgdisk /dev/sda -t=1:ef00

Ergänzende Parametererklärungen:
sgdisk ist eine Kommandozeilen-basierte Version von gdisk zum Auswerten und ändern von Partitionstabellen im GPT-Format.
Hiermit kann man unter anderem Änderungen an Partitionen Scriptgesteuert übergeben.
[/dev/sda] = bestimmt den Datenträger insgesamt.
[-t=1:ef00 = Der Parameter -t= (change a partition's type code) legt fest das der Partitionstyp (ID/siehe auch Parameter -L) einer Partition geändert wird.
Die Ziffer 1 bestimmt hier die erste Partition auf dem angebenen Datenträger (also genaugenommen /dev/sda1).
Die ID-Kennung ef00 steht hier für den Partitionstyp 'EFI system partition'.

Linux EFI-Partition (boot, esp) mit Gparted
  11.
Mountpunkte anlegen und Partitionen mounten:
mkdir -vp /mnt/boot # Mountpunkt für der EFI-Partition (boot Partition vom System) anlegen.
mkdir -vp /mnt/root # Mountpunkt für die ext4-Datenpartition (root/Dateisystemebene) anlegen.
mount -v /dev/sda1 /mnt/boot # Die EFI-Partition mounten (im System einbinden).
mount -v /dev/sda2 /mnt/root # Die ext4-Partition (Datenpartition) mounten (im System einbinden).


  12.
Nun kopiert man die zuvor gesicherten /boot/* Dateien auf die neue EFI-Partition:
cp -rv /mnt/root/boot2/* /mnt/boot/


  13.
EFI-GRUB Installieren:
apt install grub-efi -y
grub-install --force --target=x86_64-efi --boot-directory=/mnt/boot --efi-directory=/mnt/boot /dev/sda

  14.
Weiterhin muss man nun noch zwingend die Datei /etc/fstab vom ext-Dateisystem also unter /mnt/root/etc/fstab anpassen da sich die UUIDs geändert haben.
Hierzu ermittelt man am besten zuerst die neuen aktuellen UUIDs.
blkid /dev/sda1 # Ermitteln der UUID für die boot/EFI-Partition.
blkid /dev/sda2 # Ermitteln der UUID für die root/ext4-Partition.

blkid /dev/sda1 /dev/sda2 # Gibt gleich beide UUIDs aus (schnelle Version).

Die hier eben ermittelten UUIDs setzt man hier nun wie folgt in der Datei /mnt/root/etc/fstab ein.
sudo mousepad /mnt/root/etc/fstab

Wichtig: Die hier voran gestellte 'sudo' Angabe ist hier auch als User 'root' zwingend notwendig, da der Editor sonst nicht startet (andere chroot Umgebung).

Die Datei sieht dabei in etwa so aus (abhängig vom System, weitere Einträge können enthalten sein):
UUID=123e4567-e89b-12d3-a456-426614174000 / ext4 defaults 0 0
/swap.img     none     swap     sw     0     0
/dev/fd0 /media/floppy0 auto rw,user,noauto,exec,utf8 0 0


Die UUID zum root-Dateisystem ('/') muss man nun auf mit der neuen eben ermittelten UUID ersetzen.
Weiterhin muss man den Eintrag für die EFI-Partition für den Start ergänzen.
Eventuell vorhandene Einträge zu alten Floppy Laufwerken sollte man entfernen.
Denn Diskettenlaufwerke gibt es bei der Hyper-V Generation 2 nicht mehr.
Hier anbei mal ein geändertes Beispiel damit es eindeutig wird. Beachtet aber hier bitte, die UUIDs sind einzigartig und für jedes System individuell.

UUID=291D-440D                            /boot/efi vfat umask=0077 0 1 # Dies ist die boot/EFI-Partition. Diesen Eintrag muss man hier komplett neu hinzufügen. Wichtig: Die UUID entsprechend anpassen!
UUID=7a903192-55cc-45cb-996f-b22f09a27bfc /         ext4 defaults   0 0 # Dies ist die root/ext4-Partition. Wichtig: Auch hier die UUID entsprechend anpassen!
/swap.img                                 none      swap sw         0 0 # Angabe vom Swapfile.


Statt der Angabe der langen UUIDs kann man auch die entsprechenden Devicenamen (Gerätenamen angeben).
Da sich diese Angaben aber bei Veränderungen der vorhandenen Speichermedien ändern können, empfehle ich hier immer wie eben die UUIDs zu nutzen.
Der alternative Fall soll dennoch hier kurz gezeigt werden, da dies dann auch zu einem bootfähigen System führen würde.
UUID=/dev/sda1 /boot/efi vfat umask=0077 0 1 # Dies ist die boot/EFI-Partition.
UUID=/dev/sda2 /         ext4 defaults 0 0 # Dies ist die root/ext4-Partition.
/swap.img     none     swap     sw     0 0

  15.
Die Anpassung im Live-System sind nun soweit abgeschlossen die Linux VM sollte nun wieder ohne Probleme starten:
reboot # Die VM neustarten.

Beim Neustart wird bei Ubuntu Systemen in der Regel die ISO entsprechend ausgeworfen (das DVD-Laufwerk ist dann leer).
Das ist ok so, dass umgewandelte Linux-System sollte nun in der Generation 2 starten.
Beachtet ggf., dass ihr eine alte Generation 1 vorab beendet um doppelte Hostnamen im System zu vermeiden.

  16.
Das Linux-System sollte nun als Generation 2 VM starten.
Allerdings wird sehr wahrscheinlich keine Netzwerkverbindung zur Verfügung stehen.
ip -c a # Zeigt IP-Adressen und den Netzwerkstatus farbig hervorgehoben an.

Vermutlich wird man hier eine Anzeige wie folgt erhalten:
1: lo: mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
   link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
   inet 127.0.0.1/8 scope host lo
      valid_lft forever preferred_lft forever
   inet6 ::1/128 scope host
      valid_lft forever preferred_lft forever
2: eth0: mtu 1500 qdisc noop state DOWN group default qlen 1000
   link/ether 00:15:5d:14::53:2f brd ff:ff:ff:ff:ff:ff

Wie man hier unschwer erkennt, ist das Netzwerk an der Netzwerkschnittstelle 'eth0' entsprechend deaktiviert 'DOWN' also ohne Funktion.
Die Netzwerkschnittstelle erhielt also einen neuen Interface Namen.
Merkt euch hier den Namen der Ausgabe aus dem Terminal (hier im Beispiel 'eth0'). Der Name kann je nach verwendetem System unterschiedlich sein.

Normalerweise orientieren sich die Netzwerk-Interface-Namen bei neuerem Systemen unter anderem an der Art des Anschlusses also on-board, PCI-Express, USB, WLAN usw.
Statt wie üblich eth0, eth1 bei alten Systemen heißt der Interface Name der Netzwerkkarte dann normalerweise z. B. enp0s3, enps21, eno1, wlp3s0 usw.
Merkwürdiger weise erhielten bei mir die Netzwerknamen nun wieder einen alten Schnittstellennamen 'eth0'.

Fakt ist aber auf jeden Fall das sich der Name der Netzwerkschnittstelle geändert hat und so das System das Netzwerk beim Starten nicht mehr korrekt starten kann.
Man muss hier je nach verwendeten System die entsprechende Netzwerkkonfiguration ändern.
Wie man die Netzwerkkonfiguration anpasst/verändert habe ich hier in meiner Haupdokumentation schon mal im Detail beschrieben.

Bei Ubuntu Systemen ab der Version 17.10 wird hier netplan verwendet.
Habt ihr also ein Ubuntu neueres System z. B. Ubuntu 20.04, dann muss man hier nur die entsprechende netplan-Konfiguration anpassen.
Ich erläutere dies hier für dieses System hier kurz das ihr die Anleitung nicht wechseln müsst.

Hierzu geht man wie folgt vor:
cd /etc/netplan # Wechselt in das Konfigurationsverzeichnis für die Netplan-Konfigurationen.
ls -laF # Alle Netzwerkkonfigurationen auflisten.
# Beachtet dabei, der Konfigurationsname kann verschieden sein, auch mehrere Konfigurationsdateien sind möglich.
# Legt man mehrere Konfigurationen an, so werden diese in lexikalischer Reihenfolge (0-9 & A-Z) eingelesen.
# Zu Beginn ist oft nur eine einzelne yaml-Konfigurationsdatei zur Netzwerkkonfiguration vorhanden.
# Diese sollte man öffnen:
# Konsolen basierter Editor (für Server):
nano 50-cloud-init.yaml # Den Dateinamen ggf. anpassen.
mousepad /etc/netplan/* # Oder wenn es nur eine Konfiguration gibt, diese direkt öffnen.

# Oder mit einem grafischer Editor z. B. bei einer Xfce Umgebung:
mousepad 50-cloud-init.yaml # Den Dateinamen ggf. anpassen.
mousepad /etc/netplan/* # Oder wenn es nur eine Konfiguration gibt, diese direkt öffnen.

Die Datei könnte in etwa so aussehen:
# This file is generated from information provided by
# the datasource. Changes to it will not persist across an instance.
# To disable cloud-init's network configuration capabilities, write a file
# /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
# network: {config: disabled}
network:
   version: 2
   ethernets:
       enp0s10f0:
           dhcp4: no
           addresses: [192.168.0.123/24]
           gateway4: 192.168.0.1
           nameservers:
             addresses: [192.168.0.1, 1.1.1.1, 8.8.8.8]

Das Problem ist hier nur, dass der Name der Netzwerkschnittstellen (hier z. B. 'enp0s10f0') nicht mehr stimmt.
Ändert diesen auf die oben aktuell ausgegebenen richtigen Schnittstellennamen ab und speichert die Datei entsprechend unter demselben Namen ab.
Hier im Beispiel war zum Beispiel 'eth0' der richtige/neue Schnittstellennamen. Bei euch könnte das durchaus auch so sein.
So dass das Ganze dann so aussieht:
# This file is generated from information provided by
# the datasource. Changes to it will not persist across an instance.
# To disable cloud-init's network configuration capabilities, write a file
# /etc/cloud/cloud.cfg.d/99-disable-network-config.cfg with the following:
# network: {config: disabled}
network:
   version: 2
   ethernets:
       eth0:
           dhcp4: no
           addresses: [192.168.0.123/24]
           gateway4: 192.168.0.1
           nameservers:
             addresses: [192.168.0.1, 1.1.1.1, 8.8.8.8]

Wichtig:
Die Konfiguration darf keine Tabulator-Zeichen enthalten.
Geht hier beim Ändern sehr vorsichtig vor und lasst alle Einrückungen so unverändert.

Die neuen Einstellungen werden bei einem Neustart automatisch übernommen.
Mit folgendem Befehl kann man die Änderungen sofort prüfen und übernehmen:
netplan apply

Eventuelle Fehler werden sofort angezeigt.
Wird nach Eingabe des Befehls nichts angezeigt, dann ist alles ok.
Bei Fehlern verweise ich hier nochmals auf meine Dokumentation.

Die Netzwerkverbindungen sollten nun sofort wieder funktionieren.
Auch steht dann nun ein Update auf das aktuelle Ubuntu 22.04 Release und höher nichts mehr im Wege.
Um Ubuntu auf eine neue Version zu aktualisieren könnt ihr meine Anleitung von hier verwenden.

Ergänzend dazu noch folgenden Tipps:
Prüft vor einem weiteren Systemupdate die entsprechenden Abhängigkeiten der installierten Programme.
Bei mir ließ sich ein Datenbank-basierendes System nur auf einen zwischenschritt Ubuntu 21.10 aktualisieren.
Ein Update von Ubuntu 21.10 auf 22.04 schlug dan Fehl. Vermutlich aufgrund von grundsätzlich geänderten Datenbankanbindungen.
Die Detailanalyse wo es hier noch klemmt (systemspezifisch) steht noch aus.
Weiterhin wurde mir bei anderen Systemen meist von der Ubuntu Version 20.04 (LTS) kein direktes Update auf die Ubuntu Version 22.04 (LTS) angeboten.
Abhilfe schafte hier auch zuerst ein Update auf die Zwischenversion Ubuntu 21.10. Von da aus erfolgte dann in einem weiteren Schritt ein Update auf die neue Ubuntu Version 22.04 (LTS).
Ich konnte so jedenfalls bei einigen laufenden produktiven VMs die Linux-System-Umgebung relativ problemlos auf Ubuntu 22.04 aktualisieren.

  17.
Zuletzt sollte man nun noch das zuvor gesicherte /boot2 Verzeichnis wieder löschen.
Da dieses nun nicht mehr benötigt wird.
rm -rf /boot2

Abschließende Hinweise:


IP-Adressen, E-Mailadressen, Namen u. ä. wurden für die Dokumentation geändert, hacken ist also zwecklos.
Die Nutzung der Anleitung erfolgt auf eigene Gefahr, für jegliche Schäden wird keine Garantie/Haftung übernommen.
Die Dokumentation entstand aus verschiedenen Tests, sowie produktiven Installationen und stellt eine Zusammenfassung wichtiger und empfohlener Schritte dar.
Bevor sie eventuell Fragen stellen bitte ich sie die Dokumentation komplett zu lesen.
Hinweise auf Fehler, Anregungen, Danksagungen oder ähnliches sind immer willkommen.

Design:
© ctaas.de, A. Schröder - Kahla, Impressum