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.
_ _ _ _ ____ ____ ____ _ _ ______ ____ _ _ __ __
|.|_|.||.\_/.||: _ \|:___)|: _ \( \/ ) / .___/|:___)|:\| | / | |\ (_ \
|: _ :| \ : / |:___/|:__) |: / \::/ |:(_\ \|:__) |: | (/|.| |/ /:/
|_| |_| |_| |_| |____)|_|\_) \/ \_____/|____)|_|\_| |_| (___)
_ _ _ _ ____ ____ ____ _ _ ______ ____ _ _ __ __
|.|_|.||.\_/.||: _ \|:___)|: _ \( \/ ) / .___/|:___)|:\| | / | |\ (_ \
|: _ :| \ : / |:___/|:__) |: / \::/ |:(_\ \|:__) |: | (/|.| |/ /:/
|_| |_| |_| |_| |____)|_|\_) \/ \_____/|____)|_|\_| |_| (___)
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:
- Generation 2 Systeme setzen auf den EFI-Modus zum Starten, praktisch wie jeder neue Standard PC. Ein Wechsel einer laufenden virtuellen VM auf eine physische echte Maschine (sofern erforderlich) sollte so problemloser klappen.
Alte PCs die ein reines BIOS zum Starten verwenden stehen in der Praxis immer seltener zur Verfügung.
- Neue Linux Versionen (es ist hier nicht nur Ubuntu betroffen) bauen immer mehr auf die Generation 2 auf, da auch immer mehr Entwickler in der Regel auf neuen PC-Systemen mit EFI-Modus Software entwickeln.
Langfristig wird es daher mit Generation 1 VMs wohl zu Problemen kommen (so meine Einschätzung).
- Ab Ubuntu 22.04 ist kein grafischer Desktop wie (Gnome/Xfce/Mate usw.) mehr möglich.
Versucht man unter Microsoft Windows HyperV eine Ubuntu 22.04 Linux in die grafische Oberfläche zu starten, dann bleiben diese ohne ersichtliche Rückmeldung hängen. Der Bildschirm bleibt hier meist einfach nur schwarz/leer.
Möchte man nun aber ein vorhandenes System mal mit einem aktuellen Live-System starten sei es zu Sicherungs- oder zu Wartungszwecken, dann ist dies nicht möglich (das ist dann eher ungünstig).
Bei produktiven Systemen empfehle ich daher dringend einen Wechsel von der Generation 1 zur Generation 2.
- Weiterhin werden bei Systemen der Generation 1 aus Kompatibilitätsgründen eine Vielzahl der verwendeten VM Hardware softwareseitig emuliert.
Das erhöht zwar die Kompatibilität bei sehr alten Systemen, steigert aber gleichzeitig die CPU-Last bei den betroffenen VMs.
Bei neuen Linux Versionen wie bei Ubuntu 22.04 basierenden Systemen ist es nicht mehr notwendig alte Hardware zu emulieren, da diese Version bereits entsprechend an das System angepasste neue Software und Treiber mitbringen.
- Wenn das System auf die Emulation alter Hardware verzichten kann steigt nachweißlich die Performance des ganzen Systems.
Software und Programme die innerhalb einer VM laufen sind so entsprechend schneller und der Datendurchsatz erhöht sich.
Indirekt kann das Ganze dann sogar Strom sparen, da anfallenden Arbeiten auf dem System schneller erledigt sind.
Die Generation des virtuellen Computers kann man beim Erstellen einer neuen VM entsprechend auswählen:
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:
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:
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:
- Den Haken vor 'Sicheren Start aktivieren' entfernen.
- Die Anzahl der virtuellen Prozessoren sollte man entsprechend der alten VM anpassen (optional/Empfohlen).
Bei Mehrkernprozessor-Systemen empfehle hier mindestens 2 virtuelle Prozessoren, sodass man zukünftig für Software mit Threads/Mehrkernnutzung vorbereitet ist.
- Fügt nun dem SCSI-Controller die soeben kopierte 'Virtuelle Festplatte' hinzu.
Die Festplatten-Datei wählt man nur über den 'Durchsuchen' Button über den Dateiöffnungsdialog aus und fügt diese der VM hinzu.
Beachtet dabei: Die hier im Screenshot gezeigte Festplatte: 'C:\HyperV\HDs\Packer_Gen2.vhdx' ist nur ein Beispiel.
Es wird hier definitiv keine neue Festplatte angelegt.
- Fügt nun dem SCSI-Controller noch weiterhin ein DVD-Laufwerk hinzu.
- Den Punkt 'Automatische Prüfpunkte verwenden' sollte man deaktivieren (zum mindestens so lange man die Umstellung vornimmt).
Nicht das man nach der Umstellung beim Anwenden eines Prüfpunktes (zurücksetzen der VM auf einen gespeicherten Prüfpunkt) auf einen Zwischenschritt zurückfällt.
Grundsätzlich deaktiviere ich diese 'Automatischen Prüfpunkte' immer, also dauerhaft, auch für den produktiven Betrieb (meine Empfehlung).
Prüfpunkte (Snapshots) können trotzdem jederzeit noch manuell (kontrolliert) angelegt werden.
- Nachdem man nun die Festplatte und das DVD-Laufwerk hinzugefügt hat muss man nun noch die Startreihenfolge so abändern, dass zuerst vom DVD-Laufwerk und als zweites von der Festplatte gestartet wird.
Die Schritte werden hier als kurze Animation dargestellt:
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:
_vorbereiten_mit_Gparted.webp)
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'.
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
