[Info] modfs - SquashFS-Image (AVM-Firmware) ändern für NAND-basierte FRITZ!Boxen

[vtrash]

Zu deiner Anleitung, ich hab das gerade genau so gemacht und es hat geklappt

Dann habe ich meine Aufgabe gemacht. Die Anleinung ist da, jeder kann es selbst durchführen. Ende gut, alles gut.

 

[PeterPawn]

Dann habe ich meine Aufgabe gemacht. Die Anleinung ist da, jeder kann es selbst durchführen. Ende gut, alles gut.

Es ist ja wunderbar, daß da ein neues Forenmitglied unmittelbar nach dem Veröffentlichen Deines Beitrags genau nur diesen benötigte, um endlich (nach so langer Durststrecke, wo zu der Thematik überhaupt nichts im IPPF zu finden war) wieder eine 7390 mit der debug.cfg zu betreiben. Das verstehe ich natürlich, daß Dich das mit einer gewissen Befriedigung erfüllt, denn es ist ja auch schön, wenn man so umgehend (wenn auch sicherlich unerwartet) helfen konnte. Und wenn Du tatsächlich die Anleitung zur Bedienung von fwmod nicht kanntest und das alles selbst ausgeknobelt hast, dann "Chapeau!".

Ich habe tatsächlich den Thread-Titel etwas unglücklich gewählt bzw. geändert (vorher stand da nur etwas von der 7490), auch wenn ich den Zusammenhang zwischen Deinen Beiträgen und "SquashFS-Image direkt auf der Box ändern" irgendwie nicht sehe und es ja eindeutig als "Info" gekennzeichnet ist, was i.d.R. eher auf eine Erklärung für irgendetwas hindeutet, als auf eine offene Frage. Vielleicht hätte ja das Unterforum auch noch einen weiteren Thread verkraftet?

Aber ich kann ohnehin nichts dagegen tun, daß Du in diesem Thread, der sich eigentlich mit der Änderung ohne Freetz (eben direkt auf der Box) befaßt, eine (weitere) Anleitung für eine mehrfach diskutierte Vorgehensweise mit Freetz hinzufügst. So bleibt mir nur, allen späteren Lesern/Fragestellern zu "modfs" versichern, daß das absolut nichts damit zu tun hat, die Behandlung von NOR-Boxen - wie der 7390 - in "modfs" noch nicht funktioniert und man bitte keine Fragen zur 7390 an mich richten möge.

Diese werde ich ohne jeden Kommentar ignorieren, bis "modfs" auch für die 7390 verfügbar ist und einem (Beta-)Test ausgesetzt werden kann.

EDIT: Ich hab' gerade noch mal ins Wiki geschaut ... wenigstens den Anstand, die Kommandos minimal zu modifizieren (z.B. den Verzeichnisnamen durch eine eigene "Schöpfung" zu ersetzen) sollte man schon haben oder einfach gleich auf die Quelle verlinken. Ich bin der letzte, der etwas gegen überflüssige, OT- und extralange Beiträge sagen sollte ... aber mehr oder weniger nur abzuschreiben und das dann "Dann habe ich meine Aufgabe gemacht. Die Anleinung ist da, jeder kann es selbst durchführen." zu nennen, ist schon fast wieder bewundernswert frech.

 

[Semenchkare]

Hallo,

wer hat's schon mit der 6.24 probiert???

Grrüßle

Seme

 

[PeterPawn]

wer hat's schon mit der 6.24 probiert

Ausprobiert nicht, da ich von der 06.25-Labor ein Downgrade machen müßte und mich das SIP-Problem ohnehin nicht betrifft.

Aber ich habe die Unterschiede zwischen der Version 06.23 und 06.24 geprüft, da sollte es keinerlei Probleme geben. Das einzige, was sich in Dateien in Textform geändert hat (und nur die werden von den Basis-Skripten in "modscripts" ja geändert), ist die Versionsnummer.

 

