GRUB reparieren nach VM Konvertierung (VMWARE)
Hallo zusammen,
ich habe mit dem vmware converter eine physische Ubuntu Server 20.04 Maschine zu einer VM konvertiert. Der Vorgang scheitert an der GRUB Installation kurz vor Ende. Die VM wird erzeugt, bootet aber nur eine GRUB Shell. Ich kann von dort in ein Linux booten, kriege aber die EFI Partition nicht gemountet und damit GRUB nicht repariert.
Fehler: grub-install: error: cannot find EFI directory. Laut dem Mount Befehl auf der PHY Maschine ist /dev/sda1 on /boot/efi gemountet.
Hat jemand schon eine solche Maschine erfolgreich zu vmware konvertiert?
Gruß,
Thomas
ich habe mit dem vmware converter eine physische Ubuntu Server 20.04 Maschine zu einer VM konvertiert. Der Vorgang scheitert an der GRUB Installation kurz vor Ende. Die VM wird erzeugt, bootet aber nur eine GRUB Shell. Ich kann von dort in ein Linux booten, kriege aber die EFI Partition nicht gemountet und damit GRUB nicht repariert.
Fehler: grub-install: error: cannot find EFI directory. Laut dem Mount Befehl auf der PHY Maschine ist /dev/sda1 on /boot/efi gemountet.
Hat jemand schon eine solche Maschine erfolgreich zu vmware konvertiert?
Gruß,
Thomas
Bitte markiere auch die Kommentare, die zur Lösung des Beitrags beigetragen haben
Content-ID: 666152
Url: https://administrator.de/forum/grub-reparieren-nach-vm-konvertierung-vmware-666152.html
Ausgedruckt am: 26.12.2024 um 01:12 Uhr
19 Kommentare
Neuester Kommentar
Ich mache das immer mit dd oder ddrescue. Dazu dann eine passende vmdk für flat-files manuell erstellt und man kann das direkt in VMware einbinden.
Man kann datürlich auch qemu-img verwenden und das Image in eine vmdk zu konvertieren.
lks
Hallo,
Mit PHY Maschine meinst du sicher das Originalsystem? Ist in dem Linux in das du von der grub-shell booten kannst auch das efi-Verzeichnis gemountet? Wenn nicht, ist der Fehler ja selbsterklärend.
Ich würde die VM von einem passenden Live-Linux-Image booten, dort dann die Filesystems der konvertierten Maschine mounten, dev+sys+proc mit nem bind-mount einhängen und dann per chroot in diese Umgebung wechseln und dort dann grub-install entsprechend ausführen.
Grüße
bloody
Mit PHY Maschine meinst du sicher das Originalsystem? Ist in dem Linux in das du von der grub-shell booten kannst auch das efi-Verzeichnis gemountet? Wenn nicht, ist der Fehler ja selbsterklärend.
Ich würde die VM von einem passenden Live-Linux-Image booten, dort dann die Filesystems der konvertierten Maschine mounten, dev+sys+proc mit nem bind-mount einhängen und dann per chroot in diese Umgebung wechseln und dort dann grub-install entsprechend ausführen.
Grüße
bloody
Zitat von @Thomas2:
Ich würde jetzt gerne einfach aus der VM heraus die GRUB Installation reparieren. Das System läuft und das darauf installierte zabbix verrichtet seinen Dienst.
Ich würde jetzt gerne einfach aus der VM heraus die GRUB Installation reparieren. Das System läuft und das darauf installierte zabbix verrichtet seinen Dienst.
Dann schaue mal in die fstab und schau, welche UUIDs für die einzelnen Filesysteme hinterlegt ist und check das gegen mit der Ausgabe von blkid., ggf. die fstab anpassen.
wenn die fstab paßt, die Filesysteme mit mount -a komplett mounten lassen.
Danach mit update-initramfs -u -k all die initrafmfs aktualisieren und mit grub-install /dev/sda grub frisch installieren lassen. dann noch ein update-grub hinterher und alles sollte gut werden.
lks
Zitat von @Thomas2:
Moin moin,
So sieht es aktuell aus.
Moin moin,
> #blkid
> /dev/sr0: UUID="2021-02-01-17-57-41-00" LABEL="Ubuntu-Server 20.04.2 LTS amd64" TYPE="iso9660" PTUUID="63fcfd05" PTTYPE="dos"
> /dev/sda1: UUID="6087-B957" TYPE="vfat" PARTLABEL="Efi System" PARTUUID="410343e8-c0e2-4dba-5846-d8119e8c8e8b"
> /dev/sda2: UUID="a2547f30-d82a-4fba-ab4a-1305cf01cf7d" TYPE="ext4" PARTLABEL="Linux Filesystem Data" PARTUUID="5ecb6d14-9993-4871-63cf-560432ab5cf9"
> /dev/sdb1: UUID="bWZB5W-7gIb-U5WB-WpLC-4ifI-zSJQ-k7f3cB" TYPE="LVM2_member" PARTLABEL="Linux Lvm" PARTUUID="3044d3af-5398-4a18-45b6-a481d2e0cfef"
> /dev/mapper/ubuntu--vg-ubuntu--lv: UUID="435a8276-8545-4a66-8646-b444748818dc" TYPE="ext4"
>
>
>
> # /etc/fstab: static file system information.
> #
> # <file system> <mount point> <type> <options> <dump> <pass>
> # / was on /dev/ubuntu-vg/ubuntu-lv during curtin installation
> /dev/disk/by-id/dm-uuid-LVM-0kDVHmwmnbcUH3jXXYjptJaGJeXfUkzmop1r7BwcuBIjt3YQz1NEdZCB1G2FkQ2j / ext4 defaults 0 0
> # /boot was on /dev/sda2 during curtin installation
> /dev/disk/by-uuid/eccde9a6-c9dc-4f39-b01a-87ed8b0ea9d6 /boot ext4 defaults 0 0
> # /boot/efi was on /dev/sda1 during curtin installation
> /dev/disk/by-uuid/F33C-4DA9 /boot/efi vfat defaults 0 0
> /swap.img none swap sw 0 0
>
So sieht es aktuell aus.
Moin,
von welchem Systme (VM oder bare-metal) sind denn diese Daten? Auf jeden Fall passen die UUIDs nicht.
Was steht denn in /proc/mounts?
lks
Es ist offensichtlich, daß die UUIDs zwar geändert wurden, aber die fstab nicht angepaßt wurde.
Die einfachste Möglichkeit wäre, die UUIDs wieder zurückzusetzen mit mlabel oder tune2fs. Alternativ kannst Du einfach die UUIDs in der fstab anpassen.
#fstab-neu
# <file system> <mount point> <type> <options> <dump> <pass>
# / was on /dev/ubuntu-vg/ubuntu-lv during curtin installation
/dev/mapper/ubuntu--vg-ubuntu--lv / ext4 defaults 0 0
# /boot was on /dev/sda2 during curtin installation
UUID=a2547f30-d82a-4fba-ab4a-1305cf01cf7d /boot ext4 defaults 0 0
# /boot/efi was on /dev/sda1 during curtin installation
UUID=6087-B957 /boot/efi vfat defaults 0 0
/swap.img none swap sw 0 0
Und danach das machen, was ich oben schon sagte:
wenn die fstab paßt, die Filesysteme mit mount -a komplett mounten lassen.
Danach mit update-initramfs -u -k all die initrafmfs aktualisieren und mit grub-install /dev/sda grub frisch installieren lassen. Dann noch ein update-grub hinterher und alles sollte gut werden.
Danach mit update-initramfs -u -k all die initrafmfs aktualisieren und mit grub-install /dev/sda grub frisch installieren lassen. Dann noch ein update-grub hinterher und alles sollte gut werden.
lks
Zitat von @Thomas2:
Hi,
wenn ich die Schritte durchführe, bekomme ich noch immer die Fehlermeldung, dass EFI nicht gefunden wird und es wurde auch kein EFI eingehangen:
Habe ich die falsche UUID für sda1 kopiert?
Hi,
wenn ich die Schritte durchführe, bekomme ich noch immer die Fehlermeldung, dass EFI nicht gefunden wird und es wurde auch kein EFI eingehangen:
> df -kh
> Filesystem Size Used Avail Use% Mounted on
> udev 3.9G 0 3.9G 0% /dev
> tmpfs 797M 1.2M 795M 1% /run
> /dev/mapper/ubuntu--vg-ubuntu--lv 138G 23G 109G 18% /
> tmpfs 3.9G 0 3.9G 0% /dev/shm
> tmpfs 5.0M 0 5.0M 0% /run/lock
> tmpfs 3.9G 0 3.9G 0% /sys/fs/cgroup
> /dev/loop1 56M 56M 0 100% /snap/core18/1997
> /dev/loop3 32M 32M 0 100% /snap/snapd/10707
> /dev/loop0 56M 56M 0 100% /snap/core18/1944
> /dev/loop2 70M 70M 0 100% /snap/lxd/19188
> /dev/loop4 33M 33M 0 100% /snap/snapd/11588
> /dev/loop5 71M 71M 0 100% /snap/lxd/19647
> tmpfs 797M 0 797M 0% /run/user/1000
> /dev/sda2 984M 295M 623M 33% /boot
>
> angepasste fstab:
> # / was on /dev/ubuntu-vg/ubuntu-lv during curtin installation
> /dev/disk/by-id/dm-uuid-LVM-0kDVHmwmnbcUH3jXXYjptJaGJeXfUkzmop1r7BwcuBIjt3YQz1NEdZCB1G2FkQ2j / ext4 defaults 0 0
> # /boot was on /dev/sda2 during curtin installation
> /dev/disk/by-uuid/a2547f30-d82a-4fba-ab4a-1305cf01cf7d /boot ext4 defaults 0 0
> # /boot/efi was on /dev/sda1 during curtin installation
> /dev/disk/by-uuid/6087-B957 /boot/efi vfat defaults 0 0
> /swap.img none swap sw 0 0
>
Habe ich die falsche UUID für sda1 kopiert?
Nimm mal statt der Notation /dev/disk/by-uuid /xxx die version aus meinem Vorschlag mit UUID=xxxx.
Dann machst Du ein mount /boot und amnschließend ein mount /boot/efi und falls eine fehlermeldug kommt, postest Du diese hier.
lks
Zitat von @Thomas2:
@Lochkartenstanzer
Habe ich probiert, das gleiche Ergebnis. Keine Fehlermeldung beim Mounten und es ändert die Ausgabe nicht.
@Lochkartenstanzer
Habe ich probiert, das gleiche Ergebnis. Keine Fehlermeldung beim Mounten und es ändert die Ausgabe nicht.
Existiert das verzeichnis /boot/efi denn?
lks