ds-0.2.9_26-14.2

[kriegaex]

I think it would not be so hard to create a clean DS-Mod integration, but before I start working for two or so days on it, I want to know who else needs it. Thus, I started a poll (German: Umfrage) named Bedarfs-Check: IPv6. Let's wait if there is going to be more feedback than on sd-tux's old posting.

 

[jhaprins]

I think it would not be so hard to create a clean DS-Mod integration, but before I start working for two or so days on it, I want to know who else needs it. Thus, I started a poll (German: Umfrage) named Bedarfs-Check: IPv6. Let's wait if there is going to be more feedback than on sd-tux's old posting.

Then I better start praying right now.
If you need any help, for example, what is needed etc, let me know. I can make some lists for you if you need.

Greetings,
Jan Hugo

 

[kriegaex]

Feel free to put it into the other thread, Jan.

 

[hermann72pb]

make clean bricht ab

Ich hatte bei einer 7170 zuviele Pakete ausgewählt, so dass Image zu gross geworden ist. Nun wollte ich unter friboli

make clean

ausführen und bekam folgende Fehlermeldung

.......
make[1]: Leaving directory `/home/bofh/7170/ds-0.2.9_26-14.2/source/iptables-1.3.6'
export PATH=/home/bofh/7170/ds-0.2.9_26-14.2/toolchain/kernel/bin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games; \
-make -C source/ref-8mb_26-04.29/kernel/kernel_8mb_26_build \
	CROSS_COMPILE="mipsel-unknown-linux-gnu-" \
	KERNEL_MAKE_PATH="/home/bofh/7170/ds-0.2.9_26-14.2/toolchain/kernel/bin:/usr/local/bin:/usr/bin:/bin:/usr/bin/X11:/usr/games" \
	BOARD_REF="8mb_26" \
	clean
/bin/sh: line 1: -make: command not found 
make: *** [kernel-clean] Fehler 127

Was kann man dagegen tun? bzw. wie "bereinige" ich die Verzeichnisse um nochmal "make menuconfig" ausführen zu können.

MfG

Hermann

 

[magenbrot]

Hi Alexander,

make-version ist 3.81.
Ich habs eben nochmal versucht zu reproduzieren. Wieder ganz frisch angefangen:

tar xvfj ds-0.2.9_26-14.2.tar.bz2
cd ds-0.2.9_26-14.2
make menuconfig
make busybox-menuconfig
make precompiled
make

make bricht wieder ab mit:

...
make[3]: Leaving directory `/home/magenbrot/FritzBox-7170/ds-0.2.9_26-14.2/source/tar-1.15.1'
make[2]: Leaving directory `/home/magenbrot/FritzBox-7170/ds-0.2.9_26-14.2/source/tar-1.15.1'
make[1]: Leaving directory `/home/magenbrot/FritzBox-7170/ds-0.2.9_26-14.2/source/tar-1.15.1'
touch -c source/tar-1.15.1/src/tar
cp source/tar-1.15.1/src/tar tools/tar
strip tools/tar
wget -P dl http://xdelta.googlecode.com/files/xdelta30q.tar.gz
--12:38:58--  http://xdelta.googlecode.com/files/xdelta30q.tar.gz
Auflösen des Rechnernamens »xdelta.googlecode.com«.... 66.102.1.82
Verbindungsaufbau mit xdelta.googlecode.com[66.102.1.82]:80... verbunden.
HTTP-Anfrage gesendet, warte auf Antwort... 200 OK
Länge: 180962 (177K) [application/x-gzip]
Speichere nach: »xdelta30q.tar.gz«

100%[===================================================================================================================>] 180.962     22,0K/s   in 7,3s

12:39:06 (24,3 KB/s) - »xdelta30q.tar.gz« gespeichert [180962/180962]

tar -C source  -xzf dl/xdelta30q.tar.gz
tar: dl/xdelta30q.tar.gz: Kann open nicht ausführen.: Datei oder Verzeichnis nicht gefunden
tar: Nicht behebbarer Fehler: Programmabbruch.
tar: Child returned status 2
tar: Fehler beim Beenden, verursacht durch vorhergehende Fehler.
make: *** [source/xdelta30q/.unpacked] Fehler 2

danach sehe ich folgendes im ds-mod verzeichnis:

[magenbrot@brot ds-0.2.9_26-14.2]$ ll
insgesamt 336
drwxr-xr-x  2 magenbrot magenbrot   4096  5. Apr 18:27 addon
drwxrwxr-x  2 magenbrot magenbrot   4096 10. Apr 12:37 build
drwxr-xr-x  2 magenbrot magenbrot   4096 10. Apr 12:24 busybox
-rw-r--r--  1 magenbrot magenbrot   7656  5. Apr 15:49 CHANGELOG
-rw-r--r--  1 magenbrot magenbrot  19340 26. Mär 04:00 Config.in
drwxrwxr-x  2 magenbrot magenbrot   4096 10. Apr 12:38 dl
drwxr-xr-x  4 magenbrot magenbrot   4096  5. Apr 18:27 favicon
-rwxr-xr-x  1 magenbrot magenbrot  36163  5. Apr 12:32 fwmod
-rwxr-xr-x  1 magenbrot magenbrot    360  6. Feb 16:26 fwmod_custom
-rwxr-xr-x  1 magenbrot magenbrot   1663  6. Feb 16:26 fwmod_download
-rwxr-xr-x  1 magenbrot magenbrot   1294  6. Feb 16:26 fwmod_list
drwxr-xr-x  4 magenbrot magenbrot   4096  5. Apr 18:27 howtos
drwxr-xr-x  4 magenbrot magenbrot   4096 10. Apr 12:29 kernel
drwxr-xr-x 49 magenbrot magenbrot   4096  5. Apr 18:28 make
-rw-r--r--  1 magenbrot magenbrot  11967 26. Mär 04:00 Makefile
-rwxr-xr-x  1 magenbrot magenbrot    113 13. Mär 16:09 multijob.sh
drwxrwxr-x 10 magenbrot magenbrot   4096 10. Apr 12:37 packages
drwxr-xr-x 15 magenbrot magenbrot   4096  5. Apr 18:27 patches
-rw-r--r--  1 magenbrot magenbrot   1348 26. Mär 04:00 README
drwxr-xr-x  6 magenbrot magenbrot   4096  5. Apr 18:27 root
drwxrwxr-x 25 magenbrot magenbrot   4096 10. Apr 12:39 source
drwxr-xr-x  4 magenbrot magenbrot   4096 10. Apr 12:17 toolchain
drwxr-xr-x  7 magenbrot magenbrot   4096 10. Apr 12:38 tools
-rw-rw-r--  1 magenbrot magenbrot 180962 10. Apr 12:39 xdelta30q.tar.gz

aus irgendeinem Grund scheint mein wget den -P Parameter zu ignorieren, keine ahnung wieso. Ist ja scheinbar nur bei mir so *kratz* Sobald ich xdelta30q.tar.gz ins dl-Verzeichnis verschiebe läuft das make auch normal durch.
Das ist so bei Fedora Core 6, ich habs noch auf einem Fedora Core 4 getestet, dort funktionierts wie's soll. wget-Versionen sind gleich. Ich denk der Bug liegt bei Fedora, da muss keine Zeit mehr investiert werden.

Gruß
magenbrot

 

[bodobahn]

Hallo Hermann,


1. Dein Problem verschwindet, wenn Du in der Datei
(ds)/make/linux/kernel.mk
in der Zeile 136 -$(MAKE) ersetzt durch $(MAKE), also das - davor entfernst. make clean läuft dann sauber durch.

2. Wirklich Freude wirst Du an dem Ergebnis nicht haben, denn Dein Ziel wirst Du nicht erreichen. Um die Einstellungen für make menuconfig in Grundstellung zu bringen ist mal ein cp ... durch das Forum gerauscht, das ich im Moment nicht suchen mag. Ebenso kannst Du das Verzeichnis dl aus dem ds-Ordner moven, den ds-Ordner löschen, den ds-tar-ball neu entpacken und den dl-Ordner wieder in den ds-Ordner moven.


Viel Erfolg!

Gruß
Kai

PS: Habe gerade ds-0.2.9_26-14.2 als für mich ersten Versuch überhaupt auf einer 7170 in Betrieb genommen. Die "normalen" Funktionen sowie telnet und ssh laufen. Compiliert habe ich das ganze auf einem frischen mit depootstrap aufgesetzten Debian. Hier und da fehlte erst was, aber jetzt läuft's. Ein Fallstrick war für mich das Fritzbox-Passwort, das gesetzt werden muss, bevor das erste mal telnet geht..

Dank an alle, die diese tolle Sache möglich gemacht haben!

 

[fant]

@bodobahn:

Sers und willkommen im Forum... ;-)

Nutzt Du auch die Firewall-Funktion des dsmod? Wenn ja, klappt das bei Dir?

Hawedieehre.
Fant

 

[bodobahn]

@fant

Hi,

Danke für die nette Begrüßung.

