Bootmanager und Inhaus 7.39

[fda77]

Mit den neuen FW läuft dein Boot Manager unter dem AVM Webinterface nicht mehr, die Seite bleibt einfach weiß.

https://www.ip-phone-forum.de/threads/311707/

[PeterPawn]

Bei Gelegenheit ... im Moment krankt es schon daran, daß ich keine Box habe, für die es diese Inhouse-Versionen bisher gibt. Ich kann also nicht einfach hingehen, das OS patchen lassen und dann nachsehen, wo es klemmt - ich müßte das alles durch Vergleich/Lesen der AVM-Änderungen in dieser Version versuchen zu erkennen und wäre dann immer noch auf Dritte als Tester angewiesen bei der Frage, ob das nun nach Änderungen wieder klappt oder nicht.

Das ist mir derzeit noch zu anstrengend - irgendwann wird AVM ja auch die Palette der Boxen mit einer 07.39 (ob als Inhouse oder Labor) erweitern und dann schlägt vielleicht auch meine Stunde.

[fda77]

Du wolltest doch eine Erinnerung als Issue. Ich hab auch kein Gerät für die Inhaus, wegen https://github.com/Freetz-NG/freetz-ng/commit/5fd4715bd721295142dd26b975689abb8a2ba656 und https://github.com/Freetz-NG/freetz-ng/commit/ccdf8e494ab8e4caa659a79911bdd3744f92c9d6 müsste das auch jemand richtig (am besten mit Console) testen

[PeterPawn]

Ich habe mich auch nicht darüber beschwert - ich versuch(t)e lediglich (für Dich und andere, die das lesen sollten) zu erklären, warum das - selbst wenn's nur eine Kleinigkeit sein sollte - nicht "im Handumdrehen" erledigt ist und derzeit nicht "ganz oben" auf meiner Liste steht.

[PeterPawn]

1. Versuch, das Problem zu fixen: https://github.com/PeterPawn/modfs/commit/bc369d9d6692b7a947d6880525d7cc203110b56e - ich kann es nicht selbst testen und warte jetzt, wie es ausgeht ... wenn sich jemand mit einer 7590 (AX) und der Verwendung von modfs findet.

Dafür jetzt einen Branch in diesem Repo aufzumachen (der dann auch noch mehrfach in Freetz-NG geändert werden müßte, wenn es das noch nicht war mit der Korrektur), ist mir zu anstrengend. Im oben verlinkten Thread habe ich auch etwas dazu geschrieben - das sollte auch mit dieser "verteilten Verarbeitung" zu einem Ergebnis kommen.

[fda77]

Der Branch ist freetz egal, zum testen reicht es den hash hier zu ändern: https://github.com/Freetz-NG/freetz-ng/blob/master/tools/make/yourfritz-host/yourfritz-host.mk#L1

[PeterPawn]

Ich KANN das aber nicht testen, selbst wenn ich das wollte (bzw. den Patch, der durch add_to_system_reboot.sh ausgeführt wird, HABE ich natürlich geprüft) - warum sollte ich also irgendetwas in Freetz-NG anpassen?

Mit dem, was ich eingecheckt und geschrieben habe, kann jetzt erst einmal ein Benutzer mit "modfs" testen, ob diese Version auch mit 07.39 funktioniert - das ist (schon durch die deutlich geringeren Änderungen ggü. der AVM-Version, im Vergleich zu Freetz-NG) die Option mit den geringsten (zu erwartenden) Nebenwirkungen.

Wenn sich ein Freetz-NG-Benutzer die Arbeit machen will, kann er Deiner Vorgehensweise aus dem vorstehenden Beitrag ja gerne folgen - "üblich" wäre es jetzt halt, am "Ursprung" der Datei (und das wäre das YourFritz-Repo) einen Branch mit diesen Änderungen aufzumachen und den könnte dann jemand zum Testen benutzen anstelle des Hauptzweigs. Genauso habe ich das jetzt in "modfs" gemacht, allerdings ohne parallel dazu noch einen weiteren Branch im YourFritz-Repo zu erstellen.

Wenn ich irgendwann mal weiß, daß die Änderungen komplett sind und funktionieren, DANN mache ich den Branch hier im YourFritz-Repo auf, nehme darin dann die Änderungen (ggf. erneut oder auch durch Übernahme des Patches aus "modfs") vor und mische diesen Branch dann in den Hauptzweig ... also ganz die "alte Schule", so wie man mit Git arbeiten sollte.

[fda77]

Vielleicht lies es sogar jemand ausser dir, dann wüsste man ob der Commit ausreicht

[PeterPawn]

Ja, vielleicht - vermutlich habe ich deshalb so "unauffällig" in zwei IPPF-Threads auf die Änderung hingewiesen.

Ich glaube ja an vieles ... aber nicht daran, daß eine Issue im YourFritz-Repository eine größere Reichweite habe könnte, als ein Beitrag im IPPF - denn das ist hier ja auch nicht Freetz-NG (wo sicherlich noch mehr Leute "lesen", selbst wenn das auch dort viel weniger sein werden, als in irgendwelchen BBS).

Und wenn Du etwas weniger "schreibfaul" wärst und Dir für Antworten wie hier: https://github.com/PeterPawn/YourFritz/issues/43#issuecomment-1005025610 auch mal mehr als einen (halben) Satz abringen könntest, gäbe es so manches Mißverständnis gar nicht erst.

Du mußt Dich nicht extra deshalb ganz kurz (und mißverständlich) ausdrücken, weil ich vielleicht zuviel schreibe (in Deinen Augen) - das ist kein Nullsummen-Spiel, wo meine Textlänge von Dir durch besonders kurze Fassungen ausgeglichen werden müßte.

[fda77]

Wenn ich alles geschrieben hab was ich denke was nötig ist höre ich einfach auf :)

[PeterPawn]

was ich denke was nötig ist

Vielleicht denkst Du dann ja auch zu oft nicht genug und siehst selbst gar nicht, wenn irgendwelche Aussagen noch jede Menge Raum für anderweitige Interpretationen und damit für weitere Mißverständnisse lassen? Soo schwer kann es eigentlich auch nicht sein, UNMISSVERSTÄNDLICH das zu schreiben, was man zum Ausdruck bringen wollte oder will. Ansonsten darf man sich eben auch nicht wundern, wenn man ständig "falsch verstanden" wird.

[PeterPawn]

@fda77: Wenn Du möchtest, kannst Du den aktuellen Stand aus dem main-Branch erst einmal in Freetz-NG übernehmen.

Ich habe allerdings auch das Skript zur Integration in die AVM-Dateien angepaßt - es braucht jetzt nicht mehr für jedes vorhandene Branding (was ja auch zu einem eigenen Unterverzeichnis in /usr/www/$OEM führt, auch wenn das in Freetz-NG nur noch Symlinks sind) gesondert aufgerufen zu werden - ohne Angabe von TARGET_BRANDING im Environment beim Aufruf von add_to_system_reboot.sh, werden einfach die vorhandenen Brandings selbst ermittelt und jedes davon einzeln gepatcht, während die Dateien, die alle Brandings gemeinsam nutzen, nur einmalig kopiert werden.

Ob das in Freetz-NG dann noch paßt, müßtest Du selbst entscheiden ... anstelle der Schleife hier: https://github.com/Freetz-NG/freetz-ng/blob/5c5a4d1d87ab8c9c6f121a13a8fc4f44c79700af/patches/scripts/800-modfs_boot_manager.sh#L6 braucht es eigentlich nur einen einzigen Aufruf und den dann ohne Angabe von TARGET_BRANDING. Ich gehe mal davon aus, daß das niemand ernsthaft nur für ein einzelnes Branding verwenden will ... und in Freetz-NG ist es ja m.W. ohnehin nur noch ein Verzeichnis all (oder so ähnlich), auf das jweils per Symlink verwiesen wird.