[Semenchkare]

ich hab's getan, es funktioniert

 

[freebsd-man]

Zuletzt liefen bei mir die reguläre Version 113.06.23 als MOD und FHEM problemlos.
Bei meiner 7490 habe ich erst regulär die aktuelle Labor Version "113.06.25-29912" übers WebIF upgedated und danach den MOD angewendet.
Als Quelle für den MOD habe ich vorher die Labor Firmware als "firmware.image" auf einen angeschlossenen USB-Stick gelegt.

Es gab nur ein kleines Problem.

Die Modifikation 'enable system selection from GUI' wird verarbeitet ...
Überprüfen der unterstützten Sprachen ... OK
Soll die Modifikation 'enable system selection from GUI' mit folgender Beschreibung
Hinzufügen der Auswahl des beim nächsten Start zu ladenden Systems zur
'Neustart'-Maske des AVM-Webinterfaces
angewendet werden ? (j/N) j
Überprüfen der Voraussetzungen für die Modifikation ... OK
Modifikation wird ausgeführt ... OK
Überprüfen des Erfolgs der Modifikation ... Fehler (1)
Die Modifikation war nicht erfolgreich.

Die Modifikation 'enable system selection from GUI' wurde angewendet, Fehlercode = 1.

Nach dem Reboot ist alles soweit ok.
Die "Neustart Modifikation" ist trotzdem verfügbar.
Und meine Telefone melden sich bereits wegen Updates...

Anscheinend wird die Modifikation 'enable system selection from GUI' nicht richtig vom MOD Skript erkannt.

 

[mcmic]

Funktioniert bei meiner neuen 7362sl leider nicht.

USB Stick eingesteckt
OS 6.20

Beim versuch das vorhanden root System zu entpacken hängt sich die Box auf und rebootet :-/

Ermitteln der Hardware-Version ... OK
Prüfen, ob die Hardware-Version unterstützt wird ... OK
Suchen der Einstellung zur Umschaltung auf das alternative System ... OK
Prüfen der aktuell zu startenden Systemversion ... OK
Suchen der aktuellen Kernel-Partition ... OK
Suchen der alternativen Kernel-Partition ... OK
Vergleich der Systeme in den Kernel-Partitionen ... OK
Suchen der aktuellen Dateisystem-Partition ... OK
Suchen der alternativen Dateisystem-Partition ... OK
Überprüfen des zur Verfügung stehenden Speicherplatzes im RAM ... OK
Überprüfen des freien Speicherplatzes für das Auspacken des Dateisystems ... OK

Das System erfüllt die Voraussetzungen zur Modifikation des root-Dateisystems.

Im Moment läuft auf der Box die Version: 131.06.20

Als Ausgangspunkt dieser Modifikationen wird ein SquashFS-Image benötigt.
Dafür stehen drei Möglichkeiten zur Auswahl:

a - das root-Dateisystem des laufenden Systems benutzen
b - ein neues root-Dateisystem aus einem Firmware-Download vom FTP-Server des Herstellers verwenden
c - ein an anderer Stelle im Dateisystem abgelegtes Image verwenden
q - keine Änderungen vornehmen

Bitte den Buchstaben des gewünschten Punktes eingeben : a

Als Quelle wird das root-Dateisystem des laufenden Systems verwendet, damit werden auch bereits vorhandene
Änderungen automatisch in das neue System übernommen. Für das Vermeiden doppelter Änderungen sind die
jeweiligen Skripte verantwortlich.

ext3-Dateisystem für loop-Mount wird entpackt ... OK
ext3-Dateisystem über loopback-Device einbinden ... OK
Entpacken des root-Dateisystem für die Modifikationen ... /

Dasselbe wenn ich versuche ein Image per FTP runterzuladen, da hängt sich die Box schon während des downloads auf und rebootet.
Macht auf mich den Eindruck fehlendes Speichers? 4 GB USb steckt .... merkwürdig

