Fehler bei Systemauswahl im Freetz im "no freetz" Modus für 7590

reinelektronik

Neuer User
Mitglied seit
6 Dez 2007
Beiträge
59
Punkte für Reaktionen
0
Punkte
6
Hallo,

bei der erstellten Firmware für FB7590 mit Ver.7.01 im no freetz Modus ist bei Neustart die Meldung vorhanden:
Lua Load Syntax ERROR /usr/www/avm/system/reboot.lua:93 [string "/usr/www/avm/system/reboot.lua:93"]:4: unexpected symbol near '<'
im ersten Teil bei der Systemauswahl und die Auswahl gibt es nochmal und dort kommt:
Luacgi Parse ERROR in file /usr/www/avm/system/reboot.lua line 107: ?> without <?lua or <?include

und eine Umschaltung über diese Auswahl ist möglich auch wenn ich das vorherige System anklicke und neu starten lassen geht es immer auf das jetzige und Telnet geht in der Version auch nicht ich muss dann auf EVA gehen um das alte System zu starten.

Wo liegt da denn der Fehler.

Gruß Reiner
 
Selbst mit Patch hat bei mir die Datei "usr/www/avm/system/reboot.lua" keine 93 oder gar 107 Zeilen (und ja, es ist die aus der 154.07.01):
Code:
  1 <?lua
  2 g_page_type = "all"
[...]
  8 if box.post.linux_fs_start then
  9 local linux_fs_start = string.gsub(box.post.linux_fs_start, "'", "")
 10 local branding = box.post[linux_fs_start.."_branding"] ~= nil and string.gsub(box.post[linux_fs_start.."_branding"], "'", "") or ""
 11 os.execute("/usr/bin/gui_bootmanager switch_to '"..linux_fs_start.."' '"..branding.."'")
 12 end
 13 webuicookie.set_action_allowed_time()
[...]
 68 <form action="/system/reboot.lua" method="POST">
 69 <div id="managed_reboot" class="reboot_managed">
 70 <?lua
 71 pipe = io.popen("/usr/bin/gui_bootmanager html_display")
 72 line = pipe:read("*a")
 73 pipe:close()
 74 box.out(line)
 75 ?>
 76 </div>
 77 <div id="btn_form_foot">
[...]
 88 </script>
 89 <?include "templates/html_end.html" ?>
[ Ich habe die meisten Zeilen gelöscht, damit die Datei nicht als "Vollzitat" erscheint, weil sie halt dem Urheberrecht von AVM unterliegt - wie hoch die Schöpfungshöhe sein mag und ob das für die eigene Verwendung geändert werden darf oder nicht, ist hier nicht das Thema, es geht mir um die "Veröffentlichung" des AVM-Codes in Gänze. ]

Die Zeilennummer ändert sich auch durch "include"-Statements nicht ... wenn ich in Zeile 70 das "<?lua"-Tag für den serverseitigen Code absichtlich ändere (bei einer 7490 mit 07.01, aber das sollte keinen Unterschied machen), kriege ich die Nachricht:
Code:
Lua Load Syntax ERROR /usr/www/avm/system/reboot.lua:71 [string "/usr/www/avm/system/reboot.lua:71"]:2: '=' expected near 'pipe'
, obwohl auch davor schon (in Zeile 44 und 55) zwei "include"-Statements stehen.

Mir fehlt etwas die Phantasie, was hier passiert sein soll ... ich habe zwar keine Ahnung, wie "modpatch" im Inneren arbeitet (und überhaupt keinen Ehrgeiz, das zu erkunden), aber eigentlich kann das dann nur bei der Integration schieflaufen in https://github.com/Freetz/freetz/blob/master/patches/scripts/800-modfs_boot_manager.sh - aber nur "Theorie" ohne jeden Beweis und jeden Versuch, das tatsächlich zu ergründen.

Die Fehlernachrichten weisen darauf hin, daß da eine Zeile "<?lua" irgendwie falsch ersetzt wurde ... nun hat ja das "?" innerhalb von regulären Ausdrücken eine spezielle Bedeutung und wenn das beim "modpatch" irgendwie gesondert behandelt würde, wäre das zumindest eine Erklärung.

Denn eine Zeile 70 in der Form:
Code:
<?lua<
führt auch bei mir zu der Fehlermeldung:
Code:
Lua Load Syntax ERROR /usr/www/avm/system/reboot.lua:71 [string "/usr/www/avm/system/reboot.lua:71"]:1: unexpected symbol near '<'
... aber eben mit vollkommen anderen Zeilennummern und die zweite interessante Frage hier wäre ja, wo die zusätzlichen Zeilen in der "reboot.lua" am Ende herkommen sollten (das liefert vermutlich auch die Erklärung dafür, warum das im Ergebnis syntaktisch falsch ist).

------------------------------------------------------------------------------------------------

Wobei das Handling der verschiedenen Verzeichnisse unterhalb von "usr/www" durch Freetz ohnehin eher "old school" ist und mit modernen Versionen nicht mehr wirklich etwas zu tun hat bzw. dort einigermaßen unnötig ist und außer möglichen Problemen keine begründeten Vorteile mehr liefert.

Das Zusammenlegen aller vorhandenen Brandings auf "all" (über einen Symlink dorthin) impliziert erstens, daß sich diese Dateien in den verschiedenen Brandings tatsächlich nicht unterscheiden (was zwar meistens, aber eben nicht immer stimmt) und bringt zweitens bei der Verwendung von SquashFS auch keinen wirklich signifikanten Platzvorteil (wobei der Platz ohnehin nicht mehr das größte Problem ist in aktuellen Geräten), weil identische Dateien ohnehin nur einmal im SquashFS gespeichert werden und man nur (unwesentlich) Platz durch wegfallende Verwaltungsinformationen für die Dateien spart.

Wenn hier merkliche Einsparungen zu erzielen wären, hätte sich AVM bestimmt auch schon mal selbst ans Werk gemacht und etwas umgestellt bzw. auf Firmwares mit mehreren "Brandings" verzichtet (einmal müssen die Dateien aber gespeichert werden). Daher bringt auch der "remove patch" für irgendwelche Brandings nicht wirklich etwas (mal abgesehen davon, daß der ohnehin statisch konfiguriert ist und gar nicht dynamisch von der jeweiligen "Vorlage-Firmware" abhängt) und man sollte ihn bei neueren Modellen besser auch weglassen, wenn man sein Image konfiguriert.

TL;DR:
Dazu müßte man den Inhalt der Datei "/usr/www/avm/system/reboot.lua" aus dem betroffenen Firmware-Image kennen, um daraus Rückschlüsse auf die Stelle zu ziehen, wo das Problem seinen Ursprung hat.
 
Zuletzt bearbeitet:
Der yf/bootmanager/patch_system_reboot_lua.patch ist höchstwahrscheinlich mehrfach angewandt worden. Die hohen Zeilennummern, die es bei den anderen nicht gibt, sind ein diese Vermutung stützendes Indiz.

Die mehrfache Anwendung des Patches ist bei der falschen Anwendung von Freetz im "no freetz"-Modus durchaus möglich, es existieren gar keine Vorkehrungen, die das verhindern wie es diese z.B. bei modfs gibt (precheck/postcheck). Die falsche Anwendung ist es, wenn man manche Schritte mehrfach ausführt, dann werden manche Patches eben mehrfach angewandt. Auch erneutes von vorne Starten ohne vorher das build-Verzeichnis zu löschen, kann im "no freetz"-Modus zu solchen Effekten führen.

@PeterPawn:
Deine Ausführungen über /usr/www/$branding treffen hier nicht zu. Und zwar insofern, dass im "no freetz"-Modus die gesamte Verzeichnisstruktur unangetastet bleibt (es sei denn der User hat eigene Befehle in fwmod_custom eingebaut). Von Freetz wird diesbezüglich jedoch nichts verändert.
 
