freetz-ng und die FW7.39 + Boot Manager

Ich gucke mal, ob ich dazu komme, es mir anzusehen - vermutlich hat AVM wieder am HTML/CSS oder am JS der Seite, wo das eingebettet werden soll, gedreht. Schade, daß offenbar der Patch trotzdem irgendwelche Anker-Zeilen findet, sonst würde das gleich beim Hinzufügen/Patchen auffallen.
 
Deshalb habe ich es auch noch nicht wirklich eilig damit - wenn ich eine Hand frei habe, mache ich erst mal mit gerade laufenden Änderungen an den Skripten in signimage weiter. Es gibt ja noch andere offene Baustellen - spez. in modfs bei den Modifikationen (wobei das hier der Freetz-NG-Bereich ist).

Da hat man mich vor kurzem erst wieder mit der Nase darauf gestoßen, daß die verdichtete Anzeige der VPN-Verbindungen in der Übersichtsseite auch seit 07.24 nicht mehr funktioniert - das war mir schon wieder entfallen.

Weißt Du, was wirklich hilft, damit so etwas bei mir nicht unter die Räder kommt? Eine Issue im GitHub-Repository.

Auch wenn Du das vermutlich über Freetz-NG einbauen läßt, liegen die Ursprungsdateien ja hier: (hier würde jetzt ein Link stehen, wenn GitHub nicht gerade Server Error 500 ausgeben würde) - dort ist das "Tracking" dann auch für mich einfacher. Ich nehme mir zwar auch jedes Mal vor, das dann halt selbst vom IPPF zu GitHub zu übertragen, aber das vergesse ich auch gerne und dabei kommt dann so etwas wie mit der VPN-Anzeige heraus.
 
Ich habe mir das mit dem Boot-Manager und der 07.39 jetzt mal angesehen - allerdings habe ich keine passende Box (immer noch bzw. nicht mehr) und kann das nicht selbst testen.

Nach dem, was ich beim Vergleichen gefunden habe, hat sich am Ende nur der Anker für das Einbinden der zusätzlichen Daten in die reboot.lua geändert, weil AVM da zwei Leerzeichen entfernt hat in einer Zeile. Mit diesem Patch: https://github.com/PeterPawn/modfs/commit/bc369d9d6692b7a947d6880525d7cc203110b56e sollte das eigentlich schon geregelt sein ... aber den müßte jetzt mal jemand mit einem passenden Gerät testen, bevor ich den (dann zusammen mit den Änderungen, um auch die VPN-Übersicht wieder austauschen zu können) dann in den Hauptzweig übernehmen kann.

Eine leere Seite sollte eigentlich grundsätzlich nicht (mehr) vorkommen, weil ich Vorkehrungen eingebaut hatte, falls die Daten für den Boot-Manager mal nicht vorliegen sollten. Ich nehme aber an, daß es hier nun doch wieder dazu kam, weil von den zwei Patches in der reboot.lua nur einer ausgeführt wurde und dann bei der Ausführung beim Seitenabruf irgendeine Exception im Lua die Antwort im Ganzen verhindert(e). Ist aber nur "geraten" ... was konkret bei der 07.39 bisher heraus kam, wenn man die alte Version des Skripts zum Einbauen verwendete, kann ich nicht (live) testen, sondern nur durch Anschauen begutachten.

Wer das also mit dem Boot-Manager noch einmal auf einer 7590 (ggf. auch einer AX) probieren will, der muß/sollte (ohnehin) den beta-Branch (vom "modfs") verwenden beim Modifizieren/Einbauen des Boot-Managers. Dabei kann/darf man dann die VPN-Übersicht nicht ändern lassen - das ist derzeit nicht bis zum Ende implementiert. Ansonsten ist nur noch der Patch zum Aktivieren des "private"-Modus in der Firmware als drittes im beta-Branch enthalten (im Unterschied zum Hauptzweig), bei dem von der Auswertung von CONFIG_RELEASE auf CONFIG_BUILDTYPE umgestellt wurde.
 
