Freetz r14702 FB 7390 Build-Frustrationen

[TorstenEK]

Hallo Freetz-Erfahrene!

Ich verwende eine Fritz!Box 7390 F/W 6.83 als VoIP-Router und, da sie eh
läuft als NAS (der Analoganschluß wurde gekündigt; Internetzugang seit
zwei Jahren über selbstgestrickten 3G-Router samt Proxy auf einer RasPi).

NAS-Transfers via Samba sind durch die schwachbrüstige CPU langsam, wegen
des verwendeten Standards (SMB3?) kann ich trotzdem nicht mit älteren
Betriebssystemen (Windows < v5.x, OS/2, DOS) darauf zugreifen. NFS wäre
besser, und SSH-Zugang, wie ich ihn bei der RasPi ständig nutze bietet
Freetz netterweise auch. Nur bei der Dateisystem-Unterstützung nichts
dabei was mir neues bringt - für OS/2-Kompatibilität wäre ein JFS-Modul
hilfreich (Ext2OS2.IFS von 1997 unterstützt nur Sticks bis 1 GB ...).

Versionsverwaltungssysteme (CVS, SVN) sind mehr etwas für Entwickler,
ich hatte bislang einen Bogen darum gemacht. Die Begegnung mit SVN war
ein Horror: den gesamten Tree zunächst gleich dreimal geladen, weil ich's
nicht fassen konnte daß das System nicht die Timestamps aus den HTTP-
Headern übernimmt (wie wget), sondern alles toucht. Sämtlicher Code in
ein und derselben Sekunde entstanden, soso. Dummerweise Download auf
NTFS (unter WinXP) - klar, dabei gingen Symlinks und Attribute verloren ...

Vierter bis sechster Fetch auf Ext4 unter Raspbian Jessie, die Release
stieg unterdessen von 14699 auf 14702. Beim letzten Durchgang leider
Connectabbruch nach 34 MB, Symlinks darin immerhin vorhanden und Skripte
auf "ausführbar" gesetzt. Habe diesen Tree dann über den unter Windows
geladenen kopiert, und hoffe daß nun alle Dateien korrekte Eigenschaften
besitzen. - Als komprimierter Tarball ist der gesamte Sourcetree nur
3,6 MB groß. Wäre es nicht möglich, solche täglich oder wöchentlich
bereitzustellen? Leichter zu laden, und bei Bedarf aktualisierbar.

Build-Dependencies sind schlecht dokumentiert bzw. im Make-Skript wie
beim Paket libtool unvollständig angegeben - die gute Absicht aus der
Ticker-Meldung #2798 vom 21.11.15 hat's noch nicht ins Skript geschafft.
In einem Tag Googlen und Hangeln durch zig Webseiten alle Fehlermeldungen
(außer den Warnungen) beseitigt, "make menuconfig" ließ sich aufrufen.
Der Build ging gutartig an, das Sourceverzeichnis schwoll auf 690 MB
(heißt das "fast fertig"?), doch dann leider Abbruch mit

make -f scripts/Makefile.build obj=scripts/basic
if [ ! -L include/asm ]; then echo ' SYMLINK include/asm -> include/asm-mips'; if [ ! -d include/asm-mips ]; then mkdir -p include/asm-mips; fi; ln -fsn asm-mips include/asm; fi
SYMLINK include/asm -> include/asm-mips
mkdir -p .tmp_versions
make -f scripts/Makefile.build obj=.
mkdir -p kernel/
mips-unknown-linux-gnu-gcc -Wp,-MD,kernel/.bounds.s.d -nostdinc -isystem -D__KERNEL__ -Iinclude -I/Freetz/Freetz_14702/source/kernel/ref-iks-7390_06.80/linux-2.6.28/arch/mips/include -include include/linux/autoconf.h -include /Freetz/Freetz_14702/source/kernel/ref-iks-7390_06.80/linux-2.6.28/include/linux/kconfig.h -DNEW_CONFIG -I/Freetz/Freetz_14702/source/kernel/ref-iks-7390_06.80/linux-2.6.28/include -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -fno-strict-aliasing -fno-common -Werror-implicit-function-declaration -Os -mabi=32 -G 0 -mno-abicalls -fno-pic -pipe -msoft-float -ffreestanding -Wa,-march=24kc -Wa,--trap -I/Freetz/Freetz_14702/source/kernel/ref-iks-7390_06.80/linux-2.6.28/arch/mips/include/asm/mach-fusiv -mno-branch-likely -ffreestanding -I/Freetz/Freetz_14702/source/kernel/ref-iks-7390_06.80/linux-2.6.28/arch/mips/include/asm/mach-generic -D"VMLINUX_LOAD_ADDRESS=0xffffffff80010000" -fomit-frame-pointer -D"KBUILD_STR(s)=#s" -D"KBUILD_BASENAME=KBUILD_STR(bounds)" -D"KBUILD_MODNAME=KBUILD_STR(bounds)" -fverbose-asm -S -o kernel/bounds.s kernel/bounds.c
/Freetz/Freetz_14702/toolchain/build/mips_gcc-4.8.5/mips-unknown-linux-gnu/bin/mips-unknown-linux-gnu-gcc: 1: /Freetz/Freetz_14702/toolchain/build/mips_gcc-4.8.5/mips-unknown-linux-gnu/bin/mips-unknown-linux-gnu-gcc: ELF#4
4: not found
/Freetz/Freetz_14702/toolchain/build/mips_gcc-4.8.5/mips-unknown-linux-gnu/bin/mips-unknown-linux-gnu-gcc: 6: /Freetz/Freetz_14702/toolchain/build/mips_gcc-4.8.5/mips-unknown-linux-gnu/bin/mips-unknown-linux-gnu-gcc: Syntax error: "|" unexpected
/Freetz/Freetz_14702/source/kernel/ref-iks-7390_06.80/linux-2.6.28/./Kbuild:35: recipe for target 'kernel/bounds.s' failed
make[2]: *** [kernel/bounds.s] Error 2
Makefile:1040: recipe for target 'prepare0' failed
make[1]: *** [prepare0] Error 2
make[1]: Leaving directory '/Freetz/Freetz_14702/source/kernel/ref-iks-7390_06.80/linux-2.6.28'

ERROR: Build failed.
make/linux/kernel.mk:148: recipe for target 'source/kernel/ref-iks-7390_06.80/.prepared' failed
make: *** [source/kernel/ref-iks-7390_06.80/.prepared] Error 1

(Sämtliche Konsole-Ausgaben im Anhang, ferner .configure-Anweisungen.)
Installation des Pakets "bc" wie in einigen Suchtreffern nach "recipe for
target 'prepare0' failed" angegeben hilft nicht weiter.

Sorry daß diese Nachricht länger geworden ist (C-Sourcen sind kompakter;-),
mußte mir Frust vom Leib schreiben ... Mir ist bewußt daß ich von einer
Fritz!Box 7390 keine Wunderdinge erwarten darf. Angesichts ihres ständigen
Verbrauchs von 11 Watt (die RasPi zieht nur 2 W) möchte ich aber zumindest
einige der dank Freetz möglichen Goodies nutzen können.

Danke für Hinweise,
Grüße Torsten

 

[f666]

Du versuchst die für die x86 Plattform vorkompilierte Toolchain auf einem Raspberry Pi zu benutzen. Das kann nicht funktionieren.
Ich weiß nicht, ob Freetz inzwischen ohne Probleme auf einem ARM tut. Aber du musst mindestens die Toolchain selbst kompilieren und nicht die Download Toolchain benutzen.
Ich könnte mir vorstellen, dass es Tage dauern wird, auf einen Raspberry Pi ein Freetz Image inklusive Toolchain zu bauen.

 

[tuxedonet]

die Nutzung von Freetz auf 32 Bit ARMv6/v7-Systeme ist seit Changeset 14458 möglich:
http://ww.freetz.org/changeset/14458
build Freetz on build systems like Raspberry PI (for now on 32-bit systems only)

Ich könnte mir vorstellen, dass es Tage dauern wird, auf einen Raspberry Pi ein Freetz Image inklusive Toolchain zu bauen.

die neuen Rasperry-PIs mit armv6l/arpmv7l Prozessoren sind wesentlich performanter;
Laufzeit ca. 3,5h für "make menuconfig" FB7490 mit Optionen für "Build own toolchains"
FREETZ_DOWNLOAD_TOOLCHAIN=n
FREETZ_BUILD_TOOLCHAIN=y

@TorstenEK:
Checkbefehl für Raspberry, um zu prüfen, ob die richtigen Optionen im Freetz gesetzt sind:

grep -E 'FREETZ_DOWNLOAD_TOOLCHAIN|FREETZ_BUILD_TOOLCHAIN' .config

 

[TorstenEK]

Danke für die Rückmeldung Tuxedo!

Hatte am 28.5.18 drei Stunden lang versucht, die .config-Datei des Versuchs
hochzuladen, als plain text, UUEncoded/ Base64, gezippt, als Textdatei mit
".txt"-Extension, mit drei Browsern (Links, Epiphany und Firefox) - der
Server behauptete ständig, es handele sich um einen nicht-unterstützten
Dateityp, sie enthalte "SPAM-verdächtige Inhalte" oder entspräche nicht
den Vorgaben (welchen bloß?). Zwecklos, hab's aufgegeben, Sorry!
Die Site-Admins könnten gerne verraten, welche Dateinamen und -formate
zulässig sind, oder den Server .config-Datei-toleranter konfigurieren.
Seltsamerweise ließ sich mein Build-Protokoll ja problemlos hochladen.

Ich verwende noch eine RasPi 2B, noch keine so schnelle wie die Dreier
also. Außerdem läuft darüber mein Internet-Zugang und der Proxy - keine
so gute Idee also, die MicroSD-Karte mit Kompiliervorgängen zu quälen.

