@BARF wegen deinen neuen Rules ;-)

Beitrag von **Barf** » Sonntag 30. April 2006, 22:57

Ich habe HEAD busybox.config und busybox-flash.config auf die Schnelle in eine (neue) busybox.config.m4 gemerged, und eingechecked. Um newmake compilefähig zu halten. Über die Sinnvollkeit einige Parametern drin bin ich nicht überzeugt, so gibt es viele Platsfordernde Features die in Flash, aber nicht in YADD enabled sind. Mal sehen, was passiert.

Beitrag von **Tommy** » Montag 1. Mai 2006, 07:46

Barf hat geschrieben:Ich habe HEAD busybox.config und busybox-flash.config auf die Schnelle in eine (neue) busybox.config.m4 gemerged, und eingechecked. Um newmake compilefähig zu halten. Über die Sinnvollkeit einige Parametern drin bin ich nicht überzeugt, so gibt es viele Platsfordernde Features die in Flash, aber nicht in YADD enabled sind. Mal sehen, was passiert.

das meiste ist denk ich mal wg. dem mmc card support dazugekommen. Könnte man nicht eine --with mmccardsupport option reinnehmen und dann eine andere config nutzen?

Beitrag von **mrpiados** » Montag 1. Mai 2006, 15:12

ich habe mich nun auch mal dazu begeben das ganze hier zu testen und ich finde es toll !
es funktioniert sogar die busybox jetzt ohne nachfragen ! super !

ich würde nur gerne wissen wie kann ich das ganze neu erstellen lassen nach änderungen im code OHNE alles neu machen zu müssen !

also wenn ich in neutrino was geändert habe dann mit make neutrino neu gemacht und dann wioll ich ein image erstellen !
wie muss ich das machen ?

habe gesucht aber nix gefunden oder ich bin zu blind !

danke happy greetz MrPiados

Beitrag von **Tommy** » Montag 1. Mai 2006, 15:24

also ich mache immer ein make flash-semiclean vorm bauen. Du findest sämtliche cleantargets auf Barfs Website beschrieben:
http://www.bengt-martensson.de/dbox2/ne ... an+targets

Beitrag von **mrpiados** » Montag 1. Mai 2006, 18:21

also verstehe ich das richtig ??

erst
make flash-semiclean
und dann
make flash-neutrino-jffs2-all

und die änderungen wie gehabt unter
/tuxbox-cvs/cdk
make neutrino zb ??

schaut ja so aus !
nur bekomme ich jetzt beim 2x bad magic bytes !

happy greetz mrp

Beitrag von **Tommy** » Montag 1. Mai 2006, 18:37

sieht soweit gut aus. Es gibt auch noch make mostlyclean und ganz brutal make distclean (da muß dann alles neu gebaut werden >2h).

für eigene anpassungen dienen die diversen customizing skripte die zur jeweiligen Bauzeit eingeklinkt werden. Guck mal ab http://forum.tuxbox-cvs.sourceforge.net ... 4&start=80 und folgende Beiträge. Dort sind auch beispiele.

Patchen tust Du nach wie vor in den entsprechenden CVS verzeichnissen

Beitrag von **mrpiados** » Montag 1. Mai 2006, 18:46

also das mit den customize scripten hat bei mir auf anhieb geklappt ! (hätte ich selber nicht geglaubt !)

da ich ja noch blutiger anfänger bin

komme ich hier mit barfs sachen echt gut klar !

aber kann es sein das gewisse sachen die vorher im HEAD gefunzt haben hier nicht mehr gehen ??

ich meine quelltext mäßig !
ich hab mir mal ein image gebastelt mit eigenen menüs usw die gingen vorher nach tuxbox-wiki ast rein war halt nur cramfs und ein bisschen wenig platz ! die funzen hier aber nicht wirklich so wie vorher !

Beitrag von **Tommy** » Montag 1. Mai 2006, 19:03

wo hast Du denn die Änderungen vorgenommen? Ist es möglich das Du durch den CVS download Deine Änderungen "überpappt " hast? Anderseits - wenn Du eine fertige neutrino hast, kannst Du die per customizing skript austauschen. Wenn Du cramfs bauen willst geht das auch - make flash-neutrino-cramfs-all z.B.

übrigens - mit den bad magics müssen wir leben. Ich helf mir immer damit, das ich eine datei im root vergrößere oder verkleinere (durch kommentarzeilen etc) Ein paar Bytes hin oder helfen da meist. Patentrezept gibts net

Beitrag von **mrpiados** » Montag 1. Mai 2006, 19:31