sorry, nein. Meine Nutzung ist sehr "klein". ssh mit authorized_key (läuft), ftp, smb und http sind meine Ziele. Kleine Extra-Features des mods nehme ich gerne mit. In einer firewall sehe ich bei Nutzung von zugewiesenen IP-Adressen und NAT/Masquerading keinen Sinn. Die Rechner hinter dem Router sind vom Internet aus sowieso nicht erreichbar (es sei denn, man forwardet). Von der WLan-Seite her verlasse ich mich auf WPA2. Die Box selbst ist auch sehr sicher, weil per default alles nur nach "innen" angeboten wird.


Gruß
Kai

 

[kriegaex]

@hermann72pb: Was bodobahn Dir geraten hat, ist korrekt. War kaum am PC heute, habe es erst jetzt gelesen. Da hat jemand was Falsches eingecheckt, ich habe es notiert und werde es sofort korrigieren.

@magenbrot: Die wget-Version wäre dann doch interessant und evtl. die Info, gegen welche Libs in Fedora Core 6 es kompiliert ist. Wenn demnächst wieder jemand den Fehler meldet, will ich gerüstet sein und es ihm sagen können. Außerdem kann man ja mal suchen, ob der Fehler bekannt ist bzw. ob es einen Patch, Bugfix, Update etc. für Fedora Core 6 gibt.

@bodobahn: Danke erst mal für Deinen gelungenen Einstieg hier. Wie lange braucht denn das debootstrap, um eine funktionierende Toolchain zu bauen? Und wie lange dann das Bauen des Mod auf der Box? Evtl. wäre ein Spezial-Thread dazu mal ganz nett. Edit: Den Thread zu debootstrap gibt es ja schon...

 

[gsieben]

Hallo Leute,
geht alles super auf meinem Firtz!Fon 7150. Nur geht mein OpenVPN auf dem TCP Protokoll nicht. Mit UDP flunst es einwandfrei. Brauche TCP da ich den Port 22TCP des SSH nutze um durch die Firewall meiner Firma zu kommen. Hab den Modus „Brücke“ gewählt.

Hier meine configs. Vielleicht fällt jemanden was auf.

Gruß
Gabriel



Server:

# OpenVPN 2.1 Config
proto udp
port 22
dev tap
ca /tmp/flash/ca.crt
cert /tmp/flash/box.crt
key /tmp/flash/box.key
mode server
tls-server
dh /tmp/flash/dh.pem
tls-auth /tmp/flash/static.key 0
ifconfig-pool 10.7.7.1 10.7.7.250
ifconfig 10.7.7.254 255.255.255.0
push "route-gateway 10.7.7.254"
push "route 10.7.7.0 255.255.255.0"
max-clients 5
tun-mtu 1500
mssfix

daemon
verb 3

cipher AES-256-CBC
route 10.7.7.0 255.255.255.0
comp-lzo
keepalive 10 120

Client:

client
dev tap
dev-node OpenVPN
;proto tcp
proto udp
remote fritz.box 22
resolv-retry infinite
nobind
persist-key
persist-tun
ca ca.crt
cert d820n001.crt
key d820n001.key
ns-cert-type server
tls-auth ta.key 1
cipher AES-256-CBC
comp-lzo
verb 3

 

[kriegaex]

Danke für die Meldung zur 7150, habe ich im Posting #1 gleich in der Liste unterstützer Boxen entsprechend vermerkt. Falls Du denkst, das OpenVPN-Problem ist DS-Mod_26-14.x-bezogen, bist Du hier auch im richtigen Thread (z.B. ging früher wie beschrieben), ansonsten bitte ich Dich ggf., einen neuen zu eröffnen bzw. vorher einen passenden zu suchen.

 

[gsieben]

Hallo Alexander,
war hier sehr unschlüssig. Vor dem Mod ging es auf TCP wunderbar. Versuch mich jetzt erst mal woanders. Vielen Dank für Deine Arbeit und den schönen DS-Mod_26-14.
Gruß
Gabriel

 

[Darkyputz]

hallo ihr guten bastler...

ich habe ja schon die eine oder andere erfahrung mit dem modden, aber mal ganz dooof gefragt...was bringen mit dir toolchain dateine??
wo müssten die hin um mir das procompilen zu ersparen?
oder sind die für was anderes?
hab sie erstmal in den dl ordner kopiert, aber schneller wirkt das compilen trotz dem nciht...oder versteh ich da wieder was nicht??(ganz böser windoofer bin)

danke für eure antworten

 

[kriegaex]