Allerdings wird es in nicht allzu ferner Zeit noch weitere Änderungen geben, die werden dann aber weniger tiefgreifend sein hinsichtlich Dateistruktur und Integration in die AVM-Firmware - aber dann mehr Modelle unterstützen. Das FIT-Zeug ist der nächste geplante Punkt, nur verwendet AVM bei den ARM-Boxen dann doch plötzlich LE als Byte-Order und das muß ich erst mal einbauen - was mit Beschränkung auf POSIX-Syntax und -Kommandos nicht sooo simpel ist.

[fda77]

Das mit den Brandings hast du noch immer nicht verstanden. Das ist bei NG und Freetz/ gleich, ich hab daran noch nie was gemacht, es war auch nicht meine Idee. Es ist nur viel Aufwand wegen den ganzen Patches es rückgängig zu machen

Scheint noch nicht mit Freetz zu funktionieren:

applying patch file ./patches/scripts/800-modfs_boot_manager.sh
  adding modfs boot-manager
Target directory: build/modified/filesystem/
Autodetection of target system version (from 'build/modified/filesystem/'): 154.07.29
Action from line 2 of patch definitions skipped due to version settings: not below 00.00, but below 07.08 ('sed' for '$LuaFile').
sed: couldn't open file ./lua_patch_0708.sed: Datei oder Verzeichnis nicht gefunden
Action ('sed' with commands from file './lua_patch_0708.sed') from line 4 of patch definitions applied to 'build/modified/filesystem/usr/www/1und1/system/reboot.lua'.
sed: couldn't open file ./lua_patch_0708.sed: Datei oder Verzeichnis nicht gefunden
Action ('sed' with commands from file './lua_patch_0708.sed') from line 4 of patch definitions failed on 'build/modified/filesystem/usr/www/avm/system/reboot.lua'.
sed: couldn't open file ./lua_patch_0708.sed: Datei oder Verzeichnis nicht gefunden
Action ('sed' with commands from file './lua_patch_0708.sed') from line 4 of patch definitions failed on 'build/modified/filesystem/usr/www/avme/system/reboot.lua'.
sed: couldn't open file ./js_patch_0708.sed: Datei oder Verzeichnis nicht gefunden
Action ('sed' with commands from file './js_patch_0708.sed') from line 6 of patch definitions applied to 'build/modified/filesystem/usr/www/1und1/system/reboot.js'.
sed: couldn't open file ./js_patch_0708.sed: Datei oder Verzeichnis nicht gefunden
Action ('sed' with commands from file './js_patch_0708.sed') from line 6 of patch definitions failed on 'build/modified/filesystem/usr/www/avm/system/reboot.js'.
sed: couldn't open file ./js_patch_0708.sed: Datei oder Verzeichnis nicht gefunden
Action ('sed' with commands from file './js_patch_0708.sed') from line 6 of patch definitions failed on 'build/modified/filesystem/usr/www/avme/system/reboot.js'.
Action from line 8 of patch definitions skipped due to version settings: not below 00.00, but below 07.08 ('cp' for './bootmanager_html').
Action ('cp' of file './bootmanager.msg' as 'build/modified/filesystem/usr/bin/bootmanager.msg') from line 10 of patch definitions failed.
Action ('cp' of file './bootmanager' as 'build/modified/filesystem/usr/bin/bootmanager') from line 12 of patch definitions failed.
Action ('cp' of file './bootmanager_server' as 'build/modified/filesystem/usr/bin/bootmanager_server') from line 14 of patch definitions failed.
Action ('cp' of file './bootmanager.service' as 'build/modified/filesystem/lib/systemd/system/bootmanager.service') from line 16 of patch definitions failed.

zum selbst ausprobieren: patch.txt

Wenn TARGET_BRANDING drin bleibt sind es weniger Fehlerzeilen

[PeterPawn]

Das mit den Brandings hast du noch immer nicht verstanden. Das ist bei NG und Freetz/ gleich, ich hab daran noch nie was gemacht, es war auch nicht meine Idee. Es ist nur viel Aufwand wegen den ganzen Patches es rückgängig zu machen

Was sollte ich daran nicht verstanden haben? Wenn ich schreibe, daß Du gucken sollst, ob es "in Freetz-NG noch paßt", impliziert das ja nicht, daß es in Freetz irgendwie ohne Probleme passen würde - nur macht es ja keinen Sinn mehr, das für Freetz ebenso zu betonen, weil es niemanden mehr interessiert.

---

Das Problem bei der Installation ist es halt, daß er die zusätzlichen Dateien alle nicht findet, weil das Arbeitsverzeichnis nicht stimmt. Eigentlich ist das add_to_system.sh so angelegt, daß es in seinem EIGENEN Verzeichnis aufgerufen wird ... dann stimmen auch jeweils die relativen Pfade - siehe hier: https://github.com/PeterPawn/modfs/blob/b28911b238d12083a3ca3edc25618382b64e7449/modscripts/gui_boot_manager_v0.8#L43

Das wären die Änderungen am Patch-File, die notwendig sind:

diff --git a/patches/scripts/800-modfs_boot_manager.sh b/patches/scripts/800-modfs_boot_manager.sh
index fd969057a..b66f243b3 100644
--- a/patches/scripts/800-modfs_boot_manager.sh
+++ b/patches/scripts/800-modfs_boot_manager.sh
@@ -3,23 +3,17 @@ echo1 "adding modfs boot-manager"

 TEMPDIR=$(mktemp -d)

-for oem in $(supported_brandings) all; do
-   www_oem="${FILESYSTEM_MOD_DIR}/usr/www/${oem}"
-   [ -d "${www_oem}" -a ! -L "${www_oem}" ] || continue
+echo2 "adding boot-manager to AVM's page(s)"

-   echo2 "adding boot-manager front end to branding \"${oem}\""
+save_cwd="$(pwd)"
+cd "${TOOLS_DIR}/yf/bootmanager"

-   TARGET_BRANDING="${oem}" \
-   TARGET_SYSTEM_VERSION="autodetect" \
-   TARGET_SYSTEM_VERSION_DETECTOR="${TOOLS_DIR}/yf/bootmanager/extract_version_values" \
-   TARGET_DIR="${FILESYSTEM_MOD_DIR}" \
-   TMP="$TEMPDIR" \
-   sh "${TOOLS_DIR}/yf/bootmanager/add_to_system_reboot.sh"
-done
+TARGET_SYSTEM_VERSION="autodetect" \
+TARGET_SYSTEM_VERSION_DETECTOR="${TOOLS_DIR}/yf/bootmanager/extract_version_values" \
+TARGET_DIR="${FILESYSTEM_MOD_DIR}" \
+TMP="$TEMPDIR" \
+sh "./add_to_system_reboot.sh"

-rmdir "$TEMPDIR"
-
-echo2 "adding boot-manager back end script"
-cp -a "${TOOLS_DIR}/yf/bootmanager/gui_bootmanager" "${FILESYSTEM_MOD_DIR}/usr/bin/"
-chmod 755 "${FILESYSTEM_MOD_DIR}/usr/bin/gui_bootmanager"
+cd "$save_cwd"

+rmdir "$TEMPDIR"

bm083.patch.txt

PS: Gerade ist mir noch aufgefallen, daß dann auch die Zeile mit dem TARGET_SYSTEM...DETECTOR noch entfallen kann, weil der Symlink in $TOOLS_DIR/yf/bootmanager auch existieren sollte und dann ist der Name ./extract_version_values auch wieder der Standard: https://github.com/PeterPawn/YourFritz/blob/4605424f99a54986b4ad28dc21e35c472a643575/bootmanager/add_to_system_reboot.sh#L126

---

