[Ubuntu 22.04.3 LTS] UUID von Dateisystem ändern

[Mr.Seymour Buds]

Ich habe mit dd einen Datenträger geklont. Dies hat auch gut funktioniert. Nun will ich die UUID verändern, wie es bei geklonten Datenträgern empfohlen wird. Dazu habe ich mich an die Anweisungen von ubuntuusers.de gehalten.

Das Problem ist nun, dass sich die UUID nicht verändert hat.

sudo tune2fs -U random /dev/nvme0n1p2

meldet

tune2fs 1.46.5
Das Journal wird wiederhergestellt.
Bitte lassen sie e2fsck f- dieses Dateisystem überprüfen

(e2fsck gibt mir zwei Fehler aus für das ext4 von nvme0n1p2: Blockzahl falsch und Inodes Count falsch. (das ist aber weiterhin nicht tragisch, denke ich mal).)

Lasse ich mir nun die UUID meiner Block Devices ausgeben:

sudo blkid

sehe ich wieder die gleichen, unveränderten UUIDs vom Quelle und Ziel Datenträger. Eigentlich sollte ja nun die UUID von nvme0n1p2 eine randomisierte UUID sein? Was mache ich falsch?

Darüber hinaus lässt sich die UUID von "EFI System Partition" (geklonte Bootpartition) überhaupt nicht ändern, weil das Dateisystem vFat von tune2fs nicht geändert werden kann. Wie soll ich hier die UUID ändern?

 

[0x8100]

war das ziel auch wirklich mindestens gleich gross oder grösser als die quelle (meckert cfdisk /dev/nvme0n1 eine falsche partitionsgrösse an?)? du solltest auf jeden fall e2fsck -f /dev/nvme0n1p2 ausführen. die uuid der dateisysteme brauchst du nur ändern, falls beide datenträger und deren dateisysteme gleichzeitig in einem rechner laufen. das ist ja typischerweise nicht der fall, wenn man einen klon erstellt hat.

 

[Evil E-Lex]

(e2fsck gibt mir zwei Fehler aus für das ext4 von nvme0n1p2: Blockzahl falsch und Inodes Count falsch. (das ist aber weiterhin nicht tragisch, denke ich mal).)

Das sollte e2fsck automatisch reparieren. Poste mal bitte die Ausgabe von dem Befehl, den du ausgeführt hast.

Darüber hinaus lässt sich die UUID von "EFI System Partition" (geklonte Bootpartition) überhaupt nicht ändern, weil das Dateisystem vFat von tune2fs nicht geändert werden kann. Wie soll ich hier die UUID ändern?

Das steht doch in deinem verlinkten Artikel. Die einfachste Variante dürfte gdisk oder sgdisk sein.

 

[Mr.Seymour Buds]

@0x8100 , die beiden Datenträger, eine alte SATA SSD (500GB) und eine neue NVMe SSD (2TB) sind gerade im gleichen System verbaut. Deswegen möchte ich die UUID ändern. Wenn der Klonprozess 100% funktioniert hat, wird die 500GB SATA SSD formatiert.

@Evil E-Lex , Befehl war

sudo e2fsck -f /dev/nvme0n1p2

Ausgabe:

e2fsck 1.46.5 (30-Dec-2021)
/dev/nvme0n1p2: Journal wird wiederhergestellt
Wird bereinigt verwaister Inode (uid=1000, gid=1000, mode=0100664, size=32768)
Wird bereinigt verwaister Inode (uid=1000, gid=1000, mode=0100600, size=64)
Durchgang 1: Inodes, Blöcke und Größen werden geprüft
Durchgang 2: Verzeichnisstruktur wird geprüft
Durchgang 3: Verzeichnisverknüpfungen werden geprüft
Durchgang 4: Referenzzähler werden überprüft
Durchgang 5: Zusammengefasste Gruppeninformation wird geprüft
Die Anzahl freier Blöcke ist falsch (111839996, gezählt=111839669).
Reparieren<jy>? nein
Die Anzahl freier Inodes ist falsch (30147701, gezählt=30147650).
Reparieren<jy>? nein

/dev/nvme0n1p2: ***** DATEISYSTEM WURDE VERÄNDERT *****
/dev/nvme0n1p2: 351115/30498816 Dateien (0.6% nicht zusammenhängend), 10125060/121965056 Blöcke

(ich habe erstmal keine Reparatur durchführen lassen, weil ich nicht wusste, wie lange es dauert und ob es nun einen so großen Unterschied macht).


gdisk und sgdisk sehe ich mir an (kenne ich bisher nicht).

 

[Evil E-Lex]

"Ja" statt "nein" auswählen hilft.

 

[Mr.Seymour Buds]

Für die Blockzahl und den InodesCount. Da hast Du recht. Aber darum geht es hier eigentlich gerade gar nicht.

Ich möchte ja wissen, warum die UUID durch tune2fs nicht verändert worden ist.

 

[Evil E-Lex]

Weil dein Dateisystem Fehler aufweist, die du nicht reparierst indem du "Nein" auswählst. Meine Güte!

 

[Mr.Seymour Buds]

Warum sollte ich dann die UUID nicht umbennen können? Für mein besseres Verständnis: Selbst wenn dort Fehler drin sind, wo ist dort der Zusammenhang? Die UUID ist ja nur eine eindeutige Bezeichnung für eine Partition.

 

[Evil E-Lex]

Alter! Mach was die Befehle dir sagen, oder lass es. Das Dateisystem ist korrupt, das fasst tune2fs nicht an, es sei denn du gibst da auch -f mit.

 