Eine leere Seite sollte eigentlich grundsätzlich nicht (mehr) vorkommen
Habe ich aber doch noch bei einer 7530 mit 7.39-94410.
weil von den zwei Patches in der reboot.lua nur einer ausgeführt wurde
Es sind beide enthalten. mMn liegt es an der reboot.js Der Browser meldet diesen Fehler:
Code:
50 if (Object.keys(dataHandler.data.activeCalls).length !== 0) {

TypeError: can't convert null to object
 

Anhänge

  • reboot.js.diff.zip
    586 Bytes · Aufrufe: 3
  • reboot.lua.diff.zip
    2.1 KB · Aufrufe: 3
Zuletzt bearbeitet:
Bereitet man die Diffs etwas auf, sehen die beiden Unterschiede in der JS-Datei so aus:

js1_diff_prettified.PNG
js2_diff_prettified.PNG

Das stimmt also alles so weit - was aber (wenn der Vergleich stimmt) fehlt in der JS-Datei, wäre das Ergebnis dieser zwei Zeilen nach dem Patchen: https://github.com/PeterPawn/YourFr...ff421/bootmanager/add_to_system_reboot.sh#L38 ... das sollte dann den folgenden JS-Code hinzufügen:
Javascript:
function onChangeLinuxFsStart(e) {
    var s = jsl.evtTarget(e).id.substr("uiLinux_fs_start-".length);
    if (!s) return;
    jsl.show(s + "_branding");
    jsl.hide(("running" == s ? "alternative" : "running") + "_branding")
}
function buildBootmanager(data) {
    function gv(src, id) {
        var r = src.filter(function (e) {
            return e.id === id
        });
        if (r.length > 0) return r[0].value
    }

    function nl(frag, cnt = 1) {
        while (cnt--) html2.add(frag, html2.br())
    }
    var m = data.filter(function (d) {
        return "messages" === d.name
    })[0].obj;
    var v = data.filter(function (d) {
        return "values" === d.name
    })[0].obj;
    var r = html2.fragment();
    if (0 == v.length) {
        html2.add(r, html2.h3({}, gv(m, "nodata")));
        return r
    }
    html2.add(r, html2.h3({}, gv(m, "headline")));
    nl(r);
    var ct = html2.span();
    var at = html2.span();
    var cs = gv(v, "current_switch_value");
    html2.add(ct, html2.strong({
        style: gv(m, "style_caption")
    }, gv(m, "currsys")));
    html2.add(ct, html2.printf(gv(m, "switchvalue"), cs));
    nl(ct, 2);
    html2.add(ct, html2.printf(gv(m, "version"), gv(v, "active_version"), gv(v, "active_date")));
    if (gv(v, "active_modified_at")) {
        nl(ct);
        html2.add(ct, html2.printf(gv(m, "modified"), gv(v, "active_modified_at"), gv(v, "active_modified_by")))
    }
    nl(ct, 2);
    html2.add(at, html2.strong({
        style: gv(m, "style_caption")
    }, gv(m, "altsys")));
    html2.add(at, html2.printf(gv(m, "switchvalue"), cs ? ((parseInt(cs) + 1) % 2).toString() : "0"));
    nl(at, 2);
    var inactive = gv(v, "inactive_version");
    if ("missing" != inactive)
        if (inactive.length > 0) {
            html2.add(at, html2.printf(gv(m, "version"), gv(v, "inactive_version"), gv(v, "inactive_date")));
            if (gv(v, "inactive_modified_at")) {
                nl(at);
                html2.add(at, html2.printf(gv(m, "modified"), gv(v, "inactive_modified_at"), gv(v, "inactive_modified_by")))
            }
        } else gv(m, "altinv").split("\\n").forEach(function (l) {
            html2.add(at, l);
            nl(at)
        });
    else html2.add(at, gv(m, "altmiss"));
    nl(at, 2);
    var radios = html2.radios({
        name: "linux_fs_start",
        selected: "true" == gv(v, "system_is_switched") ? "alternative" : "running",
        attr: {
            disabled: "missing" == inactive ? true : false,
            onClick: onChangeLinuxFsStart
        },
        options: [{
            value: "running",
            text: ct
        }, {
            value: "alternative",
            text: at
        }]
    });
    html2.add(r, radios);
    html2.add(r, html2.h4({}, gv(m, "brndhead")));
    var cb = gv(v, "switch_branding_support");
    if ("false" == cb) {
        html2.add(r, html2.span({}, gv(m, "brndunsupp")));
        html2.add(r, html2.hiddenInput({
            name: "alternative_branding",
            value: gv(v, "current_branding")
        }))
    } else {
        var rb = html2.span({
            id: "running_branding",
            style: "true" == gv(v, "system_is_switched") ? "display: none" : ""
        });
        if ("both_fixed" == cb || "running_fixed" == cb) {
            html2.add(rb, html2.printf(gv(m, "brndcurrfixed"), html2.strong({}, gv(v, "current_branding"))));
            html2.add(r, html2.hiddenInput({
                name: "running_branding",
                value: gv(v, "current_branding")
            }))
        } else if (gv(v, "active_brandings").split(" ").length > 1) {
            html2.add(rb, html2.printf(gv(m, "brndmulti"), html2.strong({}, gv(v, "current_branding"))));
            nl(rb);
            var sb = html2.selectBoxPlain ? html2.selectBoxPlain({
                id: "uiRunningBranding",
                name: "running_branding"
            }) : html2.selectBox({
                id: "uiRunningBranding",
                name: "running_branding"
            });
            gv(v, "active_brandings").split(" ").forEach(function (o) {
                sb.options.add(html2.option({
                    value: o,
                    selected: gv(v, "current_branding") == o ? true : false
                }, o))
            });
            html2.add(rb, html2.label({
                for: "uiRunningBranding",
                style: gv(m, "style_sblbl")
            }, gv(m, "brndset")));
            html2.add(rb, sb)
        } else {
            html2.add(rb, html2.printf(gv(m, "brndcurrsingle"), html2.strong({}, gv(v, "current_branding"))));
            html2.add(r, html2.hiddenInput({
                name: "running_branding",
                value: gv(v, "current_branding")
            }))
        }
        html2.add(r, rb);
        var ab = html2.span({
            id: "alternative_branding",
            style: "true" == gv(v, "system_is_switched") ? "" : "display: none"
        });
        if ("missing" != inactive)
            if (inactive.length > 0)
                if ("both_fixed" == cb || "alternative_fixed" == cb) {
                    html2.add(ab, html2.printf(gv(m, "brndaltfixed"), html2.strong({}, gv(v, "inactive_brandings"))));
                    html2.add(r, html2.hiddenInput({
                        name: "alternative_branding",
                        value: gv(v, "alternative_branding")
                    }))
                } else if (gv(v, "inactive_brandings").split(" ").length > 1) {
            html2.add(ab, html2.printf(gv(m, "brndmulti"), html2.strong({}, gv(v, "current_branding"))));
            nl(ab);
            var asb = html2.selectBoxPlain ? html2.selectBoxPlain({
                id: "uiAlternativeBranding",
                name: "alternative_branding",
                style: gv(m, "style_selbrand")
            }) : html2.selectBox({
                id: "uiAlternativeBranding",
                name: "alternative_branding",
                style: gv(m, "style_selbrand")
            });
            gv(v, "inactive_brandings").split(" ").forEach(function (o) {
                asb.options.add(html2.option({
                    value: o,
                    selected: gv(v, "current_branding") == o ? true : false
                }, o))
            });
            if (0 == asb.selectedOptions.length) asb.options.forEach(function (o) {
                if (o.value == gv(v, "current_branding")) o.selected = true
            });
            html2.add(ab, html2.label({
                for: "uiAlternativeBranding",
                style: gv(m, "style_sblbl")
            }, gv(m, "brndset")));
            html2.add(ab, asb)
        } else {
            html2.add(ab, html2.printf(gv(m, "brndaltsingle"), html2.strong({}, gv(v, "inactive_brandings"))));
            if (gv(v, "inactive_brandings") == gv(v, "current_branding")) html2.add(ab, gv(m, "brndaltnochg"));
            else {
                html2.add(ab, html2.printf(gv(m, "brndaltset"), html2.strong({}, gv(v, "current_branding"))));
                nl(ab);
                html2.add(ab, html2.printf(gv(m, "brndaltnew"), html2.strong({}, gv(v, "inactive_brandings"))))
            }
            html2.add(r, html2.hiddenInput({
                name: "alternative_branding",
                value: gv(v, "inactive_brandings")
            }))
        } else html2.add(ab, gv(m, "brndaltinv"));
        html2.add(r, ab)
    }
    return r
}
Vermutlich fehlt auch dafür dann noch ein Anker, die vorher vorhandene Zeile, die mit TableCalls begann, existiert wohl auch nicht länger (in der bisherigen Form).



Wenn ich in eine bei mir entpackte Version (154.07.39-93231) schaue, ist da wohl ein const-Specifier/-Qualifier dazu gekommen, aus
Rich (BBCode):
TableCalls = (function () {
wurde
Rich (BBCode):
const TableCalls = (function () {
Damit müßte dann Zeile 38 (https://github.com/PeterPawn/YourFr...ff421/bootmanager/add_to_system_reboot.sh#L38) so geändert werden:
Rich (BBCode):
/^\(const \)\?TableCalls/i \
, damit der Anker wieder paßt. Das wäre dann der "nächste Versuch" (ich kann halt nicht selbst testen), der aber auch noch nicht zwingend funktionieren muß.

Allerdings sehe ich beim Vergleich der (aufgehübschten) reboot.js zwischen der o.a. Version und eine 07.27 (die da auch noch irgendwo entpackt bei mir liegt) keine anderen "unverträglichen" Änderungen - aber das ist "mit dem bloßen Auge" auch noch keine wirklich sichere Aussage. Außerdem basiert das auf einer älteren Inhouse-Version (oder es war doch eine Labor-Version, ich weiß es nicht mehr ... spielt auch keine entscheidende Rolle) und sollte es da weitere Änderungen am Inhalt der reboot.js gegeben haben, könnten auch andere Stellen wieder nicht passen.



Wobei das auch noch nicht der Grund sein dürfte, warum die Seite komplett leer bleibt - der Fehlermeldung nach zu urteilen, gibt es ja das Objekt für activeCalls nicht (das sollte per JSON nachgeladen werden über den Aufruf der reboot.lua) und das ist schon/noch von AVM.

Aber vermutlich verursacht irgendetwas anderes (nach dem Patchen) einen weiteren Fehler im Lua-Code auf der Box, so daß der Request an die data.lua am Ende kein JSON liefert, sondern irgendeine Fehlermeldung als Text. Diese Meldung enthält dann den Hinweis, wo in der Lua-Datei etwas schief läuft ... da das ein Fehler zur Laufzeit ist, kann ich das auch nicht selbst testen (ich habe immer noch keine neue 7590 besorgt).



Gleichzeitig habe ich vor drei Wochen einen Anlauf unternommen (der aber durch andere Probleme, die dringender waren, unterbrochen wurde), das ganze Zeug etwas übersichtlicher und flexibler zu machen ... der bisherige Stand ist jetzt im Branch bootmanager zu sehen: https://github.com/PeterPawn/YourFritz/tree/bootmanager/bootmanager

Das ist aber unfertig - mir war/ist aber das geänderte Konzept (u.a. das Trennen der Text-Splitter für den Zusammenbau der Anzeige vom eigentlichen Code, damit auch einfachere Anpassungen der Texte an andere Sprachen machbar wären, falls das jemand übersetzen/anpassen möchte an anderes als Deutsch oder Englisch - schließlich hat AVM jetzt auch alle Sprachen in einer Image-Version) wichtig und deshalb geht das da auch irgendwann mal weiter (nur halt im Moment nicht).

Wer das aber als "Übergangslösung" mit dem alten Stand selbst probieren möchte, kann noch die o.g. Änderung auf den Stand in modfs/beta anwenden (im YourFritz-Repo ist auch im main-Branch noch keine Änderung erfolgt) und dann mal schauen, was passiert. Da es wohl zusätzlich noch den Lua-Fehler gibt (auch wenn ich nicht erkennen kann - durch bloßes Starren auf den Code - wo das Problem liegt), wäre auch die Ausgabe der FRITZ!Box beim Aufruf der data.lua (die kriegt man mit den Developer-Tools eines Browsers auch gut angezeigt (bei den Netzwerk-Aktivitäten) und es geht nur um die "response" auf den Aufruf der data.lua für den Fall reboot) noch zu betrachten, denn ohne JSON-Response funktioniert auch der Rest in der (gepatchten) reboot.js nicht so, wie er soll.
 
Zuletzt bearbeitet:
Code:
/^[B][COLOR=rgb(184, 49, 47)]\(const \)\?[/COLOR][/B]TableCalls/i \
, damit der Anker wieder paßt.
Danke! Habe ich gemacht. Jetzt schaut die Größe der reboot.js besser aus.
Das wäre dann der "nächste Versuch" (ich kann halt nicht selbst testen), der aber auch noch nicht zwingend funktionieren muß.
Habe ich gemacht. Leider immer noch ein leeres Fenster. Was ich noch ergänzen kann: Es werden die 2 Dateien in /var/tmp nicht angelegt.

so daß der Request an die data.lua am Ende kein JSON liefert, sondern irgendeine Fehlermeldung als Text. Diese Meldung enthält dann den Hinweis, wo in der Lua-Datei etwas schief läuft ...
Wo und wie finde ich die?

(ich habe immer noch keine neue 7590 besorgt).
Eine 7520 genügt ja auch schon. :)
 

Anhänge

  • reboot.js2.diff.zip
    1.7 KB · Aufrufe: 3
Siehe oben (oder unten im Anhang) ... Du kannst in irgendeinem Browser mit Developer-Tools (die haben mittlerweile eigentlich alle aktuellen Implementierungen) den Netzwerk-Verkehr ansehen und da sollte dann als Response von der FRITZ!Box kein JSON, sondern irgendein Text mit Fehlermeldung kommen.

Irgendwelche Cache-Dateien in /var/tmp werden ohnehin nicht mehr angelegt - das war nur in Benutzung, solange die S85-app abgearbeitet wurde und man das dort einfach als Aufruf hinzufügen konnte. Jetzt extra einen neuen Service anzulegen, nur damit die Daten "im Hintergrund" schon beim Systemstart gesammelt werden, lohnt nicht wirklich - zumal auch das Sammeln bei aktuelleren Modellen nicht mehr so lange dauert, da nicht erst irgendein YAFFS2-Dateisystem (wie bei den VR9-Modellen) gemountet werden muß.
 

Anhänge

  • devtools_ff.PNG
    devtools_ff.PNG
    86.7 KB · Aufrufe: 10
Jetzt habe ich es endlich gefunden:
Code:
{
    "pid": "reboot",
    "hide": {
        "wps": true,
        "shareUsb": true,
        "faxSet": true,
        "dectRdio": true,
        "wGuest": true,
        "ssoSet": true,
        "wKey": true,
        "liveImg": true,
        "dslStat": true,
        "dslSet": true,
        "liveTv": true,
        "dectMoni": true,
        "provServ": true,
        "wlanmesh": true,
        "dectMoniEx": true,
        "rss": true,
        "mobile": true,
        "dslFeed": true,
        "dslSpec": true,
        "dslOv": true,
        "wSet": true,
        "dslGraph": true,
        "dectMail": true
    },
    "timeTillLogout": "24000",
    "time": [],
    "data": [],
    "sid": "207b7a9ba4563e6c"
}
Ist es das was du suchst?

Irgendwelche Cache-Dateien in /var/tmp werden ohnehin nicht mehr angelegt
Ich meine nicht beim Systemstart. Aber wenn ich bei 07.29 die Seite "Neustart" aufrufe dann sind danch die 2 Dateien in /var/tmp/ vorhanden.
 
Aber wenn ich bei 07.29 die Seite "Neustart" aufrufe dann sind danch die 2 Dateien in /var/tmp/ vorhanden.
Ja, die werden aber erst dann angelegt, wenn ein Shell-Skript die Daten für die Seite zusammensucht.

Da MUSS irgendein Problem in der (gepatchten) Lua-Seite reboot.lua existieren, denn das data-Objekt in der JSON-Antwort sollte mindestens ein weiteres Objekt namens activeCalls enthalten und das ist bei Dir offenbar leer (die zwei eckigen Klammern sind ein "leeres Array").

Nach dem Patchen sollte die reboot.lua so aussehen (hier auch wieder formatiert):
Rich (BBCode):
dofile("/usr/lua/rdfirst.lua")
dbg.httpvars()
local function get_active_foncalls_list()
    require("foncalls")
    local calls = foncalls.get_activecalls()
    local results = {}
    if #calls > 0 then
        for i, call in ipairs(calls) do
            local symbol = foncalls.get_callsymbol(call.call_type)
            table.insert(results, {
                symbolClass = symbol.class or "",
                symbolDirClass = symbol.dirclass or "",
                numberShortDisplay = foncalls.number_shortdisplay(call),
                portDisplay = foncalls.port_display(call),
                callDuration = call.duration or ""
            })
        end
    end
    return results
end
local function on_load()
    local data = {}
    data.activeCalls = {}
    if config.FON then
        data.activeCalls = get_active_foncalls_list()
    end
    local function data_bootmanager()
        local values = {}
        local pipe = io.popen("/usr/bin/gui_bootmanager get_values")
        local line
        for line in pipe:lines() do
            table.insert(values, {
                id = line:match("^([^=]-)="),
                value = line:match("^.-=\"?(.-)\"?$")
            })
        end
        pipe:close()
        local messages = {}
        --
        -- ToDo: consider to separate the message tables from rest of code, best in an extra file
        --
        if config.language == "de" then
            table.insert(messages, {
                id = "headline",
                value = "Folgende Systeme stehen auf dieser FRITZ!Box zur Auswahl bei einem Neustart:"
            })
            table.insert(messages, {
                id = "currsys",
                value = "das aktuell laufende System"
            })
            table.insert(messages, {
                id = "altsys",
                value = "das derzeit inaktive System"
            })
            table.insert(messages, {
                id = "switchvalue",
                value = "(linux_fs_start=%1%switch%)"
            })
            table.insert(messages, {
                id = "version",
                value = "Version %1%version% vom %2%date%"
            })
            table.insert(messages, {
                id = "modified",
                value = "zuletzt modifiziert am %1%date% durch \"%2%framework%\""
            })
            table.insert(messages, {
                id = "altinv",
                value = "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."
            })
            table.insert(messages, {
                id = "altmiss",
                value = "Die derzeit inaktiven Partitionen enthalten kein gültiges System."
            })
            table.insert(messages, {
                id = "brndhead",
                value = "Branding ändern"
            })
            table.insert(messages, {
                id = "brndunsupp",
                value = "Bei diesem Gerät ist keine dauerhafte Änderung der Firmware-Version möglich."
            })
            table.insert(messages, {
                id = "brndcurrfixed",
                value = "Die Firmware-Version des aktuell laufenden Systems ist fest auf \"%1%fixed%\" eingestellt und kann nicht geändert werden."
            })
            table.insert(messages, {
                id = "brndcurrsingle",
                value = "Das oben ausgewählte System unterstützt nur die Firmware-Version \"%1%current%\", diese ist im Moment auch eingestellt."
            })
            table.insert(messages, {
                id = "brndmulti",
                value = "Das oben ausgewählte System unterstützt mehrere Firmware-Versionen, im Moment ist \"%1%current%\" eingestellt."
            })
            table.insert(messages, {
                id = "brndset",
                value = "Beim nächsten Start wird folgender Wert gesetzt und bis zur nächsten Änderung verwendet:"
            })
            table.insert(messages, {
                id = "brndaltinv",
                value = "Da das alternative System nicht identifiziert werden konnte, ist auch keine Information über dort enthaltene Firmware-Versionen verfügbar."
            })
            table.insert(messages, {
                id = "brndaltfixed",
                value = "Die Firmware-Version des derzeit nicht aktiven Systems ist fest auf \"%1%fixed%\" eingestellt und kann nicht geändert werden."
            })
            table.insert(messages, {
                id = "brndaltsingle",
                value = "Das oben ausgewählte System unterstützt nur die Firmware-Version \"%1%alternative%\""
            })
            table.insert(messages, {
                id = "brndaltnochg",
                value = ", diese ist im Moment auch eingestellt."
            })
            table.insert(messages, {
                id = "brndaltset",
                value = ", im Moment ist jedoch \"%1%current%\" eingestellt."
            })
            table.insert(messages, {
                id = "brndaltnew",
                value = "Bei der Umschaltung des zu verwendenden Systems wird daher auch gleichzeitig dieser Wert auf \"%1%alternative%\" geändert."
            })
            table.insert(messages, {
                id = "nodata",
                value = "Fehler im Boot-Manager: Es wurden keine Daten für die Anzeige erzeugt."
            })
        else
            table.insert(messages, {
                id = "headline",
                value = "The following systems are available to be booted on this device next time:"
            })
            table.insert(messages, {
                id = "currsys",
                value = "the currently running system"
            })
            table.insert(messages, {
                id = "altsys",
                value = "the alternative system"
            })
            table.insert(messages, {
                id = "switchvalue",
                value = "(linux_fs_start=%1%switch%)"
            })
            table.insert(messages, {
                id = "version",
                value = "version %1%version% built on %2%date%"
            })
            table.insert(messages, {
                id = "modified",
                value = "last modified on %1%date% using \"%2%framework%\""
            })
            table.insert(messages, {
                id = "altinv",
                value = "Unable to identify the installed system in the alternative partitions.\nIt may use an unknown filesystem format, it may have been damaged, it's simply missing or it has been deleted otherwise.\nSwitching to this system may prevent your device from starting correctly.\nYou should be really sure, what you are doing in this case."
            })
            table.insert(messages, {
                id = "altmiss",
                value = "The alternative partitions do not contain any valid system."
            })
            table.insert(messages, {
                id = "brndhead",
                value = "Change branding"
            })
            table.insert(messages, {
                id = "brndunsupp",
                value = "Unable to change the branding permanently on this device."
            })
            table.insert(messages, {
                id = "brndcurrfixed",
                value = "Branding of currently running system was set to a fixed value of \"%1%fixed%\" and can not be changed."
            })
            table.insert(messages, {
                id = "brndcurrsingle",
                value = "The system selected above supports only the single OEM name \"%1%current%\" and this is also the current one."
            })
            table.insert(messages, {
                id = "brndmulti",
                value = "The system selected above supports different OEM names, currently the value \"%1%current%\" is set."
            })
            table.insert(messages, {
                id = "brndset",
                value = "Restarting the device now, will set this name to the following value (until it's changed once more):"
            })
            table.insert(messages, {
                id = "brndaltinv",
                value = "Due to problems identifying the installed alternative system, there's no idea, which values are supported by this system and the value remains unchanged."
            })
            table.insert(messages, {
                id = "brndaltfixed",
                value = "Branding of installed alternative system was set to a fixed value of \"%1%fixed%\" and can not be changed."
            })
            table.insert(messages, {
                id = "brndaltsingle",
                value = "The system selected above supports only the single OEM name \"%1%alternative\""
            })
            table.insert(messages, {
                id = "brndaltnochg",
                value = " and this is also the current one."
            })
            table.insert(messages, {
                id = "brndaltset",
                value = ", but currently \"%1%current%\" is set."
            })
            table.insert(messages, {
                id = "brndaltnew",
                value = "Restarting the device now, will set the OEM name value to \"%1%alternative%\" without any further questions."
            })
            table.insert(messages, {
                id = "nodata",
                value = "Error from boot-manager script: No data to display."
            })
        end
        table.insert(messages, {
            id = "style_caption",
            value = "padding-right: 8px;"
        })
        table.insert(messages, {
            id = "style_sblbl",
            value = "padding-right: 8px;"
        })
        -- end of messages
        local bootmanager = {}
        table.insert(bootmanager, {
            name = "values",
            obj = values
        })
        table.insert(bootmanager, {
            name = "messages",
            obj = messages
        })
        return bootmanager
    end
    data.bootmanager = data_bootmanager()
    return data
end
if box.post.reboot then
    local savecookie = {}
    if box.post.linux_fs_start then
        local linux_fs_start = string.gsub(box.post.linux_fs_start, "'", "")
        local branding = box.post[linux_fs_start .. "_branding"] ~= nil and
                             string.gsub(box.post[linux_fs_start .. "_branding"], "'", "") or ""
        os.execute("/usr/bin/gui_bootmanager switch_to '" .. linux_fs_start .. "' '" .. branding .. "'")
    end
    webuicookie.set_action_allowed_time()
    cmtable.add_var(savecookie, webuicookie.vars())
    cmtable.commit(savecookie)
    gDataRd = newval.validate_and_save {
        name = "reboot",
        redirect = {
            page = "rootReboot"
        }
    }
else
    gDataRd = on_load()
end
gDataRd.timestamp = box.timestamp_ms() - tonumber(g_luatime)
Der grüne Teil ist (u.a.) hinzugefügt und sollte von der gelb gekennzeichneten Zeile ausgeführt werden.

Ich sehe da auf Anhieb kein Problem - witzigerweise wird ja offenbar sogar noch das data-Element (das ja auch erst am Beginn von on_load erstellt wird) in die Antwort aufgenommen (zurückgegeben wird das dann von dem return data unmittelbar am Ende der Funktion), nur fehlen bei Dir darin die beiden Objekre activeCalls und bootmanager, die man in meinem Screenshot oben (der von einer 7490 stammt) noch sehen kann.

Mir fällt jedenfalls kein guter Grund ein, warum (in einem syntaktisch hoffentlich richtig gepatchten Lua-File und in vorhergehenden Versionen funktionierte das ja auch genau so ... außerdem sollte ein Syntax-Fehler zu einer Nachricht auf der Console (der Box) und in der Ausgabe (in die Antwort an den Browser) führen) da zwischen den zwei rot markierten Zeilen (denn data ist ja da, data.activeCalls aber nicht) noch etwas schiefgehen sollte, das KEINE entsprechende Meldung verursacht.

Vielleicht fängt AVM die Exceptions ja mittlerweile auch "außen herum" irgendwo ab (dann wäre es dennoch komisch, daß data überhaupt in der Antwort ist, denn bis zum return data dürfte es ja nie kommen), damit immer eine gültige JSON-Struktur übergeben wird und der Parser im Browser auf der Client-Seite nicht tilt - aber dann sollte zumindest auf der Console (in einer/der ersten Shell-Session) noch irgendetwas zu einem Fehler zu sehen sein.

An irgendeinem von mir eingebauten Syntax-Fehler (irgendwo ein wilder Tastendruck im Editor, der an der falschen Stelle etwas ändert) kann es ja eigentlich auch nicht liegen - die Änderung hast Du ja selbst (an einem File aus irgendeinem Repo von mir) vorgenommen und für die Datei im modfs-beta-Zweig liegt ein Diff vor, was keine weiteren (versehentlichen) Änderungen meinerseits zeigt: https://github.com/PeterPawn/modfs/commit/bc369d9d6692b7a947d6880525d7cc203110b56e - DAS kann es also irgendwie auch nicht sein.
 
Nach dem Patchen sollte die reboot.lua so aussehen
Ich habe die mal in eine Datei kopiert und damit probiert. Ergibt aber auch eine leere Seite und die Antwort von data.lua ist gleich (auch "data": [],). Ich konnte als Unterschiede zu meiner (siehe Anhang) nur Leerzeichen und Leerzeilen und Zeilenumbrüche entdecken.

Ich könnte dir ja den Zugang zu der Box einrichten. Willst du?

BTW: Alle anderen Änderungen mit modfs klappen.

EDIT:
Da MUSS irgendein Problem in der (gepatchten) Lua-Seite reboot.lua existieren,
Richtig. Und zwar in deiner Funktion data_bootmanager()
Wenn ich einige Zeilen da drin so auskommentiere erhalte ich auf der Seite wenigstens den originalen Hinweis und deine Meldung: "Fehler im Boot-Manager: Es wurden keine Daten für die Anzeige erzeugt."
Code:
    local function data_bootmanager()
        local values = {}
--        local pipe = io.popen("/usr/bin/gui_bootmanager get_values")
        local line
--        for line in pipe:lines() do
--            table.insert(values, {
--                id = line:match("^([^=]-)="),
--                value = line:match("^.-=\"?(.-)\"?$")
--            })
--        end
--        pipe:close()
        local messages = {}
Irgend was muss in den (eigentlich nur) 5 Zeilen nicht klappen. Das io.popen? Der Befehl "/usr/bin/gui_bootmanager get_values" lässt sich auf der Konsole ausführen und erzeugt auch die beiden Dateien in /var/tmp/.
 

Anhänge

  • reboot.lua.zip
    2.5 KB · Aufrufe: 2
Zuletzt bearbeitet:
Der Befehl "/usr/bin/gui_bootmanager get_values" lässt sich auf der Konsole ausführen und erzeugt auch die beiden Dateien in /var/tmp/.
Der sollte aber gleichzeitig auch noch in der Shell-Session dann ein paar Zeilen Ausgabe liefern (die Dateien in /var/tmp werden mit den notwendigen Daten als Inhalt erzeugt und so wird der "Cache" dann nur noch per cat nach STDOUT geschrieben: https://github.com/PeterPawn/YourFr...62b50dff421/bootmanager/gui_bootmanager#L1455) - ohne diese Zeilen in STDOUT KANN das Lesen der Ausgaben aus der Pipe im Lua-Code nicht funktionieren. Deshalb müßtest Du noch einmal die Ausgabe in der Console (bzw. in IRGENDEINER Shell-Session, denn das ist KEINE Ausgabe gezielt nach /dev/console) prüfen - wenn da die Daten vorhanden sind (bitte zeigen), dann stimmt vielleicht irgendetwas mit dem io.popen nicht mehr.

Um das dann wieder zu prüfen, könntest Du die Zeilen mit io.popen und mit pipe:close NICHT auskommentieren (die Schleife dazwischen aber schon) und damit dann erneut das erzeugte data-Objekt in der JSON-Ausgabe zeigen. Dann sollte wenigstens ein leeres Array values im JSON stehen (weil es erzeugt, aber in der Schleife nicht befüllt wird) und dann muß man anhand des Ergebnisses weiter überlegen.

Am Environment sollte es jedenfalls auch nicht liegen (spez. an PATH), denn der Aufruf erfolgt ja mit absoluter Pfadangabe - damit sollte das Skript auch im Lua-Code gefunden werden.

Vielleicht hat AVM die Lua-Version gewechselt (habe ich bisher nicht geprüft) oder irgendwie (wo ich auch nicht weiß, ob es tatsächlich machbar ist und es erst - bei Bedarf bzw. genauer Kenntnis, wo es klemmt - nachschauen müßte) die Funktionen in den Standard-Bibliotheken (hier dann in der I/O-Library: https://www.lua.org/manual/5.1/manual.html#5.7) ausgedünnt, denn m.W. verwendet AVM selbst keinen io.popen-Aufruf (aber durchaus auch io.open):
Rich (BBCode):
vidar:~/._fritzbox/FB7590/154.07.39-93231/usr # grep -r "=[ \t]*io\.[p]\?open"
www.nas/avm/secure_link.lua:local file=io.open(secLnkFile,"r")
www.nas/avm/secure_link.lua:local file=io.open(secLnkFile,"w")
www.nas/1und1/secure_link.lua:local file=io.open(secLnkFile,"r")
www.nas/1und1/secure_link.lua:local file=io.open(secLnkFile,"w")
www.nas/avme/secure_link.lua:local file=io.open(secLnkFile,"r")
www.nas/avme/secure_link.lua:local file=io.open(secLnkFile,"w")
rest_api/avmluamessages.lua:  local f = io.open("/dev/console", "w")
rest_api/rest_config.lua:    local f = io.open("/dev/console", "w")
rest_api/api.lua: local f = io.open("/var/tmp/juis_boxinfo.json")
www.myfritz/avm/secure_link.lua:local file=io.open(secLnkFile,"r")
www.myfritz/avm/secure_link.lua:local file=io.open(secLnkFile,"w")
www.myfritz/1und1/secure_link.lua:local file=io.open(secLnkFile,"r")
www.myfritz/1und1/secure_link.lua:local file=io.open(secLnkFile,"w")
www.myfritz/avme/secure_link.lua:local file=io.open(secLnkFile,"r")
www.myfritz/avme/secure_link.lua:local file=io.open(secLnkFile,"w")
lua/capiterm.lua:g_handle = io.open("/dev/console", "w")
lua/wizProgressTracker.lua:local file=io.open("/usr/lua/assi_start.json","r")
lua/general.lua:local file = io.open("/usr/lua/assi_start.json", "r")
lua/general.lua:local file = io.open("/usr/lua/assi_start.json", "r")
lua/first.lua:local file=io.open("/usr/lua/assi_start.json","r")
www/avm/secure_link.lua:local file=io.open(secLnkFile,"r")
www/avm/secure_link.lua:local file=io.open(secLnkFile,"w")
www/avm/support.lua:local f, err = io.open("/sbin/shellinaboxd", "rb")
www/1und1/secure_link.lua:local file=io.open(secLnkFile,"r")
www/1und1/secure_link.lua:local file=io.open(secLnkFile,"w")
www/1und1/support.lua:local f, err = io.open("/sbin/shellinaboxd", "rb")
www/avme/secure_link.lua:local file=io.open(secLnkFile,"r")
www/avme/secure_link.lua:local file=io.open(secLnkFile,"w")
www/avme/support.lua:local f, err = io.open("/sbin/shellinaboxd", "rb")
vidar:~/._fritzbox/FB7590/154.07.39-93231 # strings lib/liblua.so.1.4.1 | grep popen
popen
popen
vidar:~/._fritzbox/FB7590/154.07.39-93231 #
- andererseits sollte die Funktion (zumindest dem grep oben nach) auch enthalten sein.

Insgesamt also alles etwas mysteriös - aber wenn Du weiter testest, schaue ich mir die Ergebnisse gerne weiter an. Einen eigenen Zugriff will ich nicht - das wäre nur per Telnet überhaupt sinnvoll (vor allem, wenn's jetzt doch am Lua-Code hängt) und den gibt man generell nicht nach außen frei - für niemanden.

Wenn Du weiter testen willst und sich das Problem jetzt auf die Lua-Datei zurückführen läßt, brauchst Du auch nicht jedesmal ein neues Image erstellen (selbst wenn es im JS-Code läge, wäre das nicht notwendig) - einfach die Datei irgendwo nach /var/tmp/reboot.lua kopieren und per bind-Mount über die Datei /usr/www/<your_branding>/system/reboot.lua legen. Gegebenenfalls muß dann der ctlmgr (der bedient das GUI als HTTP-Server) noch einmal neu gestartet werden (ctlmgr -s; ctlmgr), damit der den zusätzlichen Mount-Point auch kennt - aber nur einmal, danach sollten weitere Änderungen an der Datei "live" übernommen werden.
 
Der sollte aber gleichzeitig auch noch in der Shell-Session dann ein paar Zeilen Ausgabe liefern
Ja macht er natürlich:
Code:
# /usr/bin/gui_bootmanager get_values
active_version="175.07.39-94410"
active_date="02.02.2022, 04:59:07 Uhr"
active_modified_by="modfs"
active_modified_at="05.02.2022, 17:03:51 Uhr"
active_brandings="1und1 avm avme"
inactive_version="164.07.27"
inactive_date="10.05.2021, 15:48:05 Uhr"
inactive_modified_by="modfs"
inactive_modified_at="15.05.2021, 08:43:11 Uhr"
inactive_brandings="1und1 avm avme"
current_branding="avm"
switch_branding_support=true
current_switch_value=0
system_is_switched=false
#


dann stimmt vielleicht irgendetwas mit dem io.popen nicht mehr.
Das ist aber von mir nur eine sehr bescheidene Vermutung. Ich hatte mich (wie schon in #9 geschrieben) nur gewundert dass die beiden Dateien nicht in /var/tmp/ erzeugt werden wenn ich die Seite "Neustart" aufrufe.

Um das dann wieder zu prüfen, könntest Du die Zeilen mit io.popen und mit pipe:close NICHT auskommentieren (die Schleife dazwischen aber schon)
Habe ich gemacht. Seite ist wieder leer.
und damit dann erneut das erzeugte data-Objekt in der JSON-Ausgabe zeigen.
Ist unverändert (außer der sid :) ): data: []
Dann sollte wenigstens ein leeres Array values im JSON stehen
Nein unverändert. Auch kein "activeCalls: []" oder "bootmanager: [...]".
Im letzten Fall in #13 war das vorhanden.

aber wenn Du weiter testest
Ja. Ich denke es würden sich einige darüber freuen wenn es wieder geht.
schaue ich mir die Ergebnisse gerne weiter an.
Das wäre sehr nett.
das wäre nur per Telnet überhaupt sinnvoll
Oder SSH?
und per bind-Mount über die Datei /usr/www/<your_branding>/system/reboot.lua legen.
Ja das mache ich schon die ganze Zeit
 
Zuletzt bearbeitet:
Habe ich gemacht. Seite ist wieder leer.
Dann haben die vielleicht doch die io.popen-Funktion deaktiviert bei AVM (und die Zeichenketten beim grep weiter oben stammen aus anderen Namespaces) - setze doch mal bitte anstelle des Aufrufs von /usr/bin/gui_bootmanager ein anderes Kommando ein, das eine Ausgabe name=wert erzeugt, z.B. ein /bin/sh -c 'echo test=zeile1'.

Wenn das dann auch keine Ausgabe für values erzeugt, dann ist es wohl tatsächlich das io.popen ... immerhin gibt es bei dessen Dokumentation (Link s.o.) auch den Zusatz: "This function is system dependent and is not available on all platforms." zu lesen - damit ist zumindest schon mal IRGENDEINE Bedingung im Source-Code für die Lua-Library zu erwarten, die das popen ein- oder ausschließt. Wenn ohnehin klar ist, daß ein Auslassen keine anderen Probleme verursacht, könnte man (als Hersteller) diese Bedingung natürlich auch forcieren, selbst wenn die Plattform sie bereitstellen könnte/würde.

Wenn das tatsächlich der Fall sein sollte, könnte man sich noch die Funktion os.execute ansehen (https://www.lua.org/manual/5.1/manual.html#5.8), ob die funktionieren würde. Dazu müßtest Du nur das io.popen durch ein os.execute ersetzen, in etwa so:
Rich (BBCode):
local function data_bootmanager()
local values = {}
os.execute("/usr/bin/gui_bootmanager get_values")
local pipe = io.open("/var/tmp/gui_bootmanager.data")
local line
for line in pipe:lines() do
table.insert(values, { id = line:match("^([^=]-)="), value = line:match("^.-=\"?(.-)\"?$") } )
end
pipe:close()
Von Vorteil ist es hier, daß das Skript beim Aufruf (ohne nocache) schon von selbst die Datei in /var/tmp erzeugt und man sich so irgendwelche Redirections beim os.execute sparen kann.

Wobei das auch gleich noch der zweite Teil ist, den Du testen könntest ... auch ohne das os.execute sollte die Änderung auf ein io.open für die Cache-Datei (sofern die existiert, dank eines anderen Aufrufs der Skript-Datei) zumindest zeigen, ob es noch weitere Probleme gäbe oder ob man sich bei der Suche nach einer Lösung (selbst wenn das os.execute auch stillgelegt sein sollte) auf diese eine Stelle konzentrieren kann.
 
Ja. Ich denke es würden sich einige darüber freuen wenn es wieder geht.

Ja, genau! Hatte vor kurzem eine Anfrage erhalten, dass mal jemand mit einer 7.39er Inhaus/Labor das neue WG auf seiner 7520 (die schon seit eh und je mit einer 7530er Alien-FW mit eigener Signierung läuft) testen möchte (aktuell nur Inhaus für 7530 verfügbar) und er es (warum auch immer) relativ "eilig" hat das mal zu testen.
Und da es bei ihm die Hauptbox ist, wollte ich ihm schon ein modifiziertes 7.39er Image zur Verfügung stellen (welches auch mit seinem Schlüssel signiert ist damit er diese regulär über das Webif installieren kann) wo auch der Bootmanager funktioniert, damit er ohne Konfig-Verlust zum 7.29er Partitionsset zurück wechseln kann per Webinterface (ohne bspw. erst über den Bootloader gehen zu müssen oder über Konsolenzugriff, Edit: Ergänzungen um entspr. Missverständnissen vorzubeugen (siehe nachfolgende Beiträge)). Selbst habe ich gerade keine 7520/7530 mehr zum testen bei mir und meine 7590 ist im Produktivbetrieb, die soll vorerst schön mit 7.29 weiterlaufen, damit wollte ich eigentlich keine 7.39er testen/untersuchen.

Aber lasst euch nicht unter "Druck" setzen (ich weiß, lasst ihr euch sowieso nicht), ich kann warten. ;) Evtl. ist es sowieso sinnvoller zu warten bis es eine offizielle Labor für die 7530 gibt. Muss mir nur was einfallen lassen um den potentiellen (ungeduldigen) Tester noch solange "ruhig" zu stellen. Aber ich werde euch hier weiter beobachten. ;) DuW
 
Zuletzt bearbeitet:
wo auch der Bootmanager funktioniert, damit er ohne Konfig-Verlust zum 7.29er Partitionsset zurück wechseln kann per Webinterface (ohne erst über den Bootloader gehen zu müssen).
Mache das bei meiner 7520 über Telnet bis der Bootmanager wieder geht.
Code:
cat /proc/sys/urlader/environment # schauen welche Partition aktiv ist
echo "linux_fs_start 0/1" >/proc/sys/urlader/environment # umschalten auf die inaktive Partition
reboot
 
Wer sich dennoch einstweilen selbst per Shell helfen will:
Rich (BBCode):
sw_sys()(f=/proc/sys/urlader/environment;v=linux_fs_start;o=$(sed -ne "s|^$v[\t]\([01]\)|\1|p" $f);printf "%s %u\n" "$v" $(((${o:-0}+1)%2))>$f;)
als Einzeiler (ggf. in einer eigenen profile-Datei - falls man eine hat), kann dann einfach über sw_sys aufgerufen werden und schaltet automatisch auf das alternative System (und auch wieder zurück, wenn man's möchte) - und nur das Abfangen einer eingangs leeren Variablen macht das so lang, denn ansonsten geht auch ein:
Rich (BBCode):
name()(f=/proc/sys/urlader/environment;v=linux_fs_start;printf "%s %u\n" "$v" $((($(sed -ne "s|^$v\t\([01]\)|\1|p" $f)+1)%2))>$f;)
, was am Ende 126 Zeichen (plus Name der Funktion) sind und für mich (wo printf und sed gesetzt sind, weil POSIX-konform) nicht weiter zu komprimieren (Vorschläge nehme ich aber gerne).

EDIT: OK, ich habe gerade noch selbst probiert ... das \n (als Zeilenende) kann man sich doch noch schenken beim printf.
 
  • Like
Reaktionen: Insti und NDiIPP
Neustart2.png
Noch Fragen? :)
 
  • Like
Reaktionen: Insti

Statistik des Forums

Themen
244,855
Beiträge
2,219,577
Mitglieder
371,565
Neuestes Mitglied
drummer1327
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.