Ob Du den Patch 040-bootmanager_freetz_fixed_branding_approach.patch dann weiter durchziehen willst, mußt Du selbst entscheiden - ich vermute mal, er wird nicht mehr passen bzw. er kommt auch mit anderen Änderungen (konkret dem Test auf YF_CHANGE_OEM, siehe hier: https://www.ip-phone-forum.de/threads/boot-manager-umschalten-zwischen-den-zwei-systemen-in-einer-passenden-fritz-box.307098/post-2468235) in Konflikte.

Ich habe noch nie verstanden, warum @er13 nun partout seinen eigenen Weg gehen mußte (https://github.com/PeterPawn/YourFritz/pull/16) - eine schlüssige Begründung dafür habe ich jedenfalls noch nicht gelesen.

Du mußt Dich nun entscheiden, ob Du ggf. den erwähnten Patch noch anpaßt (wie gesagt, es gibt mittlerweile deutlich mehr Aktionen rund um das Branding und da ist der "fixed"-Ansatz nur einer von vielen) oder Dich entschließt, meinen alten Commit (Link oben) in Freetz-NG zu übernehmen, dann braucht es den 400-irgendwas nicht mehr,

Einen Nachteil, wenn das Branding an der deutlich länger vorgeschlagenen und praktizierten(!) Stelle geändert wird (das habe ich ja alles schon mal in dem PR von @er13 erklärt), kann ich jedenfalls nicht erkennen - das hat sogar die ganzen Änderungen im Zuge des Zusammenlegens der Brandings bei AVM überstanden, ohne die Funktion zu verlieren.

[PeterPawn]

@fda77: Ach so ... wenn Du Dein "Freetz-NG"-Bild auch bei der Installation erhalten willst, mußt Du ggf. noch die Ausgabe auf STDOUT umleiten - ansonsten zerlegt Dir das vermutlich die Anzeige.

[PeterPawn]

@fda77: Doch noch ein Problem ... wie ich gerade gesehen habe, ist das FILESYSTEM_MOD_DIR ja nur ein relativer Pfad - das paßt dann nach dem Verzeichniswechsel auch nicht mehr und da müßte dann noch der absolute Pfad (mit realpath oder readlink -f) als TARGET_DIR übergeben werden, ebenso alle weiteren Pfade, die nur relativ angegeben sind (wobei das mktemp weiter oben ja einen absoluten Pfad liefern sollte).

Und bei der Kontrolle habe ich noch ein Problem gefunden, was für Versionen < 07.08 bestand: https://github.com/PeterPawn/YourFritz/commit/03cfc0a1eafbdfec84f28d44958beab073da5b42 - da mußt Du den Hash für das Auschecken dann auch noch einmal anpassen.

[fda77]

Danke, scheint so zu funktionieren. Dass da 10 Zeilen auf stderr herauskommen finde ich nicht so schick. Debug-Sachen könnte man auf stdout legen, das stummgeschaltet wird. 040-bootmanager_freetz_fixed_branding_approach.patch würde ich schon gern loswerden, zusätzliche Patches machen immer irgendwann Probleme. Ich mag mich da aber nicht so tief einlesen, dein Link oben verlinkt nochmals auf ein paar IPPF threads. Dass ihr da Unstimmigkeiten hattet hatte ich mitbekommen, aber nie weshalb genau Der Patch sollte aber nicht schaden da:

        b=...
+       [ -z "$b" ] && b=...

Wenn das b schon gesetzt ist, ändert sich daran nichts

[PeterPawn]

Der Patch sollte aber nicht schaden da:

Das Problem ist eher, daß der Patch nicht mehr funktioniert, wenn ich die Zeilen, an denen er sich orientiert, nicht 1:1 so drin stehen lasse - wie bei allen diesen Patches.

Es ging nie darum, ob der "irgendwas tut" (das sehe ich ja selbst) - es ging/geht darum, daß er mich jetzt und auch in der Zukunft daran hindert, das Skript an dieser Stelle so zu ändern, wie ich es für richtig halte und ich dafür keinen plausiblen Grund erkennen kann.

Und mache ich das dennoch, wird dieser Patch nicht passen und in der Folge auch der Build abbrechen - wenn die Zeilen sich ändern und nicht nur irgendwie verschieben, läßt sich das nicht einmal durch "autofix" beheben.

Um das zu verdeutlichen, habe ich mal eine winzige Änderung an der Stelle eingecheckt: tools/make/yourfritz-host/patches/040-bootmanager_freetz_fixed_branding_approach.patch - die hat noch nicht mal Auswirkungen auf die Funktion des Skripts, aber schon die stellt diesen Patch kalt ... und damit bricht auch der Build da ab, was auch ein Anpassen der Zeilennummern in den Patches nicht verhindert.

Nun konnte sich ja @er13 auf den Standpunkt stellen, dann würde er den Patch eben auch bei Änderungen von meiner Seite erneut anpassen - aber wie Du ja selbst schreibst, willst Du das sicherlich nicht machen, weder heute, noch in der Zukunft, zumal es eben so unnötig ist wie ein Kropf.

Ich mache mal einen Patch gegen https://github.com/Freetz-NG/freetz-ng/commit/b1d5bf05eaaaec8077fc9031efea2c0e47e86bdb in Freetz-NG fertig, weil ich da ohnehin gerade dabei war - der ändert auch noch mal die Patch-Files, weil ich das ohnehin schon geändert hatte und nur noch mal ein "rebase" gegen Deine Änderungen von heute gemacht habe.

Ich mußte mir nur erst mal überhaupt einen Mirror des Freetz-NG-Repos auf meinem lokalen Server ablegen und vermutlich muß ich für die PR-Verwaltung von GitHub sogar versuchen, das GitHub-Repo von Freetz-NG zu klonen. Ich bin jetzt schon gespannt, ob das reibungslos funktioniert, denn ich habe ja bereits meinen eigenen Klon, der von demselben Repo (nämlich Freetz/freetz) abstammt und der muß auch erhalten bleiben.

Da die beiden Repos (Dein Freetz-NG und mein YourFreetz) dann gemeinsame Wurzeln haben, besteht m.W. die Gefahr, daß dabei dann GitHub durcheinander kommt bzw. daß die Differenzen jeweils zum Freetz-Master ausgewiesen/ausgewertet werden, wenn man PRs zusammenstellt.

Aber mal schauen ... ich habe die Repos bei GitHub ja immer noch auf meinem lokalen Git-Server.

PS: Beim Build-Versuch ist mir dann auch noch aufgefallen (weil ich erst einen Fehler beim Übersetzen erhielt, den ich beseitigen mußte), daß die e2fsprogs (bei den Host-Tools) auch nicht wirklich benötigt werden, solange es sich beim ausgewählten FRITZ!Box-Modell nicht um eines mit einem VR9-Prozessor handelt und auch dann wird das nur so lange benötigt, wie AVM nicht selbst auch wieder auf das SquashFS-Format für den YAFFS2-Inhalt umgestiegen ist (ich weiß nicht mehr, wann das genau war, begonnen hat es irgendwann mit 06.35 und mittlerweile ist es Geschichte).

Da könnte/sollte man dann auch in der überwiegenden Zahl der Fälle auf dieses Paket ganz verzichten ... zumal es sicherlich auch wieder in den Repositories der eigenen Distribution schon fertige Pakete dafür gibt und man das kaum unbedingt selbst noch übersetzen muß - wobei das i.d.R. auch wieder (wie ldconfig) in Verzeichnissen installiert wird, auf die nur der Superuser Zugriff hat.

Irgendwann muß man sich dann halt mal Gedanken machen, wie man das mit den "prerequisites" schlauer löst ... für die Installation von Paketen als "Voraussetzung" muß man i.d.R. ja ohnehin auch Superuser-Rechte haben (egal, ob das über apt oder zypper läuft) und da bietet es sich dann auch an, wenn man dabei noch ein kleines Shell-Skript dazu packt, was mit Superuser-Rechten laufen muß und sich die notwendigen Dateien aus den Verzeichnissen, auf die nur der Superuser Zugriff hat, zusammen sucht (ein which wirkt Wunder) und sie an eine Stelle kopiert, wo dann der Build-User auch Zugriff hat. Um Libraries muß man sich dabei nicht kümmern, die sind i.d.R. ohnehin "shared" und auch für normale User erreichbar.

[PeterPawn]

@fda77: Ja, es ist (noch immer) so, wie ich es kannte und mir gedacht hatte (ich hatte Dir das irgendwo auch schon einmal versucht zu erklären, als Du wissen wolltest, warum ich nicht einfach auch noch Freetz-NG klone und damit dann PRs erzeuge) ... wenn ich mit meinem GitHub-Account auf das Freetz-NG-Repo gehe und dort auf Fork klicke, lande ich direkt wieder in meinem YourFreetz-Fork. Man kann offenbar nur EINEN einzigen Nachfahren eines anderen Repos in seinem Portfolio haben.

Da ich das YourFreetz-Repo aber brauche (das dient mir ja als Quelle für das Einhalten der GPL-Bestimmungen für die Binaries, die ich in yf_bin bereitstelle), KANN ich gar keinen PR über GitHub für Freetz-NG generieren.

Ich kann also max. gegen eine Kopie in meinem lokalen Git-Server eine Liste der Commits ausgeben (im E-Mail-Format, was git ja auch unterstützt) und die dann als Anhang irgendwo ablegen.

Die Alternative, in meinem YourFreetz-Repo einen Branch anzulegen, der dann all die Unterschiede von Freetz-NG zum Freetz-Master enthält, tue ich mir nicht an ... ich habe genauso wenig Lust dazu, wie Du zu einem rebase gegen den letzten Stand von Freetz/freetz hast.

Da sich die Repos eben schon lange vor diesem Stand auseinander entwickeln, ist das sehr, sehr viel Arbeit, weil kaum ein "fast forward"-Merge machbar sein kann.

[fda77]

Am besten aktiviertst du aptguru und damit dl-tools+toolchains. So kann man ein komplettes zb 7590 Minimalimage (ohne downloads) in 2,5 Minuten bauen. Wenn du nur mit den Patches herumexperimentierst reicht sogar ein "make firmware-nocompile" (fehler von libs etc ignorieren)

Auf aktuellem Fedora ist "~/.local/bin" im PATH der Benutzer drin, wer unbedingt möchte kann dort Binaries ablegen. Für header und libs dürfte das schwieriger sein. Eine VM in der man admin-Rechte hat ist am einfachsten. Irgend wann vielleicht auch Docker

Füg deinem lokalen Checkout doch einfach ein remote hinzu: git remote add NAME URL Dann kannst du mit "git checkout NAME HASH" einen hash als neuen branch aus jedem der remotes auschecken (und auch zu github hochladen). Mit "fetch" falls nötig alle aktualisieren. Evtl funktioniert dann auch ein PR Davon unabhängig könntest du mit "git format-patch origin/HEAD" neue Patches im am/mailbox Format speichern und hier anhängen. Eine Signatur dürfte dann aber fehlen.

Ich hab auch viele lokale Repos, aber nicht mit dem blöden gitweb sondern trac, das kann git und svn :D

[fda77]

Den 040-bootmanager_freetz_fixed_branding_approach.patch musste ich eh schon anpassen ... https://github.com/Freetz-NG/freetz-ng/commit/e509b390faf1a5a0d54c86129646ce6f554bbdc7#diff-b08dcbe09702fe9cfcb062bca98903c22fbcabe742d16565db2817432b67fa71

Da die beiden Repos (Dein Freetz-NG und mein YourFreetz) dann gemeinsame Wurzeln haben, besteht m.W. die Gefahr, daß dabei dann GitHub durcheinander kommt

Ne, das Problem besteh nur wenn auf Github ein Fork mit der Funktion dort erstellt wurde, also oben links "forked from" steht. Genau deshalb hatte ich anfangs NG nicht als Fork gekennzeichnet sondern einfach nochmal einen "bare" clone hochgeladen und Fork drangeschrieben. Ich glaub das gefiel dir damals nicht so recht ;-)

Gibt es bei e2fsprogs Fehler? Ich weiss nicht ob man dies Abhängigkeiten in der .config hat und diese sich in tools/make/Makefile.in abbilden lassen. Wenn man tools wie fwdu nutzt braucht man e2fsprogs aber eh. Da das tool einige Patches hat denke ich nicht dass man das von der Distribution verwenden kann, bestimmt nicht auf allen

[PeterPawn]

Mit git kann ich schon einigermaßen umgehen :smile: und das Freetz-NG-Repo auf GitHub ist als upstream logischerweise auch hinzugefügt (in meiner lokalen Arbeitskopie, die auch nicht mit der auf dem lokalen Git-Server verwechselt werden darf), weil sonst schon ein rebase nach Deinen Änderungen eher schwierig wäre ... aber danke für die Infos, die mir ja auch zeigen, daß Du Dich dann - nach anfänglichem Sträuben - einigermaßen mit git (und vielleicht auch GitHub) anfreunden konntest.

Wenn Du dafür dann Trac nutzen willst ... jeder nach seinen Bedürfnissen. Wenn man ohnehin mit einer IDE arbeitet (viele, die ich kenne, verwenden mittlerweile VS Code), dann übernimmt die aber auch (mit passenden Plugins) das ganze Handling der Versionskontrolle ... da braucht man dann nicht wirklich noch eine weitere Oberfläche.

Nur der lokale Git-Server ist dann immer noch ganz praktisch, weil man gegen den arbeiten kann und nicht jeden Furz nach GitHub schieben muß ... und erst wenn etwas dann einigermaßen stabil ist, kann man dieselben Commits (ggf. noch "squashed") dann auch auf GitHub publizieren.

Letztlich ging es mir auch nur darum, warum ich keine automatischen PRs aus einem eigenen (GitHub-)Klon des Freetz-NG-Repos erstellen kann und mich deucht, das mit der Option des git format-patch hatte ich gerade darüber auch schon selbst erwähnt ... oder was meinst Du, könnte ich mit

im E-Mail-Format, was git ja auch unterstützt

sonst gemeint haben?

Jetzt muß sich nur noch jemand finden, der Dich von der Verwendung von Feature-Branches überzeugen kann. :smile:

---

Genau deshalb hatte ich anfangs NG nicht als Fork gekennzeichnet sondern einfach nochmal einen "bare" clone hochgeladen und Fork drangeschrieben. Ich glaub das gefiel dir damals nicht so recht ;-)

