7050 zu eng: DS-Mod-Teile manuell auf externe Platte auslagern

dsteinkopf · 31 Mrz 2007

Ich fange hierfür mal ein neues Thema an:
Was bisher geschah ;-) : (s. http://www.ip-phone-forum.de/showpost.php?p=836630&postcount=263 ff.)

dsteinkopf schrieb:
Nachdem bei der 7050 ja fast nichts mit drauf passt, frage ich mich, ob folgendes nicht möglich ist:

Das Image vollständig (zu groß) zu erstellen, dann einige beim Hochfahren nicht benötigte Verzeichnisse nicht ins Image zu stecken sondern auf ein per NFS erreichbares Verzeichnis. Und dann beim Hochfahren per NFS diese Verzeichnisse mit --bind wieder an die richtigen Stellen zu mounten.

Ich habe das derzeit schon so ähnlich mit openvpn am Laufen.

Was meint Ihr?

Welche Verzeichnisse würden sich anbieten? Was wird bis zum Ausführen der debug.cfg nicht benötigt, sodass man es dann erst einhängen kann?

Dirk

kriegaex schrieb:
Code:

cat /etc/init.d/rc.S

Darin siehst Du, daß die debug.cfg erst ganz weit unten, unmittelbar vor rc.mod, aufgerufen wird. D.h., daß die meisten DS-Mod-Spezifika erst relativ spät aufgerufen werden. Weiter:

Code:

cat /etc/init.d/rc.mod

Darin werden explizit crond, telnetd und webcfg gestartet und anschließend alles, was in static.pkg verzeichnet ist, also weitere DS-Mod-Pakete:

Code:

cat /etc/static.pkg

Kleiner Tip noch: Am Ende von rc.mod wird sozusagen die "debug.cfg des DS-Mod", namentlich /tmp/flash/rc.custom (zu bearbeiten mit mvi), abgearbeitet. Wenn Du aus Deiner debug.cfg noch Sachen dorthin verlagerst, deren Aufrufe bis nach der Initialisierung des DS-Mod warten können, erhältst Du evtl. weiteres Optimierungs- bzw. Auslagerungspotential.

Fazit: Ganze Verzeichnisse auszulagern, wird nicht ganz einfach werden, aber Teile davon kriegst Du sicher hin. Wenn Du mal mit einen Verzeichnis-Vergleich auf Deinem Build-System zwischen Original- und Mod-FW machst, erkennst Du schnell Unterschiede:

Code:

diff -rq build/original/filesystem build/modified/filesystem

Das war jetzt alles theoretisch, also viel Spaß beim Ausprobieren. Da wir hier auch ein bißchen off-topic sind, postest Du die Ergebnisse - am besten mit einem Vollzitat unserer beiden Nachrichten als Ausgangspunkt - bitte in einem Extra-Thread.

Edit: Ich weiß ja nicht, was auf die 7050 paßt, aber falls Du mini_fo drauf bekommst, kannst Du evtl. diverse mount-Befehle durch ln oder - bei kleineren Dateien - durch cp ersetzen.

dsteinkopf · 31 Mrz 2007

Da frage ich mich, ob folgender naiver Ansatz wohl funktionieren würde:

Ich lösche aus dem filesystem alle Dateien wieder raus, die gegenüber original dazugekommen sind - bis auf die genannten Startskripten. In debug.cfg (oder ganz oben in rc.mod) sorge ich dann (irgendwie...) dafür, dass alle gelöscht Files wieder da sind. Dann sollte alles perfekt weiter laufen.

Das basiert auf der Annahme, dass vor dem Aufruf des rc.mod nichts Mod-speziefisches passiert, also keine von den hinzugekommenen Dateien benötigt werden. Stimmt das?

Und an welche Stelle im Makefile/fwmod kann ich das Wieder-Löschen am besten machen - erstmal nur als Hack? Oder wie bau ich das Image nachdem ich in build/modified/filesystem die Veränderungen gemacht habe?

Danke,

Dirk

kriegaex · 1 Apr 2007

Hi Dirk! Das wäre einen Versuch wert. Ich habe das nicht im Detail analysiert, daher bin ich mir nicht ganz sicher, welche Mod-Dateien vor dem Aufruf der debug.cfg in rc.S im Einzelnen vorher gebraucht werden, aber darauf, daß keine gebraucht werden, darfst Du Dich nicht verlassen. Mach mal

Code:

diff -ruN build/original/filesystem/etc/init.d/rc.S build/modified/filesystem/etc/init.d/rc.S

Da wirst Du sehen, daß es ein paar Unterschiede gibt bei den Mounts, daß außerdem aus den Modified-Dateien /sbin/makedevs aufgerufen wird und die Mod-Einstellungen mit /usr/bin/modload geladen werden. Die von makedevs evtl. benötigten Libs und die von modload aufgerufenen Befehle sind ebenfalls zu berücksichtigen. Wenn die alles Nötige vorfinden, kannst Du anschließend in der in einem zusätzlichen Skript den Rest nachladen. Ich würde das Skript am Anfang der debug.cfg aufrufen lassen, wenn es existiert (Prüfung einbauen), nicht erst in rc.mod oder gar erst in rc.custom, denn dann würden ggf. andere Befehle in der debug.cfg auch schon davon profitieren und Du bräuchtest an der rc.mod nicht herumzupatchen.

Das "stripped image" würde ich so bauen:

Ganz normal mit make ein Image bauen, damit Du eine Referenz für build/modified hast und später von dort die benötigten Dateien auf Deinen Datenträger kopieren kannst.
build/modified umbenennen, z.B. in build/modified_full
Nochmal make aufrufen, um eine identische Kopie von build/modified zu erhalten. Die paar Sekunden machen nichts aus, und im Gegensatz zu einer rekursiven Kopie weißt Du dann genau, daß alles ist, wie es sein sollte.
Aus der diff-Ausgabe könntest Du Dir unter Berücksichtigung des weiter oben Geschriebenen ein Skript basteln, das alle vorerst nicht benötigten Dateien löscht und ein weiteres, das später auf der Box dafür sorgt, daß alles wieder dorthin kommt, wo es sein soll. Mir einem ordentlichen Texteditor und Suchen/Ersetzen sollte das gut gehen.
Das Lösch-Skript rufst Du auf und kontrollierst, was es getan hat unter build/modified/filesystem.
Das Wiederherstellen-Skript baust Du in das gestrippte build/modified ein (z.B. als /etc/mount_external_files). Deine debug.cfg auf der Box kriegt als erste Zeile den Aufruf dieser Datei verpaßt (vorher mit if prüfen, ob die Datei existiert, damit die Box nicht hängen bleibt, falls dem nicht so ist. Paß auch auf, daß keine Fehler im Zusatz-Skript drin sind und es ausführbar ist, denn sonst hängt evtl. die Box beim Booten und Du mußt sie recovern.

Wenn alles ist, wie Du es haben möchtest, rufst Du fwmod so auf, daß es nichts auspackt oder modifiziert, sondern einfach packt, was es vorfindet:

Code:

~/ds/0.2.9_26$ ./fwmod -p -d build dl/fritz.box_fon_wlan_7170.29.04.29.image
STEP 3: PACK
WARNING: Modifications (STEP 2) and this step should never
         ever be run with different configurations!
         This can result in invalid images!!!
packing var.tar
creating filesystem image
merging kernel image
packing 7170_-.de_20070401.image
done.

Der Dateiname ist dann zwar etwas verkrüppelt und das Image liegt unterhalb von build, weil einige Variablen nicht gesetzt sind, aber es funktioniert. Den Dateinamen des Original-Images unter dl paßt Du entsprechend Deiner FW an.

Danach kannst Du ja mal schauen, ob es geht.

Update und Postskriptum: Ganz löschen darfst Du die Dateien nicht, sie sollten Platzhalter mit Länge null und den richtigen Rechten haben, denn sonst scheitert mount -o bind, das vergaß ich zu erwähnen.

dsteinkopf · 5 Apr 2007

Danke für Deine sehr ausführliche Antwort - bis heute war ich nicht dazu gekommen, sie zu lesen...

Ich habe mich etwas damit beschäftigt, eigentlich ist jetzt alles klar. Trotzdem ist mir das zu heikel, das mit meiner einzigen, produktiven Box zu machen, mit der wir hier auch wirklich telefonieren und surfen wollen...

Daher meine noch weiter reichende Idee: Ich spiele nur noch den ds-mod in minimal-config (nur ssh/dropbear) auf - dabei kann nichts schief gehen - und lade alles aus der debug.cfg nach - aber nur wenn der NFS-Mount klappt und eine bestimmte Startdatei existiert. Damit kriege ich die Box immer wieder zum Booten. Derzeit kriege ich aber noch nichtmal so einen Minimal-Mod gebaut - immer zu groß.

Ich wollte auch weniger die Dateien mit mount --bind ersetzen als die Verzeichnisse wie /bin /lib etc. Also z.B.

mount --bind /var/mod/root/mnt/lib/ /lib/

Dirk

zoolook · 5 Apr 2007

Hi,

dsteinkopf schrieb:
Daher meine noch weiter reichende Idee: Ich spiele nur noch den ds-mod in minimal-config (nur ssh/dropbear) auf - dabei kann nichts schief gehen - und lade alles aus der debug.cfg nach - aber nur wenn der NFS-Mount klappt und eine bestimmte Startdatei existiert. Damit kriege ich die Box immer wieder zum Booten. Derzeit kriege ich aber noch nichtmal so einen Minimal-Mod gebaut - immer zu groß.

Vewrsuchst Du es denn auch mit dem ds-0.2.9_26-14.1 und der 7050.14.04.31 Firmware? Ich kriege die paar minimalen Packages schon 'rein, nur der Kernel ist bei mir zu groß:

Code:

~/_ds-0.2.9_26-14.1 $ make
STEP 1: UNPACK
unpacking firmware image
splitting kernel image
unpacking filesystem image
  created 910 files
  created 69 directories
  created 169 symlinks
  created 128 devices
  created 0 fifos
unpacking var.tar
done.

STEP 2: MODIFY
applying patches
  applying patches (7050-de)
    patching file etc/profile
    patching file usr/bin/system_status
    patching file etc/init.d/rc.net
    patching file etc/init.d/rc.voip
    patching file etc/init.d/rc.S
    Hunk #1 succeeded at 251 with fuzz 1 (offset -98 lines).
    patching file etc/init.d/rc.S
    patching file etc/fstab
    patching file usr/www/all/html/de/fon/foncalls.js
    patching file etc/init.d/rc.S
    Hunk #1 succeeded at 436 (offset 1 line).
    patching file usr/www/all/html/de/menus/menu2_fon.html
    Hunk #1 succeeded at 70 (offset -1 lines).
    patching file usr/www/all/html/de/menus/menu2_homehome.html
    Hunk #1 succeeded at 43 (offset -3 lines).
    patching file usr/www/all/html/de/menus/menu2_homekonfig.html
    Hunk #1 succeeded at 12 (offset -1 lines).
    patching file usr/www/all/html/de/menus/menu2.inc
    Hunk #1 succeeded at 10 (offset -1 lines).
    patching file usr/www/all/html/de/menus/menu2_internet.html
    Hunk #1 succeeded at 87 (offset -1 lines).
    patching file usr/www/all/html/de/menus/menu2_system.html
    Hunk #1 succeeded at 90 (offset -1 lines).
    patching file usr/www/all/html/de/menus/menu2_wlan.html
    Hunk #1 succeeded at 48 (offset -1 lines).
  creating symlink /tmp and /mod
  setting subversion 'ds-0.2.9_26-14'
  applying wol patch
  applying webmenu signed patch
    patching file usr/www/all/html/de/home/home.js
    Hunk #1 succeeded at 60 (offset -2 lines).
  applying enum patch
  removing assistant
  removing help
  removing avm's libcrypto
  patching tr069.cfg
  removing avm's libssl
  removing avm's libtr069.so
  removing avalanche_usb.ko
  removing oem: 1und1
installing mod base
  copying files
  installing libs
    libgcc_s.so.1
    ld-uClibc-0.9.28.so
    libcrypt-0.9.28.so
    libdl-0.9.28.so
    libm-0.9.28.so
    libpthread-0.9.28.so
    libuClibc-0.9.28.so
    libutil-0.9.28.so
    liblzo2.so.2.0.0
    libssl.so.0.9.8
    libcrypto.so.0.9.8
    libz.so.1.2.3
    libmatrixssl.so
  adding favicons (hdeller)
replacing busybox
  replacing busybox-4mb_26
  installing symlinks
installing modules
    exportfs.ko
    lockd.ko
    nfs.ko
    nfsd.ko
    nls_cp437.ko
    nls_iso8859-1.ko
    nls_iso8859-15.ko
    ip_conntrack.ko
    ip_tables.ko
    sunrpc.ko
  generating modules.dep
  copying files
  installing libs
installing packages
  dnsmasq-2.38
  dropbear-0.49
  matrixtunnel-0.2
  stunnel-4.20
  virtualip-cgi-0.4
  wol-cgi-0.5
invoking custom script
done.

STEP 3: PACK
squashfs blocksize
  hidden squashfs: 65536
  root filesystem: 65536
packing var.tar
creating filesystem image
merging kernel image
  kernel image size: 4619264 (max: 3866624)
ERROR: kernel image is 752640 bytes too big
make: *** [firmware] Error 1

Die ganze Idee mit nachladen (oder ich würde es auch mit einem NFS mount probieren, da ich ein NAS habe welches fast immer läuft, würde eigentlich 2 Varianten haben wollen, mal bloß im RAM laden von ftp/http wenn NFS nicht erreichbar ist, denn ich stelle mir vor, das NAS auch irgendwann mal vorübergehend mitzuschleppen, oder direkt von gemountet-em NFS ausführen) hatte ich auch als schon der alte ds-mod schon immer mit den 4MB Flash Probleme hatte, nur kam ich nie dazu. Da ich nun von einem Kumpel, der nun eine 8MB-Box hat seine alte 7050 zum Austausch gegen meine Fon WLAN habe, könnte ich bis alles sicher läuft diese Sache im nicht-produktiven Einsatz auch mit-testen und eventuell mit-debuggen/entwickeln (bloß, unter der Einschränkung meiner Freizeit halt).
Gruß,
Zoolook

dsteinkopf · 5 Apr 2007

Ja, ich nehme die genannten Versionen.
Was genau meinst Du mit "geht rein, nur der Kernel ist zu groß" ? Bei mir ist das schon ähnlich:

Code:

merging kernel image
  kernel image size: 3873792 (max: 3866624)
ERROR: kernel image is 7168 bytes too big
make: *** [firmware] Fehler 1

Zum Laden via NFS: Ich benutze das derzeit vor allem für openVPN: Das Binary liegt auf NFS, ich mounte es und starte es direkt von dort. Klappt auch, wenn der NFS-Server mal nicht geht.

P.S. Ich freue mich natürlich, wenn noch jemand mit NFS experimentiert! ... Und ich habe auch nur sehr wenig (Frei-)Zeit für dieses "Projekt". Ist aber auch nicht dringend.

Dirk

zoolook · 5 Apr 2007

dsteinkopf schrieb:
Ja, ich nehme die genannten Versionen.
Was genau meinst Du mit "geht rein, nur der Kernel ist zu groß" ? Bei mir ist das schon ähnlich:

Code:

merging kernel image kernel image size: 3873792 (max: 3866624) ERROR: kernel image is 7168 bytes too big make: *** [firmware] Fehler 1

Nun, ich denke daß diese Fehlermeldung ganz ordentlich für Verwirrung hier im Forum gesorgt hat. Früher, beim "alten" ds-mod hieß es doch immer firmware image zu groß, wenn zu viele Pakete ausgewählt wurden, und nicht kernel image wie jetzt. Deswegen bin ich selber immer noch verwirrt, was soll denn bitteschön das Abwählen von sämtlichen Paketen helfen, wenn es immer der 2.6-er Kernel ist, der anscheinend ohne meine aktive Zustimmung neu gebaut wurde, was da zu groß geraten ist? Scheint bei Dir genauso.

dsteinkopf schrieb:
P.S. Ich freue mich natürlich, wenn noch jemand mit NFS experimentiert! ... Und ich habe auch nur sehr wenig (Frei-)Zeit für dieses "Projekt". Ist aber auch nicht dringend.

Bei mir auch nicht so dringend, ich würde mich eigentlich freuen, erstmal die 7050 mit dropbear und dnsmasq (so wie ich es auf der derzeitigen Fon WLAN am Laufen habe) hinbekomme, wegen dem internen ISDN-Bus, habe nämlich noch ein ISDN Telefon welches immer noch parallel mit meiner jetztigen Fritzbox am NTBA hängt.

dsteinkopf · 5 Apr 2007

zoolook schrieb:
Nun, ich denke daß diese Fehlermeldung ganz ordentlich für Verwirrung hier im Forum gesorgt hat. Früher, beim "alten" ds-mod hieß es doch immer firmware image zu groß, wenn zu viele Pakete ausgewählt wurden, und nicht kernel image wie jetzt. Deswegen bin ich selber immer noch verwirrt, was soll denn bitteschön das Abwählen von sämtlichen Paketen helfen, wenn es immer der 2.6-er Kernel ist, der anscheinend ohne meine aktive Zustimmung neu gebaut wurde, was da zu groß geraten ist? Scheint bei Dir genauso.

Also ich weißt nicht recht, was ich denken soll. Jedenfalls ändert sich die gemeldete "Übergröße" sehr wohl durch Änderung von Paketauswahlen.

zoolook schrieb:
Bei mir auch nicht so dringend, ich würde mich eigentlich freuen, erstmal die 7050 mit dropbear und dnsmasq.

Ähnlich ist mein Ziel auch, aber ich schätze, dass man dafür um den Aufwand mit dem "Nachladen"/NFS-Mounten nicht herumkommt.

Ups! Also während ich das tippe, baut mein Rechner grad ein Image fertig, das passt:

Code:

creating filesystem image
merging kernel image
  kernel image size: 3787776 (max: 3866624)
packing 7050_04.31-ds-0.2.9_26-14.de_20070405.image
done.

Was ich dazu gemacht habe: Bei dropbear auch noch "Without scp & ssh client" auswählt. Das müsste eigentlich als Minimal-DS-MOD reichen, um meinen Plan (s.o.) auszuführen, oder?

Anbei versuche ich meine .config anzuhängen.

Dirk

kriegaex · 5 Apr 2007

dsteinkopf schrieb:
Ich wollte auch weniger die Dateien mit mount --bind ersetzen als die Verzeichnisse wie /bin /lib etc. Also z.B.

mount --bind /var/mod/root/mnt/lib/ /lib/

Es wird schwierig werden, ganze Verzeichnisse zu mounten, die teilweise AVM-Binaries enthalten, welche beim Booten gebraucht werden. Aber einzelne, v.a. größere Binaries zu ersetzen durch Symbolic Links auf den externen Speicher ist meine aktuelle Idee. Komme nur nicht dazu, etwas zu testen. Demnächst mal...

gnieder · 5 Apr 2007

@dsteinkopf

hier nochmal mein Posting aus dem anderen Thread:

Das Problem wird sich wohl auch nicht mehr in den Griff bekommen lassen.

Ich habe die 7050 jetzt mal soweit, dass die für mich wichtigsten kleinen
mods im Image sind, und der Rest online nachgeladen wird.

Dazu habe ich mir ein paar addons für den online Betrieb umgebaut.
Somit wird nur das Binary übers Web geladen, die Konfigmöglichkeit bleibt
aber trotzdem im WebIF des ds-mod.

Es dauert dann halt 'ne Minute länger, bis die Büxe fertig ist.

Wenn Du Interresse hast, dann schick mir Deine email per PN, dann können
wir weiter reden.

Diese addons sind aber noch nicht ausgiebig getestet, könnte also sein, dass
noch n'paar mal Hand angelegt werden muss.

In meinem 7050 Image befindet sich statisch:

bftpd,dnsmasq,virtualip,syslog,wake-on-lan
(das eine oder andere miniaddon lässt sich evtl. noch zusätzlich einbinden)

Für dropbear,openvpn,mc habe ich die Pakete so abgeändert, dass
nur die Binaries von einem "irgendwoliegenden" Webserver während des
Boxenstarts nachgeladen werden.

D.H. die Konfigfunktionalität bleibt im addon erhalten, und man kann
wie gewohnt die Änderungen übers WebIF (wie im Orginal) durchführen.

An siproxd und nettrafd arbeite ich gerade noch.
( http://siproxd.sourceforge.net und http://nettraf.sourceforge.net )

Das Zeugs ist aber noch nicht übermässig getestet!

Gruß, gnieder

dsteinkopf · 5 Apr 2007

kriegaex schrieb:
Es wird schwierig werden, ganze Verzeichnisse zu mounten, die teilweise AVM-Binaries enthalten, welche beim Booten gebraucht werden.

Warum? Ich hatte nicht vor, diese vor dem Mounten leer zu lassen. Dass das nicht gehen würde, ist klar.

Durch den mount --bind wird ein bestehendes Verzeichnis "überschrieben". Ich habe das schon ausprobiert - allerdings nur mit eigenen Verzeichnissen und noch nicht mit "heiklen" wie /bin.

Dirk

dsteinkopf · 5 Apr 2007

gnieder schrieb:
In meinem 7050 Image befindet sich statisch:

bftpd,dnsmasq,virtualip,syslog,wake-on-lan

Wie hast du das reinbekommen? Bei uns wird es immer _sehr_ schnell zu groß (s.o.).

gnieder schrieb:
Für dropbear,openvpn,mc habe ich die Pakete so abgeändert, dass
nur die Binaries von einem "irgendwoliegenden" Webserver während des
Boxenstarts nachgeladen werden.

D.H. die Konfigfunktionalität bleibt im addon erhalten, und man kann
wie gewohnt die Änderungen übers WebIF (wie im Orginal) durchführen.

Kannst Du uns da mal entsprechende Skript-Ausschnitte schicken, anhand derer man das selber nachbauen kann? Wie machst Du das mit dem Nachladen? Ins Filesystem schreiben - dort wo sie "fehlen", geht ja nicht, oder?

Im Prinzip war meine Idee ja ähnlich - nur nicht mit einem Web-Server sondern per NFS. Daher ist die gemeinsame Frage: Welche Dateien kann man aus dem Image herauslassen, damit es noch so weit bootet, dass man sie wieder nachladen kann.

Dirk

kriegaex · 5 Apr 2007

dsteinkopf schrieb:
Warum? Ich hatte nicht vor, diese vor dem Mounten leer zu lassen. Dass das nicht gehen würde, ist klar.

Durch den mount --bind wird ein bestehendes Verzeichnis "überschrieben". Ich habe das schon ausprobiert - allerdings nur mit eigenen Verzeichnissen und noch nicht mit "heiklen" wie /bin.

Stimmt, daran hatte ich nicht gedacht, weil ich meistens nur Dateien überschreibe mit mount - inzwischen nicht mal mehr das, weil ich mini_fo habe. Platzprobleme habe ich auf meiner 7170 bisher nicht, dadurch mounte ich nichts Externes. Ihr 7050-Sparfüchse seid da fitter. ;-)

gnieder · 5 Apr 2007

dsteinkopf schrieb:
Wie hast du das reinbekommen? Bei uns wird es immer _sehr_ schnell zu groß (s.o.).

nimm mal meine dot.config. Dann kannst Du vergleichen

dsteinkopf schrieb:
Kannst Du uns da mal entsprechende Skript-Ausschnitte schicken, anhand derer man das selber nachbauen kann? Wie machst Du das mit dem Nachladen? Ins Filesystem schreiben - dort wo sie "fehlen", geht ja nicht, oder?

Ich schreibe die Binaries in die Ramdisk z.B. unter /var/mod/usr/...
Man muss nur vorsichtig sein, dass man nicht zuviel reinkopiert, sonst macht
die Box 'ne Krätsche. Bei den 32Mb Boxen ist das aber nicht so kritisch,
schlimmer ist es mit den 16Mb Kisten.

dsteinkopf schrieb:
Im Prinzip war meine Idee ja ähnlich - nur nicht mit einem Web-Server sondern per NFS. Daher ist die gemeinsame Frage: Welche Dateien kann man aus dem Image herauslassen, damit es noch so weit bootet, dass man sie wieder nachladen kann.

Im Prinzip würde das genauso gehen. Nur nicht jeder hat ständig einen
NFS oder CIFS Server im Onlinebetrieb zuhause rumstehen.
Ich lasse eigentlich garnix weg, ausser das was im mod eh' schon zum
Weglassen vorgesehen ist.

Gruß, gnieder

hermann72pb · 5 Apr 2007

dsteinkopf schrieb:
Wie hast du das reinbekommen? Bei uns wird es immer _sehr_ schnell zu groß (s.o.).

@dsteinkopf: brandings abgewählt? Sie machen viel aus.

dsteinkopf schrieb:
Was ich dazu gemacht habe: Bei dropbear auch noch "Without scp & ssh client" auswählt. Das müsste eigentlich als Minimal-DS-MOD reichen, um meinen Plan (s.o.) auszuführen, oder?

Normalerweise macht dieses "without" an der Größe von Image gar nichts aus. Zumindest war es bei mir mit xx.25 firmware so. Ich hatte es damals mit und ohne kompillieren lassen. Mit diesem "without" wirst du dir allerdings ein anderes Problem einfangen, wenn dieses immer noch nicht gefixt ist. Das Problem äußern sich darin, dass du mit WinSCP auf die Box nicht zugreifen kannst. Ich habe darüber schon irgendwo im Forum geschrieben. Aber putty würde immer noch gehen. Wenn es dir reicht, dann ok.

dsteinkopf schrieb:
Kannst Du uns da mal entsprechende Skript-Ausschnitte schicken, anhand derer man das selber nachbauen kann? Wie machst Du das mit dem Nachladen?

@gnieder: Ich schließe mich dsteinkopf ein. Kannst du uns bitte etwas mehr Infos geben. Wie kriegst du es hin, dass die cgi-s für die Pakete auf die Box kommen und die binaries weggelassen werden? Wo machst du das Nachladen? debug.cfg?

dsteinkopf · 5 Apr 2007

hermann72pb schrieb:
@dsteinkopf: brandings abgewählt? Sie machen viel aus.

Ja. Aber danke für die Idee.

hermann72pb schrieb:
Normalerweise macht dieses "without" an der Größe von Image gar nichts aus.

Jein. Ich habe einiges experimentiert und irgendwie verstehe ich das mit der Größe nicht...

Ich habe nun - basierend auf der config von gnieder - ein Image gebaut wie ich es wollte: Mit dropbear (komplett), syslog und dnsmasq. Warum es nun klein genug ist, verstehe ich nicht.

Die dot-config-mini2.txt ist mein erfolgreiches Ergebnis. Die dot-config-mini-bad.txt dagegen ist zu groß. Allerdings nur folgender diff:

Code:

diff ../dot-config-mini2.txt ../dot-config-mini-bad.txt 
50,51c50,51
< DS_PATCH_ENUM=y
< DS_PATCH_SIGNED=y
---
> # DS_PATCH_ENUM is not set
> # DS_PATCH_SIGNED is not set
74c74
< DS_PACKAGE_DNSMASQ=y
---
> # DS_PACKAGE_DNSMASQ is not set
100c100
< DS_PACKAGE_SYSLOGD_CGI=y
---
> # DS_PACKAGE_SYSLOGD_CGI is not set
264c264
< DS_LIB_libgcc_s=y
---
> # DS_LIB_libgcc_s is not set

Wie kann das sein? Eigentlich egal - Hauptsache es klappt so.

Vielleicht kann jemand bestätigen, dass das mit der dot-config-mini2.txt klappt. Dann mache ich mit der meine Nachlade-Experimente.

Dirk

kriegaex · 5 Apr 2007

Warum die libgcc_s im Mod so viel kleiner ist als im Original

Die Antwort lautet: Du hast die libgcc_s (Größe bei mir: 59.904 Bytes) neu gebaut und damit die Originalversion der 7050 (Größe: 218.412 Bytes) ersetzt. Differenz: ca. gesparte 155 KB.

Grund für die Differenz: Die AVM-Version ist nicht gestrippt - warum auch immer, scheinbar denkt AVM, man habe genügend Platz im Filesystem oder es ist schlicht ein Versehen - unsere schon. :idea:

dsteinkopf · 6 Apr 2007

@kriegaex: Ahja, danke. Das hatte ich auch schon gelesen, nur nicht drangedacht.

Ich habe nun versucht, ein Image mit nfs drin zu bauen. Leider ist das in jedem Fall zu groß. Daher habe ich versucht mit wget die Kernel-Module nachzuladen. Das klappt auch, aber der Mount klappt nicht:

Code:

wget http://martini.steinkopf.net/fritzbox/nachladen/kernel/fs/nfs/nfs.ko
wget http://martini.steinkopf.net/fritzbox/nachladen/kernel/fs/lockd/lockd.ko
wget http://martini.steinkopf.net/fritzbox/nachladen/kernel/net/sunrpc/sunrpc.ko
insmod ./sunrpc.ko
insmod ./lockd.ko
insmod ./nfs.ko

Und dann:

Code:

/var/mod/root $ mount -t nfs -o soft martini.steinkopf.net:/export/fritzbox /var/mod/root/mnt
mount: mounting martini.steinkopf.net:/export/fritzbox on /var/mod/root/mnt failed
/var/mod/root $

Der NFS-Server sagt im syslog:

Code:

Apr  6 10:52:44 martini rpc.mountd: authenticated mount request from fritz.steinkopf.net:753 for /srv/www/htdocs/fritzbox (/srv/www/htdocs/fritzbox)

Und im Fritzbox syslog+dmesg findet sich gar nichts. Und nun komme ich nicht weiter :-(

Weiß jemand, was man für ein nfs-Mount auf client-Seite noch alles braucht?

Dirk

kriegaex · 6 Apr 2007

Hast Du es schon mal mit strace oder gdb versucht? Da würdest Du mehr sehen. Ich werfe das nur mal so hin, ich habe selbst ab und zu (nicht oft) mit strace auf der Box gearbeitet. Mit gdb habe ich noch keine Erfahrung, aber es ist ja in 14.2 drin samt gdbserver für Remote-Debugging.

dsteinkopf · 8 Apr 2007

kriegaex schrieb:
Hast Du es schon mal mit strace oder gdb versucht?

Mit strace wollte ich es versuchen, habe aber nur eins für den alten (2.4?) Kernel gefunden. Lief also nicht. Wie könnte ich an ein geeignetes strace kommen? Ist jemand in der der Lage mir sowas "einfach" zu kompilieren?

gdb habe ich nicht versucht - ich schätze auch, dass ich damit nicht weit komme, weil keine debug-Infos im mount sind. Oder kann ich die irgendwie bekommen?

Dirk

7050 zu eng: DS-Mod-Teile manuell auf externe Platte auslagern

Mitglied

Mitglied

Aktives Mitglied

Mitglied

Neuer User

Mitglied

Neuer User

Mitglied

Anhänge

Aktives Mitglied

Neuer User

Mitglied

Mitglied

Aktives Mitglied

Neuer User

Anhänge

IPPF-Promi

Mitglied

Anhänge

Aktives Mitglied

Mitglied

Aktives Mitglied

Mitglied

Statistik des Forums