staging.inyokaproject.org

Das im Artikel an 2 Stellen erwähnte gdiskdump scheint nicht mehr installierbar zu sein. Ich bekomme nicht auflösbare Abhängigkeiten auf 18.04 ... schade.

Der Artikel ist wirklich sehr lang und unübersichtlich. Die meisten werden den wohl für USB Installationsmedien aufrufen. Wie wäre das Beispiel vom Ende direkt in den Abschnitt Aufruf zu verschieben?

Hallo,

wir haben unter Aufruf/Bedienung/Verwendung das in vielen Artikeln ungefähr so strukturiert, was man auch hier machen könnte:

Syntax:

dd if=IF of=OF

Beispiele:

#vorlage Befehl
(hier dein Beispiel einfügen)

ggf. weitere Beispiele

(weiß nicht ob klar ist was ich meine, tippe vom Handy aus. Ggf nochmal fragen)

Das Schöne an dem Artikel ist, dass dd quasi zeitlos ist, sonst hätten wir bei der Länge große Test-Probleme.

Falls trotzdem jemand Vorschläge zur Auslagerung in Unter-Artikel hat, bitte gerne hier melden.

Gruß BillMaier

Hallo,

Wie wäre das Beispiel vom Ende direkt in den Abschnitt Aufruf zu verschieben?

Die Reihenfolge der Beispiele ist hier im Artikel (fast) egal. IMHO spricht nichts dagegen, dass letzte Beispiel nach vorne zur schieben.

Nachtrag: erledigt

Gruß, noisefloor

Hallo zusammen,

beim Abschnitt zur Erstellung von Live-USB Versionen ist mir aufgefallen, dass noch die alte Syntax von dd angegeben ist. Das würde ich gerne anhand eines praktischen Beispiels aktualisieren. Ist aber keine große Sache. Muss dazu der Artikel in die Baustelle verschoben werden?

Grüße

schollsky

Hej schollsky,

schollsky schrieb:

...dass noch die alte Syntax von dd angegeben ist

oops, ist mir was entgangen?

Gruß black tencate

Ich habe das auch nur per Zufall entdeckt:

Mit folgendem Befehl habe ich mit mehreren USB-Sticks Live-Systeme erzeugt:

sudo dd if=(HYBRID)_ISO_IMAGE.iso of=/dev/sdX bs=1M && sync

Dabei habe musste ich feststellen, dass offensichtlich der sync-Befehl dazu führt, dass das Image nicht korrekt erzeugt wird. Ich habe es auch mit Varianten und ganz ohne sync, stattdessen mit langer Wartezeit versucht, mit gleichem (fehlerhaften) Ergebnis.

Über das Arch-Wiki bin ich dann auf die aktuell korrekte Variante gestossen:

sudo dd if=gparted-live-1.2.0-3-amd64.iso of=/dev/sdc bs=4M status=progress oflag=sync

Dies z.B. führt schnell und zuverlässig zu einem sauberen Stick.

Grüße

schollsky

Hallo,

nee, um eine Zeile auszutauschen brauchst du keine Baustelle.

Gruß, noisefloor

Gut, die Änderung ist mit einer kleinen Erläuterung eingefügt. ☺

Grüße

schollsky

Mir fällt nur kein nachvollziehbarer Grund ein, warum dd && sync nicht klappen sollte. Vermutlich irgendein anderes Problem, das da noch reingespielt hat bei dir.

Hallo in die Runde,

gparted-live-1.2.0-3-amd64.iso woher kommt diese Datei?

Bei Ubuntuusers heißen die doch je nach Derivat so oder ähnlich *buntu-xxxx-20.04-desktop-amd64.iso.

Ja, aus aktuellem Anlass (bei mir) habe ich keine Ubuntu Live Version genommen, sondern die neueste verfügbare von GParted aus dem Testing-Zweig:

https://sourceforge.net/projects/gparted/files/gparted-live-testing/

Das o.a. geschilderte Problem ist allerdings erstmalig mit einer Live-Version Ubuntu Mate 21.04 aufgetreten.

Bevor es Rückfragen gibt: Es war die finale Version von https://ubuntu-mate.org/download/

Grüße

schollsky

schollsky schrieb:

[…]

sudo dd if=(HYBRID)_ISO_IMAGE.iso of=/dev/sdX bs=1M && sync

Dabei habe musste ich feststellen, dass offensichtlich der sync-Befehl dazu führt, dass das Image nicht korrekt erzeugt wird.

Ja, das ist unter bestimmten, aber nicht ungewöhnlichen Umständen zu erwarten. Der Befehl sync ist gefährlich und kann zu Datenverlust führen, wenn das System von falschen Voraussetzungen über den Aufbau der Datenträger ausgeht!