Ideen wie ich das doch hin bekomme?

 

[PeterPawn]

@mcmic:
Das ist natürlich etwas schwer zu sagen, was da schief geht.

Das Skript versucht ein File auf dem USB-Stick per Loopback-Device als ext3-Filesystem zu mounten, damit die Dateirechte beim erneuten Einpacken richtig gesetzt werden.

Dieses File ist in gepackter Form als 128 MB großes gz-File im Skript enthalten, wird auf den USB-Speicher ausgepackt (das funktioniert offenbar noch), per Loopback-Device gemountet und dann als Ziel für das Entpacken des AVM-Firmware-Images verwendet.

Im letzten Schritt scheint dann das Problem zu liegen ...

Um das Problem zu isolieren (06.20 funktionierte auf 7362SL definitiv), müßte man diese Schritte mal von Hand der Reihe nach ausführen.

gunzip -c files/128MB_ext3.gz >/var/media/ftp/???/ext3_fs.image
mkdir /var/unpack
mount /var/media/ftp/???/ext3_fs.image /var/unpack
cd /var/unpack
unsquashfs -list /var/media/ftp/???/firmware.image

??? ist das korrekte Verzeichnis für Deinen Stick, die Datei "firmware.image" ist das "innere Dateisystem" aus dem AVM-Firmware-Image.

Eine image-Datei von AVM ist ein TAR-Archiv, das ein Unterverzeichnis "var" enthält. Dort liegt dann in einem Unterverzeichnis "tmp" eine Datei "filesystem.image", die ein SquashFS-Image mit einem rudimentären Dateisystem enthält. In diesem Dateisystem liegt dann endlich die "innere Firmware-Datei" mit dem Namen "filesystem_core.squashfs". Das ist die Datei, die zuerst ausgepackt, dann modifiziert und dann erneut eingepackt werden muß.

Wenn Du diese Kommandos der Reihe nach von Hand ausführst, sollte man eigentlich sehen können, wo es zum Abbruch kommt ... wobei ein Neustart schon ein richtig heftiger Abbruch ist. Es gibt zwar extra eine Option, daß eine OOM-Condition zu einem Watchdog-Restart führen kann, aber daß diese im laufenden Betrieb greift, wenn da nicht irgendetwas fürchterlich Speicherfressendes läuft, ist schon eher ungewöhnlich.

Wenn es tatsächlich am Speichermangel scheitert, dann eher am Hauptspeicher ... ein pauschaler Tipp, wie man da am besten vorgeht, ist schwierig zu geben. Wenn man die ganzen Vorbereitungen von AVM vor einem FW-Upgrade durchzieht (prepare_fwupgrade), legt man leider auch das USB-Subsystem lahm und muß das dann erst wieder von Hand starten ... was dann auch wieder einige AVM-Dienste anwirft, das ist ein Teufelskreis, den man nur durch manuelles Stoppen der nicht benötigten Dienste (hängt davon ab, was da bei Dir läuft) durchbrechen kann.

Das mit dem Download per FTP hört sich auch komisch an ... wenn da tatsächlich schon beim Download der Neustart erfolgt (das ist ein ganz "normales" ftpget), würde ich eher auf einen Defekt auf dem USB-Datenträger tippen ... die Antwort sollte nach dem Neustart aber auch in der Datei "/var/flash/crash.log" zu finden sein, wenn diese beim Restart noch richtig geschrieben wird.

 

[mcmic]

Hi PeterPawn.

Mercie für die Antwort ... ok ich versuche das ganze mal von Hand zu machen

Also auf dem USB Stick war ein Ordner mit nem loopback file drinnen.

Habe jetzt mal ein fw image auf dem Stick gepackt den vorher neu formatiert, die modfs.tgz geladen, in /var/mod entpackt und die Schritte ausgeführt die du erwähnst.
Allerdings hat die Box ja kein unsquashfs. Warum sind da im modfs 3 ordner mit jeweils unsquashfs binarys?

