HOWTO make an image...

Ist es wirklich so ein Geheimnis, wie man ein Image für die dbox erstellt ?

Beitrag von **Homar** » Mittwoch 30. Juli 2003, 15:27

guck mal...

Hier im Board sind etliche Threads, wo beschrieben wird, wie man Images erstellt - allerdings als Teillösungen für bestimmte Probleme.

Fasse doch alle diese Threads zusammen und erstelle ein Howto für andere die das machen wollen.

Wenn du zu fein bist, die Sachen durchzulesen und dich durch die Materie durchzuarbeiten, dann ist mir meine Zeit (und andere devs auch) genauso schade drum.

Also, was lernen wir daraus ???

Setzte dich auf dein Gesäss und mache mal was für die Allgemeinheit !!!

du sagst also, hier im forum steht immer häppchenweise wie man ein image erstellt...
na wenn du meinst...
ich lese hier viel öfter, das nicht preisgegeben wird, wie man ein richtiges image erstellen kann, welches man auf die box spielen kann, oder dass die im cvs veröffentlichten sachen dazu nicht ausreichen.
ein yadd zum laufen zu bekommen funktioniert ja ganz prima. nur wer will ernsthaft immer den rechner laufen lassen ?
wenn ich mir allerdings die howto's für images anschaue, dann funktionieren die nur teilweise.

außerdem habe ich hier im forum schon mal die schritte aufgeführt die ich hier so rausgelesen hatte mit der einfachen bitte, dass leute die images erstellen können diese auf ihre richtigkeit kontrollieren bzw. fehlende schritte ergänzen...

...aber da kam nix raus

ich weiß nicht, warum hier so ein theater gemacht wird. wenn ich weiß wie ein kuchenrezept geht und einer das haben möchte, dann schreibe ich ihm die paar stichpunkte hin und tippe nicht frasen wie "such es dir zusammen"

hier kommt auch öfter der tenor "programmiert lieber etwas fürs projekt anstatt zu versuchen images zu erstellen"
ich kann mir vorstellen, dass viele erst mal die hürde nehmen wollen ein image zu erstellen und zu sehen, das das funktioniert bevor dann (zugegebenermaßen wohl eher ein geringer teil von denen) irgendwelche neuerungen oder bugfixes zu programmieren versucht

letztendlich wird mir wahrscheinlich noch eins übergezogen, wenn ich herausfinde wie man ein image erstellt und dies dann der allgemeinheit zur verfügung stelle

anders kann ich mir diese kontraproduktive haltung hier nicht erklären

Beitrag von **Homar** » Mittwoch 30. Juli 2003, 15:52

Beispiel:
JOCKYW2001

Erst sieben Beiträge und schon hat er sich ein eigenes Image machen können.

Beitrag von **Zahni** » Mittwoch 30. Juli 2003, 15:57

Also Image erstellen sollte möglich sein. Da gibt es nicht geheimes. Was nicht geht ist ein eigenes PPCBOOT / U-Boot-FLFS Image zu erzeugen.

Neulich schrieb jemand, dass es genügt einfach sein fertiges PPCBOOT / U-Boot an einen Developer zu schicken. Die machen das dann...

Ansonsten ist das hier ein Hobby-Projekt. Und wer hat da schon Lust Doku's zu schreiben. Bzw. wer hat überhaupt Lust dazu

.

-Zahni

Also JOCKYW2001 hat es wohl so gemacht:

./autogen.sh
./configure --prefix=/dbox2 --with-cvsdir=$HOME/tuxbox-cvs --enable-maintainer-mode --with-targetruleset=flash
make all
make flash-neutriono-all
make flash-jffs2image

Große Preisfrage: für flash-jffs2image gibt es keine regeln. Was nehme ich stattdessen und sind das dann wirklich aller schritte die ich tun muss ? Ich nehme mal an, dass ich noch vorher die boot-logos und die ucodes ins CDK Verzeichnis kopieren sollte.

wenn ich "make cramfsimage" nehme ist das kein vollständiges Image, was ich mit dem dbox-boot-manager auf die box spielen kann, oder ? Dann bootete die box bei mir nämlich nicht mehr.

@ Zahni: Was heißt Image ? Ich glaube jeder macht sich seine eigene Definition von Image ? Ein Image in meinem Sinn wäre, wenn ich es mit dem dbox-boot-manager auf die box spielen könnte und fertig. Aber das ist wohl eher das U-Boot-FLFS Image ?

Beitrag von **Z80** » Mittwoch 30. Juli 2003, 16:22

da hier son bohei gemacht wird, poste ich mal ein howto aus einem anderen board.
kann den direkten link allerdings nicht posten, da illegal. der inhalt sollte es aber nicht sein.
----

HOWTO zum Erstellen eines Images vom CVS

Inhaltsverzeichnis:

1. Vorwort

2. Vor dem Start â€“ Welche Voraussetzungen müssen für dieses HowTo gegeben sein

3. Wie man den Source auscheckt

4. Den Source downloaden

5. Erstellen des CDK

5.1. YADD testen

6. Vorbereitung für JFFS2 Image für Head Branch

a) Einschub für Punkt 6 für das HEAD vom 09.03.2003

7. Vorbereitung für JFFS2 Image des Release Branch:

8. Vorbereitung der Netzwerkeinstellungen bei HEAD und RElease Branch:

b) Ergänzungen zum HEAD vom 09.03.2003

9. Bei dem Release Branch Telnet Verlinkung:

10. Weitere Vorbereitungen nur für HEAD BRanch

11. Image aus dem Release Branch erstellen

12. Erstellen des flashbaren Images aus dem Head

13. Zusammenfügen der Imagedateien für den Release Branch

c) Zusatz HEAD 09.03.2003 Netzwerkeinstellungen

14. Danke an:

1. Vorwort:

Die Beschreibung setzt ein Linux Betriebssystem voraus. Cygwin Beschreibungen sollten von HOMAR vorhanden sein. Siehe Database!

Im Folgenden werden die Befehle, die man selber eingibt in blauer Schrift dargestellt als Beispiel:

cvs -d:pserver:anonymous@cvs.berlios.de:/cvsroot/tuxbox login

Alle Ausgaben aus der Konsole werden in rot dargestellt:

Logging in to :pserver:anonymous@cvs.berlios.de:2401/cvsroot/tuxbox
CVS password:

2. Vor dem Start:

Es sollten folgende Pakete installiert sein:

Prerequistes: (aus INSTALL.en stand 2003/02/12 -- kann sich jederzeit aendern)
--------------
- cvs
- autoconf >= 2.50
- automake >= 1.4p5
- libtool >= 1.4
- gettext >= 0.10.38
- make >= 3.79
- makeinfo (texinfo)
- tar
- bunzip2
- gunzip
- patch
- infocmp (ncurses-bin)
- gcc 2.95 or >= 3.0
- g++ 2.95 or >= 3.0
- yacc
- flex
- bison
- pkg-config

Zur Überprüfung der einzelnen Versionen werden in der Konsole die einzelnen Programme mit dem Zusatz â€“version angezeigt:

Beispiel:

Die Konsole zeigt sich bei mir so, wenn sie gestartet wird:

acky:~ #

nun gibt man z.B. für die Überprüfung von gcc folgendes ein:

gcc --version

wenn eine Version vorhanden ist meldet sich die Konsole in etwa so:

gcc (GCC) 3.2

Copyright (C) 2002 Free Software Foundation, Inc.

This is free software; see the

source for copying conditions. There is NO

warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR

