Ich wollte eine Iso auf einen USB-Stick kopieren, erhalte aber bei einigen Dateiordnern eine Fehlermeldung

Ich habe noch eine ISO mit dem dd Befehl auf einen Stick entpackt. Das Hat geklappt. Bei einer anderen ISO von Mint 22.3 gab es aber Probleme. Das Dateisystem des Sticks war FAT32 und ich habe den Befehl mit sudo angefangen. Nautilus zeigte gar nichts an und Dolphin viele Datein und ausländischen Zeichen.
 
zelect0r schrieb:
Wieso so zum Teufel entpacken. Einfach mit DD auf den stick schreiben, nach dem entpacken und drauf kopieren ist der stick eh nicht mehr bootfähig.

Code:
dd if=pfad/zur/datei.iso of=dev/sdx status=progress
Oder cat:
Code:
cat < pfad/zur/datei.iso > /dev/sdXX
Dieser Mythos mit "dd" stammt noch aus der Zeit von raw-devices, wo lesen und schreiben nur mit vielfachen der physikalischen Blockgröße möglich ist. Selbst die Wikipedia-Artkel verbreiten Unsinn über raw-devices.
 
Ich habe eine ISO mit Ubuntu mit dem dd Befehl auf einen USB-Stick mit exFAT entpackt. Das hat geklappt. Ein anderes ISO mit MInt 22.3 auf einen USB-Stich mit FAT32 hat wohl nicht geklappt. Im Nautilus wurde nichts angezeigt. Und in Dolphin waren viele arabische und Farsizeichen dabei.
 
Noch einmal (und ich bin ja nicht der erste, der das fragt): Wieso möchtest Du die ISO entpacken? Du möchtest einen bootfähigen Stick erstellen, um davon zu booten? Nutze eines der vielen dafür vorgesehenen Programme (Impatience wurde noch nicht genannt) und schreibe damit die ISO auf den Stick. Keine Ahnung, was du da machst und ich gehe mal davon aus, dass ein grundsätzliches Missverständnis vorliegt.
 
  • Gefällt mir
Reaktionen: Lotsenbruder
fixedwater schrieb:
Keine Ahnung, was du da machst und ich gehe mal davon aus, dass ein grundsätzliches Missverständnis vorliegt.
Die zentrale Abstraktion von Unix "everything is a file" ist so genial das diese zu leicht Verwirrung stiftet, und Windows hat das komplett versemmelt und halbgar umgesetzt :-)

@TO: Lese dies:

https://en.wikipedia.org/wiki/Everything_is_a_file
https://de.wikipedia.org/wiki/Unix-Philosophie
https://en.wikipedia.org/wiki/Unix_philosophy#Do_One_Thing_and_Do_It_Well
 
Ich glaube er benutzt nur die falsche Terminologie. Wenn du dd benutzt hast, dann hast du die ISO nicht entpackt sondern direkt auf den Stick geschrieben.

Das der vorher mit exFAT formatiert war ist vollkommen egal, das Dateisystem ist danach WEG. Stattdessen siehst du das Dateisystem das in der ISO war - in der Regel ISO9660 oder FAT32, und das kannst du natürlich mounten, und dann siehst du den Inhalt der ISO auf dem Stick.

Wenn du einfach eine ISO mit dd auf den Stick bügelst, aber der Stick war noch gemountet, dann kriegst du ggf. keinen Fehler aber im laufenden Betrieb sieht dein System dann ein völliges kaputtes Dateisystem ("viele arabische und Farsiezeichen dabei") weil die ganzen Daten von der FAT32-Struktur die dein System da noch erwartet mit was ganz anderem Überschrieben wurde.

Du solltest den Stick nur mit dd (oder vergleichbaren Werkzeugen) beschreiben wenn er nicht gemountet ist, d.h. nicht "offen" im Dolphin/Nautilus & Co. Und das Dateisystem das da vorher drauf ist, ist völlig egal, dann das wird komplett ersetzt.
 
  • Gefällt mir
Reaktionen: zelect0r
EIne ISO ist nicht "gepackt". Das ist ein containerisiertes Dateisystem. Ergo kann man da auch nichts entpacken. Was du tun möchtest, ist das Dateisystem auf den Stick zu kopieren. Und das geht, wie schon mehrfach erklärt, mit entsprechenden Tools. Zum Beispiel dd.

Marco01_809 schrieb:
Du solltest den Stick nur mit dd (oder vergleichbaren Werkzeugen) beschreiben wenn er nicht gemountet ist

Korrekt. Und wenn das OS den Stick beim Anstecken automatisch mounted, dann musst du den vor dem dd eben mit umount /dev/sdX aushängen.
 
foofoobar schrieb:
Windows hat das komplett versemmelt und halbgar umgesetzt :-)
Wobei man sagen muss, bei UNIX respektive Linux ist es auch nicht wirklich durchgehend.
Das scheitert ja schon an einfachen Dingen wie Netzwerk. Da gibts unter Linux halt Network-Interfaces die speziell angesprochen werden. Statt einfach ein entsprechendes Filesystem zu haben mit dem man normale Dateisystemoperation machen kann.
Oder sowas wie GUI. Das wird bei einem Linux-System auch nicht im Dateisystem abgebildet.

Man kann natürlich sagen, das es unter Windows noch schlechter ist. Aber die Implementierung in UNIX/Linux ist da auch nicht wirklich konsequent und daher eher ein suboptimales Beispiel. :-)
 
  • Gefällt mir
Reaktionen: areiland
andy_m4 schrieb:
Man kann natürlich sagen, das es unter Windows noch schlechter ist. Aber die Implementierung in UNIX/Linux ist da auch nicht wirklich konsequent und daher eher ein suboptimales Beispiel. :-)
Naja, fast: :-)
Code:
       Bash handles several filenames specially when they are used in redirections, as described in the following table.  If the operating system on which bash is running provides these special  files,
       bash will use them; otherwise it will emulate them internally with the behavior described below.

              /dev/fd/fd
                     If fd is a valid integer, file descriptor fd is duplicated.
              /dev/stdin
                     File descriptor 0 is duplicated.
              /dev/stdout
                     File descriptor 1 is duplicated.
              /dev/stderr
                     File descriptor 2 is duplicated.
              /dev/tcp/host/port
                     If host is a valid hostname or Internet address, and port is an integer port number or service name, bash attempts to open the corresponding TCP socket.
              /dev/udp/host/port
                     If host is a valid hostname or Internet address, and port is an integer port number or service name, bash attempts to open the corresponding UDP socket.

       A failure to open or create a file causes the redirection to fail.

       Redirections using file descriptors greater than 9 should be used with care, as they may conflict with file descriptors the shell uses internally.

       Note that the exec builtin command can make redirections take effect in the current shell.
Immerhin funktioniert read(2) und write(2) auf einen Socket, das ist allerdings bei udp eher suboptimal.

Und Plan 9 from Outer Space ist gescheitert.

BTW: Erinnert sich noch jemand an FCBs unter CPM und DOS?
 
Zuletzt bearbeitet:
Zurück
Oben