Sorry, die letzten drei Absätze hätte ich besser mit einem <hr /> abgesetzt ... das war nur eine Bemerkung zu den Branding-Verzeichnissen, den "remove patches" und dem erzielbaren Platzgewinn, die mir durch die Ansicht der "for"-Schleife (und dem zusätzlichen "all", auch wenn das über "test -d" und "test ! -L" abgefangen wird) in dem Shell-Skript zum Patchen durch den Kopf ging - das sehe ich gar nicht als Ursache für das hier aufgetretene Problem. Ich werde den "Ruler" einfach noch einfügen ...

Wobei mir die Erklärung mit der mehrfachen Anwendung der Patch-Datei auch nicht einleuchtet. Ich habe zwar tatsächlich nur sehr wenige "Ankerzeilen" benutzt (nur eine davor und eine danach): https://github.com/PeterPawn/YourFritz/blob/master/bootmanager/patch_system_reboot_lua.patch - aber trotzdem sollte bei der zweiten Anwendung eigentlich keine passende Kombination der zwei "vorher"-Zeilen mehr zu finden sein und zwar für keinen der beiden Hunks im Patch-File. Und Freetz nutzt ja das Patch-File und nicht das Shell-Skript mit dem "sed" (https://github.com/PeterPawn/YourFritz/blob/master/bootmanager/change_system_reboot_lua.sh) und sollte damit eigentlich auch "safe" sein, was doppeltes Patchen anbelangt - selbst wenn bei der zweiten Verwendung dann "reversed" vorgeschlagen werden sollte vom Patch-Programm, würden die Zeilen ja nur wieder entfernt.

Wenn die Ankerzeilen tatsächlich unzureichend wären, würde ich sie entsprechend erweitern ... die Absicht war ja nur, den Patch so universell wie möglich zu halten und nicht bei jeder AVM-Änderung nachbessern zu müssen und das sollte nicht dafür sorgen, daß mehrfache Anwendung des Patches möglich ist ohne entsprechende Fehlermeldungen.
 
Zuletzt bearbeitet:
Ich habe es jetzt nachgestellt. Beim ersten Durchlauf sieht die Ausgabe so aus:
Code:
  adding modfs boot-manager
    adding boot-manager front end to branding "1und1"
    applying patch file /tmp/bootmanager_system_reboot_lua-RRDTog.patch
    patching file usr/www/1und1/system/reboot.lua
    ----------------------------------------------------------------------
    adding boot-manager front end to branding "avm"
    applying patch file /tmp/bootmanager_system_reboot_lua-RRDTog.patch
    patching file usr/www/avm/system/reboot.lua
    ----------------------------------------------------------------------
    adding boot-manager back end script

Beim zweiten dann so:
Code:
  adding modfs boot-manager
    adding boot-manager front end to branding "1und1"
    applying patch file /tmp/bootmanager_system_reboot_lua-de3yi4.patch
    patching file usr/www/1und1/system/reboot.lua
    Hunk #1 succeeded at 7 with fuzz 1.
    Hunk #2 succeeded at 68 with fuzz 1.
    ----------------------------------------------------------------------
    adding boot-manager front end to branding "avm"
    applying patch file /tmp/bootmanager_system_reboot_lua-de3yi4.patch
    patching file usr/www/avm/system/reboot.lua
    Hunk #1 succeeded at 7 with fuzz 1.
    Hunk #2 succeeded at 68 with fuzz 1.
    ----------------------------------------------------------------------
    adding boot-manager back end script

Edit: was dabei als Anker verwendet wird, ist mir ehrlich gesagt nicht klar, scheinbar nur die Zeilennummer (i.e. der gesamte Kontext wird ignoriert), denn die resultierende Datei sieht so aus:
Code:
1    <?lua
2    g_page_type = "all"
3    g_page_title = ""
4    g_page_help = "hilfe_system_neustart.html"
5    dofile("../templates/global_lua.lua")
6    if next(box.post) and box.post.reboot then
7    local savecookie = {}
8    if box.post.linux_fs_start then
9    local linux_fs_start = string.gsub(box.post.linux_fs_start, "'", "")
10   local branding = box.post[linux_fs_start.."_branding"] ~= nil and string.gsub(box.post[linux_fs_start.."_branding"], "'", "") or ""
11   os.execute("/usr/bin/gui_bootmanager switch_to '"..linux_fs_start.."' '"..branding.."'")
12   end
13   if box.post.linux_fs_start then
14   local linux_fs_start = string.gsub(box.post.linux_fs_start, "'", "")
15   local branding = box.post[linux_fs_start.."_branding"] ~= nil and string.gsub(box.post[linux_fs_start.."_branding"], "'", "") or ""
16   os.execute("/usr/bin/gui_bootmanager switch_to '"..linux_fs_start.."' '"..branding.."'")
17   end
18   webuicookie.set_action_allowed_time()
19   cmtable.add_var(savecookie, webuicookie.vars())
20   box.set_config(savecookie)
21   http.redirect(href.get("/reboot.lua"))
22   end
23   function show_act_calls()
24   local str = ""
25   if config.FON then
26   require"foncalls"
27   local calls = foncalls.get_activecalls()
28   if #calls > 0 then
29   str =[[<div id="uiActiveWarning">
30   <strong>{?txtHinweis?}</strong>
31   <p>{?6729:637?}]]
32   str = str..[[</p><table id="uiActiveCall" class="zebra"><tr class="thead"><th></th>]]
33   str = str..[[<th>{?6729:86?}</th><th>{?6729:309?}</th><th>{?6729:867?}</th></tr>]]
34   for i, call in ipairs(calls) do
35   local symbol = foncalls.get_callsymbol(call.call_type)
36   str = str..[[
37   <tr><td class="]]..box.tohtml(symbol.class or "")..[["></td>
38   <td class="]]..box.tohtml(symbol.dirclass or "")..[[">]]..box.tohtml(foncalls.number_shortdisplay(call))..[[</td>
39   <td>]]..box.tohtml(foncalls.port_display(call))..[[</td>
40   <td>]]..box.tohtml(call.duration or "")..[[</td>
41   </tr>]]
42   end
43   str = str..[[</table></div>]]
44   end
45   end
46   return str
47   end
48   ?>
49   <?include "templates/html_head.html" ?>
50   <link rel="stylesheet" type="text/css" href="/css/default/static.css"/>
51   <link rel="stylesheet" type="text/css" href="/css/default/update.css"/>
52   <style type="text/css">
53   #uiActiveWarning table {
54   white-space: nowrap;
55   }
56   <?lua
57   box.out(general.get_responsive_table_css("#uiActiveCall", "28.125"))
58   ?>
59   </style>
60   <?include "templates/page_head.html" ?>
61   <?lua
62   box.out(show_act_calls())
63   ?>
64   <p>{?6729:135?}</p>
65   <h4>{?6729:753?}</h4>
66   <?lua
67   if config.RAMDISK and box.query("ctlusb:settings/internalflash_enabled") == "1" then
68   box.out('<p>'..[[{?6729:203?}]]..'</p>')
69   <div id="managed_reboot" class="reboot_managed">
70   <?lua
71   pipe = io.popen("/usr/bin/gui_bootmanager html_display")
72   line = pipe:read("*a")
73   pipe:close()
74   box.out(line)
75   ?>
76   </div>
77   else
78   box.out('<p>'..[[{?6729:620?}]]..'</p>')
79   end
80   ?>
81   <form action="/system/reboot.lua" method="POST">
82   <div id="managed_reboot" class="reboot_managed">
83   <?lua
84   pipe = io.popen("/usr/bin/gui_bootmanager html_display")
85   line = pipe:read("*a")
86   pipe:close()
87   box.out(line)
88   ?>
89   </div>
90   <div id="btn_form_foot">
91   <input type="hidden" name="sid" value="<?lua box.html(box.glob.sid) ?>">
92   <button type="submit" name="reboot">{?6729:911?}</button>
93   </div>
94   </form>
95   <?include "templates/page_end.html" ?>
96   <script type="text/javascript">
97   function initActive() {
98   jsl.writeDataLabel("uiActiveCall");
99   }
100  ready.onReady(initActive);
101  </script>
102  <?include "templates/html_end.html" ?>