die änderungen kommen vor dem compilen rein !

via script kopiere ich dann meine sourcen ins tuxbox-cvs verzeichnis !

also im grunde überschreibe ich die neuen daten !

das mit dem cramfs und sq hab ich auch verstanden ! cramfs will ich ja nicht mehr haben ! jffs2 only ist voll ok für mich ! da kann ich wenigstens nacher noch was umbasteln !

bad dingens hab ich auch jetzt gemerkt das geht jetzt !

nur er haut mir die verschiedenen locales durcheinander !

also wenn da movieplayer stehen soll hab ich da xtramenü stehen usw !
voll seltsam !

Beitrag von **mrpiados** » Montag 1. Mai 2006, 19:40

ist denn so ein unterschied zwischen
newmake und

set CVS_RSH=ssh && cvs -d anoncvs@cvs.tuxbox-cvs.sourceforge.net:/cvs/tuxbox -z3 co -P .

happy greetz mrp

Beitrag von **Tommy** » Freitag 12. Mai 2006, 09:51

@Barf:

Feature Request - in der busybox unter newmake fehlen (für diverse speedtests z.B.):

-time
-dd
-sort

ist es ein Problem die Sachen als default zu aktivieren? Über "sort" kann man sich freilich streiten

Beitrag von **Barf** » Freitag 12. Mai 2006, 13:32

Schnelle Rückmeldung:

busybox in newmake enthält (z.Z.) die gleiche Befehle als HEAD. Zur Geschischte: Für etwa zwei Wochen hat jemanden einfach buysbox zu Version 1.1.2 geändert. Da newmake eigene Konfigurationsfile(s) benutzt, aber nicht eigene rules-archive/rules-make war newmake dadurch in einem nicht kompilierbares Zustand versetzt worden.

Wie ich in einem anderen Beitrag geschrieben habe, habe ich einfach die HEAD-konfigurationsfiles in das newmake m4-konfigurationfile zusammengefasst, ohne die einzelne Parametern zu überprüfen. Ich habe in dem Beitrag geschrieben, dass mir scheint am mindestens nicht alle Parametern sorgfällig und sinnvoll gewählt worden zu sein.

Die wirklich interessante Frage ist ja naürlich über sinnvolle Parameter, evtl. customization.

Beitrag von **Tommy** » Freitag 12. Mai 2006, 16:26

...das über ein eine customization (script) zu machen halte ich für zu aufwändig. Es ist ja leicht die busybox.config.m4 selbst zu ändern. Ein abgestimmter Standard wäre genial - nur wie kann man über so viele Bestandteile Einigkeit erreichen?! Eine Umfrage zu starten würde mit sicherheit in endlosen Diskussionen enden. Eine andere möglichkeit wäre, sämtliche im Umlauf befindliche Skripte zu checken - auch viiiel zu aufwendig.

Mhhh - wie kommen wir da raus?

Beitrag von **mrpiados** » Samstag 20. Mai 2006, 19:20

kann mir da keiner auskunft drüber geben ??

Beitrag von **racker** » Samstag 20. Mai 2006, 19:43

mrpiados hat geschrieben:kann mir da keiner auskunft drüber geben ??

Checke newmake ohne " -f" Option in ein eigenes Verzeichnis aus,
dann siehst du die Unterschiede.

Beitrag von **mrpiados** » Mittwoch 24. Mai 2006, 22:51

so jetzt funktioniert alles !!!

bin ja voll begeistert !

hut ab !

Hallo,

ich arbeite mich gerade in das Newmake ein. Ich habe noch leichte Probleme einige Änderungen in das Skript (die Skripte) einzufügen. Ich möchte z.B. gerne lediglich Tuxtxt und Satfind als Plugins behalten, wobei ich Tuxtxt gerne in 001Tuxtxt(so und cfg natürluch) umbenennen möchte, damit so die blaue Taste belegt wird.

Ich habe es so versucht:

PLUGINS="tuxtxt stafind"

