Micha0815
IPPF-Promi
- Mitglied seit
- 25 Feb 2008
- Beiträge
- 5,280
- Punkte für Reaktionen
- 456
- Punkte
- 83
[Info] modfs - SquashFS-Image (AVM-Firmware) ändern für NAND-basierte FRITZ!Boxen
- Ersteller PeterPawn
- Erstellt am
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,159
- Punkte für Reaktionen
- 1,708
- Punkte
- 113
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:
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":
In #1 habe ich einen entsprechenden Hinweis ergänzt.
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)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
Zuletzt bearbeitet:
Problem "Permission denied when executing modfs"
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.
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:
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
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)
#Gruß
Pokemon20021
Zuletzt bearbeitet:
Micha0815
IPPF-Promi
- Mitglied seit
- 25 Feb 2008
- Beiträge
- 5,280
- Punkte für Reaktionen
- 456
- Punkte
- 83
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
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:
Debug Output:
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
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
Zuletzt bearbeitet:
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,159
- Punkte für Reaktionen
- 1,708
- Punkte
- 113
@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.
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:
http://www.ip-phone-forum.de/attachment.php?attachmentid=87553&d=1474049234
@Micha0815 #807:
Welche FW nutzt Du ?
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"
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 ?
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.@Micha0815 #807:
Welche FW nutzt Du ?
Code:
Bitte melden Sie sich mit Ihrem Benutzername und Ihrem Kennwort an.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"
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
Zuletzt bearbeitet:
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,159
- Punkte für Reaktionen
- 1,708
- Punkte
- 113
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.
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.
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];
}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;
unklar, warum die Auswahlliste bei Anmeldemaske bei FW 6.69-41137 nicht gleich richtig angezeigt wurde.
Zuletzt bearbeitet:
Micha0815
IPPF-Promi
- Mitglied seit
- 25 Feb 2008
- Beiträge
- 5,280
- Punkte für Reaktionen
- 456
- Punkte
- 83
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:
CyberKing2k
Aktives Mitglied
- Mitglied seit
- 5 Jun 2004
- Beiträge
- 1,037
- Punkte für Reaktionen
- 0
- Punkte
- 36
Ich habe probiert, modfs auf einer 7362sl durchgeführt:
Wie und was muss ich machen (unter Windows), damit ein USB Stick den Speicher der Fritzbox 7362sl erweitert?
Wie und was muss ich machen (unter Windows), damit ein USB Stick den Speicher der Fritzbox 7362sl erweitert?
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,159
- Punkte für Reaktionen
- 1,708
- Punkte
- 113
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.
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.
Fireball3
Mitglied
- Mitglied seit
- 22 Dez 2005
- Beiträge
- 286
- Punkte für Reaktionen
- 0
- Punkte
- 16
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?
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
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,159
- Punkte für Reaktionen
- 1,708
- Punkte
- 113
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- - - 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.
Hallo PeterPawn,
vielen Dank!!!
wenn möglich Bitte auch die Version
Code:
modfs_version=0.3.5-020820162237Gruß
Pokemon20021
Micha0815
IPPF-Promi
- Mitglied seit
- 25 Feb 2008
- Beiträge
- 5,280
- Punkte für Reaktionen
- 456
- Punkte
- 83
Seltsam
scheitert ausgeführt auf einer FB7490.
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.
Code:
./modfs update ./41137.imagescheitert 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.imageFunktioniert
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.
- Mitglied seit
- 10 Mai 2006
- Beiträge
- 15,159
- Punkte für Reaktionen
- 1,708
- Punkte
- 113
Bei mir funktioniert das genau mit dieser Datei problemlos:
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 werdeich 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.
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
[...]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
- - - 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:
Neueste Beiträge
-
Wlan Mesh Problem
- Letzte: tango501
-
[Sammlung] FRITZ!Box 4050, 5690 Pro und 7690- Letzte: Jstessi
-
Anregung vor Neukauf einer alten Telefonieinstallation
- Letzte: sunnyman