Man beachte den hinzugefügten Abschnitt innerhalb von "if config.RAMDISK ...", genau da gibt es zwei öffnende "<?lua"'s
 
Zuletzt bearbeitet:
Hmm ... ich finde einfach keine passenden Zeilen für den zweiten Durchlauf in der originalen AVM-Datei und wenn ich das zweimal ausführen lasse (die "reboot.lua" habe ich in das Verzeichnis kopiert), sieht das so aus:
Code:
vidar:/home/GitHub/YourFritz/bootmanager $ patch -p4 < patch_system_reboot_lua.patch
patching file reboot.lua
vidar:/home/GitHub/YourFritz/bootmanager $ patch -p4 < patch_system_reboot_lua.patch
patching file reboot.lua
Reversed (or previously applied) patch detected!  Assume -R? [n] n
Apply anyway? [n] n
Skipping patch.
2 out of 2 hunks ignored -- saving rejects to file reboot.lua.rej
vidar:/home/GitHub/YourFritz/bootmanager $
Also muß es doch irgendetwas mit der Verarbeitung in "modpatch" zu tun haben, denn das "normale" Patch-Kommando reagiert wie erwartet.
 
modpatch als Ursache ist durchaus möglich, dieses toleriert mehr Fuzz's als der regulärer patch. Dies wurde meines Wissens (ich habe modpatch nicht geschrieben) damals deswegen gemacht, damit ein und derselbe Patch bei mehreren Boxen verwendet werden könnte, auch wenn es bei manchen nicht ganz genau passt.
 
Vielleicht wäre es ja dann eine Idee, da das normale "patch" an dieser Stelle zu verwenden ... das stellt zumindest auch dann sicher, daß die Datei "nicht wächst", wenn der Benutzer das tatsächlich mehrfach aufruft im "no_freetz"-Modus.

Wobei auch das automatische Löschen des "modified"-Verzeichnisses sicherlich eine Überlegung wert ist, wenn man Freetz im "no_freetz"-Modus verwendet ... durch "fakeroot" funktionieren i.d.R. ohnehin keine zwei Versuche nacheinander, ohne das "modified"-Verzeichnis zwischendrin zu löschen - so war zumindest mal meine Erfahrung, als ich mit "fwmod" eine 7270v3-Firmware modifizieren wollte in "Einzelschritten".

