[Info] modfs - SquashFS-Image (AVM-Firmware) ändern für NAND-basierte FRITZ!Boxen
- Ersteller PeterPawn
- Erstellt am
Hallo zusammen und Hi PeterPawn,
auf meiner 7390 (FW 6.23) möchte ich die Türklingeltasterlösung aus dem Beitrag von Pumbo umsetzten. Dazu muß ich aber die debug.cfg erweitert werden.
Leider scheint die von Dir erstellte Lösung die 7390 noch nicht zu unterstützen und daher kann ich aktuell über Deinen Weg meine 7390 noch nicht mit der Erweiterung ausstatten.
Wird sich da in Kürze was bewegen und die 7390 auch durch die Lösung von PeterPawn unterstützt werden, oder bleibt mir hier nur Freetz übrig?
Gruß und Dank,
ojo
auf meiner 7390 (FW 6.23) möchte ich die Türklingeltasterlösung aus dem Beitrag von Pumbo umsetzten. Dazu muß ich aber die debug.cfg erweitert werden.
Leider scheint die von Dir erstellte Lösung die 7390 noch nicht zu unterstützen und daher kann ich aktuell über Deinen Weg meine 7390 noch nicht mit der Erweiterung ausstatten.
Wird sich da in Kürze was bewegen und die 7390 auch durch die Lösung von PeterPawn unterstützt werden, oder bleibt mir hier nur Freetz übrig?
Gruß und Dank,
ojo
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,269
- Punkte für Reaktionen
- 1,750
- Punkte
- 113
@ojo:
Das Aus- und Wiedereinpacken auf einer 7390 ist auch machbar (der Aufbau ist halt etwas abweichend, weil Kernel und Filesystem nicht getrennt sind), mich hält das Problem beim Flashen des resultierenden Files davon ab, das "offiziell" für die 7390 auch anzubieten.
Geht dort das Flashen schief, ist die Box ein Recovery-Fall ... da ist in meinen Augen das Auspacken, Modifizieren und Wiedereinpacken mit Freetz der bessere (weil sicherere) Weg, wo man das Ergebnis vor dem Flashen noch kontrollieren kann.
Ich kann nicht genau sagen, ob mit "fwmod" inzwischen eine 1:1-Kopie der Stock-Firmware ausschließlich mit den gewünschten Änderungen erzeugt wird (da wurde früher auch eine .config mit eingepackt, wenn man das eigentlich nicht wollte) und ob dieser Vorgang auch wiederholt werden kann ... als ich das vor etwas mehr als einem Jahr zuletzt versucht habe (für eine 7270v3 mit 06.05), funkte irgendwie immer "fakeroot" dazwischen, wenn man iterative Änderungen am erzeugten Image vornehmen wollte und anschließend nur neu packen ließ - dann wurden die zusätzlichen Änderungen nicht richtig übernommen und das erzeugte Image war unbrauchbar, ohne daß man es ihm "von außen" ansah.
Das Aus- und Wiedereinpacken auf einer 7390 ist auch machbar (der Aufbau ist halt etwas abweichend, weil Kernel und Filesystem nicht getrennt sind), mich hält das Problem beim Flashen des resultierenden Files davon ab, das "offiziell" für die 7390 auch anzubieten.
Geht dort das Flashen schief, ist die Box ein Recovery-Fall ... da ist in meinen Augen das Auspacken, Modifizieren und Wiedereinpacken mit Freetz der bessere (weil sicherere) Weg, wo man das Ergebnis vor dem Flashen noch kontrollieren kann.
Ich kann nicht genau sagen, ob mit "fwmod" inzwischen eine 1:1-Kopie der Stock-Firmware ausschließlich mit den gewünschten Änderungen erzeugt wird (da wurde früher auch eine .config mit eingepackt, wenn man das eigentlich nicht wollte) und ob dieser Vorgang auch wiederholt werden kann ... als ich das vor etwas mehr als einem Jahr zuletzt versucht habe (für eine 7270v3 mit 06.05), funkte irgendwie immer "fakeroot" dazwischen, wenn man iterative Änderungen am erzeugten Image vornehmen wollte und anschließend nur neu packen ließ - dann wurden die zusätzlichen Änderungen nicht richtig übernommen und das erzeugte Image war unbrauchbar, ohne daß man es ihm "von außen" ansah.
ich denke hier, dass viele Nutzer von NOR-Modelle mit Hiden-Root-SquashFS (FB7390, FB7330, FB7360, FB7312, FB7320, FB7570, ...) über 2 Binaries (unsquashfs3, squashfs3) dankbar wären;
auch sollte dann per modscripts/mod_rc_tail_sh und modscripts/mod_enable_telnet das Erstellen eines FW-Imagefiles direkt auf der Box, ohne LINUX-PC mit komplexer Freetz-Toolchain möglich sein.
die Bedenken bzgl. Flashen von NOR-Boxen per modfs-Skripte verstehe ich, daher die Idee kein flashen per modfs von NOR-Boxen, sondern ganz normal per AVM-GUI
Gruß
splenditnet
koyaanisqatsi
IPPF-Urgestein
- Mitglied seit
- 24 Jan 2013
- Beiträge
- 14,210
- Punkte für Reaktionen
- 590
- Punkte
- 113
Moins
Du meinst eine Pseudoimagedatei mit modfs inklusive Pseudoimagegenerator für unterstützte Boxen?splenditnet schrieb:
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,269
- Punkte für Reaktionen
- 1,750
- Punkte
- 113
Nach den jüngsten Changesets in Freetz (CS 13288) sollte es kein Problem sein, solche Binaries für Host und Target bereitzustellen. Dazu fühlen sich aber eher andere berufen ... vielleicht gibt es ja auch aus dem Freetz-Trunk heraus künftig eine Möglichkeit, diese Tools direkt (analog zu den Toolchains, meinetwegen als tar-File) irgendwie anzubieten. Ein passendes Ticket dort könnte zumindest "die üblichen Verdächtigen" wie z.B. MaxMuster dazu animieren, einen Versuch ist es in jedem Falle wert und (nett und freundlich) fragen kostet nichts.
Wobei das auch nur die halbe Miete ist. Die NOR-Boxen haben auch eindeutig das Problem des zu geringen Hauptspeichers. Dort muß man also wirklich alles vorher auf die Box an passende Stellen schaffen und dann die Box so weit es geht "herunterfahren" (da ist dann das NAND-FS als "Speicher" für Images sogar die beste Lösung), damit da überhaupt etwas läuft. Das beißt sich dann wieder mit der Notwendigkeit, etwas Swap-Space zur Verfügung zu stellen ... USB-Shutdown vs. Swap-Partition/-File auf einem USB-Volume.
Es ist also machbar auf einer 7390 (vermutlich auch auf anderen Modellen mit 128 MB RAM (habe ich nicht), darunter halte ich persönlich es für aussichtslos, damit wäre die 7570 u.a. aus dem Rennen), aber es erfordert einige Kopfstände ... das ist mehr, als ich einem einzelnen Skript zumuten will (schon bei den kleineren NAND-Boxen als der 7490 braucht es ja einige Umstände, um "memory pressure" entgegenzuwirken) .
Da ist das Einrichten einer kostenlosen AWS-(EC2)-Instanz (t2.micro) am Ende sogar der leichtere Weg, den man auch dann nehmen kann, wenn man keinen eigenen PC und keinen passenden Host für eine eigene VM hat. Dort ein passendes Archiv mit den notwendigen Tools hochgeladen (es gibt z.B. CentOS-Installationen bei EC2, auch LAMP wenn man will) und das eigene Image damit erstellt ... das bleibt weit unterhalb der kostenlosen 750 h/Monat im ersten Jahr. Nur muß eben jemand dieses "Archiv" erst einmal erstellen, daß man dann einfach in den LAMP-Server lädt ... die konkrete Abarbeitung kann man dann wieder selbst über einen Browser auf diesem Server anstoßen. Es gibt auch andere SaaS-/IaaS-Angebote, die bis zu einer gewissen Nutzungshäufigkeit kostenlos bleiben ... notfalls hilft eben auch ein 4,99 EUR-Angebot für einen vServer mit monatlicher Kündigungsfrist, solange man nicht jede Woche ein neues Image erstellen will - das gibt es alles wie Sand am Meer im Internet.
Vielleicht findet sich ja auch mal jemand, der eine passende Umgebung für einen Freetz-Build auf der Basis des (kostenlosen) OBS bauen will o.ä. ...
Es gibt auch ohne eigene Freetz-Instanz so viele Möglichkeiten, daß es nichts bringt, das auf Teufel komm raus unbedingt auf der Box selbst machen zu wollen (wenn diese dafür weniger geeignet ist, bei der 7490 sehe ich das eben anders) und heutzutage ist SaaS/IaaS für einen Build-Host auch eine realistische Möglichkeit. Da ist das von vielen verwendete Ubuntu-Image für die "Freetz-VM" schon fast "old school" ... und wenn man sich überlegt, wie oft der größte Teil dieser VMs vermutlich angeworfen wird (ich schätze mal auf 3-4x pro Jahr), dann läuft das ja eher auf "start, execute and freeze again" hinaus als auf einen "Dauerbetrieb".
Die einzigen "Vorteile", die sich aus der direkten Abarbeitung auf der Box ergeben, betreffen die Möglichkeit, so ein Update auch per Fernwartung anzustoßen (von einem fertigen Image) ... das ist bei unsignierter Firmware und der Notwendigkeit, die Box vor dem Umpacken weitgehend stillzulegen bei einem Vorgehen analog zu "modfs", nicht aus der Ferne machbar - das braucht also von 10.000 FRITZ!Box-Admins vermutlich ein einzelner wirklich und auch das ließe sich mit einer passenden initialen Modifikation (die allerdings wohlbedacht sein sollte, damit die Sicherheit der Box darunter nicht leidet) ein für allemal "beheben".
Was man ansonsten noch alles machen könnte, habe ich oft genug aufgezählt ... das ist aber alles für einen einzelnen einfach zuviel Arbeit und solange sich nicht ein paar Leute zusammentun und da mal neue Wege abseits der ausgelatschten Pfade von Freetz beschreiten wollen, ist das als Idee zwar alles schön und gut - es krankt halt nur an der Umsetzung. Ich verweigere auch nicht meine Mitarbeit an so einem (neuen) Projekt (von Freetz bin ich erst einmal "geheilt"), aber ich bin auch realistisch genug um zu wissen, daß man es alleine eben nicht stemmen kann.
Zuletzt bearbeitet:
@PeterPawn:
Danke für die Inputs.
für mich sieht es somit aus:
der Großteil der Besitzer einer NOR-Box (FB7390, FB7330, FB7360, FB7312, FB7320, FB7570, ..., FB6810, FB6842) können aktuell und zukünftig (sofern AVM hier Fritz!OS 06.35 released) im Gegensatz zu Eigentümer von NAND-Boxen sich das Box-Modding /var/flash/debug.cfg alias rcuser sowie Softlink /usr/sbin/telnetd "abschminken", da Pseudo-Firmware-Update nicht reboot-persistend ist und andere Methoden wie Freetz-fwmod Spezialwissen und Zusatz-LINUX-VMs benötigen.
Somit bleibt für mich nur HW-Upgrade von FB7330 nach FB7490;
die "kaufmännische Hürde" hinsichtlich HW-Upgrade muß von jedem einzeln bewertet werden;
in meinem Fall ergeben sich Nominal folgende Mehrwerte bei einem Wechsel: Dual-Core CPU vs. Single-Core, ferner 2S% mehr Taktfrequenz (500 MHz statt 400 MHz), mehr RAM 256 MB statt 64 MB und näturlich ca. 415 MB "Onboard NAND-Speicher"
Gruß
Splenditnet
Danke für die Inputs.
für mich sieht es somit aus:
der Großteil der Besitzer einer NOR-Box (FB7390, FB7330, FB7360, FB7312, FB7320, FB7570, ..., FB6810, FB6842) können aktuell und zukünftig (sofern AVM hier Fritz!OS 06.35 released) im Gegensatz zu Eigentümer von NAND-Boxen sich das Box-Modding /var/flash/debug.cfg alias rcuser sowie Softlink /usr/sbin/telnetd "abschminken", da Pseudo-Firmware-Update nicht reboot-persistend ist und andere Methoden wie Freetz-fwmod Spezialwissen und Zusatz-LINUX-VMs benötigen.
Somit bleibt für mich nur HW-Upgrade von FB7330 nach FB7490;
die "kaufmännische Hürde" hinsichtlich HW-Upgrade muß von jedem einzeln bewertet werden;
in meinem Fall ergeben sich Nominal folgende Mehrwerte bei einem Wechsel: Dual-Core CPU vs. Single-Core, ferner 2S% mehr Taktfrequenz (500 MHz statt 400 MHz), mehr RAM 256 MB statt 64 MB und näturlich ca. 415 MB "Onboard NAND-Speicher"
Gruß
Splenditnet
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,269
- Punkte für Reaktionen
- 1,750
- Punkte
- 113
@splenditnet:
So kann man das auch zusammenfassen ... ich werde sicherlich bei der 7490 (das ist halt der "main path" für meine eigenen Kunden bei Neuanschaffungen) auch künftig "modfs" weiterführen und das auch noch etwas ausbauen für weitere NAND-Modelle, soweit diese das unterstützen. Vermutlich werde ich noch das Einrichten von Swap-Space und das teilweise Herunterfahren unter bestimmten Bedingungen mit in "modfs" aufnehmen ... aber vermutlich erst in einer weiteren Version, die sich nicht mehr ausschließlich auf Shell-Code stützen wird.
Das ist aber ohnehin eher nur für den Vorgang bei der "ersten Modifikation" ... entscheidender wird künftig sicherlich sein, daß/ob man in die AVM-Firmware entsprechende Vorkehrungen einbaut, um die Firmware tauglich für "dynamische Erweiterungen" zu machen. Da habe ich etwas in Arbeit, wann das "reif" für eine Veröffentlichung ist, kann ich noch nicht sagen.
Auf alle Fälle wird sich das wohl tatsächlich auf neuere Modelle und "große Boxen" beschränken ... ältere Boxen (das sind ja fast immer die NOR-Modelle, auch wenn die 4020 da ein "Ausreißer" ist) haben in der Regel ohnehin zu beschränkte Ressourcen, um die überhaupt noch aufzubohren - da hat AVM in der Stock-Firmware inzwischen soviele Zusätze nachgerüstet (ob man die immer alle braucht, spielt dabei ja leider keine Rolle, weil das nicht modularisiert ist), daß eben auch eine 7390 mit allen eingeschalteten Features (die hat halt die meisten zu bieten bei den NOR-Modellen) tatsächlich beim RAM an ihre Grenzen stößt mit den verbleibenden 108 MB für die Nutzung durch das System. Das läßt sich zwar dort durch ein passendes Swapping noch etwas entschärfen, aber Swap-Space auf einem USB-Stick ist schon von der Geschwindigkeit des Sticks her eigentlich ziemlicher Unfug, da die wenigsten (2.0)-Sticks halbwegs ordentliche Schreibraten bieten (ich habe gerade wieder einen "Intenso 16 GB" in die Hände bekommen, der es sage und schreibe auf eine Schreibrate von 4,31 MB/s (am PC mit h2testw) bringt) und man dann eine HDD anschließen muß, die i.d.R. den Port mit ihrem Strombedarf wieder überfordert.
Der interne NAND ist wegen der Anbindung als Swap-Space auch eher ungeeignet und so hilft bei diesen Modellen entweder nur viel Geduld oder ein Aufbau mit aktivem USB-Hub und HDD an diesem Hub, der den Aufwand nicht wirklich lohnt. Wer allerdings in der Grabbelkiste ohnehin noch einen Hub und ein altes USB2-HDD-Gehäuse für 2,5"-HDDs mit IDE-Anschluß liegen hat, zusammen mit passenden HDDs (120 GB sind locker genug und für einige dieser HDDs reichen auch die 500 mA aus, wenn der Wandler nicht selbst zuviel Strom zieht), der kann sicherlich auch so alte Schätzchen noch ein wenig länger nutzen ... aber eben nur dann, wenn er die Energie (und das Knowhow) aufbringt, die AVM-Firmware entsprechend anzupassen. Eine 7390 ist also in meinen Augen nicht per se schon aus dem Rennen, aber sie erfordert eben eine komplett abweichende Behandlung und ich werde definitiv modfs nicht offiziell für diese Box erweitern (für "noch kleinere" erst recht nicht) ... das muß dann jemand anderes übernehmen.
Meines Erachtens ist man aber für die Zukunft am besten gerüstet, wenn man für einen DSL-Anschluß
- eine 7490 (ohne Einschränkungen, viel RAM) oder
- eine 3490 (HW-Ausstattung m.W. noch etwas unklar, aber ohne Telefonie (analog, ISDN, DECT - nur IP) trotzdem sicherlich keine schlechte Wahl) oder
- eine 7430 (wohl etwas wenig RAM, aber dafür recht preiswert)
anschafft.
Was aus der 40x0-Serie am Ende wird (für die Leute ohne DSL-Anschluß), steht für mich noch in den Sternen ... die 4020 ist für mich bestenfalls ein Schuß in den Ofen - das mögen andere ja anders sehen - und die 4080 muß sich wohl erst noch materialisieren.
So kann man das auch zusammenfassen ... ich werde sicherlich bei der 7490 (das ist halt der "main path" für meine eigenen Kunden bei Neuanschaffungen) auch künftig "modfs" weiterführen und das auch noch etwas ausbauen für weitere NAND-Modelle, soweit diese das unterstützen. Vermutlich werde ich noch das Einrichten von Swap-Space und das teilweise Herunterfahren unter bestimmten Bedingungen mit in "modfs" aufnehmen ... aber vermutlich erst in einer weiteren Version, die sich nicht mehr ausschließlich auf Shell-Code stützen wird.
Das ist aber ohnehin eher nur für den Vorgang bei der "ersten Modifikation" ... entscheidender wird künftig sicherlich sein, daß/ob man in die AVM-Firmware entsprechende Vorkehrungen einbaut, um die Firmware tauglich für "dynamische Erweiterungen" zu machen. Da habe ich etwas in Arbeit, wann das "reif" für eine Veröffentlichung ist, kann ich noch nicht sagen.
Auf alle Fälle wird sich das wohl tatsächlich auf neuere Modelle und "große Boxen" beschränken ... ältere Boxen (das sind ja fast immer die NOR-Modelle, auch wenn die 4020 da ein "Ausreißer" ist) haben in der Regel ohnehin zu beschränkte Ressourcen, um die überhaupt noch aufzubohren - da hat AVM in der Stock-Firmware inzwischen soviele Zusätze nachgerüstet (ob man die immer alle braucht, spielt dabei ja leider keine Rolle, weil das nicht modularisiert ist), daß eben auch eine 7390 mit allen eingeschalteten Features (die hat halt die meisten zu bieten bei den NOR-Modellen) tatsächlich beim RAM an ihre Grenzen stößt mit den verbleibenden 108 MB für die Nutzung durch das System. Das läßt sich zwar dort durch ein passendes Swapping noch etwas entschärfen, aber Swap-Space auf einem USB-Stick ist schon von der Geschwindigkeit des Sticks her eigentlich ziemlicher Unfug, da die wenigsten (2.0)-Sticks halbwegs ordentliche Schreibraten bieten (ich habe gerade wieder einen "Intenso 16 GB" in die Hände bekommen, der es sage und schreibe auf eine Schreibrate von 4,31 MB/s (am PC mit h2testw) bringt) und man dann eine HDD anschließen muß, die i.d.R. den Port mit ihrem Strombedarf wieder überfordert.
Der interne NAND ist wegen der Anbindung als Swap-Space auch eher ungeeignet und so hilft bei diesen Modellen entweder nur viel Geduld oder ein Aufbau mit aktivem USB-Hub und HDD an diesem Hub, der den Aufwand nicht wirklich lohnt. Wer allerdings in der Grabbelkiste ohnehin noch einen Hub und ein altes USB2-HDD-Gehäuse für 2,5"-HDDs mit IDE-Anschluß liegen hat, zusammen mit passenden HDDs (120 GB sind locker genug und für einige dieser HDDs reichen auch die 500 mA aus, wenn der Wandler nicht selbst zuviel Strom zieht), der kann sicherlich auch so alte Schätzchen noch ein wenig länger nutzen ... aber eben nur dann, wenn er die Energie (und das Knowhow) aufbringt, die AVM-Firmware entsprechend anzupassen. Eine 7390 ist also in meinen Augen nicht per se schon aus dem Rennen, aber sie erfordert eben eine komplett abweichende Behandlung und ich werde definitiv modfs nicht offiziell für diese Box erweitern (für "noch kleinere" erst recht nicht) ... das muß dann jemand anderes übernehmen.
Meines Erachtens ist man aber für die Zukunft am besten gerüstet, wenn man für einen DSL-Anschluß
- eine 7490 (ohne Einschränkungen, viel RAM) oder
- eine 3490 (HW-Ausstattung m.W. noch etwas unklar, aber ohne Telefonie (analog, ISDN, DECT - nur IP) trotzdem sicherlich keine schlechte Wahl) oder
- eine 7430 (wohl etwas wenig RAM, aber dafür recht preiswert)
anschafft.
Was aus der 40x0-Serie am Ende wird (für die Leute ohne DSL-Anschluß), steht für mich noch in den Sternen ... die 4020 ist für mich bestenfalls ein Schuß in den Ofen - das mögen andere ja anders sehen - und die 4080 muß sich wohl erst noch materialisieren.
Hallo PeterPawn:
anbei Feedback/Optimierungs-Vorschläge zum modfs-0.3.1
Problem 1: falsche UNIX-Filepermissions bei Skript modfs
Lösung:
Problem 2: Cleanup fehlt ("umount /dev/loop1")
Lösung:
Gruß
Splenditnet
anbei Feedback/Optimierungs-Vorschläge zum modfs-0.3.1
Problem 1: falsche UNIX-Filepermissions bei Skript modfs
Code:
# tar tvpf modfs-0.3.1.tar
-rw-r--r-- root/root 85032 2015-07-26 18:09:50 modfs
-r--r--r-- root/root 17964 2015-05-11 18:09:34 README
-r--r--r-- root/root 28257 2015-05-11 18:04:02 README.ger
-r--r--r-- root/root 18092 2014-09-03 10:47:14 COPYING
drwxr-xr-x root/root 0 2015-06-08 15:11:19 locale/
-r--r--r-- root/root 12570 2015-06-08 15:13:35 locale/de
-r--r--r-- root/root 10771 2015-05-11 17:50:51 locale/en
drwxr-xr-x root/root 0 2015-06-08 15:10:26 files/
-r--r--r-- root/root 144392 2014-09-14 00:43:43 files/128MB_ext3.gz
drwxr-xr-x root/root 0 2015-07-18 12:53:43 bin/
lrwxrwxrwx root/root 0 2015-06-18 11:52:45 bin/212 -> VR9
lrwxrwxrwx root/root 0 2014-09-22 13:57:43 bin/185 -> VR9
lrwxrwxrwx root/root 0 2014-11-18 02:04:16 bin/175 -> VR9
lrwxrwxrwx root/root 0 2014-09-22 13:57:43 bin/203 -> VR9
lrwxrwxrwx root/root 0 2015-07-18 12:53:43 bin/193 -> VR9
drwxr-xr-x root/root 0 2015-07-26 18:49:37 bin/VR9/
-r-xr-xr-x root/root 431216 2015-07-26 18:49:26 bin/VR9/mksquashfs4
-r-xr-xr-x root/root 56420 2014-09-03 09:57:48 bin/VR9/unsquashfs3
-r-xr-xr-x root/root 361692 2015-07-26 18:49:37 bin/VR9/unsquashfs4
-r-xr-xr-x root/root 105824 2014-09-03 09:57:48 bin/VR9/mksquashfs3
drwxr-xr-x root/root 0 2015-07-26 17:53:11 modscripts/
-r-xr-xr-- root/root 1349 2014-09-22 12:08:06 modscripts/mod_profile
-r-xr-xr-x root/root 2251 2014-09-22 12:01:18 modscripts/mod_rc_tail_sh
-r-xr-xr-- root/root 3818 2014-09-22 13:18:21 modscripts/edit_rcuser
-r-xr-xr-- root/root 1202 2015-07-26 17:53:09 modscripts/mod_enable_telnet
-rwxr-xr-x root/root 11678 2015-07-18 11:06:02 modscripts/gui_boot_manager
-rw-r--r-- root/root 168 2015-07-26 18:50:47 md5sums
-rw-r--r-- root/root 552 2015-07-26 18:50:47 sha512sums
-rw-r--r-- root/root 296 2015-07-26 18:50:47 sha256sums
-rw-r--r-- root/root 200 2015-07-26 18:50:47 sha1sums
#
# ./modfs
-sh: ./modfs: Permission denied
#Lösung:
Code:
# chmod 755 ./modfsProblem 2: Cleanup fehlt ("umount /dev/loop1")
Code:
# grep linux_fs_start /proc/sys/urlader/environment
linux_fs_start 0
#
# /etc/version
113.06.24
#
# df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/root 49152 23356 25796 48% /wrapper
/dev/loop0 20928 20928 0 100% /
tmpfs 122940 1160 121780 1% /var
tmpfs 122940 40 122900 0% /dev
/dev/mtdblock4 2048 904 1144 44% /var/flash
/var/dev/nand 415744 79112 336632 19% /var/media/ftp
#
# mount
rootfs on / type rootfs (rw)
/dev/root on /wrapper type yaffs (ro,relatime)
/dev/loop0 on / type squashfs (ro,relatime)
proc on /proc type proc (rw,relatime)
tmpfs on /var type tmpfs (rw,relatime)
tmpfs on /dev type tmpfs (rw,relatime)
sysfs on /sys type sysfs (rw,relatime)
devpts on /dev/pts type devpts (rw,relatime,mode=600)
/dev/mtdblock4 on /var/flash type yaffs2 (rw,sync,relatime)
/var/dev/nand on /var/media/ftp type yaffs2 (rw,sync,relatime)
usbfs on /proc/bus/usb type usbfs (rw,relatime)
#
# uptime
16:33:40 up 2 min, load average: 1.26, 0.71, 0.28
#
# sh ./modfs update /var/media/ftp/jw/fritzbox-labor_7490-30987/FRITZ.Box_7490_Labor.113.06.35-30987.image
SNIP
Beim nächsten Start der Box wird das System in den alternativen Partitionen benutzt.
Sollte beim Start ein Problem auftreten, kann z.B. mit dem ruKernelTool wieder auf das aktuell laufende
System umgeschaltet werden.
Das neue root-Dateisystem wurde erfolgreich modifiziert und in die inaktive Partition kopiert.
Beim nächsten Start der Box wird das System in den alternativen Partitionen benutzt.
Sollte beim Start ein Problem auftreten, kann z.B. mit dem ruKernelTool wieder auf das aktuell laufende
System umgeschaltet werden.
# df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/root 49152 23356 25796 48% /wrapper
/dev/loop0 20928 20928 0 100% /
tmpfs 122940 23248 99692 19% /var
tmpfs 122940 40 122900 0% /dev
/dev/mtdblock4 2048 904 1144 44% /var/flash
/var/dev/nand 415744 79112 336632 19% /var/media/ftp
/dev/loop1 22004 1 22003 0% /var/tmp/2203_1438440366/wrapperfs
# ls -la /var/tmp/2203_1438440366/wrapperfs
drwxr-xr-x 2 root root 1024 Aug 1 16:46 .
drwxr-xr-x 3 root root 60 Aug 1 16:46 ..Lösung:
Code:
# umount /dev/loop1
# df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/root 49152 23356 25796 48% /wrapper
/dev/loop0 20928 20928 0 100% /
tmpfs 122940 1172 121768 1% /var
tmpfs 122940 40 122900 0% /dev
/dev/mtdblock4 2048 904 1144 44% /var/flash
/var/dev/nand 415744 79112 336632 19% /var/media/ftp
#Gruß
Splenditnet
Ungeachtet gewisser (zweifellos existierender) "Meinungsverschiedenheiten" habe ich kein Problem damit, einige modfs related Patches in Freetz aufzunehmen. Ich hätte lediglich folgende Anforderungen an diese:
- die Patches sollten semantisch getrennt sein, d.h. jeder Patch soll genau ein Problem adressieren
- sofern die Patches in Freetz Kontext keinen Sinn machen bzw. mit Freetz host-Paketen kollidieren, sollten diese optional gemacht werden bzw. die Änderungen aus diesen mit #ifdef's versehen werden
Das meiste aus #2730, #2731 habe ich abgearbeitet. Mir fallen folgende Erweiterungen/Anpassungen ein, die ich in Deinen Patches gesehen habe, die jedoch noch nicht in Freetz aufgenommen wurden:
- "-m[angled]"-Parameter bei SquashFS3 tools
- "make SquashFS1/SquashFS2 support optional" bei SquashFS3 tools
- "make SquashFS1/SquashFS2/SquashFS3 support optional" bei SquashFS4 tools
- weitere "Abspeck"-Patches wie "drop libm dependency/remove progress bar", "remove option xy", usw.
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,269
- Punkte für Reaktionen
- 1,750
- Punkte
- 113
OK, da sind irgendwo beim Einpacken die Permissions auf der Strecke geblieben. Danke für den Hinweis, ist bereits korrigiert.
Ohne Debug-Log (dafür habe ich das ja implementiert) kann man nicht sehen, welche Datei sich nun eigentlich hinter /dev/loop1 verbirgt. Normalerweise ist da für jedes "mount" auch ein passenden "umount" vorgesehen, wenn das bei Dir nicht ausgeführt wurde, muß man im Debug-Log nachsehen, welchen Weg die Abarbeitung genommen hat. Unter dem Namen "wrapperfs" wird eigentlich nur bei der Erkennung oder beim Download eines Images vom AVM-Server gemountet, beides kann eigentlich bei Dir nicht der Fall sein, wenn der Aufruf stimmt. Dann bleibt nur noch das Kopieren des gesamten Wrapper-FS in die mtdblock-Partition als mögliche Ursache übrig und wie das dort abläuft, hängt in höchstem Maße davon ab, was die vorhandene Busybox zu bieten hat an Kommandos und wie das Zieldateisystem aussieht ... das wiederum hängt davon ab, von wo nach wo man das Update machen läßt.
Fazit:
- Punkt 1 dankend zur Kenntnis genommen und korrigiert
- Punkt 2 braucht das zugehörigen Debug-Log ... dort steht dann auch drin, von wo nach wo das Update erfolgen sollte.
Ansonsten sehe ich im Moment auch nicht auf Anhieb, wo da dieses "mount"-Kommando übrig bleiben sollte ... bist Du ganz sicher, daß das nicht Überreste nach einem vorhergehenden Fehler sind? Auch das klärt eben das Debug-Log (dann fehlt in der aktuellen Abarbeitung eben das dazugehörige "mount") ... es macht ja keinen Sinn, da nur zu raten.
EDIT: Ok, zwei kleinere Änderungen (Versionsanzeige der AVM-Version jetzt auch mit "subversion" und Unterstützung des "losetup"-Applets der Busybox, das die "--show"-Option nicht kennt und eine nachträgliche Abfrage des Loop-Device erforderlich macht) habe ich auch noch eingebaut ... und gerade noch einmal von 06.30 auf 06.35-30987 ein Update ausführen lassen (ohne das dann auch zu benutzen) - dabei blieb bei mir (wie vorher auch) kein "orphaned mount" übrig.
Zuletzt bearbeitet:
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,269
- Punkte für Reaktionen
- 1,750
- Punkte
- 113
Ich finde nicht, daß das notwendig ist/Sinn macht ... das hat auch nichts mit "Verweigerungshaltung" o.ä. zu tun, das liegt ganz simpel daran, daß es am Ende ohnehin immer wieder geändert wird und ich damit stets erneut vor der Entscheidung stehe, meine eigenen Patches fortzuführen oder nachträglich bei mir alles so anzupassen, daß es mit den von Dir zusätzlich vorgenommenen Änderungen dann wieder läuft (das fängt im simpelsten Fall mit einem anderen Pfad für ein Binary an).
Das ist am Ende immer doppelte Arbeit für mich ... wir haben es doch nun lange genug probiert und sind dann (sicherlich im Konsens) zu der Feststellung gelangt, daß es außer Ärger und erhöhtem Blutdruck auf beiden Seiten nichts bringt.
Ich bin mental aus dem Erstellen von Freetz-Patches ausgestiegen und stelle meine Quellen (wie bereits per E-Mail angekündigt) weiterhin über yourfritz.de bereit. Wenn Du Dich zu einer Integration bestimmter Pakete in Freetz entschließt, begrüße ich das durchaus und werde nicht dagegen arbeiten ... aber auch nicht mehr dafür und so passen diese Patches zukünftig genau zu meiner Umgebung. Stimmt diese mit der von Freetz überein, passen die Patches auch für Freetz ... wenn nicht, dann eben nicht.
Nimm's mir bitte nicht übel ... die Diskussion (und entsprechende Vorleistungen/-arbeiten meinerseits - die teilweise in fast verzweifelte Versuche, es Dir irgendwie recht zu machen, ausgeartet sind) hatten wir jetzt lange genug. Das müssen wir uns gegenseitig nicht antun. Ich bleibe künftig der "neutrale Beobachter".
Das habe ich mit Freuden zur Kenntnis genommen ... mehr aber auch nicht. Das sind ja nun ausgerechnet die Tickets, die eigentlich für Dich die meiste Arbeit nach sich gezogen haben, weil sie eben ausdrücklich gerade nicht zur direkten Integration in die Freetz-Buildumgebung gedacht waren (das sollte auch irgendwo im Text zum Ticket so stehen) und dort nur als Anregung/Begründung/Archiv abgelegt wurden.
Ansonsten habe ich ja an den Stellen, wo meine eigenen Versionen nicht zwingend sind, nach der Integration durch Dich auch auf die mit Freetz erzeugten Versionen gesetzt ... das spart mir zumindest das Patch-Management, wenn ich (was eigentlich gegen meine Überzeugung geht, aber manchmal unvermeidlich ist) nur Binärdateien veröffentliche. Aber ich kann eben wegen kleiner - aber fieser - Unterschiede nicht mit fliegenden Fahnen zur Freetz-Umgebung umschwenken ... das will ich auch gar nicht (der Unterschied fängt bei /usr/lib/freetz an).
Wenn Du noch weiteren "Freetz-Skeptikern" (das meint die Leute, die kein "echtes Freetz-Image" flashen wollen - warum auch immer) eine gewisse Unterstützung anbieten willst (neben einer irgendwie klärenden Modifikation von fwmod - Ticket 2745), könntest Du darüber nachdenken, eine Art "fwmod_lite" nur zum Umpacken zusammen mit den passenden Binaries für x86 in ein tar-File zu packen (oder in einen SVN-Branch) und damit auch den Leuten, die nur das Umpacken auf einer anderen Maschine (s. weiter oben zu SaaS/IaaS) durchführen lassen wollen, die passenden Werkzeuge in die Hand geben. Mir ist aber schon bewußt, daß das wiederum auch nicht der Fokus von Freetz ist ... so müssen sich die Leute mit den NOR-Boxen eben selbst helfen.
Allerdings ist das wahrscheinlich so kurz vor dem Wechsel auf einen neuen Kernel auch der falsche Zeitpunkt ... aber vielleicht kann man das ja bei künftigen Entwicklungen auch im Freetz-Buildsystem im Hinterkopf behalten, daß noch lange nicht jeder in der Lage oder willens sein muß, einen kompletten Freetz-Build zu machen und trotzdem wegen der erhöhten Sicherheitsbestrebungen bei AVM ein neuer Bedarf an Anpassungen - mit deutlich geringerem "foot print" als es Freetz derzeit bietet - entstanden ist.
Ansonsten sehe ich eher nicht, was bzw. wie man modfs mit Freetz zusammenbringen sollte/könnte ... ich sehe eben modfs auch nur als (ein mögliches bzw. alternatives) Werkzeug, um (kleinere) Änderungen an der Stock-Firmware vorzunehmen und im Gegensatz zu Freetz kann ich es mir da eben leisten, nur die Hardware zu unterstützen, auf der das (nach meiner Ansicht) auch Sinn ergibt. Wer das anders sieht und es auch für seine Hardware umsetzen will, kann das ja gerne machen ... er kriegt auch gerne entsprechende Unterstützung und als "Anregung" kann das bisherige Verfahren mit modfs sicherlich auch dienen.
Mein eigentliches Ziel ist und bleibt ein anderes ... die in der ML vor einigen Monaten erläuterten Pläne habe ich ja nicht ad acta gelegt, sondern sie sind nur aufgeschoben und entwickeln sich aufgrund fehlender HR eben etwas langsamer als ich das wollte. Aber Baustein um Baustein entsteht so im Laufe der Zeit ...
Bei mir geht's jetzt von FRITZ.Box_7490_Labor.113.06.29-30480.image auf FRITZ.Box_7490_Labor.113.06.35-30987.image:
Es hat alles nach Wunsch perfekt geklappt. Auch die vorher nicht vorhandene "debug.cfg" mit dem Kommando zum Schreiben ins Syslog wurde erzeugt. In Zukunft kann ich mir da also wieder zusätzliche Dinge eintragen - das hatte ich in der Vergangenheit doch manchmal vermisst.
Als einzigen optionalen Mod habe ich den Symlink für den telnetd einfügen lassen, den Rest habe ich übersprungen.
Das Dateisystem wurde in "/var/media/ftp/1438450694/squashfs-root" abgelegt. Ist das korrekt? Meine beiden USB-Speicher sind ext2.
Zurückgeblieben ist jedenfalls nichts.
Tjah dann will ich mal neu starten. Falls ich hier nie wieder was schreiben sollte... Naja Ihr wisst ja
Code:
# grep linux_fs_start /proc/sys/urlader/environment
linux_fs_start 0
# /etc/version
113.06.29Als einzigen optionalen Mod habe ich den Symlink für den telnetd einfügen lassen, den Rest habe ich übersprungen.
Das Dateisystem wurde in "/var/media/ftp/1438450694/squashfs-root" abgelegt. Ist das korrekt? Meine beiden USB-Speicher sind ext2.
Code:
# df -h
Filesystem Size Used Available Use% Mounted on
/dev/root 48.0M 23.0M 25.0M 48% /wrapper
/dev/loop0 20.6M 20.6M 0 100% /
tmpfs 120.1M 2.5M 117.6M 2% /var
tmpfs 120.1M 80.0K 120.0M 0% /dev
/dev/mtdblock4 2.0M 908.0K 1.1M 44% /var/flash
/var/dev/nand 406.0M 1.3M 404.7M 0% /var/media/ftp
/dev/sda1 929.6G 69.3G 813.7G 8% /var/media/ftp/Samsung-S2Portable-01
/dev/sdb1 29.2G 63.6M 27.7G 0% /var/media/ftp/HUAWEI-TFCARDStorage-01
https://webdav.mediencenter.t-online.de
25.0G 4.5G 20.5G 18% /var/media/ftp/Online-Speicher
Code:
Das neue root-Dateisystem wurde erfolgreich modifiziert und in die inaktive Partition kopiert.
Beim nächsten Start der Box wird das System in den alternativen Partitionen benutzt.- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,269
- Punkte für Reaktionen
- 1,750
- Punkte
- 113
OK, KiRKman sind wir damit also auch los ... :mrgreen:Falls ich hier nie wieder was schreiben sollte... Naja Ihr wisst ja
EDIT: Ja, da ist wohl die Auswahl des Arbeitsverzeichnisses nicht so ganz optimal gelaufen ... deshalb hatte ich mal weiter oben geschrieben, daß ich mit einer einzigen "dummy-Datei" bei mir den freien Platz im NAND auf unter 90 MB drücke. Findet das Skript im NAND genug freien Speicher, nimmt es den (ungeachtet event. Geschwindigkeitsnachteile) ... einfach weil der garantiert "native" ist und damit alle Überlegungen zum Einsatz des Wrapper-Loop-Images mit ext3 entfallen können. Wahrscheinlich müßte man da die Auswahl etwas ändern ... ist nur eine Zeile bei den "präferierten Orten" für die Suche nach ausreichend freiem Speicher. Aber was bei Dir falsch ist (wegen der vorhandenen extX-Partitionen) ist auf einer anderen Box die schnellste und sicherste Lösung.
Zuletzt bearbeitet:
Ja, das ist auch vollkommen in Ordnung, den internen Speicher der Box zu verwenden. So lange hat es jetzt auch nicht gedauert, ich hab nicht einmal auf die Uhr geschaut. Und los seid Ihr mich noch nicht, es funktioniert nämlich soweit alles Ich hab' mir das neue Web-Interface angeschaut, und Telnet geht auch wie gewohnt. Vielen Dank für die ganze Arbeit!
Von 06.29 direkt auf 06.35 ist damit erfolgreich getestet.
Übrigens habe ich keine debug.cfg unter /var/flash. Das wundert mich etwas. Sollte die nicht da sein? Auch unter /var/tmp ist sie nicht. Im Syslog steht aber:
Naja, ist für meine Zwecke egal, aber ich war etwas verwirrt. Ich konnte mir bereits mit "supportdata.dsl" genaue Daten zu meiner Leitung und den Einstellungen der neuen Version ansehen sowie mit "showvoipdstat" die Infos vom voipd, das sind für mich wichtige Dinge, und auch Änderungen über den ctlmgr_ctl gehen noch. Sachen, die ich zu Hause schnell mal eben per Telnet erledigen kann. Sehr gut!
Ich hab' mir das neue Web-Interface angeschaut, und Telnet geht auch wie gewohnt. Vielen Dank für die ganze Arbeit!Von 06.29 direkt auf 06.35 ist damit erfolgreich getestet.
Übrigens habe ich keine debug.cfg unter /var/flash. Das wundert mich etwas. Sollte die nicht da sein? Auch unter /var/tmp ist sie nicht. Im Syslog steht aber:
Code:
01.08.15 20:06:48 Die Datei rc.user (TFFS-Minor-ID 98) wird abgearbeitet ...Weiß zwar nicht, was genau Du damit meinst, aber zur Klarstellung... Mein Angebot galt lediglich der Aufnahme der Patches, die für die Erstellung der von modfs verwendeten SquashFS*-Binaries notwendig sind. Einerseits schreibst Du, dass Du auf die Freetz-Version von SquashFS4 umgestiegen bist, andererseits, wenn es darum geht, SquashFS4 Tools mit ins Image zu packen, nimmst Du immer noch Deine Version davon (wegen der Größe). Das hört sich für mich nach Mehraufwand an - Du musst weiter Deine eigene Version pflegen, sollte ich etwas nicht "passendes" in die Freetz-Version einbauen, musst Du auch noch darauf irgendwie reagieren. Auch musst Du irgendwo eine Fall-Unterscheidung haben - was habe ich vor, welche von beiden Versionen ist dafür besser geeignet und daher zu nehmen ist. Daher der Vorschlag die in Freetz noch fehlenden Anpassungen aufzunehmen.
Die Wahrscheinlichkeit, dass es auseinander läuft, wenn Du weiterhin Deine eigene Version pflegst, ist in meinen Augen größer. Dann müsstest Du früher oder später wieder auf ausschließlich Deine Version umsteigen. Wären die modfs relevanten Patches in Freetz enthalten, wären wir gezwungen, diese mitzupflegen. Der letzte Satz ist die typische Begründung, wenn es darum geht, etwas upstream aufzunehmen, auch wenn das Wort upstream an der Stelle völlig falsch ist (die sich daraus ergebenden Vorteile sind eben dieselben). Denk übrigens auch noch daran, dass es irgendwann mal eine neue Version von SquashFS4 (4.4 oder so) geben könnte.
Das Argument mit dem Binary-Pfad lasse ich nicht gelten ;-) Das hat Dich nicht davon abgehalten, die Freetz-Version mit auszuliefern.
Der Anreiz für mich bestand in erster Linie darin, ein Tool auf dem Build-Host zu haben, welches sowohl ZLIB als auch LZMA komprimierte Images unterstützt, denn einmal in das Binary verlagert spart es ein paar Fall-Unterscheidungen in fwmod (aktuell werden mittels unsquashfs3-multi alle bisher von AVM in Release-Versionen verwendeten SquashFS-Formate entpackt: squashfs2-lzma, squashfs3-lzma, squashfs3-zlib). Auf dem Host hätte ich weiterhin die C++ Version von liblzma1 verwenden können, aber "wo ich dran war" habe ich halt die für die C-only Version notwendigen Anpassungen mitgemacht.
Hmm, /usr/lib/freetz ist eigentlich völlig harmlos. Damit wird lediglich der Pfad angegeben, aus dem die Libraries bevorzugt geladen werden sollten. Existiert der Pfad nicht bzw. enthält die nötige Library nicht, so werden ganz normal alle anderen Standard-Pfade durchsucht (/lib, /usr/lib) und die Libraries aus diesen geladen.
Dadrüber habe ich öfter schon nachgedacht. Solange es aber noch bei Freetz selbst ein paar Baustellen gibt, werde ich diese höher priorisieren.
p.s. Das Angebot, die modfs relevanten Patches aufzunehmen (unter den genannten Prämissen), gilt weiterhin.
Hallo PeterPawn,
ich habe das Problem nachgestellt, inkl. Debug-Option
Es läßt sich reproduzieren,
ich erhalte 2 Auffälligkeiten
1.) "unknown operand" im modfs-output
Code:
# MODFS_DEBUG=1 MODFS_BUFSIZE=32 ./modfs update /var/media/ftp/jw/fritzbox-labor_7490-30987/FRITZ.Box_7490_Labor.113.06.35-30987.image
SNIP
OK
Erstellen eines neuen 'äuÃeren Dateisystems' ...sh: 0: unknown operand
OK
Kopieren des neuen root-Dateisystems in die inaktive Dateisystem-Partition ... OK2.) orphaned Mountpoint /dev/loop1" nach modfs update filename.image
Code:
# MODFS_DEBUG=1 MODFS_BUFSIZE=32 ./modfs update /var/media/ftp/jw/fritzbox-labor_7490-30987/FRITZ.Box_7490_Labor.113.06.35-30987.image
SNIP
# df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/root 49152 23356 25796 48% /wrapper
/dev/loop0 20928 20928 0 100% /
tmpfs 122940 23292 99648 19% /var
tmpfs 122940 40 122900 0% /dev
/dev/mtdblock4 2048 904 1144 44% /var/flash
/var/dev/nand 415744 81156 334588 20% /var/media/ftp
/dev/loop1 22004 1 22003 0% /var/tmp/1911_1438458537/wrapperfs
#Gerne helfe ich beim Troubleshooten.
Gruß
Splenditnet
Code:
# chmod 755 modfs
# MODFS_DEBUG=1 MODFS_BUFSIZE=32 ./modfs update /var/media/ftp/jw/fritzbox-labor_7490-30987/FRITZ.Box_7490_Labor.113.06.35-30987.image
Using debug mode with a 32 KB buffer
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 ... übersprungen
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: 113.06.24
Die Angabe einer Datei nach dem 'update'-Parameter unterbindet jede Versionprüfung.
Somit ist jeder selbst dafür zuständig, die Kompatibilität der vorhandenen Einstellungen
mit dem verwendeten System sicherzustellen, speziell wenn ein Downgrade ausgeführt wurde
oder ggf. die 'Werkseinstellungen' wiederherzustellen.
Die angegebene Datei '/var/media/ftp/jw/fritzbox-labor_7490-30987/FRITZ.Box_7490_Labor.113.06.35-30987.image' wird als Quelle für die Aktualisierung genutzt.
Extrahieren des neuen Kernel-Images aus dem Firmware-Image ... OK
Extrahieren des Flash-Filesystems aus dem Firmware-Image ... OK
Extrahieren des Wurzeldateisystems aus dem Flash-Filesystem ...BPJM Update complete
OK
Entpacken des root-Dateisystem für die Modifikationen ... OK
Das entpackte Dateisystem ist jetzt bereit für die Modifikationen.
Verzeichnis des root-Dateisystems : /var/media/ftp/1438458164/squashfs-root
Die Modifikation 'enable system selection from GUI' wird verarbeitet ...
Ãberprüfen der unterstützten Sprachen ... OK
Ãberprüfen der Voraussetzungen für die Modifikation ... OK
Modifikation wird ausgeführt ... OK
Ãberprüfen des Erfolgs der Modifikation ... OK
Die Modifikation 'enable system selection from GUI' wurde angewendet, Fehlercode = 0.
Die Modifikation 'enable rc.user execution' wird verarbeitet ...
Ãberprüfen der unterstützten Sprachen ... OK
Ãberprüfen der Voraussetzungen für die Modifikation ... OK
Modifikation wird ausgeführt ... OK
Ãberprüfen des Erfolgs der Modifikation ... OK
Die Modifikation 'enable rc.user execution' wurde angewendet, Fehlercode = 0.
Die Modifikation 'create edit_rcuser command' wird verarbeitet ...
Ãberprüfen der unterstützten Sprachen ... OK
Soll die Modifikation 'create edit_rcuser command' mit folgender Beschreibung
Es wird ein zusätzliches Kommando 'edit_rcuser' erzeugt, mit dem die Kommandos
in der Datei 'rc.user' sicher bearbeitet werden können, ohne daà man sich um
die Besonderheiten des TFFS kümmern muÃ.
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 ... OK
Die Modifikation 'create edit_rcuser command' wurde angewendet, Fehlercode = 0.
Die Modifikation '(re)enable telnet daemon' wird verarbeitet ...
Ãberprüfen der unterstützten Sprachen ... OK
Soll die Modifikation '(re)enable telnet daemon' mit folgender Beschreibung
Erstellen eines Symlinks, um die Ausführung des telnetd-Applets der
Busybox wieder zu ermöglicen
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 ... OK
Die Modifikation '(re)enable telnet daemon' wurde angewendet, Fehlercode = 0.
Die Modifikation 'enable custom profile extension' wird verarbeitet ...
Ãberprüfen der unterstützten Sprachen ... OK
Soll die Modifikation 'enable custom profile extension' mit folgender Beschreibung
/etc/profile modifizieren, um die Kommandos in /var/custom/profile am Ende
zusätzlich auszuführen, wenn diese Datei existiert
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 ... OK
Die Modifikation 'enable custom profile extension' wurde angewendet, Fehlercode = 0.
Das ist die letzte Chance zum manuellen Modifizieren des Dateisystems in /var/media/ftp/1438458164/squashfs-root.
Die Eingabetaste drücken, um mit dem Packen des neuen root-Dateisystems zu beginnen
oder 'q' eingeben, um die letzte Möglichkeit zum Abbruch zu nutzen :
Packen des neuen root-Dateisystems ... \
OK
Erstellen eines neuen 'äuÃeren Dateisystems' ...sh: 0: unknown operand
OK
Kopieren des neuen root-Dateisystems in die inaktive Dateisystem-Partition ... OK
Kopieren des neuen Kernel-Images in die Zielpartition ... OK
Festlegen des alternativen Systems als aktives System beim nächsten Start der Box ... OK
Das neue root-Dateisystem wurde erfolgreich modifiziert und in die inaktive Partition kopiert.
Beim nächsten Start der Box wird das System in den alternativen Partitionen benutzt.
Sollte beim Start ein Problem auftreten, kann z.B. mit dem ruKernelTool wieder auf das aktuell laufende
System umgeschaltet werden.
#
# df
Filesystem 1K-blocks Used Available Use% Mounted on
/dev/root 49152 23356 25796 48% /wrapper
/dev/loop0 20928 20928 0 100% /
tmpfs 122940 23292 99648 19% /var
tmpfs 122940 40 122900 0% /dev
/dev/mtdblock4 2048 904 1144 44% /var/flash
/var/dev/nand 415744 81156 334588 20% /var/media/ftp
/dev/loop1 22004 1 22003 0% /var/tmp/1911_1438458537/wrapperfs
#Debug-Output
Code:
# showshringbuf modfs
SNIP
2015-08-01 21:43:49.985 - progress: mode=3, msg= OK
2015-08-01 21:43:50.046 - progress: mode=1, msg=Modifikation wird ausgeführt ...
2015-08-01 21:43:50.129 - progress: mode=3, msg= OK
2015-08-01 21:43:50.187 - progress: mode=1, msg=Ãberprüfen des Erfolgs der Modifikation ...
2015-08-01 21:43:50.218 - is_supported: option=postcheck, from=precheck postcheck install language(en,de), rc=1
2015-08-01 21:43:50.295 - progress: mode=3, msg= OK
2015-08-01 21:43:50.354 - execute_modscript: exiting, rc=0
2015-08-01 21:43:50.372 - execute_optional_modscript: exiting, rc=0
2015-08-01 21:43:50.403 - remove_directory: directory=/var/tmp/1911_1438458212, rc=0
2015-08-01 21:43:50.420 - modify_rootfs: exiting, rc=0
2015-08-01 21:43:55.026 - modfs: modifications done, rc=0
2015-08-01 21:43:55.085 - progress: mode=1, msg=Packen des neuen root-Dateisystems ...
2015-08-01 21:43:55.104 - run_spinner: dir=/var/media/ftp/1438458164, command=pack_squashfs /var/media/ftp/1438458164 /var/media/ftp/1438458164/newroot.squashfs 0 65536 4
2015-08-01 21:43:55.140 - pack_squashfs: using SquashFS version 4
2015-08-01 21:43:55.180 - sq_mksquashfs: /var/media/ftp/jw/modfs-0.3.1/bin/185/mksquashfs4 squashfs-root /var/media/ftp/1438458164/newroot.squashfs -info -b 65536 -force-uid 0 -force-gid 0
2015-08-01 21:48:56.915 - sq_mksquashfs: exiting, rc=0
2015-08-01 21:48:56.933 - pack_squashfs: exiting, rc=0
2015-08-01 21:48:56.960 - run_spinner: exiting, rc=0
2015-08-01 21:48:57.022 - progress: mode=3, msg= OK
2015-08-01 21:48:57.039 - modfs: packing done, rc=0
2015-08-01 21:48:57.098 - progress: mode=1, msg=Erstellen eines neuen 'äuÃeren Dateisystems' ...
2015-08-01 21:48:57.125 - copy_wrapper_filesystem: src=/var/tmp/1438458156/filesystem.image, rootfs=filesystem_core.squashfs
2015-08-01 21:48:57.427 - copy_wrapper_filesystem: clearing target device /dev/mtd3, rc=0
2015-08-01 21:48:57.483 - detect_image_filesystem: src=/var/tmp/1438458156/filesystem.image, fstype=ext2, rc=0
2015-08-01 21:48:57.518 - get_temp_dir: directory=/var/tmp/1911_1438458537
2015-08-01 21:48:57.627 - mount_ext2_image: src=/var/tmp/1438458156/filesystem.image, mp=/var/tmp/1911_1438458537/wrapperfs, type=ext2
2015-08-01 21:48:57.671 - mount_ext2_image: exiting, rc=0
2015-08-01 21:48:58.393 - copy_wrapper_filesystem: copying done, rc=0
2015-08-01 21:48:58.538 - remove_directory: directory=/var/tmp/1911_1438458537, rc=1
2015-08-01 21:48:58.558 - copy_wrapper_filesystem: exiting, rc=0
2015-08-01 21:48:58.616 - progress: mode=3, msg= OK
2015-08-01 21:48:58.634 - modfs: update wrapper filesystem done, rc=0
2015-08-01 21:48:58.693 - progress: mode=1, msg=Kopieren des neuen root-Dateisystems in die inaktive Dateisystem-Partition ...
2015-08-01 21:48:58.731 - get_temp_dir: directory=/var/tmp/1911_1438458538
2015-08-01 21:48:58.750 - copy_new_root_filesystem: src=/var/media/ftp/1438458164/newroot.squashfs, target=/dev/mtdblock3
2015-08-01 21:49:05.174 - remove_directory: directory=/var/tmp/1911_1438458538, rc=0
2015-08-01 21:49:05.191 - copy_new_root_filesystem: exiting, rc=0
2015-08-01 21:49:05.250 - progress: mode=3, msg= OK
2015-08-01 21:49:05.267 - modfs: copying new filesystem done, rc=0
2015-08-01 21:49:05.326 - progress: mode=1, msg=Kopieren des neuen Kernel-Images in die Zielpartition ...
2015-08-01 21:49:05.352 - copy_kernel_image: src=/var/tmp/1438458156/kernel.image, target=/dev/mtd2
2015-08-01 21:49:06.127 - copy_kernel_image: exiting, rc=0
2015-08-01 21:49:06.186 - progress: mode=3, msg= OK
2015-08-01 21:49:06.203 - modfs: update kernel done, rc=0
2015-08-01 21:49:06.261 - progress: mode=1, msg=Festlegen des alternativen Systems als aktives System beim nächsten Start der Box ...
2015-08-01 21:49:06.299 - switch_system_to: alternative
2015-08-01 21:49:06.437 - switch_system: switched to 1
2015-08-01 21:49:06.495 - progress: mode=3, msg= OK
2015-08-01 21:49:06.555 - modfs: switching system done, rc=0
2015-08-01 21:49:18.234 - remove_directory: directory=/var/media/ftp/1438458164, rc=0
2015-08-01 21:49:18.283 - remove_directory: directory=/var/tmp/1438458156, rc=0
2015-08-01 21:49:18.300 - modfs: reached normal exit point, rc=0
2015-08-01 21:49:18.317 - cleanup: running cleanup from file /var/tmp/1911_filelist_1438458152
#- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,269
- Punkte für Reaktionen
- 1,750
- Punkte
- 113
Dem Debug-Log nach tritt das "sh: 0: unknown operand" ja in der Funktion "copy_wrapper_filesystem" auf, was im Log in den Zeilen
Code:
2015-08-01 21:48:57.098 - progress: mode=1, msg=Erstellen eines neuen 'äuÃeren Dateisystems' ...
2015-08-01 21:48:57.125 - copy_wrapper_filesystem: src=/var/tmp/1438458156/filesystem.image, rootfs=filesystem_core.squashfs
2015-08-01 21:48:57.427 - copy_wrapper_filesystem: clearing target device /dev/mtd3, rc=0
2015-08-01 21:48:57.483 - detect_image_filesystem: src=/var/tmp/1438458156/filesystem.image, fstype=ext2, rc=0
2015-08-01 21:48:57.518 - get_temp_dir: directory=/var/tmp/1911_1438458537
2015-08-01 21:48:57.627 - mount_ext2_image: src=/var/tmp/1438458156/filesystem.image, mp=/var/tmp/1911_1438458537/wrapperfs, type=ext2
2015-08-01 21:48:57.671 - mount_ext2_image: exiting, rc=0
2015-08-01 21:48:58.393 - copy_wrapper_filesystem: copying done, rc=0
2015-08-01 21:48:58.538 - remove_directory: directory=/var/tmp/1911_1438458537, rc=1
2015-08-01 21:48:58.558 - copy_wrapper_filesystem: exiting, rc=0
2015-08-01 21:48:58.616 - progress: mode=3, msg= OK
2015-08-01 21:48:58.634 - modfs: update wrapper filesystem done, rc=0
2015-08-01 21:48:58.693 - progress: mode=1, msg=Kopieren des neuen root-Dateisystems in die inaktive Dateisystem-Partition ...Damit kommt eben nur copy_wrapper_filesystem in Frage:
Code:
copy_wrapper_filesystem()
{
local rc target src="$1" tmp fstype [COLOR="#FF0000"]mrc=0[/COLOR] kernelversion
target=$(get_mtd_by_name $reservedprefix$filesystemname)
# prepare MTD writes
# notify power management
echo MODE=update > /dev/avm_power
# prevent unwanted watchdog restarts, may be necessary but update is very fast
# echo "disable" > /dev/watchdog
# clear filesystem first
debug "copy_wrapper_filesystem: src=$src, rootfs=$rootfsname"
$update_kernel_binary -o /dev/$mtdprefix$target >/dev/null 2>&1
rc=$?
debug "copy_wrapper_filesystem: clearing target device /dev/$mtdprefix$target, rc=$rc"
if [ [COLOR="#FF0000"]$rc -ne 0[/COLOR] ]; then
rc=44
else
fstype=$(detect_image_filesystem "$src")
rc=$?
if [ [COLOR="#FF0000"]$rc -eq 0[/COLOR] ]; then
# mount squashfs and yaffs2 wrapper and copy from one to the other
tmp="$(get_temp_dir)"
mkdir -p $tmp/yaffs $tmp/wrapperfs
mount -t yaffs2 /dev/$mtdblockname$target $tmp/yaffs
[COLOR="#008000"] if [ "$fstype" == "ext2" -o "$fstype" == "sqfs_dummy256_ext2" ]; then[/COLOR]
# ext2 image with AVM's dummy header
mount_ext2_image "$src" "$tmp/wrapperfs" "$fstype"
rc=$?
[COLOR="#00FF00"]mrc=$rc[/COLOR]
[COLOR="#008000"] else[/COLOR]
mount "$src" $tmp/wrapperfs 2>/dev/null
rc=$?
[COLOR="#00FF00"]mrc=$rc[/COLOR]
if [ [COLOR="#FF0000"]$rc -ne 0[/COLOR] ]; then
# try to extract with unsquashfs3, if this is a 3.xx kernel based
# system without knowledge about SquashFS3 format while mounting
kernelversion=$(uname -r)
kernelversion=${kernelversion%%.*}
if [ $kernelversion -eq 3 -a x"$fstype" == x"squashfs3" ]; then
unpack_squashfs "$src" "$tmp" 2>&1 >/dev/null
rc=$?
if [ [COLOR="#FF0000"]$rc -eq 0[/COLOR] ]; then
rmdir "$tmp/wrapperfs"
mv "$tmp/$squashfsdirname" "$tmp/wrapperfs"
rc=$?
rm "$tmp/wrapperfs/$rootfsname"
fi
fi
fi
fi
if [ [COLOR="#FF0000"]$rc -eq 0[/COLOR] ]; then
tar -c -O -C $tmp/wrapperfs --exclude=$rootfsname . | tar -x -C $tmp/yaffs
rc=$?
debug "copy_wrapper_filesystem: copying done, rc=$rc"
[ [COLOR="#FF0000"]$mrc -eq 0[/COLOR] ] && [COLOR="#0000CD"]umount $tmp/wrapperfs[/COLOR]
umount $tmp/yaffs
remove_directory "$tmp"
rc=0
fi
fi
fi
debug "copy_wrapper_filesystem: exiting, rc=$rc"
return $rc
}Auch ein Vergleich der bunten Stellen mit Deinem Skript kann nicht schaden, ich hatte vor ein paar Tagen noch einmal an der Stelle etwas ändern müssen, weil ein 3er-Kernel einfach kein "mount" für das ältere SquashFS3-Format kann und man das aber für ein Downgrade von 06.35 auf 06.30 und kleiner braucht. Da muß dann eben anstelle von "mount" und "cp" ein "unsquashfs3" herhalten und dann gibt es unter wrapperfs nichts zum unmounten.
Bei Dir wird ja aber "mount_ext2_image" mit rc=0 beendet, damit wird hier
Code:
if [ "$fstype" == "ext2" -o "$fstype" == "sqfs_dummy256_ext2" ]; then
# ext2 image with AVM's dummy header
mount_ext2_image "$src" "$tmp/wrapperfs" "$fstype"
rc=$?
mrc=$rcHallo PeterPawn,
anbei meine Recherche-Ergebnisse:
zu Problem 1.) "unknown operand" im modfs-output
Code:
# MODFS_DEBUG=1 MODFS_BUFSIZE=32 ./modfs update /var/media/ftp/jw/fritzbox-labor_7490-30987/FRITZ.Box_7490_Labor.113.06.35-30987.image
SNIP
OK
Erstellen eines neuen 'äuÃeren Dateisystems' ...sh: 0: unknown operand
OK
Kopieren des neuen root-Dateisystems in die inaktive Dateisystem-Partition ... OKich denke der Fehler liegt in Funktion copy_wrapper_filesystem()
==> Zeile 650: [ $mrc -eq 0 ] && umount $tmp/wrapperfs
da die Variable $mrc un-initialized ist, wird Fehlermeldung "unknown operand" ausgeworfen und der Befehl "umount $tmp/wrapperfs" NICHT ausgeführt.
Code:
copy_wrapper_filesystem()
{
SNIP
mount -t yaffs2 /dev/$mtdblockname$target $tmp/yaffs
if [ "$fstype" == "ext2" -o "$fstype" == "sqfs_dummy256_ext2" ]; then
# ext2 image with AVM's dummy header
mount_ext2_image "$src" "$tmp/wrapperfs" "$fstype"
rc=$?
else
SNIP
fi
if [ $rc -eq 0 ]; then
tar -c -O -C $tmp/wrapperfs --exclude=$rootfsname . | tar -x -C $tmp/yaffs
rc=$?
debug "copy_wrapper_filesystem: copying done, rc=$rc"
[ $mrc -eq 0 ] && umount $tmp/wrapperfs
umount $tmp/yaffs
remove_directory "$tmp"
rc=0
fish -x output:
+ [ -eq 0 ]
sh: 0: unknown operand
+ umount /var/tmp/2647_1438464823/yaffs
+ remove_directory /var/tmp/2647_1438464823
Lösung:
Code:
copy_wrapper_filesystem()
{
SNIP
mount -t yaffs2 /dev/$mtdblockname$target $tmp/yaffs
if [ "$fstype" == "ext2" -o "$fstype" == "sqfs_dummy256_ext2" ]; then
# ext2 image with AVM's dummy header
mount_ext2_image "$src" "$tmp/wrapperfs" "$fstype"
rc=$?
mrc=$rc # Zeile 625 einfügen: Merker-RC Variable befuellt
else
SNIP
fi
if [ $rc -eq 0 ]; then
tar -c -O -C $tmp/wrapperfs --exclude=$rootfsname . | tar -x -C $tmp/yaffs
rc=$?
debug "copy_wrapper_filesystem: copying done, rc=$rc"
[ $mrc -eq 0 ] && umount $tmp/wrapperfs
umount $tmp/yaffs
remove_directory "$tmp"
rc=0
fish -x output:
+ [ 0 -eq 0 ]
+ umount /var/tmp/5520_1438467290/wrapperfs
+ umount /var/tmp/5520_1438467290/yaffs
+ remove_directory /var/tmp/5520_1438467290
das Problem 2.) orphaned Mountpoint "/dev/loop1"
ist nach meinem Stand ein Folgefehler von Problem 1.)
Unklar, warum das Problem so wie es aussieht nur bei mir aufgetreten ist.
Gruß
Splenditnet
Neueste Beiträge
-
[Frage] Voip und VPN- Letzte: erik
-
7590 flashen stor mtd1 funktioniert nicht
- Letzte: vincentvega4
-
Fritz!DECT 302 regelt nicht mehr- Letzte: Jstessi
-
[Problem] FritzBox 7590 2,4GHz WLAN nur noch sehr sehr schwach- Letzte: Zwanzigeinundzwanzig
-
[Sammlung] Fritz!Box 5690Pro, Inhaus/Labor 7.90, Pfad 'Smart24P1FCS'- Letzte: QBiT|RAMOC