Egal -- der versuch mit

/var/mod/bin/unsquashfs -list /var/media/ftp/Storage-01/fw.image

zu entpacken schlägt fehl. Was ist das für ein Parameter "list" ? Kennst das unsquashfs nicht
Der versuch, egal welches unsquashfs ich verwende ohne den "list" parameter, bringt den Fehler:

cant't find a SQUASHFS superblock on /var/media/ftp/Storage-01/fw.image

Die crash.log ist zwar vorhanden kann aber nicht mit vi geöffnet werden da, "kein regular file" nvi behauptet die Datei sei nicht vorhanden....

 

[PeterPawn]

Warum sind da im modfs 3 ordner mit jeweils unsquashfs binarys?

Ist eigentlich alles nur ein einzelnes unsquashfs und ein mksquashfs, jeweils unter der HWRevision der passenden Box verlinkt ... das "tar" der Busybox macht da beim Entpacken etwas falsch.

Was ist das für ein Parameter "list" ? Kennst das unsquashfs nicht

Das kommt davon, wenn man die Kurzform (li) falsch interpretiert und ausschreibt, wie ich es in diesem Fall gemacht habe. Richtig ist (nach unsquashfs -h) die Option "-linfo". Wenn da kein SquashFS-Superblock ist, ist es wohl die falsche Datei. Ein SquashFS-Image erkennt man problemlos an der Zeichenkette "sqsh" in den ersten vier Byte eines Hexdumps.

Die crash.log ist zwar vorhanden kann aber nicht mit vi geöffnet werden da, "kein regular file" nvi behauptet die Datei sei nicht vorhanden....

Mit "cat" (ist ein char-Device) in eine Datei auf dem Stick schreiben lassen und dann von dort weiter benutzen.

EDIT:
Ich habe gerade noch einmal (außerhalb der FRITZ!Box, da ich im Moment keine 7362SL im Zugriff habe) ein Image vom AVM-FTP-Server geladen, es mit "tar" ausgepackt und zweimal "unsquashfs" (einmal für "filesystem.image" und einmal für "filesystem_core.squashfs") verwendet. Das ließ sich problemlos entpacken, es liegt also nicht an der Struktur des AVM-Images. Da läuft irgendwas auf Deiner Box schief ...

 

[mcmic]

Mit "cat" (ist ein char-Device) in eine Datei auf dem Stick schreiben lassen und dann von dort weiter benutzen.

schon versucht, geht nicht Datei nicht vorhanden obwohl im ordner zu sehen.

Ok ... weitergespielt. das fm image ist ja ein tar file. das mal auf dem USB Stick manuell entpackt, funzt.
dann die im /var/tmp ordner entahltene filesystem.image mit

/var/mod/bin/files/203/unsquahfs /var/media/ftp/Storage-01/vat/tmp/filesystem.image

in den /var/unpack ordner entpackt.

DAS geht dann alles .... irgendwie kommt es mir vor das das Script nen bug hat, denn wenn ich

c - ein an anderer Stelle im Dateisystem abgelegtes Image verwenden

dann

b - /dev/sda1 (Dateisystem vfat) eingebunden unter /var/media/ftp/Storage-01

Bitte den Dateinamen des Images - entweder ein komplettes Firmware-Image (im tar-Format) oder
ein bereits extrahiertes squashfs-Image (kein komplettes Wrapper-Dateisystem, nur das dort
enthaltene root-Dateisystem) - eingeben, zum Abbrechen ein einzelnes 'q' verwenden :

den Dateinamen fw.image (so heißt das gespeicherte tar fw-image) eingebe, springt das script zurück. Es findet weder das Image noch das entpackte filesystem.image


EDIT:

Interessant! Wenn ich dann noch versuche das filesystem_core.squashfs mit

/var/mod/bin/v203/unsquashfs -d /var/unpack/core /var/unpack/squashfs-root/filesystem_core.squashfs