"grep -E 'FREETZ_DOWNLOAD_TOOLCHAIN|FREETZ_BUILD_TOOLCHAIN' .config"
liefert bei mir
FREETZ_DOWNLOAD_TOOLCHAIN=y
# FREETZ_BUILD_TOOLCHAIN is not set
also genau andersherum als in Deinem Beispiel.
Das Verzeichnis ./dl enthält 15 Dateien mit total 41 MB, plus der zwei
Dateien in ./dl/fw (64 MB); jüngste sfk-1.9.1.tar.gz 1,1 MB v. 18.4.18
und yourfritz-11010cf9f8.tar.xz 22 MB v. 26.5.18.

Ich hoffe, die würden bei einem Umzug des Build-Verzeichnisbaums auf
eine andere Linux-Installation übernommen werden. Ich habe einige ältere
Linux-Distributionen auf x86 laufen, GRML 2013.02, SuSE11.4 (beide mit
Compilern usw.), auch Ubuntu 14.04 (stürzt wg. nouveaufb-Bugs ab). Die
Bandbreite meines 3G-Zugangs ist begrenzt, statt ein Ubuntu 16.04 übers
Netz um Build-Requirements zu ergänzen verwende ich lieber solche, zu
denen Pakete auf DVDs (SuSE, Debian 7/ GRML) vorliegen. Übersetzt
Freetz unter diesen ältlichen Distributionen?
Oder besser .config manuell auf "FREETZ_DOWNLOAD_TOOLCHAIN=n" und
"FREETZ_BUILD_TOOLCHAIN=y" abändern und (nach Router-Backup!) unter
Raspbian übersetzen? (Unter einem Tag Zeitaufwand wäre verkraftbar.)

Und: glaubst Du meine Bitte, den SVN-Verzeichnisbaum in Abständen auch
als Freetz_r<release>.tar.xz-Datei verfügbar zu machen ist angekommen
(auch der Wunsch nach JFS-Unterstützung), oder sollte ich dafür evtl.
neue Threads aufmachen?

Viele Grüße Torsten

 

[PeterPawn]

Zumindest die Toolchains für den RasPi (für VR9-Boxen mit 3.10er-Kernel und 0.9.33.2-Lib - also nicht für die neue Labor-Reihe) kann man sich - so man will - von meinem Server laden:

http://yourfritz.de/toolchains/mips_gcc-4.8.5-freetz-r13747-yourfritz-arm.tar.lzma
http://yourfritz.de/toolchains/mips...nel-3.10-freetz-r13747-yourfritz-arm.tar.lzma

und die passenden (detached) Signatur-Dateien liegen dann (jeweils mit ".sig" als zusätzlicher Endung) dort ebenfalls (mit dem Key aus meinem GitHub-Repo signiert).

Das spart bei der Übersetzung auf dem RasPi einiges an Zeit (und Platz auf der µSD-Card - was bei kleineren Karten auch ein Aspekt ist, den man beim Build einer eigenen Toolchain berücksichtigen muß) ... solange die Rahmenbedingungen (hier eben: VR9/GRX (weil 34kc), bis 06.93 wg. der uClibc) passen - daher nutze ich die selbst ebenfalls von dort.

In der ".config" sieht das dann so aus:

pi@raspberrypi:~/freetz $ grep TOOLCHAIN .config
FREETZ_DOWNLOAD_TOOLCHAIN=y
# FREETZ_BUILD_TOOLCHAIN is not set
# FREETZ_TARGET_TOOLCHAIN is not set
FREETZ_TOOLCHAIN_MINIMIZE_REQUIRED_GLIBC_VERSION=y
# FREETZ_TOOLCHAIN_32BIT is not set
# FREETZ_TOOLCHAIN_CCACHE is not set
FREETZ_DL_TOOLCHAIN_OVERRIDE=y
FREETZ_DL_TOOLCHAIN_SITE="http://yourfritz.de/toolchains"
FREETZ_DL_KERNEL_TOOLCHAIN_VERSION="r13747"
FREETZ_DL_KERNEL_TOOLCHAIN_MD5="87008816877dd6a4206e39d0030bb2b9"
FREETZ_DL_TARGET_TOOLCHAIN_VERSION="r13747"
FREETZ_DL_TARGET_TOOLCHAIN_MD5="ae1710e50a54ec2d08d91bd88bb78cce"
FREETZ_DL_TOOLCHAIN_SUFFIX="yourfritz-arm"
pi@raspberrypi:~/freetz $

Zum "Packen" des SVN-Repos noch ein Tipp von mir: Da das Ganze auch auf GitHub zu finden ist und es dort tatsächlich zu den Grundfunktionen gehört, daß man sich einen bestimmten Stand auch als gepacktes Archiv bereitstellen lassen kann, würde ich nicht allzu sehr darauf bauen, daß sich jemand beim SVN tatsächlich dieser Mühe unterzieht.

 

[TorstenEK]

Hallo Peter,

ich kenne die Fritz!Box-Innereien noch nicht so - klar, "VR9/GRX" bezieht
sich darauf, nicht aufs Build-System ("uname -a" oder "ldd --version" egal).
Sind Deine Rahmenbedingungen bei einer Fritz!Box 7390 F/W 6.83 gegeben?

Die zweite URL
http://yourfritz.de/toolchains/mips...nel-3.10-freetz-r13737-yourfritz-arm.tar.lzma
stimmt leider nicht, und Direct Browsing ist abgeschaltet (Error 403).
Brauche ich die, und sollte ich die Datei(en) ins ./dl-Verzeichnis stellen?

Perfekt, den .config-Datei-Auszug mitzuliefern. Ebenso gut zu wissen, daß
Source-Archive auf GitHub liegen. Im HowTo stand, GIT sei veraltet, deshalb
habe ich SVN genommen. Etwas abenteuerlich kam's mir schon vor, einen
unter Windows vollständig geladenen r14702-Tree mit einem 34 MB-Fragment
via Raspbian um symbolische Links und Dateirechte anzureichern.
Aber er scheint ja okay zu sein, wenn ich soweit gekommen bin.


