.titleBar { margin-bottom: 5px!important; }

Freetz r14702 FB 7390 Build-Frustrationen

Dieses Thema im Forum "Freetz" wurde erstellt von TorstenEK, 28 Mai 2018.

  1. TorstenEK

    TorstenEK Neuer User

    Registriert seit:
    27 Mai 2018
    Beiträge:
    13
    Zustimmungen:
    0
    Punkte für Erfolge:
    1
    #1 TorstenEK, 28 Mai 2018
    Zuletzt bearbeitet: 28 Mai 2018
    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
     

    Anhänge:

  2. f666

    f666 Neuer User

    Registriert seit:
    6 Apr. 2016
    Beiträge:
    182
    Zustimmungen:
    20
    Punkte für Erfolge:
    18
    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.
     
  3. tuxedonet

    tuxedonet Neuer User

    Registriert seit:
    20 Sep. 2015
    Beiträge:
    108
    Zustimmungen:
    3
    Punkte für Erfolge:
    18
    #3 tuxedonet, 28 Mai 2018
    Zuletzt bearbeitet: 28 Mai 2018
    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)


    @TorstenEK:
    Checkbefehl für Raspberry, um zu prüfen, ob die richtigen Optionen im Freetz gesetzt sind:
    Code:
    grep -E 'FREETZ_DOWNLOAD_TOOLCHAIN|FREETZ_BUILD_TOOLCHAIN' .config 
     
  4. TorstenEK

    TorstenEK Neuer User

    Registriert seit:
    27 Mai 2018
    Beiträge:
    13
    Zustimmungen:
    0
    Punkte für Erfolge:
    1
    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
     
  5. PeterPawn

    PeterPawn IPPF-Urgestein

    Registriert seit:
    10 Mai 2006
    Beiträge:
    11,071
    Zustimmungen:
    526
    Punkte für Erfolge:
    113
    Beruf:
    IT-Freelancer
    Ort:
    Berlin
    #5 PeterPawn, 30 Mai 2018
    Zuletzt bearbeitet: 31 Mai 2018
    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:
    Code:
    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.
     
  6. TorstenEK

    TorstenEK Neuer User

    Registriert seit:
    27 Mai 2018
    Beiträge:
    13
    Zustimmungen:
    0
    Punkte für Erfolge:
    1
    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
     
  7. PeterPawn

    PeterPawn IPPF-Urgestein

    Registriert seit:
    10 Mai 2006
    Beiträge:
    11,071
    Zustimmungen:
    526
    Punkte für Erfolge:
    113
    Beruf:
    IT-Freelancer
    Ort:
    Berlin
    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 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.
     
  8. TorstenEK

    TorstenEK Neuer User

    Registriert seit:
    27 Mai 2018
    Beiträge:
    13
    Zustimmungen:
    0
    Punkte für Erfolge:
    1
    #8 TorstenEK, 31 Mai 2018
    Zuletzt bearbeitet: 31 Mai 2018
    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
     

    Anhänge:

  9. TorstenEK

    TorstenEK Neuer User

    Registriert seit:
    27 Mai 2018
    Beiträge:
    13
    Zustimmungen:
    0
    Punkte für Erfolge:
    1
    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)
     

    Anhänge:

  10. PeterPawn

    PeterPawn IPPF-Urgestein

    Registriert seit:
    10 Mai 2006
    Beiträge:
    11,071
    Zustimmungen:
    526
    Punkte für Erfolge:
    113
    Beruf:
    IT-Freelancer
    Ort:
    Berlin
    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.
     
  11. TorstenEK

    TorstenEK Neuer User

    Registriert seit:
    27 Mai 2018
    Beiträge:
    13
    Zustimmungen:
    0
    Punkte für Erfolge:
    1
    #11 TorstenEK, 2 Juni 2018
    Zuletzt bearbeitet: 2 Juni 2018
    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)
     

    Anhänge:

  12. PeterPawn

    PeterPawn IPPF-Urgestein

    Registriert seit:
    10 Mai 2006
    Beiträge:
    11,071
    Zustimmungen:
    526
    Punkte für Erfolge:
    113
    Beruf:
    IT-Freelancer
    Ort:
    Berlin
    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:
    Code:
    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):
    Code:
    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 ...
     
  13. TorstenEK

    TorstenEK Neuer User

    Registriert seit:
    27 Mai 2018
    Beiträge:
    13
    Zustimmungen:
    0
    Punkte für Erfolge:
    1
    #13 TorstenEK, 4 Juni 2018
    Zuletzt bearbeitet: 4 Juni 2018
    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:cool: 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)
     

    Anhänge:

  14. PeterPawn

    PeterPawn IPPF-Urgestein

    Registriert seit:
    10 Mai 2006
    Beiträge:
    11,071
    Zustimmungen:
    526
    Punkte für Erfolge:
    113
    Beruf:
    IT-Freelancer
    Ort:
    Berlin
    #14 PeterPawn, 4 Juni 2018
    Zuletzt bearbeitet: 4 Juni 2018
    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:
    Code:
    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.
     
  15. TorstenEK

    TorstenEK Neuer User

    Registriert seit:
    27 Mai 2018
    Beiträge:
    13
    Zustimmungen:
    0
    Punkte für Erfolge:
    1
    #15 TorstenEK, 6 Juni 2018
    Zuletzt bearbeitet: 6 Juni 2018
    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)
     

    Anhänge:

  16. MuP

    MuP IPPF-Urgestein

    Registriert seit:
    27 März 2009
    Beiträge:
    11,748
    Zustimmungen:
    448
    Punkte für Erfolge:
    83
    Ort:
    §9 Satz 1 AO
    Die Option "Titel bearbeiten" ist in deinem Beitrag #1 verfügbar: kleines schwarzes Dreieck anklicken und auswählen ;)

    201806060942.PNG
     
  17. stoney

    stoney Moderator
    Forum-Mitarbeiter

    Registriert seit:
    7 Okt. 2015
    Beiträge:
    3,616
    Zustimmungen:
    226
    Punkte für Erfolge:
    63
    Ort:
    Bayern
  18. TorstenEK

    TorstenEK Neuer User

    Registriert seit:
    27 Mai 2018
    Beiträge:
    13
    Zustimmungen:
    0
    Punkte für Erfolge:
    1
    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
     
  19. PeterPawn

    PeterPawn IPPF-Urgestein

    Registriert seit:
    10 Mai 2006
    Beiträge:
    11,071
    Zustimmungen:
    526
    Punkte für Erfolge:
    113
    Beruf:
    IT-Freelancer
    Ort:
    Berlin
    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.
     
  20. TorstenEK

    TorstenEK Neuer User

    Registriert seit:
    27 Mai 2018
    Beiträge:
    13
    Zustimmungen:
    0
    Punkte für Erfolge:
    1
    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 support@avm.de.

    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