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

Sidebar Sidebar
Upgrade 3CX to v18 and get it hosted free!
Danke

und was sieht so verkehrt aus für die Leidenden?
Wenn die FB einen USB-Stick @ext3 mounted -mit allen Rechten dort für modfs?- sollte doch modfs auf der FB als nativ Linux-Sytem auch damit zurechtkommen?
LG
 

Anhänge

  • Screen Shot 09-09-16 at 03.16 AM.JPG
    Screen Shot 09-09-16 at 03.16 AM.JPG
    38.8 KB · Aufrufe: 27
Genau deshalb gehört zu so einer Fehlermeldung auch immer die Angabe, unter welchem System man das am Ende macht.

Wenn das hier eine 113.06.69-40929 ist und AVM sollte tatsächlich (den Vorschlag habe ich vor einiger Zeit schon gemacht, aus anderen Gründen) das Mounten von USB-Sticks mit der "noexec"-Option umgesetzt haben, dann läßt sich (richtigerweise) nichts mehr von so einem Volume ausführen (in einer "normalen Box" ist das ja auch nicht notwendig).

Das schaue ich jetzt trotzdem nicht extra nach - bis zur 40767 ist das jedenfalls noch nicht umgesetzt:
Code: 
$ /etc/version -v -vsub
113.06.69
-40766
$ mount | grep ext3
/dev/sdb2 on /var/media/ftp/system type ext3 (rw,relatime,errors=continue,user_xattr,acl,barrier=1,data=writeback)
/dev/sdb3 on /var/media/ftp/data type ext3 (rw,relatime,errors=continue,user_xattr,acl,barrier=1,data=writeback)
Taucht bei der 40929 da ein "noexec" beim Mount auf (und ist das bei Dir überhaupt eine 40929, das ist ja auch nur geraten und das nicht aus Passion meinerseits), dann wäre das eine Erklärung - ansonsten muß man eben weiter nach der Ursache suchen (aber nicht ich).

Wollten wir uns nicht eigentlich wechselseitig ignorieren? Wenn ich hier in diesem Thread ein Abonnement habe und trotzdem jeden Beitrag (mit-)lese, ist das vermutlich zu erklären und viele werden es (hoffentlich) verstehen. Einen Dialog mit Dir möchte ich trotzdem nicht führen, auch nicht mehr in technischen Dingen.

Eine denkbare Erklärung habe ich geliefert, wenn das bereits "ext3" ist - war es keines (bei vielen "rookies" durchaus denkbar), steht da noch einmal explizit der Link inkl. Beschreibung der "genauen Fundstelle", was u.a. die Ursache für derartige Probleme sein kann ... genau deshalb endet der Satz dort auf "bis zu den Dateirechten der Skripte."

Daß ich auch dann reagiert habe, wenn ich demonstrativ nicht der "Adressat" der Frage in #800 bin (spätestens beim ersten Satz der Ergänzung bin ich das ja dann doch wieder und das illustriert dann auch (daher bedanke ich mich dafür ausdrücklich) das, was ich mit den kleinen, fiesen Tritten unter dem Tisch meinte und darauf bezog sich auch das "still leiden, wenn die Diskussion in diesem Thread jetzt weitergeht"), ist in diesem Thread selbstverständlich ... hier fühle ich mich zuständig für die Prävention der zusätzlichen Verwirrung mehrerer Leser, wenn sie von einigen Wenigen verursacht werden könnte - wenn der Verweis auf #1 auf Dich nicht zutraf (mangels verwertbarer Informationen ist das bisher nicht festzustellen), so erklärt er doch zumindest eine mögliche Fehlerursache, die exakt dieselben Symptome ergeben würde.

Mein Vorschlag für den "Rest" dessen, was Du wohl zum Ausdruck bringen wolltest mit dem ersten Satz Deiner Aktualisierung, wäre es, daß wir uns in der Laber-Ecke (nicht mit "Labor" zu verwechseln) einen Thread einrichten, in dem wir diese Diskussion fortführen und den wir dann einfach beide ignorieren. Das spart anderen viel Frust (manchem vielleicht auch das stille Grinsen, aber so jemand kann den neuen Thread ja dann abonnieren) und es hält diesen Thread hier vielleicht künftig von solchen Spitzen frei.