À propos Dateirechte, völlig off topic, außer daß es während des Sortierens
von Freetz-Dateien passiert ist: wvdial (für den 3G-Router) verändert
eigenmächtig jene von /dev/null, was beim Einloggen zu Fehlern ("access
denied") führt. "chmod 666 /dev/null" korrigiert das, dummerweise bin ich
in der Reverse-History aber auf "chown -R user:user ." gekommen, als Root,
vom Root-Directory aus. "ls -f" zeigt /tmp und /usr zuerst an, die habe
ich wieder komplett auf root:root-Rechte gesetzt, /usr/bin/sudo brauchte
zudem noch das User ID-Bit. Gehören alle Dateien unter /usr Root:root?
Und ich sach noch auf meinem Router sollte ich keine Sperenzchen machen ...

Viele Grüße Torsten

 

[PeterPawn]

Ja, war ein Tippfehler meinerseits ... da die Dateien bei mir den Zusatz "freetz-rxxxxx" nicht hatten (ich baue die mit ein paar Änderungen ggü. dem Upstream-Master), mußte ich sie umbenennen, damit sie zur Freetz-Konfiguration (wo das "freetz-" fest verdrahtet ist) passen und dabei bin ich bei der einen Datei in "r13747" um eins verrutscht an der vorletzten Stelle.

Ich habe es oben korrigiert.

=======================================

Im HowTo stand, GIT sei veraltet, deshalb
habe ich SVN genommen.

Im Freetz-Unterforum ist ein Thread angepinnt, der sich u.a. mit dem (kompletten) Umzug nach GitHub befaßt.

Es gibt tatsächlich mehr als ein Freetz-Projekt auf GitHub, aber nur eine Organisation "freetz" und da findet sich auch der jeweils aktuelle Stand aus dem SVN, weil (in eine Richtung) synchronisiert wird. Solange man also das richtige Repository (oder einen Fork davon, wenn man z.B. für Puma6 übersetzen will, was noch nicht im "master" angekommen ist) auf GitHub nimmt, hat man immer den aktuellen Stand und da ist die Funktion "Download as ZIP" vorhanden.

Beim Rest (ACLs usw.) streiche ich die Segel ... verstehe ich nicht (wahrscheinlich fehlt mir irgendwo das berühmte "missing link" - irgendwelche Probleme mit "/dev/nul" könnten ja sowohl mit dem Build-Host als auch mit dem Image in Verbindung stehen) und ich habe auch keine Lust, es unbedingt verstehen zu wollen. Man muß keine Dateien auf eigenen Systemen hin- und herschieben ... einfach "normal" auschecken (oder das Archiv laden und entpacken - das kann man sich vorher auch irgendwo ablegen, damit man es nicht immer aufs Neue laden muß) und die Frage nach ACLs und Eigentümern von Dateien stellt sich nicht.

 

[TorstenEK]

Hallo Peter,

schön, daß Du eigene Nachrichten später editieren und Fehler korrigieren
darfst (Danke!). Habe letzte Nacht erneut zwei Stunden mit fruchtlosen
Versuchen vertrödelt, meine Nachricht ums Protokoll des Build-Fehlschlags
zu ergänzen (und mich um Schlaf gebracht). Google-Suchen offenbarten die
Heuristik der Foren-Software: bei neuen Nutzern ist nachträgliches Editieren
von Beiträgen deaktiviert, soweit sie Links zu externen Sites enthalten
(hier ein ohnehin falscher).

Ich fühle mich am Gängelband: als ich im September 1996 für einen Verein
eine Webseite beim schweizerischen Provider Eye.ch gestaltet habe, bekam
ich eine Hardcopy der Netiquette (den Begriff kennt heute kaum noch jemand).
Habe die Seiten noch und - so hoffe ich doch - noch nie dagegen verstoßen.
Ich werde hier noch einmal versuchen, das Protokoll anzuhängen, der
Vollständigkeit halber.

Dein angepaßter Link funktioniert, viel Holz für meine 64 kbps-Anbindung ...
Habe mich auf Deiner Site Yourfritz.de umgesehen. Erstaunlich, wie viele
Ansätze und Spinoffs es gibt, um das Fritz!OS zu bereichern. Wenn Du den
Deinen um IBMs Journaling File System JFS und einen NFS-Daemon ergänzen
könntest (SSH-Server bereits drin), würde mir das genügen. - Gibt's eine
Freetz-Wishlist, auf der ich die Bitte ums (auch dort fehlende) JFS
loswerden könnte?

Mit GIT beschäftige ich mich, sobald neue Releases substantielle Erweiterungen
bringen (die ./dl-Dateien lassen sich hoffentlich übernehmen, um die Packung
nicht nochmal laden zu müssen). Blöd, daß sich die "Freetz for Beginners"/
Newbie-Seite auf freetz.org so eindeutig für SVN ausspricht, hätte mich
besser in GIT einfummeln sollen. Zip-Archive der Sourcen sind allerdings
nicht ideal, r14702 war knapp 10 MB groß, als .tar.xz dagegen nur 3,6 MB.

Hintergründe zu falschem ACL bei /dev/null in Treffer 2 von 14 aus Google-
Suche nach "'-bash: /dev/null: Keine Berechtigung'" (in Anführungszeichen,
aus oben genanntem Grund vermeide ich Links zu nennen). Freetz ist daran
unschuldig - wer sich wie ich selbst einen Router aus Dialer, Startskrípt
und Adreßumsetzung (NAT, via iptables) zusammenstrickt muß mit Schwächen
der Komponenten zurandekommen. Welchen Schaden ein Debian-Linux nehmen
könnte wenn man anfängt, den Eigentümer aller Dateien rekursiv auf "User"
zu setzen sollte ich eher dort erfragen. Login war zunächst nicht mehr
möglich, von einer offenen Konsole konnte ich aber /tmp und /usr wieder
auf "Root" setzen (hoffentlich standen alle so). Login klappte daraufhin -
etwaige sonstige Kollateralschäden werde ich schon merken.

Beide Dateien, auch Deine
mips_gcc-4.8.5_uClibc-0.9.33.2-nptl_kernel-3.10-freetz-r13747-yourfritz-arm.tar.lzma
22,4 MB v. 29.5.18 13:05:56 liegen im Squid-Cache, bzw. habe ich sie in
./dl gestellt. Kann man das Build-Skript eigentlich dazu bringen, einen
Proxy auf Port 8080 zu verwenden? Angesichts geringer Bandbreite cache
ich seit Jahren möglichst alles, um's nicht erneut laden zu müssen.
(Bislang nur unverschlüsselt, Inhalte des IPP-Forums oder yourfritz.de
leider nicht.) Transparentes Proxying (auf Port 80) hat Nachteile, wget
läßt sich aber z.B. veranlassen via Port 8080 zu laden - die Skripte auch?

Viele Grüße Torsten

 

[TorstenEK]

Hallo nochmal,

anbei das Logfile des aktuellen Fehlschlags. Ein Skript versucht,
mips_gcc-4.8.5_uClibc-0.9.33.2-nptl-freetz-r13747-yourfritz-arm.tar.lzma
statt der verfügbaren
mips_gcc-4.8.5_uClibc-0.9.33.2-nptl_kernel-3.10-freetz-r13747-yourfritz-arm.tar.lzma
von yourfritz.de zu laden.

Ich habe den gesamten Sourcetree nach dem anderen Namen wie auch nach
Strings aus den URLs (das Skript klappert verschiedene Server ab)
durchgegreppt - keine Treffer. Wo ist der Dateiname kodiert, damit
ich ihn manuell anpassen kann?

Blöd, daß das Teil - auch in den angeforderten Namen umbenannt - nicht
im ./dl-Verzeichnis gefunden wird. Ich vermute, auf x86/ amd64 wäre ich
längst fertig. Evtl. versuch ich's dort ...

Freetz-frusted Torsten


(+Freetz_r14702_FB7390_FW683_Build_Failure.txt[7] 4437 Byte v. 31.5.18 21:28)

 

[PeterPawn]

Keine Ahnung, was da noch falsch eingestellt ist ... aber der Name für die Download-Toolchain kann eigentlich kein "kernel" enthalten (zumindest nicht anstelle des "freetz") - da ist das (inkludierte) Makefile recht eindeutig: https://github.com/Freetz/freetz/blob/master/toolchain/make/download-toolchain.mk#L13

EDIT: Ich sehe das jetzt erst ... die 7390 hat gar keinen Kernel 3.10. Die Toolchain ist für diese alte Gurke NICHT geeignet (mal ganz unabhängig von 24kc vs. 34kc).

PS: Ich würde - bei allem Verständnis - auch eher darauf tippen, daß Dich hier Deine wohl generell schmale Internet-Anbindung deutlich mehr frustet (und mehr für Deine Probleme verantwortlich ist) als es Freetz wäre ... da sollte man dann auch den wirklich "Schuldigen" ausmachen und dann auf den einprügeln.

Oder man startet solche Aktionen gar nicht erst lokal, sondern gleich "in der Cloud" ... die PaaS-Angebote sind i.d.R. auch passend an den Rest des Internets angebunden.

Bei einem Projekt wie Freetz wird man eher keine Rücksicht darauf nehmen können, wenn heute noch jemand mit 64 kBit/s darauf zugreifen will - das spielt nämlich für die (hier nun wirklich mal überwältigende) Mehrheit der Benutzer nur eine untergeordnete Rolle. Wenn das vor 15-20 Jahren eine Rolle spielte, ist das nachvollziehbar ... aber die Zeiten ändern sich halt und es gäbe (bei passender Planung) heute durchaus andere Möglichkeiten, als das alles durch eine ISDN-Leitung zu lutschen. Macht man das trotzdem, ist wohl eher die Leitung der Auslöser des Frusts und nicht das Projekt an sich (selbst wenn da mit SVN/Trac vs. Git/GitHub im Moment ein - etwas holpriger - Umbruch stattfindet).

PPS: Weil ich das mit der 7390 nicht so richtig erkannt hatte (obwohl meine Ansage, daß die Toolchain für VR9-Boxen wäre, ja deutlich dasteht), habe ich (auch wenn ich gerade alle 7390 aus dem Bestand habe werfen lassen - auch bei den Kunden) noch eine Toolchain für die Übersetzung von Freetz auf einem RasPi mit den Vx180-Modellen als Zielplattform (obwohl das ja am Ende - in der Praxis zumindest - auch nur noch die 7390 betrifft - die älteren AVM-Modelle mit anderen Prozessoren brauchen dann ohnehin wieder eine LE-Toolchain) hochgeladen.

Der Dateiname lautet dann: mips_gcc-4.8.5-freetz-r13747-yourfritz-arm-24kc.tar.lzma und der für die zweite Datei (mit der Toolchain für "target build") ist analog anzupassen - die Signaturen haben dann wieder ".sig" am Ende.

 

[TorstenEK]

Hallo Peter (und Mit-Leser),

einige Tage hatte ich 7,2 (oder 3,6) MBit/s, nach diversen Freetz-Downloads
schlug die Datenlimit-Drosselung zu. Mehr kann und will ich mir derzeit
nicht leisten. Lieber eine langsame Anbindung als gar keine (bis vor zwei
Monaten kosteten mich Festnetz-Telephonie plus Internet noch Euro 18,06 mtl.,
DSL-Flatrates leicht das Doppelte, und bieten oft trotzdem kein Call-by-Call
in die hier wg. Grenzlage wichtigen Auslands-(Funk-) Netze). Einem Bekannten
zufolge hat der lokale Kabelanbieter einen Teil der Bandbreite angeschlossener
WLAN-Router öffentlich zugänglich gemacht. Falls das stimmt könnte ich mich
optional in eines dieser Funknetze einklinken, oder optional ein "Highest-
Speed-Routing" konfigurieren.

Sorry wegen des Mißverständnisses mit der Hardware bzw. der auf der
Fritz!Box 7390 installierten Kernelversion - und Danke für die passenden
Toolchains! Sind die erwähnten .sig-Dateien PGP-Signaturen? Eine
mips_gcc-4.8.5-freetz-r13747-yourfritz-arm-24kc.tzma.sig auf Deinem
Server ist gesperrt (Error 403 Access forbidden, bei falschen Dateinamen
dagegen Error 404 Not found). Entbehrlich? Die unter
./source/host-tools/yourfritz11010cf9f8/first_aid/ sind im Sourcetree
die einzigen ihrer Art.

Wie lautet der analog anzupassende Name der zweiten Datei, "mit der
Toolchain für 'target build'"? Eine nur um den Anhang "-24kc" ergänzte
mips_gcc-4.8.5_uClibc-0.9.33.2-nptl_kernel-3.10-freetz-r13737-yourfritz-arm-24kc.tar.lzma
gibt es nicht, aber Du sagst ja daß die Fritz!Box 7390 noch gar keinen
3.10er-Kernel hat (ungeachtet F/W 84.06.83?). Außer "uname -a" (via noch
fehlendem SSH) kenne ich keinen Weg wie ich die Version des laufenden
Kernels ermitteln und auch den Namensteil "-3.10-" daran anpassen könnte.

Auf 256 GB Windows-Rechnern mit Freetz-Linux in der Emulation übersetzt
der Sourcetree vermutlich "out of the Box" (sprichwörtlich). RasPi 2B
dagegen am Anschlag: beim Laden Deiner lzma-Datei dekomprimierte Links
sie im Hauptspeicher, bis 1 GB voll waren und der Browser abstürzte.
Ich setze Timestamps von Downloads aufs Original-Datum oder die "Last
modified"-Angabe im HTTP-Header. Links zeigt diese bei vollständig
geladenen Dateien an. Gibt es eine speicherschonendere Methode?

Auf einem x86-Rechner mit 4 GB RAM fange ich wieder von vorne an, bei
unerfüllten Build-Requirements (Header sys/acl.h und sys/capability.h
fehlend, siehe Anhang), entsprechende Pakete nicht im Repository.

Sollte mich an Deinen Rat aus dem tollen Thread über Dateisysteme von
2016 halten und erstmal NTFS durch das Fritz!OS-konformere Ext3 ersetzen -
auch wenn OS/2 dieses nicht lesen kann (JFS weiter ein frommer Wunsch).

Freetz würde erlauben, selbst Hand an eine von AVM eingeräumte Lücke im
GUI-Interface anzulegen: dort ist es ummöglich, einen einmal vom Default-
Share-Namen \\fritz.box\FRITZ.NAS\ (bei leerem Feld) geänderten
Namen zurückzusetzen - von \\fritz.box\<anderer-NAS-Name>\ zurück
zu "FRITZ.NAS" führt nur ein Wiederherstellen der Factory-Defaults, grr.

Viele Grüße Torsten


(+Freetz_r14702_FB7390_FW683_Build_Failure.txt[8] 1222 Byte v. 2.6.18 16:20)

 

[PeterPawn]

1. Ja, die "sig"-Dateien sind PGP-Signaturen der Toolchain-Archive mit dem Key aus dem Repo: https://github.com/PeterPawn/YourFritz/blob/master/PeterPawn.asc - daß sie sich teilweise nicht laden ließen, lag an falschen Berechtigungen, weil ich das Signieren direkt auf dem Server ausführte (mit einem anderen Konto, wo der Apache2-Server keinen Zugriff hat bei Default-Settings).

2. Die Dateinamen lauten:

f0c62eeb5759548eb5e0921254355efd  mips_gcc-4.8.5-freetz-r13747-yourfritz-arm-24kc.tar.lzma
ab7587673ed6c06adfa8dd84018bccb8  mips_gcc-4.8.5-freetz-r13747-yourfritz-arm-24kc.tar.lzma.sig
87008816877dd6a4206e39d0030bb2b9  mips_gcc-4.8.5-freetz-r13747-yourfritz-arm.tar.lzma
d886a6684409951fdba2c60263f4e244  mips_gcc-4.8.5-freetz-r13747-yourfritz-arm.tar.lzma.sig
f672f77776ee36835d9cca41cf6c96bb  mips_gcc-4.8.5_uClibc-0.9.33.2-nptl-freetz-r13747-yourfritz-arm-24kc.tar.lzma
08bc51ba76a8343ef1e39cf05941cd01  mips_gcc-4.8.5_uClibc-0.9.33.2-nptl-freetz-r13747-yourfritz-arm-24kc.tar.lzma.sig
ae1710e50a54ec2d08d91bd88bb78cce  mips_gcc-4.8.5_uClibc-0.9.33.2-nptl_kernel-3.10-freetz-r13747-yourfritz-arm.tar.lzma
f31b8ed950d7e229bdd3428933d57d8c  mips_gcc-4.8.5_uClibc-0.9.33.2-nptl_kernel-3.10-freetz-r13747-yourfritz-arm.tar.lzma.sig

das Verzeichnis "yourfritz.de/toolchains" zeigt auf das o.a. Directory.

3. Eigentlich sollten die passenden Einstellung in der config-Datei für Freetz ausreichen (mit dem "Suffix" auf "yourfritz-arm-24kc", MD5-Hash nach der o.a. Liste), damit das "make"-Kommando den richtigen Download (auch nur einmal, weil die Dateien dann im "dl"-Ordner liegen) automatisch ausführt ... da bringst Du mit Deinen zusätzlichen Aktionen (bei denen ich auch nicht mehr durchblicke bzw. durchblicken will) den Build-Prozess vielleicht einfach wieder durcheinander.

4. Ich verstehe nicht mal im Ansatz, wo hier ein NTFS-Dateisystem eine Rolle spielen soll oder kann ... ich käme nie auf die Idee, die Freetz-Build-Struktur dort zu speichern (auf irgendeinem "nicht nativen Dateisystem), weil Freetz eben auch (neben "fakeroot"-Möglichkeiten, die aber nur die "Superuser-Rechte" emulieren und m.W. immer noch von den Linux-/Posix-Rechten abhängig sind) mit den korrekten Dateirechten arbeiten muß (und will).

5. Ein JFS (wenn es die passenden Posix-ACLs unterstützt) für den Build-Host kannst Du ja nun ohne jedes Problem nutzen ... das hat per se ja erst mal mit Freetz und dem Freetz-Kernel nichts zu tun.

6. Ich verstehe auch nicht im Ansatz das Problem, warum irgendjemand für Dich nun "JFS-Support" in Freetz einbauen sollte ... der Kernel der 7390 (2.6.28) bietet problemlos die Möglichkeit, JFS direkt einzubinden oder als Module zu übersetzen und die Anpassungen an den paar Shell-Skripten in "/etc/hotplug" sind ja nun auch keine "rocket science" (wobei ich nicht mal weiß, wie "smart" hier FREETZMOUNT wäre und ob man tatsächlich den Dateisystemtyp "JFS" noch hinzufügen müßte oder ob das automatisch klappt):

config JFS_FS
        tristate "JFS filesystem support"
        select NLS
        help
          This is a port of IBM's Journaled Filesystem .  More information is
          available in the file <file:Documentation/filesystems/jfs.txt>.

          If you do not intend to use the JFS filesystem, say N.

config JFS_POSIX_ACL
        bool "JFS POSIX Access Control Lists"
        depends on JFS_FS
        select FS_POSIX_ACL
        help
          Posix Access Control Lists (ACLs) support permissions for users and
          groups beyond the owner/group/world scheme.

          To learn more about Access Control Lists, visit the Posix ACLs for
          Linux website <http://acl.bestbits.at/>.

          If you don't know what Access Control Lists are, say N

config JFS_SECURITY
        bool "JFS Security Labels"
        depends on JFS_FS
        help
          Security labels support alternative access control models
          implemented by security modules like SELinux.  This option
          enables an extended attribute handler for file security
          labels in the jfs filesystem.

          If you are not using a security module that requires using
          extended attributes for file security labels, say N.

config JFS_DEBUG
        bool "JFS debugging"
        depends on JFS_FS
        help
          If you are experiencing any problems with the JFS filesystem, say
          Y here.  This will result in additional debugging messages to be
          written to the system log.  Under normal circumstances, this
          results in very little overhead.

config JFS_STATISTICS
        bool "JFS statistics"
        depends on JFS_FS
        help
          Enabling this option will cause statistics from the JFS file system
          to be made available to the user in the /proc/fs/jfs/ directory.

Wer soll da also was genau (für Dich) "einbauen"? Gerade dann, wenn man mit solchen uralten Dateisystemen arbeiten möchte (schon über das halbe OS schütteln heutzutage sicherlich viele den Kopf, auch wenn dessen GUI-Ansatz seiner Zeit weit voraus war), sollte man sich doch so langsam mal damit auskennen ... die Quellen des JFS im Linux-Kernel sind > 15 Jahre alt.

7. Es ist halt blöd, wenn praktisch alle Ressourcen gleichzeitig begrenzt sind ... während ZIP-Kompression größere Dateien zum Download ergibt, braucht das Entpacken dort nur unwesentlichen Speicher zur Laufzeit ... wenn man die hohe Kompression von LZMA haben will, muß man auch den (Haupt-)Speicher für den Baum beim Entpacken haben. Wobei ich das auch alles nur schwer nachvollziehen kann ... mein RasPi 3B hat halt mehr Prozessor-Power als ein RasPi 2, aber auch nur 1GB RAM - und ich habe keinerlei Problem, die Toolchain-Pakete zu entpacken. Ich mag mich ja täuschen, aber ich habe halt den Eindruck, daß Dein ganzes Hantieren mit (Caching-)Proxies für alles und jedes am Ende doch nicht sooo transparent ist, wie Du vielleicht denkst und es einige Anwendungen schon bräuchten, wenn Du sie "out of the box" benutzen willst bzw. daß Du das mit dem Freetz am liebsten irgendeinem ohnehin vorhandenen Gerät noch mit "aufhalsen" möchtest. Wenn da bereits ein Kodi-Mediacenter auf dem RasPi läuft, ist zuwenig RAM sicherlich auch nicht wirklich überraschend (noch dazu, wenn dann Swap-Space am besten noch über eine µSD-Card bereitgestellt wird). Schon das ganze X-System kann (bzw. sollte) man sich für einen Freetz-Build-Host sparen, wenn die Ressourcen ohnehin schon knapp sind - wer braucht auf einem Build-Host einen (graphischen) Web-Browser?

Ich kann Dir jedenfalls versichern, daß es für eine reibungslose Nutzung der Freetz-Toolchains keines Windows-Systems mit 256 GB bedarf (weder beim RAM noch bei der HDD - wobei "Windows" hier ohnehin einigermaßen überraschend ist, wenn man nicht WSL im Hinterkopf hat) - ich übersetze sowohl auf einem RasPi 3B (Raspbian) als auch in einer (VMware WS-)VM mit 2 GB RAM und zwei (virt.) Prozessoren (Ubuntu 16.04) ohne jedes Problem (und ich schreibe, teste, debugge dann auf openSUSE tatsächlich auch noch eigenen Code und brauche nicht nur irgendwelche fertigen Pakete, dann allerdings auf einem etwas potenteren System) - zumal ja nun hoffentlich nicht auch noch der Platz auf HDD (als persistenter Speicher) bei Dir genauso knapp sein wird, wie die ganzen anderen Ressourcen ... ansonsten muß man auch mal im Kopf die Notbremse ziehen und konstatieren, daß auch "embedded development" noch nicht unbedingt etwas damit zu tun hat, daß man es alles direkt auf diesen "kleinen Geräten" auch "embedded" entwickeln kann und gerade hier oft genug in der Entwicklung (und Freetz gehört nun mal eher zu "Entwicklung" als zu "daily use" - das wäre erst das fertige Image) auch diese Geräte mit ihren begrenzten Ressourcen auf sehr viel leistungsfähigeren Maschinen emuliert werden (kein (effektiver) Mensch programmiert z.B. eine App für ein Android-Smartphone auf dem Gerät selbst) und wenn man diese Technik nicht zur Verfügung hat, kann man diese Entwicklung eben auch nicht vornehmen.

Bei Deinen Problemen mit den "build prerequisites" verstehe ich Dich auch nicht ... was soll uns denn das Stückchen Logfile sagen? Daß in Deinem fünf Jahre alten Linux-System (wenn das tatsächlich der "Grumpy Grinch" aus 2013 ist, der dann wieder auf Wheezy basieren würde) irgendwelche (ggf. neueren) Pakete nicht in den Repositories auftauchen (wenn diese Repos überhaupt noch aktiv sind und nicht nur seit langem nicht mehr gewartete Mirrors bei irgendeiner Uni auf dem vergessenen Server in der Ecke)?

Im Repo für Raspbian (sogar schon für Jessie, nicht erst für Stretch) ist jedenfalls "libacl1-dev" enthalten: https://packages.debian.org/jessie/libacl1-dev + https://packages.debian.org/stretch/libacl1-dev und auch für "libcap-dev" sieht es nicht anders aus: https://packages.debian.org/jessie/libcap-dev + https://packages.debian.org/stretch/libcap-dev - wo ist also (mal abgesehen von einer Distro, für die es vermutlich gar keine aktiven Repos mehr gibt) das Problem?

Außerdem ist eben grml per se schon eher eine schlechte Wahl ... das ist nun mal auch kein System für diesen Einsatzzweck (mit Compilern und C-Libraries) und ich hoffe mal, daß Du das hier nicht obendrein nur als Live-System auf der ZBOX laufen läßt (sollte es tatsächlich eine sein - wobei ich auch für eineZBOX ID-41 versichern kann, daß die Freetz-Toolchain dort ohne Probleme (allerdings mit 4GB RAM) arbeitet - hatte ich selbst hier, bis der SATA-Controller die SSD nicht mehr mochte) ... wobei die meisten wohl einem so alten (und für Installation eher unhandlichen) OS wie grml ohnehin nichts abgewinnen könnten. Schon die Tatsache, daß man bei einem Live-System erst die ganzen Pakete hinterherschieben muß (was als Overlay dann auch noch die RAM-Nutzung aufbläst), sollte jedem klar vor Augen führen, daß ein Live-System nur dann etwas Praktikables ist, wenn man die notwendige Hardware dafür auch hat (bis hin zur performanten Internet-Anbindung).

Du kannst jedenfalls kaum ernsthaft erwarten, daß das wirklich gut gehen kann mit der Freetz-Toolchain in einem dermaßen veralteten System wie Grumpy Grinch ... spätestens dann, wenn irgendein Paket in der heute aktuellen Version irgendwelche neueren Include-Files brauchen sollte, stehst Du das nächste Mal "vor der Wand" und wenn Du Dich da jedes Mal aufs Neue von Beginn an auf den Weg machst, dürfte das Deinen Ressourcen auch nicht gerade gut tun.

Dann kauf Dir einfach irgendeine Zeitschrift mit einem halbwegs aktuellen System (wobei das vermutlich auch wieder nicht zu aktuell sein darf, denn man kann ja auch den Eindruck gewinnen, daß Deine Hardware mit 64-Bit-Software vielleicht gar nichts anfangen kann (der Atom 525 im ID-41 kann auch nicht mehr als die 4 GB Memory verwalten) bzw. es ist auch für Dich als "beginner" sicherlich erst mal leichter, wenn Du mit einem 32-Bit-System als Build-Host startest - aber ein Ubuntu 16.04 LTS sollte da schon helfen) ... da hast Du dann auf 4,7 oder 8,5 GB auch alle Source-Pakete mit drauf und wenn nicht, bestelle Dir bei irgendeinem Distributor (openSUSE bietet das m.W. immer noch an, über irgendeinen EDV-Buchversand) einfach ein "komplettes" System. Wobei eben auch das heutzutage i.d.R. schon veraltet ist, wenn der Master noch auf dem Weg zum Pressen ist ...

 

[TorstenEK]

Hallo Peter,

thank you for your very comprehensive reply!!

@1: Apache2 macht per Config-Defaults erstmal alles dicht, alles muß man
explizit freischalten, wohlbekannt ...

@2&3: Perfekt! MD5-Prüfsummen im .config, und auch ein zunächst übersehenes
"yourfritz-arm-24kc". Schrittweise Anleitungen (1. Klicken Sie hier, 2.
Klicken Sie dort usw.) wirken etwas kindisch, haben aber den Vorteil daß
alles dabei ist wenn man sich daran hält.

@4: Keine Umnachtung, sondern schlichtes Nicht-Wissen: ich hatte noch nie
mit SVN (oder GIT oder CVS) zu tun und keinerlei Ahnung, was da überhaupt an
Sourcen kommt. Klar, daß Shell-Skripte ihre Attribute brauchen (unter OS/2
in *.cmd umzubenennen) - sichtbar erst wenn der Code da ist.

@5&6: Genial! Die eComStation- (oder ArcaOS-?) Leute entwickeln JFS fleißig
weiter, haben die GPL-Uralt-Sourcen nach OS/2 zurückportiert, das nun sogar
davon booten kann (mit IBMs JFS.IFS ausgeschlossen). Andere Aficionados
haben den Kernel nachprogrammiert (OS/4 / Phoenix-Projekt), er unterstützt
jetzt Speicheradressierung > 4 GB. Ganz tot ist das System nicht.

Ich möchte JFS auf dem angestöpselten NAS-Speicher verwenden, nicht auf dem
Build-Host. Da wie Ext3 als Kernel-Modul ausgeführt sollte es (hoffentlich)
ähnlich schnell arbeiten.

Deine JFS-Optionen sind ein ausgewachsener Patch fürs Menüsystem, wo kommen
die rein, in eine der ./.svn/pristine/bb/bb<Hash>.svn-base-Dateien, in
./config/avm/features.in, ./config/ui/modules.in oder ./config/ui/patches.in?
Oder ein generischer Auszug (incl. Docu), zum manuellen Einflicken in .config?
Aber, wie Du es schreibst sind Freetz und (hier: 2.6.2 Kernel zwei Paar
Schuhe. Echte Wissenslücke meinerseits: übersetzt Freetz' "make" den Kernel
jedesmal mit (z.B. um sich überhaupt einklinken zu können), und hat dieser
ein separates .config-File? Cross-Kompilieren allein ist wenig übersichtlich,
und die schönen Puzzle-Bildchen verraten nicht was dabei eigentlich passiert.

@7: Alles zugleich am Anschlag ist Grützenka*, wie ein Freund sagen würde.
Als die RasPi 3 2016 vorgestellt wurde meine ich "2 GB RAM" gelesen zu
haben (hätte mich gejuckt, schnellere CPU, WLAN, weiterhin lahme Ethernet-
Anbindung via USB-Port und höherer Stromverbrauch dagegen nicht die Bohne).

Windows Subsystem for Linux (WSL)? Bewahre! Nein, ich meinte Silent-Tears'
freetz-linux-x.x-x.ovf VBox-Images, aus seinem am 20.9.09 begonnenen Thread
https://www.ip-phone-forum.de/threads/buildumgebung-freetz-linux.199449/ .
Der 1st-Steps-Guide http://www.freetz.org/wiki/help/howtos/common/newbie.en
widmet VirtualBox einen so großen Screenshot daß ich (fälschlich) dachte
die meisten Leute würden von Windows-Rechnern aus mit Freetz hantieren.
Von "256 GB Hauptspeicher" erzählte ein c't-Redakteur letzten Herbst vor
seiner Verrentung. Daß die Zeitschrift über aktuelle Server-Plattformen
berichtet ist klar, so etwas privat zu verwenden wäre mir aber "too much".
1992/93 war mein i486 32 MB EISA-/VL-Rechner "State of the art" (für OS/2/
WinNT31/ NextStep), heute geht es mir wie einem anderen c't-Redakteur, der
da schrieb "Nach >30 Jahren reißt einen die 174ste Performance-Steigerung
der x86-Prozessoren nicht mehr so vom Hocker." Ein aus BYTE übernommener
Artikel (daher nicht auf c'tROM) schrieb damals sinngemäß "64-Bit-CPUs
braucht kein Schwein" ... es kam anders.

Die Frage "Wie ermittele ich den HTTP-Header einer URL" (mit wget, einem
Protokoll-Analyzer o.ä.?) hätte ich schlichter stellen müssen, ohne Bezug
zu Links! Bei letzterem "not a bug, but a feature": wie andere Browser lädt
er komprimierte HTMLs bandbreite-schonend und entpackt sie on-the-fly zum
Rendern. Binaries möchte er zweckmäßigerweise abspeichern, dieser Prozeß
läuft im Hintergrund und frißt kein Brot. Um ihre Header einzusehen lasse
ich mir Archive optional anzeigen. Bei Windows-.exe-Paketen kein Problem,
<Archiv>.tar.bz2 wird dagegen auf den Schirm gerendert ... bei Deiner 22 MB-
lzma-Datei genügten 730 MB freier Speicher nicht zum Auspacken. Das macht
kaum jemand - andere, die wie ich möchten daß Downloads den Timestamp der
"Last modified"-Angabe tragen verwenden eher Downloader-Plugins, die das
automatisch übernehmen (statt lokale Kopien nachträglich touchen zu müssen).

GRML selbstverständlich auf HD, in einer 30,5 GB-Ext4-Partition. Das Skript
(grml2hd o.ä.) hat eine Macke, statt auf Platte mußte ich in ein formatiertes
Loop-Image installieren und dessen Inhalt auf die Ziel-Partition kopieren.
Ich war scharf wie Lumpi auf die Debian 8-basierte Release gewesen und lud
GRML 2017.05 als es zwei Tage draußen war. Halt SystemD-basiert (mag ich
nicht), vieles völlig anders. GRML 2013.02 läuft auf zwei Rechnern, der
Handler für virtuelle Konsolen (tty9-11 mit IPTState, Htop & Multitail) ist
ein Hit, habe ihn samt Terminus-Font in Ubuntu 14.04 eingeflickt (v.a. wegen
der GRML-Goodies nicht seit zwei Jahren auf Ubuntu 16.04 umgestiegen), nur
für Raspbian leider kein Handler-Binary. Debian 7-Repository als DVD-Image
im Root (Komfort wie bei SuSE), viele Pakete daraus nachinstalliert, ein
rundes System, ich verwende es mittlerweile häufiger als SuSE oder Ubuntu.
Bei Raspbian führte der Tip eines Redakteurs, auf Debian-armhf-Binaries (von
DVD-Images) zurückzugreifen zu einem durchwachsenen Hybrid, GRML nimmt die
von Debian 7-amd64 dagegen klaglos, nur fehlen einige Pakete (libacl1-dev).

Die Crux an Upgrades ist, daß man Wochen mit Anpassungen zugange ist - bei
SuSE 9.3 blieb ich bis dessen Defizite überwogen. In GRML vier Kleinigkeiten
offen, vgl. http://ml.grml.org/pipermail/grml/2018-February.txt.gz .
Ubuntu 8,5 GB-DVD mit Repository (/pool/ usw., wäre ein Hit!), oder nur als
Sourcen? Hab die Debian 8.0 Source-Sammlung auf zehn DVDs liegen, Pakete
selbst bauen zu wollen ist wegen nie-endender Build-Dependencies ein Krampf!

Hast Du Deine ZBOX-ID41 noch? (Einer von meinen fehlt der Deckel, sie werden
allenfalls für die neueren Mini-Serien angeboten, nicht für die "Classic".)
Der "Pineview"-Chipsatz soll mit 512Mx8-organisierten Riegeln 8 GB oder sogar
16 GB RAM unterstützen (meine ZBOXen je 4 GB, von GRML amd64 genutzt*), vgl.
https://www.servethehome.com/supermicro-x7spahfd525-x7spehfd525-atom-server-motherboard-review/

Der Netz- und Kultursoziologe Nils Zurawski sagte Ostern "Apps werden nicht
auf Handies entwickelt sondern am Desktop-Computer. Smartphones sind reine
'Angebots-Auswahlmaschinen'." Leute die sie v.a. als solche nutzen (um zu
gucken welche Kneipen offen sind, obwohl sie gleich nebenan liegen) haben
für dieses Zitat wenig Verständnis. Hab seit Ewigkeiten Garfinkel & Mahoneys
"Objective C"-Bibel liegen, für iOS-Entwickler hat sie evtl. noch Relevanz.

"Mit Ressourcen haushalten" paßt gut - besser endlich in die Pötte kommen!
Und, nach einem Tag Stöppelei - und einem Abbruch, nachdem /usr/bin/wvdial
an /dev/null rumfuhrwerkte: "es wuppt", 1,25 GB Sourcetree liegen auf der
Platte (MicroSD), ein echter Klopper. Config- und Logfile im Anhang, habe
aber etwas Muffe das 17,5 MB-Image zu flashen. Erst gründlich prüfen ...

Danke nochmal für die Toolchains, und sämtliche Hinweise!

Viele Grüße Torsten


(+Freetz_r14702_FB7390_FW683_Build_Success.txt[9] 74670 Byte v. 4.6.18 0:37
+Freetz_r14702_FB7390_FW683_config.txt[4a] 70039 Byte v. 3.6.18 21:42)

 

[PeterPawn]

Die von mir "zitierten" JFS-Optionen sind bereits in den Kernel-Sources der 2.6.28 von AVM enthalten.

Damit reicht bereits der folgende Patch:

pi@raspberrypi:~/freetz $ git diff
diff --git a/config/ui/modules.in b/config/ui/modules.in
index 3b8ce0eec..6a3c7a987 100644
--- a/config/ui/modules.in
+++ b/config/ui/modules.in
@@ -427,6 +427,11 @@ config FREETZ_MODULE_jbd2
        depends on FREETZ_KERNEL_VERSION_2_6_28_MIN
        default n

+config FREETZ_MODULE_jfs
+       bool "jfs.ko"
+       depends on FREETZ_KERNEL_VERSION_2_6_28_MIN
+       default n
+
 config FREETZ_MODULE_lockd
        bool "lockd.ko"
        depends on \
pi@raspberrypi:~/freetz $

(und natürlich das Aktivieren der Option in der Freetz-Konfiguration), damit beim Build (der dann den Kernel neu baut und entsprechende Zeit benötigt) auch JFS als LKM mitgebaut und ins Image kopiert wird.

Zuvor braucht es dafür noch ein "make kernel-source" (damit die Quellen überhaupt erst einmal in einem "frischen" Checkout vorhanden sind) und ein "make kernel-menuconfig", bei dem man unter "File systems" dann den JFS-Support entsprechend konfigurieren muß. Solange man den als LKM bauen läßt, müßte (zumindest würde ich das aus dem Bauch heraus erst mal so probieren) auch das Ersetzen des Kernels nicht notwendig sein, da sich beim Hinzufügen von JFS für andere Dateisysteme und -strukturen ja nichts ändert.

Für das automatische Einbinden von JFS-Volumes muß man dann noch nach der "libmodmount.sh" (unter "make/mod/files/root/usr/lib/libmodmount.sh") schauen und dort (z.B. analog zu "hfs") das korrekte Mounten (in "mount_fs") nachrüsten - auch die findet man notfalls mit einem "grep" o.ä. anhand ihres Namens in der (originalen) Verzeichnisstruktur aus Git, wenn man keine Ahnung hat, wo man suchen soll/muß.

Da die Erkennung des Dateisystems natürlich über "blkid" läuft, muß man halt auch dafür sorgen, daß das verwendete "blkid" (das kann entweder das aus der BusyBox sein oder das aus "util-linux" - je nachdem, was man eingestellt hat) ein JFS am Gang erkennen kann.

==============================================================

Ich verstehe auch durchaus, daß es nicht so ganz simpel ist, durch den Freetz-Build-Prozess durchzusteigen (einiges ist auch in meinen Augen unnötig kompliziert - aber das ist nun mal so und damit muß man eben klarkommen ... hier ist "Adaptionsfähigkeit" eine echte Tugend, nur kann "Freetz" auch ein echtes Chamäleon sein und manchmal weiß man gar nicht, wie man es jemandem "recht machen" soll) - nur hilft es am Ende keinem (potentiellen) Freetz-Benutzer, wenn er auf der Basis Deiner Probleme den Eindruck gewinnt, er solle besser gleich die Finger davon lassen, weil es auch bei Dir (der Du ja offensichtlich schon seit einiger Zeit Linux verwendest) nur aus "ungelösten Problemen" besteht (bis hin zu Deinen Problemen, Textdateien an Xenforo-Beiträge anzuhängen, womit Freetz ja nun gar nichts zu tun hat).

Daher wollte ich schon noch einmal ganz deutlich machen, daß ein guter Teil Deiner Probleme eben auch aus einer "anormalen" Benutzung der Freetz-Toolchain resultiert (das ist auch vollkommen in Ordnung, daß man diese Toolchain "zweckentfremdet", das mache ich genauso und ich habe auch schon mehrmals mit den "Machern" von Freetz diskutiert, daß es sich eigentlich um vier - relativ unabhängige - Teilaspekte handelt bei dem, was man unter "Freetz" allgemein so subsummiert) - daher resultiert auch ein großer Teil Deines Frustes (und den Thread-Titel hast Du ja gewählt und kein anderer) aus dieser Benutzung.

Die Dokumentation für den Benutzer mag hoffnungslos überaltert sein ... wer das kritisiert, kann sich ja gerne selbst so weit einarbeiten, daß er sie korrigieren kann (macht er dabei fachliche Fehler, werden ihn andere schon darauf hinweisen - eine echte "Gefahr" geht da also selbst von einem absoluten Laien nicht aus). Am Ende hast Du ohnehin gerade eine Phase erwischt, wo SVN und Trac-Server mal etwas länger zu laufen scheinen (warum, weiß ich auch nicht, vielleicht haben ein paar Diskussionen auf der (Entwickler-)ML ja geholfen) ... am Beginn des Jahres hättest Du nicht mal das Wiki und/oder den SVN-Server dort erreicht. Inzwischen gibt es immerhin eine Kopie des Wiki auf GitHub und ja ... es müßte sich jemand finden, der das so abändert, daß es nicht mehr den Start des Builds anhand eines SVN-Checkouts beschreibt. Aber wer soll das machen?

Freetz ist nun mal ein Community-Projekt - zumindest bei der Dokumentation und beim "Support". Schreibzugriffe auf den Code im SVN sind limitiert, deshalb wäre ja auch der komplette Umzug auf Git/GitHub für die "Community" besser, weil man dann einfach einen anderen/eigenen Fork nimmt, in dem man die für einen selbst interessanten Patches aus anderen Forks sammelt und damit ist man dann nicht mehr auf den SVN-Trunk und das "händische" Patchen mit irgendwelchen Anhängen aus Trac-Tickets angewiesen - leider braucht das entweder noch etwas Zeit, um sich als Erkenntnis wirklich durchzusetzen oder es paßt nicht zu anderen Überlegungen hinsichtlich der "Schlüsselgewalt" beim Freetz-Master ... ich weiß es nicht und kann nur konstatieren, daß entsprechende "Weckrufe" in dieser Richtung bei den handelnden Personen eher auf taube Ohren stoßen (keine Reaktion und ein sichtbares "weiter so" durch Fortführen im SVN kann man m.E. kaum anders interpretieren).

Es darf/soll/kann jedenfalls jeder bei Freetz mitmachen und wenn jemand (egal ob jetzt Unklarheiten im Freetz oder eigene Wissensdefizite die Ursache sind) etwas von "Frust" schreibt, kann man ja durchaus auch den Eindruck gewinnen, er wolle den hier "abladen" und den "Machern" mal auf die Schnelle erklären, was sie doch eigentlich alles falsch machen (hatten wir halt auch alles schon, daher wird man da hellhörig).

Das ist auch durchaus einiges, was da beim gesamten Projekt (auch aus meiner Sicht jedenfalls) im Argen liegt ... aber solange Du nicht Deine Rosinante satteln willst, mußt Du mit einigen Kröten eben leben. Das ist trotzdem noch kein Grund zur Verzweiflung und auch keine Begründung für Frustrationen, die andere vielleicht nicht auf ihre tatsächlichen Ursachen zurückführen können und daher direkt mit dem Freetz-Projekt verknüpfen würden, wenn sie Deine ersten Einlassungen lesen ... es gibt zwar auch echte Gründe für Frustrationen beim Projekt (von denen lasse ich mir aber die Laune nicht verderben und denke eher: "Steter Tropfen höhlt den Stein."), aber bei Dir liegen die Ursachen dann (zumindest nach meinem Eindruck) doch eher noch an anderen Stellen und da kann Freetz nur sehr bedingt für.

 

[TorstenEK]

Hallo Peter (und alle, die nicht die Lust verloren haben mitzulesen)!

Der Name eines Threads läßt sich nachträglich nicht mehr ändern (oder doch?),
nach dem ersten erfolgreichen Compile-Durchlauf habe ich mich aber durchaus
gefreut (Motto "Freetz-Frustrationen, abgelöst durch Jubelschreie" ...).

Was Du über Vereine schreibst (SVN-Auszeit) kommt mir sehr bekannt vor: ein
Baseler Maker-Space (starship-factory.ch) veranstaltet öfter RasPi-Workshops
und andere Events. Ein langjähriger Bekannter, mit dem ich Weihnachten 2001
beim 18C3 auf dem "Blinkenlights"-Gebäude herumgestiegen war meinte vorletzten
Herbst, ich solle zu meinem "RasPi als 3G-Router" einen Wiki schreiben. Bis auf
einige Hakeleien (durch Heraufsetzen der USB-Versorgung auf 1200 mA gelöste
Connect-Abbrüche des 3G-Sticks - mehr Strom, d.h. 900 mA an Fritz!Boxen nur
bei USB 3.0-Modellen? - und das weiterhin offene wvdial-Issue) hatte ich alles
beisammen, doch dann war die Seite längere Zeit offline, und die Idee schlief
ein. Gut, daß svn.freetz.org wieder online ist/ Ende Mai war!

Mein erstes unixoides System war NextStep (ein SCO o.ä.-Diskettensatz, der
mir 1991 zuflog erwies sich als unvollständig, bei Heise trafen sich um die
Zeit noch die Coherent-Leute), 1997 dann FreeBSD 2.2.2 mit XFree86 3.3.2 und
Kalle Dalheimers 0.4er-KDE (alles via 28,8 kbps-Modem). Über Linux Spott bei
einer Party ("Mainstream mit lahmem TCP/IP-Stack"), wegen seiner Verbreitung
und guter Vor-Konfiguration bin ich jedoch schnell bei SuSE gelandet.

Die Kernel-Sourcen unter ./source/kernel/ref-iks-7390_06.80/linux-2.6.28/ samt
Config- und Makefile hatte ich entdeckt. Gut, auf Deine Tips gewartet zu haben!
Der 433 MB-Tree scheint vollständig zu sein, "make kernel-source" war nicht
nötig (siehe Logfile).

Am JFS-Patch hatte ich zu knabbern. Liefert "git diff" einen zu Diff analogen
Output und kann mit Patch auf ./config/ui/modules.in angewendet werden? (Bislang
hatte ich noch nie mit Git zu tun, keinerlei Erfahrung damit.) Wäre schön wenn
Du die Parameter zu Patch nennen könntest, nach erfolglosem Probieren habe ich
ihn manuell eingeflickt (zwischen "config FREETZ_MODULE_jbd2", hier in Zeile 425
und "depends on FREETZ_KERNEL_VERSION_2_6_28_MIN" steht in r14702-modules.in ein
"bool 'jbd2.ko'", vielleicht hat Patch die Stelle deshalb nicht gefunden).

Auf "make kernel-menuconfig" wäre ich nie gekommen! Als Label im Makefile
taucht's nicht auf (dort suche ich sonst nach Optionen, die ./configure nicht
anzeigt). Im Freetz-Menü taucht jetzt ein einzelnes JFS-Kästchen auf, ohne Sub-
Optionen, diese nur im Kernel-Menü, dort einkompiliert wie als Modul wählbar.
Habe wie vorgeschlagen letzteres genommen - obwohl auch Ext4 als Modul existiert,
das von der Fritz!Box 7390 im Gegensatz zu einkompilierten Ext2 und Ext3 nicht
gemountet wird. Oder ist es so, daß vorherige Auswahl im Freetz-Menü automatisch
"Modul" im Kernel-Configfile auswählt? (Dann wäre Ext4 zuvor ganz aus gewesen,
obwohl das 2017er-Handbuch zur 7390 behauptet Ext4 werde unterstützt. Grr, fast
1 GB Daten aus ./dl/fw/7390_06.80-release_kernel.tar.xz umgeschaufelt, nur um an
die Vanilla-./source/kernel/ref-iks-7390_06.80/linux-2.6.28/.config 42398 Byte
v. 23.3.17 11:32:47 heranzukommen, CONFIG_EXT4_FS war zuvor nicht gesetzt, AVMs
https://assets.avm.de/files/docs/fritzbox/fritzbox-7390/fritzbox-7390_man_de_DE.pdf
3,8 MB v. 14.6.17/ Abruf 8.4.18 S. 149 erzählt Müll, und man rätselt rum.)

So simpel und funktional wie die Kernel-Configmenüs sollte mal die Fritz!Box-
Oberfläche sein, dann hätte es die 24KC-CPU leichter und man bräuchte keine
Oversized-Browser um ans GUI heranzukommen. Etwas Blut habe ich geleckt: der
Fritz!Box 7390-SMBD verwendet standardmäßig Port 445 (plain SMB über TCP), das
Protokoll älterer DOS-, OS/2- und Windows-Clients, SMB über NetBIOS über TCP
dagegen Port 139. Wäre interessant, NAS-Speicher auch von diesen Plattformen
aus via SMB (nicht nur per FTP) nutzen zu können.

Funktion mount_fs() in ./make/mod/files/root/usr/lib/libmodmount.sh analog HFS
um JFS ergänzt. Unter GRML (Kernel-3.7-1) mountet JFS nur mit "rw,relatime",
der simpele HFS-String sollte reichen. Startet blkid via Config-Datei, welcher?

Beim Vorab-Befüllen eines JFS-Mediums gab's Seltsamkeiten: unter OS/2 mit
Schreibschutz-Bit versehene Dateien lassen sich partout nicht löschen, weder
mit der Mount-Option "iocharset=utf8" noch via Root-Paßwort noch chmod/setfacl
(alle Attribute R/W/X/S aus, nicht änderbar), stets "Operation not permitted".
(Hab sie unter OS/2 gelöscht.) Einige Dateimanager touchen auch beim Kopieren
auf JFS und können dort Timestamps nicht ändern, JFS nicht ganz hauseigen also.
Ferner ein Ext3-Medium mit den gleichen Daten vorbereitet (andere Linux-Sticks
stets mit Ext4, ein kleiner für OS/2 mit Ext2), zwecks Performance-Vergleichs
an der Fritz!Box. Beschreiben ließ es sich deutlich langsamer als das mit JFS,
evtl. fabrikatsbedingt. Da es als Read-only-Speicher mit unter 100 Dateien
dient hatte ich zwecks Platzgewinns Journalgröße und reservierte Blöcke (für
den Superuser) auf untere Limite gesetzt, für die Performance sollte das wohl
keine Geige spielen (?).

Ich finde es toll wenn Leute sich engagieren und etwas dabei herauskommt! Wenn
ich mich auf Freetz bezogen habe dann um deutlich zu machen daß ich mir Gedanken
gemacht hatte, aber nicht weiterkam. Bei Interessengemeinschaften ist es wie in
der Politik: Streitigkeiten nerven (amüsant allenfalls Eitelkeiten einzelner),
für Außenstehende interessant sind vor allem die Ergebnisse. Freetz bietet tolle
Möglichkeiten. Unreflektiert rumzumaulen ist nicht meine Art - ich wollte zu
Potte kommen, und bin es Dank Deiner erhellenden Angaben ja auch!

"tune2fs -l /dev/mmcblk0p2" auf der SDSDQXN-016G RasPi2B liefert 125 MB Lifetime
writes. Speicherkarten rangieren qualitativ im Mittelfeld (beste Flash-Zellen
landen in SSDs, die nicht so guten in USB-Sticks). Von Samsung riet man mir ab,
aber auch SanDisk-Modelle sind mir schon gestorben. Wäre erfreulich wenn Freetz'
zusätzliche Daten nicht den Strohhalm auf dem RasPi-µSD-Packesel spielen würden.

Auf http://linux-club.de/forum/viewtopic.php?t=90209 (10.7.17 Treffer 2 von 14
aus Google-Suche nach "'-bash: /dev/null: Keine Berechtigung'") Erläuterungen
zur erwähnten WVDial-Macke bei Neu-Einwahl, "chmod 666 /dev/null" setzt die
Berechtigungen zurück. Gleich als Cron-Job starten?

Hoffe niemanden mit meiner Detailversessenheit genervt zu haben,
viele Grüße Torsten



(+Freetz_r14702_FB7390_FW683_modules_in.txt 18024 Byte v. 5.6.18 6:40
+Freetz_r14702_FB7390_FW683_Build_Success.txt[a] 5269 Byte v. 5.6.18 6:56
+Freetz_r14702_FB7390_FW683_kernel-config_old.txt[2] 44740 Byte v. 5.6.18 7:28
+Freetz_r14702_FB7390_FW683_libmodmount_sh.txt 22767 Byte v. 5.6.18 11:15)

 

[MuP]

Der Name eines Threads läßt sich nachträglich nicht mehr ändern (oder doch?)

Die Option "Titel bearbeiten" ist in deinem Beitrag #1 verfügbar: kleines schwarzes Dreieck anklicken und auswählen

 

[stoney]

@TorstenEK bitte die Formartierung anpassen, das grenzt schon beinahe an Körperverletzung

https://www.ip-phone-forum.de/threads/freetz-r14702-fb-7390-build-frustrationen.299707/edit - erspart einen Klick/Tapp

Es könnte aber auch an Xenforo liegen und ich würde es weitergeben

 

[TorstenEK]

Hallo MuP, Stoney, Peter und alle anderen,

@MuP #16 v. 6.6.18 9:45:
nenne gerne einen Titel/ geeigneteres Subject, ich bin nicht sonderlich kreativ.

@stoney #17 v. 6.6.18 10:00:
in wieweit Formatierung ändern, gibt es Guidelines? Ich beschränke mich bewußt
auf 81 Zeichen breite Zeilen, damit der Inhalt auch in Textbrowsern vernünftig
angezeigt wird (überbreiter Text geht dort unter oder macht das Lesen durchs
hierfür nötige, ständige horizontale Scrollen zur Qual).

Inhaltlich habe ich mich bemüht eigene Beobachtungen ordentlich und korrekt
zusammenzutragen, an Nachricht #15 v. 6.6.18 7:43 saß ich recht lange.

Zu meinem Anliegen "Freetz zum Laufen [zu] bringen", und zu Peters Nachricht
#14 v. 4.6.18 16:25:

Miquel de Servantes Werk zählte nicht zu meinem Bildungskanon - eher schon
Alphonse Daudets "Tartarin de Tarascon", der Don Quichote und Sancho Pansa
in einer Person verkörpert - der Name ihres Reittiers sagte mir zunächst
überhaupt nichts. Einem Kampf gegen Windmühlenflügel ähneln meine Versuche
meine Versuche tatsächlich, oder einem Hamster im Laufrad (der hört auf wenn
er genug hat), ich wollte bereits am Freitag berichten, doch dann kam ein
Ruyard Kipling-Fan dazwischen ...

Ich habe etwas Zeit gebraucht um das Zusammenspiel von Freetz- und Kernel-
Konfigurationsdatei zu sichten. Wird letztere mittels "make kernel-menuconfig"
verändert und dabei gar Optionen aus der von Dir vorgeschlagenen Änderung an
./config/ui/modules.in gesetzt, so beklagt sich "make" mit der Meldung "You have
either updated to a newer svn version or changed one of the menuconfig files
manually since last modifying your config.". Einmaliger "make menuconfig"-Aufruf
und Abspeichern (ohne Optionsänderungen) ergänzt .config um die Zeile
"FREETZ_MODULE_jfs is not set", mit der "make" durchläuft (hier ohne JFS-Modul).
Die Skripte führen offensichtlich eine Konsistenzprüfung durch - gegessen.

Eine echte Nuß die Eigenschaften der AVM-Firmwareversionen ab 6.50. Der FTP-
Dienst zu ftp://service.avm.de/Downgrade/ ist abgeschaltet, unklar wann (HTTP-
Dummyseite weiterhin online, http://currentlydown.com/service.avm.de ohne FTP-
Historie), aber ohne Belang, FRITZ.Box_Fon_WLAN_7390.AnnexB.84.06.23.image ist
auf einem netten Server weiterhin verfügbar. Zuvor mittels FREETZ_FWMOD_SIGN=y
und FREETZ_FWMOD_SIGN_PRIVATE_KEY_PASSWORD=<secret> ("Setting this option will
sign the image with previously created .freetz.image_signing.* private key files
in the user's home directory." oder so ähnlich als Menü-Hilfetext, was passiert
findet man auch durch Probieren heraus) entsprechenden Code erzeugt.

