In Ubuntu kann man fast das ganze Wissen von Knoppix wieder anwenden (vor allem auf shell-Ebene, abseits der GUI, im Prinzip die ganze OS-config), denn ebenso wie Mint oder Bodhi beruhen alle diese distros auf Debian. Schon bei Fedora, openSUSE, Gentoo oder Mageia schaut's dann auch dort zuweilen wieder ganz anders aus.

So, nach 26 Stunden ist der Download beendet und liegt in einem Unterverzeichnis des Knoppix-Desktops.
Wenn ich das richtig verstehe, kopiere ich den Vereichnisbaum jetzt einfach auf meine bootfähige USB-Harddisk in die OMNIBOOT-Partition, die ich ohnehin von einer Vorversion habe.

Ja, allerdings hat Deine Vorversion noch einen alten bootloader, daher ist anschließend entweder http://omniboot.org/htm/boot/winusb.html oder http://omniboot.org/htm/boot/linusb.html relevant!
Auch das script kann mit einem weiteren Aufruf eine Partition OMNIBOOT erkennen, syncen und sie nachher bootfähig machen.
Der Befehl dazu ist hier nachzulesen (./om r f) http://omniboot.org/htm/build/ususb.html.

So, mein Stick ist nun ansich fertig, bleibt nurmehr der finale Test. ;)

Gruss Wildfoot

Na hoffentlich schläft Murphy heute schon ;)

Hat alles geklappt. Sogar das Problemkind OpenSUSE64. ;)

Aber in Linux Mint macht der VLC Player Bildstörungen, das bitte bis zur nächsten Version korrigieren. ;)

Gruss Wildfoot

Ach, und ich dachte der Grünton bei Mint sei etwas zu blaustichig ... ;)

Im Omiboot-Verzeichnis habe ich jetzt zwei Verzeichnisse, "filesystem" und "isostore". Schiebe ich jetzt beide Verzeichnisse, wie sie sind, auf die Bootdisk? Oder beginnt der Verzeichnisbaum unterhalb von "filesystem" (das war wohl bei früheren Versionen so - wohin kommt aber dann isostore)?
Das ist mir aus der Hilfe nicht ganz klar.

Der Inhalt vom folder filesystem ist es, der isostore ist nur für die Erstellung. D.h. die folder-Struktur vom stick bleibt im root gleich.

Heisst das, man kann isostore löschen, oder braucht man ihn für ein späteres update, wie ich herauszulesen glaubte?

Ja genau, beim nächsten update spart Dir isostore den download aller nicht upgedateten Elemente!

Ich habe jetzt die verschiedenen Distros durchprobiert. Dabei habe ich festgestellt, dass Debian, Opensuse, Mint und Ubuntu bei mir nicht starten (auf zwei verschiedenen Geräten - Desktop mit 4GB und Notebook mit 3GB). Die übrigen funktionieren einwandfrei.
Woran könnte das liegen?
Gemeinsam ist diesen, dass es sich um größere Pakete handelt.

Waren das 64-bit fähige Geräte oder bloß 32-bit Geräte? Bootsource ist USB?

Bootsource USB-Harddisk (Fat32), Geräte sind 64bit-fähig.

Fällt mir momentan nicht viel dazu ein, das hätte ich eigentlich alles getestet und sollte gehen. Bekommst Du überall die Auswahl im jeweiligen sub-menü von 64 oder 32 bit?
Jedenfalls ist in solchen Fällen immer hilfreich, erst nochmal zu schauen ob
./om c
fehlerfrei abläuft. Danach syncen vom stick mit
./om r a
und nochmal testen.
Werde mir das auch nochmal genauer anschauen.

