@BARF wegen deinen neuen Rules ;-)

Beitrag von **Barf** » Montag 13. März 2006, 08:51

@Günther: Angenommen es nicht das "Bad Magic"-Problem ist (der LCD sagt in diesem Fall "Kein System") muss das Problem entweder in dem BR-Bootloader oder in dem FLFS/U-boot partition liegen. Chip-Anzahl richtig? Läuft es beim Flashen von z.B. dietmarw-Images?

Beitrag von **Günther** » Montag 13. März 2006, 09:10

Angenommen es nicht das "Bad Magic"-Problem ist (der LCD sagt in diesem Fall "Kein System")

bei mir steht da nur 'loading kernel'

muss das Problem entweder in dem BR-Bootloader oder in dem FLFS/U-boot partition liegen

Chip-Anzahl richtig?

jepp nokia mit 2x

Läuft es beim Flashen von z.B. dietmarw-Images?

Werde ich gleich mal ausprobieren. Das jtg funktioniert auf jedenfall. Werde jetzt mein erzeugtes Image noch mal mit einer Sagem 1x ausprobieren.

Günther

Beitrag von **Günther** » Montag 13. März 2006, 09:41

So habe jetzt mal ein paar Images geflasht. Meine mit newmake erzeugten Images funktionieren weder auf der Sagem1x noch auf der Nokia2x. Die dietmarw Images allerdings schon. Scheint als ob die Image-Maker Gilde doch noch nicht wegzudenken ist

Also, ich habe mich beim letzten Image ganz nach Anleitung verhalten. Frisches cvs geholt, kompiliert als squashfs. Der Magic check für 1x war iO. Allerdings habe ich keine weiteren Änderungen gemacht, also auch keine bootlogos, ucodes, ect.

Und ich hatte mich schon so gefreut mal ein eigenes Image zu bauen

Günther

PS: Barf, Deine Anleitung ist übrigens Klasse. Vor allem mit ein paar mehr Infos als die üblichen Howtos...

Beitrag von **dietmarw** » Montag 13. März 2006, 09:44

Günther hat geschrieben:...Meine mit newmake erzeugten Images funktionieren weder auf der Sagem1x noch auf der Nokia2x. Die dietmarw Images allerdings schon.

bei den images steckt bei mir reines newmake dahinter, (wobei ich nur mit make everything arbeite)
bei den yadds ist schon noch etwas händische nacharbeit dabei..

Beitrag von **Günther** » Montag 13. März 2006, 09:58

bei den images steckt bei mir reines newmake dahinter, (wobei ich nur mit make everything arbeite)

liegt es ev. daran das Deine Images vom 27.2. sind? Ich habe ja gestern komplett geupt. Kannst Du denn ein aktuelles squashfs image erstellen, welches funktioniert ?

Günther

Beitrag von **dietmarw** » Montag 13. März 2006, 10:04

wenn newmake seit den dort liegenden squashfs images
eins ohne bad magics erzeugt hätte, dann läge es dort

edit: auf dem backupserver scheint ein neutrino 1x geklappt zu haben, lade ich mal hoch. (taucht in der übersicht nicht auf)

Beitrag von **Barf** » Montag 13. März 2006, 10:15

Es klingt wie "This cannot happen"

Mit der Beschreibung sollte es en Problem mit dem FLFS-Partition sein. Probiere ein Solche von einem dietmarw-image zu extrahieren, z.B. mit ein Kommando wie

Code: Alles auswählen

dd if=neutrino-squashfs.img2x of=squashfs.flfs2x bs=128k count=1

und benutze dies anstatt deine eigene.

Kannst du jffs2-images bauen/flashen?

Beitrag von **Günther** » Dienstag 14. März 2006, 07:36

Also Danke erst einmal für Eure Anteilnahme!

Gabe gerade mal getan wie angeraten: Leider ist alles so wie vorher - meine Images gehen nicht, die von DiemtarW schon.

