Bootbare ISO aus USB Stick

[Huck Fin]

Moin,
ich wollte aus einem bootbaren USB-Stick (DOS + Debian) ein .ISO machen, um es mit Ventoy zu booten.
Ein Image kann ich mit dd if=/dev/sdb of=dos.img machen.
Aber wie bekomme ich ein bootfähiges ISO daraus.

[cosinus]

ISO-Datei? Dasist eigentlich ein Abbild eines optischen Datenträgers. Auf die Schnelle hab ich nur das hier gefunden --> https://raywoodcockslatest.wordpress.co ... e-usb-iso/

[wanne]

Dasist eigentlich ein Abbild eines optischen Datenträgers.

Ja. Und Grub/Ventoy können die booten. Ich würde es so langsam aber auch als massiv fragwürdig ansehen, steinalte und im bootvorgang deutlich komplexere format zurück greifen will.

Aber wie bekomme ich ein bootfähiges ISO daraus.

Weitestgehend gar nicht. moderne Dateisysteme haben viel mehr Fuktionen als ne ISO. Alle Tools erstellen ein neue ISO und versuchen dann halt wichtige Daten vom IMG in die neue ISO zu kopieren. Die suchen aktiv nach Linux-Kerneln, initrds, Windows-Bootloadern, EFI-Firmwares... und nutzen dann die. Die konvertieren nicht generisch.

So als alternativ-Idee A:
Installier einfach ein normales Deibian und lasse Ventory, Ventory sein.
Grub kann problemlos unterschiedlichste Betriebssysteme booten. Insbesondere für EFI ist das super einfach. Man geht einfach in den EFI-Ordner der FAT-partiton und schreibt den Dateinamen ins Grub-Menü. grub-update passt grub auf die geänderte Konfiguration an. grub-install macht den Stick dann bootfähig. Leider ist die Doumentation sehr bescheiden. Genoo hat ne deutlich bessere: https://wiki.gentoo.org/wiki/GRUB/Chainloading
Leider lässt sich unter Debian Grub-EFI und Grub-BIOS nicht gleichzeitig installieren. Sodass man Sticks immer nur auf einem der beiden Plattformen zum laufen bekommt. (Aber heute unterstützen praktisch alle Mainboards eh beides.) Das ist aber kein grundsätzliches Problem. Problm ist dass debian beide Varianten an den selben Ort installiert. In den ISOs bescheißen die das indem sie die Ergebnisse von Grub-install manuell auf die CD packen. Das kannst du auch machen. (/boot/EFI und die bios-Grub-Partition kopieren und die Eintraäge aus /boot/grub/grub.cfg zusammenfügen.)

Alternativ:
Ventoy sollte auch problemlos mit image-Files klar kommen. Btw: cp /dev/sdb dos.img ist deutlich sinnvoller als die dd variante.
Aber auch hier gilt: Auch wenn Ventoy EFI und BIOS kann: es ist unwarscheinlich, dass du wenn due ein Ventory im EFI geladen hast ein BIOS-Debian zum laufen bekommst. De fehlen einfach die passenden EFI-Komponenten. Und ich bezweifele, dass Ventory die nachladen kann.

[Livingston]

Genoo hat ne deutlich bessere: https://wiki.gentoo.org/wiki/GRUB/Chainloading
Leider lässt sich unter Debian Grub-EFI und Grub-BIOS nicht gleichzeitig installieren. Sodass man Sticks immer nur auf einem der beiden Plattformen zum laufen bekommt. (Aber heute unterstützen praktisch alle Mainboards eh beides.) Das ist aber kein grundsätzliches Problem. Problm ist dass debian beide Varianten an den selben Ort installiert.

*HUST*
Zum Thema BIOS- und UEFI-grub haben wir ein ein schönes Wiki mit dazugehörigem Thread (oben im Wiki-Beitrag verlinkt):
Ein Notfallsystem auf einem USB-Stick installieren
Und ob das geht

[Tintom]

Ich kenne Ventoy nicht und weiß nicht wie es arbeitet, die einfachste Methode (wenn es wirklich eine Boot-CD sein soll) wäre jedoch mit grub-mkrescue eine ISO erstellen zu lassen, bei der die gewünschten Daten gleich eingebunden werden.

