Posts by kanotixer

Quote

Original von hjs

Wenn du gern ein rennendes Sys hättest , solltest du die CD011a , hjslfs-1.2.8 und base004 nehmen .
Für die base004 kannste auch die 10b nehmen , bei älteren Listen gibbet n Prob mit dem neueren libc/gcc Gespann die älteren Versionen zu bauen - daher basiert die 11er CD ja auch wieder auf gcc-4.1.2/libc-2.5 , statt gcc-4.2.3/libc-2.7 wie die 10er .

Mit Base004 meinst Du sicherlich "experimental" oder?
Allerdings hat er da Probleme mit. Wenn ich das ausgewählt habe, werden ja Sachen runtergeladen. Dann kommt eine (?) mächtig lange URL und die Meldung: "URI too long" oder so ähnlich. Dann macht er erstmal munter weiter, aber so ganz richtig ist das nicht, gelle?

Komme ich an die Fehler während der Skriptkonfiguration hinterher nochmal ran?

Der Ehrgeiz hat mich gepackt!

Dinge die mir auffallen:

1.3.11, Base 004
- Nach der Konfiguration des Basis-Systems kommt man mit "weiter" nicht weiter, lediglich ein Abbrechen führt einen ins Hauptmenü.
-Obwohl Binaries installieren auf n steht, zieht er sich fröhlich die ganzen ...bin...-Dateien.
-Des weiteren findet er dann nicht:
http://backup/binaries/004/readjusting.bin.tar.bz2
http://backup/binaries/004/adjusting.bin.tar.bz2
http://backup/binaries/004/stripping.bin.tar.bz2
http://backup/binaries/004/presystem.bin.tar.bz2

Grüße
Marc

Moinmoin,

ich mal wieder.

Du hattest mir die 10b für die 1.2.8-Skripte empfohlen, mit der Iso von Deiner Seite gibts aber beim Booten Kernel Panic, Init not found.
Liegts an mir oder an der Iso?

Grüße
Marc

Häng ich mich direkt hinten dran, sowas suche ich auch!

In der aktuellen c't ist ein Test drin.

Ich zitiere mal stichpunktartig aus dem Fazit:
D-Link DNS 313 ist solide verarbeitet, könnte benutzerfreundlicher sein
Iomega oder Lacie sind preiswert, Iomega hat dabei die bessere Nutzerverwaltung und das höhere Tempo.

Aber so richtig vom Hocker haut mich da alles nicht, entweder teuer, langsam oder laut.

Mal ne Frage nebenbei: Was kann man bei Fast Ethernet eigentlich maximal für Transferraten erreichen? Damit würde sich die Geschwindigkeitsfrage dann wieder relativieren.

Grüße
Marc

Quote

Original von hjs

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

Alles klar, dann nehm ich erstmal die alte Version. War ja auch nur ein Test, ob es damit vielleicht läuft.

Quote

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

Hier das Ende von ncurses.log, in meinen Augen weder dort noch vorher was auffälliges.

Quote