1. Das aktuelle 1x image von dietmarw geht, das darin enthaltene squashfs.flfs1x ist auch bis auf das Datum das Gleiche wie bei meinem erzeugten squashfs.flfs1x.
2. Meine 1x und 2x image funktionieren auch nicht mit dem extrahierten squashfs.flfs1x und squashfs.flfs2x von dietmarws Februar images.
3. Das Feb-squashfs.flfs2x von Diemtarw ist deutlich unterschiedlich zu meinem squashfs.flfs2x
4. Alles wie gesagt getestet mit einem frisch gesaugten cvs, unter Einhaltung der orginal Barf regeln (weiter oben hatte ich noch meinen vorherigen Versuch gepostet), ohne ucodes, logos ect.

Was nu?

EDIT: Achja ich wollte ja noch die jffs2 und crams images mal ausprobieren.
Übrigens bei den oben beschriebenen Versuchen war die Magic-Byte Fehlermeldung beim 2x mit dem Austausch des squashfs.flfs2x behoben worden

Günther

Beitrag von **Tommy** » Dienstag 14. März 2006, 07:55

./configure --prefix=/home/Guenther/tux/audio/image --with-cvsdir=/home/Guenther/tux/audio/cvs --with-ucodesdir=/home/Guenther/tux/custom/var/ucodes --with-logosdir=/home/Guenther/tux/custom/var/tuxbox/boot/logos --with-checkImage=warn --enable-maintainer-mode

wenn Du ohne Logos und ucodes baust warum gibst Du's im configure dann an?

Beitrag von **Günther** » Dienstag 14. März 2006, 08:01

Tommy hat geschrieben:wenn Du ohne Logos und ucodes baust warum gibst Du's im configure dann an?

das war mein erster Versuch, danach hatte ich um alle Eventualitäten auszuschalten, nochmal ein komplettes cvs nach Barfschen Vorgaben gesaugt. Die hatte ich dann allerdings nicht mehr gepostet, die sind aber ohne ucodes usw.

Achja übrigens, das cramfs 1x funktioniert! Das 2x könnte ich wegen magic bytes nicht testen. Scheint sich bei mir also um ein squashfs Problem zu handeln???
Günther

Beitrag von **Barf** » Dienstag 14. März 2006, 08:50

Dann bleibt eigentlich nur zwei Verdächtige: das squashfs und der Kernel. Weil dein cramfs läuft ist der Kernel unwahrscheinlich. Weilche mksquashfs benutzt du? (Seit ein Paar Monaten gibt es mksquashfs in CVS).

Beitrag von **Günther** » Dienstag 14. März 2006, 19:47

So nachdem ich das mksquashfs in usr/bin ausgetauscht habe funktioniert es (kaum macht man es richtig, schon geht es

)

Vielen, vielen Dank für Eure Hilfe, ich hätte mir hier sonst einen Wolf gesucht (ich wußte gar nicht das mksquashfs schon installiert war

)

Günther

Beitrag von **yjogol** » Dienstag 14. März 2006, 19:50

@barf
distribution-lists.mk
cramfs.urls.mk
fehlen in newmake.files

Gruß
yjogol

Beitrag von **yjogol** » Donnerstag 16. März 2006, 18:03

Beim make yadd-neutrino bekomme ich:

Code: Alles auswählen

make -C root install
make[1]: Entering directory `/home/y/tuxbox/tuxbox-cvs/cdk/root'
Making install in etc
make[2]: Entering directory `/home/y/tuxbox/tuxbox-cvs/cdk/root/etc'
Making install in init.d
make[3]: Entering directory `/home/y/tuxbox/tuxbox-cvs/cdk/root/etc/init.d'
make[4]: Entering directory `/home/y/tuxbox/tuxbox-cvs/cdk/root/etc/init.d'
make[4]: Für das Ziel Â»install-exec-amÂ« ist nichts zu tun.
make[5]: Entering directory `/home/y/tuxbox/tuxbox-cvs/cdk/root/etc/init.d'
make[5]: *** Keine Regel vorhanden, um das Target Â»initializeÂ«,
  benötigt von Â»install-standardÂ«, zu erstellen.  Schluss.
make[5]: Leaving directory `/home/y/tuxbox/tuxbox-cvs/cdk/root/etc/init.d'
make[4]: *** [install-data-local] Fehler 2
make[4]: Leaving directory `/home/y/tuxbox/tuxbox-cvs/cdk/root/etc/init.d'
make[3]: *** [install-am] Fehler 2
make[3]: Leaving directory `/home/y/tuxbox/tuxbox-cvs/cdk/root/etc/init.d'
make[2]: *** [install-recursive] Fehler 1
make[2]: Leaving directory `/home/y/tuxbox/tuxbox-cvs/cdk/root/etc'
make[1]: *** [install-recursive] Fehler 1
make[1]: Leaving directory `/home/y/tuxbox/tuxbox-cvs/cdk/root'
make: *** [/home/y/tuxbox/dbox2/cdkroot/etc/init.d/rcS] Fehler 2

