Bootmanager und Inhaus 7.39
fda77 opened this issue · 88 comments
Mit den neuen FW läuft dein Boot Manager unter dem AVM Webinterface nicht mehr, die Seite bleibt einfach weiß.
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.
Du wolltest doch eine Erinnerung als Issue. Ich hab auch kein Gerät für die Inhaus, wegen Freetz-NG/freetz-ng@5fd4715 und Freetz-NG/freetz-ng@ccdf8e4 müsste das auch jemand richtig (am besten mit Console) testen
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.
- Versuch, das Problem zu fixen: PeterPawn/modfs@bc369d9 - ich kann es nicht selbst testen und warte jetzt, wie es ausgeht ... wenn sich jemand mit einer 7590 (AX) und der Verwendung von
modfsfindet.
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.
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
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.
Vielleicht lies es sogar jemand ausser dir, dann wüsste man ob der Commit ausreicht
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: #43 (comment) 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.
Wenn ich alles geschrieben hab was ich denke was nötig ist höre ich einfach auf :)
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.
@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.
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
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"
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:
YourFritz/bootmanager/add_to_system_reboot.sh
Line 126 in 4605424
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 (#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.
@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.
@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: 03cfc0a - da mußt Du den Hash für das Auschecken dann auch noch einmal anpassen.
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
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 Freetz-NG/freetz-ng@b1d5bf0 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.
@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.
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
Den 040-bootmanager_freetz_fixed_branding_approach.patch musste ich eh schon anpassen ... Freetz-NG/freetz-ng@e509b39#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
Mit git kann ich schon einigermaßen umgehen 😄 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. 😄
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.
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 Freetz-NG/freetz-ng@a9bf4f7 Freetz-NG/freetz-ng@bfe6aa6
Scheint noch nicht zu funktonieren: Freetz-NG/freetz-ng@cd14bb0#commitcomment-68360413
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/).
@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
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.
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: Freetz-NG/freetz-ng@cd14bb0#commitcomment-68360413
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
Führ mal head bootmanager* aus. Vielleicht hilft ein dos2linux bootmanager*
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
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
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
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
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.
Ok
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.
@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.
Oh ja das habe ich total übersehen
Und hast eine mail
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).
Ich habe den neustart ja nicht da weil Seite leer ;-)
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.
{"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"}
Wir mißverstehen uns immer noch. Ich beschreibe es mal in einzelnen Schritten:
- Neues Browser-Fenster/-Tab öffnen
- das AVM-GUI aufrufen und bis zu dieser Seite navigieren:
- F12 drücken (sollte die Taste für die "developer functions" sein und ein neues Fenster öffnen)
- Auf "Netzwerkanalyse" im Menü dieses neuen Fensters klicken
- jetzt im Fenster mit dem AVM-GUI auf den "Neustart"-Tab klicken
- im anderen Fenster sollten jetzt mehrere Requests zu sehen sein (mind. einer für
reboot.jsund einer fürdata.lua) - des Ergebnis (Response/Antwort) für den Aufruf der
data.luaist das, was mich interessiert
Das mache ich doch immer
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.
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
#43 (comment)
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
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":
xhr=1&sid=823baeeae78abb60&lang=de&page=sysSave&xhrId=all
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.
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
Ich meinte auch eher die originale AVM-Labor-Version ... welcher Build ist das denn? Dann könnte man das ggf. auch von anderen Benutzern der 7590ax im IPPF mal prüfen lassen - es passiert desöfteren mal, daß in Labor-Reihen irgendwelche Links nicht richtig funktionieren.
Im IPPF wurde jetzt bestätigt, daß zumindest die Buildnummer 94934 der 7590ax auch die Reboot-Seite im GUI aufrufen läßt.
An irgendwelche Probleme mit einem Browser-Cache o.ä. kann ich nicht recht glauben, da der Request eigentlich nicht aus statischen Daten besteht (nicht mal die Menüstruktur wird statisch erzeugt) und dynamische sollte ein Browser nicht cachen, sondern bei einem frisch gestarteten Browser-Fenster auch immer bei Null beginnen.
Das hinterläßt mich noch ratloser ... da komme ich dann wohl doch auf die Option zurück, mal selbst per Browser zuzugreifen und dabei auch den JS-Code zu debuggen, aus dem der Request erzeugt wird. Das würde ich mit Dir per Mail verabreden wollen.
ok melde dich dann per mail
So ... ich habe eine 7590 mit Inhouse-07.39 mit dem Boot-Manager versehen und was soll ich schreiben? Das hat mit der Version 0.8.2 auf Anhieb geklappt:
Das ist der Stand vom 01.03.2022: 116bf91
Es liegt also nicht am Sammeln der Daten und auch nicht an Ausgabe der Daten zum Browser (also am Lua-Code), ebenso nicht an der Aufbereitung der Daten zur Anzeige (also dem JS-Code).
Zumindest ist das Problem also kein generelles, vielleicht ja noch eines, was sich auf bestimmte Modelle beschränkt.
Allerdings ist das getestete Verhalten der Firmware beim Request (für die Seite sysSave) mir ja schon suspekt, seitdem das Ergebnis der Tests ergab, daß die falsche Seite angefordert wird.
Ich weiß also nicht, was da bei der 7590ax passiert und wo deren Problem liegt ... ich werde den Verdacht nicht los, daß hier bereits die originale AVM-Firmware nicht funktioniert hat. Meines Wissens ist auch immer noch nicht klar, was das nun für ein Build war, der das Problem hatte ... vielleicht ist es ja das einfachste, noch einmal eine neue Version zu bauen. Bei AVM kommen ja auch ständig neue Labor- und Inhouse-Versionen hinterher - da wäre ein temporär eingebauter Fehler zumindest keine so große Überraschung bzw. kein Ding der Unmöglichkeit.
Seit der 0.8.2 habe ich eigentlich nur die Unterstützung für das Zerlegen der Bootloader-Konfiguration bei den Modellen, die LE-Byte-Order im Konfigurationsbereich verwenden, hinzugefügt (das wurde dann 0.8.3) und in der 0.8.4 soll dann die Unterstützung auch für FIT-Images in vollem Umfang erfolgen.
Ich bin nach meinen eigenen Tests wieder der Ansicht, daß der Boot-Manager spätestens in Version 0.8.2 auch mit der neuen Labor-/Inhouse-Reihe funktionieren sollte - warum das hier: #43 (comment) dann nicht klappt, weiß ich auch nicht.
Daher mache ich hier erst mal wieder zu ... und @fda77: Ich sähe keinen Grund, warum der Stand hier: 5e33421 nicht wieder aktiviert werden sollte. Es ist zumindest eben kein "07_25_MAX"-Problem (mehr) und wenn das auf der 7590ax tatsächlich weiterhin problematisch sein sollte, dann wäre zuerst zu prüfen, ob es OHNE die Modifikationen auch tatsächlich (mit derselben Build-Number) funktioniert.
Vielleicht wartest Du mit dem Aktualisieren des Hash-Wertes aber doch noch ein paar Stunden ... ich versuche mal, da noch die schon vorher irgendwo angesprochene Versionsnummer irgendwo in den Daten abzulegen, damit irgendwo klipp und klar steht, mit welchem Stand ein Image da tatsächlich arbeitet. Das muß ich ja nicht unbedingt anzeigen (lassen), aber man sollte es zumindest in den JSON-Daten der Response irgendwo finden können.
@PeterPawn du meinst also so wie es NACH #43 (comment) bereits ist?
Wenn ich's mir aussuchen kann, dann diesen Stand: 026fa5d - da sind noch die Versionsnummer und eine Möglichkeit zum Debuggen des Shell-Skripts für den "Server" dabei. Das wäre erst mal "abgeschlossen", bis die volle Unterstützung von FIT-Images in der nächsten Version dann kommen soll.
Hat das nicht noch Zeit bis das FIT ganz drin ist? Vorerst kannst du ja noch den test-tag nutzen
Hat das nicht noch Zeit bis das FIT ganz drin ist?
Wer das JETZT SCHON auf Geräten mit FIT-Image verwendet, ist in meinen Augen selbst schuld oder er WILL das (hier) testen und dann KANN er auch das Tag verwenden.
Für alle anderen Geräte (also die, für die AVM eine Labor-Firmware veröffentlicht hat) ist das damit aber auch ausgeschaltet (solange die [...]_07_25_MAX-Bedingung aktiv ist) und um die geht es eigentlich bei der Frage, die den Titel hier bildet.
Ich blicke auch so langsam nicht mehr richtig durch, weil ich bei Deinen Kommentaren nur selten WIRKLICH erkennen kann, was Du nur "anmerkst" und wo Du dann - basierend auf solchen Kommentaren - doch noch etwas änderst. Das beste Beispiel für ein erneutes "Mißverständnis" dürfte ja diese Antwort sein, die ich an @freetz-ng-mod geschrieben hatte:
Bleib einfach bei dem alten Stand (oder ändere die aktuelle Version wieder lokal, falls Du ein neues git pull gemacht hast), wo das ..._07_25_MAX NICHT enthalten ist - wenn Du den Boot-Manager nicht einbauen lassen willst, kannst Du den immer noch deaktivieren, solange Dir diese Option angezeigt wird und das ist bei der aktuellen Firmware (und dem Stand im Freetz-NG-Repo von heute mittag) nur dann der Fall, wenn diese Zeile NICHT existiert in den *.in-Files für Kconfig.
Das hätte ich ja nicht geschrieben, wenn Du zuvor klipp und klar geschrieben hättest, daß Du das in Freetz-NG TROTZ des gemeldeten Problems auf der 7590ax (die ja auch nichts mit FIT o.ä. zu tun hat, sondern nur/eher mit der Labor-Reihe 07.39) weiterhin aktiviert lassen würdest. Zwar hast Du auch nicht geschrieben, daß Du es deshalb DEAKTIVIEREN würdest, aber nach vorhergehenden Reaktionen/Diskussionen verstehst Du ja vielleicht auch, warum ich überhaupt auf die Idee kommen konnte, Du würdest das wieder deaktivieren. Spätestens nach meiner oben zitierten Antwort an @freetz-ng-mod hättest Du dieses Mißverständnis auch Deinerseits wieder aufklären können ... und in meinen Augen damit dann einen Beitrag für mehr Klarheit leisten können.
Wenn man sich - auch in dem Bestreben, dem Freetz-NG-Projekt beim Vorwärtskommen zu helfen, selbst wenn's hier um meine Software geht/ging - immer erst noch parallel die Commits in Freetz-NG reinziehen muß, um da noch "halbwegs mitzukommen" bei Deinen Änderungen, dann ist das auch "belastend" und nichts, wozu ich persönlich größere Lust habe. Selbst wenn Du nicht jedem die Änderungen noch einmal "vorsingen" kannst oder sollst - wenn sich aus solchen Änderungen oder auch aus unterlassenen Änderungen Konsequenzen für die Arbeit anderer ergeben, dann gehört auch eine "vernünftige Information" (auch über "Absichten" und nicht zwingend nur über tatsächliche Änderungen) dazu. Sonst fühlen sich andere (konkret auch ich selbst) auch schnell mal an der Nase herumgeführt (ich will Dir nicht mal unterstellen, daß Du das (immer) absichtlich machen würdest - vielleicht liegt es auch nur daran, daß Du "Zusammenarbeit" anders verstehst und da eher (wie andere auch) "Zuarbeit" erwartest) und haben dann einfach auch keine Lust mehr, ihre eigene Zeit zu investieren.
Zurück zum "gewünschten" Stand in Freetz-NG (ich schrieb ja ausdrücklich:
Wenn ich's mir aussuchen kann
) ... solange das überhaupt für Benutzer zum Testen auswählbar ist, ist mir das in jedem Fall natürlich "lieber", als wenn es gar nicht eingebaut werden kann.
Die letzte Änderung mit dem Zeitstempel für das Skript erleichtert dann auch die Einordnung, ob ein beschriebenes Problem vielleicht auch schon längst gefixt ist oder ob die verwendete Version TATSÄCHLICH auch die zuletzt "freigegebene" ist.
Wenn es mit dem vorhergehenden Stand in Freetz-NG also "neue Fehlermeldungen" geben sollte, würde ich diese Daten bei demjenigen "abfragen" wollen, der ein Problem meldet und wenn die nicht vorhanden/enthalten sind, ihn auf die neueste Version verweisen und die Frage stellen, ob sein Problem damit auch noch auftritt ... soweit sicher "normal" im Umgang mit gemeldeten Fehlern von Benutzern.
Wenn er dann nur sagen kann (so überhaupt): "... der Stand in Freetz-NG mit diesem Hash: xxx ...", läge "die Arbeit" wieder bei mir, denn dann müßte ICH erst mal in Freetz-NG nachsehen, welcher YourFritz-Stand denn beim Hash "xxx" in Freetz-NG verwendet wurde und DANN erst kann ich erkennen, ob das eine alte oder die aktuelle Version ist.
Ich bin eigentlich sogar so weit, daß ich die Version des Boot-Managers noch irgendwo direkt anzeigen lassen möchte (ein Eintrag in der Freetz-NG-Paketliste ist ja bei anderen Lösungen zum Modifizieren der Firmware auch nicht vorhanden) ... nur der passende Platz macht mir noch Kopfzerbrechen, denn wenn die gesamte Seite (bzw. der Inhalt im Tab) nicht angezeigt werden kann wegen eines Fehlers, dann sieht man die Version ja auch nicht.
Im Moment steht sie zwar in der erzeugten JSON-Struktur, da sieht man sie aber auch nur mit den Developer-Tools eines Browsers oder einer ähnlichen Lösung - auch kein wirklich optimales Vorgehen, wenn der Benutzer sich damit nicht selbst auskennt. Es ist also gut möglich, daß es dafür noch eine "Zwischenlösung" gibt - lange bevor die FIT-Unterstützung benutzbar ist.
Bis die volle Unterstützung für FIT-Boxen fertig implementiert ist, kann es auch noch eine Weile dauern ... man MUSS ja die notwendigen Schritte auch erst mal implementieren und dann testen (das geht jetzt beim FIT-Format - je nach Ansicht "auch schon" oder "erst seit" - 14 Tage: #45 (comment)) und es werden auch an anderen Stellen garantiert wieder weitere Hürden auftauchen, die man so gar nicht erwarten konnte - wie die extremen Laufzeiten beim Suchen nach dem richtigen Offset für das Dateisystem, wenn es NICHT auf x86-Systemen (Desktop-PC und 6490-ATOM-Core) arbeitet.
Ich würde das also eher nicht in dieser Woche "fertig" erwarten ...
@PeterPawn du meinst also so wie es NACH #43 (comment) bereits ist?
? (dürfte jetzt das 3. mal sein)
Was willst Du mir denn jetzt - meinetwegen auch zum dritten Mal - mit dem Link auf einen Kommentar(!) genau sagen? Welchen exakten Stand im Freetz-NG-Master soll ich denn mit diesem Kommentar (der NICHT auf einen Commit oder einen damit zu assoziierenden Hash verweist) verbinden?
Meinst Du die zwei (automatisch dazwischen geschobenen) Kommentare zu den Commits mit Deinem "NACH" und es ist damit ein Bezug auf die Reihenfolge innerhalb dieses Threads oder ist es ein "zeitliches NACH" als "Abgrenzung" und Dein Kommentar (08.03.2022 18:09 Uhr) bildet dann "den Stand", auf den Du mich aufmerksam machen willst - Zitat:
Danke, scheint so zu funktionieren.
Ich bin etwas irritiert ... die Commits, die da in der Lesefolge NACH dem verlinkten Kommentar stehen, liegen eben zeitlich auch erst NACH dem Kommentar (08.03.2022 18:12 Uhr und 18:13 Uhr) und da nutzt dann auch Dein Link auf den Kommentar nicht wirklich bei der Frage, was "NACH" nun heißen soll. Zeigt der Link auf einen konkreten Commit, stellt sich diese Frage dem Leser erst gar nicht.
Und Du kannst Dir ja selbst mal ansehen, was da bei einem "mouseover" für Deinen - jetzt mehrfach wiederholten - Link angezeigt wird - kein Mensch klickt ständig auf jeden Link in so einem Kommentar, weil er dann auch leicht die Seite mit den Anfängen einer eigenen Antwort "verblättert" (die Links öffnen leider nicht automatisch neue Fenster oder Tabs), die dann "verloren" sind, weil es keine zwischenzeitliche automatische Sicherung eingegebener Texte im GitHub-GUI gibt (m.W. immer noch nicht) - oder vielleicht gibt es die, dann aber cookie-basiert und deren Speicherung hat man manchmal ja auch deaktiviert.
Von mir aus UNTER dem Verlinktem
Für alle anderen Geräte (also die, für die AVM eine Labor-Firmware veröffentlicht hat) ist das damit aber auch ausgeschaltet
(solange die [...]_07_25_MAX-Bedingung aktiv ist) und um die geht es eigentlich bei der Frage, die den Titel hier bildet.
Warum nicht einfach ein Link auf einen Hash? Dann stellt sich die Frage gar nicht erst und für den sieht man dann beim "mouseover" auch ganz einfach die Commit-Message - wenn die dann auch noch aussagekräftig ist, weiß automatisch jeder, was gemeint ist und wenn ihn der INHALT dann tatsächlich noch zusätzlich interessiert, DANN kann er auch den Link öffnen lassen (am besten gewöhnt man sich an (wenn man selbst schreibt), das nur "in new tab|window" zu machen).
Ansonsten: Ja, wenn dieser Stand im Moment in Freetz-NG nutzbar ist, ist das immer noch besser als gar keiner ... zumindest für diejenigen, die das (Unter-)Projekt in ihr Freetz-Image einbauen lassen wollen.
Aber DAS ist eben exakt wieder die Situation, die ich mit dem Vorschlag für das freetz-ng-version-Tag vermeiden wollte - damit die jüngsten Änderungen für Freetz-NG-Benutzer verwendbar werden (u.a. ist ja eine Protokollierung für den bootmanager.service dazu gekommen, weil das noch eine relativ neue Erweiterung ist, wo ein Benutzer vielleicht auch mal auf meine Bitte hin ein paar Tests machen können sollte), mußt Du erst den neuen Hash in Freetz-NG übernehmen und DANACH erst würde beim nächsten Build anhand des geänderten Hash-Wertes für das "Download-Paket" auch ein neuer Checkout erfolgen (wenn das nicht wieder irgendwo zum Download bereitgehalten wird, was ich jetzt aber gar nicht als Thema aufwärmen will).
Und die Benutzung des "festen" Hashwertes im Makefile sichert auch nicht wirklich ab, daß da IMMER ein Download/Checkout möglich ist - wenn ich tatsächlich ein rebase für einen bereits gepushten Branch machen sollte, verschwindet so ein Hash auch mal aus einer Commit-History (ein Tag würde man ja ABSICHTLICH neu setzen) und wenn dann noch ein prune für das Repo dazukommt, bei dem "orphaned" Hashes aus dem "reflog" entfernt werden, gibt es den ggf. nicht mal mehr dann, wenn man den Hash kennt und den Stand "gezielt" auslesen will.
Es sind ja nicht nur "handling"-Gründe, warum auch andere Projekte einen aktuell "freigegebenen" Stand mit Tags markieren und nicht (primär, denn selbstverständlich zeigt so ein Tag am Ende auf einen Hash) mit einem Hash-Wert - auch wenn sich Tags natürlich "besser lesen lassen". Wenn ich jetzt den Stand 0.8.3 "freigegeben" habe und daran danach aber noch Änderungen vornehmen muß/will, dann MUSS ich daraus ja nicht den Stand 0.8.4 (oder 0.9.x) machen, sondern DARF nach diesen Änderungen auch das Tag für die 0.8.3 auf den korrigierten Stand schieben.
Man kann ja einfach diese neue Option auswählen, dann nutzt man den dynamisch gesetzten tag
Das muß man nur wissen (welcher Freetz-NG-Benutzer tut das?) und obendrein muß man sich noch zum "Developer" erklären (welcher Freetz-NG-Benutzer tut das?), wo dann auch noch ausdrücklich steht:
WARNING - DO NOT USE DEVELOPER
... welcher Freetz-NG-Benutzer ignoriert das einfach?
Ich habe ja gar kein Problem damit, wenn Du das NICHT ändern willst - aber bitte höre damit auf, mir ständig zu erklären, wie ich irgendetwas in Freetz-NG ja TROTZDEM machen könne, wenn ich nur "diese drei (vier, fünf, was auch immer) kleinen Punkte" dabei beachte.
DAS erinnert mich tatsächlich an zu viele fruchtlose Diskussionen mit ehemaligen Maintainern des Freetz-Projekts, wo auch mit Argumenten nichts zu machen war und mir immer nur irgendwelche kruden Alternativen vorgeschlagen wurden, die das Problem aber nicht lösen konnten (was nicht mal wirklich mein's war, sondern nur meine Beurteilung der "usability" für "die Benutzer", wenn schon diejenigen, die sich mit der Materie etwas besser auskennen, mit der Benutzung Probleme haben).
Speziell fällt mir da eine Diskussion zum mconf und der Arbeit, die jemand in seine "passende" Paketkonfiguration (inkl. BusyBox) gesteckt hat, ein und einem Ansatz, diese Arbeit auch irgendwie über einen Modellwechsel oder gar in einer neuen Kopie des Build-Systems weiterhin zu verwenden, ohne sie noch einmal zu beginnen ... und dabei dann dennoch zu einer passenden(!) Konfiguration für die Toolchain zu kommen, was nachgewiesenermaßen mit den stattdessen vorgeschlagenen "Workarounds" aber nicht funktionierte.
Die Hürden, die für "normale Freetz-NG-Benutzer" jedenfalls vor der Nutzung einer getaggten Version des YourFritz-Repos liegen, sind deutlich höher, als Du sie jetzt erscheinen lassen möchtest - so viel Ehrlichkeit muß dann doch sein.
Das ist ja auch kein Beinbruch - ich hatte das hier: #43 (comment) tatsächlich als "echte Frage" mißverstanden (nicht zum ersten Mal, im Vergleich mit manchen Deiner Beiträge, war das Orakel von Delphi nachgerade überspezifisch in seinen/ihren Aussagen - auch nicht das erste Mal, wo ich versuche, Dir dieses zu verdeutlichen), wie man sicherlich auch an meiner Antwort sehen kann ... ich entschuldige mich aber auch aufrichtig dafür, daß ich von Dir eine solche "ernsthafte Frage" in Betracht gezogen habe (soviel Sarkasmus leiste ich mir dann doch auch noch).
Aber erneut ... laß uns das beenden, ehe es irgendwann doch wieder entgleist - man MUSS ja tatsächlich nicht immer derselben Ansicht sein, wenn man GEMEINSAM nach einer Lösung suchen will und das wäre ja noch an anderen Stellen erforderlich, während hier schon "zu ist".
@fda77 / @PeterPawn:
Habe jetzt Eure Diskussion hier nicht durchgelesen, aber die Kette der Änderungen an https://github.com/Freetz-NG/freetz-ng/commits/master/patches/scripts/800-yf_bootmanager.sh führt dazu, dass ...
(im folgenden auf Englisch, da der untere Teil als erstes für den Bug-Report geschrieben wurde, der scheinbar nicht mehr eingestellt werden kann)
Adding the bootmanager in no-freetz mode fails with
adding yf-bootmanager
Target directory: /./filesystem/
Target system version: .
TARGET_SYSTEM_VERSION value is invalid.
There are multiple errors in different commits:
In Freetz-NG/freetz-ng@e509b39:
The following code (removed in this commit) is required to make the code work both in freetz and no-freetz mode
for oem in $(supported_brandings) all; do
www_oem="${FILESYSTEM_MOD_DIR}/usr/www/${oem}"
[ -d "${www_oem}" -a ! -L "${www_oem}" ] || continue
...
done
Freetz-NG/freetz-ng@e509b39 breaks it actually in the freetz mode, which was later incorrectly fixed in
Freetz-NG/freetz-ng@6e876ad breaking the no-freetz mode (branding all is not available in the no-freetz mode).
ABS_BASE_DIR is not available/exported in the no-freetz mode.
In Freetz-NG/freetz-ng@4e70b57
AVM_FW_MAJOR and AVM_FW_VERSION are not available/exported in the no-freetz mode.
Instead of manually providing AVM_FW_MAJOR and AVM_FW_VERSION it is better to let the bootmanager autodetect the values by using
TARGET_SYSTEM_VERSION="autodetect" \
TARGET_SYSTEM_VERSION_DETECTOR=".../tools/yf/toolbox/image/extract_version_values"
One however should checkout YourFritz in a way that it contains toolbox/image/extract_version_values. As of now this file is simply missing in the sparse-checkout of YourFritz.
Auf diese ganzen komischen Issues hatte ich keine Lust mehr, 99% schaffen es nach einem "geht nicht" nicht mal zu nennen bei welchem Gerät. Ausserdem wurde dann immer der Anspruch erhoben dass mit einem Issue irgend jemand imaginäres dies Problem sofort beheben müsste. Da Issues nur automatisch geschlossen werden können alle in der Organisation diese wieder öffnen. Diskussionen sind offen, auch wenn dort Chaos herrscht
Ich denk das grösste Problem ist dass ich keinen Bootmanager verwendet und Peterpawn kein Freetz und so das ganz untermaintaind ist.
Im Freetz-Modues scheint es jedenfalls keine Problem zu geben
applying patch file ./patches/scripts/800-yf_bootmanager.sh
adding yf-bootmanager
Target directory: build/modified/filesystem/
Target system version: 154.07.57
Action from line 2 of patch definitions skipped due to version settings: not below 00.00, but below 07.08 ('sed' for '$LuaFile').
Action ('sed' with commands from file './lua_patch_0708.sed') from line 4 of patch definitions applied to 'build/modified/filesystem/usr/www/all/system/reboot.lua'.
Action ('sed' with commands from file './js_patch_0708.sed') from line 6 of patch definitions applied to 'build/modified/filesystem/usr/www/all/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 succeeded.
Action ('cp' of file './bootmanager' as 'build/modified/filesystem/usr/bin/bootmanager') from line 12 of patch definitions succeeded.
Action ('cp' of file './bootmanager_server' as 'build/modified/filesystem/usr/bin/bootmanager_server') from line 14 of patch definitions succeeded.
Action ('cp' of file './bootmanager.service' as 'build/modified/filesystem/lib/systemd/system/bootmanager.service') from line 16 of patch definitions succeeded.
Wie man no-freetz verwendet weiss ich gar nicht
Zuerst sollte gesagt werden dass Freetz die Details über die 2. FW entweder vom BM erhält oder selbst sucht (cacht nach dem starten). Allerdings ist die Bootmanager Implementartion lückenhaft und Peterpawn möchte dass es so bleibt. Dieser commit (wie jeder andere nicht von ihm) darf laut ihm nicht verwendet werden und er möchte diesen auch nicht mergen: 487a9b0 Daher würde ich denn Bootmanager aktuell nie mit Freetz nutzen.
Instead of manually providing AVM_FW_MAJOR and AVM_FW_VERSION it is better to let the bootmanager autodetect
One however should checkout YourFritz in a way that it contains toolbox/image/extract_version_values.
Das ist auch so ein Peterpawn Ding. Denn laut ihm hat jede Datei in seinem Repo eine andere Lizenz (nicht die die Github vorne anzeigt, wie kommt man auf so eine Idee?). Da es mir zu viel Aufwand ist und auch keine Lust hatte sind nur absolut nötige Verzeichnisse in Freetz. Und deshalb sind auch die verschiedenen Verzeichnis verschieden Pakete in Freetz. toolbox/ müsste theoretisch müsste dieses Verzeichnisse ein eigenes Package werden das von andere ausgewählt wird.
Da sind 2 Variablen vielleicht doch einfacher...
Im Freetz-Modues scheint es jedenfalls keine Problem zu geben
Ich habe den Fehler ja auch nur für den no freetz-Modus gemeldet ;-)
Wie man no-freetz verwendet weiss ich gar nicht
Der no freetz-Modus wird aktiviert, indem die Option FREETZ_FWMOD_SKIP_MODIFY auf y gesetzt wird.
Zuerst sollte gesagt werden dass Freetz die Details über die 2. FW entweder vom BM erhält oder selbst sucht (cacht nach dem starten). Allerdings ist die Bootmanager Implementartion lückenhaft und Peterpawn möchte dass es so bleibt. Dieser commit (wie jeder andere nicht von ihm) darf laut ihm nicht verwendet werden und er möchte diesen auch nicht mergen: 487a9b0 Daher würde ich denn Bootmanager aktuell nie mit Freetz nutzen.
Diesen Absatz habe ich nicht verstanden, sprichst Du von Freetz zur Laufzeit oder doch zur Build-Zeit (ich tendiere eher zur Laufzeit). Der 487a9b0 (wenn ich ihn richtig lese und verstehe) erweitert die Ausgabe nur um die Versionen der Mods, die auf der aktiven und auf der passiven Partitionen angewandt wurden. Nette Information, wenn sie vorhanden ist, aber lückenhaft würde ich die YourFritz-Implementierung vom Boot-Manager deswegen nicht bezeichnen.
Das ist auch so ein Peterpawn Ding. Denn laut ihm hat jede Datei in seinem Repo eine andere Lizenz (nicht die die Github vorne anzeigt, wie kommt man auf so eine Idee?). Da es mir zu viel Aufwand ist und auch keine Lust hatte sind nur absolut nötige Verzeichnisse in Freetz. Und deshalb sind auch die verschiedenen Verzeichnis verschieden Pakete in Freetz. toolbox/ müsste theoretisch müsste dieses Verzeichnisse ein eigenes Package werden das von andere ausgewählt wird. Da sind 2 Variablen vielleicht doch einfacher...
Keine Ahnung, was da der Mehrwert von "jedes benötigte Unterverzeichnis von YourFritz ist ein separates Freetz-host-Paket" ist. Aus meiner Sicht wäre es einfacher YourFritz einmalig als Paket auszucheken (so wie das früher der Fall war) und dann halt auf die entsprechenden Verzeichnisse zuzugreifen. Dass PeterPawn diese Art der Verwendung nicht gemeint hat, zeigt ja die Tatsache, dass er (oh Gott, wie konnte er nur) die Symlinks verwendet ;-). In dem Boot-Manager-Verzeichnis ist die für den autodetect-Modus benötige Datei extract_version_values nun mal ein Symlink, der in dem Freetz-host-Paket einfach ins Leere zeigt.
Ich habe für meine Zwecke die Pfade in 800-yf_bootmanager.sh hartkodiert und wieder auf den autodetect-Modus umgeschaltet, indem ich die Datei extract_version_values händisch dorthin kopiert habe, wo sie benötigt wird. Und das in dem no freetz-Modus falsche TARGET_BRANDING="all" wieder entfernt.
Ob ich die Zeit finde, es sauber zu lösen, weiß ich nicht. Betrachte dies jedoch als Bug-Report: in dem no freetz-Modus funktioniert das Hinzufügen des Boot-Managers nicht.
Sollte ich doch mir die Zeit nehmen, so müssen wir lustigerweise erst diese phylosophische Frage klären, ob jedes von Freetz benötigte Unterverzeichnis von YourFritz wirklich ein separates Freetz-Host-Paket sein muss. Ich bin der Meinung, dass es Unsinn ist, schließlich machst Du es mit den anderen von Freetz verwendeten Paketen nicht, warum dann mit YourFritz?
Ah, der "no freetz" modus ist eine Option im menuconfig, danke :)
Wie gesagt, Peterpawn sieht dadurch irgend welche Rechte verletzt. Du musst suchen wo er das schrieb, es müsste irgend wo in der Näch seiner Lizenzänderung von gpl aus sonstwas sein. Welche seiner Dateien welche Speziallizenzen haben hab ich nicht untersucht und ich fand es nicht so spannend. Daher ist in Freetz nur was überblickbar und nötig ist.
Dies PP-Lizenz verbietet zb auch dass der Patch von oben in Freetzgenutzt werden darf
Frag ihn am besten sebst wie das genau ist
Diesen Absatz habe ich nicht verstanden
Genau, es geht um die Details zu Laufzeit
Hmm, wo könnte ich das mit der Lizenz nachlesen? Die Version vom Boot-Manager unter dem Tag freetz-ng-version scheint noch die GPL-Lizenz zu verwenden. Wenn Du diese noch unter GPL stehende Version in freetz-ng verwendest, dann darfst Du diese auch patchen.
Wenn sich später die Lizenz geändert hat und in dieser späteren Version die von Dir genannten Restriktionen eingeführt wurden, dann darfst Du diese spätere Version nicht mehr patchen. Aber eine frühere Version, die noch unter GPL stand, darf gepatcht werden.
Edit: auch die Version vom Boot-Manager in dem main-Branch steht noch unter GPL.
Edit 2: die License hat sich Stand 2023-09-09 seit 2018 nicht geändert. Und auch 2018 wurde sie nur clarified.
Wie gesagt JEDES UNTERVERZEICHNIS oder gar Datei kann ihre eigene Lizenz haben bei Peterpawn!
DU hat die Pflicht ganz genau zu suchen wenn du aus dem Repo hier was benutzt. Scheinbar bist du genau so blöd wie ich...
Es gibt dazu irgend wo ne längere Diskussion wo ich wissen wollte was das genau bedeuten mag btw wo die EXPEPTIONS überhaupt stehen.
Das Problem vom no-freetz modus ist jedenfalls dass es in build/modified ausgeführt wird
--
imported from framework - it's not allowed to copy the functions below (up to the next comment box) to other works
Das ist 1 der Exceptions, steht im Source in einer Datei an Zeile 200+. Bei mit gabs schon Verständnisprobleme was eine "comment box" ist
--
Wow, es ist nicht wie Du gesagt hast, einige Dateien haben ihre eigene Lizenz, es ist noch schlimmer - einige Teile einiger eigentlich unter GPL stehenden Dateien haben ihre eigene Lizenz bzw. Restriktionen. Da hat sich PeterPawn aber was einfallen lassen. Mich würde interessieren, ob es auf der Ebene überhaupt rechtens ist. Auf der Ebene "eine ganze Datei eines sonst unter GPL stehenden Projekts" hat ihre eigene Lizenz kenne ich, aber auf der Ebene von Zeile X bis Y einer sonst unter GPL stehenden Datei wäre mir neu.
Bin mir noch nicht ganz sicher, aber ich würde sagen, @PeterPawn verstösst gegen GPL mit dieser Restriktion.
bootmanager/bootmanager
Stand von Anfang an unter GPL. Gemäß https://www.gnu.org/licenses/gpl-faq.html#DoesTheGPLAllowModNDA
The GPL says that the modified versions must carry all the freedoms stated in the GPL.
...
You may not distribute any version of the work on a more restrictive basis.
4e81b28 ist eindeutig eine Modifikation eines ursprünglich unter GPL veröffentlichten Werks und darf somit nicht unter einer restirktiveren Lizenz veröffentlicht/verteilt werden. Genau dies wird aber in 4e81b28 gemacht.
Auch scheint mir die Bedingung "die kombinierten Lizensen sind compatible" im Sinne von https://www.gnu.org/licenses/gpl-faq.html#WhatIsCompatible nicht erfüllt zu sein. GPL erlaubt explizit das Kopieren. Eine zweite Lizenz, die das explizit verbietet, ist somit nicht mit GPL kompatibel => daher dürfen die beiden Lizensen nicht kombiniert werden.
Auch die Restiktionen bzgl. 487a9b0 sind meiner Ansicht nach nichtig. Es wird ein unter GPL veröffentlichter Teil des Codes modifiziert. Damit darfst Du ihn modifizieren und die modifizierte Version verwenden und verbreiten.
Das ganze ist schon etwas über 1 Jahr her, da verschwimmt weniger wichtiges.. Ich denke auch dass man das nach wie vor Patchen darf etc, aber ich will nicht herumstreiten, das ist immer so viel Geschreibsel. Ich hätte den Bootmanager ja einfach aus Freetz rausgeworfen :)
Er will halt keine Änderungen an seinem Code. Ich glaub du warst dafüt die Ursache, wegen deinen umfangreichen Änderungen am avm-kernel-area tool
Dadurch dass es in Freetz je Verzeichnis Packages (aktuell 3?) sind kann man einzelnes updaten oder zurückhalten was man noch nicht möchte. Und man bekommt keinen Sachen dazu die man nicht will...
Durch die letzten Commits müssten alle Patches in Freetz als auch no-Freetz Modus funktionieren, fwmod_custom wird nun aus ./ und nicht build/modified/ aufgerufen. Ich finde das war eine komische Idee. Die 2 Versions-Variablen hab ich einfach mitgegeben.
Durch die letzten Commits müssten alle Patches in Freetz als auch no-Freetz Modus funktionieren, fwmod_custom wird nun aus ./ und nicht build/modified/ aufgerufen. Ich finde das war eine komische Idee. Die 2 Versions-Variablen hab ich einfach mitgegeben.
Hab's getestet, geht. Danke!
Das mit dem neuen Aufrufpfad ist etwas suboptimal, alle custom-Scripts müssen nun angepasst werden. Aber OK. So kann man auch rausfinden, wer das (außer mir) überhaupt nutzt :-)
Gedanken zum no freetz-Modus:
Generell, als ich noch aktiv mitgewirkt hatte, hatte ich immer die Vision, dass freetz eine Art Framework zur Modifikation der Firmware sein soll. Es gibt viele Modifikationen, die es gar nicht benötigen, dass die gesamte Freetz-Infrastruktur reingepatcht wird. Freetz-Build-Umgebung sollte das nach Möglichkeit unterstützen, d.h. ein Untermenü für alle Änderungen, die keiner Freetz-Infrastruktur benötigen und dann ein Untermenü für die Änderungen, die diese zwingend benötigen (auch könnte man dabei feiner als jetzt unterscheiden, welche Freetz-Teile da zwingend benötigt werden, nur die Freetz-Version der uClibc oder auch das Freetz-WebIf, etc.). Auch einzelne wichtige Pakete (wie dropbear/openssh/busybox) könnte man so anbieten, dass sie ohne Freetz-Infrastruktur laufen. no freetz-Modus ist aktuell eine Art Krücke, die diese Vision umsetzt. Man könnte es aber besser machen. Da ich nicht glaube, dass ich je zur aktiven Freetz-Entwicklung zurückkehre, bleibt es wohl bei der Vision, wollte diese aber zumindest einmal laut ausgesprochen haben :-)
Danke fürs testen. Dass die gleichen Script mit verschiedenem Context aufgerufen werden hat bei allen funktioniert, ausser dem Bootmanager. Evlt hätte man dessen Code analsysieren können und noch weitere Variablen gefunden die man mitgeben müsste.
Das sind so komisch uralten Designentscheidungen von Freetz, die man entweder einfach absrtellen kann oder für immer workarounden muss.
Es ist jedenfalls sehr lange niemandem aufgefallen dass der BM mit no-freetz nicht mehr funkioniert :)
Ich musste mein fwmod_custom script nicht ändern, da ich überall $FILESYSTEM_MOD_DIR genutzt hatte. Ich mache nachher aber noch einen NEWS Eintrag.
Das was du umschreibst ist (hab ich mir nie genau angeschaut) wohl etwa so wie Peterpawns "modfs". Das kann packen+entpacken und ein paar Patches anwenden. Allerdings kann das nur manche Geräte packen
Was freetz zwingend ändert hab ich versucht hier zusammenzustellen: https://github.com/Freetz-NG/freetz-ng/tree/master/patches/scripts#readme
Das ist entstanden bei der Fehlersuche weshalb ein Fretz image nicht lief. Auch diese Option
https://github.com/Freetz-NG/freetz-ng/blob/master/make/busybox/Config.in#L672 war dafür
Ich hab aktuell nicht vor noch allzuviel zu machen, nur noch für libctlmgr/libmutlid mit dsld/ctlmgr/multid/rext die neuerdings systemd-services sind. Die ganzen updaten von Geräten+Packages geht meist automatisch und ich lese nur drüber
Nach längerem Überlegen, ob ich mich dazu überhaupt noch einmal äußern will oder nicht, nun doch noch (auch hier letztmalig) ein paar Gedanken meinerseits:
Zum Punkt "spezielle Lizenzbedingungen" für die Datei bootmanager:
- nur für diese gilt bisher die Einschränkung, daß Teile der Datei nicht von Dritten bereitgestellt werden dürfen
- es ist exakt markiert in der Datei, welche Funktionen davon betroffen sind (Zeilen 250 bis 304)
- wer die Datei (egal ob in modifizierter oder originaler) Form irgendwoanders bereitstellen möchte, kann das ja gerne tun, jedoch nur ohne die markierten Teile, die eben unter einer anderen, restriktiveren Lizenz stehen
- diese Lizenz basiert zwar auf der GPL, jedoch werden auch zusätzliche Bedingungen formuliert, die letztlich einem definierten Zweck dienen - nämlich zu verhindern, daß ältere Implementierungen von "Bibliotheksfunktionen", die zur einfacheren Handhabung (sprich: Verringerung der Anzahl von Dateien und Abhängigkeiten zwischen Dateien) zu einer einzigen Datei zusammengezogen wurden (vergleichbar mit dem statischen Linken bei "echten" Bibliotheken) am Ende an irgendwelchen anderen Stellen in diversen älteren, ggf. auch falschen Versionen herumdümpeln und - obwohl ggf. an der Quelle bereits mehrfach aktualisiert und korrigiert - am Ende zu dem Eindruck führen, der Autor würde sich gar nicht weiter kümmern
- denn die meisten Autoren von eigenen Änderungen verzichten ja leider auch gerne auf korrekte Kennzeichnung ihrer Änderungen in den betroffenen Dateien und nicht nur in irgendwelchen Commit-Messages, die eben keinen direkten Zusammenhang zu den geänderten Dateien haben, wenn diese außerhalb des Repos mit den Commit-Messages bereitgestellt werden - obwohl auch die Bedingungen der GPL da eindeutig etwas anderes fordern
- zusätzliche oder alternative Bedingungen zur GPL sind durchaus auch "üblich" (wenn auch nicht soo häufig), es gibt sogar Listen solcher Zusatzlizenzen, die u.a. für automatisierten Abgleich genutzt werden können (https://spdx.org/licenses/ ff.)
- die Lizenzbedingungen für jede Datei (sofern diese solchen unterliegt und nicht nur irgendeine
README.mdo.ä. ist, bei denen schon die "schöpferische Höhe" nicht gegeben sein dürfte) sind auch maschinell auswertbar (zur Spezifikation siehe https://spdx.dev/) - der "Mehraufwand" für den Verwender ist also durchaus überschaubar (vor allem, wenn da CI/CD im Spiel ist), sofern man passende Tools verwendet - die "gemischte" Lizenz für
bootmanagerleitet sich u.a. auch aus der Lizenz für die (teils auch noch unveröffentlichten) Bibliotheken für die Shell-Programmierung ab, deren "Ansätze" man hier findet: https://github.com/PeterPawn/YourFritz/blob/_scriptlib/scriptlib/yf_uiYourFritz/scriptlib/yf_template
Line 31 in b57fc7b
- als bisher - meines Wissens - einziger Autor für dieses (Teil-)Projekt
bootmanagersteht es mir nun einmal frei, unter welchen Bedingungen ich den Code an Dritte lizenziere und leider habe ich da in den vergangenen Jahren auch zu viele schlechte Erfahrungen gemacht ... sonst wäre ich vermutlich auch nie auf diese Ideen gekommen - die von @er13 zitierten Bedingungen aus der GPL gelten für die jeweiligen Lizenznehmer und nicht für den/die Lizenzgeber ... mein Code ist auch nicht der erste, für den im Zuge der Weiterentwicklung Lizenzbedingungen geändert wurden - siehe die vielen Fälle, wo nur ältere Versionen weiterhin unter OpenSource-Lizenzen bereitgestellt werden und die ganzen Weiterentwicklungen nur unter anderen (i.d.R. kommerziell ausgerichteten) Lizenzen verfügbar sind - hier nenne ich mal OpenVPN als Beispiel: https://openvpn.net/)
Wie ist der bootmanager zu installieren?
- das ist seit mehr als vier Jahren ebenfalls (meines Erachtens auch in der gebotenen Ausführlichkeit) beschrieben: 77fb6f7 + 77fb6f7 und darin habe ich auch den Aspekt, daß das Skript zum Erkennen der Version eben nicht innerhalb des
bootmanager-Verzeichnisses liegt, erwähnt ... ebenso die Tatsache, daß man den Pfad dorthin (oder zu irgendeinem anderen Skript, was "aufrufkompatibel" ist) ebenfalls per Environment festlegen kann - ich halte es nicht für "unbotmäßig" zu erwarten, daß es die Verwender dann auch lesen und berücksichtigen, zumal das nun auch keine "rocket science" ist
Zum Inhalt von 487a9b0:
-
ca. drei Monate, nachdem ich die Kommunikation mit Dir (@fda77) für beendet erklärt hatte (#43 (comment)) verfaßt Du dann plötzlich diesen PR und wirfst ihm mir mehr oder weniger vor die Füße
-
Ja, es hat nicht einmal für eine etwas ausführlichere Beschreibung dessen gereicht, was mit diesem Änderungsvorschlag eigentlich bewirkt werden sollte und auch die von Dir aufgestellten Prämissen teile ich praktisch überhaupt nicht (s.u.).
-
Jedes der möglichen (und ggf. auch künftigen) "marker files" enthält in der allerersten Zeile irgendeine Versionsnummer, anhand derer die Versionen auch bereits eindeutig unterschieden werden können? Was ist denn z.B. damit, daß andere Frameworks darin durchaus auch in anderen Formaten (u.a. XML) Informationen hinterlegen könnten?
-
Warum tragen nach Deiner Ansicht dann alle Installationen, bei denen das modifizierende Framework nicht erkannt werden kann oder die gar nicht modifiziert wurden (im alternativen Slot kann ja durchaus auch eine originale AVM-Version installiert sein) die Versionsnummer
1? Gibt es dafür irgendeine plausible Erklärung? Wenn ja, warum steht die dann nirgendwo? -
Man kann ja (denke ich jedenfalls) in meinem Code recht gut sehen, daß ich die Abhängigkeiten von verfügbaren Shell-Kommandos so gering wie möglich halten will bzw. gehalten habe und im gesamten Code bisher nicht ein einziges Mal auf das
head-Kommando zurückgegriffen habe, auch wenn das im POSIX-Standard definiert sein mag. Man kann sich bei AVM eben nie wirklich sicher sein, daß ein zuvor vorhandenes Applet auch weiterhin (für die Ewigkeit) in der AVM-Software enthalten sein wird - es gab genug Gegenbeispiele in der Vergangenheit. -
Warum sollte man (oder ich) hier also - ohne jede Not - plötzlich ein weiteres Kommando verwenden, wenn doch dieselbe Aufgabe genauso gut mit anderen Befehlen (z.B.
sed -n -e 1p, was bisher dafür auch immer verwendet wurde, wenn die komplette Zeile zu lesen war) zu lösen ist? -
Was ist eigentlich mit einer Fehlerbehandlung für den Fall, daß mit dem
head-Kommando keine Daten gelesen werden können, weil z.B. das File leer ist (aber dennoch existiert)? -
Mein Fazit zu Deinem PR: Eine Zumutung und da die Kommunikation (zuvor) ohnehin (weitestgehend) ergebnislos war, hielt ich es nicht für nötig, darauf auch nur irgendwie zu reagieren - zumal nicht einmal die primitivsten "Benimmregeln" (u.a. eine sinnvolle Commit-Message und/oder irgendeine passende andere "Kommunikation", was das Ganze eigentlich bezwecken soll bzw. wo da der Schuh warum drückt) eingehalten wurden.
So sehe ich das jedenfalls und ich habe (bisher) nichts gelesen, was mich von dieser Ansicht abrücken ließe ...
Ich wäre ja sogar bereit, die Notwendigkeit zu akzeptieren, daß man auch aus der Installation im inaktiven Slot ein paar zusätzliche Informationen haben möchte (aus der Installation im aktiven Slot kann man die ja i.d.R. direkt selbst auslesen) ... nur würde ich mir dann eher einen etwas allgemeiner gültigen Ansatz überlegen wollen, wie man beim Aufruf festlegen kann, welche Daten man aus dem inaktiven System gerne zur Verfügung gestellt hätte, denn das muß sich ja nicht zwangsläufig auf diese "marker files" beschränken. Da sähe ich dann wieder Verbesserungs- bzw. Einsparpotential, weil man den Code für die unterschiedliche Behandlung der verschiedenen "Image-Formate" nur einmal verwalten (und aufrufen) müßte.
Aber das setzt eben voraus, daß man sich darüber austauscht (oder das zumindest - und zwar sachlich - versucht) und nicht einfach nur irgendeinen Patch hinrotzt, bei dem sich jeder seinen Teil denken soll. Ich habe zwar irgendwann tatsächlich aufgegeben, mich mit Dir zu "unterhalten", aber das hatte eben auch seine Gründe, denn wenn ich jemanden suche, der mir möglichst dumm kommt (Link s.o.), dann mache ich das auch eher in meinem persönlichen Umfeld.
Hatte die Ehre ...
.PeH
Ich find es nach wie vor total übertrieben wegen eine Kleinstfunktion wie Bootmanager so einen riesen Aufwand mit Lizenzen zu machen. Ausserdem vermute ich die Lizensierung ist auch der Grund weshalb du keine PRs magst, bei Mitautoren kann man die Lizenz nicht mehr einfach so wechseln ... ;-) Ich bin sicher dass ich zu diesem Patch/PR irgend wo was geschrieben hab, ich weiss aber nicht mehr in welchem Repo, es könnte was mit den Fiber und/oder Fit Modellen und/oder Bootmanager zu tun gehabt haben.
Ich erinnere Dich gerne noch daran, daß auch Du mit Deiner Praxis, irgendwelche "snapshots" des YourFritz-Repositorys auf irgendwelchen (i.d.R. FTP-)Servern zu "bunkern", auf denen Du Schreibrechte hast und DAMIT dann bei der Suche (der Freetz-NG-Benutzer) nach Download-Quellen zu arbeiten, anstatt den "aktuellen Stand" aus meinem Repository zu verwenden, einen Anteil daran hattest, daß ich da keinerlei Abstriche an meinen Lizenzbedingungen machen werde.
Die Gründe für dieses "Bunkern" kennst/kanntest offenbar auch nur Du und Deine Antworten auf meine "Nachfragen" zu diesem Punkt waren alles andere als plausibel oder gar zwingend.
Aber alles das haben wir auch oft genug "diskutiert" (#45 (comment)) und wenn dann im Verlauf von Deiner Seite nur noch Antworten wie diese kommen:
Frag du doch mal den Peter was jetzt mit dem package bump und seiner lizenz ist, er schafft es nicht mir ne klar Antwort zu geben.
Falls die in seine mehrseitigen Post drin stehen sollte, übersetz mir diese bitte.jo/nö würde reichen
(zu finden hier: #45 (comment))
dann hast Du es einfach nicht länger verdient, daß ich mir die Mühe mache, mit Dir zu kommunizieren. Wenn Du nicht lesen WILLST, was ich meinerseits als Erklärung geschrieben habe, dann lass es ... aber beschwere Dich dann auch nicht, ich würde Dir keine Antworten geben.
DAS ist es auch, was ich damit meinte, als ich schrieb, ich suche mir schon selbst aus, wer mir wie dumm kommen darf, bevor ich den Kanal voll habe.
Und auch das hier schreibe ich nur noch einmal als Erwiderung, damit sich niemand mit Deinen (falschen) Behauptungen als "Schlußpunkt" in dieser Diskussion anfreundet - ich WILL einfach nicht mehr, wenn irgendetwas im Kontext von Freetz und/oder Freetz-NG steht und ich habe das ja mittlerweile auch schon eine sehr, sehr lange Zeit durchgehalten.
Mein "Rückfall" ist/war nur der Tatsache geschuldet, daß da plötzlich von @er13 ein paar Theorien aufgestellt wurden, die ich so auch nicht stehen lassen wollte, zumal er es zuvor ja auch nicht für erforderlich hielt, sich die GANZE GESCHICHTE dazu durchzulesen, Zitat:
Habe jetzt Eure Diskussion hier nicht durchgelesen (#43 (comment))
Ich fange nach dem Absenden dieses Beitrags dann auch wieder damit an, mich nicht länger zu äußern, sofern es um Freetz/-NG geht ... und die Frage, ob und wenn ja, wie man den Bootmanager dort integrieren kann oder ob man ihn lieber komplett entfernen sollte, gehört da auch schon dazu.
Denn damit hast Du (@fda77) ja auch nicht nur einmal "gedroht" bzw. es sogar ausgeführt (nur die Nachfrage von anderen Benutzern führte dazu, daß Du ihn wieder "aufgenommen" hast) und vieles von dem, was ich ursprünglich mal entworfen habe für die Arbeit mit FRITZ!Boxen, hast Du ja dann auch (ziemlich schamlos - wenn auch ohne Verstoß gegen Urheberrechte) "nachprogrammiert". Ich vermute einfach mal, beim Bootmanager bist Du mit dem Zerlegen von FIT-Images und der Suche nach dem Konfigurationsbereich mit den Daten aus der Finalisierung dann nur überfordert, ansonsten hättest Du auch das noch versucht durch Deine eigene Version zu ersetzen.
Ich bin sicher dass ich zu diesem Patch/PR irgend wo was geschrieben hab, ich weiss aber nicht mehr in welchem Repo
Auch das zeigt noch einmal, daß Du absolut nichts verstanden hast von dem, was ich (ständig) an Kritik geäußert habe.
Es interessiert kein Schwein, ob Du IRGENDWO an einer anderen Stelle noch etwas zu Deinem PR geschrieben hast oder nicht. Das gehört IN den PR (im Minimalfall als Link auf diese "andere Stelle", obwohl auch das schon grenzwertig wäre), weil NIEMAND sich die Mühe machen will (und das auch nicht müssen sollte), erst noch einmal alles das zu durchsuchen, was DU vielleicht dazu an anderer Stelle geschrieben hast.
Zumal ja alle anderen Punkte, warum ich diesen PR ohnehin abgelehnt hätte, weiterhin ihre Gültigkeit haben bzw. behalten ... ja, Du hast es ja nicht einmal geschafft, diesem PR einen wirklich stimmigen Titel zu geben, denn wenn man sich den Inhalt ansieht, wird da ja keineswegs nur ein "add active_modified_version" ausgeführt, sondern es erfolgen noch weitere Änderungen.
Ob Du jetzt irgendetwas "total übertrieben" findest oder nicht ... es bleibt meinerseits dabei. Punkt.
Ich werde das hier auch nicht sofort "locken", falls noch jemand etwas beitragen möchte ... aber in einer Woche mache ich hier ein Schloß dran und spätestens dann ist das Thema durch.
Ich korrigiere meine frühere Aussage, daß @fda77 mir 487a9b0 nach drei Monaten vor die Füße geworfen hätte, dahingehend, daß es sich nur um drei Tage handelte, nachdem ich endgültig die Nase voll hatte und das auch (ich denke schon, auch sehr klar) zum Ausdruck gebracht habe: #45 (comment)
Freetz hat schon immer Mirror für langsame Downloads genutzt bei Repos ist die Revision/Hash im Dateinamen. Ist das laut deines Lizensframeworkes auch illegal? Freetz-NG/freetz-ng#861
Wenn dich am PR der Comment störte hättest du ihn einfachst beim mergen auf der Githubseite anpassen können, das bekommt jeder Mausschubser hin. Du hättest dich zeilenweise austoben können!
Ich hab auch kein Lust wegen dem BM ewig herumzudebattieren, wie die bemerkt hast hätte ich keine Problem ihn rauszuwerfen da ich den weder benutze noch brauche. Es ist halt nur blöd dass wegen deines Dickkopfes auf der Freetz System-Seite weniger Infos angezeigt wenn der BM mitausgewählt ist als ohne.
Aber ich schicke die Leute die es wundert mit passender Erklärung einfach zu dir weiter
... wobei ich auch gleich eine Warnung ins menuconfig und einbauen könnte weshalb die Infos fehlen
Der BM lauft doch auf FIT Boxen richtig.
Und es wurde nichts an BM geändert, nur in freetz-ng.
Und genau deshalb gibts wie auf deinem Screenshot zu sehen keine Infos zum Freetz in der inaktiven Partition. Ich habs dir mal markiert:
So wie du es in freetz-ng hast, bekommst man da überhaupt nichts zusehen. Denn da steht dann FritzOS UNKNOWN.
Auf der 5590 habe ich die Information, die du da haben willst
Mir auch egal, ob diese Zusatzinfo da nun steht oder nicht. Sol lange da überhaupt was steht, das ist viel wichtiger. Weil diese 22613M-67cbca0dc bringt ein doch so oder so nichts. Denn freetz bekommt jedes Mal eine neue Bezeichnung, wenn nur einmal eine neue FW da ist. Das Datum ist da viel wichtiger.
Daher einfach weiter machen, bin wieder raus hier
Dir ist schon klar dass das eine die aufsteigende svn revision ist und das andere der git hash??? Aber wenn man nichts damit anfangen kann ist es wirklich Wurst
Ich glaube, es ist einfach schauen, was am 13.09.2023 gekommen ist. Als, wenn ich denn hash suchen 517a49e0c
Ich hab leider keinen öffentlichen SVN Server
