staging.inyokaproject.org

Hallo in die Runde,

(HYBRID)_ISO_IMAGE.iso finde ich beim Teil if= deutlich eindeutiger als gparted-live-1.2.0-3-amd64.iso, weil es ja auch Programm und einen Befehl gparted gibt. Aus meiner Sicht macht dieser Name nur Verwirrung.

Es ist wichtig, das es ein HYBRID.iso ist.

Nachtrag aus dem wikipedia.org Hybrid-ISO

Als Hybrid-ISO werden Images bezeichnet, die identisch sowohl auf eine CD gebrannt als auch auf einen Massenspeicher wie USB-stick aufgezogen werden können. Diese können auf beiden Datenträgern booten, indem zusätzlich zur CD-Boot-Struktur am Anfang ein Master Boot Record (bzw. eine GPT) mit passendem Bootcode vorhanden ist.

*.iso von Seite Downloads sind hybrid.

Berlin_1946 schrieb:

Hallo in die Runde,

(HYBRID)_ISO_IMAGE.iso finde ich beim Teil if= deutlich eindeutiger als gparted-live-1.2.0-3-amd64.iso, weil es ja auch Programm und einen Befehl gparted gibt. Aus meiner Sicht macht dieser Name nur Verwirrung.

Es ist wichtig, das es ein HYBRID.iso ist.

Dem stimme ich voll und ganz zu 👍

frostschutz schrieb:

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.

Genau das ist aber doch das Problem. dd auf einer gemounteten Partition zu verwenden, sollte nicht passieren, aber wenn es passiert, macht sync das Problem eher noch größer.

Aber sonst... ist das einfach Quark. Ob der Kernel die aktuelle Partitionstabelle kennt oder nicht, da passiert genau nix.

... aber eben nur, wenn keine Partition des Datenträgers gemountet ist.

Das sync kann gar keine veraltete Daten schreiben, das schreibt genau das was geschrieben worden ist genau dahin wo es dd haben wollte.

Aber was soll denn das sync bringen, im Fall, dass korrekter Weise keine Partition gemountet ist? Ich habe sie noch nie gebraucht, und habe immer korrekte Ergebnisse bekommen.

Ich finde, wenn da schon so eine exotische Option im Wiki steht, sollte da auch genau erläutert werden, wozu sie dient. Noch nicht mal unter dd (Abschnitt „Optionen“) ist sie aufgeführt.

Ansonsten sollte man bedenken, dass sync alle im System eingebundenen Partitionen betrifft, nicht nur die von dd gerade geschriebenen. Sollte man das nicht besser dem Betriebssystem überlassen, wann die Datenträger synchronisiert werden?

UlfZibis schrieb:

frostschutz schrieb:

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.

Genau das ist aber doch das Problem. dd auf einer gemounteten Partition zu verwenden, sollte nicht passieren, aber wenn es passiert, macht sync das Problem eher noch größer.

In dem Fall nicht. schollsky hat nach eigener Angabe sogar mehrmals versucht den Stick so zu beschreiben. Spätestens beim 2. Versuch kann da keine andere Partition oder Dateisystem mehr gewesen sein eigentlich. Von daher ist das unerklärlich...

Aber was soll denn das sync bringen, im Fall, dass korrekter Weise keine Partition gemountet ist?

Für den Fall daß du den Stick direkt danach abstecken willst. Bleibt er stecken brauchst du den sync nicht bzw. den bekommst du dann halt spätestens beim Reboot.

Ansonsten sollte man bedenken, dass sync alle im System eingebundenen Partitionen betrifft, nicht nur die von dd gerade geschriebenen.

Das ist dem Stick und sonst auch ja egal...

Sync ist generell völlig harmlos. Das schreibt nur was sowieso irgendwann geschrieben worden wäre. Deswegen darf das auch jeder User einfach so ausführen (im Wiki Beispiel läuft dd als sudo root und sync als Otto Normaluser).

Solange sich an dem sync Verhalten nichts geändert hat, sollte das alles funktioniert haben so.

frostschutz schrieb:

Für den Fall daß du den Stick direkt danach abstecken willst. Bleibt er stecken brauchst du den sync nicht bzw. den bekommst du dann halt spätestens beim Reboot.

Sollte man nicht dennoch den Zweck von oflag=sync hier kurz erläutern? Das Wiki soll doch dem User die Nutzung von Ubuntu erleichtern, und es ihm ersparen, sich durch die man-Dokumente zu quälen. Sonst wäre das Wiki ja komplett überflüssig, denn in man findet man immer alles und zudem genau.

Das ist dem Stick und sonst auch ja egal...

Sync ist generell völlig harmlos. Das schreibt nur was sowieso irgendwann geschrieben worden wäre. Deswegen darf das auch jeder User einfach so ausführen (im Wiki Beispiel läuft dd als sudo root und sync als Otto Normaluser).