in das gemountete filesystem zu entpacken .... zack ist die Box weg !!! Reboot !!!

Speicherproblem? Kann ich die modifikation auch extern auf meinem Linux hier erzeugen? bzw. wie muß denn die modifizierte rc.tail.sh aussehen?
Dann denke ichmal das core verzeichniss neu squashen und dann das ganze wieder als filesystem squashen und dann das ganze mit tar wieder zu nem update packen?

EDIT2:
falls jemand das gleiche Problem hat, bei mir läuft es jetzt.
Habe das original FW Image direkt auf dem usbstick via telnet entpackt (tar -xf fw.image)
dann im neu entstandenen verzeichnis var/tmp die Datei filesystem.image mit dem im modfs.tgz enthaltenen unsquashfs binary entpackt
dann im darin neu entstandenen verzeichniss root-squashfs die Datei filesystem_core.squashfs mit unsquashfs entpackt
im darin neu entsandenen unterordner rootfs-squashfs/etc/int.d der rc.tail.sh

am ende das eingefügt:

#########################################################################
mknod /var/flash/debug.cfg c $tffs_major $((0x62))
if ! /usr/bin/checkempty /var/flash/debug.cfg 2>/dev/null; then
. /var/flash/debug.cfg
fi
exit 0

Quelle

dann erst wieder das filesystem_core.squashfs neu gepackt mit mksquashfs
(natürlich das nicht mehr benötigte verzeichniss root-squashfs beseitig)
dann das filesystem.image neu mit mksquashfs packen
das ganze var Verzeichniss wider mit tar als fw-image zurückpacken
(root-squashfs in var/tmp vorher beseitigen)

und dann das ganze als fw update in die box einspielen. Und voila !!
(die FB meckert zwar wegen nicht originaler fw aber trotzdem eingespielt)

debug.cfg wird nach dem neustart gestartet

..... was mich auf den gedanken bringt .... muß man denn überhaupt das ganze image packen/entpacken etc. ??
Könnte man nicht nur die rc.tail.sh als "pseudo-update" einspielen?

Warum es mit dem modfs script nicht geht .... keine Ahnung immer beim unsquashen hängt sich meine box auf ... vielleicht wäre es ja besser nicht in das loopback gemountete file zu entpacken sondern direkt auf den stick?

 

[zyklide]

Box 3370 - telnet über Aktualisierungsfunktion und automatischer Neustart

Hallo,

kann jemand über Erfahrungen mit der Box 3370 berichten?

Der Zugang über telnet geht mit Einspielung einer Aktualisierung, da die Box keine Telefonfunktion besitzt.
Die Box führt jedoch nach etwa 2,5 Minuten einen Neustart durch.

Nun befürchte ich, dass diese Zeit nicht ausreicht, um das Abbild zu ändern.

Ist es möglich diesen Neustart zu verhindern (z.B. über eine andere Methode der Telnetaktivierung)?


Viele Grüße und Danke für das Projekt


EDIT:

Das Beenden des Aktualisierungsprozesses hat den Neustart verhindert.
Glücklicherweise reichte der interne Speicher für die Installation, dass ich nicht extra einen externen Speicher einbinden musste.

Jedoch habe ich jetzt ein neues Problem, einen Fehler im Dateisystem nach der Installation.
Alle vorhandenen Dateien und Verzeichnisse in /var/media/ftp wurden gelöscht und ein Verzeichnis FRITZ wurde erstellt.

Auszug aus /var/media/ftp:

548    137 -rwsrwsrwt    1 42949672 42949672  136.9K Jan  1  1970 ??????????????(...)

Dieser Eintrag erscheint neun mal identisch und die Fragezeichen setzen sich über drei Zeilen fort.

Ist es möglich das Dateisystem überprüfen zu lassen? fsck ist nicht vorhanden.

EDIT2:

Die Größe des Eintrages lässt auf modfs.tgz schließen, habe den Eintrag gelöscht mit:

find -inum 548 -exec rm -f {} \;

Im FritzNas sind die fehlerhaften Einträge nun verschwunden, dafür habe ich nun diese Ausgabe (acht mal in Folge):

ls: /var/media/ftp/����(...)���: No such file or directory

Die Ursache ist mir jedoch unklar, modfs gab keine Fehlermeldungen aus.

 

[thoffi1978]

Hallo,

ich versuche gerade das "Scribt"
mkdir -p /var/mod;cd /var/mod;wget -qO- [url]http://yourfritz.de/modfs.tgz | gunzip -c | tar x;./modfs[/URL]
zu installieren. Das Scribt scheint auch installiert worden zu sein. Ich bekomme aber FHEM nicht zum laufen. So wie ich es verstanden habe soll es damit doch wieder laufen, oder hab ich grad n Denkfehler?

Lieben Gruß
Hoffi

 

[koyaanisqatsi]

Moin

Zum Laufen kriegen und ein simples Entpacken ist nicht dasselbe.

Entpacken geht auch einfacher: tar xzvf modfs.tgz
...jetzt musst du nur nach das richtige Skript ausführen.

 

[thoffi1978]

Vielen Dank für die Antwort,
leider Hilft mir diese Antwort nicht weiter, Ich verstehe es nicht.

Welches richtige Script muss ich ausführen? Damit FHEM startet?

Hoffi

 

[PeterPawn]

modfs ist nur das Framework, das die "Abarbeitung" der "debug.cfg" (unter anderem Namen) wieder reaktiviert (und auch andere vom Nutzer gewünschte Änderungen am Root-FS einer passenden FRITZ!Box vornehmen kann, ohne daß man dafür ein Freetz-Image flashen müßte).

Um damit am Ende FHEM zu starten, mußt Du erstens FHEM installieren (ich habe da keine Ambitionen, da die im Paket auf fhem.de enthaltene Perl-Version nur die alte und fehlerhafte OpenSSL-Implementierung unterstützt - so jedenfalls mein letzter Stand) und kannst dann - wenn Du das Skript zum Erstellen des "edit_rcuser"-Kommandos nicht abgewählt hast - durch Editieren der "rc.user" (das ist der "neue" Name, der in Wirklichkeit der "alte" von TI ist) den automatischen Start des FHEM wieder anordnen.

Ein fertiges Skript, das diese Vorgänge der Reihe nach automatisiert, scheitert wie geschrieben an der Verfügbarkeit eines FHEM-Pakets für die FRITZ!Box, das auch aktuelle und fehlerbereinigte OpenSSL-Versionen in der SSLeay-Lib unterstützt. Wenn es ein solches Paket irgendwann mal auf fhem.de geben sollte, integriere ich umgehend das passende Skript als optional in "modfs".

 

[thoffi1978]

Ok.
das habe ich verstanden.
Magst du mir vielleicht kurz beschreiben wie ich den Befehl in die rc.user eintragen kann?

Vielen lieben Dank schon mal
Hoffi

 

[PeterPawn]

Magst du mir vielleicht kurz beschreiben wie ich den Befehl in die rc.user eintragen kann?

So wie das früher bei der debug.cfg auch funktionierte ... es gibt aber - wenn modfs komplett abgearbeitet wurde - ein zusätzliches Kommando "edit_rcuser". Was für den FHEM-Start am Ende in der debug.cfg/rc.user eingetragen sein muß (sicherlich der Start irgendeines Perl-Moduls aus dem NAND-Flash unter /var/media/ftp/fhem oder so), weiß ich nicht genau ... das Installationspaket von fhem.de modifiziert m.W. die debug.cfg passend, wenn das entsprechende char-Device eingerichtet ist bei der Installation. Das läßt sich durch die Ausführung von

mkconfigfile /var/flash/debug.cfg 98