Minimales Beispiel gibt's auf der Webseite von grub: https://www.gnu.org/software/grub/manua ... CD_002dROM

Im nächsten Schritt erstellst du dann eine spezifische grub.cfg für diese Boot-CD, um damit die unterschiedlichen Einträge booten zu können. Ab hier kann es aber dann herausfordernd werden.

[MSfree]

Aber wie bekomme ich ein bootfähiges ISO daraus.

Gar nicht, denn
ISO ist ein Dateisystem.
Ein Medium, auf dem mehrere Dateisysteme existieren können, ist kein ISO.

Benutzt doch bitte nicht ständig den falschen Begriff.

ISO ist ein Dateisystem, eigentlich ISO9660, und damit kann man nunmal keine bootfähigen Medien bauen, die zwei verschiedene Betriebssystem booten können.

Was du wilst, ist ein Image, das mehrere Dateisystem (hier DOS und Linux) beinhaltet, von dem wahlweise das eine oder das andere gebootet werden kann.

[cosinus]

ich wollte aus einem bootbaren USB-Stick (DOS + Debian) ein .ISO machen, um es mit Ventoy zu booten.

Erklär doch mal auch bitte was das mit dem DOS soll. Das macht die Sache nämlich unnötig kompliziert.
Ansonsten richte den Stick mit Ventoy ein, danach kopierst du die ISO-Datei von Debian rauf und von das von der Ultimate Boot CD, da ist ein FreedDOS mit drin
Link -> https://ubcd.sourceforge.net/download.html

[DeletedUserReAsG]

Gar nicht, denn
ISO ist ein Dateisystem.
Ein Medium, auf dem mehrere Dateisysteme existieren können, ist kein ISO.

Jain … Livesysteme bestehen in der Regel aus dem ISO9660-Dateisystem, in dem im Wesentlichen der Bootloader und eine große Datei mit einem SquashFS ist, die das eigentliche System enthält. Hindert einen keiner daran, da mehrere Systeme auf je einem eigenen SquashFS drauf zu parken und den Bootloader so zu konfigurieren, dass man beim Booten das gewünschte System anwählen kann. AFAIR haben beispielsweise Zeitschriften (kennt das noch jemand? Zeitschriften?) so mehrere Livesysteme zum Rumtesten und -spielen auf einer DVD ausgeliefert – mit einem ISO9660-Dateisystem

Glaube aber irgendwie nicht, dass das hier das Gesuchte ist – obschon machbar, ist’s nicht direkt trivial, sowas von Hand aufzuziehen. Die Doku dazu wird auch immer rarer, je mehr die optischen Datenträger aussterben …

[DeletedUserReAsG]

Btw: cp /dev/sdb dos.img ist deutlich sinnvoller als die dd variante.

Ansichtssache. Während cp vermutlich mit den vom Device zurückgegebenen Blockgrößen arbeitet, die bei Flash-Medien nicht unbedingt den tatsächlichen Blockgrößen entsprechen, könnte man dd auf die tatsächliche Blockgröße zwingen, wenn man die denn weiß. Ist aber eher beim Schreiben von Interesse. Ansonsten ist die kleine Zusammenfassung am Ende eines dd-Durchlaufs schon nicht verkehrt.

Edit, OT: ich hätte nun gerne den versehentlichen Doppelpost zusammengeführt, aber man darf eigene Beiträge nicht mehr selbst löschen? Das halte ich für einen enormen Rückschritt.

[wanne]

Während cp vermutlich mit den vom Device zurückgegebenen Blockgrößen arbeitet, die bei Flash-Medien nicht unbedingt den tatsächlichen Blockgrößen entsprechen

Nein. cp arbeitet eben nicht mit festen Blockgrößen. Genau das ist der Vorteil gegenüber dd. So kann es von readahead, asyncio, lseek holepunching (wenn man die --sparse=always mitgibt) und ähnlichen Optimierungen profitieren. Wobei dd auch nicht mehr ganz so dumm ist, wie vor ein paar Jahren.

[DeletedUserReAsG]

