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 a Microsoft Hyper-V Ubuntu/Debian Linux VM
from Generation 1 to Generation 2
2022-09-02 © ctaas.de, Arno Schröder § Impressum
Diese Anleitung beschreibt Schritt-für-Schritt wie man eine Hyper-V VM Ubuntu basierende Linux VM in der Generation 1 in eine Hyper-V 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 Hyper-V nur dann, wenn diese Hyper-V 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 Hyper-V 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 Hyper-V 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 Hardware innerhalb der VM 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 -pv /boot2 # Erstellt ein extra Verzeichnis '/boot2' in der Root-Verzeichnisebene.
cp -rv /boot/* /boot2 # Kopiert rekursiv alle für den Start benötigten Dateien nach '/boot2'.
Ergänzender Hinweis:
Das sichern der der Startpartitionen kann man nicht überspringen, auch wenn alle Daten zum Start auf einer Partition gespeichert sind.
Dieser Schritt ist somit zwingend notwendig!
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 Hyper-V 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).
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 wie gewohnt über den Hyper-V-Manager 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 in der Regel immer die Endung: '.vhdx'.
Solltet ihr eine Festplatte im Format alten '.vhd' Format haben,
dann müsst ihr diese über den Hyper-V-Manger über die Menüpunkte [Einstellungen], hier dann [Bearbeiten] auf der Festplatte anklicken,
diese entsprechend in eine '.vhdx' Festplatte [konvertieren]. Denn die Generation 2 VMs können nur mit '.vhdx' zusammenarbeiten.
Hier im Beispiel wird eine Linux System angepasst dessen Festplatten-Name 'Packer.vhdx' lautet verwendet.
Jeder Festplatten-Name ist natürlich individuell (je nachdem was ihr festgelegt habt). Diesen solltet ihr daher dem eigenen System entsprechend anpassen.
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 Hyper-V 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 (falls ihr langsamer lest/nebenbei arbeiten erledigt).
Gebt zum Deaktivieren der Energiesparfunktion hier folgenden Befehl in einem grafischen Terminal ein:
xset s off -dpms
Ein weiterer wichtiger Punkt vorab:
Ein Linux System welches in einer Hyper-V 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_Animation.gif)
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).
mkfs.vfat /dev/sda1 # Alternative Version/Ubuntu Versionsabhängig - Formatiert ebenso die Partition '/dev/sda1' mit 'FAT32'.
Nur ergänzend zur Info: 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 -g # Der Parameter ' -g' ist nur bei einem vorhandenen alten MBR-Bootsektor auf einem Datenträger mit neuem GPT-Format notwendig. Also demnach nur ggf. bei Konvertierungen bzw. nur wenn ein Fehler bei der Ausführung erscheint.
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 -g = 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 -pv /mnt/boot # Mountpunkt für der EFI-Partition (boot Partition vom System) anlegen.
mkdir -pv /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 /boot2/* Dateien auf die neue EFI-Partition zurück:
cp -rv /mnt/root/boot2/* /mnt/boot/
Bachtet hierbei das ihr wirklich die Dateien aus dem Ordner /boot2/ kopiert und nicht fälschlicherweise den Ordner /boot/ verwendet!
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
Ergänzender Hinweis:
Das korrekte '--efi-directory' Pfad müsste eigentlich '/mnt/boot/efi' heißen, diesen kann man hier aber noch nicht angeben.
Gebt den Pfad daher erst einmal so wie hier gezeigt ein. Der Pfad wird später noch entsprechend korrigiert (siehe Punkt 16).
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 ggf. 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 können weitere Einträge 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 mit der eben ermittelten UUID ersetzen (nur falls diese abweichen).
Weiterhin muss man den Eintrag für die EFI-Partition für den Start ergänzen. Verwendet hier ebenso die eben ermittelte passende UUID (siehe Zeile 1).
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 also 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 (sofern vorhanden).
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/IP-Adressen im Netzwerk zu vermeiden.
16.
Nun im Nachgang muss man nun noch den korrekten '--efi-directory' Pfad angegeben (siehe auch Punkt 13).
Denn das System startet sonst nach Updates (insbesondere Upgrades auf neue Release Versionen) also z. B. nach einem Update von Ubuntu 20.04 auf Ubuntu 22.04.x möglicherweise nicht mehr korrekt durch.
Um dies zu vermeiden führt man im neu gestarten System noch die folgenden Befehle aus:
grub-install /dev/sda --efi-directory=/boot/efi
update-grub
reboot
Wenn der '--efi-directory' Pfad nicht richtig angegeben wurde, bleibt das System nach einem Upgrade (do-release-upgrade) z. B. mit folgender Fehlermeldung hängen:
[Please append a correct "root=" boot option ... Kernel panic ... Unable to mount root fs .... BIOS Hyper-V UEFI].
Hier nur noch mal ergänzend ein Screenshot des Fehlers (der nur dann auftritt wenn der '--efi-directory' Pfad nicht korrekt gesetzt wurde):
17.
Hinweis:
Diesen Punkt 17 könnt ihr überspringen wenn eine Internet/Netzwerkverbindung zur Verfügung steht.
Das Linux-System sollte nun als Generation 2 VM starten.
Allerdings kann es passieren (abhängig vom Urspungssystem) das keine Netzwerkverbindung zur Verfügung steht.
ip -c a # Zeigt IP-Adressen und den Netzwerkstatus farbig hervorgehoben an.
Falls das zutrifft, dann wird man hier eine Anzeige wie folgt erhalten:
1: lo: <LOOPBACK,UP,LOWER_UP> 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: <BROADCAST, MULTICAST> 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 (verwendet bei Bedarf nur die Leertaste).
Geht hier beim Ändern sehr vorsichtig vor und lasst alle Einrückungen möglichst 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.
Hier muss man dann per Hand nacharbreiten, dies ist aber kein grundsätzliches Problem der verwendeten Generation, sondern der eingesetzten Software.
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.
Nachtrag vom 24.08.2022. Mit der Freigabe der neuen Ubuntu Version 22.04.1 erfolgen nun direkt Updates von Ubuntu 20.04. auf Ubuntu 22.04.1 (ich habe dies produktiv auch so schon umgesetzt).
Der Weg zuerst über eine Zwischenversion ist demnach nicht mehr notwendig (schaden würde er aber auch nicht).
Beachtet auch den Datenumfang (insbesondere den freien Speicherplatz der virtuellen Festplatte) beim Update von Ubuntu 20.04 auf Ubuntu 22.04.
Der Update-Assistent schätzt zwar Anfangs den speicher und gibt dazu meiner Meinung nach auch Meldungen aus. Allerdings scheinen Warnungen hier nicht so zuverässig zu funktionieren.
Bei mir hing ein Update ständig bis ich festgestellt hatte, dass nur 5 GB freier Festplattenspeicher nicht für ein Update ausreichen.
Empfehlen würde ich daher mindestens 10 GB freien Festplattenspeicher bevor ihr mit dem Update anfangt.
18.
Zuletzt sollte man nun noch das zuvor gesicherte /boot2 Verzeichnis wieder löschen.
Da dieses nun nicht mehr benötigt wird.
rm -rfv /boot2
19.
Wer die VM in der Microsoft Hyper-V Umgebung noch weiter optimieren möchte kann nun noch das linux-azure package installieren.
Dieses Paket installiert einen optimierten Kernel der speziell für Hyper-V optimiert wurde (weitere Details finden sich unter diesem Link).
Den optimierten Azure-Kernel installiert man wie folgt:
apt install linux-azure
reboot
Die Installation überprüfen:
Nach einem Neustart kann man mit uname prüfen ob der optimierte Azure-Kernel auch wirklich verwendet wird:
uname -r # (kernel release) kurze Ausgabe
uname -a # (all) ausführliche Ausgabe
Wenn der Kernel korrekt verwendet wird sollte eine Ausgabe in der Art folgen:
5.15.0-1019-azure
Linux ubuntu 5.15.0-1019-azure #24-Ubuntu SMP Tue Aug 23 15:05:55 UTC 2022 x86_64 x86_64 GNU/Linux
Ohne installiertem Azure-Kernel steht hier für gewöhnlich statt 'azure' meist 'generic'.
Den Azure-Kernel wieder entfernen (optional):
Den Azure-Kernel kann man mit folgenden Befehlen wieder entfernen:
apt purge linux*azure # Die Frage: [Abort kernel removal?] entsprechend mit [No] beantworten (also das entfernen fortsetzen).
reboot # Der Azure-Kernel wird erst nach einem Neustart nicht mehr verwendet.
apt autoremove # Optional: Entfernt alle nicht mehr benötigte Paket einschließlich aller nicht mehr benötiger Abhängigkeiten von der Festplatte (auch den Speicherplatz wieder freigeben).
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