Doch leider verweigert die aktuell laufende F/W 84.06.83 jegliches Downgrade,
FRITZ.Box_Fon_WLAN_7390.84.06.04.image wird abgelehnt, der Weg zu "AVM only" als
Einbahnstraße abgesichert, wie hintereinandergeschaltete Venenklappen, oder die
einwärts gerichteten Zähne einer Schlange, die keinen Schritt zurück erlauben.
Auf http://www.freetz.org/wiki/help/howtos/development/sign_image Stand 21.2.17
und
https://www.ip-phone-forum.de/threa...ntlich-das-signieren-der-avm-firmware.286213/
bis 20.7.16 habe ich dazu nichts entdeckt. Vielleicht verstehe ich das Procedere
aber falsch und Downgrades laufen stattdessen übers Wiederherstellungsprogramm,
hier beispielsweise ein fritz.box_fon_wlan_7390.annexb.06.20.recover-image.exe,
um der Box älteren Code quasi aufzudrängen, schlimmstenfalls nach einem bewußt
hervorgerufenen Prüfsummen-Fehler? Bislang liegt mir nur das Recover-Image zur
F/W 84.06.83 vor, und ich habe es noch nicht getestet (Windows selten genutzt).

Viele Grüße Torsten

 

[PeterPawn]

Bei der 7390 kann man das System direkt in die MTD-Partitionen schreiben lassen vom Bootloader ... da braucht man weder Recovery und Downgrade, noch das Starten aus dem Speicher (obwohl es bei der 7390 auch funktioniert, selbst wenn sich da die Firmware nicht automatisch selbst installiert).

