staging.inyokaproject.org

Hi!

Folgende Ausgangssituation: Zwei SATA-SSDs im btrfs-Verbund sollen unter Ubuntu 22.10 auf einem UEFI-Motherboard durch eine M2-NVME-SSD ersetzt werden.

Dafür habe ich die M2-SSD erst einmal hardwaremäßig ins System integriert. Klar! Dann überlegt: Von der M2-SSD soll ja am Ende gebootet werden. Die Partitionierung mit UEFI blick' ich nicht. Also habe ich kurzerhand erst einmal die alten SSDs abgehängt und per USB-Stick ein weiteres Ubuntu 22.10 auf die neue M2-SSD installiert. So habe ich schon einmal eine hübsche default-Partitionsstruktur mit dem UEFI-Gedöns (die ersten zwei Partitionen), Ubuntu (auf der 3. Partition) und einer swap-Partition.

Danach alte SSDs wieder aktiviert und mit denen gebootet. Eine davon hat die gleiche Boot-Struktur mit dem UEFI-Gedöns, nur halt mit anderem Größenvolumen. Unter Zuhilfenahme dieser Seite: https://wiki.debianforum.de/Btrfs#System_umziehen habe ich dann das Dateisystem der 3. Partition auf der neuen M2-SSD gelöscht und mittels

1

btrfs replace start /dev/sdb3 /dev/nvme0n1p3 /

die alte Systempartition der einen alten SSD auf die neue übertragen. Die eine alte SSD ist jetzt also aus dem btrfs-Verbund verschwunden und durch die neue ersetzt worden. Per

1

btrfs filesystem resize 1:max /

wird der maximale Platz auf der neuen M2-SSD verfügbar gemacht.

Jetzt müssen noch die Daten von der zweiten alten SSD auf die neue M2-SSD übertragen werden. Dies geschieht durch:

1

btrfs device remove /dev/sda1 /

Der Verbund ist nun kein Verbund mehr. Das gesamte System und alle Daten sind auf die neue M2-SSD migriert worden.

Jetzt heißt es in der Anleitung noch, dass die UUIDs in der /etc/fstab angepasst werden müssen. Das ging problemlos. Eine /etc/initramfs-tools/conf.d/resume gibt es in Ubuntu 22.10 nicht, daher habe ich in der initramfs.conf die Variable RESUME eingefügt und mit /dev/nvme0n1p3 gleich gesetzt. Das Problem: Zum Abschluss die Befehle

1
2

update-initramfs -u -k all
grub-install /dev/nvme0n1

auszuführen, bringt nicht den gewünschten Erfolg. (Unsicher, ob ich bereits /dev/nvme0 ausprobiert habe, ich meine, es hat auch nicht funktioniert.) Ich kann (noch) nicht direkt von der M2-SSD booten. Versuche ich das, lande ich ohne Fehlermeldung in einer grub-Konsole. Nach wie vor benötige ich die Ursprungs-SSD mit Ihrer Boot-Infrastruktur, obwohl alle relevanten Daten bereits auf der neuen M2-SSD liegen. Boote ich von der alten SSD, hilft ein "update-grub" allerdings auch nichts, weil lediglich die alten Strukturen aktualisiert werden.

Kann mir jemand helfen, meinen Umzug zu vervollständigen?

Moin,

mitscherdinger schrieb:

Die Partitionierung mit UEFI blick' ich nicht.

ist eigentlich ganz einfach. Partitionstabelle "gpt" nehmen. Man benötigt eine Partition mehr als beim alten Legacy-Boot-Verfahren - die EFI-Partition halt. Diese sollte...

• ~100MB groß sein (das ist mehr als großzügig bemessen, also bloss nicht größer werden)

• Fat32 oder Fat16 formatiert sein

• Als EFI-Partition gekenzeichnet sein. Bei Gparted braucht man dafür lediglich die Markierungen "Boot" und "ESP" zu setzen. Bei anderen Tools muss man halt die Paritions-GUID "c12a7328-f81f-11d2-ba4b-00a0c93ec93b" setzen bzw. bei gdisk den Partitionscode "ef00"

Das Problem: Zum Abschluss die Befehle