Habe vor configure

In HEAD, there are two files cdk/root/etc/init.d/rcS and root/etc/init.d/rcS.insmod. In newmake, these are instead products, which are generated from its source root/etc/init.d/rcS.m4. It is therefore advisable to delete cdk/root/etc/init.d/rcS and root/etc/init.d/rcS.insmod, just to be on the safe side.

durchgeführt.
Jemand eine Idee?

Gruß
yjogol

Beitrag von **Barf** » Donnerstag 16. März 2006, 19:17

initialize ist ein File, die vor etwa ein Monat zugekommen war. Irgendwie hast du es nicht beim checkout/update bekommen. Also einfach auschecken.

Ich sehe, dass ich vergessen habe, es in newmake.files zu erwähnen. Danke für dein Hinweis in dem vorgehende Posting.

Beitrag von **saruman** » Freitag 17. März 2006, 10:10

@Barf:
Habe mich gestern endlich mal drangemacht und den newmake Branch ausgecheckt. Klasse, aus meiner Sicht hat alles funktioniert. Prima Anleitung, die ist nahezu DAU-fest.

Ist es möglich, dass Dir auf Deiner Webseite ein Fehler unterlaufen ist? Du schreibst hier:

In HEAD, there are two files cdk/root/etc/init.d/rcS and root/etc/init.d/rcS.insmod. In newmake, these are instead products, which are generated from its source root/etc/init.d/rcS.m4. It is therefore advisable to delete cdk/root/etc/init.d/rcS and root/etc/init.d/rcS.insmod, just to be on the safe side.

Müssten das nicht eher die beiden Files cdk/root/etc/init.d/rcS und cdk/root/etc/init.d/rcS.insmod sein?

Ansonsten aber wirklich klasse, prima Arbeit in meinen Augen. Danke!

Beitrag von **yjogol** » Freitag 17. März 2006, 17:55

@Barf: läuft

Eine Frage:
Wenn ich statt einem Yadd ein Flash bauen will, muß ich dann immer configure mit " --enable-flashrules" aufrufen und andersherum, wenn ich einen yadd baue dann ohne??
Oder kann ich in beiden Fällen immer mit --enable-flashrules bauen??

Gruß
yjogol

Beitrag von **Barf** » Freitag 17. März 2006, 18:25

--enable-flashrules macht was der Name sagt, macht imagebauen möglig ohne yadd-bauen unmöglich zu machen (in Unterschied zu HEAD). Einzige Unterschied für yadd-bauen ist dass die Programme wird mit anderem TARGET_CFLAGS kompiliert (mit/ohne Debugging), und dass in --enable Fall Installationsregeln aus rules-install-flash benutzt wird. (Das Letzte möchte ich eigentlich abschaffen...)

@saruman: Thanx!

Beitrag von **saruman** » Sonntag 19. März 2006, 10:21

Zwei ich noch.

Eben sauber ausgecheckt und neue Neutrino-Yadd gebaut. Beim Starten des TuxMail Plugins kommt folgende Meldung in der Konsole:

Code: Alles auswählen

TuxMail <Font "/share/fonts/pakenham.ttf" failed>
TuxMail <FTC_Manager_Lookup_Face failed with Errorcode 0x01>
[CPlugins] exec done...