[Donnerkind]

Warum sollte ich dann die UUID nicht umbennen können?

Das ist halt ein Sicherheitsfeature, damit sich der Nutzer nicht ins Bein schießt. Es kann ja sonst was kaputt sein, das wird in dem Moment nicht geprüft. Und diese Prüfung wird auch nicht nur beim Ändern der UUID gemacht, sondern z.B. auch beim Ändern der Größe des Dateisystems. Und da willst du schlicht keine Fehler drin haben.

 

[Mr.Seymour Buds]

@Evil E-Lex , #9, ich bin bei allen Befehlen, die ich benutze, prinzipiell eher vorsichtig. Warum sollte ich etwas reparieren lassen, wenn es vielleicht auch - erstmal - so geht? Ich benutze dd nicht so häufig. Außerdem ist es im Allgemeinen so, dass Reparaturversuche auch Dinge schlechter machen können (das ist hier aber nicht der Fall).

@Donnerkind, ok!

Ich habe für nvme0n1p2 nun gparted benutzt, und dort lief alles ohne Probleme. Die neue UUID konnte erstellt werden. Es gab auch keine Fehlermeldungen und ich habe auf volle Kapazität erweitert (nach dem Klonen waren es nur die 500GB, wie zu erwarten). gparted konnte die UUID von nvme0n1p1 (EFI Boot Partition) nicht ändern (Feld ausgegraut).
Danach habe ich versucht, die vfat Partition umzubenennen, was aber zu größeren Schwierigkeiten geführt hat. mlabel (aus dem mtools Paket) hat den Dienst verweigert, ich konnte die UUID nicht ändern. Genauer gesagt, konnte ich die UUID nicht ändern, weil vfat keine UUID kennt, sondern nur eine GUID und Seriennummer? Auf einigen Ubuntu Seiten konnte ich dann aber lesen, dass ein Ändern dieser Seriennummer wie eine Änderung der UUID wirken würde. Als nächstes habe ich sgdisk probiert:

sudo sgdisk -u 1:7317-EC8D /dev/nvme0n1

angewendet. Das hat auch endlich mal irgendwas gemacht. Mit sudo blkid konnte ich nun auch eine andere Seriennummer? auf dem Datenträger feststellen. Endlich auf allen Partitionen eindeutige Nummern!
Beim Versuch diesen dd Klone nun zu starten, kam ich leider nicht weiter, als zur GRUB Kommandozeile. Dort habe ich dann aufgegeben, weil ich die Partionen nicht mehr zuordnen konnte und der Kernel nicht laden wollte. Damit ist die Klone-Aktion (für heute) erstmal beendet.

Warum wird dieses seltsame - und veraltete - vfat überhaupt noch benutzt und nicht gleich ext4 auf allen Partitionen?

 

[andy_m4]

Warum sollte ich etwas reparieren lassen, wenn es vielleicht auch - erstmal - so geht?

Naja. Wenns Inkonsistenzen im Dateisystem geben sollte, ist das erst mal schlecht. Selbst wenn es funktioniert. Aber genauso wie eine Reparatur Sachen schlimmer machen kann, kann auch auf einem kaputten Filesystem weiter zu arbeiten Folgefehler nachsich ziehen.
Es ist also so oder so angebracht den Fehler gerade zu ziehen.
Um ein Sicherheitsnetz zu haben falls was schief geht, sollte man im jeden Fall ein Backup haben.

Mal davon abgesehen, das ich für Dein Vorhaben (also Systemumzug auf neue Platte) Klonen nicht als die optimale Vorgehensweise ansehe.

Warum wird dieses seltsame - und veraltete - vfat überhaupt noch benutzt und nicht gleich ext4 auf allen Partitionen?

Das ist eine Vorgabe, die das UEFI macht. UEFI kann nur von vFAT lesen. Und ja. Das Dateisystem ist veraltet. Es ist aber auch sehr einfach und lässt sich gut implementieren und für die Zwecke, für die es gebraucht wird braucht man auch kein komplexes Dateisystem.

Beim Versuch diesen dd Klone nun zu starten, kam ich leider nicht weiter, als zur GRUB Kommandozeile. Dort habe ich dann aufgegeben, weil ich die Partionen nicht mehr zuordnen konnte und der Kernel nicht laden wollte. Damit ist die Klone-Aktion (für heute) erstmal beendet.

Hab ne Vermutung:
Der Loader und Kernel findet seinen Kram ja anhand der UUID (falls man das nicht anders konfiguriert hat). Da Du das aber geändert hast, stimmen die Angaben dort nicht mehr bzw. müsstest Du die dann auch nachziehen.

 

[Evil E-Lex]

Warum sollte ich etwas reparieren lassen, wenn es vielleicht auch - erstmal - so geht?

Was lässt dich glauben, das es erstmal so geht? Du vermutest nur anstatt dich an dem zu orientieren, was die Ausgaben der Befehle dir sagen.

Außerdem ist es im Allgemeinen so, dass Reparaturversuche auch Dinge schlechter machen können

Das ist schlicht Unsinn. Egal in welchen Zusammenhang.

Ich benutze dd nicht so häufig.

Mag sein, spielt für diesen Fall aber keine Rolle. dd ist hier ohnehin das falsche Tool. Entweder gleich partclone oder clonezilla nutzen, oder auf dem neuen Datenträger die Dateisysteme anlegen und die Daten einfach direkt kopieren. Dann hättest du weder das Problem mit der identischen UUID noch das defekte Dateisystem gehabt.