Komponenten der Busybox einzeln !?
-
- Einsteiger
- Beiträge: 273
- Registriert: Mittwoch 29. Mai 2002, 01:37
Komponenten der Busybox einzeln !?
Hallo,
ich hoffe ich habe hier das richtige Fenster erwischt
Habe eine Frage (hab mich schon tot-gegoogelt). Wie kann man einzelne Komponenten der Busybox im Tuxboxprojekt alleine lauffähig basteln ?
Zum Beispiel wäre interessant der Befehl "mount" mit integrierter Library, damit ganz am Anfang des Bootvorgangs der Befehl in der rcS "mount -a" das jffs2 einbindet, ohne daß die busybox darum gebeten werden muß, die ja dann gleich wieder dazu Libraries nachladen muss.
Hintergrund ist der, daß es möglich ist, gegenenfalls mal die libc.so.6 zu tauschen, obwohl man ein Squash-Image hat.
Auch interessant wäre der Befehl "reboot" für die alten Nokias, die zwar den Befehl reboot ausführen können, aber nach dem Flashen mit den Expertentools in Neutrino/Enigma dies eben nicht tun.
ich hoffe ich habe hier das richtige Fenster erwischt
Habe eine Frage (hab mich schon tot-gegoogelt). Wie kann man einzelne Komponenten der Busybox im Tuxboxprojekt alleine lauffähig basteln ?
Zum Beispiel wäre interessant der Befehl "mount" mit integrierter Library, damit ganz am Anfang des Bootvorgangs der Befehl in der rcS "mount -a" das jffs2 einbindet, ohne daß die busybox darum gebeten werden muß, die ja dann gleich wieder dazu Libraries nachladen muss.
Hintergrund ist der, daß es möglich ist, gegenenfalls mal die libc.so.6 zu tauschen, obwohl man ein Squash-Image hat.
Auch interessant wäre der Befehl "reboot" für die alten Nokias, die zwar den Befehl reboot ausführen können, aber nach dem Flashen mit den Expertentools in Neutrino/Enigma dies eben nicht tun.
-
- Semiprofi
- Beiträge: 1383
- Registriert: Freitag 18. April 2003, 15:12
Re: Komponenten der Busybox einzeln !?
http://cvs.tuxbox-cvs.sourceforge.net/l ... 00016.htmlCarTrinoZap hat geschrieben:Auch interessant wäre der Befehl "reboot" für die alten Nokias, die zwar den Befehl reboot ausführen können, aber nach dem Flashen mit den Expertentools in Neutrino/Enigma dies eben nicht tun.
Tuhen sie, ist schon ne weile jetzt gefixt.
-
- Developer
- Beiträge: 1475
- Registriert: Dienstag 4. Februar 2003, 22:02
Re: Komponenten der Busybox einzeln !?
Gar nicht. Wiederspricht der Sinn des busybox.CarTrinoZap hat geschrieben:Wie kann man einzelne Komponenten der Busybox im Tuxboxprojekt alleine lauffähig basteln ?
Du suchst also ein "statisch gelinktes" mount-programm. Suche, z.B. bei GNU oder BSD oder Linux, passende Quellen aus und kompiliere selbst. Statische Binding gegen libc gilt aber als schlecht.Zum Beispiel wäre interessant der Befehl "mount" mit integrierter Library,
Bzgl reboot hat Nico77 schon geantwortet. Ich habe selbst den Nokia-Wurgaround in Neutrino in CVS entfernt.
-
- Einsteiger
- Beiträge: 273
- Registriert: Mittwoch 29. Mai 2002, 01:37
@Nico77,
ok alles klar War aber nur ein Beispiel zu der Sache (siehe @Barf)
@Barf,
ich weiss was der Sinn der Busybox ist Ich will den Sinn auch nicht umkrempeln, sondern nur einen einzigen Befehl auslagern, bzw zusätzlich haben ! Der kann ja auch mmmounttt heissen, und der mount der busybox kann drinbleiben. Dann hol' ich mal etwas weiter aus:
Es geht um die Reihenfolge wie ein Linux bootet. Ziel ist es, zu Testzwecken zb. mal die libc.so.6 zu tauschen, obwohl die ja im ro-Squashbereich liegt.
Im JFFS2-only geht das so: libc.so.6 nach /tmp uppen, und mit Telnet "cd /tmp" und "mv libc.so.6 /lib" eingeben, warten bis Cursor wiederkommt, und resetten. So soll es hier auch werden.
Idee dabei ist, dass in /lib (im Squash am Beispiel der libc.so.6) nur ein Symlink namens "libc.so.6" steht, der nach /var/libc.so.6 geht. Und /var/libc.so.6 ist auch wieder nur ein Symlink, der zurück nach /lib/libc.so.6.squash geht ! Will man also mal eine lib tauschen, dann muss man in /var nur den Symlink mit einer Test-Lib überschreiben.
In Tuxboximages kommt ja in der Bootreihenfolge nach dem Bootloader und FLFS erstmal der Kernel dran, der dann nach der fstab und der inittab schaut, und dann die rcS abarbeitet. Die fstab, inittab, und rcS kann man also auf gar keinen Fall nach /var schieben/verlinken, da /var zu dem Zeitpunkt noch nicht gemountet ist. OK. Ziemlich weit am Anfang der rcS kommt ein Mountbefehl (mount -a, um alle noch nicht gemounteten, imageinternen FS'e zu mounten). Wenn er das getan hat, ist ab da theoretisch alles erlaubt; also egal in welchem FS die Files stehen.
Dummerweise ist aber der Mountbefehl Bestandteil der Busybox, und diese benötigt ca. 4 Libs, um den "blöden mount-Befehl" auszuführen. Aber Ziel ist ja, im Image alle Libs tauschbar zu machen. Man könnte sich jetzt zufrieden geben, und sagen, daß alle libs bis auf 4 tauschbar sind. Aber ausgerechnet die libc.so.6 ist zb. eine, die man gerne mal gegen eine andere tauschen möchte. Und jetzt zum Punkt ;-)
Wenn man einen mount-Befehl mit integrierten Libs hätte, könnte man in der rcS "mmmmmounttttt -a" eintragen, und über diesen Trick alle Libs durch hin- und herlinken über /var als Schnittstelle austauschbar machen. Es müssten sich im Grunde nur der Kernel, die fstab, die inittab, die rcS, und mmmmountttt im Squash befinden. Jetzt könnte man zwar auch fragen "Warum erstellst Du Dir kein JFFS2-Only ?".. Wegen Platzmangels ! Symlinks fressen nur ganz wenig Speicher, und nahezu keine Performance. Also könnte man in diverse FS'e eine ganze Menge reingepacken, und hätte dennoch den Komfort eines JFFS2-Only, bis auf das die getauschten Files halt 2x vorhanden sind !
Danke für den Hinweis, daß man einen Mount-Befehl auch irgendwo saugen und compilieren kann, aber hier sind auch wieder #include's drin, die dann später beim Ausführen wieder auf Libs zugreifen wollen, die ich ja auslagerbar haben will; ich bräuchte eine Starthilfe, wie man ein völlig Lib-freies Binary compiliert.
Oder könnte man auch irgendwie das u-boot, oder den Kernel bitten, daß bereits vor fstab und inittab das /var (JFFS2) gemountet wird ?
Bye, CTZ
ok alles klar War aber nur ein Beispiel zu der Sache (siehe @Barf)
@Barf,
ich weiss was der Sinn der Busybox ist Ich will den Sinn auch nicht umkrempeln, sondern nur einen einzigen Befehl auslagern, bzw zusätzlich haben ! Der kann ja auch mmmounttt heissen, und der mount der busybox kann drinbleiben. Dann hol' ich mal etwas weiter aus:
Es geht um die Reihenfolge wie ein Linux bootet. Ziel ist es, zu Testzwecken zb. mal die libc.so.6 zu tauschen, obwohl die ja im ro-Squashbereich liegt.
Im JFFS2-only geht das so: libc.so.6 nach /tmp uppen, und mit Telnet "cd /tmp" und "mv libc.so.6 /lib" eingeben, warten bis Cursor wiederkommt, und resetten. So soll es hier auch werden.
Idee dabei ist, dass in /lib (im Squash am Beispiel der libc.so.6) nur ein Symlink namens "libc.so.6" steht, der nach /var/libc.so.6 geht. Und /var/libc.so.6 ist auch wieder nur ein Symlink, der zurück nach /lib/libc.so.6.squash geht ! Will man also mal eine lib tauschen, dann muss man in /var nur den Symlink mit einer Test-Lib überschreiben.
In Tuxboximages kommt ja in der Bootreihenfolge nach dem Bootloader und FLFS erstmal der Kernel dran, der dann nach der fstab und der inittab schaut, und dann die rcS abarbeitet. Die fstab, inittab, und rcS kann man also auf gar keinen Fall nach /var schieben/verlinken, da /var zu dem Zeitpunkt noch nicht gemountet ist. OK. Ziemlich weit am Anfang der rcS kommt ein Mountbefehl (mount -a, um alle noch nicht gemounteten, imageinternen FS'e zu mounten). Wenn er das getan hat, ist ab da theoretisch alles erlaubt; also egal in welchem FS die Files stehen.
Dummerweise ist aber der Mountbefehl Bestandteil der Busybox, und diese benötigt ca. 4 Libs, um den "blöden mount-Befehl" auszuführen. Aber Ziel ist ja, im Image alle Libs tauschbar zu machen. Man könnte sich jetzt zufrieden geben, und sagen, daß alle libs bis auf 4 tauschbar sind. Aber ausgerechnet die libc.so.6 ist zb. eine, die man gerne mal gegen eine andere tauschen möchte. Und jetzt zum Punkt ;-)
Wenn man einen mount-Befehl mit integrierten Libs hätte, könnte man in der rcS "mmmmmounttttt -a" eintragen, und über diesen Trick alle Libs durch hin- und herlinken über /var als Schnittstelle austauschbar machen. Es müssten sich im Grunde nur der Kernel, die fstab, die inittab, die rcS, und mmmmountttt im Squash befinden. Jetzt könnte man zwar auch fragen "Warum erstellst Du Dir kein JFFS2-Only ?".. Wegen Platzmangels ! Symlinks fressen nur ganz wenig Speicher, und nahezu keine Performance. Also könnte man in diverse FS'e eine ganze Menge reingepacken, und hätte dennoch den Komfort eines JFFS2-Only, bis auf das die getauschten Files halt 2x vorhanden sind !
Danke für den Hinweis, daß man einen Mount-Befehl auch irgendwo saugen und compilieren kann, aber hier sind auch wieder #include's drin, die dann später beim Ausführen wieder auf Libs zugreifen wollen, die ich ja auslagerbar haben will; ich bräuchte eine Starthilfe, wie man ein völlig Lib-freies Binary compiliert.
Oder könnte man auch irgendwie das u-boot, oder den Kernel bitten, daß bereits vor fstab und inittab das /var (JFFS2) gemountet wird ?
Bye, CTZ
-
- Senior Member
- Beiträge: 1339
- Registriert: Donnerstag 24. April 2003, 12:12
Moin,
Wenn du unabhängige init und mount-Anwendungen haben willst, mußt du das machen was Barf schon genannt hat, statische Anwendungen erzeugen.
Ist normalerweise ein "don't do it" weil man sich damit üblicherweise Bugs schafft.
Gerade die libc sollte zur Compilezeit die gleiche sein wie zur Laufzeit. Ich sage dir ansonsten schon mal "seltsame" Fehler und "eigenartige" Verhaltensweisen voraus. Man will die libc nicht tauschen. Wirklich nicht. Schon gar nicht zur Laufzeit.
Falls du damit übrigens vorhast, zum Beispiel auf eine niedrigere Version zurückzugehen (2.3.2), das geht auf keinen Fall, wenn nicht alle Anwendungen für die alte Version gebaut waren.
Der Kernel macht überhaupt nichts mit fstab und inittab. Er startet nur init und das ist (bei tuxbox) bereits die busybox.CarTrinoZap hat geschrieben:In Tuxboximages kommt ja in der Bootreihenfolge nach dem Bootloader und FLFS erstmal der Kernel dran, der dann nach der fstab und der inittab schaut, und dann die rcS abarbeitet.
Wenn du unabhängige init und mount-Anwendungen haben willst, mußt du das machen was Barf schon genannt hat, statische Anwendungen erzeugen.
Ist normalerweise ein "don't do it" weil man sich damit üblicherweise Bugs schafft.
Gerade die libc sollte zur Compilezeit die gleiche sein wie zur Laufzeit. Ich sage dir ansonsten schon mal "seltsame" Fehler und "eigenartige" Verhaltensweisen voraus. Man will die libc nicht tauschen. Wirklich nicht. Schon gar nicht zur Laufzeit.
Falls du damit übrigens vorhast, zum Beispiel auf eine niedrigere Version zurückzugehen (2.3.2), das geht auf keinen Fall, wenn nicht alle Anwendungen für die alte Version gebaut waren.
-
- Developer
- Beiträge: 2183
- Registriert: Mittwoch 10. Dezember 2003, 07:59
-
- Einsteiger
- Beiträge: 273
- Registriert: Mittwoch 29. Mai 2002, 01:37
@Houdini,
Du hast leider meinen (zugegebenermaßen etwas langen) Beitrag nicht richtig gelesen
@Nqp, ( @Barf ),
ich will ja nicht aufdringlich sein, aber ich habe das _gesamte_ /cdk/Patches/ Verzeichnis durchwühlt, und in allen Dateien nach dem Wort "busybox" suchen lassen ! Ich finde da rein gar nichts. Wo steht da, daß der Kernel nun statt eine Datei namens "init" zu laden, die "busybox" suchen- bzw. laden soll ? Einen Symlink nach busybox, namens "init" gibts ja auch nicht. Da musst Du Dich entweder geirrt, oder unglücklich ausgedrückt haben, oder ich habe auf beiden Augen dicke, große Fleischtomaten
Nochmal kurz (wenn das auch nicht fruchtet, dann verwerfe ich meine Idee)......... Ich will eigentlich nix statisch verlinken, sondern ich will einen Mountbefehl (und nur den), der keine einzige Tuxbox-Lib im Image benötigt, da er die eigens zu verwendenden entweder integriert hat, oder eigene (anders lautende) lädt. ZB. könnte der Befehl "mmmounttt", damit er überhaupt starten kann, die mmmountlibc.so, die mmmountlibxy.so, und die mmmountyz.so suchen/laden! Wenn man es geschickt macht, dann sind die drei Libs sehr klein, weil diese ja nix anderes als diesen einen Befehl bedienen sollen.
Ok, wenn das auch nix ist, dann werde ich es zwar aufgeben, aber es wäre ein schönes "Outro" für mich (so zum trotzdem nochmal Nachschauen, Ausprobieren und Verwerfen), wenn ich wüsste wie die Startreihenfolge des Tuxbox-Linux ist, und wo welche Dateien dazu gepatcht werden müssen. Wenn mir das jemand erläutern könnte... das wär echt stark von Euch !
Du hast leider meinen (zugegebenermaßen etwas langen) Beitrag nicht richtig gelesen
@Nqp, ( @Barf ),
ich will ja nicht aufdringlich sein, aber ich habe das _gesamte_ /cdk/Patches/ Verzeichnis durchwühlt, und in allen Dateien nach dem Wort "busybox" suchen lassen ! Ich finde da rein gar nichts. Wo steht da, daß der Kernel nun statt eine Datei namens "init" zu laden, die "busybox" suchen- bzw. laden soll ? Einen Symlink nach busybox, namens "init" gibts ja auch nicht. Da musst Du Dich entweder geirrt, oder unglücklich ausgedrückt haben, oder ich habe auf beiden Augen dicke, große Fleischtomaten
Nochmal kurz (wenn das auch nicht fruchtet, dann verwerfe ich meine Idee)......... Ich will eigentlich nix statisch verlinken, sondern ich will einen Mountbefehl (und nur den), der keine einzige Tuxbox-Lib im Image benötigt, da er die eigens zu verwendenden entweder integriert hat, oder eigene (anders lautende) lädt. ZB. könnte der Befehl "mmmounttt", damit er überhaupt starten kann, die mmmountlibc.so, die mmmountlibxy.so, und die mmmountyz.so suchen/laden! Wenn man es geschickt macht, dann sind die drei Libs sehr klein, weil diese ja nix anderes als diesen einen Befehl bedienen sollen.
Ok, wenn das auch nix ist, dann werde ich es zwar aufgeben, aber es wäre ein schönes "Outro" für mich (so zum trotzdem nochmal Nachschauen, Ausprobieren und Verwerfen), wenn ich wüsste wie die Startreihenfolge des Tuxbox-Linux ist, und wo welche Dateien dazu gepatcht werden müssen. Wenn mir das jemand erläutern könnte... das wär echt stark von Euch !
-
- Developer
- Beiträge: 2183
- Registriert: Mittwoch 10. Dezember 2003, 07:59
OKok PlatzproblemDu hast leider meinen (zugegebenermaßen etwas langen) Beitrag nicht richtig gelesen
busybox ist ein Sammelsurium von Tools in einer executable, angefangen von init, cp, link, mount, etc... jenachdem was man konfiguriert.
Diese Tools sind dann ein Symlink auf busybox. Damit du also was bewegen kannst braucht du doch eine statische busybox (obwohl du ja nix statisches willst), die läuft dann ohne libs und kann mount, cp, ln usw. was du ja so alles brauchen wirst. Beim statischen Linken werden auch nur die Funktionen hinzugefügt, die benutzt werden.
Oder du kompilierst dir ein statisches mount, cp, ln, rm, init, insmod, ...
Diese links wirst du nicht im patches dir finden, weil sie während der busybox kompilation erzeugt werden.
-
- Developer
- Beiträge: 2183
- Registriert: Mittwoch 10. Dezember 2003, 07:59
ppc hüpft an die Adresse 0x100 von CS0 und startet denstartreihenfolge des Tuxbox-Linux
BR Bootloader - der lädt aus dem flfs den
uboot - der läd aus dem cramfs/jffs2/squashfs den
linux kernel - der startet
init - welches ein link ist auf
busybox, diese läd die
/etc/inittab - wobei dann
/etc/init.d/rcS - und
/etc/init.d/start - abgearbeitet werden, start ruft dann je nach GUI
/etc/init.d/start_$GUI auf
Houdini
-
- Einsteiger
- Beiträge: 273
- Registriert: Mittwoch 29. Mai 2002, 01:37
Das war genau die Stelle die mich interessiert hat... Danke, weil es hat mich auf den entscheidenden Hinweis gebrachtHoudini hat geschrieben:linux kernel - der startetstartreihenfolge des Tuxbox-Linux
init - welches ein link ist auf
busybox, diese läd die
Ich habe Tomaten auf den Augen, denn die init ist unter /sbin zu finden (und weder eine Sache in /etc, noch eine Sache in /bin), aua. Da hab ich sie nicht vermutet Tschuldigung an Houdini, Barf und Npq.CarTrinoZap hat geschrieben:Einen Symlink nach busybox, namens "init" gibts ja auch nicht. Da musst Du Dich entweder geirrt, oder unglücklich ausgedrückt haben, oder ich habe auf beiden Augen dicke, große Fleischtomaten
Ok, in dem offiziellen Tarball der busybox befindet sich auch u.a. eine init.c, die man anpassen kann. Quick & Dirty wird es wohl gehen, einfach den Tarball zu entpacken, die Zeilen/Pfade etwas abzuändern, den Tarball wieder zu packen, und dann "make busybox" einzugeben. Es war sehr aufschlussreich den Code kurz durchzuschauen Es reicht also gar nicht den mount-Befehl alleine auszulagern, und in irgendeinem Script namens init (was ich zuerst dachte), bereits mount -a busybox-unabhängig auszuführen, sondern die init ist ein binary, welches sich bereits mehreren busybox-Befehlen bedient, grummel
Ich müsste quasi alle verwendeten Files, die in der init.c in /bin, oder /sbin angegeben sind auslagern. mount, umount, reboot, usw. Oder die init.c in zwei Teile splitten; zuerst wird fstab und inittab ausgewertet, und busybox-unabhängig mit eigenem mount-Befehl gemountet, und im zweiten Teil wird "der Rest" abgehandelt. Also doch etwas aufweniger
Ich will gar nicht wissen, wie oft ich dann flashen muss, bis das zum 1. mal gescheit läuft....... Ok, vergessen wir es Dennoch vielen Dank für Eure Antworten
-
- Einsteiger
- Beiträge: 261
- Registriert: Donnerstag 15. November 2001, 00:00