Augen auf beim schreiben von ISOs unter Windows

[Uridium]

Die Laufzeitumgebung (runtime environment) ändert sich. Der Stage1 Assemblercode wird ausgetauscht, Speicher wird anders zugewiesen, usw. Technisch läuft es "anders".

 

[P.Jay]

mehrere ISOs die mit Ventoy nicht funktioniert haben

Das hatte ich auch schon.
Aber Moment - es ist ja eben nicht einfach nur ein bootable Stick. Es ist halt in sich ein kleines Live-OS das booted und dann erst die jeweiligen ISO's lädt.

Ergo, muss es nicht an Ventoy liegen, sondern kann an der ISO bzw. auch der Hardware (bzw. der Firmware der Hardware) liegen. Konnte auf meinem Chromebook keinerlei Distros, die nicht SystemD basiert sind booten. Liegt in dem Fall an der Coreboot open source Firmware, die das halt i.wie nicht zulässt. Will damit nur sagen, muss nicht unbedingt an Ventoy gelegen haben. Kann es aber natürlich.

 

[DonChiChi]

Der Pi Imager wird auch empfohlen.

 

[foofoobar]

Das hat nix mit dem Schreiben/Entpacken der ISO an sich zu tun und schon garnicht mit "rumfummeln an Daten".

Und ein paar Sätze weiter:

Zudem änderte es das Tails-Image auf nicht näher genannte Art und Weise, die die Tails-Maintainer jedoch als "riskant" einstuften.

Ergänzung (21. Februar 2025)

Die Laufzeitumgebung (runtime environment) ändert sich. Der Stage1 Assemblercode wird ausgetauscht, Speicher wird anders zugewiesen, usw. Technisch läuft es "anders".

Warum?

 

[Uridium]

Weil es ein ganz anderer Bootloader ist. Das ISO wird komplett neu erstellt (reauthoring). Der "Payload" (bzw. die Nutzerdaten) werden zwar nicht verändert, die Imagestruktur und Codeausführung aber schon. Das kann zu unterschiedlichen Ergebnissen der Laufzeit führen.
El-Torito <> Syslinux/Isolinux

Ob das Sinn macht, besser oder schlechter ist, sei dahingestellt. Was damals für Protest gesorgt hatte, war, dass das Programm den Benutzer bevormundet hatte und keine Option zur Verhinderung dieses "Reauthoring" erlaubte. Dem Programmierer unterstellte man eine gewisse Radikalität, während er wiederum auf bessere Kompatibilität (erhöhter Booterfolg) verwies. Das Programm sei letztlich maßgeblich für "weniger versierte" Benutzer gedacht.

In gewisser Weise hat er auch recht, da El-Torito nie für USB Sticks definiert wurde, ein dd Image (Direktkopie) streng genommen nicht zulässig ist und technisch gesehen durchaus die "verkorkstere" Methode darstellen kann.

Edit2:
Rufus analysiert das ISO Image. Findet es Syslinux (z.B. bei Knoppix) bietet es die Option für "plain dd" an (kein Reauthoring). Bei ElTorito wird immer neu gebaut.

 

[GrillSgt]

Toll... ein Artikel der Art:

Zudem änderte es das Tails-Image auf nicht näher genannte Art und Weise, die die Tails-Maintainer jedoch als "riskant" einstuften.

Frei nach dem Motto. Wir haben mal was zu sagen gehabt. Wenn man schon von angeblich "riskant" spricht sollte man es auch mal genauer definieren.

 

[foofoobar]

Ob das Sinn macht, besser oder schlechter ist, sei dahingestellt. Was damals für Protest gesorgt hatte, war, dass das Programm den Benutzer bevormundet hatte und keine Option zur Verhinderung dieses "Reauthoring" erlaubte. Dem Programmierer unterstellte man eine gewisse Radikalität, während er wiederum auf bessere Kompatibilität (erhöhter Booterfolg) verwies. Das Programm sei maßgeblich für "weniger versierte" Benutzer gedacht.

Ist das ein signifikantes Problem um per Default Daten zu manipulieren?
Ich mache das seit Jahrzehnten mit "cat foo.img > /dev/sdx" bzw. boote das iso-file direkt für VMs und das war bisher immer erfolgreich.

 

[Uridium]

Nein, manipuliert wird an den (Nutz)Daten selbst nichts. Ich habe oben noch was hinzugefügt. Ich mache das auch lieber mit dd.

Die These/Befürchtung ist, dass ein dd Image bei gewissen Boards oder BIOS nicht bootet. Mir ist aber noch kein Board in die Hände gefallen, wo es nicht funktionierte.

Edit:
ISO File in der VM booten ist was anderes. Da wird direkt via CD-ROM Emulation gebootet. Die Problematik entsteht erst wenn man cdrom images (iso9660) via USB Stick booten will.