-Meine Vermutung war tatsächlich richtig (ob nun mein Vorschlag/Hinweis der Auslöser war, weiß ich natürlich nicht), die 40929 mountet mit "noexec":
Code: 
$ /etc/version -v -vsub;grep ext3 /proc/mounts
113.06.69
-40929
/dev/sda2 /var/media/ftp/system ext3 rw,[COLOR="#FF0000"]noexec[/COLOR],relatime,errors=continue,user_xattr,acl,barrier=1,data=writeback 0 0
/dev/sda3 /var/media/ftp/data ext3 rw,[COLOR="#FF0000"]noexec[/COLOR],relatime,errors=continue,user_xattr,acl,barrier=1,data=writeback 0 0
In #1 habe ich einen entsprechenden Hinweis ergänzt.
 
Zuletzt bearbeitet:
Problem "Permission denied when executing modfs"

PeterPawn schrieb:
AVM hat seit der Laborversion 113.06.69-40929 (bei der 7490, da ist es zuerst zu finden für mich) das Mounten von USB-Volumes abgeändert, dort wird jetzt mit der Option "noexec" gearbeitet. In der Folge sind von dort keine Programme mehr auszuführen - der interne NAND-Flash (auch kleinere Modelle haben den ja, wenn auch mit weniger Platz, aber für das Auspacken von "modfs" sollte es eigentlich immer reichen) steht aber immer noch zur Verfügung, ansonsten muß man entweder "/var" (tmpfs, volatil) dafür nehmen oder die Volumes anders mounten, bevor man "modfs" ausführen will.
Zum Vergrößern anklicken....

Micha0815 schrieb:
Wo könnte die Berechtigung fehlen zw. ./modfs -Ausführung
Zum Vergrößern anklicken....

Hallo,
ich habe mir das Problem "Permission denied when executing modfs" angesehen,

es ist in der Tat seit FW 113.06.69-40929 die Umstellung von Mount-Option "exec" auf "noexec" für die USB-Mass-Storage-Devices eingeführt worden.

Code: 
# ls -la 113.06.69-40766/rootfs_new/etc/hotplug/udev-mount-sd
-rwxrwxrwx    1 root     root         12952 Aug 18 14:15 113.06.69-40766/rootfs_new/etc/hotplug/udev-mount-sd
# ls -la 113.06.69-40929/rootfs_new/etc/hotplug/udev-mount-sd
-rwxrwxrwx    1 root     root         12983 Sep  1 17:31 113.06.69-40929/rootfs_new/etc/hotplug/udev-mount-sd
#



# /var/media/ftp/bin/diff 113.06.69-40766/rootfs_new/etc/hotplug/udev-mount-sd 113.06.69-40929/rootfs_new/etc/hotplug/udev-mount-sd
--- 113.06.69-40766/rootfs_new/etc/hotplug/udev-mount-sd
+++ 113.06.69-40929/rootfs_new/etc/hotplug/udev-mount-sd
@@ -150,20 +150,20 @@
 ;;
 squashfs)
 echo "MOUNT: mount -t 'squashfs' $DEVNODE $MNTPATH" >/dev/console
-if mount -t squashfs -o ro $DEVNODE "$MNTPATH"; then
+if mount -t squashfs -o ro,[COLOR=#0000ff]noexec[/COLOR] $DEVNODE "$MNTPATH"; then
 new_filesystem=true
 fi
 ;;
 vfat)
 echo "MOUNT: mount -t 'vfat' $DEVNODE $MNTPATH" >/dev/console
-if mount -t vfat -o $READMODE,noatime,shortname=winnt,uid=$FTPUID,gid=$FTPGID,utf8,$FMASK,$DMASK $DEVNODE "$MNTPATH"; then
+if mount -t vfat -o $READMODE,noatime,shortname=winnt,uid=$FTPUID,gid=$FTPGID,utf8,$FMASK,$DMASK,[COLOR=#0000ff]noexec[/COLOR] $DEVNODE "$MNTPATH"; then
 new_filesystem=true
 fi
 ;;
 ntfs)
 echo "MOUNT: mount -t 'ntfs' $DEVNODE $MNTPATH" >/dev/console
 if test -x /bin/ntfs-3g ; then
-ntfs-3g $DEVNODE "$MNTPATH" -o $READMODE,locale=de_DE.UTF-8,$FMASK,$DMASK,big_writes
+ntfs-3g $DEVNODE "$MNTPATH" -o $READMODE,locale=de_DE.UTF-8,$FMASK,$DMASK,big_writes,[COLOR=#0000ff]noexec[/COLOR]
 local NTFS_RET=$?
 case "$NTFS_RET" in
 0 )
@@ -194,7 +194,7 @@
 ;;
 ext2|ext3|ext4)
 echo "MOUNT:mount -t 'extX' $DEVNODE $MNTPATH" >/dev/console