Auch die Beschreibung (http://freetz.org/wiki/help/howtos/development/repack_fw) gibt das nicht so richtig her, daß der Benutzer selbst für ein Löschen verantwortlich ist ... und zwar nicht nur bei den "Einzelschritten" (-u + -p - da erscheint es notfalls noch logisch), sondern auch bei der (automatischen) Steuerung über "make".
 
OK,

Danke dann werde ich das mit der neue Release probieren. Ich habe es soweit hingebracht das Telnet läuft aber mit der Bootauswahl hat es nicht geklappt dort gibt es im Menü keine Auswahl
 
Das ist wesentlich schneller als die AVM Variante, um genau zu sein
Was genau soll das heißen ... oder auch "was genau ist denn genau"? Inwiefern ist das "schneller" bzw. welche Zeit (bei "schneller" sollte es ja um eine Zeitdauer gehen) wird da von Dir gemessen?

Ich verstehe nicht so ganz, ob das jetzt die Verwendung der alternativen Ausgabe im "gui_bootmanager" ist (also "get_values") oder ob Du das alles noch einmal komplett nachprogrammieren wolltest (über die unterstützten DualBoot-Modelle hinweg, denn das war ja ein Grund für die neue Implementierung, nachdem die erste eher auf VR9-Boxen beschränkt war).

Es geht mich zwar auch nichts an, was Du da wie machst ... aber daß ich im Rahmen von "modfs" diese Möglichkeit direkt in das AVM-Interface einbaue (und nur da), ist ja durchaus Absicht.

Erstens ist da i.d.R. gar kein Freetz-Interface vorhanden auf diesen Boxen und zweitens bedienen die meisten Benutzer ihre Boxen eben doch weiterhin über das AVM-GUI (denn da finden sie das, was sie täglich brauchen - z.B. die Anruflisten oder die Netzwerk-Übersicht - und nicht auf der Freetz-Oberfläche) und da stellt dann eher das Freetz-GUI den "Bruch" dar und die (inzwischen auch deutlich weniger gut dokumentierte) Schnittstelle für den etwas "spezielleren" Fall.

Genau dieses GUI war auch mal der Auslöser dafür, daß ich mich nach etwas anderem umgesehen habe ... zwar bestand der Bedarf, die Firmware zu modifizieren und ein paar zusätzliche Einstellmöglichkeiten bereitzustellen, aber dafür war das Freetz-GUI nun tatsächlich nicht geeignet (jedenfalls nicht "für Laien", das geht schon beim abweichenden Port los, auch wenn im AVM-GUI wohl immer noch ein Link auf das Freetz-GUI erzeugt wird) und es mußte etwas anderes her und damit auch die Möglichkeit, dieses "andere" irgendwie in die Box zu bringen.

Um den "Kern" dieser Behandlung - auch über die verschiedenen Modelle - einheitlich zu haben, habe ich ja die alternative Ausgabe der relevanten Daten vorgesehen und die Kenntnisse, wo in Freetz die passenden Datumsangaben zu finden sind, nachgerüstet.

Unterschiedlicher "Geschmack" war auch der Grund, warum ich das Sammeln der Daten noch einmal sehr deutlich (im Vergleich zur Version davor) von der Erzeugung der Ausgabe entkoppelt habe (auch wenn das - ebenfalls wieder absichtlich - nicht wirklich zwei getrennte Skript-Dateien geworden sind, von denen eine nur die Daten sammelt und die andere nur die Ausgabe erzeugt) ... ich fände es unnütz und Verschwendung von Ressourcen (aka Arbeitszeit), wenn man mehrere konkurrierende Implementierungen (im Kern, also beim Sammeln der Daten) hätte, die sich nur bei der Ausgabe der Daten am Ende unterscheiden.

Die mag durchaus Geschmackssache sein und da soll jeder machen, was er will (das AVM-GUI kennt der Benutzer eben immer auch noch parallel bzw. er muß/sollte es zumindest kennen) ... bisher wußte ich halt nichts von alternativen Ausgaben und das ist auch der Grund, warum bei "get_values" im Moment noch nichts gecacht wird: https://github.com/PeterPawn/YourFritz/blob/master/bootmanager/gui_bootmanager#L1170.Ich überlege, ob man das nicht auf diesen Fall erweitern sollte ... wobei ich bisher eben die gesamte Ausgabe (inkl. generiertem HTML) zwischenspeichere und nicht die gesammelten Daten.

Wobei dieses fehlende Caching ja eher gegen Dein "schneller" oben sprechen würde, denn die Ausführung beim Sammeln der Daten braucht ihre Zeit, wenn man in die inaktiven Partitionen hineinschauen will ... ein weiterer Grund, warum ich das auf "einmalig" umgestellt habe und es (bei der Integration im Rahmen von "modfs") sogar schon beim Start ausführen lasse, wo es mit seinem Zeitbedarf nicht wirklich auffällt und normalerweise ändert sich das ja auch im Laufe eines Startzyklus nicht mehr bzw. in "modfs" ist dann auch wieder ein Refresh für die gecachten Daten eingebaut.

Wenn jemand (plausibel) weitere Daten braucht, würde ich das nachrüsten (sofern es nicht "zu speziell" ist - denn die CS-Nummer von Freetz bringt halt auch nur in Freetz etwas und ist da deutlich leichter zu finden, als im "gui_bootmanager" - um mal ein Beispiel zu nennen) und solange das Datensammeln vom "gui_bootmanager" erledigt wird, fühle ich mich auch für Probleme von Benutzern an dieser Stelle zuständig.

Daher meine "Neugierde" und so würde ich eben gerne wissen wollen, ob jemand die Daten "auf eigene Faust" sammelt, weil ich mich dann nicht "verantwortlich" fühlen müßte, sofern es dabei Probleme gibt.

Wobei es beim Zusammenspiel mit den neueren Inhouse-Versionen (hier habe ich die Unterschiede beim Speichern der Versionsangaben mal festgehalten: https://www.ip-phone-forum.de/threa...r-firmware-intern.294029/page-81#post-2306405) ohnehin auch neue Probleme gibt, weil AVM dort einiges umgestellt hat ... nun kann man erst mal wieder raten, ob das auch Einzug in "offizielle Laborversionen" halten wird (und man es damit als Alternative bei der Suche nach den Versionsangaben implementieren sollte) oder nur ein "Versuchsballon" ist, der wieder verschwindet.

-------------------------------------------------------------------------------------------------

Es wäre aber auch - im Gegenteil zu "eher das Freetz-GUI nutzen" - in meinen Augen inzwischen sogar logischer, wenn man viel mehr vom Freetz-Interface auch in das AVM-Interface integrieren würde ... wobei das bei der Struktur (das ist ja ein CGI-Interface, vorwiegend mit Shell-Skripten) auch nicht ganz einfach ist (ein Delay im Shell-Code ist gleich auch ein "unresponsive interface").

Aber heutzutage würde wohl niemand mehr auf diese Weise ein GUI implementieren ... das ist weder dynamisch noch "responsive" (und auch wenn das deutlich überstrapaziert wird als Schlagwort, haben bestimmte Aspekte davon ja durchaus etwas für sich) und solange man da nicht ständige Refreshs (im Vordergrund, weil eben nicht nur die Inhalte, sondern die gesamte HTML-Struktur aktualisiert würde) macht, ist das immer eine ziemlich statische Angelegenheit und nur ein "Schnappschuß" eines Zustands zum Zeitpunkt, wo dieser erstellt wurde. Dabei wären ja auch ein paar Freetz-GUI-Seiten mit dynamischer Aktualisierung durchaus sinnvoll ... angefangen bei einer "Live-Ansicht" der verbundenen Clients für einen OpenVPN-Server bis hin zur LED-Anzeige für die Boxen, die sich hinter dem Schrank befinden.

Von der Möglichkeit, das auch mit anderen Geräten als einem PC und dem dort installierten Browser (mit entsprechender Auflösung) vernünftig zu bedienen, will ich gar nicht erst anfangen ... aber die Zeiten, wo man irgendetwas fix für "640x480 quer" implementiert hat (ja, ich weiß, daß einige Elemente im Freetz-GUI eine Breite von > 1000 px verwenden), sind lange vorbei und ich möchte mal sehen, wie man das Freetz-GUI auf dem 3,5"-Display eines RasPi bedienen will (das ist die Größe, die zur 3er-Platine paßt und wo das Display nicht die Größe des gesamten Gerätes bestimmt).

Das Freetz-Interface ist also einigermaßen "old style" (nicht nur vom Layout her) und bevor man dem neue Kunststückchen beibringt, sollte man es m.E. (mehr als meine persönliche Ansicht samt Begründung ist das aber auch nicht) erst einmal "modernisieren". Da das aber durchaus größere Anstrengungen erfordert und die heute wohl niemand mehr für Freetz leisten kann (und will), sollte man eher überlegen, ob man nicht für die wichtigsten Pakete ein anderes Interface dazupackt, was sich (meinetwegen nach Wahl des Benutzers - wobei es auch kein "entweder oder" sein müßte) in das AVM-GUI integriert.

Das muß ja nicht gleich heißen, daß die sich dann (wie der "gui_bootmanager" mit seinem "html_display") in eine bereits bestehende AVM-Seite einpassen müssen (das bot sich hier nur an in meinen Augen) ... man kann durchaus auch einen eigenen Menüpunkt dafür erzeugen und darunter dann diese Einstellungen ablegen.

Das mache ich für ein paar Seiten unterhalb des AVM-Punktes "Diagnose" auch so, wo mir der Weg von AVM über "Inhalt" einfach zu beschwerlich ist und die Seiten, die zu den eigenen Erweiterungen gehören, haben dann eben ihren eigenen Menüpunkt (auch um die optisch von den AVM-Seiten etwas abzugrenzen, denn das im Anschluß fehlerhaft anzeigende GUI und die Frage, ob der "normale Kunde" das am Ende AVM anrechnen würde, war ja der einzige Punkt, in dem AVM im Cybits-Prozess einen Teilerfolg verbuchen konnte):
diag_menu_with_yourfritz.PNG

Da muss man ständig AVM hinterherprogrammieren
Das ist beim Boot-Manager bisher nicht ein einziges Mal der Fall gewesen, seitdem ich die erste Version (für das "responsive design", denn da wurde tatsächlich vieles umgestellt) erstellt habe - jedenfalls kann ich mich an keinen Fall erinnern. Insofern haben wir von "ständig" vielleicht auch unterschiedliche Vorstellungen.

Bei anderen Patches, die direkt in das AVM-GUI eingreifen, kommt das schon mal vor (z.B. bei der Anzeige der VPN-Verbindungen in der Übersicht) ... aber das kann man m.E. auch kaum vermeiden.

Da die AVM-Versionen am Ende auch alle nach demselben Schema organisiert sind, kann man das schon in den Labor-Versionen wieder sehen, wie es in der Zukunft wohl aussehen wird bei so ziemlich jedem Modell ... man hat also i.d.R. die notwendige Zeit, um sich da erneut anzupassen - und inzwischen macht die fortschreitende Modularisierung bei AVM im GUI das noch deutlich attraktiver, es für eigene Zwecke nachzunutzen, anstatt da etwas eigenes bereitzustellen ... bis hin zur Frage, daß man auch das Freetz-GUI natürlich auf der LAN-Seite besser mit TLS implementiert und nutzt, wenn man "mit gutem Beispiel vorangehen" will.

Auch die Frage der Benutzerverwaltung hat AVM inzwischen deutlich weiter vorangetrieben, als das bei Freetz der Fall ist ... oder gibt es dort inzwischen auch "read-only user", die sich nur mit Statusinfos aus dem Freetz-GUI versorgen können (z.B. wieder bei der Frage, welche OpenVPN-Verbindungen aktiv sind) und nicht gleich auch alle Einstell- (und "Verstell-") Möglichkeiten ebenfalls haben?

Mir fallen bestimmt noch ein paar weitere Argumente für die Benutzung des AVM-GUI ein ... solange das Freetz-GUI (bis auf Schönheitskorrekturen mit irgendwelchen Skins) funktional auf dem derzeitigen Stand bleibt, wird der Abstand am Ende ja sogar immer größer.

-------------------------------------------------------------------------------------------------

Wo es aber wahrscheinlich tatsächlich problematisch wird, ist die Unterstützung von Freetz für Firmware-Versionen bis zurück zum Hrn. Zuse ... damit kann man sich nicht mehr nur auf die jeweils aktuelle Masche von AVM einstellen und muß wirklich viele ältere Sachen parallel noch vorhalten oder gar solche Patches pro Version verwalten.

Da wüßte ich auch keine andere Lösung, als einfach die alten Zöpfe abzuschneiden ... denn an die "Masse" an FRITZ!Box-Besitzern, die krampfhaft mit älterer (und fehlerbehafteter) Firmware arbeiten wollen, kann (und will) ich einfach nicht glauben. Meine eigenen Erfahrungen legen eigentlich nahe, daß die meisten Freetz-Benutzer immer zu den ersten gehören (oder das gerne würden), die auf eine neue Firmware-Version von AVM anspringen.

Unterschiede je Geräte machen
Ich bin etwas neugierig, wie man z.B. eine Puma-Box und eine 7490 hier "gleichbehandeln" sollte, wenn man anzeigen will, welches System jeweils installiert ist. Oder was meinst Du mit diesem "Unterschiede je Gerät machen" genau? Da, wo sich die Geräte vom Aufbau unterscheiden, muß man solche Unterschiede halt berücksichtigen.

Ich habe z.B. noch eine andere, bisher private Version (eine Mischung aus dem anderen Bootmanager und seiner Fähigkeit, Settings für jedes System getrennt zu verwalten und zu versionieren und dem aktuellen, garniert mit etwas TFFS-Verwaltung wie in "tbackup" - also alles nichts "Geheimes", sondern nur in einer etwas spezielleren Kombination, die zu erklären mir deutlich zu mühsam ist und die deshalb "unter Verschluß" bleibt) und bei der merke ich noch viel mehr, wie unterschiedlich schon die VR9-Boxen (konkret 7490 und 7412) bei der Behandlung von "/var/flash" vorgehen (mal liegt da die "config"-Partition und mal "nur" ein "tmpfs"). Wie sollte man da alle Geräte/Modelle über einen Kamm scheren können?
 
@PeterPawn: Ich würde das "old style" shell-basierte CGI und FREETZ doch noch nicht komplett abschreiben. Ist aber wiederum meine persönliche Meinung. Ich stelle es für mich persönlich z.B. leichter vor, ein Paket shell-basiert unter FREETZ zu entwickeln / zu portieren, als mich in die LUA-Tiefen von diesem "modernen" AVM-CGI reinzudenken. Und so freetz-altmodisch bin ich vermutlich nicht alleine. Deine Kritikpunkte bzgl. der Aktualisierung des WebIF zur Laufzeit usw. teile ich voll mit. Auch dass FREETZ auf Port 81 nicht jedermann-Sache schon immer war. Es war aber damals schon sinnvoll, sich vom Standard-AVM-WebIF zu trennen und eigene Wege zu gehen. Die Erinnerungen von @cuma gehen vermutlich noch in die Zeit zurück, wo es noch tatsächlich so war, wie er es beschreibt. Von daher, hat jeder irgendwie Recht...

MfG
 
- Ich benutze gar kein Freetz-Interface, weder mit noch ohne Skin. Habe ich mir früher angesehen, es gewogen und für "zu leicht" befunden. Spätestens seit 05.xx mit anständiger Benutzerverwaltung ist das AVM-GUI dem Freetz-Interface in meinen Augen überlegen ... in welchen Punkten konkret, habe ich schon weiter oben angeführt.

- Die Zeit, die im "gui_bootmanager" beim Zusammensuchen der Daten benötigt wird, wird (nach meinen Messungen) weniger beim Erkunden des korrekten Modells verbraten, als vielmehr beim Erkunden des Systems in der anderen Partition. mount/umount braucht dabei am längsten, bei den 4er-Boxen für das YAFFS2 noch mal deutlich länger (je nach Zustand des NAND-Flashs) - weil das sequentiell gescannt wird vom Treiber beim Mounten. Afaik verwendet AVM hier keine Checkpoints - ist auch zu wenig Speicher in den Partitionen ... bei der "config"-Partition im UBIFS der GRX-Boxen hat man sich ja auch vollkommen vertan, denn in den 2 MB kann nun mal der Kernel kein UBI-Dateisystem anlegen.

- Wie schnell/langsam das AVM-Interface ist, ist nun mal Ansichtssache ... denn eines kann das Freetz-GUI eben unbestreitbar nicht: sich automatisch so an andere (genauer: an kleinere) Auflösungen anpassen, daß es auch mit dem Smartphone les- und bedienbar bleibt. Das kann man selbst nun von einem GUI "erwarten" oder nicht ... die Erfahrung der meisten würde heutzutage so eine dynamische Anpassung an anderen Stellen beinhalten und da ist es für manchen vielleicht auch hilfreich, wenn er bei einer Handy-Auflösung von >2000x1000 px nicht erst an einen Button heranzoomen muß, um den auf dem Smartphone-Display überhaupt zu treffen. Hinsichtlich Farbgebung und Anordnung von Elementen (kurz: Usability) kann jeder eigene Vorstellungen haben ... ich finde es durchaus gut, daß es bei AVM hier keine Möglichkeit der Skin-Verwaltung gibt, weil das die verbale Beschreibung am Telefon (oder wo auch immer man selbst anderen helfen muß) dann doch deutlich vereinfacht, wenn blau auch blau ist und nicht pink und wenn der Benutzer oben rechts steht (solange der Platz reicht) und nicht unten links.

- Wie Du das Problem der parallelen Aufrufe jetzt selbst gelöst hast bzw. wie hoch Du die Wahrscheinlichkeit eines parallelen Aufrufs siehst, ist ja - mangels sichtbarem Code - auch unklar ... aber daß der "gui_bootmanager" beim "get_values" 2/3 der Zeit in "sys"-Aufrufen verbringt:
Code:
root@FB7490:/var/tmp $ time ./gui_bootmanager get_values nocache
active_version="113.07.01"
active_date="10.09.2018, 11:42:49 Uhr"
active_modified_by="modfs"
active_modified_at="14.10.2018, 01:37:15 Uhr"
active_brandings="1und1 avm"
inactive_version="113.06.93"
inactive_date="13.12.2017, 11:59:12 Uhr"
inactive_modified_by="modfs"
inactive_modified_at="13.10.2018, 21:45:57 Uhr"
inactive_brandings="1und1 avm"
current_branding="avm"
switch_branding_support=true
current_switch_value=0
Command exited with non-zero status 1
real    0m 0.77s
user    0m 0.28s
sys     0m 0.53s
root@FB7490:/var/tmp $
, gibt ja genauso einen Hinweis darauf, wo die Zeit wohl bleibt, wie die "summary" vom "strace" (was die "real"-Time hier deutlich höher ausfallen läßt, als oben zu sehen mit den 0,77 s):
Code:
% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
 93.84    3.200000        4488       713       530 wait4
  2.05    0.070000         169       414           read
  1.17    0.040000         261       153           open
  0.59    0.020000         134       149         2 write
  0.29    0.010000        1250         8           getdents64
  0.29    0.010000         769        13           lstat64
  0.29    0.010000          55       181           sigreturn
  0.29    0.010000         128        78           execve
  0.29    0.010000         232        43        15 stat64
  0.29    0.010000          22       438           brk
  0.29    0.010000          16       599           close
  0.29    0.010000          64       156           set_thread_area
  0.00    0.000000           0         1           unlink
  0.00    0.000000           0        23           time
  0.00    0.000000           0         1           getpid
  0.00    0.000000           0         1           mount
  0.00    0.000000           0        79           getuid
  0.00    0.000000           0         2           access
  0.00    0.000000           0        14        11 mkdir
  0.00    0.000000           0         3           rmdir
  0.00    0.000000           0        91           pipe
  0.00    0.000000           0         1           geteuid
  0.00    0.000000           0         1           umount2
  0.00    0.000000           0       199       136 ioctl
  0.00    0.000000           0         4           fcntl
  0.00    0.000000           0         6           umask
  0.00    0.000000           0       173           dup2
  0.00    0.000000           0         1           getppid
  0.00    0.000000           0         2           getrlimit
  0.00    0.000000           0         4         4 readlink
  0.00    0.000000           0         6           mmap
  0.00    0.000000           0         6           munmap
  0.00    0.000000           0       183           clone
  0.00    0.000000           0         1           uname
  0.00    0.000000           0        10           poll
  0.00    0.000000           0       125           rt_sigaction
  0.00    0.000000           0         2           mmap2
  0.00    0.000000           0         5           fstat64
  0.00    0.000000           0        80           fcntl64
  0.00    0.000000           0         4           clock_gettime
------ ----------- ----------- --------- --------- ----------------
100.00    3.410000                  3973       698 total
Wenn ich hier (absichtlich) auf das AVM-"Angebot" mit dem "puma_helper.sh"-Skript zurückgreife, dann dient das ja gerade dazu, bei der Unterscheidung eben nichts selbst programmieren zu müssen ... egal wie umständlich das bei AVM gelöst ist. Da mache ich mir dann lieber Gedanken, wie ich mehrfache Aufrufe vermeiden kann und siehe da, mit dem Cache sieht das dann beim zweiten Aufruf schon wieder ganz anders aus:
Code:
root@FB7490:/var/tmp $ strace -o /var/media/ftp/YourFritz/bootmanager.trc -f -v -T -t -x -C time ./gui_bootmanager get_value
s
active_version="113.07.01"
active_date="10.09.2018, 11:42:49 Uhr"
active_modified_by="modfs"
active_modified_at="14.10.2018, 01:37:15 Uhr"
active_brandings="1und1 avm"
inactive_version="113.06.93"
inactive_date="13.12.2017, 11:59:12 Uhr"
inactive_modified_by="modfs"
inactive_modified_at="13.10.2018, 21:45:57 Uhr"
inactive_brandings="1und1 avm"
current_branding="avm"
switch_branding_support=true
current_switch_value=0
real    0m 0.78s
user    0m 0.08s
sys     0m 0.18s
root@FB7490:/var/tmp $
[...]
% time     seconds  usecs/call     calls    errors syscall
------ ----------- ----------- --------- --------- ----------------
100.00    0.680000        3560       191       163 wait4
  0.00    0.000000           0        87           read
  0.00    0.000000           0        15           write
  0.00    0.000000           0        28           open
  0.00    0.000000           0        88           close
  0.00    0.000000           0        11           execve
  0.00    0.000000           0         3           time
  0.00    0.000000           0         1           getpid
  0.00    0.000000           0        11           getuid
  0.00    0.000000           0         1           access
  0.00    0.000000           0         4         3 mkdir
  0.00    0.000000           0         1           rmdir
  0.00    0.000000           0        11           pipe
  0.00    0.000000           0        79           brk
  0.00    0.000000           0        29        15 ioctl
  0.00    0.000000           0         1           fcntl
  0.00    0.000000           0         2           umask
  0.00    0.000000           0        27           dup2
  0.00    0.000000           0         1           getppid
  0.00    0.000000           0         1           munmap
  0.00    0.000000           0        27           sigreturn
  0.00    0.000000           0        28           clone
  0.00    0.000000           0         1           uname
  0.00    0.000000           0        36           rt_sigaction
  0.00    0.000000           0         1           mmap2
  0.00    0.000000           0         8           stat64
  0.00    0.000000           0         1           lstat64
  0.00    0.000000           0         1           fstat64
  0.00    0.000000           0         2           getdents64
  0.00    0.000000           0        17           fcntl64
  0.00    0.000000           0         2           clock_gettime
  0.00    0.000000           0        22           set_thread_area
------ ----------- ----------- --------- --------- ----------------
100.00    0.680000                   738       181 total
Solange Du also nicht den konkreten Code zeigst, wie die Daten bei Dir ermittelt werden (meinen kann man sich im Repo jederzeit ansehen), ist der "Vergleich" eher problematisch.

- Ja, das Lua-Interface von AVM schon deshalb "lahm" (zumindest im Vergleich zu anderem), weil eben auch hier jede Lua-Seite über das "luacgi" aufgerufen wird ... wer das nicht glauben kann, braucht nur mal die "/usr/www/cgi-bin/luacgi" aus dem Spiel nehmen (z.B. durch bind-Mount einer Verzeichniskopie ohne dieses Programm) und dann mal versuchen, irgendeine Seite im AVM-GUI aufzurufen, die nicht als statische Seite vorliegt. Schon die Initialisierung des CGI braucht also immer etwas Zeit ... angesichts all dessen, was das "framework" von AVM aber auch noch macht (von der Berechtigungsprüfung bis zur Session-Verwaltung), kann man das schon wieder nicht mit Freetz und den Shell-Aufrufen als CGI vergleichen bzw. man vergleicht da Äpfel mit Birnen.

- Wenn da bei Freetz Perl o.ä. im Einsatz wäre (und nicht die Shell, deren Code als Kopie obendrein auch noch ständig im RAM steht, weil das "shared" ist und nur entsprechend gemappt werden muß), dann sähe das auch schon wieder anders aus - denn daß mit Lua mehr "Freiheiten" bei der GUI-Implementierung bestehen als mit Shell-Code, wird wohl auch niemand bestreiten wollen und erst bei entsprechender Komplexität werden die Nachteile bei der Initialisierung von den Vorteilen der "richtigen Programmiersprache" aufgewogen. Wenn ein Shell-Skript nur statisches HTML erzeugt (bei AVM sind das wenigstens noch Klassen/Objekte, die den Schreibaufwand (und die Chance auf Fehler in der HTML-Syntax) entsprechend verringern) und darin ein paar Variablen ersetzen muß, dann geht das logischerweise schneller ... aber die Komplexität dessen, was das Freetz-GUI macht und kann, ist auch ein Fliegenschiß im Vergleich zu dem, was das AVM-GUI inzwischen kann - und auch das "Maulen" über das "ungewohnte Interface" seit der 06.5x, ist (zumindest für mein Empfinden) inzwischen verhallt.

- Wie lange die "ds-mod"-Zeiten nun schon zurückliegen, muß ich Dir sicherlich auch nicht erklären ... ich bin immer wieder aufs Neue verblüfft, wieso gerade bei Freetz auch diesen "guten alten Zeiten" immer noch hinterher geschaut wird, während man bei anderen Geräten ganz heiß auf Neuheiten ist. Wer mal genau nachdenkt, wird auch darauf kommen, daß diese "ds-mod"-Zeiten eben die graue Vorzeit beschreiben, in der es noch nicht einmal Smartphones mit Touchscreen-Bedienung gab (erstes iPhone: 2007) ... und die Welt hat sich seitdem auch weiter gedreht.

- Ich kann bei AVM auch keinen Drang zu "ständigen Runderneuerungen" erkennen, was das GUI angeht. Dem alten GUI folgte irgendwann das Lua-basierte (auch dieses sehr konsistent über alle Modelle durchgezogen, bis hin zum N/G-Repeater, afaik - auch wenn ich gerade keine Firmware für den habe, in der ich das überprüfen könnte) und das bekam dann ein Facelift in Form des "responsive design" (was irgendwie auch überfällig war, weil die "Browserbedienung" auf dem PC deutlich auf dem Rückzug war/ist). Das macht in der Summe drei "große" Unterschiede in den Versionen, die ich als "Runderneuerungen" bezeichnen würde. Das dann auf 12 Jahre umgelegt (so lange gibt es die FRITZ!Boxen mit Linux-Kernel 2.6 inzwischen schon) ... und das relativiert sich (zumindest in meinen Augen) deutlich, denn in dieser Zeit haben sich die Paradigmen und Schnittstellen bei anderen Systemen (von Windows bis Android) erheblich mehr geändert, als es beim AVM-GUI der Fall ist.

- Die "asynchrone Programmierung" von Oberflächen in einem Browser steckte 2005 noch in den Kinderschuhen, ebenso wie die dafür notwendigen Features von HTML, CSS und JavaScript (bzw. ECMAScript) und wie ungewöhnlich das sogar noch zu den Zeiten war, wo dann das Freetz-GUI in der heutigen Form entstand, kann man sicherlich auch daran sehen, daß es dort (meines Wissens zumindest) nicht einen einzigen XHR-Aufruf gibt. Da ist mir das "sobald sich etwas am AVM-Interface ändert" dann doch zu unbestimmt ... wobei man auch hier durchaus unterscheiden muß, worum es eigentlich geht. Wenn das Ziel eine Korrektur des AVM-Interfaces ist (wie bei der Mehrzahl der GUI-bezogenen "modscripts"), kommt man gar nicht umhin, das auch am AVM-Interface zu machen (analog zu Patches in Freetz) und wenn es um eine Oberfläche für eigene Erweiterungen geht, dann kann man die auch so in die AVM-Oberfläche einpassen, daß man nicht bei jedem AVM-Furz sofort selbst wieder ändern muß ... für den Boot-Manager habe ich das ja bereits "ausgeführt" und der ist tatsächlich so eine Art "Mittelding", wenn es um die Integration in ein GUI geht. Aber auch da habe ich zumindest im Skript versucht, den HTML-Teil von der Erzeugung der Daten zu isolieren ... wenn das nur eine einzige Datei ist, dient das nur der einfacheren Integration "von Hand", denn beim automatischen Zusammenbau (wie in Freetz oder in meinem "modscript") wären auch mehrere Dateien benutzbar.

- FB7590 und "replace kernel" (betrifft ja eigentlich alle GRX-Boxen): Es fehlt m.W. noch das passende Skript, um den kombinierten Kernel aus "bootcore" und dem selbst-kompilierten zu erstellen. Das prinzipielle Vorgehen sollte klar und bekannt sein und man muß sich vermutlich nur noch überlegen, ob man den "bootcore" von AVM übernimmt (m.E. spricht nichts dagegen) oder auch den selbst übersetzt (halt mit passenden Settings). Ich selbst habe bisher halt "keinen Druck", einen eigenen Kernel zu verwenden (nicht mal OpenVPN ist bei mir ein Show-Stopper, weil ich dann halt einen Server im Netz als Relay nehme, wenn wirklich ein OpenVPN-Anschluß mit einem reden muß, der "nur" IPSec mit IKEv1 spricht) und habe das nur durch manuelles Basteln mal ausprobiert, ob es - wie erwartet - funktionieren würde. Ich vermute einfach mal, daß Eugene keine passende Box hat und von den Besitzern der passenden Modelle niemand wirklich gewillt ist (oder auch in der Lage und das ist auch nicht despektierlich gemeint), das selbst zu entwickeln oder zu testen. Dabei ist es wirklich simpel ... aber ein weiterer Grund, warum ich das nicht von mir aus bastele, dürfte auch klar sein (oder zumindest "zu vermuten", wenn man nicht vollkommen neu hier ist).

- Außerdem bin ich (auch wegen der Gefahr, daß AVM neben den fehlenden Quellen für "avm_kernel_config" noch andere "Besonderheiten" im eigenen Kernel hat, von denen außerhalb ebenfalls niemand etwas weiß) kein großer Fan von einem dauerhaften Austausch des Kernels (solange man alle AVM-Funktionen nutzen will), weil man sich (sofern mein Verdacht auch nur im Ansatz stimmt) ganz schnell Fehler einfangen kann, die nur sehr schwer zu diagnostizieren sind. Daher würde ich selbst das Entfernen der "BUG_ON()"-Statements aus dem Netzwerk-Code in den AVM-Quellen eher durch ein Patchen im Kernel-Speicher ausführen, als einen anderen Kernel zu verwenden. Allerdings geht das eben nicht immer ... aber von dem, was ich selbst tatsächlich brauche (bis hin zum "overlayfs"), hat AVM bisher noch nichts weiter ausgebaut und damit braucht es (bei mir) auch keinen eigenen Kernel.
 
  • Like
Reaktionen: NDiIPP
Nein, nichts falsches kopiert ... das eine ist halt mit dem Aufruf von "strace" außen herum (das zweite) und das andere zeigt das Timing des Aufrufs ohne "strace". Deshalb stehen die Kommandos davor und ich habe vor der ersten Ausgabe von "strace" auch noch geschrieben:
was die "real"-Time hier deutlich höher ausfallen läßt, als oben zu sehen mit den 0,77 s

Daß die Anzeige der "strace"-Summary nicht aus dem gezeigten Aufruf von "time gui_bootmanager" stammen kann, sollte sich aus dem Kontext ergeben. Selbstverständlich läuft das Ganze unter "strace" deutlich langsamer und ist nicht in den 0,77 s "real time" erledigt, die oberhalb der (ersten) "strace"-Summary zu sehen sind. Da ging es mir auch weniger um die (konkreten) Zeiten, sondern mehr um die deutlich geringere Anzahl von "syscalls" ... irgendwas um die 750 (bei gecachten Daten) vs. fast 4.000 bei der "tatsächlichen" Ausführung. Geht es nur um das "timing", sieht es bei Verwendung der gecachten Daten so aus (auf der 7490):
Code:
root@FB7490:/var/tmp $ time ./gui_bootmanager get_values
active_version="113.07.01"
active_date="10.09.2018, 11:42:49 Uhr"
active_modified_by="modfs"
active_modified_at="14.10.2018, 01:37:15 Uhr"
active_brandings="1und1 avm"
inactive_version="113.06.93"
inactive_date="13.12.2017, 11:59:12 Uhr"
inactive_modified_by="modfs"
inactive_modified_at="13.10.2018, 21:45:57 Uhr"
inactive_brandings="1und1 avm"
current_branding="avm"
switch_branding_support=true
current_switch_value=0
real    0m 0.13s
user    0m 0.06s
sys     0m 0.07s
Der Cache funktioniert also durchaus und er bringt auch richtig einen Effekt an den Start ... aber das sieht man eben schon an der Verringerung der "syscalls()" mit dem Cache auf ca. 2/9 der Aufrufe im anderen Fall.

Außerdem gilt auch hier wieder ... das kann man unter Freetz vielleicht so machen, aber unter anderen Bedingungen (die mit demselben Code funktionieren sollen, weil ich nicht alles mehrfach warten will) gibt es auch keine "options.cfg" (und auch bei "no-freetz"-Modus ist das nicht zwingend, weil "patches/scripts/900-add_options_cfg.sh" da m.W. nicht ausgeführt wird) und wenn man das (so, wie ich mir das vorstelle oder es "empfehle") einfach beim Systemstart einmal machen läßt und die Ergebnisse speichert, ist das für mich (vom Aufwand her) dasselbe.

Ob ich den Prozessor-Typ jedesmal aus der "options.cfg" ermittele oder alles auf einmal (einmalig) beim Systemstart (und es nur bei Änderungen neu sammeln lasse, wobei für solche Änderungen ja nicht so viele Ursachen in Frage kommen) zusammensuche, macht (für mich zumindest) jetzt nicht so den Unterschied aus - der entscheidende Faktor für mich, war hier die einheitliche Code-Basis.

Ich hatte ja zuvor auch in "YourFritz" und in "modfs" zwei Versionen und mußte damit Änderungen immer zweifach ausführen ... als ich das geändert habe, habe ich einfach noch Freetz als potentielle Quelle einer "eigenen Firmware" dazugenommen - weil es ja auch vorkommen könnte, daß ein Benutzer sowohl ein Freetz-Image als auch eines von "modfs" (oder gar "YourFritz", wobei ich die noch im Überblick habe) auf seiner Box hat oder auch ein originales von AVM.

Wo ich tatsächlich noch überlegt habe (und wieder neu überlege, seitdem die Inhouse-Versionen mit einem eigenen Key signiert werden), ist der Punkt, ob man noch eine Erkennnung von Labor- und Inhouse-Versionen an dieser Stelle einbaut (egal, ob es eine Modifikation ist oder nicht) ... wenn die Leute in Zukunft genauer aufpassen müssen, sofern sie "reguläre" und Inhouse-Versionen auf der Box haben, wäre die entsprechende Anzeige vielleicht auch nicht so ganz umsonst.
 
Nur damit nicht der Eindruck entsteht, dass das, was cuma da erzählt, the Freetz way ist bzw. dem entspricht, was in Freetz gemacht wird.

Freetz nutzt die /etc/options.cfg bei ganz wenigen Sachen, bei denen es sonst Schwierigkeiten gab, die entsprechenden Eigenschaften irgendwie anders zu ermitteln bzw. man die Use-Cases hat unterstützen wollen wie "User muss Paket FOO konfigurieren können auch dann, wenn das entsprechende Paket per external ausgelagert ist und der Träger mit den ausgelagerten Dateien gerade nicht eingesteckt ist". Das sind in der Regel solche Eigenschaften wie "wurde ein Paket/eine Library mit der Option SUPPORT for FOO oder ohne übersetzt" (hier z.B. openvpn.cgi#L14 als Beispiel). Bei allen anderen Eigenschaften, die sich zuverlässig ohne den Zugriff auf /etc/options.cfg ermitteln lassen, werden diese zur Laufzeit ermittelt.

p.s. Ansonsten der Hinweis, Ihr seid inzwischen Meilen weit weg von dem, was in der Überschrift des Threads steht.
 
@cuma:
Ich kann die Aufforderung, Deinen Code "zu zeigen", nur wiederholen, wenn Du der Ansicht bist, es besser gemacht zu haben - dann kann man auch die "Unterschiede" besser beurteilen.

Ein zweimaliger, paralleler Aufruf derselben Seite, die dann ihrerseits das Shell-Skript startet, soll hier einfach vermieden werden - das gibt "unschöne" Ergebnisse, wenn da Aufrufe "ineinander geschachtelt" erfolgen können.

Beim AVM-GUI kann das aber durchaus vorkommen (sofern man nicht eine "single admin"-Umgebung hat und einfach "proklamiert": Außer mir macht das soundso niemand. - das kann man gerne für sich selbst entscheiden, aber nicht bei einer Software, die man anderen zur Verfügung stellt) ... möglicherweise serialisiert beim Freetz-GUI bereits der "httpd" die Zugriffe (ich habe nicht nachgesehen).

Da das YAFFS2-Filesystem der alternativen Partition durchaus auch mal im laufenden Betrieb gemountet sein kann (z.B., wenn man dort gerade eine neue Software für das alternative System installiert oder auch nur eigene Erweiterungen oder dort Einstellungen speichern will) und das dabei nicht zwangsläufig auch immer nur "read-only" ist (davon kann man dann tatsächlich auch mehrere mounten), kann es auch nicht zuverlässign immer ein zweites Mal parallel(!) gemountet werden:
Code:
root@FB7490:~ $ set -x;mount | grep block3;mkdir /tmp/dir1 /tmp/dir2;mount /dev/mtdblock3 /tmp/dir1;mount -o ro /dev/mtdblock3 /tmp/dir2;mount | grep block3;umount /tmp/dir[12];mount | grep block3;rmdir /tmp/dir[12]
+ set -x
+ mount
+ grep block3
+ mkdir /tmp/dir1 /tmp/dir2
+ mount /dev/mtdblock3 /tmp/dir1
+ mount -o ro /dev/mtdblock3 /tmp/dir2
mount: mounting /dev/mtdblock3 on /tmp/dir2 failed: Device or resource busy
+ mount
+ grep block3
/dev/mtdblock3 on /var/tmp/dir1 type yaffs (rw,relatime)
+ umount /tmp/dir1 /tmp/dir2
umount: can't unmount /tmp/dir2: Invalid argument
+ mount
+ grep block3
+ rmdir /tmp/dir1 /tmp/dir2
root@FB7490:~ $
, damit braucht es einen Mechanismus, der entweder den vorhandenen Mount-Point (sicher) verwenden kann (wobei der durchaus auch in einem anderen Namespace liegen kann und gar nicht zwangsläufig für das Skript erreichbar sein muß) oder solange wartet, bis die Ressource wieder frei ist.

Denn im Ergebnis schlägt ansonsten einfach der Zugriffsversuch fehl, wenn die inaktive Wrapper-Partition "in use" ist ... speichert man das jetzt noch "im Cache", ist's ganz vorbei mit der Möglichkeit, da noch mal sinnvolle Daten auszulesen.

Also braucht es (zumindest bei mir) eine Serialisierung (eigenes "mount", wenn die Partition wieder "frei" ist - und das kann auch lange dauern) oder eine Garantie, daß die Partition da, wo sie gerade gemountet ist, auch so lange existiert (und damit vom Skript genutzt werden kann), bis die Daten gesammelt wurden. Dazu muß dann wieder das Skript, welches die Partition gemountet hat und sie nun irgendwann wieder "entmounten" könnte, für diese Aktion genau dieselbe Semaphore verwenden und erst dann etwas am Mount-Status ändern, wenn diese verfügbar war.

Also verwenden mehrere Skripte, u.a. auch solche, die ihrerseits in der YAFFS2-Partition Schreibzugriffe vornehmen (das geht bis zur automatischen Sicherung von geänderten Einstellungen und wird gar nicht immer von mir selbst gestartet/gesteuert - das ist eine Weiterentwicklung von dem hier: https://github.com/PeterPawn/YourFritz/tree/master/customconfig), dieselbe Semaphore (nur heißt sie bei mir persönlich halt anders, deshalb ist der Name auch konfigurierbar in einer Variablen) und damit wird dafür gesorgt, daß sich zwei Skripte nicht ins Gehege kommen können, wenn sie mit den YAFFS2-Partitionen "rummachen".

Denn das gilt für die Wrapper-Partition des aktiven Systems ja auch, daß die ab und an mal read/write gemountet werden muß, wenn man da schreiben will ... nur muß der Bootmanager da halt nichts auslesen und daher spielt es - in diesem konkreten Kontext - auch keine Rolle, für die aktive Partition entsprechende Vorsorge zu treffen (weil auch deren "filesytem_core.squashfs" bereits gemountet ist als Wurzelverzeichnis) und demzufolge wird hier nur für den (kurzen) Zeitraum, in dem die alternative Partition gemountet werden muß, etwas unternommen.

Wie hoch die Wahrscheinlichkeit so eines "clashes" jetzt sein mag, soll jeder selbst einschätzen oder beurteilen. Ich hatte jedenfalls oft genug die Situation (vielleicht auch der Entwicklung geschuldet, aber schaden kann eine Serialisierung hier auch nicht wirklich), daß ein Aufruf des Skripts keine Daten auslesen konnte, weil die Partition anderweitig gemountet war ... es gab durchaus einen Grund für den gesamten Commit b316a5d598045cec4ed1dad080a1dae1a92b24b3 - den habe ich nicht aus Langeweile zusammengebaut, sondern zur Prävention bzw. zum Beheben von Problemen.
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.