Welcher zweite Fork von Freetz in GitHub hat Dich denn damals genau davon abgehalten, auch Freetz-NG von Beginn an als Fork zu beginnen? Bei mir war es eben mein Freetz-Fork mit dem Namen YourFreetz - etwas ähnliches habe ich damals bei Dir gar nicht gesehen. Vielleicht irrst Du Dich ja auch hinsichtlich Deiner Beweggründe damals ... aber ich denke auch, das brauchen wir nicht (erneut) zu vertiefen. Wenn ich mich recht erinnere, war die korrekte Reihenfolge bei Deinen Aktionen ja auch "Fork -> kein Fork -> Fork" ...

---

Und nein ... ich verwende (prinzipiell) keine Download-Toolchain, solange das nicht in einer isolierten Umgebung läuft, die keinerlei Kontakte nach außen hat (was dem Download-Gedanken dann auch widerspricht) und nach Benutzung einfach entsorgt wird.

Eine nur mittels MD5 gesicherte Datei, die auf (aus meiner Sicht) unsicheren Servern liegt, kann heutzutage viel zu schnell verändert werden, während der MD5-Hash weiterhin derselbe ist:

https://auth0.com/blog/birthday-attacks-collisions-and-password-strength/ https://natmchugh.blogspot.com/2015/02/create-your-own-md5-collisions.html

Davon würdest Du nicht mal etwas mitbekommen ... das MUSS für mich einfach nicht sein, da baue ich lieber eigene Toolchains, zumal man die ja auch selbst sichern kann (Stichwort "Build-Artefakte" - hatten wir iirc auch hier in irgendwelchen Diskussionen) und das mache ich durchaus auch:

vidar:~ $ ls -l /autofs/ssh/source/srv/www/vhosts/www.yourfritz.de/toolchains/
total 60176
-rw-r----- 1 wwwrun www  6246899 Jan 21  2018 i686_gcc-4.7.4-freetz-rXXXXX-shared-glibc.tar.lzma
-rw-r----- 1 wwwrun www      566 May 30  2018 i686_gcc-4.7.4-freetz-rXXXXX-shared-glibc.tar.lzma.sig
-rw-r----- 1 wwwrun www 11365291 Jan 21  2018 i686_gcc-4.7.4_uClibc-0.9.33.2-nptl-freetz-rXXXXX-shared-glibc.tar.lzma
-rw-r----- 1 wwwrun www      566 May 30  2018 i686_gcc-4.7.4_uClibc-0.9.33.2-nptl-freetz-rXXXXX-shared-glibc.tar.lzma.sig
-rw-r--r-- 1 wwwrun www  5542235 Jun  1  2018 mips_gcc-4.8.5-freetz-r13747-yourfritz-arm-24kc.tar.lzma
-rw-r----- 1 wwwrun www      566 Jun  1  2018 mips_gcc-4.8.5-freetz-r13747-yourfritz-arm-24kc.tar.lzma.sig
-rw-r--r-- 1 wwwrun www  5548868 May 29  2018 mips_gcc-4.8.5-freetz-r13747-yourfritz-arm.tar.lzma
-rw-r----- 1 wwwrun www      566 May 30  2018 mips_gcc-4.8.5-freetz-r13747-yourfritz-arm.tar.lzma.sig
-rw-r--r-- 1 wwwrun www 10451858 Jun  1  2018 mips_gcc-4.8.5_uClibc-0.9.33.2-nptl-freetz-r13747-yourfritz-arm-24kc.tar.lzma
-rw-r----- 1 wwwrun www      566 Jun  1  2018 mips_gcc-4.8.5_uClibc-0.9.33.2-nptl-freetz-r13747-yourfritz-arm-24kc.tar.lzma.sig
-rw-r--r-- 1 wwwrun www 22428576 May 29  2018 mips_gcc-4.8.5_uClibc-0.9.33.2-nptl_kernel-3.10-freetz-r13747-yourfritz-arm.tar.lzma
-rw-r----- 1 wwwrun www      566 May 30  2018 mips_gcc-4.8.5_uClibc-0.9.33.2-nptl_kernel-3.10-freetz-r13747-yourfritz-arm.tar.lzma.sig
vidar:~ $

Die sind zwar alle schon etwas älter, aber ich habe auch schon lange nichts mehr übersetzen müssen (weil fast alles statisch gelinkt ist in yf_bin, funktioniert es auch auf neueren Systemen noch) und da ich bekanntlich selbst gar kein Freetz verwende, gibt es i.d.R. auch keine Notwendigkeit, da aktuelle Toolchains vorzuhalten.

Aber diesen Server habe ich eben unter meiner eigenen Kontrolle - das steigert das Vertrauen schon mal um die Hälfte.

Und da ich normalerweise auch kein Freetz-NG baue (das mit dem eigenen Patch/PR ist eine Ausnahme), gibt es für mich auch keinen Grund, eine neuere Toolchain dafür beiseite zu legen - daher ist dann eben ab und an doch mal ein kompletter Build erforderlich (meistens ohnehin für andere, als Überprüfung gemeldeter Probleme) und das schadet auch keinesweg, weil nur so auch die Sachen auffallen, die auf einem "eingetragenen System" (im Gegensatz zu einem frischen, wo nach der Installation erst mal die notwendigen Pakete installiert werden müssen) schon lange vorhanden sind und daher auch keine Probleme mehr machen (solange man eben nicht in Containern baut, die tatsächlich jedesmal per "build" auch neu aufgesetzt werden).

---

Bei e2fsprog war ich selbst schuld ... da werden beim configure in den Quelltexten absolute Pfade eingetragen (konkret in lib/et/compile_et) und da ich das ganze Freetz-NG-Verzeichnis verschoben habe (weil im tmpfs dann doch nicht genug Platz war und er beim Build für den gcc abgebrochen hatte), stimmte darin dann dieser Pfad nicht und als ich die Host-Tools neu bauen ließ (weil das dann auch yourfritz-host einschloß), fiel mir das e2fsprogs vor die Füße und mir dabei auch auf, daß es in meiner Situation (ich hatte eine 7590 eingestellt) gar nicht benötigt wird.

---

Den 040-bootmanager_freetz_fixed_branding_approach.patch musste ich eh schon anpassen

Stimmt ... war mir gar nicht aufgefallen und war auch keine Absicht. Damit nicht doch mal die Daten in einer printf-Maske mit einem Bindestrich beginnen und von einigen printf-Implementierungen dann als "unbekannte Option" abgelehnt werden, setze ich (erst spät in der Phase der "Formatierung" und wenn ich shellcheck über die Datei laufen lasse) da grundsätzlich diese zwei Bindestriche, weil danach alles als Parameter zu betrachten ist und keine Optionen mehr "erlaubt" sind. Das geht dann so weit, daß sogar ein printf "\n" am Ende als printf -- "\n" erscheint, weil ich das per "search & replace" mache und gar nicht jedes einzelne dieser Statements anschaue.

[fda77]

Die meisten Dinge die ich braucht kenne ich von git schon. Es ist für mich aber immer noch keine richtiger Nachfolger von svn, da noch ein paar in svn vorhandene Featrues fehlen, leere Verzeichnisse, kopieren von Objekten MIT History etc

Das Trac nutze ich zum anzeigen vieler Repos, und es kann halt nicht nur 1 sc. Ich hab sowas schon lange, daher kommt auch das Backup vom freetz-svn der einfach gelöscht wurde

Reihenfolge bei Deinen Aktionen ja auch "Fork -> kein Fork -> Fork" ...

So genau weiss ich das nicht mehr, kann aber gut sein dass es beim 1en Test ein fork war. Ein Fork auf Github hat noch einen Nachteil: Auf den Benutzerprofilen werden keine commits angezeigt, nur wenn die im "root" repo sind. Ohne Fork gefiel mir aber auch nicht. Keines der beiden ist optimal

Die md5 ersetze ich so nach und nach, da könnte aber auch jeder andere mitmachen

shellcheck hatte ich mit auch mal angeschaut und die gröbsten in fwmod behoben, die zumindest https://github.com/Freetz-NG/freetz-ng/commit/a9bf4f7259c50dd64c6fc865a40b26113fc02e36 https://github.com/Freetz-NG/freetz-ng/commit/bfe6aa6520faebd3f32d299e31ea30e7f72ae3f5

[fda77]

Scheint noch nicht zu funktonieren: https://github.com/Freetz-NG/freetz-ng/commit/cd14bb0d548d1a80e8246c0ed27c1b695e8631af#commitcomment-68360413

[PeterPawn]

Bisher wurden ja die Änderungen am AVM-Lua als Ursache ausgemacht - da gibt es kein os.execute() und auch kein popen() mehr, weshalb ich das ja auf den Service umgestellt habe: https://www.ip-phone-forum.de/threads/boot-manager-umschalten-zwischen-den-zwei-systemen-in-einer-passenden-fritz-box.307098/post-2467135

Da in Freetz-NG jetzt aber gleich der Stand der 0.8.3 verwendet wird, weiß ich auch nicht, ob es weiterhin nur an unvollständigen Änderungen für 07.39+ liegt oder ob die Änderungen zwischen Version 0.7 und 0.8 die Ursache der Probleme sind. Eigentlich hatte ich das so verstanden, daß nach der Änderung im Lua-Code auf io.open (und damit dem Lesen des Cache-Files) der Rest im JS-/Lua-Code (der alten Version 0.7.x) funktioniert hat, wie der Screenshot in diesem IPPF-Thread zeigte. Daher halte ich es für denkbar, daß es gar nicht (mehr) an der neuen FRITZ!OS-Version liegt, sondern eher an den Änderungen zwischen den Versionen des Boot-Managers.

@freetz-ng-mod: Rufe mal bitte auf der Box (dazu muß natürlich der letzte Patch in Freetz-NG, der das wieder deaktiviert, nicht vorhanden sein beim Bauen des Images - oder Du hast die alte Version noch) das Kommando bootmanager debug verbose auf und zeige dessen Ausgabe + den Inhalt (ggf. maskiert) der Dateien /var/tmp/bootmanager.*.

