[gelöst] Boot-SSD-Tausch mit GPT/UEFI: Vorgehen?

[hikaru]

Hallo,

bei mir steht ein SSD-Tausch an. Nachdem ich mich damit letztes Jahr auf einem anderen Gerät mit zickigem UEFI schwer tat [1] und ich eigentlich immer noch nicht wirklich weiß, wie man das bei UEFI-Systemen sauber macht, frage ich lieber vorher nach, statt tagelang rumzuprobieren und dann diesen Thread zu eröffnen.

Ausgangslage:
Ich habe ein Notebook mit M.2-SATA-SSD. Darauf läuft lediglich eine Buster-Installation, wobei das UEFI ohne Secure Boot Grub2 lädt, welches wiederum Debian startet. Das soll auch so bleiben. Bei der ursprünglichen Installation über den Installer traten keine UEFI-Probleme auf.
Die alte SSD soll durch eine Größere ersetzt werden. Dazu habe ich einen M.2-USB-Adaper und einen USB-Stick mit einem Ubuntu-Live-System.

Vorgehen:
1. Ich erstelle die Partitionen auf der neuen SSD nach Muster der Alten. Insbesondere achte ich darauf, dass die EFI-Partition den Code "EF00" hat.
2. Kopieren der Daten mittels rsync
3. Anpassen der Partitions-UUIDs in fstab und grub.cfg
4. chroot in das System auf der neuen SSD
5. update-grub

Reicht das schon oder gibt es noch ein 6. und 7., um die neue SSD bootfähig zu machen? grub-install ist hier meinem "Kenntnisstand" nach nicht mehr angesagt.
Für mich ist unklar, ob ich die neue SSD noch irgendwie im UEFI "registrieren" muss (auf UEFI- oder Debian-Seite). Problemlos startende angestöpselte UEFI-USB-Sticks lassen das nicht vermuten.


[1] viewtopic.php?f=12&t=170441

[kalle123]

Hab schon mehrfach EFI Systeme mit Clonezilla kopiert. Bisher keine Probleme. Teste natürlich das Ziel, bevor ich die Quelle gelöscht habe ....

Gruß KH

[OrangeJuice]

Ich habe auch mit Clonezilla/Gnome Laufwerke(Disks) teilverschlüsselte SSDs mit Linux und Windows auf eine gleichgroße SSD übertragen. Klappte einwandfrei ohne Anpassungen. Allerdings mit MBR, ohne EFI Partition. Es sollte dort aber auch gehen. Die Partitionen könntest du später noch vergrößern oder anpassen.

[hikaru]

Mit Clonezilla hatte ich es letztes Jahr probiert. Das funktionierte nicht, mag aber an dem zickigen UEFI des anderen Notebooks gelegen haben.
Natürlich könnte ich die SSD auch mit Clonezilla umziehen (falls es funktioniert). Aber das ist ja eher eine Black Box und ich wüsste perspektivisch schon gern, was ich da tue - zumal ja Clonezilla sicher auch nichts anderes tut, als ich es zu Fuß machen würde.

[ottonormal]

Unabhängig von EFI oder MBR lässt sich die komlette alte SSD doch einfach mit dd auf die neue klonen. Ich habe das, allerdings auch mit MBR, schon mehrfach praktiziert:

Code: Alles auswählen

dd if=/dev/sda of=/dev/sdb bs=4K

Das dauert auch nicht soo lange wie immer behauptet wird. Eine 500GB-SSD auf ein 1TB-SSD brauchte bei mir nur ca. eine Stunde.

[smutbert]

Also ich meine die Vorgehensweise, die du im Eröffnungspost beschrieben hast, sollte funktionieren. Ich möchte nur ein paar Ergänzungen machen:

Ich denke es ist nicht unüblich, dass nicht-funktionierende Booteinträge vom uefi automatisch entfernt werden. Wenn du das Live-System bootest, dann ist die interne SSD ja noch leer.
Ich würde also nach der Kopieraktion in chroot sicherheitshalber auch den Booteintrag noch einmal verlässlich neu erstellen lassen, dh zusätzlich zum update-grub auch noch ein grub-install ausführen.

Damit das Anlegen des Booteintrages aber klappt, muss das Livesystem im UEFI-Modus gebootet werden, damit auf die EFI-Variablen zugegriffen werden kann.

Ein weiterer Grund weshalb ich ein grub-install empfehlen würde, ist, dass grub bei mir – ohne dass ich nachvollziehen könnte woran genau das liegt – gelegentlich schon nach der kleinsten Änderung an der Parittionstabelle nur mehr im rescue-Modus gestartet ist.
Außerdem hat grub eine eingebettete Konfiguration mit den UUIDs, dank der er das Dateisystem findet auf dem /boot/grub liegt, damit der die grub.cfg lesen und Module nachladen kann.



Solltest dir kein Live-System zur Verfügung stehen, das im uefi-Modus bootet, kannst du trotzdem noch so vorgehen und dafür sorgen, dass das System auch ohne Booteintrag bootet indem du auf der EFI System Partition das frisch erstellte grub-Image von EFI/debian/grubx64.efi nach EFI/boot/bootx64.efi kopierst.
Nach dem ersten Boot kannst du dann noch einmal grub-install aufrufen, damit der Booteintrag erstellt wird und kannst die vorher erstellte grub-Kopie wieder löschen.

[hikaru]

Danke erstmal für die Rückmeldungen! Die neue SSD ist vorerst "Lost in Post". Das zieht sich also noch etwas.

Unabhängig von EFI oder MBR lässt sich die komlette alte SSD doch einfach mit dd auf die neue klonen. Ich habe das, allerdings auch mit MBR, schon mehrfach praktiziert:

Code: Alles auswählen

