hjslfs-1.3.49.3 ist offline

  • Zitat

    Original von kanotixer
    Komisch, das hat nicht funktioniert.


    Werd noch mal n Auge auf die Scripte werfen - da hat sich eigentlioch nix geändert ...


    Zitat

    [...] nur der VDR zickt, weil er wohl die DVB- und Kernelsourcen im gleichen Verzeichnis erwartet. Wie ich das hinkriege, hab ich noch nicht herausbekommen.


    Durch Verlinken - im CVS DVB Pfad gibbet dafür n Script - auch im Readme erkennbar :)


    Zitat


    Falscher Thread, aber trotzdem der Hinweis: Beim Booten mit cd011 und nach starten der Tools (neuere Version) findet er beim starten des Backups partimage nicht. Liegts an der CD oder an mir?


    Weder noch - partimage hätten die tools mitbringen sollen - is jetzt auch wieder so :gap


    Zitat

    Ansonsten habe ich mich wahnsinnig gefreut, als mein handgemachtes System plötzlich bootfähig war.


    Is jedesmal erhebend , wohl wahr :]


    HJS

  • Jaja, die Readme... Ich gelobe Besserung :schiel


    Hab trotzdem erstmal den Kernel neu kompiliert und die mitgelieferten DVB-Treiber genommen, sollte ja reichen.


    Jetzt habe ich beim Kompilieren vom VDR ein ganz anderes Problem. Er findet die libcap nicht.
    Im Logfile von dessen Installation steht



    Weil ich sowieso gerne vdr-1.6 verwenden würde, hab ich dann die libcap-2.x-Sourcen gezogen und versucht zu kompilieren, da kommt aber ein

    Zitat

    "/usr/bin/ld: cannot find -lattr"


    Any Ideas?


    EDIT: Wie war das noch mit den Readmes...

    Zitat

    If the "capability" module is not compiled into your kernel, you may need to do "modprobe capability" before running VDR.


    Er ist grad noch beschäftigt, aber gleich probier ich das mal.


    Grüße
    Marc

    Full-Budget: Athlon XP 2600+ auf Asrock K7VT4A+, XFX Nvidia Geforce 6200, Hauppauge Nova-S Plus.
    HjsLfs 1.2.8 mit VDR 1.6.0-2 und xineliboutput.

    Einmal editiert, zuletzt von kanotixer ()

  • Zitat

    Original von kanotixer
    make[1]: *** [cap_alloc.o] Fehler 1
    make[1]: Leaving directory `/sources/libcap-1.10.orig/libcap'
    make: *** [all] Fehler 2


    Vermutlich nen ziemlich neuen Kernel genommen ?
    Schätze , ab ner bestimmten Kernelversion landet der Build der alten libcap aufm Bauch .
    Hatte das Ergebnis auch schon mal mit nem 2.6.24er - hab aber noch nicht genau eruiert , wo bzw ab wann das Prob auftritt .



    Was sagt er nu ?


    HJS

  • Ich fang schonmal an (hab noch kein Fernsehbild), sonst vergess ich hinterher die Hälfte.


    modprobe capability -> gibbet nicht.
    Kernel neu kompiliert, Security Options -> ... capabilities (Posix) reingenommen
    Er vermisst die libcaps immer noch (irgendwie logisch, sind ja auch noch nicht sauber durchgelaufen.)
    Also nochmal die 2.11 probiert: make bricht mit .../ld -lattr not found oder so ähnlich ab. Das Problem wurde schonmal in einem anderen Thread hier (Du warst auch beteiligt...) abgehandelt, glücklicherweise wurde auch der Link zu den attr-Sources gepostet.
    Runtergeladen, kompiliert, immer noch nicht. Problem: libattr.a an der falschen Stelle. Per ln -s auf das übliche dir gelegt (/usr/lib).
    Nun läuft der make für den VDR durch.
    Fehler bei make install: ncursesw nicht gefunden, skincurses kann nicht erstellt werden. Hatte Dr. Seltsam schonmal, Problem: ncurses muss mit der option --enable-widec kompiliert werden (Könntest Du in den Scripts vielleicht ändern?). Danach dann make install.lib


    Soweit erstmal. Mal schauen, was heut noch so geht...


    Grüße
    Marc

    Full-Budget: Athlon XP 2600+ auf Asrock K7VT4A+, XFX Nvidia Geforce 6200, Hauppauge Nova-S Plus.
    HjsLfs 1.2.8 mit VDR 1.6.0-2 und xineliboutput.

  • Zitat

    Original von kanotixer
    Ich fang schonmal an (hab noch kein Fernsehbild), sonst vergess ich hinterher die Hälfte.


    modprobe capability -> gibbet nicht.
    Kernel neu kompiliert, Security Options -> ... capabilities (Posix) reingenommen


    Hab ich in die aktuelle default-config übernommen


    Zitat


    Er vermisst die libcaps immer noch (irgendwie logisch, sind ja auch noch nicht sauber durchgelaufen.)
    Also nochmal die 2.11 probiert: make bricht mit .../ld -lattr not found oder so ähnlich ab. Das Problem wurde schonmal in einem anderen Thread hier (Du warst auch beteiligt...) abgehandelt, glücklicherweise wurde auch der Link zu den attr-Sources gepostet.
    Runtergeladen, kompiliert, immer noch nicht. Problem: libattr.a an der falschen Stelle. Per ln -s auf das übliche dir gelegt (/usr/lib).


    Na immerhin hat er die überhaupt installiert - bei meinen Probeläufen hat er die erst gar nicht installiert ...
    Machen wir das halt händisch - libcap-2.11 nebst libattr ist in a003 zu finden :)


    Zitat


    Nun läuft der make für den VDR durch.
    Fehler bei make install: ncursesw nicht gefunden, skincurses kann nicht erstellt werden. Hatte Dr. Seltsam schonmal, Problem: ncurses muss mit der option --enable-widec kompiliert werden (Könntest Du in den Scripts vielleicht ändern?). Danach dann make install.lib


    Jep - issich passiert .

  • So, nun steh ich da und weiß net weiter.


    Softdevice nebst DirectFB, Vidix, FFmpeg... kompiliert, und kein Ausgabetreiber will so richtig.


    Vidix zeigt nur schwarzes Bild, DirectFB nur eine Bildschirmhälfte...


    Und udev bekomme ich auch nicht gezähmt um mal ein gescheites /dev/input/ir zu haben...


    Aber das sind ja zugegeben keine Probleme des hjslfs...


    Mal so anbei: Da es ja keinen Paketmanager gibt, sollte man tunlichst nur installieren, wenn man 100% sicher ist, das es hinhaut oder? Oder häufiger mal Backups fahren... Wird ja auch alles erstmal in /usr/ hineingebastelt, das macht das nachträgliche aussortieren dann schon schwierig.


    Aber ich wollte es ja nicht anders... Warum einfach, wenns auch from scratch geht.

    Full-Budget: Athlon XP 2600+ auf Asrock K7VT4A+, XFX Nvidia Geforce 6200, Hauppauge Nova-S Plus.
    HjsLfs 1.2.8 mit VDR 1.6.0-2 und xineliboutput.

  • Zitat

    Original von kanotixer
    So, nun steh ich da und weiß net weiter.


    Davon gibts einige Stellen - nen Teil davon kenn ich auch :whatever


    Zitat


    Softdevice nebst DirectFB, Vidix, FFmpeg... kompiliert, und kein Ausgabetreiber will so richtig.


    Vidix zeigt nur schwarzes Bild, DirectFB nur eine Bildschirmhälfte...


    Xine ?


    Zitat


    Und udev bekomme ich auch nicht gezähmt um mal ein gescheites /dev/input/ir zu haben...


    Ein Workaround , der dir /dev/[input/]ir auf das richtige device verlinkt ?


    Zitat

    Aber das sind ja zugegeben keine Probleme des hjslfs...


    Was ein Glück :gap


    Zitat


    Mal so anbei: Da es ja keinen Paketmanager gibt, sollte man tunlichst nur installieren, wenn man 100% sicher ist, das es hinhaut oder? Oder häufiger mal Backups fahren... Wird ja auch alles erstmal in /usr/ hineingebastelt, das macht das nachträgliche aussortieren dann schon schwierig.


    N Backup is immer gut .
    Die Abhängigkeiten werden beim builden aufgelöst .
    Wenn du dir die Scripte ansiehst siehst du stets die Abfragen vor dem Build .
    Wenn du Packages nutzt , für die bereits Scrpte existieren , sollte kein build an einer Anhängigkeit scheitern .
    Wenn du eigene Sourcen hinzufügst , mußt du dich sekbstverfreilich auch selbst um die Abhängigkeiten kümmern - das ist LFS .
    Wobei mein erster Blick bei neuen Scripten ins BLFS führen - da sind die Abhängigkeiten aufgeführt - wenn dort die Source zu finden ist .
    Wenn du eigene Packages baust , machs nicht manuell sondern nimm dir eines der Scripte und korrigiere die Variablen URL , SRC und FLD , ggf den make - die Deps nicht zu vergessen .


    Was denkst du , warum hjslfs überhaupt enstanden ist ?
    Wenn du mal wieder von vorn beginnen mußt , haste die Scripte .


    In späteren Versionen wird das Basescript auch die Möglichkeit geben , Userscripts von anderen Pages zu ziehen - derzeit mußte die entweder manuell dazu packen oder an mich schicken , damit ich sie mit reinnehmen kann .


    Zitat

    Aber ich wollte es ja nicht anders... Warum einfach, wenns auch from scratch geht.


    Ebent - nur die Harten kommen in den Garten :D


    HJS

  • Zitat

    Original von hjs
    Xine ?


    Das sagen alle...
    Hätte ich auch als nächstes probiert. Allerdings stört mich, dass immer ein X gestartet werden muss. Softdevice schafft eine deutlich kürzere Bootzeit. Obwohl es ja auch ein xine für den Framebuffer gibt, aber da bin ich noch nicht ganz durchgestiegen.


    Zitat

    Original von hjs
    Ein Workaround , der dir /dev/[input/]ir auf das richtige device verlinkt ?


    Jo, genau das. Aber meine Regeln haben bisher nicht funktioniert. Hab jetzt den Debuglevel mal hochgesetzt, vielleicht steht da warum.



    Ich hätte früher fragen sollen... Gestern hab ich noch so gedacht, wäre klug gewesen, zu dokumentieren, was ich alles so kompiliert habe. Also muss ich jetzt doch mein provisorisches tar-Backup einspielen, dass den Stand frisch nach dem Skriptdurchlauf enthält und nochmal von vorne anfangen...
    Diesmal dann ganz sauber mit Scripts! Hätte dann ja sogar den Nebeneffekt, dass andere davon auch profitieren.


    Leider wird das alles noch was dauern, man lebt ja nicht nur für den VDR...

    Full-Budget: Athlon XP 2600+ auf Asrock K7VT4A+, XFX Nvidia Geforce 6200, Hauppauge Nova-S Plus.
    HjsLfs 1.2.8 mit VDR 1.6.0-2 und xineliboutput.

  • Zitat

    Original von kanotixer


    Das sagen alle...
    Hätte ich auch als nächstes probiert. Allerdings stört mich, dass immer ein X gestartet werden muss. Softdevice schafft eine deutlich kürzere Bootzeit. Obwohl es ja auch ein xine für den Framebuffer gibt, aber da bin ich noch nicht ganz durchgestiegen.


    Hab ich mich noch nicht mit beschäftigt - hab genügend FF :)


    Zitat


    Jo, genau das. Aber meine Regeln haben bisher nicht funktioniert. Hab jetzt den Debuglevel mal hochgesetzt, vielleicht steht da warum.


    Dachte da mehr an n Script nach udev , welches nach dem richtigen Text sucht und das Ergebnis verlinkt - ne udev Regel is ja nich wirklich ein workaround


    Zitat

    Ich hätte früher fragen sollen... Gestern hab ich noch so gedacht, wäre klug gewesen, zu dokumentieren, was ich alles so kompiliert habe. Also muss ich jetzt doch mein provisorisches tar-Backup einspielen, dass den Stand frisch nach dem Skriptdurchlauf enthält und nochmal von vorne anfangen...
    Diesmal dann ganz sauber mit Scripts! Hätte dann ja sogar den Nebeneffekt, dass andere davon auch profitieren.


    Yep - und es erhöht die Anzahl derer , die's mal ausprobieren , wiederum eigene Scripte einbringen ... auch Lawineneffekt genannt ...


    Zitat


    Leider wird das alles noch was dauern, man lebt ja nicht nur für den VDR...


    Geht wohl uns allen so ...


    HJS

  • Sodele - lang hats gedauert , abba nu is mal wieder ne neue Version fällig :)


    Neu ist im Menü das "Sourcen Finetuning"


    Dort kann man sowohl die ursprünglich gewählte Liste noch einmal ändern als auch die Versionen der Scripte - sprich Sourcen - einzeln nach eigenem Gusto ändern .


    Verfügbare Versionen werden angezeigt und können ausgewählt werden .


    Eine Änderung der Liste setzt selbstverfreilich alle Änderungen zurück - genau so wie ein Abbruch - dann werden wieder die Defaults der zuletzt gewählten Liste gesetzt .


    Diese Option ist derzeit nur für die Base verfügbar .


    HJS

  • Sodele - nu lassen sich auch die Sourcenversionen der Addons individuell ändern .


    Allerdings geht das derzeit zu Lasten der Dependencies - da muß ich noch was anpassen .


    HJS

  • Und da bin ich wieder :lachen3


    Mir fällt auf, dass man die Partitionierung nicht per default übernehmen kann. Zumindest in meiner Konstellation (virtuelle Maschine) muss man erst manuell partitionieren. Setzt man ungeachtet dessen das Bauen fort, zeigt er zwar hübsch was auf dem Bildschirm an, schreibt aber nichts auf die Festplatte, weil keine Partitionen angelegt werden.
    Prinzipiell ist es natürlich kein Problem, erst Partitionen mit fdisk anzulegen, allerdings fehlt ein wenig die Kommunikation, dass der User das tun muss!
    Vielleicht kann man eine Standardpartitionierung ("one-click") anbieten und wenn der User diese nicht wahrnimmt darauf hinweisen, dass er Partitionen manuell anlegen muss.


    Noch ne Frage anbei: Wenn ich das lfs auf ner virtuellen Maschine baue, wie bekomme ich das dann am geschicktesten auf eine echte Festplatte? Gibt es da Erfahrungswerte?


    Grüße
    Marc

    Full-Budget: Athlon XP 2600+ auf Asrock K7VT4A+, XFX Nvidia Geforce 6200, Hauppauge Nova-S Plus.
    HjsLfs 1.2.8 mit VDR 1.6.0-2 und xineliboutput.

  • Zitat

    Original von kanotixer
    Und da bin ich wieder :lachen3


    Welcome back :)


    Zitat


    Mir fällt auf, dass man die Partitionierung nicht per default übernehmen kann. Zumindest in meiner Konstellation (virtuelle Maschine) muss man erst manuell partitionieren. Setzt man ungeachtet dessen das Bauen fort, zeigt er zwar hübsch was auf dem Bildschirm an, schreibt aber nichts auf die Festplatte, weil keine Partitionen angelegt werden.
    Prinzipiell ist es natürlich kein Problem, erst Partitionen mit fdisk anzulegen, allerdings fehlt ein wenig die Kommunikation, dass der User das tun muss!


    Naja - ich setze vorraus , daß ein User , der ne jungfräuliche Platte im System hat weiß , daß er da ersmal fdisk aufrufen muß ( ist ja übers Menü erreichbar ) .


    Hat er Partitionen , sieht er die ja und kann bestimmen welche zu verwenden ist .


    Spätestens , wenn ich vorbereitete Listen wie "VDR" oder "Bürokiste mit KDE" drin hab , wird der Partitionierungsvorschlag auch drin sein .


    Zitat

    Vielleicht kann man eine Standardpartitionierung ("one-click") anbieten und wenn der User diese nicht wahrnimmt darauf hinweisen, dass er Partitionen manuell anlegen muss.


    Hat die gleichen Vorraussetzungen ( Prüf und Programmiertechnisch )
    Zum derzeitigen Zeitpunkt ( reichlich Baustellen ) scheint mir die Überprüfung , ob die angegebenen Partitionen existieren/mountable sind die schnellste und erstmal grob hinweisende Variante ... :gap


    Zitat


    Noch ne Frage anbei: Wenn ich das lfs auf ner virtuellen Maschine baue, wie bekomme ich das dann am geschicktesten auf eine echte Festplatte? Gibt es da Erfahrungswerte?


    Dafür waren ursprünglich auch die Tools gedacht - partimage oder Package backup .


    Die letzte Version müßte auch noch mit der 1.3er laufen .


    Ansonsten kannste n simples tar auf die [virtuelle] LFS Platte los lassen und auf die Zielpartition auspacken .


    In späterer Version ( nicht für die 1.4 vorgesehen ) wirds auch die "Package_Build[_only] Option haben - der baut dir dann von vorne herein nur die Packages zur Installation auf irgendein System ...


    Abba is Zukunftsmusik - davor gibts noch n paar andere Feinheiten , die ich für wichtiger halte ...


    HJS

  • Ich sehe - kommt alles!


    Aktuell hänge ich aber grade an einem ganz anderen Fehler. Hab das Script insgesamt zweimal durchlaufen lassen (004, je zwei unterschiedliche Versionen linux-util), jedesmal bricht er nach dem Bauen den Bootvorgang mit folgender Meldung ab:



    Im Build-Log der linux-util steht kein /bin/mount, allerdings finde ich die Datei nicht, in der steht was schiefgelaufen ist. Ich kann ja mit der CD booten, dann die Systempartition mounten und Dateien einsehen, welche sind denn da von Interesse?


    Vielen Dank und Grüße
    Marc

    Full-Budget: Athlon XP 2600+ auf Asrock K7VT4A+, XFX Nvidia Geforce 6200, Hauppauge Nova-S Plus.
    HjsLfs 1.2.8 mit VDR 1.6.0-2 und xineliboutput.

  • util_linux.log hab ich gefunden:


    Liegt also am uuid. Ist Dir das auch schonmal passiert?


    EDIT: Beim Durchlauf mit dem älteren util_linux sieht der Fehler anders aus:

    Zitat

    cc -s cal.o ../lib/err.o -o cal -lncurses
    /usr/bin/ld: cannot find -lncurses
    collect2: ld returned 1 exit status
    make[1]: *** [cal] Error 1
    make[1]: Leaving directory `/sources/util-linux-2.12r/misc-utils'
    make: *** [all] Error 1


    Eine Sache hätte ich noch. Es wäre fein, wenn man die hjlfs-Skripte mal ein wenig mehr dokumentiert hätte. Dann würden einige Features bestimmt größeren Anklang finden. Du müsstest Dir da ne Methode ausdenken, für ein bisschen Inhalt würden sich sicherlich User (inkl. mir) finden.
    Bis es soweit ist:
    Wie funktioniert denn das mit den Binaries?
    Was muss ich als Source auswählen und warum kommen danach immer nur die Ordner im Root als "Binaries"?


    Grüße
    Marc (der sich schon auf sein erstes lauffähiges hjlfs freut!)

    Full-Budget: Athlon XP 2600+ auf Asrock K7VT4A+, XFX Nvidia Geforce 6200, Hauppauge Nova-S Plus.
    HjsLfs 1.2.8 mit VDR 1.6.0-2 und xineliboutput.

    2 Mal editiert, zuletzt von kanotixer ()

  • Zitat

    Original von kanotixer
    util_linux.log hab ich gefunden:


    Liegt also am uuid. Ist Dir das auch schonmal passiert?


    Yep - das Script steht mit Absicht in keiner Liste - es will noch nicht so wie ich will :gap


    Zitat

    EDIT: Beim Durchlauf mit dem älteren util_linux sieht der Fehler anders aus:


    Sieht aus , als wenn bei ncurses was nicht lief - was sagt das log ?


    Zitat


    Eine Sache hätte ich noch. Es wäre fein, wenn man die hjlfs-Skripte mal ein wenig mehr dokumentiert hätte. Dann würden einige Features bestimmt größeren Anklang finden. Du müsstest Dir da ne Methode ausdenken, für ein bisschen Inhalt würden sich sicherlich User (inkl. mir) finden.


    Welche Scripte meinst du ? Die Buildscripts sollten keiner Erklärung bedürfen .


    Zitat


    Bis es soweit ist:
    Wie funktioniert denn das mit den Binaries?
    Was muss ich als Source auswählen und warum kommen danach immer nur die Ordner im Root als "Binaries"?


    Ich vermute mal , du sprichst jetzt von den Tools ?
    Dort solltest du als source deine LFS Partition angeben .


    HJS

Jetzt mitmachen!

Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!