Konkret passiert folgendes:

1. Der Kernel hat intern eine eine Kopie der Partitionstabelle von /dev/sdX und benutzt diese zum Zugriff, insbesondere auch beim Schreiben auf den Datenträger.

2. Per dd wird der Datenträger und damit auch dessen Partitionstabelle überschrieben. Der Kernel hat jetzt veraltete Daten, kann dies aber nicht erkennen.

3. Per sync leert man nun die Puffer und der Kernel schreibt veraltete Daten an veraltete Positionen auf den Datenträger. Damit wird natürlich das gerade geschriebene Image zerstört.

Richtig ist dieses Vorgehen:

1. /dev/sdX selbst und alle (!) Partitionen von diesem Datenträger aushängen.

2. Das Image mit dd (ohne sync!) schreiben.

3. Den Kernel zum erneuten Einlesen der Partitionstabelle auffordern:

   partprobe /dev/sdX 

Niemals unreflektiert sync in Kombination mit dd benutzen!

schollsky schrieb:

[…]

sudo dd if=gparted-live-1.2.0-3-amd64.iso of=/dev/sdc bs=4M status=progress oflag=sync

Dies z.B. führt schnell und zuverlässig zu einem sauberen Stick.

Aber nur durch glückliche Umstände. Tatsächlich ist die markierte Option hier Unsinn, sie macht glücklicherweise hier nichts und wenn sie etwas machen würde, dann wäre es das Falsche. Also ist sie gefährlich und sollte deshalb auf keinen Fall im Wiki empfohlen werden. Mit dieser Option werden beim Arbeiten mit unterschiedlichen Blockgrößen für Quelle und Ziel die geschriebenen Blöcke mit Füllzeichen erweitert.

Nach wie vor ist die einzige zulässige Variante bei Schreiben von Images:

sudo dd if=gparted-live-1.2.0-3-amd64.iso of=/dev/sdX status=progress 

• status=progress ist hier optional, aber zweckmäßig.

• bs=… darf nicht abgegeben werden! Wenn, dann sollte man obs angeben und der Wert muss der tatsächlichen physischen Sektorgröße des Zielgerätes entsprechen. Die kennt man in der Regel nicht. obs=512 ist die Vorgabe und immer sicher, leider langsam.

kB schrieb:

Konkret passiert folgendes:

1. Der Kernel hat intern eine eine Kopie der Partitionstabelle von /dev/sdX und benutzt diese zum Zugriff, insbesondere auch beim Schreiben auf den Datenträger.

2. Per dd wird der Datenträger und damit auch dessen Partitionstabelle überschrieben. Der Kernel hat jetzt veraltete Daten, kann dies aber nicht erkennen.

3. Per sync leert man nun die Puffer und der Kernel schreibt veraltete Daten an veraltete Positionen auf den Datenträger. Damit wird natürlich das gerade geschriebene Image zerstört.

Das wär höchstens ein Problem wenn da eine alte Partition gemountet wäre auf dem Stick und dann schreibt da irgendein altes Dateisystem irgendwas mitten rein.

Aber sonst... ist das einfach Quark. Ob der Kernel die aktuelle Partitionstabelle kennt oder nicht, da passiert genau nix. Das sync kann gar keine veraltete Daten schreiben, das schreibt genau das was geschrieben worden ist genau dahin wo es dd haben wollte.

Solange dd Daten schreibt und sonst niemand, sollte das Image am Ende auch korrekt sein. Ist das nicht der Fall dann hat man vielleicht ein USB-Problem oder fehlerhaftes RAM oder der Stick selber hat einen Schuss, aber sonst macht das einfach keinen Sinn.

Vielleicht interessant einfach mal zu schauen wo genau die Abweichung ist (mit cmp u.a. Tools).

Das was dem && sync sonst noch am nächsten käme wäre vielleicht conv=fdatasync.

Ein ganz anderes Problem ist noch die GPT-Partitionstabelle, von der es ein Backup am Ende des Datenträgers gibt, das vom dd nicht überschrieben wird. Wenn man das ganz sauber haben möchte muss man den Stick vorher mit wipefs o.ä. bearbeiten. Aber normalerweise wird das GPT-Backup hinten einfach ignoriert wenn vorne ein Image drauf ist. Und wenn das das Problem gewesen wäre hätte es der andere Befehl auch nichts daran geändert.

bs=… darf nicht abgegeben werden!

Natürlich darfst du bs=1M angeben. Die blocksize ändert am Endergebnis nichts (solange keine komischen Zusatzoptionen wie conv=sync,noerror ins Spiel kommen).