dd if=/dev/sda of=/dev/sdb bs=4K

Das dachte ich früher auch. Auf meinem zickigen Acer mit UEFI führte das aber nicht zum Ziel - warum auch immer.

Das dauert auch nicht soo lange wie immer behauptet wird. Eine 500GB-SSD auf ein 1TB-SSD brauchte bei mir nur ca. eine Stunde.

Ich find's trotzdem konzeptuell hässlich, eine weitgehend leere SSD nutzlos mit "Nichts" zu füllen. Außerdem müsste ich mich dann ja immer noch um den GPT-Header am Ende der Partitionstabelle kümmern.

Also ich meine die Vorgehensweise, die du im Eröffnungspost beschrieben hast, sollte funktionieren.

Das klingt ermutigend. Danke!

Ich denke es ist nicht unüblich, dass nicht-funktionierende Booteinträge vom uefi automatisch entfernt werden. Wenn du das Live-System bootest, dann ist die interne SSD ja noch leer.

Auf der aktuell verbauten SSD ist schon Buster drauf.
Was die Booteinträge angeht habe ich aktuell eher den gegenteiligen Effekt. Da gibt es momentan drei Einträge:
1. Ubuntu von SSD (war auf der SSD vorinstalliert - ist jetzt formatiert und überschrieben)
2. Debian von USB (Buster - mein USB-Stick-Test)
3. Debian von SSD (Buster - aktuell instaliertes System - soll auf neue SSD geklont werden)

Offensichtliche Möglichkeiten, die Liste direkt im UEFI zu putzen sah ich nicht.

Ich würde also nach der Kopieraktion in chroot sicherheitshalber auch den Booteintrag noch einmal verlässlich neu erstellen lassen, dh zusätzlich zum update-grub auch noch ein grub-install ausführen.

Also doch!
Genau das machte uns ja letztes Jahr auf dem Acer mit Stretch so viel Kopfzerbrechen. Wenn ich dich jetzt richtig verstehe, sollte sich für mich als Anwender also im Idealfall gar nichts gegenüber einem BIOS/MBR-System ändern?

Damit das Anlegen des Booteintrages aber klappt, muss das Livesystem im UEFI-Modus gebootet werden, damit auf die EFI-Variablen zugegriffen werden kann.

Das machen sowohl das Live-Ubuntu als auch der Buster Installer offenbar von allein.

Solltest dir kein Live-System zur Verfügung stehen, das im uefi-Modus bootet, kannst du trotzdem noch so vorgehen und dafür sorgen, dass das System auch ohne Booteintrag bootet indem du auf der EFI System Partition das frisch erstellte grub-Image von EFI/debian/grubx64.efi nach EFI/boot/bootx64.efi kopierst.
Nach dem ersten Boot kannst du dann noch einmal grub-install aufrufen, damit der Booteintrag erstellt wird und kannst die vorher erstellte grub-Kopie wieder löschen.

Ich erinere mich dunkel (und mit Grauen). Ich behalt's im Hinterkopf.

[AspeLin]

Offensichtliche Möglichkeiten, die Liste direkt im UEFI zu putzen sah ich nicht.

Mit einer UEFI-Shell und dem Befehl bcfg sollte es gehen.

[smutbert]

Ich würde also nach der Kopieraktion in chroot sicherheitshalber auch den Booteintrag noch einmal verlässlich neu erstellen lassen, dh zusätzlich zum update-grub auch noch ein grub-install ausführen.

Also doch!
Genau das machte uns ja letztes Jahr auf dem Acer mit Stretch so viel Kopfzerbrechen. Wenn ich dich jetzt richtig verstehe, sollte sich für mich als Anwender also im Idealfall gar nichts gegenüber einem BIOS/MBR-System ändern?

Das Acer-Ding ist auf jeden Fall ein besonderer Problemfall. Sensibilisiert durch deinem Thread sind mir später im Netz und in der c't noch viele Tipps zum Umschiffen der Acerschen Tücken aufgefallen...

Auf so gut wie jedem anderen system geht es wahrscheinlich eh genauso wie du dir das vorstellst.

Ohne grub install stehen halt noch die alten UUIDs in der eingebetteten grub-Konfiguration, aber die ist so gestaltet, dass sie bei unveränderter Partitionreihenfolge solche Fehler verkraften sollte.

Nur warum eine geänderte Partitionstabelle bei mir schon mindestens einmal trotz unveränderter UUIDs grub lahmgelegt hat weiß ich nicht. Deshalb rate ich halt eher zur Vorsicht.
Ich starte in solchen Situationen das kopierte System, ohne jemals chrootet zu haben, von einem auf einen usb-stick installierten grub(-efi) (nicht per Menüeintrag sondern von der grub-Konsole aus) und hole das update-grub und grub-install dann vom laufenden System aus nach.

[hikaru]

Offensichtliche Möglichkeiten, die Liste direkt im UEFI zu putzen sah ich nicht.

Mit einer UEFI-Shell und dem Befehl bcfg sollte es gehen.

Ich habe eine "UEFI Shell" im Bootmenü des UEFI. Woher die kommt (bereits vorinstaliert, Überbleibsel vom gelöschten UEFI, von Debian) weiß ich nicht. Ich komme da auch in eine Shell, aber den Befehl "bcfg" kennt sie nicht.
Wichtig genug dem nachzugehen ist mir das momentan aber auch nicht. Trotzdem danke für den Hinweis!

Die SSD ist jetzt angekommen und ich habe das System umgezogen. Im Grunde lief es genau wie auf einem Legacy/MBR-System. Ich hatte nur anfangs vergessen, die EFI-Partition auf der neuen SSD in's chroot zu mounten, als ich Grub neu installierte. Nachdem ich das nachgeholt hatte lief ales problemlos.