Nein. cp arbeitet eben nicht mit festen Blockgrößen.

Eben, tut es nicht. Flash arbeitet aber mit festen Blockgrößen.

[chrbr]

Edit, OT: ich hätte nun gerne den versehentlichen Doppelpost zusammengeführt, aber man darf eigene Beiträge nicht mehr selbst löschen? Das halte ich für einen enormen Rückschritt.

OT: Man kann einen eigenen Beitrag löschen wenn es noch kein neueren Beitrag als deinen eigenen Beitrag gibt. Ganz verkehrt erscheint mir das nicht, weil ja neue Beiträge auf deinen Beitrag verweisen könnten. Mir ist das die Tage passiert. Da habe ich auf den Eingangsbeitrag etwas antworten wollen, bin dabei im Nachhinein etwas unpassend abgedriftet. Ein Moderator hat dann für mich meinen Beitrag gelöscht.

[DeletedUserReAsG]

OT: Man kann einen eigenen Beitrag löschen wenn es noch kein neueren Beitrag als deinen eigenen Beitrag gibt.

Das ist, wie es früher™ war. Besagten Beitrag konnte ich nicht löschen – sonst hätte ich den Edit nicht reingeschrieben, sondern ihn gelöscht

[chrbr]

Das ist, wie es früher™ war. Besagten Beitrag konnte ich nicht löschen – sonst hätte ich den Edit nicht reingeschrieben, sondern ihn gelöscht

Ich habe es eben mal hier ausprobiert. Nach dem Absenden bin ich raus aus dem Thread und über deine Benachrichtigung durch den Quote wieder rein. Da war in meinem Beitrag rechts oben beim !" noch ein x. Darauf geklickt ging ein Fenster auf in dem ich eine Begründung schreiben sollte. Danach war mein Beitrag gelöscht.

[DeletedUserReAsG]

Da war in meinem Beitrag rechts oben beim !" noch ein x.

Damit tut’s, ja. Als ich beim Ändern des Beitrags die Checkbox zum Löschen angeklickt hatte, bekam ich hingegen die Meldung, dass ich zum Löschen keine Rechte hätte.

Sorry für’s OT-Rauschen

[wanne]

Eben, tut es nicht. Flash arbeitet aber mit festen Blockgrößen.

Nein. Siehe: https://doi.org/10.1016/B978-1-78548-124-6.50010-4 oder such einfach mal bei Google nach write-Gap.
Ganz abgesehen, das die Diskussion sinnlos ist, da die anderen Vorteile weiter zählen und und eh keiner das interne Layout seiner SD-Karte kennt. Und wenn er sich so gut auskennt würde er den Tipp eh ignorieren.

[DeletedUserReAsG]

Natürlich arbeitet Flash intern, hardwareseitig, mit festen Blockgrößen. Geht technisch gar nicht anders. Dein Link knallt in eine Paywall, btw.

So kann es von readahead, asyncio, lseek holepunching (wenn man die --sparse=always mitgibt) und ähnlichen Optimierungen profitieren.

Wenn du magst, könntest du diese Vorteile von cp beim Schreiben von zusammenhängenden Daten auf ein Device gerne näher ausführen. Geht nicht um das Schubsen von Daten innerhalb von Dateisystemen, wohlgemerkt – da leuchtet mir schon selbst ein, dass readahead, asyncio, lseek holepunching [sic!] gewisse Vorteile bieten können.

[wanne]

da leuchtet mir schon selbst ein, dass readahead, asyncio, lseek holepunching [sic!] gewisse Vorteile bieten können.

Es ging um das schreiben ins Dateisystem. Und dah hilft es halt massiv.
Aber auch wenn du auf flash schreibst kann das relevant werden: Ich kenne ich mit mit USB nicht so aus. Aber prinzipiell spricht nichts dagegen, dass dein Flash Chip den nächsten Block schon mal cleard und den übernächsten decodiert während der alte schreibt. Da du üblicherweise mehrer Flash-Chips hast sogar viele gleichzeitig schreiben. SATA kann aus gutem Grund bis zu 8 befehle parallel ausführen NVMEs weit mehr: https://blog.westerndigital.com/nvme-queues-explained/
Kannst du nur wenn du die nächsten Daten anforderst, bevor du die alten hast. Aber wie gesagt. dd verhält sich da nicht mehr so dumm wie früher.