Wenn da noch alles in Ordnung ist, liegt wohl noch ein weiteres Problem im JS- oder Lua-Code vor - dann kriegst Du weitere Anleitungen von mir, wo Du das wie genauer untersuchen kannst (teilweise ist das in diesem Thread schon beschrieben: https://www.ip-phone-forum.de/threads/freetz-ng-und-die-fw7-39-boot-manager.311707/).

[freetz-ng-mod]

@PeterPawn Ich werde die Box heute Abend wann (spätestens Morgen früh) mal mit

    Reserve in linux_fs_start=1, deaktiviert beim nächsten Systemstart

FritzOS 07.39 rev94932 (02.03.2022 17:05:07)
Freetz ng-18929MO-5c5a4d1d8 (04.03.2022 05:26:05)

wieder starten da das ja noch mit deaktiviert bootmanager ist. Und werde das hier dann posten. Die 7590AX halt meine Hauptbox

[PeterPawn]

Es würde auch schon reichen, wenn Du die Datei bootmanager aus meinem Repo einfach mal so auf die Box kopierst (wie Du es beim Repeater ja auch gemacht hast) und dort dann wie oben gezeigt aufrufst. Dazu muß der Boot-Manager nicht installiert sein und wenn er das nicht ist, muß auch kein Cache vorher gelöscht werden.

Es geht ja erst mal darum, ob das Erzeugen der Daten auf der 7590ax richtig funktioniert oder nicht - ich habe nur auf einer alten 7580 testen könne und da funktionierte es zumindest auch in der Version 0.8.3 - wenn ich mich nicht vertan habe, was auch mal vorkommen kann - deshalb prüfe ich solche Sachen immer doppelt, solange ich die Chance (sprich: Hardware) dazu habe.

[fda77]

Es geht ja erst mal darum, ob das Erzeugen der Daten auf der 7590ax richtig funktioniert oder nicht

Von Seiten AVM scheint sich nichts geändert zu haben: https://github.com/Freetz-NG/freetz-ng/commit/cd14bb0d548d1a80e8246c0ed27c1b695e8631af#commitcomment-68360413

[freetz-ng-mod]

wegt https://github.com/PeterPawn/YourFritz/blob/main/bootmanager/bootmanager wget https://github.com/PeterPawn/YourFritz/blob/main/bootmanager/bootmanager.msg

sh /var/mod/root/bootmanager debug verbose
/var/mod/root/bootmanager: line 8: syntax error: unexpected newline

sh /var/mod/root/bootmanager clear_cache /var/mod/root/bootmanager: line 8: syntax error: unexpected newline oder habe ich da jetzt was falsch verstanden

[fda77]

Führ mal head bootmanager* aus. Vielleicht hilft ein dos2linux bootmanager*

[freetz-ng-mod]

head bootmanager*
==> bootmanager <==

<!DOCTYPE html>
<html lang="en" data-color-mode="auto" data-light-theme="light" data-dark-theme="dark" >
  <head>
    <meta charset="utf-8">

==> bootmanager.msg <==

<!DOCTYPE html>
<html lang="en" data-color-mode="auto" data-light-theme="light" data-dark-theme="dark" >
  <head>
    <meta charset="utf-8">

dos2linux bootmanager* -sh: dos2linux: not found

sh /var/mod/root/bootmanager debug verbose
/var/mod/root/bootmanager: line 8: syntax error: unexpected newline
root@fritz:/var/mod/root# sh /var/mod/root/bootmanager clear_cache
/var/mod/root/bootmanager: line 8: syntax error: unexpected newline
root@fritz:/var/mod/root# 

Edit es ist aber immer noch das os mit aktiven BM

[fda77]

Das sind die falschen Dateien, nämlich HTML seiten. Du musst die "RAW" url nehmen, zb https://raw.githubusercontent.com/PeterPawn/YourFritz/main/bootmanager/bootmanager

[freetz-ng-mod]

Frau ist grade mit Hund raus, daher konnte ich das alte BS wieder starten. Also das ganze nun genauso wie bis jetzt gesagt oder muss ich nun anders vorgehen

[freetz-ng-mod]

sh /var/mod/root/bootmanager debug verbose

'firmware_version' found in fixed values area.
>>>>>>>>>> debug output of bootmanager script <<<<<<<<<<
system type = GRX500
system selector = 1
system is switched = false
device branding = avm
device branding is changeable = false
current branding = avm
inactive system is installed = true
>>>>>>>>>>>>>>>>>>>> running system <<<<<<<<<<<<<<<<<<<<
active kernel = /dev/mtdblock3
active filesystem = /dev/mtdblock6
active system version = 259.07.39-94932
active system date = 02.03.2022, 17:05:07 Uhr (epoch: 1646237107)
active system modification date = 04.03.2022, 05:26:05 Uhr (epoch: 1646367965)
active system modification source = Freetz-NG
brandings supported on active system = 1und1 avm avme
branding used by active system = avm (immutable)
>>>>>>>>>>>>>>>>>> alternative system <<<<<<<<<<<<<<<<<<
inactive kernel = /dev/mtdblock0
inactive filesystem = /dev/mtdblock5
inactive filesystem mounted on /var/tmp/4427_1646931989/alt_root
inactive system version = 259.07.39-94932
inactive system date = 02.03.2022, 17:05:07 Uhr (epoch: 1646237107)
inactive system modification date = 10.03.2022, 06:22:07 Uhr (epoch: 1646889727)
inactive system modification source = Freetz-NG
brandings supported on inactive system = 1und1 avm avme
branding used by inactive system = avm (immutable)
inactive filesystem dismounted

sh /var/mod/root/bootmanager get_values

active_version="259.07.39-94932"
active_date_epoch="1646237107"
active_date="02.03.2022, 17:05:07 Uhr"
active_modified_by="Freetz-NG"
active_modified_at_epoch="1646367965"
active_modified_at="04.03.2022, 05:26:05 Uhr"
active_brandings="1und1 avm avme"
active_branding="avm"
active_change_branding_support=immutable
inactive_version="259.07.39-94932"
inactive_date_epoch="1646237107"
inactive_date="02.03.2022, 17:05:07 Uhr"
inactive_modified_by="Freetz-NG"
inactive_modified_at_epoch="1646889727"
inactive_modified_at="10.03.2022, 06:22:07 Uhr"
inactive_brandings="1und1 avm avme"
inactive_branding="avm"
inactive_change_branding_support=immutable
device_branding=avm
device_branding_changeable=false
switch_branding_support=false
current_switch_value=1
system_is_switched=false

cat /var/tmp/bootmanager.data

active_version="259.07.39-94932"
active_date_epoch="1646237107"
active_date="02.03.2022, 17:05:07 Uhr"
active_modified_by="Freetz-NG"
active_modified_at_epoch="1646367965"
active_modified_at="04.03.2022, 05:26:05 Uhr"
active_brandings="1und1 avm avme"
active_branding="avm"
active_change_branding_support=immutable
inactive_version="259.07.39-94932"
inactive_date_epoch="1646237107"
inactive_date="02.03.2022, 17:05:07 Uhr"
inactive_modified_by="Freetz-NG"
inactive_modified_at_epoch="1646889727"
inactive_modified_at="10.03.2022, 06:22:07 Uhr"
inactive_brandings="1und1 avm avme"
inactive_branding="avm"
inactive_change_branding_support=immutable
device_branding=avm
device_branding_changeable=false
switch_branding_support=false
current_switch_value=1
system_is_switched=false

[PeterPawn]

~Hast Du da tatsächlich in beiden Slots dieselbe Firmware installiert oder ist das ein Fehler, wenn für das aktive und das inaktive System exakt dieselben Daten angezeigt werden?~

Quatsch, was habe ich denn da gesehen?

Dieses Sammeln der Daten hat also funktioniert ... damit ist der Teil schon mal draußen als Ursache des Problems.

Ich denke mal nach, wie man das mit dem Lua- und dem JS-Code jetzt am besten prüft - melde mich dann wieder.

[freetz-ng-mod]

Ok

[PeterPawn]

So - es gibt ja nun mehrere Baustellen und diese hier, erscheint mir persönlich erst mal am dringendsten.

Da mittlerweile für die 7590ax geklärt ist, daß das Sammeln der Daten einwandfrei funktioniert hat, bräuchte ich folgende Dateien aus einer Firmware, bei der die Neustart-Seite von AVM leer bleibt:

• /usr/www/avm/system/reboot.lua
• /usr/www/avm/system/reboot.js

Da diese eigentlich (C) AVM sind, wäre es aber wieder riskant (ich will AVM nichts unterstellen, man weiß aber auch nie genau, ob da nicht doch mal jemand einen Rappel kriegt), die hier in vollem Umfang zu "veröffentlichen" (weil das für die (im UrhG erlaubte) Selbsthilfe nicht erforderlich wäre). Die bräuchte ich daher dann bitte per E-Mail ...

Parallel dazu kannst Du auch mal in dem Browser, den Du verwendest, mit dessen Developer-Tools nach dem Request sehen, der da für data.lua mit pid=reboot ausgeführt wird. Im Firefox sähe das z.B. so aus:

Wenn da kein gültiges JSON-Format erzeugt werden sollte, weil es einen Lua-Fehler in der Datei reboot.lua gibt, dann sollte da stattdessen ein Text mit einer Beschreibung des Fehlers stehen. Wenn da JSON erzeugt wird, kann man die Struktur für data durch Klicken auf das Symbol vor der Zeile erweitern oder auf "raw"-Ansicht umschalten und da dann die JSON-Zeichenkette herauskopieren, die dann im o.g. Fall so aussieht:

{"pid":"reboot","hide":{"dslStat":true,"dslSet":true,"liveTv":true,"dectMoni":true,"dectRdio":true,"dslSpec":true,"dectMoniEx":true,"rss":true,"mobile":true,"dslFeed":true,"dslOv":true,"dectMail":true,"dslGraph":true,"ssoSet":true,"liveImg":true},"time":[],"data":{"activeCalls":[],"bm":{"values":{"inactive_branding":"avm","active_brandings":"1und1 avm avme","inactive_modified_by":"modfs","inactive_change_branding_support":"immutable","inactive_modified_at_epoch":"1646165177","active_modified_at_epoch":"1646227137","active_branding":"avm","hasService":true,"device_branding_changeable":false,"system_is_switched":false,"active_date_epoch":"1636107311","switch_branding_support":false,"inactive_date_epoch":"1636107311","device_branding":"avm","inactive_version":"113.07.29","active_modified_by":"modfs","active_version":"113.07.29","active_change_branding_support":"immutable","inactive_brandings":"1und1 avm avme","inactive_modified_at":"01.03.2022, 21:06:17 Uhr","current_switch_value":"0","inactive_date":"05.11.2021, 11:15:11 Uhr","active_modified_at":"02.03.2022, 14:18:57 Uhr","active_date":"05.11.2021, 11:15:11 Uhr"},"localized":{"brndcurrfixed":"Die Firmware-Version des aktuell laufenden Systems ist fest auf \"%1%fixed%\" eingestellt und kann nicht geändert werden.","altinv":"Das System in den alternativen Partitionen kann nicht identifiziert werden.\nEs verwendet entweder ein unbekanntes Dateisystem oder es könnte auch beschädigt sein.\nEine Umschaltung auf dieses System sollte nur ausgeführt werden, wenn man sich wirklich sehr sicher ist, was man da tut.","nodata":"Fehler im Boot-Manager: Es wurden keine Daten für die Anzeige erzeugt.","modified":"zuletzt modifiziert am %1%date% durch \"%2%framework%\"","unknowndate":"(keine Angabe)","brndhead":"Branding ändern","currsys":"das aktuell laufende System","unsupported":"Die Umschaltung zwischen zwei installierten Systemen ist auf dieser FRITZ!Box nicht verfügbar.","style_sblbl":"padding-right: 8px;","brndaltnew":"Bei der Umschaltung des zu verwendenden Systems wird daher auch gleichzeitig dieser Wert auf \"%1%alternative%\" geändert.","brndaltnochg":", diese ist im Moment auch eingestellt.","brndmulti":"Das oben ausgewählte System unterstützt mehrere Firmware-Versionen, im Moment ist \"%1%current%\" eingestellt.","unknown":"unbekannt","style_caption":"padding-right: 8px;","switchvalue":"(linux_fs_start=%1%switch%)","brndunsupp":"Bei diesem Gerät ist keine dauerhafte Änderung der Firmware-Version möglich.","usedLanguage":"de","brndset":"Beim nächsten Start wird folgender Wert gesetzt und bis zur nächsten Änderung verwendet:","brndaltsingle":"Das oben ausgewählte System unterstützt nur die Firmware-Version \"%1%alternative%\"","headline":"Folgende Systeme stehen auf dieser FRITZ!Box zur Auswahl bei einem Neustart:","datetime":"%d.%m.%Y, %H:%M:%S Uhr","brndaltfixed":"Die Firmware-Version des derzeit nicht aktiven Systems ist fest auf \"%1%fixed%\" eingestellt und kann nicht geändert werden.","altmiss":"Die derzeit inaktiven Partitionen enthalten kein gültiges System.","brndaltset":", im Moment ist jedoch \"%1%current%\" eingestellt.","brndaltinv":"Da das alternative System nicht identifiziert werden konnte, ist auch keine Information über dort enthaltene Firmware-Versionen verfügbar.","altsys":"das derzeit inaktive System","brndcurrsingle":"Das oben ausgewählte System unterstützt nur die Firmware-Version \"%1%current%\", diese ist im Moment auch eingestellt.","version":"Version %1%version% vom %2%date%"}}},"sid":"8e545408f89c1d9d"}

(Die erste Version des JSON-Strings enthielt keine Daten, weil ich zuvor etwas getestet hatte.)

Die kann dann auch problemlos hier gezeigt werden, da ist nichts mehr, was AVM's Urheberrechte tangieren würde.

[PeterPawn]

@freetz-ng-mod: Push ... falls Dir das versehentlich durchgerutscht sein sollte - es sind ja mittlerweile viele verschiedene Baustellen. Da diese hier einerseits meine eigene Software betrifft und weil ich sie andererseits für die am einfachsten zu beseitigende halte, würde ich sie auch gerne als erste abhaken können.

[freetz-ng-mod]

Oh ja das habe ich total übersehen

Und hast eine mail

[PeterPawn]

Sorry - der Screenshot oben ist für den falschen Request. Der richtige wird erst nach dem Klicken auf "Neustart" ausgeführt - bei dem steht dann auch pid: "reboot" in den Daten (oben ist das sysSave).

[freetz-ng-mod]

Ich habe den neustart ja nicht da weil Seite leer ;-)

