Tatsächlich hatte ich am 12.04.2021 mal eine Änderung dafür angefangen (ab 07.24 teilt sich der Pfad), die aber offenbar irgendwie aus den Augen verloren. Ich vermute mal, daß etwas Wichtiges dazwischen kam und das so lange brauchte, bis ich diese begonnene Änderung (es soll(te) zwei unterschiedliche Dateien zum Implementieren dieser Modifikation geben - im "beta"-Branch gibt es seitdem schon die ersten Commits) einfach aus dem Gedächtnis gestrichen hatte.
ja stimmt bei der 7.21 funktionierte es noch. ab 7.24 beta nicht mehr. die anderen Updates bis 7.28 hatte ich ausgelassen.
Genau. Denn ich konnte mir nicht vorstellen dass da von der 7.28 zur 7.29 etwas geändert wurde.
Danke für die Info.
mkdir -p /var/mod;cd /var/mod;wget -qO- https://yourfritz.de/modfs-0.6.4-beta.tgz | gunzip -c | tar x ; ./modfs updateÜberprüfen der Signatur der geladenen Datei ... OK
Überprüfen, ob die Datei '/var/media/ftp/Storage-01/FRITZ.Box_7490-07.29.image' ein Firmware-Image enthält ... OK
Extrahieren des root-Dateisystems aus dem Firmware-Image ... OK
Prüfen der Firmware-Version des root-Dateisystems in '/var/tmp/1641996061/filesystem_core.squashfs' ... Fehler
Die Version der gefundenen Datei '/var/tmp/1641996061/filesystem_core.squashfs' paßt nicht zum installierten System.
Bitte den Dateinamen des Images - entweder ein komplettes Firmware-Image (im tar-Format) oderSSLRequireSSL zuviel in der Verzeichnisdefinition für den HTTP-Server (denn die RewriteRules für die automatische HTTPS-Redirection hatte ich genau geprüft).modfs update die aktuelle Version nicht findet, kann ich ohne Protokoll auch nicht sagen - das funktioniert nun wieder bei mir einwandfrei, wobei die "Start-Version" auch eine unterhalb von 07.29 ist:/var/media/ftp/YourFritz/modfs/bin/scripts # ./juis_check -l
juis_check: Found newer version: 113.07.29
URL=http://download.avm.de/fritzbox/fritzbox-7490/deutschland/fritz.os/FRITZ.Box_7490-07.29.image
/var/media/ftp/YourFritz/modfs/bin/scripts #-c funktioniert bei mir ... dabei wird die Versionsnummer auf 113.07.28-00000 herunter geschraubt, um auch die gerade aktuellen Versionen zu finden (wenn es ansonsten eben kein "Update" gäbe) - auch das gibt (ausgehend von der Version 113.07.29-92201) die korrekte URL für die 07.29 der 7490:/var/media/ftp/YourFritz/modfs/bin/scripts # ./juis_check -d -l -c Version=113.07.29-92201
debug: Setting 'Version' to '113.07.29-92201' from command line parameter
debug: Reading values from local file '/var/juis_boxinfo.xml'.
debug: Splitting compound version number '113.07.29-92201' to:
debug: Major=113
debug: Minor=07
debug: Patch=29
debug: Buildnumber=92201
debug: Just decremented the version number to get an answer with URL for current version.
debug: Compound version number used for request: '113.07.28-00000'
debug: -------------------------------------------------------
debug: Variables set:
debug: -------------------------------------------------------
debug: Name="FRITZ!Box 7490 (UI)"
debug: HW="185"
debug: OEM="1und1"
debug: Lang="de"
debug: Annex="B"
debug: Country="049"
debug: Serial="0896D7DAC6F2"
debug: Major="113"
debug: Minor="7"
debug: Patch="28"
debug: Buildnumber="00000"
debug: Flag="remote_login_service medium_lan mesh_master_no_trusted"
debug: Public="1"
debug: type="1001"
debug: hostname="185.jws.avm.de"
debug: nonce="MTY6NTg6NTkwMS8xMi8yMg=="
debug: -------------------------------------------------------
debug: Sent request:
debug: -------------------------------------------------------
POST /Jason/UpdateInfoService HTTP/1.1
Host: 185.jws.avm.de:80
Content-Length: 1261
Content-Type: text/xml; charset="utf-8"
Connection: close
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/" xmlns:soap-enc="http://schemas.xmlsoap.org/soap/encoding/" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:e="http://juis.avm.de/updateinfo" xmlns:q="http://juis.avm.de/request">
<soap:Header/>
<soap:Body>
<e:BoxFirmwareUpdateCheck>
<e:RequestHeader>
<q:Nonce>MTY6NTg6NTkwMS8xMi8yMg==</q:Nonce>
<q:UserAgent>Box</q:UserAgent>
<q:ManualRequest>true</q:ManualRequest>
</e:RequestHeader>
<e:BoxInfo>
<q:Name>FRITZ!Box 7490 (UI)</q:Name>
<q:HW>185</q:HW>
<q:Major>113</q:Major>
<q:Minor>7</q:Minor>
<q:Patch>28</q:Patch>
<q:Buildnumber>00000</q:Buildnumber>
<q:Buildtype>1001</q:Buildtype>
<q:Serial>0896D7DAC6F2</q:Serial>
<q:OEM>1und1</q:OEM>
<q:Lang>de</q:Lang>
<q:Country>049</q:Country>
<q:Annex>B</q:Annex>
<q:Flag>remote_login_service</q:Flag><q:Flag>medium_lan</q:Flag><q:Flag>mesh_master_no_trusted</q:Flag>
<q:UpdateConfig>1</q:UpdateConfig>
<q:Provider>oma_lan</q:Provider>
</e:BoxInfo>
</e:BoxFirmwareUpdateCheck>
</soap:Body>
</soap:Envelope>
debug: -------------------------------------------------------
debug: Reading response from '185.jws.avm.de:80': .
debug: Received response:
debug: -------------------------------------------------------
HTTP/1.1 200 OK
download-delay: 5813
content-type: text/xml;charset=UTF-8
content-length: 2178
date: Wed, 12 Jan 2022 15:58:59 GMT
access-control-allow-origin: http://scope.avm.de
access-control-allow-headers: content-type
connection: close
<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"><SOAP-ENV:Header xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"/><soap:Body ID="Body"><ns2:BoxFirmwareUpdateCheckResponse xmlns:ns2="http://juis.avm.de/updateinfo" xmlns:ns3="http://juis.avm.de/response" xmlns:ns4="http://juis.avm.de/request"><ns2:ResponseUpdateInfo><ns3:ResponseHeader><ns3:Nonce>MTY6NTg6NTkwMS8xMi8yMg==</ns3:Nonce></ns3:ResponseHeader><ns3:UpdateInfo><ns3:CheckInterval>24</ns3:CheckInterval><ns3:Found>true</ns3:Found><ns3:Name>EXTERN RELEASE PSQ19 Phase2 NL4 deutsche info.txt</ns3:Name><ns3:Version>113.07.29</ns3:Version><ns3:Type>1</ns3:Type><ns3:DownloadURL>http://download.avm.de/fritzbox/fritzbox-7490/deutschland/fritz.os/FRITZ.Box_7490-07.29.image</ns3:DownloadURL><ns3:InfoURL>http://download.avm.de/fritzbox/fritzbox-7490/deutschland/fritz.os/info_de.txt</ns3:InfoURL><ns3:InfoText>RELEASE</ns3:InfoText><ns3:HintURL></ns3:HintURL><ns3:IconURL></ns3:IconURL><ns3:Priority>1</ns3:Priority><ns3:AutoUpdateStartTime>1800</ns3:AutoUpdateStartTime><ns3:AutoUpdateEndTime>16200</ns3:AutoUpdateEndTime><ns3:AutoUpdateKeepServices>true</ns3:AutoUpdateKeepServices></ns3:UpdateInfo></ns2:ResponseUpdateInfo></ns2:BoxFirmwareUpdateCheckResponse><Signature xmlns="http://www.w3.org/2000/09/xmldsig#"><SignedInfo><CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/><SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/><Reference URI="#Body"><Transforms><Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/></Transforms><DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/><DigestValue>mOY96JGBKSqk0ru8muFeufbbsD2rZ3qawLmtAD1vtbo=</DigestValue></Reference></SignedInfo><SignatureValue>ZIHRijS0ZcPw1fmULnzdZH2EI6NA7OvU6PSh6FnTr8YmNl7B5vJon46ibCb6wiSTTmxN65zTVian4qQY0EIDIGxSpYV2pZ5HYmhT8f40eRWGzjdYhLky9u4+gBHR+2N7GZrod/0r9jWXlATrL3vjXCmbstU15KGqZTdFiDwwnw3f1IQKY6hk3XcA+WCMXFJFzKVOc1AhtcJxW2C7m8hbB0OwSAL0Geet0vismFY3lIuYihuJTt27I6H6HamFT6nVZ+T6k/FyP4ffcdTFCHWBz3Wm3+3wxNlyjSJD5wy9IF+nag5yDyCa5mxaWCoIrAHWl8a+wF0vMfT26tCGF3idsw==</SignatureValue></Signature></soap:Body></soap:Envelope>
debug: -------------------------------------------------------
juis_check: Found newer version: 113.07.29
URL=http://download.avm.de/fritzbox/fritzbox-7490/deutschland/fritz.os/FRITZ.Box_7490-07.29.image
/var/media/ftp/YourFritz/modfs/bin/scripts #modfs eine neuere Version installieren lassen will, muß man immer noch (aus dem Gedächtnis, ich will jetzt nicht nachsehen - daher bitte selbst noch an den richtigen Stellen einmal prüfen) den update-Parameter zwischen modfs und dem Dateinamen angeben - ansonsten wird in der angegebenen Image-Datei eine Version erwartet, die zur aktuell installierten paßt.# cd bin/scripts
# ./juis_check -l
juis_check: Missing a required command: nc.
# nc
-sh: nc: not foundjuis_check im Rahmen von modfs aufgerufen wird, ist die BusyBox-Version aus dem modfs-Paket aktiv - und darin ist auch das nc-Applet vorhanden. Ruft man das also außerhalb von modfs und auf einem System ohne passende BusyBox auf, muß man erst mal dafür sorgen, daß tatsächlich die passende BusyBox als "Grundlage" für die Shell-Benutzung verwendet wird. Dazu muß man nur einmal busybox sh (mit dem passenden Pfad zur richtigen BusyBox, eine davon findet man auch in der modfs-Struktur) aufrufen - danach sollte der Rest immer zuerst nach einem passenden BusyBox-Applet suchen, weil die von mir bereitgestellte BusyBox-Version dahingehend konfiguriert wurde.modfs-Versuchs bereitstellen und wenn sich dabei dann herausstellen sollte, daß da tatsächlich ein systematischer Fehler existiert, dann kann man immer noch nach Einzelheiten schauen. Denn da diese Suche nach der aktuellen Firmware internet-basiert erfolgt, kann schon ein temporäres Problem die Ursache des vergangenen Mißerfolgs sein und dann sucht man sich - wenn man's nicht mind. 2x mit entsprechendem zeitlichen Abstand probiert hat - vollkommen umsonst einen Wolf.modfs update <image_filename> sollte ohnehin funktionieren - bei diesem (dritten) Problem würde ich im Moment noch eher auf einen Fehler beim Aufruf tippen ... aber auch das läßt sich mit dem Debug-Protokoll dann relativ schnell klären, denn das ist nun wirklich sehr, sehr ausführlich und am ehesten geeignet, den "flow of execution" durch das Skript zu verfolgen.modfs update <image_filename> klappt wirklich...das Update auf 7.29 hat funktioniert. Leider hab ich aus Versehen den Bootloader Switch nicht aktiviert und kam nicht mehr so einfach zu 7.28 zurück. Auf die FTP-Prozedur hatte ich keine Lust und hab anhand Deiner Sourcen gesucht, wie man das im laufenden Betrieb umschalten kann. Hab dann den gui_bootmanager gefunden, aufgerufen und damit ging es.update ohne einen weiteren Parameter genutzt.gui_bootmanager benutzen konnte. Im letzteren Fall hätte ich niemals geglaubt, dass man ein 85kB Bash-Skript benötigt, um das laufende System umzuschalten. Ja, ich weiß, das macht auch noch eine ganze Menge anderer Sachen.
juis_check (https://github.com/PeterPawn/YourFritz/commit/049839bdf5811ed0c7d9b3036249c12a294ecffe) auch in das modfs-Repository zu übernehmen (das habe ich jetzt nachgeholt) und seit der eigenen, internen Änderung zur Erkennung von Versionen anhand von Buildtype scheint AVM stärker auf Abhängigkeit der JUIS-Antworten von dieser Variablen zu setzen.modfs-Archiv neu laden, es reicht auch ein wget https://raw.githubusercontent.com/PeterPawn/YourFritz/main/juis/juis_check (im passenden Verzeichnis <modfs>/bin/scripts und mit einem wget, das auch HTTPS beherrscht - was die BB von AVM nicht kann), um das Skript in der entpackten Struktur zu ersetzen (ggf. noch ausführbar machen mit chmod).Buildtype=1 kommt - zumindest klappt das bei mir von Hand. Das Problem scheint auch erst seit der 07.25-Release aufzutreten ... in ebendieser hat AVM ja auch die Erkennung/Unterscheidung der Versionen anhand von CONFIG_BUILDTYPE komplett durchgezogen und wenn da heutzutage dieser Wert nicht stimmt (was die alte juis_check-Version stumpf aus der aktiven Firmware ausliest), gibt es offensichtlich keine Update-Antwort (zumindest keine mit einer neuen URL) mehr vom JUIS.juis_check nett - die Parameter sind in der Hilfe-Anzeige (juis_check -h) erklärt.Danke für die Anerkennung.
Braucht man ja auch nicht wirklich - das ist nur erforderlich, um das (a) wartbar zu halten und (b) damit einen bunten Strauß an FRITZ!Box-Modellen zu unterstützen, die intern alle einen etwas unterschiedlichen Aufbau haben ... das Skript muß also manches mehrfach implementieren, jeweils unter Berücksichtigung der Spezifika eines Modells (bzw. einer SoC-Reihe). Und das ist ja dann auch noch nicht alles - die Integration ins GUI (speziell die Nachrichten-"Fetzen", aus denen die Anzeigen zusammengesetzt werden) braucht noch Lua- und JS-Code und auch da hat sich noch so manches (bei AVM) geändert, so daß es weitere "Weichen" gibt, je nachdem, ob da nun eine ältere oder eine neuere AVM-Version vorliegt.
nicht. Das stand auch schon auf Deiner github-Page. Warum kann ich das mit der original Firmware herunterladen? In der Version 7.28 wird halt nur eine NOTE ausgegeben...mehr aber auch nicht. Oder habe ich im PATH ein eigenes wget liegen? Könnte möglich sein...aber dann würde die NOTE ja nicht erscheinen. Hmm...
https://yourfritz.de/modfs-0.6.4-beta.tgz ein "automatischer Prozess" von github oder hast Du das manuell zusammengepackt? Dort war die aktualisierte Datei juis_check nämlich noch nicht drin. Teilweise leitest Du ja von Deiner Domain auf github weiter. Deswegen meine Frage.
modfs-Repo).wget bei AVM kein HTTPS unterstützt, hat sich tatsächlich in manchen Konstellationen überlebt - zumindest seit 07.20 nutzt auch AVM eine neuere BusyBox-Version und offenbar hat man dort dann mittlerweile auch die Option CONFIG_FEATURE_WGET_HTTPS für die BusyBox ausgewählt. Da aber gleichzeitig auch CONFIG_FEATURE_WGET_OPENSSL gesetzt wurde/wird, funktioniert(e) das normalerweise in AVM-Versionen auch nicht, weil das dann verwendete Binary openssl wieder nicht vorhanden ist in der AVM-Firmware (https://git.busybox.net/busybox/tree/networking/wget.c#n104) ... so jedenfalls meine bisherigen Erfahrungen.wget bei HTTPS-Downloads das eigene Programm httpsdl - das wurde auch in einer der letzten Versionen noch etwas aufgebohrt, so daß man damit (neben der Upload-Option, die das wget auch nicht bietet - jedenfalls nicht genauso, wie httpsdl) mittlerweile auch HTTPS-URLs abrufen kann - jedenfalls solange dabei keine Redirections auftreten.httpsdl auch heute noch nicht richtig umgehen:~ # wget -q -O - https://github.com/PeterPawn/YourFritz/archive/refs/heads/main.zip | unzip -q -l - | wc -l
335
~ # httpsdl -n -O - https://github.com/PeterPawn/YourFritz/archive/refs/heads/main.zip
failed
~ # httpsdl -n -O - https://codeload.github.com/PeterPawn/YourFritz/zip/refs/heads/main | unzip -l - | wc -l
336
~ #httpsdl von AVM klappt der Download also nur dann, wenn man als URL die tatsächlich finale Adresse verwendet, so daß keine weiteren Redirections erforderlich sind.modfs propagiere bzw. favorisiere - denn der Download über "reines HTTP" war eben nur ein Workaround, weil selbst der Weg über das httpsdl von AVM erst funktioniert, seitdem das Programm von AVM noch einmal geändert wurde. Heute wäre jedenfalls folgendes "richtig" als Download für das modfs-Paket:~ # cd /var/media/ftp
/var/media/ftp # httpsdl -n -O - https://codeload.github.com/PeterPawn/modfs/zip/refs/heads/master | unzip -o -q -
ok
/var/media/ftp # ls -l modfs-master/
-rw-r--r-- 1 root root 11081 Jan 13 22:29 BOOTSELECTION.ger
-rw-r--r-- 1 root root 18092 Jan 13 22:29 LICENSE
-rw-r--r-- 1 root root 1166 Jan 13 22:29 README.md
drwxrwxrwx 1 root root 2048 Jan 13 22:29 bin
drwxrwxrwx 1 root root 2048 Jan 13 22:29 contrib
drwxrwxrwx 1 root root 2048 Jan 13 22:29 files
drwxrwxrwx 1 root root 2048 Jan 13 22:29 locale
-rw-r--r-- 1 root root 107531 Jan 13 22:30 modfs
-rw-r--r-- 1 root root 982 Jan 13 22:30 modnow.sh
drwxrwxrwx 1 root root 2048 Jan 13 22:29 modscripts
-rw-r--r-- 1 root root 4302 Jan 13 22:30 run_modscripts
-rw-r--r-- 1 root root 2494 Jan 13 22:30 set_correct_flags.sh
/var/media/ftp # httpsdl -n -O - https://codeload.github.com/PeterPawn/modfs/zip/refs/heads/beta | unzip -o -q -
ok
/var/media/ftp # ls -l modfs-beta/
-rw-r--r-- 1 root root 11081 Jan 13 22:32 BOOTSELECTION.ger
-rw-r--r-- 1 root root 18092 Jan 13 22:32 LICENSE
-rw-r--r-- 1 root root 1166 Jan 13 22:32 README.md
drwxrwxrwx 1 root root 2048 Jan 13 22:32 bin
drwxrwxrwx 1 root root 2048 Jan 13 22:32 contrib
drwxrwxrwx 1 root root 2048 Jan 13 22:32 files
drwxrwxrwx 1 root root 2048 Jan 13 22:32 locale
-rw-r--r-- 1 root root 107536 Jan 13 22:32 modfs
-rw-r--r-- 1 root root 982 Jan 13 22:32 modnow.sh
drwxrwxrwx 1 root root 2048 Jan 13 22:32 modscripts
-rw-r--r-- 1 root root 4307 Jan 13 22:32 run_modscripts
-rw-r--r-- 1 root root 2494 Jan 13 22:32 set_correct_flags.sh
/var/media/ftp #master- ODER den beta-Branch braucht.yourfritz.de betrifft, wird automatisch auf die Startseite im YourFritz-Repository bei GitHub umgeleitet. Die gepackten Archiv-Dateien auf meinem eigenen Server haben (zumindest für mich) nur noch untergeordnete Bedeutung - in meinen Beispielen verwende ich inzwischen generell Checkouts bei GitHub, auch weil die VR9-Boxen ja die einzigen sind, wo das direkt auf der Box und nicht auf einem "richtigen Linux" verwendet werden kann - und selbst für die Boxen ist der Download von GitHub inzwischen machbar (s.o.), so daß diese Archiv-Dateien nur ein - mittlerweile praktisch unnützer - Zwischenschritt sind. modfs von ihrer Box aus zugreifen können. Da spielt das Alter dann auch keine Rolle mehr, weil diese alten Versionen ja auch mit den alten FRITZ!OS-Versionen zusammenpassen.
modfs-Repos und Umschalten auf den beta-Branch (empfohlen außerhalb vom FRITZ!OS, wenn git verfügbar ist - Beispiele dafür gibt es mittlerweile genug)httpsdl -n -O - https://codeload.github.com/PeterPawn/modfs/zip/refs/heads/beta | unzip -o -q -wget für HTTPS nicht nutzbar ist, ansonsten (und auf anderen Systemen, wo wget verfügbar wäre) könnte das z.B. so aussehen:wget -q -O - https://github.com/PeterPawn/modfs/archive/refs/heads/beta.zip | busybox unzip -o -q -unzip-Applet der BusyBox verwendet wird, weil das dieselben Funktionen bietet, wie auf einer FRITZ!Box vorhanden wären. Die Dateien liegen dann in einem neu erstellten Unterverzeichnis modfs-beta im aktuellen Verzeichnis, das Unterverzeichnis muß vorher leer sein oder noch besser gar nicht erst existieren - vorhandene Dateien führen ggf. zu einem Fehler beim Entpacken.wget -O - http://yourfritz.de/modfs-0.7.0-beta.tgz | tar -xset_correct_flags.sh aufrufen, weil die Ergebnisse bei den execute-Flags (die zur Auswahl der zu verarbeitenden Modifikationen herangezogen werden) sehr durchwachsen sein können - je nachdem, was/wie da ein- und ausgepackt wurde. Da auch für dieses Skript u.U. keine execute-Flags gesetzt sein könnten, empfiehlt sich der Aufruf mit direkter Angabe der Shell: sh ./set_correct_flags.sh - bei der Verwendung von run_modscripts anstelle von modfs spielen diese Flags aber keine Rolle.gui_boot_manager_v0.7 umbenannt (vorher hieß es ...v0.6)telefon-Daemon (CONFIG_BUILDTYPE=998) wurde übernommen.modfs-Skript selbst wurde an die Änderungen beim Boot-Manager angepaßt (nach der Installation des geänderten Images und bei der Umschaltung wird der Boot-Manager informiert).modfs bieten jetzt neben den Ja-/Nein-Antworten auch die Möglichkeit, die Verarbeitung bei jeder dieser Nachfragen sauber zu beenden (durch ein a - für "abbrechen" - als Eingabe bei deutschen Texten).custom_modscripts im Basisverzeichnis von modfs funktionierte nicht mehr richtig, das wurde korrigiert. Dateinamen in dieser Datei sind immer relativ zum Basisverzeichnis und nicht zum Unterverzeichnis modscripts.mod_show_vpn_on_overview_pre0724 soll die "kondensierte" Anzeige der VPN-Verbindungen für Versionen < 07.24 bereitstellen, das funktioniert jedoch derzeit noch nicht - deshalb ist dieses Skript auch standardmäßig deaktiviert ... vermutlich würde seine Verwendung große Probleme bereiten. Für Versionen ab 07.24 gibt es noch kein passendes "modscript" für diese Modifikation.mod_squashfs_mount wird zwar i.d.R. nach mod_exec_on_usb ausgeführt (die Ausführung erfolgt ja in aufsteigender Sortierung nach Namen), verwendet aber ebenfalls eine exec-Option für den Mountpoint, wenn mod_exec_on_usb ausgewählt/eingebaut wurde.modfs auf einer FRITZ!Box der Hauptspeicher selbst bei den Modellen mit 512 MB schnell knapp wird (und AVM es ausgebaut hat), was nur mit Swap-Space zu entschärfen ist. Dabei würde ich dann immer auch den Einbau von mod_swapoff empfehlen, damit das Deaktivieren/Auswerfen eines USB-Gerätes über das AVM-GUI noch funktioniert. An einer weiteren Änderung, die auch ein Swap-File(!) mit vorgegebenem Namen beim Mounten eines USB-Volumes automatisch aktiviert, bin ich noch dran.
master-Branch übernommen und auch unter yourfritz.de/modfs.tar.gz bereitgestellt. Für die Optionen, diesen Stand zu laden, gelten analog die Ausführungen aus #1915 - beim Laden von GitHub ist dann jeweils beta durch master zu ersetzen.run_modscripts für das Modifizieren von Firmware auch außerhalb der VR9-Modelle verwenden, Probleme mit diesen Änderungen auftauchen, dann bitte hier oder im Thread zum Boot-Manager (https://www.ip-phone-forum.de/threa...assenden-fritz-box.307098/page-3#post-2467135) melden.juis_check aus YourFritz übernommenbootmanager (0.7.1) aus YourFritz übernommen, "modscript" dafür auch geändert, neuer Name: gui_boot_manager_v0.7CONFIG_RELEASE auf CONFIG_BUILDTYPE bei der Simulation des Build-Types für "private Erweiterungen" der AVM-Komponentenmodfs-Skript bei jeder Nachfrage auf der Konsolecustom_modscripts, das sollte wieder reibungslos funktionieren
gui_boot_manager_v0.7 wurde zwar nach inactive verschoben und könnte theoretisch auch wieder aktiviert werden, dann muß man aber parallel auch die von der vorhergehenden Version des Boot-Managers verwendeten Dateien erst wieder nach files schaffen. Die neue Version wird jedenfalls mit dem "modscript" gui_boot_manager_v0.8 eingebaut. Das Skript kümmert sich dabei auch darum, daß alle erforderlichen Dateien an der richtigen Stelle in der zu modifizierenden Dateisystem-Struktur landen und die AVM-Dateien passend geändert werden, sowie um die Bereitstellung des .service-Files für den supervisor von AVM.yf_custom_environment (einer zusätzlichen Methode, das Branding auch dann zu ändern, wenn der Bootloader das bei einem Modell NICHT persistent erlaubt) oder von YF_CHANGE_OEM (ein weiterer Ansatz, jenseits der Option mit einem "festen Branding" in der Zeile export OEM=<value> in der AVM-Datei rc.conf) gibt es noch kein fertiges "modscript" von mir - das kommt vielleicht (keine Garantie, weil's schwer zu verallgemeinern ist bei der Integration) zusammen mit oder nach der Erklärung zu den damit neu ermöglichten Optionen im Bootmanager-Thread.
mod_swap_fileswapfile auf einem gemounteten USB-Volume (read/write-Mounts natürlich nur) wird erst ein mkswap und dann ein swapon ausgeführt, damit reicht es mit dieser Modifikation auch aus, wenn man eine Datei mit der gewünschten Größe anlegt, bevor man den Datenträger an die Box steckt oder die Box startet.mkswap (das nur ein paar Strukturen einrichtet) erst noch mit Nullen aus /dev/zero zu überschreiben.hdparm) auslösen kann. trim-Kommandos unterstützt (was bei SSD's erwartbar ist, bei USB-Sticks aber eher selten anzutreffen wäre), ist das nur die Meldung an den Controller, daß der Inhalt dieser Speicherblöcke nicht länger relevant ist und notwendige Löschoperationen ausgeführt werden können, ohne auf den vorhandenen Inhalt Rücksicht zu nehmen ... Daten werden dadurch noch nicht gelöscht.cryptsetup-Kommando, denn bei vielen der neueren AVM-Modelle dürften die meisten anderen Module bereits in der Firmware vorhanden sein. Ich muß mal sehen, daß ich mich schlau mache, bei welchen AVM-Modellen welche Binaries oder LKMs noch fehlen - wenn das einigermaßen unkompliziert mit statischen Binaries über mehrere Modelle nachrüstbar ist (das heißt dann natürlich auch, daß keine LKM betroffen sein dürfen, denn die müssen zum konkreten Kernel passen), dann könnte man das auch wieder sicherer gestalten.httpsdl -n -O - https://codeload.github.com/PeterPawn/modfs/zip/refs/heads/beta | unzip -o -q -./set_correct_flags.shsh set_correct_flags.sh läuft durch.sh modfsnoexec gemountet, wenn man noch nichts dagegen unternommen hat. Daher bezieht sich meine "Anleitung" auch immer darauf (auch heute noch, obwohl der Platzbedarf immer größer wird), daß man das Ganze unterhalb von /var laufen läßt, wo Ausführen auch heute noch per se möglich ist.mount -o remount,exec /var/media/ftp und schon sollte das bei Dir funktionieren, wenn tatsächlich nur dieser Umstand die erfolgreiche Verwendung verhindert(e).
