ubuntuusers.de

Liegt vermutlich daran, das die Funktion noch relativ neu und sogar noch nicht übersetzt ist ("new UUID"). Ich werde in nächster Zeit (Wochende) versuchen beide Artikel passend umzuformulieren.

Hallo,

Ich werde in nächster Zeit (Wochende) versuchen beide Artikel passend umzuformulieren.

Ok. Bitte zuerst GParted und dann UUID. Wenn du eine Artikel in der Baustelle brauchst bitte im zugehörigen Thread melden.

Gruß, noisefloor

Das Bearbeiten hat sich jetzt leider etwas verzögert. Im Artikel GParted habe ich in der Tabelle "New UUID" hinzugefügt, und in diesem Artikel "UUIDs anzeigen" neu formuliert, da ich nicht weiß, wo ich einen entsprechenden Hinweiß platzieren soll: Wenn er unter anzeigen und unter verändern steht, dann hat man eine unsinnige Dopplung, und wenn er vor anzeigen steht wird er falsch platziert.

Hallo WIKI-Team und andre Nutzer!

Ich möchte diesen Artikel zur UUID, aus gegebenen Anlass, erweitern.

Bevor ich das dort einbringe, als Ergänzung oder als Ersatz, hätte ich gerne Eure Meinung dazu.

gruß syscon-hh

vol c: 

E0CF-1F83

sudo blkid | grep 'E0CF1F83' 

/dev/sda3: LABEL="HOME-PC-PROG" UUID="A6E0CF4AE0CF1F83" TYPE="ntfs"

Hallo,

kannst du einbauen. Geht auch ohne Baustelle, oder?

Gruß, noisefloor

noisefloor schrieb:

Geht auch ohne Baustelle, oder?

Ich denke mal - in Arbeit done!

Habe das noch mal etwas anders eingebracht - also noch mal einen Blick drauf werfen.

gruß syscon-hh

Hallo,

Danke für die Ergänzung ☺

Gruß, noisefloor

Hi, danke für die ergänzung, hier passt es perfekt.

LG

Jetzt Baustelle zur Beseitigung zahlreicher sprachlichen und technischer Ungenauigkeiten und besserer Strukturierung des Artikels.

kB schrieb:

Jetzt Baustelle […]

Ich bin fertig und stelle meine Überarbeitung zur Diskussion.

Hallo kB,

schöne Überarbeitung! Eine Frage habe ich zum Abschnitt Baustelle/UUID (Abschnitt „UUIDs-von-Partitionen-aendern“):

Nach einer Festplattenspiegelung muss man sowieso als ersten Schritt bei der Kopie mit gdisk die Partitionstabelle (GPT) reparieren, weil deren Backup-Teil auf dem Datenträger an der falschen Stelle liegt.

Ist das wirklich auch so, wenn Original und Klon die identische Größe haben? Ich habe jetzt schon länger keine Platte mehr geklont, dachte aber, dass Problem bestünde beim Klonen auf Datenträger anderer Kapazität. In der UEFI-Spezifikation unter Abschnitt 5.3.1 - GPT-Overview heißt es dazu:

...The primary GPT Header must be located in LBA 1 (i.e., the second logical block), and the backup GPT Header must be located in the last LBA of the device.

Die eigentliche GPT liegt dann beim original im Anschluss an den Header, beim Backup vor dem Backup-Header umgekehrt, sozusagen gespiegelt.

Wenn man jetzt blockweise klont, dann müsste doch bei identischer Datenträgergröße, am Ende alles wieder passen, oder habe ich einen Denkfehler?

Außerdem würde ich im Anschluss statt "sollte" den Begriff "kann" verwenden. Also:

Bei dieser Gelegenheit kann man auch den GUID des Datenträgers und die UUIDs aller Partitionen auf neue zufällige Werte setzen.

Denn vielleicht möchte man ja gerade einen 1:1-Klon als Backup.

Im übernächsten Absatz muss es dann statt

Bei einem mit dem DOS/MBR-Schema partitionierten Datenträger ist ggf. in einer Kopie sinnvoll, den VSN im MBR zu ändern.

IMO

Bei einem mit dem DOS/MBR-Schema partitionierten Datenträger ist ggf. in einer Kopie sinnvoll, die VSN im MBR zu ändern.

heißen.

LG, Newubunti

Newubunti schrieb:

[…]

Nach einer Festplattenspiegelung muss man sowieso als ersten Schritt bei der Kopie mit gdisk die Partitionstabelle (GPT) reparieren, weil deren Backup-Teil auf dem Datenträger an der falschen Stelle liegt.

Ist das wirklich auch so, wenn Original und Klon die identische Größe haben?

In diesem Sonderfall ist in der Tat keine Reparatur der GPT-Strukturen erforderlich und wäre auch nicht sinnvoll.

[…] Außerdem würde ich im Anschluss statt "sollte" den Begriff "kann" verwenden. Also:

Bei dieser Gelegenheit kann man auch den GUID des Datenträgers und die UUIDs aller Partitionen auf neue zufällige Werte setzen.

Nein. Mit „kann“ formuliert man neutrale Anforderungen, deren Be- oder Missachtung keinerlei negativen Auswirkungen haben kann. Im konkreten Fall Hier würde aber ein Verzicht auf die Maßnahme zum Datenverlust führen können. Deshalb ist hier eine durch „sollte“ bewertete dringende Empfehlung auszusprechen. Ein dringende Empfehlung per „sollte“ ist im Gegensatz zu „muss“ immer noch optional, man sollte aber eine eigene gute Begründung haben, wenn man sie nicht beachtet. (Vgl. RFC 2119, im Deutschen wohl DIN 820)

Denn vielleicht möchte man ja gerade einen 1:1-Klon als Backup.

Das wäre ja eine gute Begründung, der Anweisung mit „sollte“ doch nicht zu folgen. An dieser Stelle ist also „sollte“ richtig, „kann“ wäre falsch.

Im übernächsten Absatz muss es dann statt

Bei einem mit dem DOS/MBR-Schema partitionierten Datenträger ist ggf. in einer Kopie sinnvoll, den VSN im MBR zu ändern.

IMO

Bei einem mit dem DOS/MBR-Schema partitionierten Datenträger ist ggf. in einer Kopie sinnvoll, die VSN im MBR zu ändern.

heißen.

OK

kB schrieb:

In diesem Sonderfall ist in der Tat keine Reparatur der GPT-Strukturen erforderlich und wäre auch nicht sinnvoll.

Also dann das "muss" im ersten Satz des Absatzes wenigstens ändern in ein "häufig... muss" oder eben auch in eine "sollte", oder man benennt hier die Fälle, wann man darauf verzichten kann.

LG, Newubunti

Newubunti schrieb:

[…] oder man benennt hier die Fälle, wann man darauf verzichten kann.

Du hast zwar recht, aber ich war schneller.

kB schrieb:

Jetzt Baustelle […]

Artikel ist wieder im Wiki.