vor dem Start der Installation des FHEM sicherstellen. Da die Änderung im Inhalt des char-Devices (vereinfacht) stattfindet, ist es beim nächsten Start auch egal, wenn das File auf einmal rc.user anstelle von debug.cfg heißt, die dort enthaltenen Befehlen sollten trotzdem abgearbeitet werden.

Wenn irgendwas davon nicht klappt, braucht man schon das exakte Console-Log ... alles andere ist pures Raten.

 

[pyrochroa]

Neustartmaske leer

Hallo PeterPawn,

auch erst mal vielen Dank für die geniale Arbeit. Ich habe modfs auf der 06.24 durchgeführt und es hat soweit auch alles fehlerfrei geklappt. Ledigilich die Anpassung der der GUI für den Neustart scheint schief zu gehen. Diese Seite ist jetzt komplett leer. Nachdem der Rest gut gelaufen ist und ich die Box auch anderweitig neu starten kann, schmerzt mich das nur mittel. Aber für künftige Updates ist jetzt schon doof, wenn man die originale Bootpartition nicht mehr aktivieren kann. Gibt es da eine Lösung dazu?

 

[PeterPawn]

Nachdem der Rest gut gelaufen ist und ich die Box auch anderweitig neu starten kann, schmerzt mich das nur mittel. Aber für künftige Updates ist jetzt schon doof, wenn man die originale Bootpartition nicht mehr aktivieren kann. Gibt es da eine Lösung dazu?

Höre ich das erste Mal ... diese Modifikation ist eine Kombination aus einem Shell-Skript und etwas zusätzlichem Lua-Code in der Datei /usr/www/${OEM}/system/reboot.lua.

Wenn da etwas nicht richtig funktioniert, müßtest Du das mal "von Hand" testen, was dort schief geht. Bei anderen funktioniert es meines Wissens problemlos.

Das erzeugte Shell-Skript hört auf den Namen "/usr/bin/guibootmanager" und kennt zwei Parameter beim Aufruf: "html_display" oder "switch_to". Beim Aufruf mit "html_display" wird der HTML-Code zur Anzeige erzeugt und beim Aufruf mit "switch_to" wird auf das angegebene System (0 oder 1) umgeschaltet. Der einfachste Test für das Skript besteht also in einem Aufruf von "guibootmanager html_display" in einer Telnet-Session, dabei sollte ein kompletter HTML-Abschnitt erzeugt werden. Da dieser sich eigentlich nicht auf HTML-Code "außen herum" verläßt, sollte er von Änderungen seitens AVM nicht beeinflußt werden.

Als zweites wird eine AVM-Datei mit Lua-Code geändert, deren Ablageort ist abhängig vom Branding der verwendeten Box. Diese Datei sieht im Original an den zwei zu ändernden Stellen so aus:

[...]
require("cmtable")
require("webuicookie")
local savecookie = {}
webuicookie.set_action_allowed_time()
[...]
<form action="/system/reboot.lua" method="POST">
<div id="btn_form_foot">
[...]

Bei der Modifikation sollten dort folgende Änderungen erfolgen:

[...]
require("cmtable")
require("webuicookie")
if box.post.linux_fs_start then
os.execute("/usr/bin/guibootmanager switch_to "..box.post.linux_fs_start)
end
local savecookie = {}
webuicookie.set_action_allowed_time()
[...]
<form action="/system/reboot.lua" method="POST">
<div id="managed_reboot" class="reboot_managed">
<?lua
pipe = io.popen("/usr/bin/guibootmanager html_display")
line = pipe:read("*a")
pipe:close()
box.out(line)
?>
</div>
<div id="btn_form_foot">
[...]

Theoretisch sollte beim Modifizieren der AVM-Datei eine Kontrolle des Erfolgs dieser Aktion erfolgen. Wenn das aus irgendeinem Grund nicht funktioniert haben sollte, wäre die entscheidende Frage, was da schief gelaufen ist.

Du müßtest also die Datei auf Deiner Box mit dem gewünschten Resultat vergleichen und die Unterschiede ermitteln.