/tools/bin/install -c ncurses-config /tools/bin/ncurses5-config
make[1]: Leaving directory `/mnt/lfs/sources/ncurses-5.6/misc'
cd c++ && make DESTDIR="" install
make[1]: Entering directory `/mnt/lfs/sources/ncurses-5.6/c++'
/tools/bin/install -c ../lib/libncurses++.a /tools/lib/libncurses++.a
installing ./cursesapp.h in /tools/include
installing ./cursesf.h in /tools/include
installing ./cursesm.h in /tools/include
installing ./cursesp.h in /tools/include
installing ./cursesw.h in /tools/include
installing ./cursslk.h in /tools/include
installing etip.h in /tools/include
make[1]: Leaving directory `/mnt/lfs/sources/ncurses-5.6/c++'

Display More

Quote

Welche Scripte meinst du ? Die Buildscripts sollten keiner Erklärung bedürfen .
[/qoute]
Naja, ein kleines HowTo fände ich z.B. gut. Was gibt man wo an, welche Version sollte man nehmen, was ist, wenn was schiefgeht...
Und eine Anleitung zur Nutzung der Tools wäre schön. Oder mal irgendwo der Hinweis, wie man eigene Quellen kompiliert (nämlich mit Hilfe eines Skripts und nicht per Hand).
Vielleicht bin ich ja auch zu anfängerorientiert. Wer mit den hjslfs-Skripten arbeiten will, sollte wissen was er tut oder?

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

Display More

Bei den Tools wähle ich "Package Binaries aus Buildfiles erstellen", im folgenden Dialogfenster "/dev/hda1" und "ext2", im nächsten Fenster soll ich einen Pfad wählen, /source ist voreingestellt. Egal wo ich dort hinnavigiere, im folgenden Fenster "tarball nach footprint erstellen" erscheinen die Ordner im Root (bin, boot, dev, etc, hjslfs, home...), wenn ich das so übernehme, gibts lauter Fehler, dass das Ordner seien. Was mach ich denn da falsch?

Und direkt noch eine Frage: Wenn ich jetzt weiß wo was schiefgelaufen ist, wie kann ich das korrigieren, ohne nochmal alles kompilieren zu müssen? Gibt es eine Möglichkeit irgendwo in der Mitte einzusteigen und nur bestimmte Skripts (ncurses, util_linux) nochmal auszuführen?

Grüße
Marc

util_linux.log hab ich gefunden:

Quote

...
checking for uuid_is_null in -luuid... no
configure: WARNING: uuid library is not found; mkswap(8) will not generate UUIDs
checking for openpty in -lutil... yes
checking for tgetnum in -ltermcap... no
checking for blkid_known_fstype in -lblkid... no
configure: error: blkid or volume_id is needed to build util-linux-ng.
make: Entering directory `/mnt/lfs/sources/util-linux-ng-2.13.1/mount'
cc mount.c -o mount
mount.c:43:17: error: env.h: No such file or directory
mount.c:44:17: error: nls.h: No such file or directory
mount.c:49:26: error: setproctitle.h: No such file or directory
mount.c: In function 'already':
mount.c:512: warning: passing argument 1 of 'error' makes pointer from integer without a cast
mount.c:516: warning: passing argument 1 of 'error' makes pointer from integer without a cast
mount.c: In function 'create_mtab'
...

Display More

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

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

Quote

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!)

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:

Quote

...
VFS: Mounted root (ext2 filesystem) readonly
...
Mounting kernel-based file systems: /proc/etc/rc.d/rcsysinit.d/S00mountkernfs: line 24: mount: command not found
/sys/etc/rc.d/rcsysinit.d/S00mountkernfs: line 29: mount: command not found
...
Unable to create devices without a SysFS filesystem

Display More

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

Und da bin ich wieder

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

Leider ist easyVDR meiner Erfahrung nach von Haus aus ziemlich träge, was die Bootzeit angeht...

Mein Linvdr (Mahlzeit 3.2) startet in ~30 Sekunden, mit easyVDR hats immer länger als ne Minute gedauert.

Sollten die Entwickler das in den Griff kriegen, bin ich sofort dabei. Allerdings kann ich auch verstehen, dass einige Annehmlichkeiten (udev) ihre Zeit brauchen.

Hallo HJS

ich mal wieder.

Nach kleinen Hardwareumbauten wollte ich Deiner Iso und meiner Installation davon ein wenig Zeit widmen.

Leider lässt sich die CD mit 512 MB Ram tatsächlich nicht starten. Hab das in der virtuellen Maschine nachvollzogen, gibt Lesefehler und Kernel-Paniken. Erst ab 768 gehts! Vielleicht kannst Du die Abfrage dahingehend verändern, dass der CD-Inhalt erst ab 768 kopiert wird.

Leider hat die Fehlersuche meine zeitlichen Ressourcen gefressen, aber das nächste freie Wochenende kommt bestimmt (vielleicht).

Noch was anderes:
Gibts irgendwo eine Hilfe/Doku zu den Binary-Funktionen? Da mein Rechner sich fürs Neukompilieren immer ziemlich viel Zeit nimmt, würde ich die Funktion gerne nutzen, ist aber m.M nach nicht besonders selbsterklärend!

