tcpdump vorkompiliert?

[hvkls]

Ich habe einen Bug gegen Linux > 2.6.18 gemeldet, bezueglich Problemen von aktuellen Kernels 2.6 und NFS [rw]size bei Kernel 2.4 Clients. Konkret sind mir keine NFS-Verbindungen mit einer [rw]size > 8K gegen die Buffalo Linkstation LS1 bzw. 16K gegen die Linkstation HG moeglich, obwohl 32K angefordert wurden.

Zur Analyse wurde ich gebeten, tcpdump auf der dbox laufen zu lassen. Gibt es hierfuer Vorkompiliertes?

[rhabarber1848]

Nicht das ich wüßte, aber eine eigene Kompilierumgebung
einzurichten, ist nicht schwierig:
http://forum.tuxbox-cvs.sourceforge.net ... 13&t=48503

[Houdini]

http://home.arcor.de/houdini/dbox/tcpdump.gz

[hvkls]

@rhabarber1848

Tolle Anleitung, das Setup dauert hier noch etwas. Aktuelle URL:

http://cdimage.debian.org/debian-cd/5.0 ... etinst.iso

@houdini:

Danke, ich habe zur Zeit noch ein aelteres Drittimage laufen und bekomme

./tcpdump: relocation error: ./tcpdump: symbol getservent, version GLIBC_2.0 not defined in file libc.so.6 with link time reference

[hvkls]

Leider musste ich unter Mac OS X auf den lahmen qemu zureckgreifen, der zudem keine Schnittstelle zur Zwischenablage hat. Heute morgen bietet sich mir (endlich) folgendes Bild:

"make flash-neutrino-squashfs-all" beendet sich bei "cd missing && ./configure --prefix=/home/tuxbox/image/cdk". In der Tat ist "missing" kein Verzeichnis, sondern ein Softlink auf /usr/share/automake-1.10/missing, ein ausfuehrbares Programm.

[rhabarber1848]

"make flash-neutrino-squashfs-all" beendet sich bei "cd missing && ./configure --prefix=/home/tuxbox/image/cdk". In der Tat ist "missing" kein Verzeichnis, sondern ein Softlink auf /usr/share/automake-1.10/missing, ein ausfuehrbares Programm.

Könntest Du einen Screenshot der Fehlermeldung posten,
besonders die Meldungen vor dem Fehler wären interessant.

Den Link zum Netinst-ISO habe ich im HowTo aktualisiert, danke!

[hvkls]

Ich habe zu danken. --

Ein Screenshot ist eine prima Idee.

[rhabarber1848]

Wie sieht Dir

Code: Alles auswählen

grep "hostappsdir =" $HOME/compile/cdk/Makefile

aus?
Dort darf nicht "missing" stehen, sondern "/home/tuxbox/compile/hostapps"

[hvkls]

hostappsdir = missing

Nach der Aenderung geht's jetzt weiter...

[rhabarber1848]

hostappsdir = missing

Nach der Aenderung geht's jetzt weiter...

Der Wert "missing" ist aber nicht in Ordnung und deutet
darauf hin, dass $HOME/compile/cdk/configure nicht
richtig durchgelaufen ist oder Verzeichnisse vom CVS
checkout fehlen, hier besonders $HOME/cvs/hostapps.

[hvkls]

Weit geht es nicht:



~/cvs/hostapps ist 13MB, ~/compile/hostapps 17MB gross.

Uebrigens stehen auch auf missing:

bootdir, driverdir

[rhabarber1848]

Nutzt Du mein VMWare-HowTo zur Einrichtung Deiner qemu-Umgebung?
Gab es bisher Probleme bei der Umsetzung?
Hast Du noch die Resultatübersicht von cdk/configure?
Dort werden die zu nutzenden Verzeichnisse angezeigt.
Irgendwas ist an der Stelle schief gelaufen.

[hvkls]

Bis auf das noch fehlende LAN war alles bisher unproblematisch.

Ich habe ein Image eingerichtet, das .iso gebootet, Debian nach Anleitung installiert und genau nach Anleitung CVS gesynct und dann kompiliert. Das Letzte, was ich bewusst gesehen habe, war das Auspacken von 2.4.37.

Zwar habe ich config.log, aber nach ca. 40 Screenshots habe ich aufgegeben. Vielleicht koenntest du mir die Werte zu bootdir und driverdir sagen, dann versuche ich's nochmal. Ich wuerde sehr ungern ./configure laufen lassen, da die Neukompilierung etwa zwoelf Stunden benoetigen wuerde.

[hvkls]

OK, ein wenig WebDAV hat config.log herbeigezaubert.