[PeterPawn]

Ich habe den neustart ja nicht

Der "Register-Tab" in der AVM-Seite (mit dem Namen "Neustart") sollte ja noch vorhanden sein und der Klick darauf löst dann auch den Request aus, um den es mir hier geht.

[freetz-ng-mod]

{"pid":"sysSave","hide":{"ssoSet":true,"shareUsb":true,"boxExchange":true,"liveTv":true},"timeTillLogout":"1200","time":[],"data":{"DECT":true,"tfaNeeded":false,"telExportPossible":true,"anyUsbHost":true,"backToPage":"sysSave"},"sid":"816403b32c631343"}

[PeterPawn]

Wir mißverstehen uns immer noch. Ich beschreibe es mal in einzelnen Schritten:

1. Neues Browser-Fenster/-Tab öffnen
2. das AVM-GUI aufrufen und bis zu dieser Seite navigieren:
3. F12 drücken (sollte die Taste für die "developer functions" sein und ein neues Fenster öffnen)
4. Auf "Netzwerkanalyse" im Menü dieses neuen Fensters klicken
5. jetzt im Fenster mit dem AVM-GUI auf den "Neustart"-Tab klicken
6. im anderen Fenster sollten jetzt mehrere Requests zu sehen sein (mind. einer für reboot.js und einer für data.lua)
7. des Ergebnis (Response/Antwort) für den Aufruf der data.lua ist das, was mich interessiert