PURPOSE.

Wenn eine Version nicht vorhanden ist, dann wird halt irgendein Fehler angezeigt.

Bei yacc etc. wird keine Versionsnummer angegeben, sondern es werden Parameter für einzelne Optionen angezeigt. Wenn das der Fall ist weiss man, dass das Modul auch korrekt installiert ist. Als Beispiel:

yacc --verison

und die Ausgabe:

usage: yacc [-dlrtv] [-b file_prefix] [-p symbol_prefix] filename

Die Zeichen >= bedeuten in diesem Fall natürlich, dass eine höhere Version als die angegebene auch funktioniert. In Worten also eine Versinon größer oder gleich der angegebenen Versionsnummer.

Des weiteren sollte eine der folgenden Dateien

mkfs.jffs2

oder

mkjffs2

in das /(bin Verzeichnis kopiert werden. Die Rechte sollten mit

chmod 777 /bin/mkfs.jffs2

bzw.

chmod 777 /bin/mkjffs2

angepasst werden

3. Wie man den Source auscheckt:

Ok zunächst sollte man einen neuen User unter Linux erstellen, den ich aus Bequemlichkeit Acky nenne, weil ich unter dem Namen in Liunx angemeldet bin und so einfacher die Befehle hier reinkopieren kann.

Anlegen des CVS Verzeichnisses:

In der Konsole wird das Verzeichnis tuxbox-cvs angelegt indem wir in der Konsole eingeben:

mkdir $HOME/tuxbox-cvs

danach in das Verzeichnis wechseln mit:

cd $HOME/tuxbox-cvs

Jetzt melden wir uns auf den berlios Server an, von dem wir das CVS runterladen wollen:

cvs -d:pserver:anonymous@cvs.berlios.de:/cvsroot/tuxbox login

Der Server verlangt nun eine Passwortabfrage, die allerdings mit einem einfachen drücken der ENTER Taste (sprich kein Passwort) bestätigt werden kann. Das sieht so aus:

Logging in to :pserver:anonymous@cvs.berlios.de:2401/cvsroot/tuxbox
CVS password:

Hier also einfach <ENTER> drücken.

Jetzt kommt die Entscheidung ob man den Release Branch den Head Branch oder den AlexW Branch auschecken möchte.

Der neuste Release Branch der stabil laufen sollte hat die Versionsnummer rel_1_0_0. Der Head Branch ist meist junger bzw. neuer, aber hat meist auch noch einige Bugs drinn, die es dann schwer machen das Image für Ungeübte und Nichtprogrammierer zum laufen zu bringen. Der AlexW Branch (weiss ich im Moment nichts zu â€“ muss noch ergänzt werden).

Hier noch mal im Überblick die Befehlszeilen, die für die einzelnen Branches eingegeben bzw. kopiert werden müssen (in Schriftgröße 9 damit der ganze Befehl in eine Zeile passt):

Head Branch : cvs -d:pserver:anonymous@cvs.berlios.de:/cvsroot/tuxbox -z3 co -r HEAD .
Release Branch : cvs -d:pserver:anonymous@cvs.berlios.de:/cvsroot/tuxbox -z3 co -r rel_1_0_0 -P .
alexw Branch: cvs -d:pserver:anonymous@cvs.berlios.de:/cvsroot/tuxbox -z3 co -r rel_alexW .

Der Punkt am Ende ist übrigens kein Schreibfehler, sondern der muss dahin!!
Zu der Befehlszeile soll noch kurz erwähnt werden:
Der Punkt "." am Ende der Zeile heißt, dass alles ausgecheckt wird.
Das "co" ist die Kurzform für Checkout
"z3" ist der Kompressionsgrad von gz-Dateien. 1 ist dabei der niedrigste Wert (niedrige Kompression), 9 ist der höchste Wert.

So eigentlich sollte man am besten mit dem Release Branch beginnen, da dieser im allgemeinen stabiler ist als der HEAD Branch. Es kann aber immer wieder vorkommen, dass der Release Branch an bestimmten Tagen eben doch buggy ist und der HEAD Branch durchläuft. Man muss sich hier also entscheiden womit man es versuchen will. Die Beschreibung geht im Folgenden auf beide CVS-Stände ein.

das Update für alle geht folgendermaßen:

cvs -d:pserver:anonymous@cvs.berlios.de:/cvsroot/tuxbox -r -z9 update -P â€“d

Alle weiteren Informationen befinden sich schon im CVS deshalb reicht für alle dieses Kommando für das Update

Also in die Konsole (wo wir vorher das Passwort mit <ENTER> bestätigt hatten) machen wir jetzt mit:

cvs -d:pserver:anonymous@cvs.berlios.de:/cvsroot/tuxbox -z9 co .

weiter.

Jetzt rattert die Kiste erstmal alleine los mit etwa folgenden Zeilen:

...
...
U apps/tuxbox/tools/configure.ac
cvs server: Updating apps/tuxbox/tools/camd
U apps/tuxbox/tools/camd/Makefile.am
U apps/tuxbox/tools/camd/camd.c
U apps/tuxbox/tools/camd/camd.h
U apps/tuxbox/tools/camd/cat.c
U apps/tuxbox/tools/camd/cat.h
U apps/tuxbox/tools/camd/sdt.c
U apps/tuxbox/tools/camd/sdt.h
cvs server: Updating apps/tuxbox/tools/misc
U apps/tuxbox/tools/misc/.cvsignore
U apps/tuxbox/tools/misc/Makefile.am
U apps/tuxbox/tools/misc/aviafbtool.c
U apps/tuxbox/tools/misc/camd.c
U apps/tuxbox/tools/misc/lcddump.c
U apps/tuxbox/tools/misc/pluginx.c
U apps/tuxbox/tools/misc/rcinfo.c
U apps/tuxbox/tools/misc/saa.c
...
...

Bei DSL dauert diese Prozedur etwa 2 Minuten. Dabei werden auch einige Verzeichnisse erstellt. Unter anderem das Verzeichnis cdk in welches wir nun wechseln mit:

cd cdk

Hier wird nun das makefile erstellt. Dazu geben wir noch einmal folgendes in die Konsole ein:

./autogen.sh

und dann:

./configure --prefix=$HOME/dbox2 --with-cvsdir=$HOME/tuxbox-cvs --enable-maintainer-mode

Folgende Ausgabe erscheint in etwa auf der Konsole:

uxbox@sonne:~/tuxbox-cvs$ cd cdk
tuxbox@sonne:~/tuxbox-cvs/cdk$./autogen.sh
Generating configuration files for tuxbox-cdk, please wait....
aclocal
libtoolize --automake
autoconf
configure.ac:13: warning: AC_ARG_PROGRAM was called before AC_CANONICAL_TARGET
automake --add-missing
automake: configure.ac: installing `./install-sh'
automake: configure.ac: installing `./mkinstalldirs'
automake: configure.ac: installing `./missing'
automake: Makefile.am: installing `./INSTALL'
automake: Makefile.am: installing `./COPYING'
tuxbox@sonne:~/tuxbox-cvs/cdk$

Das WARNING (hier in der 7. Zeile) ist ok, da man bei Linux stark zwischen WARNING und ERROR unterscheiden sollte.

Jetzt entscheiden wir uns, ob wir ein Flash oder eine Yadd erstellen wollen (wir nehmen hier ein Flash) und geben folgende Zeile ein:

./configure --prefix=$HOME/dbox2 --with-targetruleset=flash --with-cvsdir=$HOME/tuxbox-cvs --enable-maintainer-mode

Wenn wir eine Yadd machen wollten, dann würden wir anstelle von targetruleset=flash halt targetruleset=yadd eingeben.

Da man mit dem Flash-Eintrag auch eine Yadd machen kann bietet sich eigentlich immer der targetruleset=flash Eintrag an. Umgekehrt (wenn man targetruleset=yadd schreibt und dann ein Flash machen will) geht es nicht.

Jetzt kommt wieder eine ähnliche Ausgabe auf der Konsole:

checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether to enable maintainer-specific portions of Makefiles... yes
checking for gcc... gcc
checking for C compiler default output... a.out
checking whether the C compiler works... yes
checking whether we are cross compiling... no
checking for suffix of executables...
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc accepts -g... yes
checking for gcc option to accept ANSI C... none needed
checking for style of include used by make... GNU
checking dependency style of gcc... none
checking build system type... i686-pc-linux-gnu
checking host system type... i686-pc-linux-gnu
checking target system type... powerpc-tuxbox-linux-gnu
checking for apps directory... yes
checking for boot directory... yes
checking for driver directory... yes
checking for hostapps directory... yes

Summary:
Hostruleset: standard
Targetruleset: standard
Targetprefix: /home/tuxbox/dbox2/cdkroot
Hostprefix: /home/tuxbox/dbox2/cdk
Bootprefix: /home/tuxbox/dbox2/tftpboot
Buildprefix: /home/tuxbox/tuxbox-cvs/cdk
Appsdir: /home/tuxbox/tuxbox-cvs/apps
Bootdir: /home/tuxbox/tuxbox-cvs/boot
Driverdir: /home/tuxbox/tuxbox-cvs/driver
Hostappsdir: /home/tuxbox/tuxbox-cvs/hostapps

configure: creating Makefile-archive
configure: creating ./config.status
config.status: creating Makefile
config.status: creating root/Makefile
config.status: creating root/etc/Makefile
config.status: creating root/etc/init.d/Makefile
config.status: creating root/etc/network/Makefile
config.status: creating root/share/Makefile
config.status: creating root/share/udhcpc/Makefile
config.status: executing default-1 commands
tuxbox@sonne:~/tuxbox-cvs/cdk$

4. Den Source Downloaden:

Wir befinden uns ja immer noch im Verzeichnis â€¦tuxbox-cvs/cdk

Hier geben wir jetzt einfach den Befehl:

make download

ein. Dadurch wird der Download vom Berlios Server gestartet. Dies dauert immer unterschiedlich lange und ist nicht immer gleich erfolgreich. Teilweise kommt es nämlich vor, dass einige Dateien nicht erreichbar sind und somit das make download gestoppt wird. Das sieht dann etwa so aus:

tuxbox@sonne:~/tuxbox-cvs/cdk$ make download
wget -c -P Archive http://tuxbox.berlios.de/pub/tuxbox/cdk ... 2.2.tar.gz || \
wget -c --passive-ftp -P Archive ftp://ftp.gnu.org/gnu/gcc/gcc-3.2.2/gcc ... 2.2.tar.gz
--11:15:18-- http://tuxbox.berlios.de/pub/tuxbox/cdk ... 2.2.tar.gz
=> `Archive/gcc-core-3.2.2.tar.gz'
Auflösen des Hostnamen Â»tuxbox.berlios.deÂ«.... fertig.
Verbindungsaufbau zu tuxbox.berlios.de[195.37.77.138]:80... verbunden.
HTTP Anforderung gesendet, warte auf Antwort... 404 Not Found
11:15:18 FEHLER 404: Not Found.

Jetzt bleibt einem entweder die Möglichkeit einfach noch mal

make download

einzutippen, oder aber über eine Suchmaschine (z.B. Google) die betreffende Datei selbst zu suchen und dann in das Verzeichnis â€¦tuxbox-cvs/cdk/Archive zu speichern.

Da mehr als 100MB herunter geladen werden müssen kann diese Prozedur schon eine Weile dauern. Um sicher zu gehen, dass auch wirklich alles vorhanden ist gibt man am Ende (sobald nichts mehr herunter geladen wird) nochmals:

make download

ein. Wenn alles vorhanden ist sollte als Ausgabe etwa so was kommen wie:

Nothing left to do for <make download>

Diese Prozedur muss nicht immer wiederholt werden. Die Ansammlung von Dateien wird im Verzeichnis tuxbox-cvs/cdk/Archiv gespeichert. Nur bei Änderungen ist also ein erneutes make downlaod nötig.

Des Weiteren können auch bei anderen CVS-Checkouts die Dateien aus dem /Archiv-Verzeichnis verwendet werden. Somit wird der Download stark minimiert bzw. muss gar nicht erst gemacht werden. Hierfür macht man einen Softlink in die anderen CVS-Stände.

Beispiel für Softlink von Merandos:

home/tuxbox/mycvs1

sei die Basis meines ersten cvs Standes. Z.B. für einen Release Branch.
Dann ist Archiv in:

home/tuxbox/mycvs1/cdk/Archive

home/tuxbox/mycvs2

sei die Basis meines zweiten cvs Standes. Z.B.. für einen Head oder AlexW Branch
dann kann ich z.B. mit

ln -s /home/tuxbox/mycvs1/cdk/Archive /home/tuxbox/mycvs2/cdk/Archive

einen Softlink auf Archive in meinem 2ten cvs Verzeichnis erstellen.
Wenn nun durch ein make download in mycvs2 neue Dateien herunter geladen werden,
werden die natürlich physikalisch in mycvs1/cdk/Archive gespeichert. Das ist aber nicht schlimm! im Gegenteil, das ist sogar praktisch ;-)
Für weitergehende Informationen in Hinsicht auf Verlinkung kann man in der Konsole
man ls