1 2	update-initramfs -u -k all grub-install /dev/nvme0n1

auszuführen, bringt nicht den gewünschten Erfolg.

Dass funktioniert so auch nur für das Legacy-Boot verfahren. Für EFI muss die Chroot-Methode verwendet werden, um grub nach zu installieren. Zudem gibt man bei der Grub-Installation die Festplatte nicht mehr an (der Bootloader wird ja auf die gemountete EFI-Partition geschrieben).

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

# Rootsystem nach /mnt mounten:
sudo mount -o subvol=@ /dev/nvme0n1p3 /mnt

# EFI-Partition nach /mnt/boot/efi mounten (ggfs. anpassen, falls die EFI-Partition auf /dev/nvme0n1p2 liegt)
sudo mount /dev/nvme0n1p1 /mnt/boot/efi

# Geräte, Treiber usw. bereitstellen
for item in /dev /dev/pts /sys /proc /etc/hostname /etc/hosts;do sudo mount --bind $item /mnt$item;done

# Wechsel ins System
sudo chroot /mnt /bin/bash

# grub installieren
grub-install

Gruß Thomas

TK87 schrieb:

Für EFI muss die Chroot-Methode verwendet werden, um grub nach zu installieren. Zudem gibt man bei der Grub-Installation die Festplatte nicht mehr an (der Bootloader wird ja auf die gemountete EFI-Partition geschrieben).

1 2 3 4 5 6 7 8 9 10 11 12 13 14

# Rootsystem nach /mnt mounten: sudo mount -o subvol=@ /dev/nvme0n1p3 /mnt # EFI-Partition nach /mnt/boot/efi mounten (ggfs. anpassen, falls die EFI-Partition auf /dev/nvme0n1p2 liegt) sudo mount /dev/nvme0n1p1 /mnt/boot/efi # Geräte, Treiber usw. bereitstellen for item in /dev /dev/pts /sys /proc /etc/hostname /etc/hosts;do sudo mount --bind $item /mnt$item;done # Wechsel ins System sudo chroot /mnt /bin/bash # grub installieren grub-install

Gruß Thomas

Für den Part brauche ich ein Rescue-System, auf dem die m2-SSD noch nicht eingehängt ist, richtig?

Für den Part brauche ich ein Rescue-System, auf dem die m2-SSD noch nicht eingehängt ist, richtig?

Ja. Entweder per Live-System oder falls das System auf der anderen Festplatte sich noch booten lässt, geht das auch von dort aus.

Gruß Thomas

Alles nachvollzogen, bis auf die letzte Zeile. Da gibt Ubuntu aus:

1
2
3

root@ubuntu:/# grub-install
i386-pc wird für Ihre Plattform installiert
grub.install: Fehler: Kein Installationsgerät angegeben.

Bin mir unsicher, ob ich da jetzt nvme0, nvme0n1, nvme0n1p2 (EFI-Partition) oder nvme0n1p3 (zukünftige root-Partition) angeben muss…

mitscherdinger schrieb:

Alles nachvollzogen, bis auf die letzte Zeile. Da gibt Ubuntu aus:

root@ubuntu:/# grub-install
i386-pc wird für Ihre Plattform installiert
grub.install: Fehler: Kein Installationsgerät angegeben.

Du hast das Live-System per Legacy gebootet, das ist der Fehler. Am besten deaktivierst du den Legacy-Support im UEFI/Bios komplett, damit es zukünftig nicht mehr zu solchen Problemen kommt.

Falls du noch im Chroot drin bist, kannst du mal folgendes versuchen:

1

grub-install --target=x86_64-efi --efi-directory=/boot/efi

Ansonsten noch mal explizit mit der Boot-Option (U)EFI starten.

1
2
3
4
5

root@ubuntu:/# grub-install --target=x86_64-efi --efi-directory=/boot/efi
x86_64-efi wird für Ihre Plattform installiert.
grub-install: Achtung: EFI variables cannot be set on this system.
grub-install: Achtung: You will have to complete the GRUB setup manually.
Installation beendet. Keine Fehler aufgetreten.

Mmh! Kann man so nicht stehen lassen. Oder?