Es gibt also nur wenig Grund, da auf signierte Images zurückzugreifen ... es sei denn, man möchte es (ab dem zweiten Image) dann bequemer haben und nicht mehr über den Bootloader, sondern über's AVM-GUI installieren.

Man kann also jedes eigene Image immer direkt über den Bootloader installieren (lassen) und muß (weder hier bei der 7390, noch sonst irgendwo bei einer (verbreiteten) FRITZ!Box) gar nicht über Recovery, Downgrade und alte AVM-Firmware samt der Frage, woher man die nun bekommen soll, nachdenken.

 

[TorstenEK]

Danke für die prompte Antwort, Peter!

Ich habe mir unter http://www.freetz.org/wiki/help die historische Entwicklung
von Bootloadern und Partitionierungsschemata zu Gemüte geführt, da mir Begriffe
wie MTD und Loader herzlich wenig sagten (mit TI-Signalprozessoren letztmals in
den Neunzigern im Zusammenhang mit Analogmodems hantiert).
Angeführte Beispiele beziehen sich oft auf Shell-Befehle ... ich kann derzeit
aber ausschließlich via FTP oder eben HTTP auf die Fritz!Box 7390 zugreifen;
Befehle wie "quote MEDIA FLSH" kapiert der darauf laufende FTP-Server nicht.