[rhabarber1848]

Zwar habe ich config.log

Die Analyse

Code: Alles auswählen

grep dir= config.log | grep -iv "INSTALL\|configure"

sollte so aussehen (Pfade ähnlich):

Code: Alles auswählen

ac_cv_path_mkdir=/bin/mkdir
appsdir='/root/tuxbox/work_glibc/compile/apps'
bindir='${exec_prefix}/bin'
bootdir='/root/tuxbox/work_glibc/compile/boot'
ccachedir='/root/tuxbox/work_glibc/image/cdk/bin'
customizationsdir='/root/tuxbox/customizations'
datadir='${datarootdir}'
datarootdir='${prefix}/share'
docdir='${datarootdir}/doc/${PACKAGE_TARNAME}'
driverdir='/root/tuxbox/work_glibc/compile/driver'
dvidir='${docdir}'
hostappsdir='/root/tuxbox/work_glibc/compile/hostapps'
htmldir='${docdir}'
includedir='${prefix}/include'
infodir='${datarootdir}/info'
libdir='${exec_prefix}/lib'
libexecdir='${exec_prefix}/libexec'
localedir='${datarootdir}/locale'
localstatedir='${prefix}/var'
logosdir='/root/tuxbox/work_glibc/compile/cdk/logos'
mandir='${datarootdir}/man'
oldincludedir='/usr/include'
pdfdir='${docdir}'
psdir='${docdir}'
sbindir='${exec_prefix}/sbin'
sharedstatedir='${prefix}/com'
sysconfdir='${prefix}/etc'
ucodesdir='/root/tuxbox/cdk_stuff/ucode'

[hvkls]

Danke. Und weiter geht's mit uboot...

[hvkls]

Herausgekommen ist nun etwas, jedoch mit einer fetten "bad magic bytes will cause no system"-Warnung?

[rhabarber1848]

Für tcpdump "make tcpdump".

Zu den magic bytes: http://forum.tuxbox-cvs.sourceforge.net ... 96#p321296

[hvkls]

tcpdump ist kompiliert, aber wegen der magic bytes stehe ich irgendwie auf dem Schlauch. Ist der Makefile zu editieren?

[rhabarber1848]

Versuch einfach mal, tcpdump in Deinem jetzigen Image zu nutzen.
Wenn es wegen glibc nicht klappt, kopiere libc.so.6 nach /var/lib
und probier nochmal.

Das bad magic-Problem ist durch das Kopieren weiterer Dateien
ins Image zu lösen, die Boardsuche hilft weiter.

[seife]

Das bad magic-Problem ist durch das Kopieren weiterer Dateien
ins Image zu lösen, die Boardsuche hilft weiter.

Oder durch solange "make flash-semiclean; make flash-neutrino-$FSTYPE-$CHIP" bis es keine bad magics mehr gibt. Wenn ich mehr als 5 "Durchgänge" brauche, mach ich auch mal ein "make flash-clean" zwischendurch.

[hvkls]

Danke, werd's probieren. Meintest du die Variablen 'as-is' oder soll ich da etwas einsetzen? Ziel ist ein Neutrino-2x-Image.

tcpdump und libc6 zusammen haben uebrigens ihren Zweck auf dem alten Image getan, so dass ich die Informationen an die linux-nfs-Liste absenden konnte.

[rhabarber1848]

soll ich da etwas einsetzen?

Es gibt z.B. folgende Targets:

flash-neutrino-squashfs-all
flash-neutrino-squashfs-1x
flash-neutrino-squashfs-2x

flash-neutrino-jffs-all
flash-neutrino-jffs2-1x
flash-neutrino-jffs2-2x

seife meinte mit seinem Posting, dass Du Wahl zwischen verschiedenen
Dateisystemen (jffs oder squashfs) und Chiptypen hast, wobei "-all" jeweils
ein 1x- und ein 2x-Image kompiliert.

[hvkls]

Nach einem "make flash-clean" hat es geklappt! Danke!! Bin gespannt aufs geflashte Image.

[hvkls]

Ok, versuche gerade, das frisch geflashte ~/cdkflash/image/neutrino-squashfs.img2x zu booten. Es haengt nach wenigen Sekunden. Leider ist das Display meiner Nokia so voller Streifen, dass ich nichts erkennen kann, ausser dass womoeglich ein "]" am Ende der einzigen Zeile am unteren Displayrand steht, und im ersten Drittel ggf. ein "i". Hab mal alle Farbtasten und OK gedrueckt, aber ohne Erfolg. (Ein Nullmodemkabel besitze ich nicht.)