Grüße
Marc

PCM-Pegel zu hoch?

Klingt der Sound dazu leicht verzerrt? Würde ich mal drauf tippen.

alsamixer aufrufen und mal mit den Pegeln spielen (also runter damit).

Moin,

bei mir läuft auch seit geraumer Zeit die Mahlzeit ISO 3.2 und verrichtet stabil ihren Dienst.

Trotzdem würde ich einen neuen Server mit einer zeitgemäßen Distribution ausstatten, LinVDR ist, das ist Fakt, gnadenlos veraltet und wird nur noch künstlich am Leben erhalten.

Gerade solche Geschichten wie USB-Festplatten, etc. meistern neuere Systeme mit udev viel eleganter.

Weil Du schon Erfahrungen mit LinVDR hast, würde vielleicht eine Debian-basierte Distri passen. Entweder nacktes Debian und selbst den VDR drauf oder z.B. easyVDR. Man hört ja auch immer wieder von Gen2Vdr, aber da kann ich nix zu sagen, ist kein Debian

Quote

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.

Quote

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.

Quote

Original von hjs
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 .

Display More

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...

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.

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

Jaja, die Readme... Ich gelobe Besserung

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

Quote

In Datei, eingefügt von cap_alloc.c:12:
libcap.h:57:3: Warnung: es wird empfohlen, #error vor traditionellem C mit # zu verbergen
libcap.h:57:3: Fehler: #error "Kernel <linux/capability.h> does not match library"
libcap.h:58:3: Warnung: es wird empfohlen, #error vor traditionellem C mit # zu verbergen
libcap.h:58:3: Fehler: #error "file "libcap.h" --> fix and recompile libcap"
libcap.h:101:25: Warnung: ISO-C erlaubt keine benannten variadischen Makros
cap_alloc.c: In Funktion »cap_init«:
cap_alloc.c:19: Warnung: traditionelles C weist Funktionsdefinitionen im ISO-C-Stil zurück
cap_alloc.c:26:28: Warnung: ISO-C99 erfordert, dass Restargumente verwendet werden
cap_alloc.c: In Funktion »_libcap_strdup«:
cap_alloc.c:46: Warnung: traditionelles C weist Funktionsdefinitionen im ISO-C-Stil zurück
cap_alloc.c: In Funktion »cap_dup«:
cap_alloc.c:73: Warnung: traditionelles C weist Funktionsdefinitionen im ISO-C-Stil zurück
cap_alloc.c:77:27: Warnung: ISO-C99 erfordert, dass Restargumente verwendet werden
cap_alloc.c:84:28: Warnung: ISO-C99 erfordert, dass Restargumente verwendet werden
cap_alloc.c: In Funktion »cap_free«:
cap_alloc.c:99: Warnung: traditionelles C weist Funktionsdefinitionen im ISO-C-Stil zurück
cap_alloc.c:118:65: Warnung: ISO-C99 erfordert, dass Restargumente verwendet werden
make[1]: *** [cap_alloc.o] Fehler 1
make[1]: Leaving directory `/sources/libcap-1.10.orig/libcap'
make: *** [all] Fehler 2

Display More

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

Quote

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

Any Ideas?

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

Quote

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

Komisch, das hat nicht funktioniert. Habe jetzt eine Woche kompilierpause einlegen müssen, morgen gehts aber weiter.

Es hängt momtentan immer noch an den DVB-Treibern. Einzeln kompilieren die CVS-Treiber nun und auch die Module kann ich laden, nur der VDR zickt, weil er wohl die DVB- und Kernelsourcen im gleichen Verzeichnis erwartet. Wie ich das hinkriege, hab ich noch nicht herausbekommen.

Mein Plan für morgen ist, den Kernel neu zu bauen und die enthaltenen DVB-Treiber lauffähig zu kriegen. Eigentlich bin ich auf die neusten CVS-Treiber ja nicht angewiesen (Nova-S).

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?

Ansonsten habe ich mich wahnsinnig gefreut, als mein handgemachtes System plötzlich bootfähig war. Mal schauen ob ich am Wochenende noch ein TV-Bild hinbekomme!

Grüße
Marc

Versuch macht kluch...
Um das cvs-Zeug rauszubekommen habe ich jetzt die Kernel-Sourcen neu entpackt und versuch mich nochmal am kompilieren. Bis zur menuconfig kommt er schonmal.

Moin hjs,

jetzt hats mich doch in den Fingern gejuckt, einen zweiten Anlauf zu nehmen. Nach ganztägigem Kompilieren (Tut Euch das auf einem Athlon 1600+ nicht an!) hat er zwar rebootet findet aber keinen Kernel.

Quote

drivers/media/Kconfig:31:error: found recursive dependency: VIDEO_V4L2_COMMON -> VIDEO_V4L2 -> VIDEO_CAPTURE_DRIVERS -> VIDEO_MXB -> VIDEO_SAA7146_VV -> VIDEO_SAA7146 -> I2C -> VIDEO_V4L2_COMMON
-> VIDEO_V4L1 -> VIDEO_V4L1_COMPATmake[1]: *** [oldconfig] Error 1
make: *** [oldconfig] Error 2
scripts/kconfig/conf -s arch/x86/Kconfig
drivers/media/Kconfig:31:error: found recursive dependency: VIDEO_V4L2_COMMON -> VIDEO_V4L2 -> VIDEO_CAPTURE_DRIVERS -> VIDEO_MXB -> VIDEO_SAA7146_VV -> VIDEO_SAA7146 -> I2C -> VIDEO_V4L2_COMMON
-> VIDEO_V4L1 -> VIDEO_V4L1_COMPATmake[2]: *** [silentoldconfig] Error 1
make[1]: *** [silentoldconfig] Error 2
make: *** No rule to make target `include/config/auto.conf', needed by `include/config/kernel.release'. Stop.
scripts/kconfig/conf -s arch/x86/Kconfig
drivers/media/Kconfig:31:error: found recursive dependency: VIDEO_V4L2_COMMON -> VIDEO_V4L2 -> VIDEO_CAPTURE_DRIVERS -> VIDEO_MXB -> VIDEO_SAA7146_VV -> VIDEO_SAA7146 -> I2C -> VIDEO_V4L2_COMMON
-> VIDEO_V4L1 -> VIDEO_V4L1_COMPATmake[2]: *** [silentoldconfig] Error 1
make[1]: *** [silentoldconfig] Error 2