mitscherdinger schrieb:

Mmh! Kann man so nicht stehen lassen. Oder?

Doch, sollte funktioniert haben. Die Meldungen sind bei btrfs normal.

Gruß Thomas

TK87 schrieb:

Die Meldungen sind bei btrfs normal.

Tatsache!

Voll cool! Danke! Sehr kompetente Unterstützung!

Nur noch 'ne Kleinigkeit: Beim Hochfahren zeigt Ubuntu nun jedes mal an, dass man die Festplattenüberprüfung mittels "Strg+C" unterbrechen könnte. Das kam bei mir früher deutlich seltener - konnte man ja in der /etc/fstab grob einstellen. Ich nehme an, da geht btrfs auch andere Wege…?

mitscherdinger schrieb:

Beim Hochfahren zeigt Ubuntu nun jedes mal an, dass man die Festplattenüberprüfung mittels "Strg+C" unterbrechen könnte. Das kam bei mir früher deutlich seltener - konnte man ja in der /etc/fstab grob einstellen. Ich nehme an, da geht btrfs auch andere Wege…?

Kann ich gerade leider auch nicht sagen - habe schon lange kein btrfs mehr genutzt.

Ich werde es mal testen, wenn ich heute Abend Zuhause bin.

Gruß Thomas

Moin,

diese Überprüfungen scheinen bei btrfs ohnehin unnötig zu sein.

Ändere in der "/etc/default/grub" folgende Zeile so ab:

GRUB_CMDLINE_LINUX_DEFAULT="fsck.mode=skip quiet splash"

und mache anschließend ein

1

sudo update-grub

Gruß Thomas

TK87 schrieb:

• ~100MB groß sein (das ist mehr als großzügig bemessen, also bloss nicht größer werden)

Das möchte ich mal infrage stellen. Je nachdem, was man da so speichert, kann es schnell auch mal etwas mehr sein. Bei ca. 10 Cent pro GiB NVME-Speicher würde ich mir da glatt was zwischen 5 und 10 Cents gönnen 😉. Im Nachhinein vergrößern ist dann nämlich sehr schwer.

Thomas_Do schrieb:

Das möchte ich mal infrage stellen. Je nachdem, was man da so speichert, kann es schnell auch mal etwas mehr sein.

Klar, wenn man seine Urlaubsfotos da ablegen will, werden die 100MB natürlich schnell knapp 😉.

Auf eine EFI-Partition gehören eigentlich nur die EFI-Loader - selbst bei einem Multiboot von 1x Grub & 2x Windows-Loader bleibt noch locker genug Platzt für 5 weitere Grub's oder 1 weiteres Windows (wofür auch immer mehr als ein Grub gut sein sollte).

Gruß Thomas

TK87 schrieb:

Auf eine EFI-Partition gehören eigentlich nur die EFI-Loader - selbst bei einem Multiboot von 1x Grub & 2x Windows-Loader bleibt noch locker genug Platzt für 5 weitere Grub's oder 1 weiteres Windows (wofür auch immer mehr als ein Grub gut sein sollte).

Ich bin kein Freund der „reinen Lehre“, sondern ein Mensch der Praxis. Und ich sehe immer wieder Leute, die Probleme mit zu kleiner ESP haben. Im Arch-Wiki werden deshalb z.B. min. 300 MiB besser 1 GiB empfohlen, um auf der sicheren Seite zu sein. Und ich sehe keinerlei Grund hier "geizig" zu sein. Aber jeder, wie er mag.

Thomas_Do schrieb:

Im Arch-Wiki werden deshalb z.B. min. 300 MiB besser 1 GiB empfohlen, um auf der sicheren Seite zu sein.

Arch-Linux geht standardmäßig auch einen ganz anderen Weg als Debian / Ubuntu.

Die Anleitungen im Arch sehen vor, dass die EFI-Partition direkt nach /boot gemountet werden soll (und nicht nach /boot/efi, wie bei Debian/Ubuntu). Das hat zur Folge, dass in dem Fall auch die Kernelimages mit auf die EFI-Partition geschrieben werden - ich mache es im übrigen auch im Arch nach dem Debian Vorbild.

Gruß Thomas