nicht angemeldet
Linux -> gechrootete Umgebung erstellen
0 0 -1 0 -1 0 0 -1 0 -1 0 Fazit
-1
0
Linux -> gechrootete Umgebung erstellen
Hallo,
auf einem i686-pc-linux-gnu System versuche ich mir eine gechrootete Umgebung zu erstellen, um einen Webserver zu testen.
Nach anfänglichen Versuchen über |$ ldd /${binär}| mir alle Bibliotheken und Binäre zu kopieren, bin ich aber immer weider an der Linux-üblichen Verzeichnisstruktur gescheiter. Diese wollte ich in der Chroot-Umgebung folgendermaßen vereinfachen werden:
/chroot_dir
|
|-/bin
|
|-/etc
|
|-/htdocs
|
|-/include
|
|-/sbin
|
`-/tmp
Ganz klar, die zur Kompilierungszeit angegebenen Pfade für /usr (u. a.) sind nicht mehr auffindbar und damit war auch schon Ende mit diesem Versuch.
Daher hatte ich vergeblich versucht die Bibliotheken und Programme auf die gewünschte Verzeichnisstruktur abgestimmt selbst zu kompilieren. Jedoch liegt dem der gleiche Fehler zu grunde, da auch hier (beispielhaft mit) --prefix einen absoluten Pfad erwartet.
Gibt es eine Möglichkeit ./configure Parameter zu übergeben, womit die Pfade der Programme auf das Wurzelverzeichnis "/chroot_dir" verweisen und die installierten Dateien nicht im zugrundeliegendem Dateisystem versteut werden?
Derzeit habe ich mir ein stage1 von gentoo in das /chroot_dir entpackt. Damit konnte ich mich zwar chrooten und einzelne Bibliotheken aufsetzen, aber bereits beim Kompilieren von gcc gibt es einen Error.
./configure \ --prefix=/ \ --includedir=/include
Was kann/muß ich machen, um mir meine Chroot-Umgebung aufzubauen?
Gruß aus Berlin!
eddi
-
Sup!
Öhm... also eigentlich musst Du nur eine vernünftige Verzeichnisstruktur im /chroot/ aufbauen und die nötigen Libraries dorthin kopieren.
Etwas neu zu kompilieren, um die Verzeichnisstruktur zu vereinfachen ist IMHO keine so schlaue IDee.Hast Du verstanden, dass Du in der chroot-Umgebung nur die Sachen hast, die in dieser Umgebung sind?
Mir scheint es fast, als wolltest Du Programme so kompilieren, dass sie von ausserhalb gestartet im chroot laufen. Das geht natürlich nicht.
Das chroot ist wie ein eigenes System mit eigener Konfiguration.
Ein paar Sachen kannst Du übernehmen - z.B. das /proc im /chroot nochmal mounten - aber alles, was die Programme im chroot nutzen, muss auch im chroot vorhanden sein, und alles, was im chroot laufen soll, muss von innerhalb dieser Umgebung nach dem chroot-Befehl gestartet werden.Gruesse,
Bio
--
Keep your friends close, but your enemies closer!-
Hallo Bio,
Etwas neu zu kompilieren, um die Verzeichnisstruktur zu vereinfachen ist IMHO keine so schlaue IDee.
Hast Du verstanden, dass Du in der chroot-Umgebung nur die Sachen hast, die in dieser Umgebung sind?
Ja. (Darin sehe ich den essentiellen Vorteil im Einsatz später, jetzt geht es mir nur darum, daß mein Server nicht mal kurz das System ausradiert.)
Mir scheint es fast, als wolltest Du Programme so kompilieren, dass sie von ausserhalb gestartet im chroot laufen. Das geht natürlich nicht.
Nein. Sie sollen nur innerhalb funktionabel sein; also das genaue Gegenteil muß erreicht werden.
Das chroot ist wie ein eigenes System mit eigener Konfiguration.
Ein paar Sachen kannst Du übernehmen - z.B. das /proc im /chroot nochmal mounten - aber alles, was die Programme im chroot nutzen, muss auch im chroot vorhanden sein, und alles, was im chroot laufen soll, muss von innerhalb dieser Umgebung nach dem chroot-Befehl gestartet werden.Genau das ist mein Vorhaben. Wenn ich nun alle Programme bräuchte, würde ich mich mit dem stage1 von gentoo zufrieden geben.
Nun schreibst Du etwas zum mounten von /proc. Ich will ja nur erreichen, daß die Shell ihren Dienst tut, um den Server (PHP-Binär) zu unterhalten und Bindeglied zu weiteren Programme zu bilden, aber nicht ein Linux im Linux aufzubauen. Muß ich dann wirklich wieder udev proc und Konsorten rumschlagen?
Gruß aus Berlin!
eddi-
Hi,
Das chroot ist wie ein eigenes System mit eigener Konfiguration.
Ein paar Sachen kannst Du übernehmen - z.B. das /proc im /chroot nochmal mountenDas würde ich nicht machen, Bio, aber gut: ich bin auch paranoid und werde dazu noch dafür bezahlt.
- aber alles, was die Programme im chroot nutzen, muss auch im chroot vorhanden sein, und alles, was im chroot laufen soll, muss von innerhalb dieser Umgebung nach dem chroot-Befehl gestartet werden.
Genau das ist mein Vorhaben. Wenn ich nun alle Programme bräuchte, würde ich mich mit dem stage1 von gentoo zufrieden geben.
Einerseits zuviel, andererseits etwas zu wenig. je nach Programm. Ich würde auf alles, was Du laufen lassen möchtest ein 'ldd' ansetzen, was Du ja schon getan hast. Alles in eine Datei | sort | uniq usw.
Die nötige Verzeichnisstruktur kannst Du dann aus obiger Liste rausziehen, 'mkdir -p' ist dabei Dein Freund. Es gibt auch für viele Programme Howtos. Goolge gibt bei "chroot Linux Howto" plus $PROGNAME bereitwillig Auskunft. Nein, es gibt leider nix zentrales, zumindest wüßte ich jetzt nicht.Nun schreibst Du etwas zum mounten von /proc.
Naja, es würde so einiges erleichtern, da einige Programm beim Bauen gesagt bekamen, das es existiert und die sich dann darauf verlassen. Für den Anfang kannst Du es also tun.
Ich will ja nur erreichen, daß die Shell ihren Dienst tut, um den Server (PHP-Binär) zu unterhalten und Bindeglied zu weiteren Programme zu bilden, aber nicht ein Linux im Linux aufzubauen. Muß ich dann wirklich wieder udev proc und Konsorten rumschlagen?
Wenn Du soviele Programme, insbesondere die Shell brauchst, sind das entschieden zuviele. Was brauchst Du denn wirklich außer dem Apachen?
Oder möchtest Du wirklich ein ganzes System aufbauen? Dann würde ich UML empfehlen, das dürfte bedeutend einfacher sein.so short
Christoph Zurnieden
-
Hallo Christoph,
derzeit bastle ich an einem HTTP-Server geschreiben in PHP und ausgeführt über Shell durch das CLI-Binär. Für spätere Aufgaben sollen die Erweiterungen iconv, pcntl, posix, sockets, sysvsem und sysvshm modular angesprochen werden. Bei den Erweiterungen dio und sysmsg bin ich nicht weiter über deren grundsätzlich möglichen Nutzen hinausgekommen, aber auch diese können zum Einsatz kommen.
Im ersten Versuch geht es nun darum, von einem lauernden "sockets"-Prozess im Requestfall einen Kindprozes abzuspalten, der das Aufsuchen der angeforderten Resource übernimmt, diese gegebenenfalls ausliest, die Ausgabe verfertigt, absendet und stirbt.
Soweit das Vorhaben - aber bevor ich beim Testen mir das System gleich mal nebenbei ins Nirvana schicke, will ich dies in einer gechrooteten Umgebung tun.
Du hattest mich auf die zahlreichen google-Einträge verwiesen und den dort beschreibenen Tenor auch nochmals kurz dargelegt. Ich hätte nur gerne keine zusammenkopierte Umgebung, sondern mir dabei sehr gerne auch die Grundlagen erarbeitet, wie ich in einer solchen Umgebung, und eben (da mein Punkt, über den ich nicht hinwegkomme) für diese auch Programme innerhalb der Umgebung selbst kompiliere.
Das ganze Problem hat zwar einen konkreten Hintergrund mit meinem Vorhaben, soll mich aber in der Weise auch im Wissen um Linux selbst weiterbringen, um später auch eigene C-Programme austesten zu können, oder Progamme anderer (beta-Versionen) zu testen. User-Mode hatte ich mir in diesem Zusammenhang auch schon angesehen, scheint mir aber völlig überdimensioniert.
Auch ein stage von gentoo wird irgentwie zusammengestellt werden, dieses weist die übliche Linux-Verzeichnisstruktur. Daher schlußfolgere ich daraus, daß es eine Möglichkeit geben wird, Programme für eine Chroot-Umgebung zu kompilieren, denn ich kann mir nicht vorstellen, das dies immer nur aus einem bereits bestehendem System zusammenkopiert wird. Genau bei dieser (möglicherweise falschen) Vorstellung setzt meine Wissbegier an :)
Gruß aus Berlin!
eddi-
Hi,
derzeit bastle ich an einem HTTP-Server geschreiben in PHP und ausgeführt über Shell durch das CLI-Binär.
Ah, ja gut, dann brauchst Du eine Shell.
Ich würde mir aber eine abgespeckte Magerversion besorgen oder sogar besser eben selber schreiben. Du brauchst mit Sicherheit nicht alle Feinheiten und Buildins einer Bash, oder? ;-)Im ersten Versuch geht es nun darum, von einem lauernden "sockets"-Prozess im Requestfall einen Kindprozes abzuspalten, der das Aufsuchen der angeforderten Resource übernimmt, diese gegebenenfalls ausliest, die Ausgabe verfertigt, absendet und stirbt.
Erstmal fork(), gut. Hat aber jetzt nix mit dem Problem zu tun ;-)
Soweit das Vorhaben - aber bevor ich beim Testen mir das System gleich mal nebenbei ins Nirvana schicke, will ich dies in einer gechrooteten Umgebung tun.
Ganz schützt Dich chroot() nicht davor, das würde nur das weiter unten angeführte UML können.
Aber ich glaube das bei Deinem Vorhaben chroot() durchaus ausreichen würde. Man müßte schon sehr viel Mist bauen, das da noch etwas passieren könnte.Ich hätte nur gerne keine zusammenkopierte Umgebung, sondern mir dabei sehr gerne auch die Grundlagen erarbeitet,
Es ist aber wirklich nichts weiter als eine "zusammenkopierte Umgebung", wie Du das so abfällig beschreibst. Da gibt es keine linken Tricks, fiesen Kniffe oder sonstiges Gedöns, dsa ist schlicht kopiert.
wie ich in einer solchen Umgebung, und eben (da mein Punkt, über den ich nicht hinwegkomme) für diese auch Programme innerhalb der Umgebung selbst kompiliere.
Wenn Du Diene Quellpakete in der chroot-Umgebung auspackst kannst Du ganz normal bauen. "chroot" ist ja die Abkürzung für "change rootdirectory". Statt "/" ist halt "/usr/local/chroot/" das Wurzelverzeichnis für alle, die sich in "/usr/local/chroot/" befinden. Ein 'pwd' in der Bash in einem ge-chroot'd "/usr/local/chroot/" würde ganz einfach "/" ausgeben. Somit kannst Du auch jedes Quellpaket da drinen auspacken und dann mit "configure && make && make check && make install" bauen. Keine "--prefix" Änderung, nix.
Das ganze Problem hat zwar einen konkreten Hintergrund mit meinem Vorhaben, soll mich aber in der Weise auch im Wissen um Linux selbst weiterbringen, um später auch eigene C-Programme austesten zu können, oder Progamme anderer (beta-Versionen) zu testen. User-Mode hatte ich mir in diesem Zusammenhang auch schon angesehen, scheint mir aber völlig überdimensioniert.
Nun, ich hielt die 30 GiB Platte in meinem neuem Rechner auch für total überdimensioniert, habe sie aber trotzdem vollbekommen ;-)
Nein, für komplexere Tests, insbesondere im Netzwerkbereich ist UML wirklich sehr nützlich. Ich finde es sogar einfacher als den chroot-Kram, aber das mag Geschmacksache sein.
Für ein, zwei Progrämmchen mag dagegen chroot() einfacher sein.so short
Christoph Zurnieden
-
Re:
Wenn Du Diene Quellpakete in der chroot-Umgebung auspackst kannst Du ganz normal bauen. "chroot" ist ja die Abkürzung für "change rootdirectory". Statt "/" ist halt "/usr/local/chroot/" das Wurzelverzeichnis für alle, die sich in "/usr/local/chroot/" befinden. Ein 'pwd' in der Bash in einem ge-chroot'd "/usr/local/chroot/" würde ganz einfach "/" ausgeben. Somit kannst Du auch jedes Quellpaket da drinen auspacken und dann mit "configure && make && make check && make install" bauen. Keine "--prefix" Änderung, nix.
Da wäre immer noch das Problem, der sehr verzweigten Struktur, die sich in der Vaiable PATH an der Shell wiederspiegelt. Dies soll doch bewußt vereinfacht werden. Jedes Programm installiert sich ohne definierte Angaben von bspw. --prefix, wohin es will.
Du hattest auch etwas davon geschrieben, daß mit festsetzen des Wurzelverzeichnisse völlige Sicherheit erreicht wird. Wo sind dort die Lücken?
Gruß aus Berlin!
eddi-
Ups. So sollte es heißen:
Du hattest auch etwas davon geschrieben, daß mit Festsetzen des Wurzelverzeichnisse keine völlige Sicherheit erreicht wird.
-
Hi,
Da wäre immer noch das Problem, der sehr verzweigten Struktur, die sich in der Vaiable PATH an der Shell wiederspiegelt. Dies soll doch bewußt vereinfacht werden. Jedes Programm installiert sich ohne definierte Angaben von bspw. --prefix, wohin es will.
Meist nach /usr/local, wie sich das auch gehört. Da das Rootverzeichnis geändert wurde, z.B. nach "/usr/local/chroot/" wäre der komplette Pfad zum Binary "helloworld" aus Kernelsicht "/usr/local/chroot/usr/local", aus Sicht des Binaries "helloworld" wäre es jedoch ganz genau "/usr/local/helloworld".
D.h. das die Verzeichnisstruktur _von Außen_ ziemlich wüst aussieht, _von Innen_ jedoch ganz normal. Wenn Du die Quellpaket _im_ chroot-Verzeichnis auspackst und baust funktioniert sie Installation völlig normal. Was Du dann noch an Libs und anderem Zeug benötigst sagt Dir dann "./configure" schon. Da Du Gentoo benutzt sollte das noch weniger Probleme bereiten, das ist ja dafür ausgelegt aus den Quellen zu installieren.Du hattest auch etwas davon geschrieben, daß mit festsetzen des Wurzelverzeichnisse völlige Sicherheit erreicht wird. Wo sind dort die Lücken?
Es gibt einige typische Fehler beim chroot-Basteln, aber die dürftest Du kennen. Wenn nicht: sind leicht zu finden. Das Hauptproblem neben o.a. Schusseligkeit ist der Umstand, das es keine vollständig getrennte "Sandbox" ist, wie es z.B. bei UML der Fall wäre, (Selbst da nicht 100% aber das wäre dann wirklich vernachlässigbar) Du hast immer noch den gleichen Kernel. Es ist also nicht wirklich interessant für Dein Ansinnen und ich ärgere mich jetzt auch, es überhaupt erwähnt zu haben, denn der evt Schaden bestünde in Deinem(!) Fall eh nur im Höchstfall im Reboot. Mehr kann da eigentlich nicht passieren.
so short
Christoph Zurnieden
-
Re:
Meist nach /usr/local, wie sich das auch gehört. Da das Rootverzeichnis geändert wurde, z.B. nach "/usr/local/chroot/" wäre der komplette Pfad zum Binary "helloworld" aus Kernelsicht "/usr/local/chroot/usr/local", aus Sicht des Binaries "helloworld" wäre es jedoch ganz genau "/usr/local/helloworld".
Also bitte!
D.h. das die Verzeichnisstruktur _von Außen_ ziemlich wüst aussieht, _von Innen_ jedoch ganz normal. Wenn Du die Quellpaket _im_ chroot-Verzeichnis auspackst und baust funktioniert sie Installation völlig normal. Was Du dann noch an Libs und anderem Zeug benötigst sagt Dir dann "./configure" schon. Da Du Gentoo benutzt sollte das noch weniger Probleme bereiten, das ist ja dafür ausgelegt aus den Quellen zu installieren.
Wie im Ausgangspost dargelegt, hatte ich das alles schon durch und scheitere dabei gcc in dieser Umgebung aufzusetzen.
Gruß aus Berlin!
eddi-
Hi,
Also bitte!
Wir sind hier nicht alleine, es lesen noch evt andere mit, die unsere Kürzel nicht verstehen!
Wie im Ausgangspost dargelegt, hatte ich das alles schon durch und scheitere dabei gcc in dieser Umgebung aufzusetzen.
Das hast Du zwar nicht gesagt, das Dir der GCC Kopfschmerzen bereitet (welcher genau?) aber gut, ich werde dem nachgehen. Gab's irgendwelche Fehlermeldungen?
BTW: ein Compiler im chroot? Naja![ich häng' das andere Post mal hier an]
Ja: statisch bauen. Ist auch eine nicht unübliche Vorgehensweise bei chroot().
Ja. Was die bash angeht, so bringt sie dankenswerter Weise den Parameter --enable-static-link mit. Das ist aber leider nicht immer der Fall. Was mache ich dann?
Also bitte ich um mehr als zwei Sätze im Cheatah-stil!Na, _so_ gut bin ich nun wirklich nicht!
Aber trotzdem danke! ;-)Wenn's nun kein --enable-static-link o.ä. gibt bist Du -- so leid es mir tut -- SOL.
Dann mußt Du wohl oder übel aus der "normalen" Installation per 'ldd' o.ä. die Libnamen rausziehen und nach chroot kopieren. 'ldconfig' nicht vergessen.so short
Christoph Zurnieden
-
Hallo Christoph,
vier antwortenlang habe ich nun runtergeschluck, jetzt platzt mir der Kragen.
Wir sind hier nicht alleine, es lesen noch evt andere mit, die unsere Kürzel nicht verstehen!
[...] -- so leid es mir tut -- SOL.
Da waren keine kürzel, sonder Du hast mir das offensichtlicher erklärt. Vielen Dank!
Wie im Ausgangspost dargelegt, hatte ich das alles schon durch und scheitere dabei gcc in dieser Umgebung aufzusetzen.
Das hast Du zwar nicht gesagt, das Dir der GCC Kopfschmerzen bereitet (welcher genau?) aber gut,
Wer lesen kann ist klar im Vorteil https://forum.selfhtml.org/?t=106548&m=660409
"...Derzeit habe ich mir ein stage1 von gentoo in das /chroot_dir entpackt. Damit konnte ich mich zwar chrooten und einzelne Bibliotheken aufsetzen, aber bereits beim Kompilieren von gcc gibt es einen Error..."
ich werde dem nachgehen. Gab's irgendwelche Fehlermeldungen?
Lieber nicht.
BTW: ein Compiler im chroot? Naja!
Guten Morgen - ich will nicht hin und her kopieren (vgl.: https://forum.selfhtml.org/?t=106548&m=660495, ich will es in meine Strukur installieren (vgl.: https://forum.selfhtml.org/?t=106548&m=660409). Die einkompilierten Pfade in den Programmen beziehen sich aber immer auch ein Wurzelverzeichnis, also muß zur Erstellung der Umgebung auch ersteinmal ein Kompiler einsetzen.
Ich habe mir sagen lassen, man kann diese Programme auch wieder herauslöschen, oder sie auf einer Extrapartition bei bedarf in die Umgebung mounten...
Also bitte ich um mehr als zwei Sätze im Cheatah-stil!
Na, _so_ gut bin ich nun wirklich nicht!
Auch wenn Cheatah hier und da auch Fehler macht, so habe ich nie erlebt, daß er sich bei einer Hilfestellung zur Selbsthilfe einem Problemvortrag derart oberflächlich gewidmet hätte.
Aber trotzdem danke! ;-)
Bitte, bitte!
Wenn's nun kein --enable-static-link o.ä. gibt bist Du -- so leid es mir tut -- SOL.
Dann mußt Du wohl oder übel aus der "normalen" Installation per 'ldd' o.ä. die Libnamen rausziehen und nach chroot kopieren. 'ldconfig' nicht vergessen.Ist denn das so schwer zu verstehen, daß ich mir diese Umgebung mit meiner Struktur selbst zusammenbauen will?
#############
In https://forum.selfhtml.org/?t=106548&m=660432 habe ich extra geschrieben:Ich will ja nur erreichen, daß die Shell ihren Dienst tut, um den Server (PHP-Binär) zu unterhalten und Bindeglied zu weiteren Programme zu bilden, aber nicht ein Linux im Linux aufzubauen.
Darauf hin kommst Du in https://forum.selfhtml.org/?t=106548&m=660453 mit:
Was brauchst Du denn wirklich außer dem Apachen? Oder möchtest Du wirklich ein ganzes System aufbauen?
Das ist doch keine Betrachtung eines Problemaufrisses, das würde ich Vergackeiern nennen.
Daraufhin, insbesondere auf die abwegige Aussage von Dir, daß ich den Apachen bräuchte, schreibe ich Dir detailiert, was das ursprüngliche Ansinnen ist (vlg.: https://forum.selfhtml.org/?t=106548&m=660495)Daraufhin schreibst Du in https://forum.selfhtml.org/?t=106548&m=660539
Hat aber jetzt nix mit dem Problem zu tun ;-)
#############
so short
Langsam wird mir klar, warum es dementsprechend bei Dir auch "so long" geben wird, das kommt dann vermutlich, wenn Du die Problematik verstanden hast...
Es gab hier mal einen Beitrag von Lude, warum Stammposter so selten Fragen stellen. Ich habe jetzt einen Grund gefunden:
Man unterliegt oberflächlichster Betrachtung von Profis, kann sich nur verschaukelt fühlen und bekommt Lösungsansätze, die einem offensichtlich schon bekannt sind und deren Pferdefüße man mit versucht zu umgehen. Nur bei der Umsetzung bräuchte man Hilfe, aber die ist hier nicht zu erwarten.Gruß aus Berlin!
eddi-
Hi,
vier antwortenlang habe ich nun runtergeschluck, jetzt platzt mir der Kragen.
Warum schluckst Du runter, das gibt nur Magengeschwüre, also immer _sofort_ raus damit.
Wer lesen kann ist klar im Vorteil https://forum.selfhtml.org/?t=106548&m=660409
Ah, Mißverständnis, ich hatte das nur auf das Bauen bezogen, sorry.
BTW: ein Compiler im chroot? Naja!
Guten Morgen - ich will nicht hin und her kopieren
Warum denn nicht um Gotteswillen? Du kannst meinetwegen alles im chroot neu bauen, aber laß Dir gesagt sein: es ist hinterher haargenau das Gleiche. Der einzige Unterschied ist der, das es viel länger dauert udn deutlcih komplizierter ist (denn es funktioniert ja nicht aus dem Stand, wie Du berichtet hast) als ein simples 'cp'.
Du brauchst Dich dabei auch um keine fest eingebauten Pfade kümmern, da ja das Wurzelverzeichnis geändert wurde und deshalb alles völlig korrekt ist. Da Du wahrscheinlich auch schon im Grundsystem ein Gentoo sitzen hast, entfällt auch die Optimierung. Die zu kopierenden Dateien sind ja bereits auf Dein System hin optimiert.Wenn Dir das zuviel Gedöns mit den ganzen Libs ist, kannst Du die Teile natürlich auch nochmal und dann statisch gelinkt bauen lassen. Das kannst Du dann aber ebenfalls im normalem System, da die Pfade im chroot genau die gleichen wie "normal" sind.
Ist denn das so schwer zu verstehen, daß ich mir diese Umgebung mit meiner Struktur selbst zusammenbauen will?
Da könnte ich natürlich zurückraunzen, das das im Endeffekt rein gar keinen Unterschied macht. Ob Du in den chroot rein kopierst oder die Programme darin baust, es ist völlig egal.
(Vorrausgesetzt natürlich, das Du beim ./configure keine Veränderungen vornimmst, sondern beide gleich baust.)Daraufhin schreibst Du in https://forum.selfhtml.org/?t=106548&m=660539
Hat aber jetzt nix mit dem Problem zu tun ;-)
Hat es auch nicht.
Man unterliegt oberflächlichster Betrachtung von Profis, kann sich nur verschaukelt fühlen und bekommt Lösungsansätze, die einem offensichtlich schon bekannt sind und deren Pferdefüße man mit versucht zu umgehen. Nur bei der Umsetzung bräuchte man Hilfe, aber die ist hier nicht zu erwarten.
Die kannst Du hier wirklich nicht erwarten, wenn der Lösungsansatz an sich schlecht ist. Wenn Du an Dein Hühneraugenproblem mit einem Werkzeug der Firma Heckler&Koch gehen möchtest und fragst mich nach der Beseitigung von Ladehemmungen und ich empfehle Dir den Besuch beim Fußpfleger Deines Vertrauens, dann regst Du Dich total darüber auf, warum ich Dir nicht beim Problem mit den Ladehemmungen geholfen habe?
Simile claudicat? Ach, omne simile claudicat!Du kannst gerne den schweren Weg gehen, aber scheiß' mich nicht nachher dafür noch an, denn ich habe Dir den leichten gewiesen. Ob's der einzige ist weiß ich nicht, ist einfach der leichteste, den ich kenne.
so short
Christoph Zurnieden
-
Re:
Warum denn nicht um Gotteswillen? Du kannst meinetwegen alles im chroot neu bauen, aber laß Dir gesagt sein: es ist hinterher haargenau das Gleiche. Der einzige Unterschied ist der, das es viel länger dauert udn deutlcih komplizierter ist (denn es funktioniert ja nicht aus dem Stand, wie Du berichtet hast) als ein simples 'cp'.
Du brauchst Dich dabei auch um keine fest eingebauten Pfade kümmern, da ja das Wurzelverzeichnis geändert wurde und deshalb alles völlig korrekt ist. Da Du wahrscheinlich auch schon im Grundsystem ein Gentoo sitzen hast, entfällt auch die Optimierung. Die zu kopierenden Dateien sind ja bereits auf Dein System hin optimiert.Wenn Dir das zuviel Gedöns mit den ganzen Libs ist, kannst Du die Teile natürlich auch nochmal und dann statisch gelinkt bauen lassen. Das kannst Du dann aber ebenfalls im normalem System, da die Pfade im chroot genau die gleichen wie "normal" sind.
NEIN - Verdammt noch mal (vgl.: https://forum.selfhtml.org/?t=106548&m=660409):
"...Diese wollte ich in der Chroot-Umgebung folgendermaßen vereinfachen [...]:
/chroot_dir
|
|-/bin
|
|-/etc
|
|-/htdocs
|
|-/include
|
|-/sbin
|
`-/tmp..."
Da könnte ich natürlich zurückraunzen, das das im Endeffekt rein gar keinen Unterschied macht. Ob Du in den chroot rein kopierst oder die Programme darin baust, es ist völlig egal.
(Vorrausgesetzt natürlich, das Du beim ./configure keine Veränderungen vornimmst, sondern beide gleich baust.)Da war ich schonlängst! Ich will nur _EIN_ Verzeichnis für Binäre (/bin) und _EIN_ weiteres für sicherheitsrelevante Programme (/sbin) haben. Daraus folgt zwangsläufig eine Zuordung von Parametern für die Installationen der einzelen Programme beim Aufruf von ./configure, sonst würde ich hier nicht nachfragen und mit den allseits nachzulesenden Varianten des simplen kopierens nehmen.
Wenn Du der Meinung bist, mein Weg sei der "schwerere Weg", so stimme ich Dir auch zu. Aber vielleicht ist Dir auch mal in den Sinn gekommen, daß dieser in allen Punkten der Durchführung vom Installieren bis zum eigentlichen Einsatz erheblich mehr Bezug zum Späteren Einsatz aufweist. Und im Übrigen:
https://forum.selfhtml.org/?t=106548&m=660495:
Das ganze Problem hat zwar einen konkreten Hintergrund mit meinem Vorhaben, soll mich aber in der Weise auch im Wissen um Linux selbst weiterbringen, um später auch eigene C-Programme austesten zu können, oder Progamme anderer (beta-Versionen) zu testen. User-Mode hatte ich mir in diesem Zusammenhang auch schon angesehen, scheint mir aber völlig überdimensioniert.
Das Installieren von Programmen innerhalb einer Chroot-Umgebung steht nicht zur Disposition, so lange das einzige Argument ist, daß es mühseliger ist. Das Aufsetzen eines gentoo-System ist auch mühseliger, als das kopieren eines SuSE-Systems von der DVD.
Gruß aus Berlin!
eddi-
Hi,
"...Diese wollte ich in der Chroot-Umgebung folgendermaßen vereinfachen [...]:
Das vereinfacht aber nix außer dem Verzeichnisbaum, aber der ist ja nun wirklich nicht gerade hochkomplex. Du hast dabei wirklich nichts gewonnen, glaub's mir.
Da war ich schonlängst! Ich will nur _EIN_ Verzeichnis für Binäre (/bin) und _EIN_ weiteres für sicherheitsrelevante Programme (/sbin) haben. Daraus folgt zwangsläufig eine Zuordung von Parametern für die Installationen der einzelen Programme beim Aufruf von ./configure, sonst würde ich hier nicht nachfragen und mit den allseits nachzulesenden Varianten des simplen kopierens nehmen.
Das funktioniert dann ähnlich, wie das statische Linken. Du kannst alles in der normalen Umgebung bauen (dann halt mit den entsprechenden Optionen beim ./configure) und die so erhaltenen Teile in den chroot kopieren. Du mußt wirklich nix, aber auch rein gar nix im chroot selber bauen. Ich glaube auch nicht, das Gentoo dafür vorgesehen ist, das es sich in einem chroot installiert, das müßtest Du händisch machen. Also erstmal alle Dev-Tools statisch gelinkt bauen und in's chroot rüberkopieren, da der Gentoo-GCC ja nicht funktioniert, wie Du sagtest. Dann kannst Du mit denen dann Deine Pakete im chroot selber bauen.
Wenn Du der Meinung bist, mein Weg sei der "schwerere Weg", so stimme ich Dir auch zu. Aber vielleicht ist Dir auch mal in den Sinn gekommen, daß dieser in allen Punkten der Durchführung vom Installieren bis zum eigentlichen Einsatz erheblich mehr Bezug zum Späteren Einsatz aufweist.
Ein Einsatz in einem Dateisystem, das nur 5 Verzeichnisse erlaubt? Kenne ich nicht. Könnte ich Dir aber bauen >;->
Das Installieren von Programmen innerhalb einer Chroot-Umgebung steht nicht zur Disposition, so lange das einzige Argument ist, daß es mühseliger ist.
Diese "mühseliger" zieht jedoch einen ganzen Rattenschwanz an Konsequenzen nach sich. So ist "mühseliger" stets ein Quell an Fehlern. An _unnötigen_ Fehlern!
Grundprinzip beim Programmieren ist KISS:"Keep it simpel, stupid!".
Ein heiliges Prinzip bei Flugzeugentwerfern ist:"Entweder ein neues Flugzeug mit alten Motoren oder ein altes Flugzeug mit neuen Motoren, niemals beides gleichzeitig!", das haben die guten Programmierer ebenfalls übernommen.Es sind verdammt viele blutige Nasen die Ursache dieser beiden Sprüche, warum ignorierst Du sie so vehement?
Warum willst unbedingt die ganze, lang gewachsene und standardtisierte Unix-Verzeichnisstruktur umschmeißen? Weil Du meinst, das irgendwann einmal gebrauchen zu können? Wann denn bitteschön und vor allem: wobei? Klar gäbe es Einsatzmöglichkeiten, aber möchtest Du wirklich Deine eigene Distribution herausgeben? Das würde sehr tiefes Systemwissen erfordern und da könnte so ein Experiment wie Deines helfen. Aber dafür mußt Du das dafür nötige Handwerkzeug schon sehr gut, besser: perfekt beherrschen. Du mußt die Interna des ELF-Formates kennen wie Deine Westentasche, den Linker, den Compiler ...
Partikelwissen -- und mehr kannst Du auf Deine jetzige Methode nicht erwerben -- führt Dich nirgendwohin. Ich kann Distributionen erstellen, das gehört zu meinem Job und ich habe verdammt lange gebraucht bis ich dahin kam. (da ich also weiß, was für eine Schweinearbeit das ist, tue ich das auch nicht sondern nehm ein *BSD ;-) Ich kann Dich also an die Hand nehmen und Dich durch die Fährnisse Deines Vorhabens führen. Danach weißt Du ganz genau, _wie_ es funktioniert. Du weißt aber kein Stück _warum_ es so funktioniert. Und genau dieses Warum ist nötig, damit Du daraus lernen kannst.Mach also alles einfach und der Reihe nach:
- chroot durch einfaches Kopieren füllen
- das eine oder andere Programm dort testen
- den Umgang mit den Dev-Tools erlernen
- das ELF-Format kennenlernen und das Linken
5-99) Üben - dem chroot eine eigene Verzeichnisstrukur aufbürden
- alle Dev-Tools in's chroot packen
- erste Versuche *from scratch* im chroot
103-999) Üben - Alle Distributionen "irgendwie Scheiße" finden und sich selber eine bauen.
Während all dem hast Du noch nebenbei und auf die harte Tour C (ist nunmal immer noch _die_ Unixsprache wenn's nah an's Metall geht), Shellskript, Perl, Misc. und Fluchen gelernt. Und auch nicht nur oberflächlich sondern bis in's Mark!
Ich kann natürlich nicht behaupten, das man nicht auch alles auf einmal lernen kann, aber dran glauben muß ich nicht. Das einzige, was möglich ist: wenn Du eine richtig faule Socke und vor allem geschickt darin bist, dann kannst Du vielleicht mit der Zeit unterscheiden, was Du wissen mußt, nachschlagen kannst und was Du an Dritte abgeben darfst.
Das Aufsetzen eines gentoo-System ist auch mühseliger, als das kopieren eines SuSE-Systems von der DVD.
Naja, was das betrifft ist es doch eher Geschmacksache, viel Unterschied finde ich da nicht. Aber ich kenne die ganz neuen SuSEs auch nicht.
so short
Christoph Zurnieden
-
Ich glaube auch nicht, das Gentoo dafür vorgesehen ist, das es sich in einem chroot installiert, das müßtest Du händisch machen. Also erstmal alle Dev-Tools statisch gelinkt bauen und in's chroot rüberkopieren, da der Gentoo-GCC ja nicht funktioniert, wie Du sagtest. Dann kannst Du mit denen dann Deine Pakete im chroot selber bauen.
Dochdoch, dass ist bei Gentoo so vorgesehen. Dafür gibt es die Stage-Archive, die man in den chroot entpackt; danach wechselt man dann wirklich ins chroot und arbeitet dort mit einem vorkonfigurierten Mini-Basis-System weiter. Wobei bei Stage1 dann doch wieder alles neu gebaut wird.
Und ja, bei Gentoo _muss_ man alles von Hand machen. Siehe auch http://www.gentoo.org/doc/en/handbook/2005.0/handbook-x86.xml
-
Moin,
"...Diese wollte ich in der Chroot-Umgebung folgendermaßen vereinfachen [...]:
Das vereinfacht aber nix außer dem Verzeichnisbaum, aber der ist ja nun wirklich nicht gerade hochkomplex. Du hast dabei wirklich nichts gewonnen, glaub's mir.
In dem Moment, wo man nur fünf Verzeichnisse zu sonst zig schon dahingehend, daß wenn man Programme hat, die Daten auf ins Dateisystem ablegen, nicht allzulange im Fehlerfall suchen muß. Man kann zudem auch die Größe der Systemvariablen überschaubarer machen. Zusätzliche installierte Tools sind einfach auffindbar.
Da war ich schonlängst! Ich will nur _EIN_ Verzeichnis für Binäre (/bin) und _EIN_ weiteres für sicherheitsrelevante Programme (/sbin) haben. Daraus folgt zwangsläufig eine Zuordung von Parametern für die Installationen der einzelen Programme beim Aufruf von ./configure, sonst würde ich hier nicht nachfragen und mit den allseits nachzulesenden Varianten des simplen kopierens nehmen.
Das funktioniert dann ähnlich, wie das statische Linken. Du kannst alles in der normalen Umgebung bauen (dann halt mit den entsprechenden Optionen beim ./configure) und die so erhaltenen Teile in den chroot kopieren.
Dennoch verbleiben Headerdateien im $includedir - können gar wichtige Headerdateien des System beim installieren überschreiben. Weiterhin bringen manche Programme auch zusätzliche Tools mit, die zwar nicht schaden, aber das System unnötig zumüllen.
Du mußt wirklich nix, aber auch rein gar nix im chroot selber bauen.
Du kennst den kennst den Unterschied zwischen "müssen" und "wollen"?
Ich glaube auch nicht, das Gentoo dafür vorgesehen ist, das es sich in einem chroot installiert, das müßtest Du händisch machen.
Tjo Dein Glaube scheint sich in diesem Punkt nicht mit dem Wissen von vielen Gentoonutzen und mir zu denken. Aber was solls.
Also erstmal alle Dev-Tools statisch gelinkt bauen und in's chroot rüberkopieren, da der Gentoo-GCC ja nicht funktioniert, wie Du sagtest.
Nein, wie Du es verstehen willst...
Ein Einsatz in einem Dateisystem, das nur 5 Verzeichnisse erlaubt? Kenne ich nicht. Könnte ich Dir aber bauen >;->
Du schweifst ab!
Das Installieren von Programmen innerhalb einer Chroot-Umgebung steht nicht zur Disposition, so lange das einzige Argument ist, daß es mühseliger ist.
Diese "mühseliger" zieht jedoch einen ganzen Rattenschwanz an Konsequenzen nach sich. So ist "mühseliger" stets ein Quell an Fehlern. An _unnötigen_ Fehlern!
Grundprinzip beim Programmieren ist KISS:"Keep it simpel, stupid!".
Ein heiliges Prinzip bei Flugzeugentwerfern ist:"Entweder ein neues Flugzeug mit alten Motoren oder ein altes Flugzeug mit neuen Motoren, niemals beides gleichzeitig!", das haben die guten Programmierer ebenfalls übernommen.Es sind verdammt viele blutige Nasen die Ursache dieser beiden Sprüche, warum ignorierst Du sie so vehement?
Ganz einfach: Gentoo macht es vor, daß nichts außergewöhnliches daran ist, selbst ein ganzes Betriebssystem in einer Chroot-Umgebung aufzusetzen. Aber selbst nicht einmal so hochgesetze Träume hege ich. Und da kommst Du mit Flugzeugen.
Du schweifst ab!
Warum willst unbedingt die ganze, lang gewachsene und standardtisierte Unix-Verzeichnisstruktur umschmeißen? Weil Du meinst, das irgendwann einmal gebrauchen zu können?
Die davon Versprochenen Vorteile sind oben angegeben.
Wann denn bitteschön und vor allem: wobei? Klar gäbe es Einsatzmöglichkeiten, aber möchtest Du wirklich Deine eigene Distribution herausgeben? Das würde sehr tiefes Systemwissen erfordern und da könnte so ein Experiment wie Deines helfen. Aber dafür mußt Du das dafür nötige Handwerkzeug schon sehr gut, besser: perfekt beherrschen. Du mußt die Interna des ELF-Formates kennen wie Deine Westentasche, den Linker, den Compiler ...
Du schweifst ab!
Selbst als Programmierer müßte Dir klar sein, daß Du Dich auf nichts verlassen darfst, auch nicht auf quasistandardisierte Verzeichnisstrukturen, insbesondere wenn dies der User selbst verändern kann. Also bitte was soll dieser realitätsverne Vergliech zu einem Betriebssystem?
Partikelwissen -- und mehr kannst Du auf Deine jetzige Methode nicht erwerben -- führt Dich nirgendwohin. Ich kann Distributionen erstellen, das gehört zu meinem Job und ich habe verdammt lange gebraucht bis ich dahin kam.
Christoph, ich weiß seit der letzten Diskussion, daß Du verdammt gut bist, aber das steht auch gar nicht im Zweifel! Das ärgerlichste ist bei Dir Dein Polemisieren statt durchdringendes Argumentieren.
(da ich also weiß, was für eine Schweinearbeit das ist, tue ich das auch nicht sondern nehm ein *BSD ;-) Ich kann Dich also an die Hand nehmen und Dich durch die Fährnisse Deines Vorhabens führen. Danach weißt Du ganz genau, _wie_ es funktioniert. Du weißt aber kein Stück _warum_ es so funktioniert. Und genau dieses Warum ist nötig, damit Du daraus lernen kannst.
Tjo, da hatte ich Dir letztemal auch eine Cola versprochen (Champagner kann ich mir als kleiner Graphiker nicht leisten). ;(
Nichts desto Trotz nehme ich dieses Angebot hiermit an. Hilf mir über den Tellerrand, aber bitte mit Argumenten und nicht mit abwegigen Debatten über selbsterstellte Distributionen!
Während all dem hast Du noch nebenbei und auf die harte Tour C (ist nunmal immer noch _die_ Unixsprache wenn's nah an's Metall geht), Shellskript, Perl, Misc. und Fluchen gelernt. Und auch nicht nur oberflächlich sondern bis in's Mark!
Nebenher fange ich auch an C zu probieren, aber:
Du schweifst ab!
Ich kann natürlich nicht behaupten, das man nicht auch alles auf einmal lernen kann, aber dran glauben muß ich nicht. Das einzige, was möglich ist: wenn Du eine richtig faule Socke und vor allem geschickt darin bist, dann kannst Du vielleicht mit der Zeit unterscheiden, was Du wissen mußt, nachschlagen kannst und was Du an Dritte abgeben darfst.
Ich wollte mich nicht als Chef qualifizieren, sondern eine Chroot-Umgebung aufbaun, aber:
Du schweifst ab!
Das Aufsetzen eines gentoo-System ist auch mühseliger, als das kopieren eines SuSE-Systems von der DVD.
Naja, was das betrifft ist es doch eher Geschmacksache, viel Unterschied finde ich da nicht. Aber ich kenne die ganz neuen SuSEs auch nicht.
Es ist auch eine spührbare Frage der Geschwindigkeit, aber:
Du schweifst ab!
Gruß aus Berlin!
eddi-
Hi,
Dennoch verbleiben Headerdateien im $includedir - können gar wichtige Headerdateien des System beim installieren überschreiben. Weiterhin bringen manche Programme auch zusätzliche Tools mit, die zwar nicht schaden, aber das System unnötig zumüllen.
Wenn ich bei einem korrekt "autoconf-iertem" Paket ein './configrue --help' mache kommt ziemlich oben folgendes:
[...]
--program-prefix=PREFIX prepend PREFIX to installed program names
--program-suffix=SUFFIX append SUFFIX to installed program names
--program-transform-name=PROGRAM
run sed PROGRAM on installed program names
[...]Du kannst also die Programme nennen, wie Du lustig bist.
Ich glaube auch nicht, das Gentoo dafür vorgesehen ist, das es sich in einem chroot installiert, das müßtest Du händisch machen.
Tjo Dein Glaube scheint sich in diesem Punkt nicht mit dem Wissen von vielen Gentoonutzen und mir zu denken.
Du sagtest, das es nicht funktioniert und ich habe meine Witzchen drüber gemacht. Zugegebenermaßen sogar mit vollem Bewußtsein darüber, das Leute, die in ihrer Sig ein Gentoo-Logo haben darauf extrem empfindlich reagieren.
Also erstmal alle Dev-Tools statisch gelinkt bauen und in's chroot rüberkopieren, da der Gentoo-GCC ja nicht funktioniert, wie Du sagtest.
Nein, wie Du es verstehen willst...
Funktioniert nicht ist funktioniert nicht, da gibt es nix mißzuverstehen.
Ganz einfach: Gentoo macht es vor, daß nichts außergewöhnliches daran ist, selbst ein ganzes Betriebssystem in einer Chroot-Umgebung aufzusetzen.
Und warum funktioniert das dann bei Dir nicht?
Selbstverständlich kann ich ein ganzes Betriebsystem in einer chroot-Umgebung aufsetzen, das funktioniert z.B. mit dem letzthin vorgestelltem UML. Gut, das war jetzt etwas unfaire Beckmesserei, sorry.Warum willst unbedingt die ganze, lang gewachsene und standardtisierte Unix-Verzeichnisstruktur umschmeißen? Weil Du meinst, das irgendwann einmal gebrauchen zu können?
Die davon Versprochenen Vorteile sind oben angegeben.
Meinst Du nicht auch, das Du es ganz sein lassen solltest, wenn Dich ein paar Verzeichnisse mehr schon irritieren können?
Du schweifst ab!
Das dritte Mal schon, vielleicht sollte ich mich im nächstem Leben mal als Komet bewerben? Was bräuchte man denn da für einen Abschluß?
Selbst als Programmierer müßte Dir klar sein, daß Du Dich auf nichts verlassen darfst, auch nicht auf quasistandardisierte Verzeichnisstrukturen, insbesondere wenn dies der User selbst verändern kann. Also bitte was soll dieser realitätsverne Vergliech zu einem Betriebssystem?
Wenn der Nutzer etwas ändert, das anderweitig mit einem Standard belegt ist, dann tut er das auf eigenes Risiko. Es gibt einige Standard, an die muß sich der Programmierer nunmal einfach halten. Was Du meinst ist der Umstand, das er selbstverständlich auch voraussetzen muß, das er nichts voraussetzen kann. Anhand von autoconf: Der Benutzer hat die Möglichkeit die Installationspfade zu ändern, Programmnamen und noch dies und das. Der Programmierer muß also alles so allgemein halten, das es auch bei der abstrusesten Konfiguration noch funktioniert. Wenn jedoch vom Benutzer gar nichts geändert wird gelten alle aktuellen Standards.
Christoph, ich weiß seit der letzten Diskussion, daß Du verdammt gut bist, aber das steht auch gar nicht im Zweifel! Das ärgerlichste ist bei Dir Dein Polemisieren statt durchdringendes Argumentieren.
Ja, ich lasse mich oft dazu verleiten.
Nichts desto Trotz nehme ich dieses Angebot hiermit an. Hilf mir über den Tellerrand, aber bitte mit Argumenten und nicht mit abwegigen Debatten über selbsterstellte Distributionen!
Das ist hier nicht abwegig, zumindest nicht so ganz, da Du im chroot *from scratch* arbeiten mußt, das Dingen ist einfach _leer_ bis auf die Verbindung zum Kernel. Du mußt also nicht genau, wie bei einer Distribution von Null anfangen, da Du den Kernel schon drin hast und gebootet. Noch ein kleiner Unterschied: Du hast immer die gleiche Hardware. Der größte Ärger beim Distributionsbauen ist also schonmal von anderen erledigt worden, du mußt nur noch für Änderungen sorgen. Die möchtest Du mittels des Gentoo-Installateurs tun.
Das funktioniert jedoch nicht. Also mußt Du das von Hand machen oder den Gentoo-Installateur reparieren. (Vermute jedoch, wie Du wahrscheinlich auch selbst, nur einen Bedienfehler) Hier mal die Methode "per Hand":- chroot einrichten. Ich gehe im weiteren davon aus, da Du das in /home/eddi/knast eingerichtet hast
- wir brauchen zum Bauen alle nötigen Werkzeuge und jetzt kommt Dein Wunsch nach wirrer, pardon, geänderter Verzeichnisstruktur zum tragen. Fast alle Entwicklerwerkzeuge sind auf deutlich mehr und teilweise auch in völlig andere Verzeichnisse installiert, als Du möchtest. Also mußt Du die neu bauen, ist zumindest die einfachste Lösung. Das geht recht simpel wenn die Pakete Autoconf benutzen. Ich gehe im weiteren mal vollkommen willkürlich davon aus, das Du das Prefix auf '/home/eddi/buildtools/' gesetzt hast. Wenn die Möglichkeit zum statischem Linken gegeben ist sollte man das ausnutzen. Ein paar Libs (die statischen, meist *.a) wirst Du aber nachher noch in den chroot temporär kopieren müssen. Einfacher wäre es aber mit dynamischen Libs zu arbeiten. Wenn Dir aber da das vorgegeben Installationsverzeichnis nicht gefällt mußt Du entweder mit den Binutils spielen, Wrapper um Deine Programme wickeln oder neu bauen. Aber Du hast Recht, ich schweife mal wieder ab. Der reihe nach ist's besser.
- alles von /home/eddi/buildtools/ nach /home/eddi/knast/home/eddi/buildtools/ kopieren. Funktion kontrollieren, denn meist hat man irgendwas vergessen. - alle gewünschten Programmpakete in /home/eddi/knast/home/eddi/buildtools/ kopieren, auspacken, nach Wunsch konfigurieren, bauen und installieren. Wenn irgendeine Lib fehlt beschweren sich in der Reihenfolge ./configure, Compiler/Interpreter, Programm. Um letzteres herauszubekommen ist eigentlich das 'make check' vorgesehen, das aber leider seltenst benutzt wird (nur bei Perlpaketen findet man es wirklich regelmäßig), das installierte Programm ist also versuchsweise zu starten. 'ldd' kann evt auch helfen. Kommt es zu merkwürdigen Abstürzen ist 'strace' Dein Freund.
Da Du eine vom Standard abweichende Verzeichnisstruktur haben möchtest -- was ja der einzige Grund für den ganzen Driss ist -- würde ich empfehlen fehlende Libs im chroot zu bauen und die Installation per Autoconf zu regeln, wie bei den Programmen oben auch. Trotz langjährigen Kampfes gegen diese Unsitte haben einige Libs noch Pfade fest eingebaut, was sich mitunter ja noch nicht einmal vermeiden läßt. Willst Du also wie oben angedeutet Ärger umgehen baue sie im chroot neu. - nicht jedes Programm besitzt ein Autoconf. Das ist zu individuell um hier behilflich sein zu können, das mußt Du leider selber lernen. Es ist aber auch nicht wirklich schwierig.
- einige Programm, die Du installieren möchtest wollen evt Dinge, die Du nicht bereitgestellt hast bzw nicht bereitstellen willst. Das /proc System kannst Du z.B. einfach einhängen, andere Dinger mögen jedoch nicht so simpel sein. Es ist dann zu überlegen, ob nicht ein vollständiges Parallelsystem (UML, VMWare o.ä.) besser wäre.
So, das wäre jetzt die grobe Richtung.
Nebenher fange ich auch an C zu probieren, aber:
Du schweifst ab!
Das vierte Mal! Was verdient man denn so als Komet?
Du schweifst ab!
Fünfmal? Also: ich habe gerade das Arbeitsamt angerufen, die haben nicht nur keine Stelle frei, was ja ncoh normal ist, sondern wissen gar nicht, das es den Beruf "Komet" überhaupt gibt! Ja, hält man sowas denn für möglich? Sachen gibt's!
Naja, was das betrifft ist es doch eher Geschmacksache, viel Unterschied finde ich da nicht. Aber ich kenne die ganz neuen SuSEs auch nicht.
Es ist auch eine spührbare Frage der Geschwindigkeit
Verglichen mit welcher anderen Distribution? Verglichen mit "nur Kernel selber bauen", "nur Kernel und Grundlibs selber bauen"? Verglichen mit einer auf eine Prozessorfamilie optimierten Distribution?
Du schweifst ab!
Aller guten Dinge sind sechs? Sollte ich denn jetzt wirklich mal eine Stellenanzeige in der Times schalten?
so short
Christoph Zurnieden
-
Hallo Christoph,
[...] Driss [...]
ach so ;)
nichts desto Trotz habe ich immer noch einen Fehler beim Bauen von gcc 3.4.3. Nach aufruf von make wird mit folgenden Zeilen abgebrochen
collect2: ld returned 1 exit status
make[2]: *** [libgcc_s.so] Error 1
make[2]: Leaving directory '/pakete/gcc-3.4.3/gcc'
make[2]: *** [libgcc.a] Error 2
make[2]: Leaving directory '/pakete/gcc-3.4.3/gcc'
mkae: *** [all-gcc] Error 2Gruß aus Berlin!
eddi-
Hi,
nichts desto Trotz habe ich immer noch einen Fehler beim Bauen von gcc 3.4.3. Nach aufruf von make wird mit folgenden Zeilen abgebrochen
collect2: ld returned 1 exit status
make[2]: *** [libgcc_s.so] Error 1
make[2]: Leaving directory '/pakete/gcc-3.4.3/gcc'
make[2]: *** [libgcc.a] Error 2
make[2]: Leaving directory '/pakete/gcc-3.4.3/gcc'
mkae: *** [all-gcc] Error 2Tja, ein klein wenig mehr bräuchte man schon noch, den am Grund _warum_ der Fehler stattfand ist gelegen, nicht am Umstand, das ein Fehler auftauchte ;-)
Versuch's mal mit einer statisch linkbaren glibc im Pfad.
Oder hast Du einen AMD-64?so short
Christoph Zurnieden
-
Re:
Da steht das Schwein vorm Uhrwerk ;(
- glibc-ports
- glibc-linuxthreads
- glibc-libidn
- glibc-crypt
- glibc
Vermutlich reicht nur die glibc, aber woführ wurde der Rest gemacht? Welche kann/sollte ich nehmen? (Der Rechner ist mit einem alter athlon-xp bestückt; welche angaben werden noch benötigt?)
Gruß aus Berlin!
eddi-
Hi,
Da steht das Schwein vorm Uhrwerk ;(
Der ist schön, den nehm' ich ;-)
- glibc-ports
- glibc-linuxthreads
- glibc-libidn
- glibc-crypt
- glibc
Vermutlich reicht nur die glibc, aber woführ wurde der Rest gemacht?
Für andere Zwecke. Mehr kann ich ohne nachzuschauen auch nicht sagen. Bei den mittleren drei klingelt's ein wenig, die Bezeichner kenn' ich aus der GLibC-Konfigurierung. Aber ob "glibc" jetzt alles drin hat (ein paar Sachen schließen sich gegenseitig aus, "alles" ist aber trotzdem nicht wirklich übertrieben) oder nur die Minimalversion darstellt müßte ich genauso wie Du der Gentoo-Doku entnehmen.
Welche kann/sollte ich nehmen?
Am besten selber bauen. Wenn Du das aber in Deinem chroot Verzeichnis machen willst beißt sich die Katze in den Schwanz, das weißt Du, ja?
(Der Rechner ist mit einem alter athlon-xp bestückt;
Ging bei meiner Frage wg AMD-64 eigentlich nur darum, ob's ein 64-Bit Prozessor ist, beim AMD gab's hin und wieder Probleme, die Konfigurierung einiger Pakete war zu Anfang ziemlich mit der heißen Nadel gestrickt.
welche angaben werden noch benötigt?)
Ein paar Zeilen über den von Dir geposteten Meldungen des Linkers. Erstmal so Stücker 10. Das war nämlich wirklich zu wenig, da kann man nicht genug drus erkennen. Meine Vermutung mit der GLibC basierte auch mehr auf meinem Wissen, das Du im chroot baust, als das ich aus der Verabschiedung von make etwas herauslesen konnte.
so short
Christoph Zurnieden
-
-
nichts desto Trotz habe ich immer noch einen Fehler beim Bauen von gcc 3.4.3. Nach aufruf von make wird mit folgenden Zeilen abgebrochen
collect2: ld returned 1 exit status
make[2]: *** [libgcc_s.so] Error 1
make[2]: Leaving directory '/pakete/gcc-3.4.3/gcc'
make[2]: *** [libgcc.a] Error 2
make[2]: Leaving directory '/pakete/gcc-3.4.3/gcc'
mkae: *** [all-gcc] Error 2Die richtige Fehlermeldung steht in der Regel ein paar Zeilen weiter oben. Das ist nur ein Folge-Fehler.
-
Tach Grußloses,
Die richtige Fehlermeldung steht in der Regel ein paar Zeilen weiter oben. Das ist nur ein Folge-Fehler.
soweit ich mir die Ausgabe ansehen konnte war nichts von einer Fehlermeldung zu sehen. Ein erneuter Aufruf von make ist unter http://eddi.to-grip.de/hilfe/make.txt abgelegt.
Gruß aus Berlin!
eddi-
Hi,
hupps, dabei schau' ich doch meist vorher nach, ob zwischenzeitlich ... aber egal ;-)
soweit ich mir die Ausgabe ansehen konnte war nichts von einer Fehlermeldung zu sehen. Ein erneuter Aufruf von make ist unter http://eddi.to-grip.de/hilfe/make.txt abgelegt.
Ja, im _erneutem_ Aufruf ist nix zu sehen. Uns hätte aber schon die originale und vollständige Fehlermeldung inklusiver Weg dahin interessiert. Auch das neue "make.txt" ist ja nur ein minimaler, nichtssagender Ausschnitt.
Da es jetzt funktioniert (funktioniert es denn?) war es wohl nur ein kleiner Bedienfehler beim Bootstrap. Hätte mich schon interessiert, was das gewesen sein könnte, aber wenn Du nicht magst: auch gut. Wenn der GCC am Ende nicht funktioniert: lösche _alles_, pack das Paket neu aus und bau komplett neu, reparieren kannst Du da nix. Zumindest nicht preiswert.so short
Christoph Zurnieden
-
Re:
hupps, dabei schau' ich doch meist vorher nach, ob zwischenzeitlich ... aber egal ;-)
na ich habe es jetzt nochmal mit protokolliert
Da es jetzt funktioniert...
?!?
Immer wieder faszinierend Deine Schlußfolgerungen zu lesen.Auf der in https://forum.selfhtml.org/?t=106548&m=661797 geposteten Fehlermeldung aufbauend kann nach einem weiteren, komplett neuen Versuch nur eine Zeile von Bedeutung sein:
/usr/bin/ld: crti.o: No such file: No such file or directory
In der Ausgabe von make.txt wird im ersten "Anweisungsblock" extra LD=/usr/lib/gcc-lib/i386-pc-linux-gnu/3.3.5/../../../../i386-pc-linux-gnu/bin/ld angegeben. Nun will er aber auf /usr/bin/ld zugreifen??? (Müssen das noch Zeiten gewesen sein, als ein Rechner Abacus hieß.) Wie auch immer, /usr/bin/ld ist ein Link auf ../i386-pc-linux-gnu/bin/ld. Dieses Verzeichnis existiert nicht. Nur das ist das gentoo stage1 und dort gab es noch keinerlei Probleme solcher Art. Was ist zu tun?
Gruß aus Berlin!
eddi-
Hi,
Da es jetzt funktioniert...
?!?
Immer wieder faszinierend Deine Schlußfolgerungen zu lesen.Habe ich irgendetwas nicht mitbekommen? Dein geposteter make-Mitschnitt zeigte keine Fehler!
Auf der in https://forum.selfhtml.org/?t=106548&m=661797 geposteten Fehlermeldung aufbauend kann nach einem weiteren, komplett neuen Versuch nur eine Zeile von Bedeutung sein:
/usr/bin/ld: crti.o: No such file: No such file or directory
Das ist nicht im make.txt Listing!
Allerdings lag ich mit meiner Vermutung genau im Schwarzem.
Mitunter hab' sogar ich ein wenig Glück! ;-)
BTW: auch hier sind wieder die Zeilen darüber interessant, denn dort sollte eigentlich stehen, wo die Datei gesucht wird.crtio.o ist die Datei, die alle nötigen Startdaten beinhaltet. Entweder ist die nicht gebaut, oder ld findet sie nicht. Wie heißt der Pfad zu ld eigentlich genau? Ist das tatsächlich /usr/bin/ld oder /home/eddi/knast/usr/bin/ld? Wo wird crtio.o genau gesucht?
Normalerweise würde ich ja sagen, das Du Deine bereits im eigentlichem System vorhanden crtio.o einfach an die passende Stelle kopierst, aber Du weigerst Dich ja standhaft irgendetwas einfach so zu kopieren.So, jetzt muß ich alter Sack aber endgültig in die Heia, bis morgen, pardon gleich mal.
so short
Christoph Zurnieden
-
Moin,
Da es jetzt funktioniert...
?!?
Immer wieder faszinierend Deine Schlußfolgerungen zu lesen.Habe ich irgendetwas nicht mitbekommen?
lol
Dein geposteter make-Mitschnitt zeigte keine Fehler!
Ist entstanden durch |make > make.txt|. Somit sind wir wieder bei der Frage, inwieweit mich das ganze im Wissen um Linux weiterbringt. Die Meldungen vom Kompiler werden immernoch an der Konsole ausgegeben (war mir nicht bewußt, daß dort auch ein Unterschied besteht).
/usr/bin/ld: crti.o: No such file: No such file or directory
Das ist nicht im make.txt Listing!
Allerdings lag ich mit meiner Vermutung genau im Schwarzem.
Mitunter hab' sogar ich ein wenig Glück! ;-)
BTW: auch hier sind wieder die Zeilen darüber interessant, denn dort sollte eigentlich stehen, wo die Datei gesucht wird.Wie bekomme ich die gesamte Ausgabe, die an die Konsole gesendet wird in eine Datei umgeleitet? (make > make.txt ist immerhin satte 200kb groß)
crtio.o ist die Datei, die alle nötigen Startdaten beinhaltet. Entweder ist die nicht gebaut, oder ld findet sie nicht.
Das würde heißen, im müßte erst ein bootstrap vollziehen
Wie heißt der Pfad zu ld eigentlich genau? Ist das tatsächlich /usr/bin/ld oder /home/eddi/knast/usr/bin/ld? Wo wird crtio.o genau gesucht?
/sv/usr/bin/ld
Normalerweise würde ich ja sagen, das Du Deine bereits im eigentlichem System vorhanden crtio.o einfach an die passende Stelle kopierst, aber Du weigerst Dich ja standhaft irgendetwas einfach so zu kopieren.
Tütengerichte gibts im Supermarkt, ich will Selbstgekocht!
So, jetzt muß ich alter Sack aber endgültig in die Heia, bis morgen, pardon gleich mal.
Nacht ;)
so short
BTW: spricht eigentlich etwas gegen
short main()oder muß es immer
int main()sein?
Gruß aus Berlin!
eddi-
Dein geposteter make-Mitschnitt zeigte keine Fehler!
Ist entstanden durch |make > make.txt|. Somit sind wir wieder bei der Frage, inwieweit mich das ganze im Wissen um Linux weiterbringt. Die Meldungen vom Kompiler werden immernoch an der Konsole ausgegeben (war mir nicht bewußt, daß dort auch ein Unterschied besteht).
Für ein Programm werden zwei Ausgabe-Kanäle geöffnet: Standard-Ausgabe und Standard-Fehler-Ausgabe. Die meisten Programm schicken Fehler nach STDERR. Der ist in der Shell über 2 verfügbar. Also statt make > make.txt sowas hier: make 2>&1 > make.txt. Damit leitest du den Fehler-Kanal in die Standard-Ausgabe um (2>&1) und die Standard-Ausgabe leitest du dann in die Datei um (> make.txt).
BTW: spricht eigentlich etwas gegen
short main()oder muß es immer
int main()sein?
Der Standard spricht von int.
-
Hi,
crtio.o ist die Datei, die alle nötigen Startdaten beinhaltet. Entweder ist die nicht gebaut, oder ld findet sie nicht.
Das würde heißen, im müßte erst ein bootstrap vollziehen
Nein, das heißt: entweder ist die Datei nicht gebaut oder ld findet sie nicht. Ob ein "bootstrap" von was auch immer helfen würde weiß ich nicht. Ich weiß aber, das eine gebaute crtio.o, die ld auch findet helfen würde.
Wie heißt der Pfad zu ld eigentlich genau? Ist das tatsächlich /usr/bin/ld oder /home/eddi/knast/usr/bin/ld? Wo wird crtio.o genau gesucht?
/sv/usr/bin/ld
Das ist der Pfad zu ld, nicht wo crtio.o gesucht wird.
Was ist "/sv"?Tütengerichte gibts im Supermarkt, ich will Selbstgekocht!
Das Bild hierfür wäre eher: Du möchtest das Gericht nicht in einer drei Sterne Küche gratis(!) verspeisen, sondern es unbedingt selber machen können.
Dagegen ist ja prinzipiell erstmal nix zu sagen, nur fehlen Dir einfach die Grundlagen! Ich bestand nicht ohne Grund darauf, das Du erst mal ganz einfach anfangen solltest. Zum Beispiel mit der Nutzung der Shell. Damit muß man einfach umgehen können.
Ich habe Dir angeboten Dich an die Hand zu nehmen, aber laufen mußt Du schon selber, ich werde Dich nicht auch noch tragen!BTW: spricht eigentlich etwas gegen
short main()oder muß es immer
int main()Wenn es, wie im Forums-Markup gekennzeichent, Standard-C sein soll, dann ist
int main()vorgeschrieben.so short
Christoph Zurnieden
-
Hallo,
Ich habe Dir angeboten Dich an die Hand zu nehmen, aber laufen mußt Du schon selber, ich werde Dich nicht auch noch tragen!
Ja, ja, ja - es _läuft_ nun; danke! :)))
Gruß aus Berlin!
eddi
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
Hallo,
ein anderer Lösungsansatz: Gibt es eine Möglichkeit, welche verhindert, daß ein zu kompilierendes Programm sich in Programm und Bibliothek abspaltet?
Gruß aus Berlin!
eddi-
Hi,
ein anderer Lösungsansatz: Gibt es eine Möglichkeit, welche verhindert, daß ein zu kompilierendes Programm sich in Programm und Bibliothek abspaltet?
Ja: statisch bauen. Ist auch eine nicht unübliche Vorgehensweise bei chroot().
so short
Christoph Zurnieden
-
Re:
Ja: statisch bauen. Ist auch eine nicht unübliche Vorgehensweise bei chroot().
Ja. Was die bash angeht, so bringt sie dankenswerter Weise den Parameter --enable-static-link mit. Das ist aber leider nicht immer der Fall. Was mache ich dann?
Also bitte ich um mehr als zwei Sätze im Cheatah-stil!
Gruß aus Berlin!
eddi
-
-