Die beiden Toolchains sind die Werkzeuge, die Du brauchst, um selbst einen Kernel bzw. User-Mode-Pakete bauen zu können, in unserem Fall - debootstrap mal ausgenommen - via Cross-Compiling. Das Bauen der Toolchains selbst (auch sie müssen aus Quellcode auf Deinem Linux übersetzt werden) dauert mit am längsten beim ganzen Build-Prozeß, weil die TCs sehr umfangreich sind. Um diesen Teil des Build-Prozesses zu verkürzen, hat Oliver die Download-TCs als Option in Release 14 eingeführt. Ich habe sie nie benutzt, aber sie werden ja, wenn man sie ankreuzt, automatisch heruntergeladen und entpackt. Man hat mehrfach hier berichtet, daß der Build-Prozeß dadurch dramatisch beschleunigt wurde, natürlich nur im Vergleich zu jemandem, der die TCs noch nicht auf seinem System gebaut hat. Wenn precompiled bei Dir vorher schon komplett durchgelaufen war, hast Du auch die TCs schon, und danach gibt es keinen Unterschied mehr. Alles klar?

 

[kriegaex]

Okay, gsieben, nur ganz kurz, um Release-Abhängigkeiten zu erkennen oder auszuschließen: Unter welcher Mod-Version (Patchlevel auch nennen, bitte) ging es denn mit genau dieser Konfiguration bei Dir? Vielleicht sehe ich ja was im Diff, obwohl ich OpenVPN gar nicht kenne.

 

[Darkyputz]

auf gut deutsch...die dinger sind für die füsse???
mit multijob dauert das nämlich mit und ohne diese dinger genau 56 minuten wenn ich alle packages mitkompilieren lasse und es mal keinen fehler gibt
Immerhin wieder was gelernt...hatte ja gehofft das es wie damals bei den ersten ds-mods nicht mehr geprecompiled werden muss ;-)

 

[kriegaex]

Nein, die sind nicht umsonst, wenn Du gerade neu aufsetzen mußt. Dann ist es ein großer Unterschied. Insbesondere kriegst Du keinen Fehler beim Bauen der TCs, weil sie ja fertig sind. Für Einsteiger deutlich praktischer...

Warum Du einen precompiled überhaupt brauchst, liegt in den Download-Paketen begründet: Unter 2.4 gab es die wichtigen Pakete unter dl inklusive Binaries, bei 2.6 nicht. Das könnte man im Grunde genommen änderen, Oliver hat sich irgendwann vor meiner Zeit aber dagegen entschieden, weil es auch viel Arbeit bedeutet, das immer up to date zu halten. Vielleicht ändern wir das ja zukünftig mal wieder, aber in Erwartung des ipkg-Mods von Daniel kann man antizipieren, daß es irgendwann sowieso wieder in die Richtung vorkompilierter Binaries in Paketen gehen wird.

Ach so, bevor jetzt der Ansturm beginnt, damit wir das in Zukunft wieder machen: Ich habe jetzt nicht geprüft, wieviele Fälle es gibt, in denen unterschiedliche Varianten eines Pakets angeboten werden müßten, um unterschiedliche Hardware zu befriedigen bzw. unterschiedliche Paket-Optionen. Das könnte ein Grund für Olivers Entscheidung gewesen sein. Ein anderer ist wohl, daß der Download von Binärpaketen wesentlich länger dauert. Inzwischen haben wir genügend Angebote für Download-Speicherplatz und Bandbreite, also mal sehen.

 

[bodobahn]

Hi,


@kriegaex: Sorry für das Missverständnis, aber ich habe in Sachen ds-mod nichts mit debootstrap gemacht. Ich habe das Debian, das ich für das Übersetzen genutzt habe, per debootstrap aus Knoppix heraus aufgesetzt. Ansonsten habe ich nur den tar-ball von Dir genommen und laufen lassen...
Ich habe von depbootstrap im ds-mod gelesen und noch nicht durchschaut, wie das laufen soll. Wenn ich das mal verstehe, vielleicht mache ich da mal was...


Danke und Gruß
Kai

 

[hermann72pb]

Können die Brandings überhaupt abgewählt werden?