The present kernel configuration has modules disabled.
Type 'make config' and enable loadable module support.
Then build a kernel with module support enabled.

make: *** [modules_install] Error 1
cp: cannot stat `arch/i386/boot/bzImage': No such file or directory
cp: cannot stat `System.map': No such file or directory
/hjslfs/tools/filefind: line 1: /var/hjslfs/build/: Is a directory

Display More

Da scheints zu hängen. Leider ist auch ein nachträgliches, manuelles Kernelbauen nicht erfolgreich, er geht nicht bis zur menuconfig:

Quote

scripts/kconfig/mconf arch/x86/Kconfig
drivers/media/Kconfig:70: can't open file "drivers/media/dvb/Kconfig"
make[1]: *** [menuconfig] Error 1
make: *** [menuconfig] Error 2

hjslfscd011, hjslfs-1.3.7.1, 004

Was kann ich denn da jetzt machen?

Grüße
Marc

Kann ich mich soweit anschließen (auch wenn der Urlaub um war, bevor easyvdr als Produktivsystem lief), allerdings stört mich die lange Bootzeit doch sehr.

Nachdem ich die linvdr Platte wieder drin hatte und nach kurzer Zeit das Bild da war, war das schon schön. 20 sek mehr können viel sein! 1 Minute finde ich schon sehr lang.

Wenn die Entwickler (wink) da noch ein bisschen was machen...
Ich weiß aber auch, dass das eine Gratwanderung ist. Komfortfunktionen wie udev, etc sind leider nicht mit kurzer bootzeit vereinbar. Schade, aber ist ja häufiger im Leben so.