eingeben.

5. Erstellen des cdk:

Nun folgt lediglich der Befehl:

make all

Das make extra ist für ein lauffähiges Image nicht notwendig und da wir ja einen Einstieg hier beschreiben wollen bleibt alles erstmal so einfach wie möglich! Also, make extra bleibt erstmal aussen vor!!

So als Ausgabe auf der Konsole geht es jetzt für ein paar Stunden abâ€¦

Es beginnt etwa mit Folgendem:

/usr/bin/install -c -d /home/tuxbox/dbox2/cdkroot/bin
/usr/bin/install -c -d /home/tuxbox/dbox2/cdkroot/dev
/usr/bin/install -c -d /home/tuxbox/dbox2/cdkroot/etc
/usr/bin/install -c -d /home/tuxbox/dbox2/cdkroot/include
/usr/bin/install -c -d /home/tuxbox/dbox2/cdkroot/mnt
/usr/bin/install -c -d /home/tuxbox/dbox2/cdkroot/lib
/usr/bin/install -c -d /home/tuxbox/dbox2/cdkroot/proc
/usr/bin/install -c -d /home/tuxbox/dbox2/cdkroot/root
/usr/bin/install -c -d /home/tuxbox/dbox2/cdkroot/sbin
/usr/bin/install -c -d /home/tuxbox/dbox2/cdkroot/tmp
/usr/bin/install -c -d /home/tuxbox/dbox2/cdkroot/var
/usr/bin/install -c -d /home/tuxbox/dbox2/cdkroot/var/run
/usr/bin/install -c -d /home/tuxbox/dbox2/cdkroot/var/tuxbox/ucodes
/usr/bin/install -c -d /home/tuxbox/dbox2/cdk/powerpc-tuxbox-linux-gnu
/usr/bin/install -c -d /home/tuxbox/dbox2/tftpboot
rm /home/tuxbox/dbox2/cdk/powerpc-tuxbox-linux-gnu/include
rm: Entfernen von Â»/home/tuxbox/dbox2/cdk/powerpc-tuxbox-linux-gnu/includeÂ« nicht möglich: Datei oder Verzeichnis nicht gefunden
make: [.directories] Fehler 1 (ignoriert)
rm /home/tuxbox/dbox2/cdk/powerpc-tuxbox-linux-gnu/lib
rm: Entfernen von Â»/home/tuxbox/dbox2/cdk/powerpc-tuxbox-linux-gnu/libÂ« nicht möglich: Datei oder Verzeichnis nicht gefunden
make: [.directories] Fehler 1 (ignoriert)
ln -s /home/tuxbox/dbox2/cdkroot/include /home/tuxbox/dbox2/cdk/powerpc-tuxbox-linux-gnu/include
ln -s /home/tuxbox/dbox2/cdkroot/lib /home/tuxbox/dbox2/cdk/powerpc-tuxbox-linux-gnu/lib
ln -s /home/tuxbox/tuxbox-cvs/cdk/linux/include/asm /home/tuxbox/dbox2/cdk/powerpc-tuxbox-linux-gnu/include
ln -s /home/tuxbox/tuxbox-cvs/cdk/linux/include/linux /home/tuxbox/dbox2/cdk/powerpc-tuxbox-linux-gnu/include
touch .directories