-if mount -t $filesystem_type $DEVNODE "$MNTPATH"; then
+if mount -t $filesystem_type -o [COLOR=#0000ff]noexec[/COLOR] $DEVNODE "$MNTPATH"; then
 new_filesystem=true
 chmod 777 "$MNTPATH"
 fi
#

Um aus irgendwelchen Gründen den alten "unsicheren" Modus zu reaktivieren, müßte u.a. der Befehl "mount -o remount,exec" auf den Mountpoint angewendet werden:

Code: 
# df
Filesystem           1K-blocks      Used Available Use% Mounted on
/dev/root                49152     22440     26712  46% /wrapper
devtmpfs                119404        68    119336   0% /wrapper/dev
/dev/loop0               20032     20032         0 100% /
devtmpfs                119404        68    119336   0% /dev
tmpfs                   119548      1416    118132   1% /var
/dev/mtdblock4            2048       916      1132  45% /var/flash
/var/dev/nand           415744    340516     75228  82% /var/media/ftp
/dev/sda1            119402724  31188076  82149292  28% /var/media/ftp/USB-Stick-01
#

# mount
SNIP
/dev/sda1 on /var/media/ftp/USB-Stick-01 type ext3 (rw,[COLOR=#0000ff]noexec[/COLOR],relatime,errors=continue,user_xattr,acl,barrier=1,data=writeback)
#

# mount -o remount,[COLOR=#0000ff]exec[/COLOR] /var/media/ftp/USB-Stick-01
#

# mount
SNIP
/dev/sda1 on /var/media/ftp/USB-Stick-01 type ext3 (rw,relatime,errors=continue,user_xattr,acl,barrier=1,data=writeback)
#
ansonsten bleibt natürlich der sichere Installationsort für modfs "/var/media/ftp" oder die temporäre Ablageverzeichnis "/var"; siehe auch Betrag von PeterPawn #1

Gruß
Pokemon20021
 
Zuletzt bearbeitet:
Ich bedanke mich für die Erläuterung des Problems in #803 und #804. In der aktuellen 113.06.69-41049 wird ebenfalls so gemountet. Es ist anzunehmen, dass dies wohl auch in einer kommenden Release Einzug halten wird.
LG
 
modscript mod_preselect_username läuft bei FW 6.69-41137 in Error (1)

Hallo zusammen,
bei FW 06.69-41137 erscheint bei mir folgende Fehlermeldung:
Code: 
# ./modfs update FRITZ.Box_7490_Labor.113.06.69-41137.image
SNIP
Die Modifikation 'preselect username' wird verarbeitet ...
Überprüfen der unterstützten Sprachen ... OK
Soll die Modifikation 'preselect username' mit folgender Beschreibung
Benutzernamen aus der URL im der Login-Maske vorausw▒hlen
angewendet werden? (j/N) j
[COLOR=#ff0000]Überprüfen der Voraussetzungen für die Modifikation ... Fehler (1)
Die Modifikation wurde bereits angewendet oder ist nicht erforderlich.

Die Modifikation 'preselect username' wurde angewendet, Fehlercode = 1.[/COLOR]

Debug Output:
Code: 
# showshringbuf modfs
SNIP
2016-09-16 19:46:19.005 - progress: mode=3, msg= OK
2016-09-16 19:46:19.057 - progress: mode=1, msg=Modifikation wird ausgeführt ...
2016-09-16 19:46:19.144 - progress: mode=3, msg= OK
2016-09-16 19:46:19.196 - progress: mode=1, msg=Überprüfen des Erfolgs der Modifikation ...
2016-09-16 19:46:19.230 - is_supported: option=postcheck, from=precheck postcheck install language(en,de), rc=1
2016-09-16 19:46:19.298 - progress: mode=3, msg= OK
2016-09-16 19:46:19.351 - execute_modscript: exiting, rc=0
2016-09-16 19:46:19.370 - execute_optional_modscript: exiting, rc=0
2016-09-16 19:46:19.400 - execute_optional_modscript: script=/var/media/ftp/USB-Stick-01/download/modfs-0.3.5-020820162237/modscripts/mod_preselect_username, root=/var/media/ftp/USB-Stick-01/1474047911/squashfs-root, mode=
2016-09-16 19:46:19.505 - progress: mode=1, msg=Überprüfen der unterstützten Sprachen ...
2016-09-16 19:46:19.552 - is_supported: option=language, from=precheck postcheck install language(en,de), rc=1
2016-09-16 19:46:19.609 - progress: mode=3, msg= OK
2016-09-16 19:46:20.648 - get_temp_dir: directory=/var/tmp/3754_1474047980
2016-09-16 19:46:20.697 - remove_directory: directory=/var/tmp/3754_1474047980, rc=0
2016-09-16 19:46:20.716 - get_description: Benutzernamen aus der URL im der Login-Maske vorausw▒hlen
2016-09-16 19:46:20.848 - ask_yes_or_no: Q=Soll die Modifikation 'preselect username' mit folgender Beschreibung{LF}Benutzernamen aus der URL im der Login-Maske vorausw▒hlen{LF}angewendet werden?
2016-09-16 19:46:22.388 - ask_yes_or_no: A=j
2016-09-16 19:46:22.418 - execute_modscript: script=/var/media/ftp/USB-Stick-01/download/modfs-0.3.5-020820162237/modscripts/mod_preselect_username, root=/var/media/ftp/USB-Stick-01/1474047911/squashfs-root, mode=onrequest
2016-09-16 19:46:22.481 - is_supported: option=language, from=precheck postcheck install language(en,de), rc=1
2016-09-16 19:46:22.539 - progress: mode=1, msg=Überprüfen der Voraussetzungen für die Modifikation ...
2016-09-16 19:46:22.567 - is_supported: option=precheck, from=precheck postcheck install language(en,de), rc=1
2016-09-16 19:46:22.641 - progress: mode=3, msg= Fehler (1)
2016-09-16 19:46:22.694 - execute_modscript: exiting, rc=1
2016-09-16 19:46:22.713 - execute_optional_modscript: exiting, rc=0
2016-09-16 19:46:22.742 - execute_optional_modscript: script=/var/media/ftp/USB-Stick-01/download/modfs-0.3.5-020820162237/modscripts/mod_profile, root=/var/media/ftp/USB-Stick-01/1474047911/squashfs-root, mode=
2016-09-16 19:46:22.847 - progress: mode=1, msg=Überprüfen der unterstützten Sprachen ...
2016-09-16 19:46:22.893 - is_supported: option=language, from=precheck postcheck install language(en,de), rc=1
2016-09-16 19:46:22.951 - progress: mode=3, msg= OK
2016-09-16 19:46:23.991 - get_temp_dir: directory=/var/tmp/3754_1474047983
2016-09-16 19:46:24.040 - remove_directory: directory=/var/tmp/3754_1474047983, rc=0
2016-09-16 19:46:24.059 - get_description: Kommandos in /var/custom/etc/profile in /etc/profile einschließen
2016-09-16 19:46:24.193 - ask_yes_or_no: Q=Soll die Modifikation 'enable custom profile extension' mit folgender Beschreibung{LF}Kommandos in /var/custom/etc/profile in /etc/profile einschließen{LF}angewendet werden?
2016-09-16 19:46:29.024 - cleanup: running cleanup from file /var/tmp/3754_filelist_1474047903
#

ich denke da hat AVM ein LUA-Skript angepasst und das modscript läuft ins Leere.

Gruß
Pokemon20021

EDIT:
die gewünschten Anpassungen bei Loginmaske fehlen
modfs-bug-06.69-41137.png
 
Zuletzt bearbeitet:
Bei mir lief es fehlerfrei durch und macht was es soll?
 

Anhänge

  • Screen Shot 09-16-16 at 08.52 PM.JPG
    Screen Shot 09-16-16 at 08.52 PM.JPG
    23.4 KB · Aufrufe: 33
@Pokemon20021:
Das hatte ich bereits bei einer "Inhouse-Version" festgestellt, einfach den Patch weglassen.

Bei mir funktionierte zumindest die Entwicklerversion auch ohne den Patch dann problemlos, allerdings habe ich auch nur internes Login (also mit SELECT-Box) getestet, während das bei Dir eher nach externem Login (TEXT-Feld für den Benutzernamen) aussieht.

Jedoch habe ich die 41137 auch noch nicht angesehen, da kann das schon wieder anders sein als in der 41091.
 
Hallo zusammen,
bei FB7490 FW 6.69-41137 wird mir neuerdings angeboten mit E-Mail-Adresse anmelden:
Code: 
Bitte melden Sie sich mit Ihrem Benutzername [COLOR=#0000ff]oder Ihrer E-Mail-Adresse[/COLOR] und Ihrem Kennwort an.
http://www.ip-phone-forum.de/attachment.php?attachmentid=87553&d=1474049234

@Micha0815 #807:
Welche FW nutzt Du ?
Code: 
Bitte melden Sie sich mit Ihrem Benutzername und Ihrem Kennwort an.
http://www.ip-phone-forum.de/attachment.php?attachmentid=87554&d=1474052326
irgendwie sieht die Anmeldemaske bei Dir ganz anders aus, und auch die Aussage "Bei mir lief es fehlerfrei durch" kann ich nicht nachvollziehen.

Gruß
Pokemon20021

- - - Aktualisiert - - -

Mein Setup: FritzBox läuft im IP-Client-Modus
User-Setup: "Zugang auch aus dem Internet erlaubt"
FB7490-06.69-41137, IP-Client-Login-Problem.png
nach Entfernen des Häkchens, konnte ich mich an Box nicht mehr anmelden; Fehlermeldung "Anmeldung fehlgeschlagen"

Hat jemand eine Idee wie das ohne Recovery zu fixen ist.

Kann ich ein neues Web-IF Passwort per SSH-Dropbear Zugang setzen ?
 

Anhänge

  • FB7490-06.69-41137, IP-Client-Login-Problem.png
    FB7490-06.69-41137, IP-Client-Login-Problem.png
    3.5 KB · Aufrufe: 138
Zuletzt bearbeitet:
Der Text der Anmeldung ist bei extern schon früher so, wie im Screenshot zu sehen.

Bei interner Anmeldung fehlt halt der Zusatz mit der E-Mail-Adresse, obwohl es natürlich ebenfalls funktionieren würde, wenn beim Benutzer eine E-Mail-Adresse eingetragen ist in der Benutzerverwaltung. Da aber dort die Liste der Benutzer als SELECT-Box bereits vorgegeben ist, macht der Zusatz mit der E-Mail-Adresse ja wenig Sinn ... man kann ja nur wählen und nichts eingeben.

Warum die Box bei aktiviertem IP-Client-Modus überhaupt auf die Idee kommt, die Anmeldung erfolgt von extern, wäre die entscheidende Frage.

Ansonsten würde ich einfach aus dem zweiten System heraus noch einmal die Anmeldung probieren, vielleicht arbeitet das bei der intern/extern-Erkennung besser. Wenn nicht, kann man immer noch über ctlmgr_ctl oder das Editieren der Benutzerrechte in der ar7.cfg das Chaos wieder entwirren.
 
PeterPawn schrieb:
Wenn nicht, kann man immer noch über ctlmgr_ctl oder das Editieren der Benutzerrechte in der ar7.cfg das Chaos wieder entwirren.
Zum Vergrößern anklicken....

Nach "Fallback" auf 06.60 (hier hatte ich supportdata Datei) und Anpassung der ar7.cfg
Code: 
# nvi /var/flash/ar7.cfg
SNIP
boxusers {
         users {
                 enabled = yes;
                 id = 13;
                 name = "SECRET";
                 email = "";
                 password = "SECRET";
                 vpn_access = yes;
-                box_admin_rights = secobj_access_rights_readwrite_from_homenetwork_only;
-                nas_rights = secobj_access_rights_readwrite_from_homenetwork_only;
-                phone_rights = secobj_access_rights_readwrite_from_homenetwork_only;
-                homeauto_rights = secobj_access_rights_readwrite_from_homenetwork_only;
+                box_admin_rights = secobj_access_rights_readwrite_from_[COLOR=#0000ff]everywhere[/COLOR];
+                nas_rights = secobj_access_rights_readwrite_from_[COLOR=#0000ff]everywhere[/COLOR];
+                phone_rights = secobj_access_rights_readwrite_from_[COLOR=#0000ff]everywhere[/COLOR];
+                homeauto_rights = secobj_access_rights_readwrite_from_[COLOR=#0000ff]everywhere[/COLOR];
         }
hat das Einloggen per Web-IF bei 06.60 wieder funktioniert

Für mich sieht es nach Bug aus, da eine Änderung per GUI die Fritzbox nicht in einen "unmanagbaren" Zustand bringen sollte.

EDIT: nach anschließendem Update von 06.60 auf 6.69-41137 war alles OK;
FB07490-6.69-41137, IP-Client OK.png

unklar, warum die Auswahlliste bei Anmeldemaske bei FW 6.69-41137 nicht gleich richtig angezeigt wurde.
 
Zuletzt bearbeitet:
Pokemon20021 schrieb:
...

EDIT: nach anschließendem Update von 06.60 auf 6.69-41137 war alles OK;
Anhang anzeigen 87561

unklar, warum die Auswahlliste bei Anmeldemaske bei FW 6.69-41137 nicht gleich richtig angezeigt wurde.
Zum Vergrößern anklicken....

Genau so gehe ich zumeist vor. Von der gestarteten 6.60 aus, offline die jeweilige Labor via ./modfs update auf die inaktive Partition zu bringen.
Nur als Antwort auf Deine Frage in #809. Und ja hier läuft sie ebenfalls als Client (WLAN-Repeater-Modus).
Es sind 3 User eingerichtet inkl. ftpuser.
LG

Nachtrag: Ich muss mich korrigieren wie ich gerade in der noch offenen bash sehe.
Code: 
...
Die Modifikation 'preselect username' wird verarbeitet ...
Überprüfen der unterstützten Sprachen ... OK
Soll die Modifikation 'preselect username' mit folgender Beschreibung
Benutzernamen aus der URL im der Login-Maske vorausw�hlen
angewendet werden? (j/N) j
Überprüfen der Voraussetzungen für die Modifikation ... Fehler (1)
Die Modifikation wurde bereits angewendet oder ist nicht erforderlich.

Die Modifikation 'preselect username' wurde angewendet, Fehlercode = 1.
...

Nur konnte ich keine Auswirkung erkennen.
 
Zuletzt bearbeitet:
Ich habe probiert, modfs auf einer 7362sl durchgeführt:

ext3-Dateisystem für loop-Mount wird entpackt ... OK
ext3-Dateisystem über loopback-Device einbinden ... OK
Entpacken des root-Dateisystems für die Modifikationen ... -
(fritzbox reboot)
Zum Vergrößern anklicken....

Wie und was muss ich machen (unter Windows), damit ein USB Stick den Speicher der Fritzbox 7362sl erweitert?
 
USB-Stick neu partitionieren und formatieren ... eine Partition (1-2 GB) als "linux swap" (Typ 82) und eine als Linux-FS (Typ 83), welche dann als "ext3" formatiert wird. Auf der Swap-Partition dann am besten noch ein "mkswap" und dann sollte diese Partition auch beim Anstecken des Sticks als Swap-Device erkannt und verwendet werden. Das Vorhandensein eines "nativen" Filesystems für Linux macht dann den Versuch der Verwendung eines Loopback-Devices für das Entpacken auch überflüssig. Es wird halt ein Dateisystem benötigt, was die Linux-Dateirechte "konserviert" beim Entpacken und bei der 7490 kann man dafür notfalls die yaffs2-Partition verwenden - bei der 7362SL ist die deutlich zu klein.

Das würde ich trotzdem nicht unter Windows machen (da muß man sich die Programme zum Partitionieren/Formatieren ggf. erst zusammensuchen), sondern auf der Box selbst ... die notwendigen Programme dafür (fdisk, mkfs.ext3) sollten im "modfs"-Archiv vorhanden sein.
 
Eisbär, ich würde Dir gerne eine Nachricht senden, aber dein Postfach ist voll.
Kannst Du mir deinerseits eine Nachricht schicken, wenn Du wieder empfangsbereit bist?
Danke!

- - - Aktualisiert - - -

Scheinbar ist Eisbär schon länger offline. Gibt es jemand der sich stellvertretend um die modfs Gebrauchsanleitung kümmert?
http://www.ip-phone-forum.de/showthread.php?t=284778

- - - Aktualisiert - - -

Eine Frage zu den Voraussetzungen von modfs:
"Es muß in beiden Partitionen eine FW sein, d.h. es muß mindestens einmal ein Update gemacht worden sein"
Gesetzt den Fall, ich muss die FW mittels Recovery erst downgraden damit ich telnet Zugang erhalte, wie ist dann die Sachlage?
Werden bei einem Recovery beide Partitionen beschrieben, sodaß diese Voraussetzung erfüllt ist?
Wenn nicht, wie kommt man da raus/weiter?
 
Zuletzt bearbeitet:
Beim starten von modfs werden die partitionen verglichen. Falls Unterschiede festgestellt werden wird angeboten die aktive Partition zu kopieren
 
Jein ... den Fall, daß "linux_fs_start" noch gar nicht vorhanden ist (bei einer werksneuen Box, die niemals ein Update erhalten hat), behandele ich (immer noch) nicht richtig - das war zum Zeitpunkt des "Erscheinens" noch etwas unklar und ich wollte nicht, daß das Skript irgendetwas automatisch annimmt, was am Ende nicht stimmt.
EDIT: Gestrichen ... siehe unten.

Bei Recovery wird in die gerade aktive Partition geschrieben, das hilft also bei einer "frischen Box" auch nicht. Aber was in jedem Falle hilft, ist das Kommando
Code: 
grep -q "linux_fs_start" /proc/sys/urlader/environment || echo "linux_fs_start 0" >/proc/sys/urlader/environment
, das setzt dann bei fehlendem "linux_fs_start" im Environment das äquivalente "linux_fs_start 0".

- - - Aktualisiert - - -

Ich habe mal eine geänderte Version eingecheckt, die mit fehlendem "linux_fs_start" umgehen kann und auch nach dem Kopieren des laufenden Systems in die alternativen Partitionen (das erfolgt ja ohnehin nur beim Aufruf ohne "update") keinen Reboot mehr hinlegt (das war mit ständig aktiviertem Debug ja ohnehin schon Geschichte und mußte manuell gemacht werden oder es konnte eben auch einfach weggelassen werden) und auch keinen Neustart von "modfs" mehr erfordert. Jetzt wird nach dem Kopieren des Kernels und des Wrapper-Dateisystems einfach weitergemacht ... das enthaltete "filesystem_root.squashfs" wird später ohnehin ausgetauscht.

- - - Aktualisiert - - -

Weitere Änderungen an der Version im GitHub:

Bei "update" wird jetzt das angegebene Image bei Aufruf mit Dateinamen bzw. das vom FTP-Server geladene Image beim Aufruf ohne Dateinamen auf eine gültige Signatur geprüft. Da hierfür die Keys auf der verwendeten FRITZ!Box benutzt werden, funktioniert das nicht für das Erstellen eines "fremden" Images (zumindest nicht für ein anderes Modell, das Erstellen eines Images für eine zweite Box desselben Modells funktioniert natürlich auch mit den vorhandenen Keys) - daher ist für den Aufruf dann die zusätzliche Angabe der Variablen "NOVERIFY=1" am Beginn der Kommandozeile erforderlich.

Das nur zwischenzeitlich bei der 7490 erforderliche Skript "mod_preselect_username" wurde wieder gestrichen, offenbar hat AVM das Problem in den neuen Labor-Versionen behoben und ältere Release-Versionen waren ohnehin nicht betroffen.
 
PeterPawn schrieb:
Ich habe mal eine geänderte Version eingecheckt
Zum Vergrößern anklicken....
Hallo PeterPawn,
vielen Dank!!!

wenn möglich Bitte auch die Version
Code: 
modfs_version=0.3.5-020820162237
auf aktuelles Datum 21092016xxxx anheben

Gruß
Pokemon20021
 
Ist eigentlich vorhin schon passiert, dort sollte jetzt 210920162017 aktuell stehen.
 
Seltsam

Code: 
 ./modfs update ./41137.image

scheitert ausgeführt auf einer FB7490.

Code: 
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.69-40929

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/modd/41137.image' wird als Quelle f  r die Aktualisierung genutzt.
  berpr  fen der Signatur der geladenen Datei ... Fehler
#



Code: 
 NOVERIFY=1 ./modfs update ./41137.image

Funktioniert ;)

Seltsam nur, das ein orginal vom AVM-FTP besorgtes .image eine falsche Signatur innehaben soll?

LG und nur zur info für die lesende "Anfängerschaft", da ich dem TE ja aus dem Weg gehen soll.
 
Bei mir funktioniert das genau mit dieser Datei problemlos:
Code: 
$ ./modfs update ../system/FB7490/firmware/FRITZ.Box_7490_Labor.113.06.69-41137.image
Using debug mode with a 64 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.69-41137

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/system/FB7490/firmware/FRITZ.Box_7490_Labor.113.06.69-41137.image' wird als Quelle für die Aktualisierung genutzt.
[B][COLOR="#008000"]Überprüfen der Signatur der geladenen Datei ... OK[/COLOR][/B]
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 ... OK
[...]
Wenn Fehlermeldung "über Bande", dann bitteschön auch mit der erstellten Debug-Datei ... dafür habe ich das schließlich eingebaut.

Woran das am Ende liegen mag (das Laden und Auspacken des kompletten neuen tgz-Files versteht sich von selbst, sonst fehlen automatisch notwendige Komponenten), ist durch bloßes Anstarren der Konsolenausgaben nicht zu entdecken ... anders als bei funktionierendem Ablauf (da ist das nur die "Bestätigung") braucht es das Protokoll im Fehlerfall.

Einen weiteren Fingerzeig kann der direkte Aufruf von "check_signed_image image -b" (das Skript steht im Verzeichnis mit den ausführbaren Dateien) liefern, der gibt dann auch auf STDERR/STDOUT konkretere Hinweise auf die mögliche Fehlerursache.

Sollten aus irgendeinem Grund die Dateien nicht richtig gefunden werden, muß eben das Unterverzeichnis "bin" mit der korrekten Hardware-Revision (oder gleich "VR9", denn in der veröffentlichten Version sind ja ohnehin nur die VR9-Modelle unterstützt) zusätzlich in den Linux-Suchpfad aufgenommen werden. Das würde ich ohnehin als Eingangsvoraussetzung erwarten ... ich werde ich wohl trotzdem (als Service/Kulanz meinerseits und ohne Anerkennung einer Rechtspflicht) noch eine Änderung vornehmen und den Pfad für den Aufruf von "check_image_signature" entsprechend erweitern.
- - - Aktualisiert - - -

So, ich habe "modfs" noch einmal geändert (auch ohne genaue Kenntnis, ob das nun tatsächlich die Ursache war) und den Suchpfad für den Aufruf von "check_image_signature" um das Binaries-Verzeichnis für die aktuelle Box ergänzt.

Die eigentliche Arbeit bei der Signaturprüfung übernimmt ja dasselbe Skript, was ich im "YourFritz"-Repository unter "signimages" verwalte und das auch Eingang in die Freetz-Toolchain gefunden hat.

Dort sind die notwendigen Programme auch über den Suchpfad zu erreichen ... vermutlich wird nicht jeder die notwendigen Komponenten für die Signaturprüfung bereits an anderer Stelle auf der eigenen FRITZ!Box haben, wo sie dann auch direkt aufgerufen werden können.

Da ich wegen der Verwendung an mehreren Stellen das "check_signed_image" nicht an die verwendete Aufruf-Methode in "modfs" (alle BusyBox-Applets über direkten Aufruf des beigelegten Binaries starten anstatt sich auf den Suchpfad zu verlassen und - in der Vergangenheit oft erlebt - am Ende die falschen Programme aus einem laufenden AVM-Image zu erwischen) anpassen konnte/wollte, blieb nur dieser Weg ... wenn jetzt immer noch Probleme auftauchen, dann braucht es aber wirklich den passenden Return-Code - nicht umsonst wird für jedes Problem ein gesonderter Code verwendet (und dann auch im Debug-Log protokolliert) und nicht nur einfach "Fehler" signalisiert.

Der nächste Punkt, der geändert wird (bzw. bei mir schon geändert ist), ist dann das Suchen nach einer neuen Version (mit juischeckupdate) aus "modfs" heraus, bisher wird dazu ja noch der FTP-Server "befragt" und dafür braucht es auch noch die HTML-Variante von AVM. Bevor die demnächst vielleicht auch noch eingestampft wird (schon jetzt ist es m.W. nur einer von den drei Servern, der das überhaupt noch unterstützt), stelle ich die Suche nach einer neueren Version lieber auf den AVM-Updatecheck um - dann findet der auch gleich noch die Labor-Versionen, was bisher ja auch nicht funktionierte. Das braucht dann allerdings mit "xmllint" und "bash" gleich noch die nächsten binären Dateien ... schmeckt mir nicht so richtig, aber der Dammbruch ist wohl ohnehin schon erfolgt.
 
Zuletzt bearbeitet:
Um antworten zu können musst du eingeloggt sein.

Zurzeit aktive Besucher

Gesamt: 621 (Mitglieder: 8, Gäste: 613)

Neueste Beiträge

Statistik des Forums

Themen
246,158
Beiträge
2,247,073
Mitglieder
373,677
Neuestes Mitglied
MK34
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.
Ihr E-Mail-Adresse verifizieren

Ihr E-Mail-Adresse verifizieren

Wir haben Ihnen eine E-Mail geschickt. Klicken Sie auf die Schaltfläche im E-Mail-Text, um Ihre E-Mail-Adresse zu verifizieren – (Können Sie diese nicht finden können, dann überprüfen Sie Ihren Spam-Ordner).

IPPF im Überblick

Neueste Beiträge

Direktlinks Telefonanlage

Website-Sponsoren

3CX sponsor
KONTAKTIEREN SIE UNS BEI INTERESSE
| Style by ThemeHouse
XenPorta 2 PRO © Jason Axelrod of 8WAYRUN
Oben Unten
Zurück