[DaCoda]

Was soll das für ein USB-Stick sein, der MS DOS und Debian beinhaltet?

Startet da etwa Grub und du kannst dann zwischen MS DOS und Debian wählen?

Habe noch nie gehört, dass jemand MS DOS von einem USB-Stick startet... Und dann auch noch Dualboot mit Debian ???

[cosinus]

Was soll das für ein USB-Stick sein, der MS DOS und Debian beinhaltet?

Leider beantwortet der TO keine Fragen mehr

[Livingston]

Habe noch nie gehört, dass jemand MS DOS von einem USB-Stick startet... Und dann auch noch Dualboot mit Debian ???

Kann man machen, um z.B. MS-DOS oder freedos für BIOS-Updates zur Hand zu haben. Man muss dazu das DOS vorher mit USB-Treibern füttern. Hab das mal mit viel Rumgemurkse hinbekommen.
U.U. braucht man dann aber auch noch SATA-Treiber und was sonst noch nötig ist. Um sich sowas zusammenzuschrauben empfiehlt sich eine virtuelle Maschine.

[cosinus]

Kann man machen, um z.B. MS-DOS oder freedos für BIOS-Updates zur Hand zu haben.

Das müssen aber richtig alte Kisten sein!
Ich mein bei den letzten bei denen ich ein MS- oder Free-DOS brauchte um das BIOS zu aktualisieren, waren so Baujahr 2006/2007 herum. Ich weiß leider nicht wie das später bei den anderen Mainboardherstellern war, aber unsere Standard-PCs mit ASUS-Boards hatten dann EZ-Flash. Damit konnte man direkt aus dem BIOS heraus auf einen FAT32-Stick zugreifen und mit einer Update-Datei das BIOS updaten.

Bei derzeitiger Hardware von Lenovo kommen die EFI-Updates über Windows Update rein. Da wie ich mal gehört habe nicht jeder Windows hat kann man bei Lenovo eine ISO runterladen, da hat es einfach gereich das auf einem FAT32-Stick zu entpacken und man konnte davon booten um das EFI zu aktualisieren.

[DaCoda]

Kann man machen, um z.B. MS-DOS oder freedos für BIOS-Updates zur Hand zu haben. Man muss dazu das DOS vorher mit USB-Treibern füttern. Hab das mal mit viel Rumgemurkse hinbekommen.
U.U. braucht man dann aber auch noch SATA-Treiber und was sonst noch nötig ist. Um sich sowas zusammenzuschrauben empfiehlt sich eine virtuelle Maschine.

Ein Mainboard das BIOS-Updates unter DOS macht ist geschätzt von 1999. Solche Mainboards können gar nicht von USB starten. Macht also immernoch keinen Sinn???

[cosinus]

Ein Mainboard das BIOS-Updates unter DOS macht ist geschätzt von 1999. Solche Mainboards können gar nicht von USB starten. Macht also immernoch keinen Sinn???

Es gab auch deutlich jüngere Boards wo man das unter DOS machen musste. Sowas wie EZ-Flash aus dem BIOS heraus hatte nicht jedes Board. Wohl aber konnte man bei diesen Boards von USB booten.

[Huck Fin]

Danke für die Tipps.

Ich habe es zwar hin bekommen, bleibe aber dabei, einen 500gb Stick nur für Dos zu nutzen.
So kann ich den auch mal an den PC anstecken und direkt Bios + Flash-Dateien draufzuladen.

Bei meinem Live-Debian das Selbe. Ist eine normale Installation auf 8GB Stick. Das ist für Datenrettung gedacht.
Ist so besser mit einem einzelnen Stick.

Ansonsten habe ich jetzt den Stick bestückt mit ISOs, die von Ventoy zum booten benutzt werden.
Win11, Win10 (32+64), Win7 Multi-Version, SuperGrub, Hirens Boot-CD, Win7RescuePE Memtest

Und alle möglichen Installationen in einem Ordner.
Schweizer Taschenmesser sozusagen.