Interessant. Konnte nicht nachvollziehen, warum diese Module bei Dir nicht booten. Aber ich habe nach Tests mit isos und vom pxe-Server offenbar beim USB-Testen geschlampt. Denn da habe ich einen Fehler gefunden, der dazu führt, dass bei USB-boot bei folgenden Modulen keine 64-bit Option angeboten wird:
Clonezilla, Debian, Mint und Ubuntu.
Das Hinzufügen der 64-bit Version war nämlich die wesentliche Änderung an Modulen, mit denen jetzt auch Du Probleme hast.
Daher meine Frage im letzten posting.
Ich habe eine Datei zu löschen vergessen bei dieser Änderung, komischerweise nur bei openSUSE nicht.
Der Bugfix besteht also nun darin,
folgende Dateien zu löschen:

1. /images/clonezilla/menu/syslinux.cfg
2. /images/debian/menu/syslinux.cfg
3. /images/mint/menu/syslinux.cfg
4. /images/ubuntu/menu/syslinux.cfg

Das löst aber wahrscheinlich nicht Dein Problem, zumindest nicht wie von Dir beschrieben.
Dafür würde ich

• die entsprechenden Module in Deiner build-source löschen
• durch eine Kopie aus der tgz-Version ersetzen
• Bugfix wie oben erläutert durchführen
• rebuild mittels ./om cr

Nein, derzeit werden keine 64bit-Versionen angeboten.
Ich hab mir die Fehlercodes am Desktop notiert (am Notebook bleiben die genannten Distros kommentarlos hängen):
Ubuntu 0x0106a940
Mint 0x01069e40
OpenSuse 0x0105d1b0
Debian 0x0107a470

Ich experimentiere weiter, wie von dir vorgeschlagen.

Diese Fehlercodes geben mir Rätsel auf. Die kommen genau wann? Wenn Du schon im opensuse submenu bestätigst (oder auf autoboot wartest) oder schon im distro submenu wo opensuse als ein Element aufscheint?
Die mangelnde 64-bit Version ist nun quasi nebenbei geklärt ;)
Bin schon neugierig, wie es nach dem rebuild ausschaut!

Vorher - Submenu der Distribution kommt gar nicht.

Aha. Da ist dann gröber was daneben und der obige Vorschlag des rebuilds vorrangig.
Denn erst durch den build wird ein Modul überhaupt ins übergeordnete Menü aufgenommen. Sonst scheint es dort nicht mal auf. Wenn selbiges dann aber nicht funktioniert, kann nur im Modul was ziemlich schief gelaufen sein.

Bei mir sind in /menu jeweils syslinux32.cfg und syslinux64.cfg vorhanden.

Ja, die gehören dahin. Nur die besagte nicht. Und in der tgz wäre sie auch nicht fälschlicherweise drin, da habe ich mich selbst zu unrecht verdächtigt. Keine Ahnung, wie die bei mir da rein geschlüpft ist und diesen bug verursacht hat. Das muss ich noch erforschen, hat aber mit Deinem prob eh nichts zu tun.
Du kannst übrigens statt cr auch nur c nehmen, da werden nur die noch leeren Module erstellt und alles andere bleibt, wie es ist (Zeitersparnis).

Danke, jetzt funktioniert es.

Gerne, und ich danke Dir auch besonders! Schon wieder selber etwas gelernt und korrigieren können. Das war nämlich ein wirklich witziger bug. Denn er tritt nur in der USB-Version auf, die aber den gleichen code wie iso nützt (an der Stelle, wo ich den Fehler hatte). Ein undokumentiertes sinnloses feature von Syslinux selbst hat einer Datei nur aufgrund ihres Namens und ihrer location Priorität vor einer code-Zeile mit Datei anderen Namens gegeben.
Falls es jemanden interessiert ;)

Also bei mir hats gestimmt. Das heisst, es waren jeweils immer syslinux32.cfg und syslinux64.cfg vorhanden, nicht aber syslinux.cfg.

Scheint also nicht generell am Script zu liegen. ;)

Gruss Wildfoot

Ja, ist mittlerweile geklärt, aber danke für die Rückmeldung!