Nach dem Reinkopieren des Fonts in die Yadd funktioniert es. Nimmst Du den Font noch mit rein?

Und nun noch eine Herausforderung: Ich habe zwei Boxen zuhause, möchte eine mit Neutrino und eine andere mit Enigma betreiben. Jetzt möchte ich natürlich nicht zweimal auschecken und zwei CDKs bauen um zwei Yadds zu erstellen und die Boxen gesondert booten zu können. Wie würde man das am besten erledigen? An sich müsste doch ein

Code: Alles auswählen

./configure --prefix=/data/tuxbox --with-cvsdir=/data/tuxbox/head --enable-maintainer-mode --with-ucodesdir=/data/tuxbox/additional/ucodes --with-logosdir=/data/tuxbox/additional/logos --with-targetprefix=/data/tuxbox/dbox/cdkroot --with-bootprefix=/data/tuxbox/dbox/tftpboot
make yadd-neutrino

./configure --prefix=/data/tuxbox --with-cvsdir=/data/tuxbox/head --enable-maintainer-mode --with-ucodesdir=/data/tuxbox/additional/ucodes --with-logosdir=/data/tuxbox/additional/logos --with-targetprefix=/data/tuxbox/dbox2/cdkroot --with-bootprefix=/data/tuxbox/dbox2/tftpboot
make yadd-enigma

schon reichen? Oder klappt das nicht?

Beitrag von **Tommy** » Sonntag 19. März 2006, 12:07

geht da nicht

make yadd-all ?

Beitrag von **saruman** » Sonntag 19. März 2006, 13:08

Ja, habe ich auch gedacht. Aber wenn ich Barfs Anleitung richtig verstanden habe baut er dann ja alle Oberflächen in ein und dasselbe $TARGETPREFIX. Damit kann ich dann natürlich nicht beide gleichzeitig booten, weil nun beide Boxen zwar unterschiedliche Oberflächen booten würden, aber gleichzeitig auf gemeinsam genutzte Files zugreifen. Das wär irgendwie suboptimal denke ich. Die dbox hat ja (noch

) kein ClusterFS...

@Barf:
Ich hab noch was gefunden: make yadd-all gibt mir

Code: Alles auswählen

powerpc-tuxbox-linux-gnu-g++ -shared -nostdlib /data/tuxbox/cdk/lib/gcc/powerpc-tuxbox-linux-gnu/3.4.4/../../../../powerpc-tuxbox-linux-gnu/lib/nof/crti.o /data/tuxbox/cdk/lib/gcc/powerpc-tuxbox-linux-gnu/3.4.4/nof/crtbeginS.o  .libs/movieplayer_la-movieplayer.o  -Wl,--rpath -Wl,/data/tuxbox/cdk/powerpc-tuxbox-linux-gnu/lib/nof -Wl,--rpath -Wl,/data/tuxbox/cdk/powerpc-tuxbox-linux-gnu/lib/nof -L/data/tuxbox/cdk/lib/gcc/powerpc-tuxbox-linux-gnu/3.4.4/nof -L/data/tuxbox/cdk/lib/gcc/powerpc-tuxbox-linux-gnu/3.4.4 -L/data/tuxbox/cdk/lib/gcc/powerpc-tuxbox-linux-gnu/3.4.4/../../../../powerpc-tuxbox-linux-gnu/lib/nof -L/data/tuxbox/cdk/lib/gcc/powerpc-tuxbox-linux-gnu/3.4.4/../../../../powerpc-tuxbox-linux-gnu/lib /data/tuxbox/cdk/powerpc-tuxbox-linux-gnu/lib/nof/libstdc++.so -lm -lc -lgcc_s_nof /data/tuxbox/cdk/lib/gcc/powerpc-tuxbox-linux-gnu/3.4.4/nof/crtsavres.o /data/tuxbox/cdk/lib/gcc/powerpc-tuxbox-linux-gnu/3.4.4/nof/crtendS.o /data/tuxbox/cdk/lib/gcc/powerpc-tuxbox-linux-gnu/3.4.4/../../../../powerpc-tuxbox-linux-gnu/lib/nof/crtn.o  -mcpu=823 -Wl,-O1 @CURL_LIBS@ -Wl,-soname -Wl,movieplayer.so.0 -o .libs/movieplayer.so.0.0.0
powerpc-tuxbox-linux-gnu-g++: @CURL_LIBS@: No such file or directory
make[2]: *** [movieplayer.la] Fehler 1
make[2]: Leaving directory `/data/tuxbox/head/apps/tuxbox/plugins/enigma/movieplayer'
make[1]: *** [all-recursive] Fehler 1
make[1]: Leaving directory `/data/tuxbox/head/apps/tuxbox/plugins/enigma'
make: *** [enigma-plugins] Fehler 2