[freetz-ng-mod]

Das mache ich doch immer

[PeterPawn]

OK, jetzt sehe ich auch die reboot.js unmittelbar davor (in vorherigen Screenshots waren da weitere Aufrufe von data.lua dazwischen, was auch so aussehen würde, wenn man danach wieder auf andere Tabs klickt) - was ich nicht verstehe, ist die Tatsache, daß hier ja weiterhin pid: "sysSave" in der Antwort steht (das ist die erste Registerkarte "Sichern"); das kann eigentlich nur ein Fallback sein.

Würdest Du mir bitte mal den dazugehörigen Request zeigen ("Anfrage" rechts über dem Einzelheiten des Requests)? Da sollte pid: "reboot" stehen und das wäre dann auch die Seite (eben reboot.lua), die da aufgerufen werden sollte. Wie es von dort zur Sichern-Seite geht, ist mir ein Rätsel - zumindest ohne Lua-Fehler, wobei es eben sein kann, daß AVM die abfängt und dann einfach die Antwort für die "Standardseite" des Menüpunkts auf der linken Seite sendet.

Versuche mal bitte noch, parallel zu dem Request, die Ausgaben auf /dev/console zu erwischen - die sieht man üblicherweise in der allerersten Shell-Session, die man zur neu gestarteten Box aufmacht - die hinterlegte /etc/profile sorgt dafür, daß die Ausgaben in diese Session erfolgen. Eigentlich sollten sich Lua-Exceptions auch dort noch bemerkbar machen - zumindest war das bei den vorhergehenden Versionen noch der Fall.

[freetz-ng-mod]

Das steht da bei der 7590AX mit FW 7.39 {"pid":"sysSave","hide":{"ssoSet":true,"shareUsb":true,"boxExchange":true,"liveTv":true},"timeTillLogout":"1200","time":[],"data":{"DECT":true,"tfaNeeded":false,"telExportPossible":true,"anyUsbHost":true,"backToPage":"sysSave"},"sid":"823baeeae78abb60"} ^ das hatte ich aber auch schon mal geschrieben https://github.com/PeterPawn/YourFritz/issues/43#issuecomment-1065897259

Bei der 7490 {"pid":"reboot","hide": {"shareUsb":true,"faxSet":true,"dectRdio":true,"pod":true,"trafapp":true,"netCnt":true,"dslSet":true,"dyndns":true,"trafapp_edit":true,"rdio":true,"liveImg":true,"ssoSet":true,"dslStat":true,"trafprot_edit":true,"liveTv":true,"dectMoni":true,"trafprio":true,"provServ":true,"dectMoniEx":true,"rss":true,"mobile":true,"dslFeed":true,"portoverview":true,"dslOv":true,"dslGraph":true,"dslSpec":true,"dectMail":true},"time":[],"data":{"activeCalls":[],"bm":{"values":{"inactive_branding":"avm","active_brandings":"1und1 avm avme","inactive_modified_by":"Freetz-NG","inactive_change_branding_support":"changeable","inactive_modified_at_epoch":"1646936645","active_modified_at_epoch":"1647019728","active_branding":"avm","hasService":true,"device_branding_changeable":true,"system_is_switched":false,"active_date_epoch":"1636107311","switch_branding_support":true,"inactive_date_epoch":"1636107311","device_branding":"avm","inactive_version":"113.07.29","active_modified_by":"Freetz-NG","active_version":"113.07.29","active_change_branding_support":"changeable","inactive_brandings":"1und1 avm avme","inactive_modified_at":"10.03.2022, 19:24:05 Uhr","current_switch_value":"1","inactive_date":"05.11.2021, 11:15:11 Uhr","active_modified_at":"11.03.2022, 18:28:48 Uhr","active_date":"05.11.2021, 11:15:11 Uhr"},"localized":{"brndcurrfixed":"Die Firmware-Version des aktuell laufenden Systems ist fest auf \"%1%fixed%\" eingestellt und kann nicht geändert werden.","altinv":"Das System in den alternativen Partitionen kann nicht identifiziert werden.\nEs verwendet entweder ein unbekanntes Dateisystem oder es könnte auch beschädigt sein.\nEine Umschaltung auf dieses System sollte nur ausgeführt werden, wenn man sich wirklich sehr sicher ist, was man da tut.","nodata":"Fehler im Boot-Manager: Es wurden keine Daten für die Anzeige erzeugt.","modified":"zuletzt modifiziert am %1%date% durch \"%2%framework%\"","unknowndate":"(keine Angabe)","brndhead":"Branding ändern","currsys":"das aktuell laufende System","unsupported":"Die Umschaltung zwischen zwei installierten Systemen ist auf dieser FRITZ!Box nicht verfügbar.","style_sblbl":"padding-right: 8px;","brndaltnew":"Bei der Umschaltung des zu verwendenden Systems wird daher auch gleichzeitig dieser Wert auf \"%1%alternative%\" geändert.","brndaltnochg":", diese ist im Moment auch eingestellt.","brndmulti":"Das oben ausgewählte System unterstützt mehrere Firmware-Versionen, im Moment ist \"%1%current%\" eingestellt.","unknown":"unbekannt","style_caption":"padding-right: 8px;","switchvalue":"(linux_fs_start=%1%switch%)","brndunsupp":"Bei diesem Gerät ist keine dauerhafte Änderung der Firmware-Version möglich.","usedLanguage":"de","brndset":"Beim nächsten Start wird folgender Wert gesetzt und bis zur nächsten Änderung verwendet:","brndaltsingle":"Das oben ausgewählte System unterstützt nur die Firmware-Version \"%1%alternative%\"","headline":"Folgende Systeme stehen auf dieser FRITZ!Box zur Auswahl bei einem Neustart:","datetime":"%d.%m.%Y, %H:%M:%S Uhr","brndaltfixed":"Die Firmware-Version des derzeit nicht aktiven Systems ist fest auf \"%1%fixed%\" eingestellt und kann nicht geändert werden.","altmiss":"Die derzeit inaktiven Partitionen enthalten kein gültiges System.","brndaltset":", im Moment ist jedoch \"%1%current%\" eingestellt.","brndaltinv":"Da das alternative System nicht identifiziert werden konnte, ist auch keine Information über dort enthaltene Firmware-Versionen verfügbar.","altsys":"das derzeit inaktive System","brndcurrsingle":"Das oben ausgewählte System unterstützt nur die Firmware-Version \"%1%current%\", diese ist im Moment auch eingestellt.","version":"Version %1%version% vom %2%date%"}}},"sid":"bd18642f1572df5c"}

Da ist das mit dem reboot

[PeterPawn]

Das sind aber die Antworten - ich meinte (bei der 7590AX) die Abfrage (links daneben auf der rechten Seite im Fenster)!

Und ich lag auch leicht daneben - in der Anfrage steht da nicht pid: "reboot", sondern page: "reboot":

[freetz-ng-mod]

xhr=1&sid=823baeeae78abb60&lang=de&page=sysSave&xhrId=all

[PeterPawn]

Dann ist das aber kein Problem des Boot-Managers ... wenn die Abfrage schon die Seite sysSave haben will, dann kann ich (bzw. meine Änderungen am Lua- und JS-Code) nichts mehr dafür.

Wie sieht das denn mit der aktuellen AVM-Firmware aus? Funktioniert da die "Neustart"-Seite auch tatsächlich? Wenn nicht, dann hat AVM da einen Fehler in der Labor-Version und ich kann mich (vorerst) zurücklehnen.

[freetz-ng-mod]

Da kann ich nicht zu sagen, wie es bei der fw 7.31 aussehen tut. Weil die habe ich leider nicht auf der Box

Ich kann nur sagen, dass der reboot mit der inhaus Version mit deaktivierten Bootmanager geht. Da sollte man mal nachfragen, da sind einige die die labor drauf haben

Inhaus ist zurzeit bei FritzOS 07.39 rev94932