Das erzeugte Image im FTP-Home-Verzeichnis abzulegen und die Box neu zu starten
bringt nichts. Bei Settop-Boxen müssen Firmware-Updates auf einem dafür
angesteckten USB-Stick manchmal in speziell bezeichneten Verzeichnissen abgelegt
werden. Gibt es bei Fritz!OS einen analogen Verzeichnisnamen, der beim Start
nach zu installierendem Code abgeklappert wird?

Oder bietet einer der bis heute verfügbaren FTP-Befehle etwas adäquates (?):
root@BS2:/ # ncftp fritz.box
NcFTP 3.2.5 (Feb 02, 2011) by Mike Gleason (http://www.NcFTP.com/contact/).
Connecting to fritz.box...

FRITZ!BoxFonWLAN7390 FTP server ready.
Logging in...
User @SkipAuthFromHomenetwork logged in.
Logged in to fritz.box.
ncftp / > rhelp
The following commands are recognized (* =>'s unimplemented).
USER PORT STOR MSAM* RNTO NLST MKD CDUP EPRT
PASS PASV APPE MRSQ* ABOR SITE XMKD XCUP FEAT
ACCT* TYPE MLFL* MRCP* DELE SYST RMD STOU OPTS
SMNT* STRU MAIL* ALLO CWD STAT XRMD SIZE AUTH
REIN* MODE MSND* REST XCWD HELP PWD MDTM PBSZ
QUIT RETR MSOM* RNFR LIST NOOP XPWD EPSV PROT
Direct comments to [email protected].

Danke für Hinweise (bzw. Link zu Infos), wie ich anderweitig mit dem
(vermutlich EVA-) Bootloader der Fritz!Box 7390 in Kontakt treten könnte.

Viele Grüße Torsten