Wenn es optimal läuft sollte alles mit der Ausgabe enden:
rm â€“rf nano-1.0.7
touch .nano
acky:~/tuxbox-cvs/cdk
Falls es zwischendurch zu Problemen kommt wie z.B. es erscheint so etwas:

make [2]: *** [../obj_s/comp_captab.o] Error 1
make [2]: leaving directory â€¦â€¦â€¦/ncurses
make [1]: *** [.libncurses] Error 2

dann kann man das mit folgendem Befehl übergehen.

touch .llibncurses

Der "touch" - Befehl täuscht letztendlich ein erfolgreiches "make" vor. Dies funktioniert so, weil bei erfolgreichem "make" immer eine Datei (man kann sie sich als eine Art Merker vorstellen) erstellt wird, anhand derer sich das makefile "merkt" welche Dateien schon kompiliert wurden. "touch .driver" z.B. erzeugt nun eine leere Datei ".driver" und gaukelt so dem makefile vor die Kompilierung von driver wäre erfolgreich gewesen. Somit macht das makefile mit dem nächsten Schritt (nach driver also) weiter. Die fertig kompilierten Datei werden übrigens als Targets bezeichnet. Im makefile sind die Targets aufgeführt die erstellt werden.

Der Befehl "rm" hingegen löscht Dateien (remove). Dies wird im späteren Teil des HowTos noch wichtig. Sinnvoll ist dieser Befehl immer dann, wenn im Nachhinein noch Dateien angepasst werden müssen und man nicht das komplette CVS neu kompilieren will. Dann wird eine bestimmte Datei in der Änderungen vorgenommen wurden gelöscht z.B. rm .linuxkernel und danach kann allein der linuxkernel neu kompiliert werden.

Ich kann an dieser Stelle leider nicht sagen, welche Pakete essentiell bzw. nicht zu touchen sind, damit das Image später auch noch fehlerfrei laufen kann. Da brauche ich auf jeden Fall noch Feedback von den Profis! Klar sollte aber sein, dass wenn man ein Neutrino-Image erstellen will, man ohne Bedenken enigma und lcars touchen kann. Auf der sicheren Seite ist man, wenn man das Problem noch mal im Board postet und sich erkundigt, ob der aufgetretene Fehler sich auf das angestrebte Image auswirken wird, oder ob man es touchen kann.

Nach dem make all sollte ein dbox2 Verzeichnis entstanden sein mit einigen Unterverzeichnissen:

/dbox2/cdkroot

/dbox2/tftpboot

/dbox2/cdkflash

5.1 YADD testen:

Der Zeitpunkt ist gekommen, an dem wir mal testen können, ob die ganze Sache läuft.

Also Beschreibung (bitte um Verbesserungen falls Fehler drin sind!!!):

Ich gehe hier nicht auf das strippen ein, weil bei mir das strippen noch nie wirklich geklappt hat. Das soll deshalb lieber jemand machen der das auch kann!!!

Sobald das compilieren durchgelaufen ist befinden im Ordner dbox2 unter anderem die Verzeichnisse CDKROOT und TFTPBOOT.
In diese Verzeichnisse müssen wir nun noch einige Dateien aus unserer D-Box übernehmen, damit wir die Yadd testen können. Diese Dateien sind:

/var/tuxbox/ucodes > ucode.bin; cam-alpha.bin; die jeweilige avia.ux
/var/tuxbox/config/zapit > bouquets.xml; services.xml
/var/tuxbox/config > scan.conf

Diese Dateien werden in die gleichnamigen Verzeichnisse des CDKROOT Ordners gelegt.

Des weiteren müssen die Dateien lobo-fb und logo-lcd aus der D-Box (/boot > logo-fb; logo-lcd)
in den Ordner TFTPBOOT gelegt werden. Hier müssen nun also 4 Dateien vorhanden sein.

Jetzt packt man die beiden Verzeichnisse, bevor man sie auf die Windows-Platte schiebt, damit die Verlinkungen nicht verloren gehen.
Dazu wechselt man in das dbox2 Verzeichnis in der Konsole und gibt folgendes ein (nach emmeli):

tar -cvf yadd.tar cdkroot tftpboot
chmod 755 cdkroot -R
chgrp 100 cdkroot -R
chown 500 cdkroot -R
gzip -9 yadd.tar

Danach hat man die Datei yadd.tar.gz im dbox2 Verzeichnis. Diese kann jetzt auf die Windows-Platte und mit Hilfe der untar_utils entpackt werden (siehe Readme der untar_utils).
Nach dem entpacken sollten wieder die Verzeichnisse CDKROOT und TFTPBOOT im Verzeichnis sein.
Dann startet man den Bootmanager. Die Netzwerkverbindung sollte natülich funzen.
Hier nun ein Auszug aus der ReadMe des Bootmanagers für den Start einer Yadd:

0. DBox über Netzwerkkabel und Serielle Schnittstelle anhängen.
1. Die richtige Netzwerkkarte auswählen (dort wo die DBox hängt), RARP muß aktiviert sein.
2. Gewünschte DBox-IP überprüfen / eintragen (muß aus dem gleichen
Nummernkreis wie Eure Netzwerkkarte sein)
3. COM-Port prüfen (Baud-Rate auf 57600) - HIER BITTE FEEDBACK!! BEI MIR funktioniert DIE AUSGABE NUR MIT 9600 BAUD!
4. RARP-Server könnt ihr ausschalten (wird nicht mehr gebraucht, erhöht die Stabilität)
5. BootP-Server EINschalten und richtiges Bootfile für die Box auswählen
Wenn ihr zB die YADD verwendet, dann kommt also das "c:\untar_utils\tftpboot\ppcboot" hin
!! Verwendet am besten die Tools aus UnTar_Utils.zip, dieses File findet ihr auch auf meiner Web-Seite (http://dbox.feldtech.com/) !!
6. Richtiges NFS-Root Verzeichnis kontrollieren, sollte sich mit dem Bootfile mit geändert haben
7. Start-Knopf drücken...
8. Box starten und alles sollte klappen!

ZUSATZ:

Wenn man einen Head Branch auscheckt, dann hat man in dem Verzeichnis tftpboot keine ppcboot mehr, sonder eine u-boot. Mit dieser Datei funktioniert der hier beschriebene Startvorgang nicht! Ich lege in den Dateianhang eine ppcboot bei, die dann anstelle der u-boot Datei ausgewählt erden muss. Am besten ersetzt man die u-bbot durch die ppcboot.

6. Vorbereitung für JFFS2 Image des Head Branch:

Im Verzeichnis /dbox2 sind nun also die Unterverzeichnisse
/cdkroot
/cdkflash
/tftpboot
Das cdkflash Verzeichnis sollte als einziges von diesen leer sein. Um ein Image zu erstellen muss dieses Verzeichnis gefüllt sein. Hierfür ist der Befehl make flash-neutrino-all zuständig. Damit dieser Befehl aber auf unterstützende Dateien zugreifen kann müssen wir jetzt noch ein wenig vorbereiten.
Dies gilt nur für JFFS2 â€“ cramfs etc. brauche ich noch Infos!!

Zunächst muss der Kernel neu kompiliert werden. Dazu müssen folgende Dateien ausgetauscht werden

dbox2-flash.c diese Datei befindet sich in â€¦/tuxbox-cvs/cdk/linux/linux-2.4.20/drivers/mtd/maps/

do_mounts.c diese Datei befindet sich in â€¦/tuxbox-cvs/cdk/linux/linux-2.4.20/init/

Das kopieren kann mit dem Konqueror gemacht werden oder wie man auch will. Zur Sicherheit sollten die Rechte noch mal überprüft werden ( müssen auf rwx rwx rx stehen). Ggf mit dem Befehl

chmod 777 â€¦/tuxbox-cvs/cdk/linux/linux-2.4.20/drivers/mtd/maps/ dbox2-flash.c und

chmod 777 â€¦/tuxbox-cvs/cdk/linux/linux-2.4.20/ init/ do_mounts.c

Des weiteren wird die Datei mklibs in das Verzeichnis /usr/bin kopiert. Auch hier wieder ggf. die Rechte anpassen mit:

chmod 777 /usr/bin/mklibs

WICHTIG!!!!

Wenn man einen Release Branch auscheckt muss die Datei umbenannt werden in mklibs.py Nun gehen wir in das /tuxbox-cvs/cdk/linux-Verzeichnis und geben folgendes ein:

make dep clean

dann:

cd ..

jetzt sind wir wieder im â€¦/tuxbox-cvs/cdk Verzeichnis. Jetzt wird der bisherige linuxkernel entfernt mit:

rm .linuxkernel

das geht schnell. Nun den neuen linuxkernel erstellen mit:

make .linuxkernel

Jetzt kompiliert Linux wieder und es kommen einige Ausgaben auf der Konsole. Wenn hier alles durchgelaufen ist sollten wir den nächsten Befehl eingeben:

make flash-neutrino-all

Jetzt wird das cdkflash Verzeichnis gefüllt. Das dauert wieder ein paar Minuten! Zeit um einen Kaffe aufzusetzten!

a) EINSCHUB FÜR HEAD VOM 09. MÄRZ 2003

Hier müssen wir eine Veränderung am makfile vornehmen, bevor wir den Befehl make flash-neutrino-all ausführen. Dazu gehen wir mit dem Konqueror in das tuxbox-cvs/cdk Verzeichnis und öffnen mit einem Editor die Datei Makefile. Recht weit unten in dieser Datei befindet sich die Zeile:

cp -pa $(targetprefix)/share/fonts/tuxtxt.fon $(flashprefix)/root/share/fonts

Diese ändern wir in:

cp -pa $(targetprefix)/share/fonts/tuxtxt*.fon $(flashprefix)/root/share/fonts

Es wird also â€žnurâ€œ das â€ž*â€œ hinter tuxtxt eingefügt! Danach wird die Datei wieder gespeichert.

7. Vorbereitung für JFFS2 Image des Release Branch:

Kurzer Einschub!!!
Im Gegensatz zum HEAD Branch muss man für den Release Branch die Datei "mklibs" in "mklibs.py" umbenennen und ins /usr/bin Verzeichnis kopieren. Zur Sicherheit werden noch mal die Rechte kontrolliert und ggf. mit dem Befehl: chmod 777 /usr/bin/mklibs.py

angepasst.
So, weiter gehts:

Im Verzeichnis /dbox2 sind nun also die Unterverzeichnisse
/cdkroot
/cdkflash
/tftpboot
Das cdkflash Verzeichnis sollte als einziges von diesen leer sein. Damit sich dieses Verzeichnis jetzt mit der Imagestruktur füllt geben wir im Verzeichnis
acky:~/tuxbox-cvs/cdk

den Befehl:

rebuilt-flash

ein. Nun sollte sich das CDKFLASH Verzeichnis gefüllt haben mit der Verzeichnisstruktur, die wir aus der D-Box schon kennen.

Jetzt müssen die Verschiedenen Pakete kompiliert werden, die man im späteren Image haben möchte. Für ein Neutrino Image sollten folgende Pakete reichen. Wir geben also wieder im gleichen Verzeichnis:

acky:~/tuxbox-cvs/cdk

folgende Befehle ein:

make flash-neutrino
(das komplette Neutrino Paket)
make flash-ftpd
(das ftp Paket)
make flash-telnetd
(das telnet Paket)
make flash-plugins oder make flash-fx2
(das plugin Paket je nach Stand)
Nach jeder Befehlseingabe wird ein Kompilierungsvorgang gestartet.
Es gibt noch weitere Befehle, wenn man z.B. enigma oder lcars im Image haben möchte:
make flash-enigma
make flash-lcars
etc.

Wenn man alle Pakete kompiliert hat, die man in seinem Image haben möchte kommt noch ein Befehl, damit alle libs vorhanden und gestrippt sind:

make flash-lib

Das wars schon fast mit den Vorbereitungen

Jetzt werden noch die ucodes kopiert und zwar nach /cdkflash/root/var/tuxbox/ucodes

Ebenfalls müssen noch die logo-fb und die logo-lcd nach /cdkflash/root/boot kopiert werden.

Somit ist das CDKFLASH Verzeichnis so vorbereitet, dass mit dem eigentlichen erstellen des Images begonnen werden kann.

8. Vorbereitung der Netzwerkeinstellungen bei HEAD und RElease Branch:

Es müssen noch einige Veränderungen gemacht werden, da es beim strippen (wofür die mklibs gebraucht wird) zu unerwünschten Effekten kommt. Zunächst müssen wir die Datei interfaces verändern. Diese finden wir in:

/dbox2/cdkflash/root/etc/network/ hier liegt die Datei interfaces

Diese kann mit einem Editor geöffnet werden und folgende Veränderungen werden vorgenommen:

So sieht die Datei eigentlich aus (jetzt nicht in der Konsole sondern im Editor):

auto lo

iface lo inet loopback

#auto eth0

#iface eth0 inet static

#address 10.0.0.42

#gateway 10.0.0.1

#netmask 24

Und so sollte die Datei für uns aussehen:

auto lo

iface lo inet loopback

auto eth0

iface eth0 inet static

address 10.0.0.42

gateway 10.0.0.1

netmask 24

Es müssen also alle â€ž#â€œ entfernt werden.

Danach wird die Datei einfach gespeichert.

Jetzt werden die Dateien satellites.xml und cables.xml ins cdkflash Verzeichnis übernommen.