Ich melde mich wieder mit der Entwicklung der "make clean" Frage. Ich hatte ja gestern versucht das Image für 7170 zu bauen. Dabei hatte ich fast alle Pakete angewählt (bis auf obsolete und Testversionen mit binaries). Ergebnis war: Image 5376 Bytes zu groß. (Ich weiß, ich soll nicht so hungrig sein und nur das Notwendige nehmen)
Nun gut, dachte ich 5kB ist nicht die Welt und wollte so vorgehen, wie ich Anfang des Jahres mit 7050 gemacht hatte, um dort rein gerade passend paar Pakete reinzukriegen: Brandings entfernen. Also AVM (das ist das Größte!) und FreeNet abgewählt. Damals mit 7050 war es tatsächlich die Lösung. Wie groß war meine Verwunderung, als Image immer noch gerade diese 5376 Bytes zu groß war, egal ob ich nur Freenet abwähle, oder samt AVM.
Hm, dachte ich "make clean" ist die Lösung. Jemand hatte mir sogar "make distclean" vorgeschlagen. Alles gemacht, immer noch 5376 Byte zu groß.
Heute bin ich dann ganz von vorne angefangen: Alles gelöscht bis auf "dl" (war bei mir sowieso verlinkt). Und von vorne rein mit "menuconfig" nur "1und1" als Branding. Wieder "precomiled", also volles Programm. Und .... Image wieder 5376 Byte zu groß.

Ich sehe hier folgende Möglichkeiten:
1. 5376 ist ein magischer Wert (irgendeine Grenze) und ist einfach falsch berechnet. Meine tatsächliche Überschreitung ist durch zu viele Pakete deutlich größer, so dass abwählen von Brandings alleine nichts bringt.
2. Brandings werden nicht abgewählt. Seit daniels ds-2.9 für Kernel 2.4 und Firmwares xx.xx.25 (wo es noch geht) hat sich irgendwas geändert. Wenn es so ist, wäre es für 7050 fatal, weil gerade dort man durch Abwählen von Brandings einige Pakete noch "reinquetschen" könnte.
3. Brandings sind abhängig geworden und können nicht voneinander getrennt werden.

Ich probiere nun mit weniger Paketen...

MfG

Hermann

 

[kriegaex]

Wieso Brandings weglassen manchmal nicht viel bringt

@Hermann: Magischer Wert? Na ja, wie man es nimmt 5376 = 21 * 256, das ist also ein Vielfaches der Kernel-Blockgröße. Und um den Wert wird Dein Image eben insgesamt zu groß. Übrigens hätten eine genaue Fehlermeldung und ein angehängtes Log mit Verbosity Level 2 vom make auch geholfen zu sehen, was da genau zu groß wird. Wenn Du es ganz genau wissen willst, hängst Du an die erste Zeile von fwmod sogar noch ein -x an, damit du jeden Shell-Befehl protokolliert bekommst.

Davon abgesehen, werden abgewählte Brandings gelöscht, wie Du in build/modified/filesystem sehen kannst. Es fällt u.U. nur nicht bei der Image-Größe ins Gewicht, denn bei einer Dateisystem-Blockgröße von 64 KB und einem komprimierten Dateisystem wie SquashFS merkst Du keinen Unterschied, wenn das Weggelassene LZMA-komprimiert weniger als diese 64 KB ausmacht. Ich habe mal spaßeshalber einen Test für die 29.04.29 gemacht:

$ cd build/original/filesystem/etc/default.Fritz_Box_7170_26
$ tar cvf test.tar avm freenet
(...)
$ lzma e test.tar test.tar.lzma
$ ls -l test*
-rw-r--r-- 1 ubuntu ubuntu 337920 2007-04-11 19:24 test.tar
-rw-r--r-- 1 ubuntu ubuntu  17274 2007-04-11 19:25 test.tar.lzma

Du siehst: Zwar sparst Du ohne die zwei abgewählten Brandings 330 KB Dateigröße ein, aber unter Berücksichtigung der LZMA-Komprimierung sind es gerade mal 16,8 KB, also gerade mal ein Viertel der Blockgröße. Da braucht man sich also nicht zu wundern, daß das in Deinem Fall nichts ausmacht. Die eingesparten Dateien sind größtenteils Textdateien, und die sind sowieso gut komprimierbar. Darüber hinaus komprimiert lzma sowieso nochmal deutlich besser als bzip2, in diesem Beispiel >21% (habe ich auch probiert).

Fazit: Ja, probiere weniger Pakete. Gestrippte Binaries machen gleich viel mehr aus als Textdateien, sie sind nicht oder kaum komprimierbar. ;-)

Edit (12.04.2007, 20:30): Laut olistudent (zurück aus dem Urlaub) erkennt SquashFS außerdem wohl noch identische Dateien und komprimiert daher noch besser als ohnehin schon beschrieben. Edit 2: Als Checksummen-Algorithmus für die Doubletten-Prüfung wird übrigens "BSD sum" verwendet, also das, was auch das UNIX-Tool sum standardmäßig ausgibt. Das ist eine Art 16-Bit-CRC.