Ja schon, aber dass nicht immer alles sofort auf den Datenträger geschrieben wird, hat ja auch seinen Sinn. Deshalb finde ich hier oflag=sync auch die bessere Variante.

UlfZibis schrieb:

Sollte man nicht dennoch den Zweck von oflag=sync hier kurz erläutern? Das Wiki soll doch dem User die Nutzung von Ubuntu erleichtern, und es ihm ersparen, sich durch die man-Dokumente zu quälen. Sonst wäre das Wiki ja komplett überflüssig, denn in man findet man immer alles und zudem genau.

😎 Dem stimme ich voll und ganz zu 👍

Nachtrag:

Auf der manpages.ubuntu.com für 20.04 habe ich nichts über oflag und oflag=sync gefunden.

aus der man dd

...
nocache
              Request to drop cache.  See also oflag=sync
...

das gelbe gibt es aber nicht in der Man- Page. Weder see noch also 😇

Hej frostschutz,

frostschutz schrieb:

... 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.

geht am schnellsten mit gdisk. Aber da ist es wieder, die "Kenntnis" des kernel ist womöglich eine andere, und nicht immer hilft da ein partprobe.

Und statt …&& rsync kann man ja auch nach dem dd in einem nächsten Schritt rsync einsetzen. Eine halbwegs brauchbare Methode ist, einfach dem System überlassen, z.B. mit Nautilus "auswerfen".

Es wäre natürlich schön, wenn sync auch so einen Schalter "status=progress" hätte, man darf nicht vergessen, das "eigentlich" Schreiben auf den Stick dauert ein vielfaches länger, als das Schreiben in den cach.

Btw., ein Blick in man sync (sync [OPTION] [FILE]...) zeigt, daß sich das syncen auf ein File beschränken läßt.

blacktencate@T520-BB:/media/blacktencate/agfa-iso/focal_2020-10-04$ sudo dd if=ubuntu-20.04.1-desktop-amd64.iso of=/dev/sde bs=1M status=progress && sync ubuntu-20.04.1-desktop-amd64.iso
[sudo] Passwort für blacktencate: 
2761949184 Bytes (2,8 GB, 2,6 GiB) kopiert, 111 s, 24,9 MB/s


2656+0 Datensätze ein
2656+0 Datensätze aus
2785017856 Bytes (2,8 GB, 2,6 GiB) kopiert, 626,741 s, 4,4 MB/s
blacktencate@T520-BB:/media/blacktencate/agfa-iso/focal_2020-10-04$ 
blacktencate@T520-BB:/media/blacktencate/agfa-iso/focal_2020-10-04$ 

der sync dauert dann noch e i n i g e Minuten.

Gruß black tencate

frostschutz schrieb:

[…] 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.

Ja. Deshalb gehört ja auch die Anweisung „vorher ausbinden“ unbedingt zur Anleitung.

Aber sonst... ist das einfach Quark.

Keineswegs!

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.

sync arbeitet auf den Puffern für die Dateisysteme, manche bevorzugen dafür den Namen Caches. dd schreibt aber direkt auf das Blockgerät unter Umgehung der Dateisystemtreiber. Damit kann sync gar nichts für dd tun. Wenn sync nach dd überhaupt etwas schreibt, dann schreibt es etwas, was nach dem Wirken von dd veraltet ist. dd auf Blockgerät und sync arbeiten unabhängig voneinander; deshalb ist eine Verkettung der beiden Befehle Unsinn. Sie bewirkt im günstigen Fall gar nichts und führt allen anderen Fällen zu Fehlern.

Die richtige Arbeitsweise ist ein Leeren der Puffer vor dem Schreiben auf das Blockgerät. Dies geschieht durch Aushängen aller Partitionen und ggf. sync vor dd, aber niemals danach!

Hallo in die Runde

Sry, was ist das jetzt mit dem Teil

... oflag=sync

?

Berlin_1946 schrieb:

Hallo in die Runde

Sry, was ist das jetzt mit dem Teil

... oflag=sync

?

Du hast die falsche Manpage verlinkt (POSIX Version), guckst du hier https://manpages.ubuntu.com/manpages/focal/en/man1/dd.1.html

       oflag=FLAGS
[...]
       Each FLAG symbol may be:
[...]
       dsync  use synchronized I/O for data

       sync   likewise, but also for metadata

Das gilt für jeden Block während des gesamten Kopiervorgangs (und hier kann dann auch die Blockgröße eine Rolle spielen).

Ansonsten conv=fdatasync:

       conv=CONVS
[...]
       Each CONV symbol may be:
[...]
       fdatasync
            physically write output file data before finishing

fdatasync wäre einmal wenn dd fertig ist, also im Anschluss des Kopiervorgangs wie && sync.

kB schrieb:

dd schreibt aber direkt auf das Blockgerät unter Umgehung der Dateisystemtreiber. Damit kann sync gar nichts für dd tun.

sync macht durchaus auch Blockgeräte.