Die Dateien liegen im Moment noch im cdkroot Verzeichnis. Das machen wir aus Bequemlichkeit mit dem Konqueror.

Die Dateien befinden sich in folgendem Verzeichnis:

b) Ergänzung für HEAD vom 09.03.:

Aufgrund eines kleinen Bugs im CVS kann man die Netzwerkeinstellungen nicht in der D-Box speichern. Daher sollte man an dieser stelle schon seine eigentlichen Netzwerk Parameter eintragen, die er normalerweise im Menü â€žNetzwerkeinstellungenâ€œ in der D-Box machen würde. Bei mir sieht die Datei interfaces dann so aus:

auto lo

iface lo inet loopback

auto eth0

iface eth0 inet static

address 192.168.6.90

broadcast 192.168.6.255

netmask 255.255.255.0

#netmask 24

Ich habe hier also â€œnurâ€ die Einstellungen für die Verbindung D-Box â€“ PC eingegeben. Wer noch die Verbindung zum Internet haben möchte muss noch die Gateway Daten eintragen.

Danach wird die Datei einfach gespeichert!

HIER GEHTS MIT DEM HEAD BRANCH WEITER!!!(10)

9. Bei dem Release Branch Telnet Verlinkung:

Für den telnet â€“login kann noch eine Verlinkung von â€žloginâ€œ auf â€žtinyloginâ€œ gemacht werden.
Dafür gehen wir in das Verzeichnis:
acky:~/dbox2/cdkflash #

und geben folgenden Befehl ein:
ln â€“sf /bin/tinylogin tuxbox-cvs/dbox2/cdkflash/root/bin/login

und zum Passwort ändern noch:

ln â€“sf /bin/passwd tuxbox-cvs/dbox2/cdkflash/root/bin/login

HIER GEHTS MIT DEM RELEASE BRANCH WEITER!!!(11)

10. Weitere Vorbereitungen nur für HEAD Branch:

/dbox2/cdkroot/share/tuxbox/

und müssen nach:

/dbox2/cdkflash/root/share/tuxbox/

Danach wird die Datei inetd verlinkt. Das machen wir wieder mit der Konsole:

Wir gehen ins cdkflash Verzeichnis (bei mir siehtâ€™s dann so auf der Konsole aus):

acky:~/dbox2/cdkflash #

und geben dann folgendes ein:

rm root/sbin/inetd

dann:

cd root/sbin

dann:

ln -s ../bin/busybox inetd

dann :

cd ../../

jetzt wird die Datei libcrypto, die beim strippen immer kaputt geht wieder erneuert mit:

cp ../cdkroot/lib/libcrypto.so.0.9.7 root/lib/libcrypto.so.0

nun müssen wir noch einen Symlink setzen. Dazu muss der komplette Pfad angegeben werden. Da sich mein dbox2 Verzeichnis mit allen Unterverzeichnissen in /root befindet, sieht mein Befehl also so aus:

/root/dbox2/cdk/bin/powerpc-tuxbox-linux-gnu-strip -s /root/dbox2/cdkflash/root/lib/libcrypto.so.0

Wenn der Pfad falsch war kommt eine Fehlermeldung die in etwa so aussieht:

bash: /dbox2/cdk/bin/powerpc-tuxbox-linux-gnu-strip: No such file or directory

Wenn es richtig war, dann kommt keine Fehlermeldung und auf der Konsole erscheint die ganz normale Ausgabe:

acky:~/dbox2/cdkflash #

Jetzt werden noch die ucodes kopiert und zwar nach /cdkflash/root/var/tuxbox/ucodes

Ebenfalls müssen noch die logo-fb und die logo-lcd nach /cdkflash/root/boot kopiert werden.

HIER GEHTS MIT DEM HEAD BRANCH WEITER!!! (12)

11. Image aus dem Release Branch erstellen:

Wir kopieren nun die Datei "vmlinuz" aus dem Dateipaket in das Verzeichnis /cdkflash/root

Voraussetzung ist (wie am Anfang des HowTos beschrieben), dass entweder die Datei mkfs.jffs2 oder mkjffs2 in /bin vorhanden ist. Jetzt kann man das ja noch nachholen falls es versäumt wurde!!

Benutzen wir mkfs.jffs2 dann wird jetzt folgender

Wir gehen in das Verzeichnis:

acky:~/dbox2#

Befehl eingegeben:

mkfs.jffs2 â€“b â€“e 131072 --pad=8126464 â€“r cdkflash/root/ -o cdkflash/root-jffs2.tmp

Wenn man die Datei mkjffs2 benutzt, dann ist der Befehl der gleiche nur halt mit

mkjffs2 â€“b â€“e 131072 --pad=8126464 â€“r cdkflash/root/ -o cdkflash/root-jffs2.tmp

Dabei wird ein jffs2 only Image aus den Dateien im /cdkflash/root Verzeichnis erstellt. Das bedeutet auch, dass Ihr vorher im cdkflash/root Verzeichnis Eure eigenen Änderungen machen könnt, die dann ins Image übernommen werden. Z.B Senderlisten, lcdmenu, etc.

HIER GEHTS MIT DEM RELEASE BRANCH WEITER !!!(13)

12. Erstellen des flashbaren Images aus dem HEAD Branch:

wir gehen jetzt in das Verzeichnis /dbox2/cdkflash. Hierein kopieren wir aus dem Dateianhang die Datei boot15.img . Jetzt liegt in diesem Verzeichnis also eine Datei und das /root Verzeichnis.

Auf der Konsole steht also der letzte Eintrag s.o.

/dbox2/cdkflash #

Nun geben wir folgendes ein:

mkfs.jffs2 -b -f -e 0x20000 --pad=0x7c0000 -r root -o datei.img

Nun sollte eine Datei entstanden sein, die 7,8 MB groß ist und den Namen datei.img hat.

Ich empfehle bis zum folgenden Befehl ein kurzen Augenblick zu warten, und eventuell die Größe kurz zu überprüfen, bis man den nächsten Befehl eingibt. Jetzt kommt der Befehl, der das Image erstellt. Wir geben also:

cat boot15.img datei.img > Neutrino.img

ein. Nun sollte auch eine Datei Neutrino.img entstanden sein, die 7,9 MB groß ist.

Diese kann jetzt nach Windows kopiert werden und mit dem Bootmanager gestartet werden.

13. Zusammenfügen der Dateien für Release Branch:

Hierfür gehen wir wieder ins Verzeichnis:

acky:~/dbox2/cdkflash#

In den ersten 128kb eines Images ist immer der ppcboot aufgehoben, deshalb geben wir zuerst:

cat jffs2-ppcboot-flfs.img > only-jffs2.img

ein und erst danach:

cat root-jffs2.tmp >> only-jffs2.img

Das wars!!! Jetzt sollte das only-jffs2.img in Eurem cdkflash Verzeichnis liegen. Nun braucht Ihr es lediglich mit dem Bootmanager oder unter Neutrino/Enigma mit der Expertenfunktion zu flashen!!!

c) Zusatz HEAD 09.03. Netzwerkeinstellungen:

Das Image aus dem HEAD-Branch vom 09.03. muss ich immer zweimal starten, da beim ersten Mal keine Fernbedienung funktioniert. Beim 2. Start sollte man zunächst mit telnet auf die Box gehen und das Verzeichnis root auf der D-Box anlegen. Das geht so:

Unter Windows unten links den START-Button drücken > telnet eingeben. Jetzt öffnet sich auch eine Konsole. Nun den Befehl open eingeben und danach die IP der D-Box (bei mir also: 192.168.6.90) und mit <ENTER> bestätigen. Danach den Benutzer root eingeben. Jetzt ist man schon auf der Box. Jetzt nur noch mkdir root eingeben und man hat das Verzeichnis erstellt. Jetzt kann man per FTP auf die Box zugreifen â€“ gelangt dabei aber immer zuerst in das leere /root Verzeichnis. Für die Anmeldung bei diesem HEAD ist kein Passwort mehr nötig!!! Um die Expertenfunktion zu aktivieren, um später mal das Image auszulesen und auf Festplatte zu speichern, muss man (am besten in Linux) auf die Box zugreifen > per FTP die Datei strat_neutrino aus /etc./init.d/ rauskopieren und dann hinter den Eintrag â€žneutrinoâ€œ die Anhänge â€ž-flashâ€œ und â€ž-suâ€œ hängen, so dass der neutrino Eintrag dann so aussieht:

neutrino â€“flash â€“su

somit sollte die Expertenfunktion im Image vorhanden sein!

Um das Image dann aus dem /tmp Ordner herauskopieren zu können muss allerdings noch eine kleine Änderung in einer Datei vorgenommen werden. Wir gehen wieder unter Linux auf die D-Box mit einem FTP-Programm und editieren die Datei /etc/int.d > fstab

Von:

proc /proc proc defaults 0 0
tmpfs /tmp tmpfs defaults 0 0

nach:

proc /proc proc defaults 0 0
ramfs /tmp ramfs defaults 0 0

Nun sollten wir aus dem /tmp Verzeichnis.kopieren können â€“natürlich nach einem D-Box Neustart.

Danke an:

Diese Beschreibung basiert auf dem Thread â€žBei Null anfangen und dann irgendwann ein eigenes Imageâ€œ der am 27.02.03 von ganz_alleine gestartet wurde. Allen Beteiligte dieses Threads möchte ich hiermit noch mal danken.

Danke an:

Alpha, Body, dkey, de Buhr, Limette, Lucgas, Stiffmeister

für den schnellen und freundlichen Support, ohne den ich mit meinen persönlichen Image- und Verständnisproblemen wohl nie soweit gekommen wäre!!

Besonderer Dank gilt:

Merandos

für den Großteil des HowTos, dass ich lediglich übernommen habe und die vielen Korrekturen und Verbesserungsvorschläge!!!!!

Besten Dank!
Der komplette Teil des HowTos über den Release Branch ist von Handyhunter mit freundlicher Unterstüzung von dkey!!! An Euch auch noch einen riesen Dank!!!

MfG

Doktorknow

Todo:

Yadd unter Linux starten

bitte ergänzen und Verbesserungsvorschläge machen!!!

na, das werd ich gleich mal probieren

danke

Beitrag von **rasc** » Mittwoch 30. Juli 2003, 18:38

habjetztLinux hat geschrieben:du sagst also, hier im forum steht immer häppchenweise wie man ein image erstellt...
na wenn du meinst...
ich lese hier viel öfter, das nicht preisgegeben wird, wie man ein richtiges image erstellen kann, [...]

Die Lesart für deinen Satz muesste richtig heissen:

Eine Person (nennen wie ihn mal "Troll"), der fast woechentlich die Nicks wechselt - mal zum Eigensupport seiner Meinung auch mal mit 2 Nicks in einem Thread praesent ist - und gewisse Floskeln staendig wiederholt...

Beitrag von **Frockert** » Mittwoch 30. Juli 2003, 19:33

Z80 hat geschrieben:da hier son bohei gemacht wird, poste ich mal ein howto aus einem anderen board.
kann den direkten link allerdings nicht posten, da illegal. der inhalt sollte es aber nicht sein.
----

Nun sollte eine Datei entstanden sein, die 7,8 MB groß ist und den Namen datei.img hat.

Ich empfehle bis zum folgenden Befehl ein kurzen Augenblick zu warten, und eventuell die Größe kurz zu überprüfen, bis man den nächsten Befehl eingibt. Jetzt kommt der Befehl, der das Image erstellt. Wir geben also:

cat boot15.img datei.img > Neutrino.img

ein. Nun sollte auch eine Datei Neutrino.img entstanden sein, die 7,9 MB groß ist.

Diese kann jetzt nach Windows kopiert werden und mit dem Bootmanager gestartet werden.

Tja, nun habe ich das auch mal "getestet".
Denn Haupteil hatte ich schon vorliegen, es ging nur noch ums Image erstellen.
Meine erstellte 11 MB Datei ist wahrscheinlich etwas groß zum flashen.

Naja, und bei den vielen Fehlermöglichkeiten werde ich mich hüten mein eigenes, erstelltes Image zu flashen.
Sogar wenn die Größe passt.

Nachtrag:
Bisher hatte ich einfach nur Respekt vor den Machern/Entwicklern.
Jetzt falle ich auf die Knie und bewundere sie, das sie sowas erarbeiten und umsetzen können.

Gruß Frockert

Beitrag von **zexma** » Mittwoch 30. Juli 2003, 19:46

