Rufus-Alternative für Linux

[Mickey Cohen]

achja, sry, sollte ich eigentlich von selbst schreiben: aktuellstes fedora, 64 bit


edit: so, mittlerweile hats geklappt. der fehler war, dd nicht durchlaufen zu lassen. das ist natürlich einerseits saudämlich, gebe ich zu, andererseits muss man aber schon auch sagen, dass die status-anzeige von dd ja wohl ein schlechter witz ist. naja und ne viertelstunde, nur um ein 1.6GB image auf einen (zugegebenermaßen langsamen usb 2.0) 4GB stick zu schreiben ist jetzt auch nicht gerade der zeitrahmen, mit dem man rechnet. unter rufus geht das wesentlich schneller.

daher meine frage: "nullt" dd den unbeschriebenen rest auf dem usb-stick durch? das wär ja schön bescheiden, weil wenn ich dieses verfahren mal mit nem 64 oder 128GB Stick machen muss, gute nacht.

 

[NJay]

oh, ok, aber das dauert bei großen sticks doch bestimmt ewig?

Das dauert genauso lange wie bei RUFUs, etcher, etc auch. Liegt einfach an der Geschwindigekeit des sticks. Er behauptet zwar, bereits 1.6 GB kopiert zu haben, aber vermutlich das meiste nur ind en RAM. Warte bis dd sich beendet hat, fuehre den befehl sync aus und warte bis der fertig ist. Dann kannst du den stick ausstecken/rebooten

 

[fixedwater]

Hm, ich hab letztens Mal ca. 20 Minuten vor Rufus gesessen, weil der 16-GB-USB-Stöpsel vom Rewe (Mutter fand den toll und hat ihn gekauft) sich nicht ausgekaspert hat - trotz USB 3 und nem Ryzen 7 2700. Man glaubt es nicht, aber die Unterschiede zwischen verschiedenen Sticks sind manchmal echt erschreckend.

 

[new Account()]

Er behauptet zwar, bereits 1.6 GB kopiert zu haben, aber vermutlich das meiste nur ind en RAM.

Nein, bei Rufus kann man direkt danach rausziehen

 

[NJay]

Nein, bei Rufus kann man direkt danach rausziehen

Es ging bei meiner antwort ja auch um dd, nicht rufus.

 

[linuxfan]

[...] und ne viertelstunde, nur um ein 1.6GB image auf einen (zugegebenermaßen langsamen usb 2.0) 4GB stick zu schreiben ist jetzt auch nicht gerade der zeitrahmen, mit dem man rechnet. unter rufus geht das wesentlich schneller.

daher meine frage: "nullt" dd den unbeschriebenen rest auf dem usb-stick durch? das wär ja schön bescheiden, weil wenn ich dieses verfahren mal mit nem 64 oder 128GB Stick machen muss, gute nacht.

Eigentlich schreibt dd ohne zusätzliche Optionen nur die Daten, die in dem Image drin sind, von Beginn des Datenträgers an und hört dann auf. D.h. z.B., wenn der Rest des USB-Sticks aus vertraulichen Daten bestand, sind sie alle noch da. Nur nicht ohne weiteres sichtbar, weil jetzt ja eine neue Partitionierung drauf ist.

 

[anarki99]

Ich stehe mit Ubuntu 20.04 vor dem selben Problem und muss den 'dd' Befehl zum Klonen meinen Nextcloudpi-Installation (miniSD-Karten Backup) einsetzen. Im Netz wird der hauptsächlich dokumentiert um ein SD Image auf die HD des Rechners als .img zu klonen.
Da hierfür aber die Kapazität der verbauten SSD nicht ausreicht möchte ich das Image auf eine Externe Festplatte (sdb - siehe unten) sichern. Sämtliche Versuche sind bislang gescheitert.
'lsblk' gibt folgendes aus:

sda              8:0    0 238,5G  0 disk
├─sda1           8:1    0   260M  0 part
├─sda2           8:2    0    16M  0 part
├─sda3           8:3    0 118,6G  0 part
├─sda4           8:4    0  1000M  0 part
├─sda5           8:5    0  63,3G  0 part
├─sda6           8:6    0     1M  0 part
├─sda7           8:7    0   513M  0 part /boot/efi
└─sda8           8:8    0  54,8G  0 part /
sdb              8:16   0   3,7T  0 disk
└─sdb1           8:17   0   3,7T  0 part
  └─veracrypt1 253:0    0   3,7T  0 dm   /media/veracrypt1
mmcblk0        179:0    0 119,1G  0 disk
├─mmcblk0p1    179:1    0   256M  0 part /media/anarki/boot
└─mmcblk0p2    179:2    0 118,9G  0 part /media/anarki/rootfs

In Anlehnung an bisherige Forenposts und des oa. Threadverlaufs hätte ich folgenden Befehl abgesetzt:

sudo dd if=/mmcblk0 of=dev/sdb/raspberry.img bs=1M status=progress

Wichtig:
Die HD unter sdb enthält bereits Daten und soll keinesfalls überschrieben werden.

Der oa. Befehl bringt aber nur die Fehlermeldung, dass das angegebene Verzeichnis nicht vorhanden sei.

Hat jemand Anregungen/ Tipps?

 

[DorMoordor]

@anarki99 die Platte mounten, in den Ordner navigieren, wo das Image liegen soll dann.:

dd if=/dev/mmcblk0 of=<image_name>.img

Dann funktioniert das

 

[anarki99]

@anarki99 die Platte mounten, in den Ordner navigieren, wo das Image liegen soll dann.:

dd if=/dev/mmcblk0 of=<image_name>.img

Dann funktioniert das

Danke für die Info. Aufgrund der Datenmenge kann ich das erst am Wochenende durchführen. Ich melde mich mit dem Feedback.

 

[Uridium]

Für USB-Sticks empfiehlt sich dies:

dd if=image.bin of=/dev/sdx bs=4M oflag=sync status=progress
eject /dev/sdx

Mit 'progress' Anzeige, 4MB Blocksize (die alle gängigen 'erase block sizes' abdecken sollte) und ordnungsgemäßem 'eject'.
Bei zu geringer Blocksize kann es in der Tat länger dauern, weil der Stick immer nur 2/4MB Blöcke schreiben (streng genommen 'löschen') kann.