https://github.com/torvalds/linux/blob/4a0225c3d208cfa6e4550f2210ffd9114a952a81/fs/sync.c#L99-L127

Finally, we writeout all block devices

 1
 2
 3
 4
 5
 6
 7
 8
 9
10

/*
 * Sync everything. We start by waking flusher threads so that most of
 * writeback runs on all devices in parallel. Then we sync all inodes reliably
 * which effectively also waits for all flusher threads to finish doing
 * writeback. At this point all data is on disk so metadata should be stable
 * and we tell filesystems to sync their metadata via ->sync_fs() calls.
 * Finally, we writeout all block devices because some filesystems (e.g. ext2)
 * just write metadata (such as inodes or bitmaps) to block device page cache
 * and do not sync it on their own in ->sync_fs().
 */

dd auf Blockgerät und sync arbeiten unabhängig voneinander;

Wenn du in einem Terminal dd laufen lässt und in einem anderen Terminal sync ausführst (während dd noch läuft) siehst du auch daß sync auf einmal lange braucht.

Das mit sync nach dd nachzustellen ist etwas komplizierter. Nicht jedes Blockgerät läuft in dem Cachemodus wo es eine Rolle spielt. D.h. oft reicht dd auch ohne jede Sync Option aus. Aber wenn der USB2-Kartenleser mit 500 MB/Sekunde schreibt dann halt auch wieder nicht.

Hallo in die Runde,

die von frostschutz vorgeschlagene Alternative (conv=fdatasync) finde ich besser als die derzeitige (oflag=sync)

sudo dd if=(HYBRID)_ISO_IMAGE.iso of=/dev/sdX bs=4M status=progress conv=fdatasync

conv=conversion[,conversion]…’

Convert the file as specified by the conversion argument(s). (No spaces around any comma(s).)

Conversions= ‘fdatasync’ Synchronize output data just before finishing. This forces a physical write of output data.

Meine frei Übersetzung von –fdatasync: Stellt sicher, das die Synchronisierung der Ausgabedaten vor dem Abschluss erfolgt ist.– (ggf dann ins Wiki schreiben, als Erklärung)

Damit ist das Ziel erreicht, dass nichts verloren geht.

Ist conv=fdatasync eine <Optionen> oder ist es eher ein Parameter, wie im Wiki bs=4M bezeichnet wird?

Hallo zusammen,

ich verstehe es so, dass "conv" die Option ist, und dann "-fdatasync" der Parameter. Bevor das ins Wiki kommt, sollte es allerdings gründlich getestet werden, ob das auch so funktioniert wie beschrieben.

Grüße

schollsky

Hej,

imho reicht ein simples

sudo dd if=HYBRID_ISO_IMAGE.iso of=/dev/sdX

• optional

  1. bs=…

  2. stautus=progress

Begründung: Der Befehl (wie oben) schreibt, wie gewünscht, ein (Hybrid)*.iso file auf einen Datenträger. Wenn das abgeschlossen ist, meldet sich das Terminal mit dem prompt zurück. Dann "hat es auch fertig"!

Die Option bs= kann Geschwindigkeitsvorteile bringen, status= halte ich für überflüssig, da nach dem "relativ" schnellen 'Schreiben' der Datensätze eine sehr viel längere Zeit – ohne jede 'Regeung/Anzeige im Terminal – vergeht, bis sich der prompt als Abschluß der Aktion zurückmeldet.

Gruß black tencate

black_tencate schrieb:

imho reicht ein simples

sudo dd if=HYBRID_ISO_IMAGE.iso of=/dev/sdX

Bin genau deiner Meinung, den Rest in der Befehlszeile ersatzlos in den "Eimer". Der o.g. Befehl reicht völlig.

Wenn kein massiver Protest kommt, mache ich das morgen. 😲

Berlin_1946 schrieb:

Bin genau deiner Meinung, den Rest in der Befehlszeile ersatzlos in den "Eimer". Der o.g. Befehl reicht völlig.

Wie schon oben beschrieben, das reicht eben NICHT in allen Fällen.

schollsky schrieb:

Berlin_1946 schrieb:

Bin genau deiner Meinung, den Rest in der Befehlszeile ersatzlos in den "Eimer". Der o.g. Befehl reicht völlig.

Wie schon oben beschrieben, das reicht eben NICHT in allen Fällen.

meinst du das?

schollsky schrieb:

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.

Ich kann leider nicht erkennen, was bei dir genau nicht funktioniert hat. Hast du es auch mal mit einem (HYBRID)_ISO_IMAGE.iso von Ubuntuusers versucht.

Was ist jetzt genau der Fall in dem es NICHT ausreicht.

Meine USB-Live-Sticks haben gemäß den Wiki- Befehl immer funktioniert.

mit gleichem (fehlerhaften) Ergebnis.

Wie sieht dein fehlerhaftes Ergebnis aus? Terminaltbefehl oder Screenshot kann ggf helfen. 😇