Beitrag von **Barf** » Sonntag 19. März 2006, 18:55

saruman hat geschrieben:

Code: Alles auswählen

TuxMail <Font "/share/fonts/pakenham.ttf" failed>
TuxMail <FTC_Manager_Lookup_Face failed with Errorcode 0x01>
[CPlugins] exec done...

Eigentlich sollte die Makefile für tuxmail dafür sorgen, dass die notwendige Fonts installiert sind/wird, entweder durch Prerequisites, oder durch tatsächlich Installation. Dies ist nicht der Fall.

Ich habe ein einwas unschön fix anstatt in neutrino.mk implementiert. Besser wäre natürlich ...

Jetzt möchte ich natürlich nicht zweimal auschecken und zwei CDKs bauen um zwei Yadds zu erstellen und die Boxen gesondert booten zu können. Wie würde man das am besten erledigen?

Die furchterliche Wahrheit ist dass z.Z. keine saubere Lösung existiert. Die vorgeschlagene Lösung fordert dass du z.B. eine make distclean dazwischem machst, und den Compiler und glibc neu zu baust. Einige wesentliche Dateien werden beim glibc-installation in cdkroot installiert.

Ich habe mich überlegt, falls mann "wirkliche" yadd-targets implementieren sollte, die etwas wie dietmarws yadds bauen, z.B. durch rüberkopieren von cdkroot. Die existiernde yadd-* Targets könnte mann dann in cdk-* umbenennen? Klar was ich meine?

Eine Lösung "auf die schnelle" wäre dass dbox1 und dbox2 gemeinsam cdkroot als root mountet, dann mountet boxprivate filesysteme auf (z.B.) /etc und /var.

Code: Alles auswählen

powerpc-tuxbox-linux-gnu-g++: @CURL_LIBS@: No such file or directory

Irgendwie läuft bei mir der Build durch, auch wenn @CURL_LIBS@ nicht expandiert wird. Fix.

Beitrag von **yada** » Sonntag 19. März 2006, 20:04

in newmake busybox.config.m4 fehlen ein paar sachen für die neue busybox:
wahrscheinlich das gleiche auch im head zweig.

CONFIG_FEATURE_INIT_SWAPON
CONFIG_DBOX_WATCHDOG
CONFIG_BBOX_SYSCTL
CONFIG_NFS_MOUNT
CONFIG_FEATURE_MOUNT_FORCE

gruß yada

Beitrag von **racker** » Sonntag 19. März 2006, 21:08

yada hat geschrieben:in newmake busybox.config.m4 fehlen ein paar sachen für die neue busybox:
wahrscheinlich das gleiche auch im head zweig.

CONFIG_FEATURE_INIT_SWAPON
CONFIG_DBOX_WATCHDOG
CONFIG_BBOX_SYSCTL
CONFIG_NFS_MOUNT
CONFIG_FEATURE_MOUNT_FORCE

gruß yada

CONFIG_FEATURE_INIT_SWAPON
CONFIG_FEATURE_MOUNT_FORCE
gibt es nicht mehr
und die anderen sind schon noch da...

Beitrag von **yada** » Sonntag 19. März 2006, 21:12

busybox fragt aber genau die werte bei mir ab, wenn ich es durchcompilieren will...