Frockert hat geschrieben:[Meine erstellte 11 MB Datei ist wahrscheinlich etwas groß zum flashen.

Schon mal hier reingeschaut?

http://tuxbox.berlios.de/forum/viewtopic.php?t=23363

Homar hat geschrieben:Try to unset DEBUG to clean binarys from debug-output or change to gcc-2.95.
The latest Version of gcc makes 10 to 15 percent bigger binaries.

So, nun hab ich in den letzten Stunden mal das HOWTO von Z80 getestet.
Ergebnis: Meine dbox sagt mir: "no system"

Also zurück zum Sammeln von Infos. Ausgehend von der README-flash.de:

> cvs -d:pserver:anonymous@cvs.tuxbox-cvs.sourceforge.net:/cvs/tuxbox login
> cvs -d:pserver:anonymous@cvs.tuxbox-cvs.sourceforge.net:/cvs/tuxbox -z3 co -P .
> cd cdk
> ./autogen.sh
> ./configure --prefix=/dbox2 --with-cvsdir=$HOME/tuxbox-cvs --enable-maintainer-mode --with-targetruleset=flash
> make all
> make flash-neutrino-all

ucodes nach cdkflash/root/var/ucodes
boot-logos nach cdkflash/root/boot

Ab hier hapert es gewaltig. Wenn mir da einer helfen könnte ?

was muss ich jetzt tun ?

make cramfsimage

und welchen image teil muss ich mir vorher von der box runterladen

und auf welchem weg lade ich diese dann hoffentlich von mir geschaffene image wieder auf die box

plz help

thx

habjetzlinux

Beitrag von **Homar** » Donnerstag 31. Juli 2003, 00:44

nimm dir einen mixed-image (alexW)
mounte nfs

telnet <dboxip>
login: root

cat /dev/mtd/1 > /tmp/cramfs-flfs.img
mv /tmp/cramfs-flfs.img /nfs/.

OK, die Datei habe ich jetzt.

Was nun ?
Soll ich diese Datei ins cdkflash Verzeichnis kopieren ?
Und dann "make cramfsimage" ?

Beitrag von **dietmarw** » Donnerstag 31. Juli 2003, 11:51

habjetztLinux hat geschrieben:..Und dann "make cramfsimage" ?...

also ich habe aus den anderen Beträgen eher "make flash-cramfsimage" rausgelesen.
damit ein image erstellt, geflash..
aber er bootet dann leider nicht korrekt, Fehlerbeschreibung auch hier im Board..
http://www.tuxbox-cvs.sourceforge.net/f ... hp?t=23447

ich komme leider immer noch nicht weiter

ist die datei "cramfs-flfs.img" die einzige, die ich benötige, oder benötige ich noch mehr

und welches make muss ich dann machen, um ein image zu erstellen ?

Beitrag von **MHC** » Freitag 1. August 2003, 01:58

habjetztLinux hat geschrieben:...
und welches make muss ich dann machen, um ein image zu erstellen ?

manchma versteh ich die Fragerei nicht ... mhh

Tipp: schau ins Makefile ...

folgende Make flash-rules gibt es zb.

rel 1_0_0

Code: Alles auswählen

rebuild-flash
flash-ftpd
flash-telnetd
flash-ssh
flash-sshd
flash-dvb-tools
flash-neutrino
flash-enigma
flash-lcars
flash-plugins
flash-lcdmenu
flash-lib
flash-compress
flash-compress-complete-jffs2

oder
HEAD

Code: Alles auswählen

flash-all
flash-ssl
flash-enigma-all
flash-neutrino-all
flash-lcars-all
rebuild-flash
flash-ftpd
flash-telnetd
flash-ssh
flash-sshd
flash-dvb-tools
flash-neutrino
flash-enigma
flash-lcars
flash-plugins
flash-lcdmenu
flash-lib
flash-cramfs
flash-var-jffs2
flash-root-jffs2
flash-cramfsimage
flash-jffs2image

ich persönlich nehme diese rules eher als Anhaltspunkte

bzw. nach 'rebuild-flash' berarbeite ich es per Hand so, bis es passt ...
also auch lauffähig und nicht zu gross ist usw. usw.

welche make geschichten es gibt weiß ich auch, nur weiß ich leider nicht den unterschied zwischen

flash-cramfs
flash-var-jffs2
flash-root-jffs2
flash-cramfsimage
und
flash-jffs2image

ich will doch nur ein image, das alle aktuellen informationen aus dem cvs enthält und welches ich am besten mit dem sbox-boot-manager einspielen kann

Beitrag von **MHC** » Samstag 2. August 2003, 01:42

habjetztLinux hat geschrieben:...ich will doch nur ...

eine eierlegende Wollmilchsau ...

ps: nimms nicht persönlich, es kommt nur so rüber

Beitrag von **Onvi** » Samstag 2. August 2003, 08:11

habjetztLinux hat geschrieben:ich will doch nur ein image, das alle aktuellen informationen aus dem cvs enthält und welches ich am besten mit dem sbox-boot-manager einspielen kann

Die meisten Entwicker sind selbst nicht in der Lage ein Image zu erzeugen. Sie halten dieses auch einfach für vollkommen überflüssig.

Zum Programmieren und Probieren kann man ein YADD nehmen - und alles andere halten sie für unwichtig.

Leider sind sie nicht in der Lage deinen Wunsch nach einem selbst hergestellten Image zu verstehen. Daher gibt es auch nur derart wenig Unterstützung in Schriftform und hier im Board.

Das ist hier schon ein merkwürdiger Haufen Menschen...

Übrigens gibt es einen recht aktuellen Snapshot von AlexW - falls dir seine Images zusagen sollten: http://dboxupdate.berlios.de/snapshot/

______________

Was ist ein Forums-Hampel?
Jemand im Forum, der entgegen aller Unfähigkeit der Verantwortlichen, die Hoffnung und die Bemühungen auf Besserung nie aufgibt.

Beitrag von **Frockert** » Samstag 2. August 2003, 08:44

Onvi hat geschrieben:
habjetztLinux hat geschrieben:ich will doch nur ein image, das alle aktuellen informationen aus dem cvs enthält und welches ich am besten mit dem sbox-boot-manager einspielen kann
Die meisten Entwicker sind selbst nicht in der Lage ein Image zu erzeugen. Sie halten dieses auch einfach für vollkommen überflüssig.

Zum Programmieren und Probieren kann man ein YADD nehmen - und alles andere halten sie für unwichtig.

Leider sind sie nicht in der Lage deinen Wunsch nach einem selbst hergestellten Image zu verstehen. Daher gibt es auch nur derart wenig Unterstützung in Schriftform und hier im Board.

Das ist hier schon ein merkwürdiger Haufen Menschen...

Übrigens gibt es einen recht aktuellen Snapshot von AlexW - falls dir seine Images zusagen sollten: http://dboxupdate.berlios.de/snapshot/

______________

Was ist ein Forums-Hampel?
Jemand im Forum, der entgegen aller Unfähigkeit der Verantwortlichen, die Hoffnung und die Bemühungen auf Besserung nie aufgibt.

Sind deine eltern geschwister?

wenn das doch alles so einfach ist, dann mach du doch die images für die suchenden.
und wenn dir die Philosophie oder die software/images der freizeitentwickler nicht passt, dann erfreu dich doch an der super entwickelten originalsoftware und laß die anders denkenden mit deinem naiven getue in ruhe.

ich bin kein entwickler und kein forum-administrator, sondern begeisterter anwender des projekts.
Bei geistig beminderten aussagen wie die von Onvi immer sind, geht mir die galle hoch.

Gruß Frockert

Warum eierlegende Wollmilchsau ?

Das klingt als ob es unmöglich wäre !

Ich möchte einfach selbst ein Image für meine Box erzeugen, wenn ein Bug gefixt wurde ohne unbestimmte Zeit warten zu müssen bis wieder ein alexW Image verfügbar ist.

Jüngstes Beispiel: Movieplayer

Und nein, ich möchte kein yadd verwenden. Ich wohne schließlich nicht allein und meine Frau will fernsehen und nicht Informatik studieren.

Beitrag von **Onvi** » Samstag 2. August 2003, 11:54

habjetztLinux hat geschrieben:Das klingt als ob es unmöglich wäre !

Unmöglich ist das nicht. Allerdings ist das Interesse der Entwickler an der Imageerstellung so gering, dass sie sich einfach nicht bemühen.

Außerdem werden immer wieder Änderungen von Leuten ins CVS eingecheckt ohne anschließend zu prüfen ob das CVS noch compiliert.

Wenn die Entwickler schon nicht sauber arbeiten und dann noch viele Leute mit rumwurschteln, die nur sehr unsauber arbeiten wird das halt nix.

Beitrag von **rasc** » Samstag 2. August 2003, 12:21

Wer hat denn gesagt dass das HEAD-cvs immer compilieren muss?
Schliesslich ist es zur Entwicklung da.

Klar ist es nicht schoen, wenn es nicht durchcompiliert - aber so ist das nun mal mit Entwicklungs-Zweigen im CVS - insbesondere, wenn auch noch mit verschiedenen Tools und Versionen gearbeitet wird.

Sprich beim Einchecker geht es, aber anderen halt nicht...

Beitrag von **Onvi** » Samstag 2. August 2003, 13:32

rasc hat geschrieben:Sprich beim Einchecker geht es, aber anderen halt nicht...

Wenn jeder, der eincheck anschließend auschecken würde, nochmal compilieren würde - dann wüßte er, dass ein Problem exisiert und sollte das Problem beseitigen.

Klar wird nicht in jeder Minute das auschecken und durchcompilieren möglich sein. Aber das ist noch kein Grund, dass es so selten funktioniert.

Es ist eben die Frage, wo sauber und korrekt man arbeitet. Aber da dieses hier fast gar nicht interessiert ist das halt so.