for f in $newroot/lib/tuxbox/plugins/*; do
(echo $PLUGINS | grep -v `basename $f .*` >/dev/null) && rm -f $f

aber das geht nicht.
Danach sollte dann das Umbenennen mit "mv" stattfinden...

Hat jemand eine elegante Lösung für mich??
MfG
doktorknow

Beitrag von **Barf** » Sonntag 27. August 2006, 18:23

doktorknow hat geschrieben: Hat jemand eine elegante Lösung für mich??

Ich gehe davon aus, dass du über (z.B.) root-local.sh redest. Warum notwendigerweise eine "elegante" Lösung? Etwas enfaches wie z.B.

Code: Alles auswählen

cd DEIN_PFAD/root/lib/tuxbox/plugins/
mv tuxtxt.cfg 001tuxtxt.cfg
mv tuxtxt.so 001tuxtxt.so

tut es auch.

Beitrag von **dietmarw** » Sonntag 27. August 2006, 20:11

er meinte wohl eher das löschen aller plugins ausser den beiden

ich hoffe mal nicht das du stafind geschrieben hast??

PLUGINS="tuxtxt stafind"

Beitrag von **doktorknow** » Montag 28. August 2006, 21:19

Ja, ich meinte das Löschen der Plugins (außer Tuxtxt und Satfind).

Den Schreibfehler habe ich rausgenommen, aber es kommen dennoch Fehler und alle Plugins bleiben erhalten.
Ich poste morgen ein Log.

Danke erstmal!
MfG
doktorknow

Beitrag von **Barf** » Montag 28. August 2006, 21:28

doktorknow hat geschrieben:Ja, ich meinte das Löschen der Plugins (außer Tuxtxt und Satfind).

Ok, ich habe dein Posting schlecht gelesen, 'tschudigung. Mein eigenliche "Botschaft" bleibt aber: Mann kann es auch wenig elegant machen. Z.B. mit mehrfache rm-s.

Den Schreibfehler habe ich rausgenommen, aber es kommen dennoch Fehler und alle Plugins bleiben erhalten.

schreibe

set -x

im Skript. Dann sehst du was passiert, und was schiefläuft.

Hallo,
wie kann es eingentlich sein, dass bei einem "make-neutrino-squashfs-all" das 1ximg fehlerfrei erstellt wird und das 2ximg bei checkImage immer den "Bad magic" Fehler ausgibt?

Kann ich einfach das 1ximg in ein 2ximg umwandeln und habe somit das Problem umgangen??

/usr/bin/mkfs.jffs2 -b -e 131072 -p -r /USB_LINUX/dbox2-nm/cdkflash/var-neutrino -o /USB_LINUX/dbox2-nm/cdkflash/var-neutrino.jffs2
make -C /USB_LINUX/tuxbox-cvs-nm/hostapps/checkImage install INSTALLDIR=/USB_LINUX/dbox2-nm/cdk/bin
make[1]: Entering directory `/USB_LINUX/tuxbox-cvs-nm/hostapps/checkImage'
if gcc -DHAVE_CONFIG_H -I. -I. -I.. -g -O2 -MT checkImage.o -MD -MP -MF ".deps/checkImage.Tpo" -c -o checkImage.o checkImage.c; \
then mv -f ".deps/checkImage.Tpo" ".deps/checkImage.Po"; else rm -f ".deps/checkImage.Tpo"; exit 1; fi
/bin/sh ../libtool --tag=CC --mode=link gcc -g -O2 -o checkImage checkImage.o
mkdir .libs
gcc -g -O2 -o checkImage checkImage.o
make[2]: Entering directory `/USB_LINUX/tuxbox-cvs-nm/hostapps/checkImage'
test -z "/USB_LINUX/dbox2-nm/cdk/bin" || mkdir -p -- "/USB_LINUX/dbox2-nm/cdk/bin"
/bin/sh ../libtool --mode=install /usr/bin/install -c 'checkImage' '/USB_LINUX/dbox2-nm/cdk/bin/checkImage'
/usr/bin/install -c checkImage /USB_LINUX/dbox2-nm/cdk/bin/checkImage
make[2]: Für das Ziel Â»install-data-amÂ« ist nichts zu tun.
make[2]: Leaving directory `/USB_LINUX/tuxbox-cvs-nm/hostapps/checkImage'
make[1]: Leaving directory `/USB_LINUX/tuxbox-cvs-nm/hostapps/checkImage'
/USB_LINUX/tuxbox-cvs-nm/hostapps/flash/flashmanage.pl -i /USB_LINUX/dbox2-nm/cdkflash/neutrino-squashfs.img1x -o build \
--rootsize=0x660000 \
--part ppcboot=/USB_LINUX/dbox2-nm/cdkflash/squashfs.flfs1x \
--part root=/USB_LINUX/dbox2-nm/cdkflash/root-neutrino.squashfs \
--part var=/USB_LINUX/dbox2-nm/cdkflash/var-neutrino.jffs2
/USB_LINUX/dbox2-nm/cdk/bin/checkImage /USB_LINUX/dbox2-nm/cdkflash/neutrino-squashfs.img1x || mv /USB_LINUX/dbox2-nm/cdkflash/neutrino-squashfs.img1x /USB_LINUX/dbox2-nm/cdkflash/neutrino-squashfs.img1x_bad
check 'neutrino-squashfs.img1x' for bad magic bytes.
No bad magic bytes found
[ -x /USB_LINUX/tuxbox-cvs-nm/cdk/neutrino-squashfs.img1x-local.sh ] && /USB_LINUX/tuxbox-cvs-nm/cdk/neutrino-squashfs.img1x-local.sh /USB_LINUX/dbox2-nm/cdkflash /USB_LINUX/tuxbox-cvs-nm/cdk || true
/USB_LINUX/tuxbox-cvs-nm/hostapps/flash/flashmanage.pl -i /USB_LINUX/dbox2-nm/cdkflash/neutrino-squashfs.img2x -o build \
--rootsize=0x660000 \
--part ppcboot=/USB_LINUX/dbox2-nm/cdkflash/squashfs.flfs2x \
--part root=/USB_LINUX/dbox2-nm/cdkflash/root-neutrino.squashfs \
--part var=/USB_LINUX/dbox2-nm/cdkflash/var-neutrino.jffs2
/USB_LINUX/dbox2-nm/cdk/bin/checkImage /USB_LINUX/dbox2-nm/cdkflash/neutrino-squashfs.img2x || mv /USB_LINUX/dbox2-nm/cdkflash/neutrino-squashfs.img2x /USB_LINUX/dbox2-nm/cdkflash/neutrino-squashfs.img2x_bad
check 'neutrino-squashfs.img2x' for bad magic bytes.
!!! If you flash this image these bytes cause 'no system' !!!
[ -x /USB_LINUX/tuxbox-cvs-nm/cdk/neutrino-squashfs.img2x-local.sh ] && /USB_LINUX/tuxbox-cvs-nm/cdk/neutrino-squashfs.img2x-local.sh /USB_LINUX/dbox2-nm/cdkflash /USB_LINUX/tuxbox-cvs-nm/cdk || true
doktorknow@KanotixBox:/USB_LINUX/tuxbox-cvs-nm/cdk$

MfG
doktorknow

Beitrag von **Tommy** » Mittwoch 30. August 2006, 17:48

Ähnliches beobachte ich auch seit einiger Zeit. Nur interessierts mich nicht da ich nur das 1er brauche. Relativ gesehen sind 80% der 2xi Müll

Beitrag von **Barf** » Mittwoch 30. August 2006, 19:35

wie kann es eingentlich sein, dass bei einem "make-neutrino-squashfs-all" das 1ximg fehlerfrei erstellt wird und das 2ximg bei checkImage immer den "Bad magic" Fehler ausgibt?

Lese den Code in checkImage! Es wird bei 2x-images etwa vier (?) mal so viele Bytes gecheckt. Also kommt "bad magic bytes" viel öfter bei 2x als bei 1x-Images vor.

Kann ich einfach das 1ximg in ein 2ximg umwandeln und habe somit das Problem umgangen??

Nein, aus oben genannte Grund.

Ist übrigens kein newmake-thema.

Danke zunächst für die ERklärung!!

Lese den Code in checkImage! Es wird bei 2x-images etwa vier (?) mal so viele Bytes gecheckt. Also kommt "bad magic bytes" viel öfter bei 2x als bei 1x-Images vor.

Bedeutet das, dass wenn bei einem 1x Image auch genau so viele Bytes getestet würden, dann wäre gleich oft der Fehler "Bad magic bytes" vorhanden? Und hieße das weiter, dass nicht immer, wenn dieser Fehler angezeigt wird, ein "Kein System" die Folge wäre??

Ist übrigens kein newmake-thema.

Sollte auch keine Kritik am Newmake sein. Ich finde das Newmake wirklich gut (obwohl ich es erst seit einer Woche nutze). Nur vorher hatte ich nie ein 1ximg gebaut und jetzt fällt halt auf, dass im gleichen "make-Prozess" einmal der Fehler auftritt und einmal nicht.

Ich muss mich wohl noch einmal genauer in checkImage einlesen. Im Moment bin ich nämlich etwas ratlos, was ich gegen diese Bad magics machen kann ... oder muss man einfach ein paar Mal bauen und irgendwann ist ein "heiles" Image dabei

Naja, ich werde nochmal ein wenig stöbern ...
MfG
doktorknow

Tuxbox-Board

@BARF wegen deinen neuen Rules ;-)

1ximg ok; 2ximg bad magic - wieso?