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.
Zu deiner Anleitung, ich hab das gerade genau so gemacht und es hat geklappt
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!".Dann habe ich meine Aufgabe gemacht. Die Anleinung ist da, jeder kann es selbst durchführen. Ende gut, alles gut.
Ausprobiert nicht, da ich von der 06.25-Labor ein Downgrade machen müßte und mich das SIP-Problem ohnehin nicht betrifft.wer hat's schon mit der 6.24 probiert
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.
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 ... /
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
/var/mod/bin/unsquashfs -list /var/media/ftp/Storage-01/fw.image
cant't find a SQUASHFS superblock on /var/media/ftp/Storage-01/fw.image
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.Warum sind da im modfs 3 ordner mit jeweils unsquashfs binarys?
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.Was ist das für ein Parameter "list" ? Kennst das unsquashfs nicht
Mit "cat" (ist ein char-Device) in eine Datei auf dem Stick schreiben lassen und dann von dort weiter benutzen.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.
in den /var/unpack ordner entpackt./var/mod/bin/files/203/unsquahfs /var/media/ftp/Storage-01/vat/tmp/filesystem.image
dannc - ein an anderer Stelle im Dateisystem abgelegtes Image verwenden
b - /dev/sda1 (Dateisystem vfat) eingebunden unter /var/media/ftp/Storage-01
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.imageBitte 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 :
in das gemountete filesystem zu entpacken .... zack ist die Box weg !!! Reboot !!!/var/mod/bin/v203/unsquashfs -d /var/unpack/core /var/unpack/squashfs-root/filesystem_core.squashfs
#########################################################################
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
548 137 -rwsrwsrwt 1 42949672 42949672 136.9K Jan 1 1970 ??????????????(...)
find -inum 548 -exec rm -f {} \;
ls: /var/media/ftp/����(...)���: No such file or directory
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 vonMagst du mir vielleicht kurz beschreiben wie ich den Befehl in die rc.user eintragen kann?
mkconfigfile /var/flash/debug.cfg 98
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.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?
[...]
require("cmtable")
require("webuicookie")
local savecookie = {}
webuicookie.set_action_allowed_time()
[...]
<form action="/system/reboot.lua" method="POST">
<div id="btn_form_foot">
[...]
[...]
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">
[...]