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

[tacitus-nrw]

Wie groß sollte die Swap Partition mindestens sein?

 

[PeterPawn]

512 MB sollten reichen, ich selbst habe immer eine 2 GB-Swap-Partition auf den USB-Geräten an den Boxen.

Der neue Wrapper wird auf 512 MB Swap-Space gesamt testen ... ob ich auch das Anlegen eines Swap-Files und das Deaktivieren dieses Files nach dem Einpacken dazupacken werde, weiß ich noch nicht genau.

 

[handersson1952]

Ist es mit dem modfs möglich z.B. das DECT-Modul aus der Firmwareversion 06.93 zu nehmen und das der 7.01 damit zu ersetzen (bei letzterer gibt es Probleme beim Betrieb mit Gigaset/RTX Repeatern und ich weiß nicht, ob das für die 7490 noch gefixt wird)?
Die Module an sich will ich nicht ändern.

 

[Mr.I]

Bitte die Protokoll-Datei (mit "showshringbuf modfs" am Terminal angezeigt, am besten umleiten in eine Datei

Ich habe einen neuen Versuch gestartet, diesmal mit EXT3-formatiertem USB-Stick auf dem ich ein Swapfile angelegt habe.

Leider kurz vor dem Ende Abbruch mit identischer Fehlermeldung wie gestern. Logfile anbei...

"Zum Spaß" habe ich das Update mit der "normalen" modfs-Version gestartet, diese ist bis zum Ende durchgelaufen, nach reboot startet die Box dann mit 7.01 und einigen funktionierenden Modifikationen (bspw. Auswahl des zu startenden Betriebssystems) aber natürlich ohne funktionierenden telnet-Zugang. Daraus würde ich schließen, das zwischen der beta und der bisherigen modfs-Version eine Veränderung stattgefunden hat, die (zumindest auf meiner Box) den Fehler erzeugt...

 

[PeterPawn]

Jetzt bin ich einigermaßen verblüfft, weil ich an dieser Stelle gar nichts bewußt geändert habe und auch beim "diff" zwischen dem neuen und dem alten Stand, sehe ich jetzt nichts, was das (vordergründig) auslösen sollte.

diff --git a/modfs b/modfs
index 0207e3e..ee7d785 100755
--- a/modfs
+++ b/modfs
@@ -159,7 +159,7 @@ nativefilesystems="tmpfs ext2 ext3 ext4 yaffs2"
 #
 # our "internal" constants
 #
-modfs_version=0.4.6-280220180003
+modfs_version=0.5.0-beta-170920181616
 modfs_comment="please look at https://github.com/PeterPawn/modfs for further info"
 bindirname="bin"
 localedirname="locale"
@@ -1972,7 +1972,7 @@ check_firmware_image()
     else
         progress 3 96
         # ok, let's get the filesystem image from it
-       working_directory="$(get_working_directory $extract_space_needed "tmpfs nand storage")"
+       working_directory="$(get_working_directory $extract_space_needed "tmpfs $nand storage")"
         rc=$?
         if [ $rc -ne 0 ]; then
             echo -e "$(get_localized $lang $rc)" 1>&2
@@ -2008,7 +2008,7 @@ check_squashfs_file_version()
     local squashfsimage="$1" rc=0 working_directory checkdir imageversion sq_version
     debug "check_squashfs_file_version: src=$squashfsimage"
     # check squashfs version
-   working_directory="$(get_working_directory 1M "tmpfs nand storage")"
+   working_directory="$(get_working_directory 1M "tmpfs $nand storage")"
     rc=$?
     if [ $rc -ne 0 ]; then
         echo -e "$(get_localized $lang $rc)" 1>&2
@@ -2379,7 +2379,8 @@ check_prerequisites()
                                             fi
                                             # find enough free local space to unpack the squashfs image
                                             progress 1 119
-                                           path=$(find_free_storage_space $free_space_for_unpack 2>/dev/null)
+                                           [ $INCLUDE_NAND -eq 1 ] && local_nand="withnand" || local_nand="nonand"
+                                           path=$(find_free_storage_space $free_space_for_unpack $local_nand 2>/dev/null)
                                             rc=$?
                                             if [ $rc -eq 0 ]; then
                                                 progress 3 96
@@ -2701,6 +2702,12 @@ if [ x"$MODFS_DEBUG" != x"0" ]; then
     MODFS_DEBUG=1
 fi
 #
+# include / exclude NAS NAND flash as working directory
+#
+INCLUDE_NAND=${INCLUDE_NAND:-0}
+! ( [ "$INCLUDE_NAND" = "0" ] && [ "$INCLUDE_NAND" = "1" ] ) && INCLUDE_NAND=0
+[ $INCLUDE_NAND -eq 0 ] && nand="nonand" || nand="nand"
+#
 # FRITZ!Box language environment setting
 #
 lang=$Language
@@ -2887,7 +2894,7 @@ case $source in
         debug "modfs: running system selected"
         ;;
     download)
-       working_directory="$(get_working_directory $download_space_needed "tmpfs nand storage")"
+       working_directory="$(get_working_directory $download_space_needed "tmpfs $nand storage")"
         rc=$?
         if [ $rc -ne 0 ]; then
             echo -e "$(get_localized $lang $rc)" 1>&2
@@ -2927,7 +2934,7 @@ case $source in
                         exit $rc
                     fi
                 fi
-               working_directory="$(get_working_directory $extract_space_needed "tmpfs nand storage")"
+               working_directory="$(get_working_directory $extract_space_needed "tmpfs $nand storage")"
                 rc=$?
                 if [ $rc -ne 0 ]; then
                     echo -e "$(get_localized $lang $rc)" 1>&2
@@ -3000,7 +3007,7 @@ case $source in
         rc=$?
         if [ $rc -eq 0 ]; then
             eval "$download_version"
-           working_directory="$(get_working_directory $download_space_needed "tmpfs nand storage")"
+           working_directory="$(get_working_directory $download_space_needed "tmpfs $nand storage")"
             rc=$?
             if [ $rc -ne 0 ]; then
                 debug "modfs: unable to get working directory"
@@ -3036,7 +3043,7 @@ case $source in
                         exit $rc
                     fi
                 fi
-               working_directory="$(get_working_directory $fullimage_space_needed "tmpfs nand storage")"
+               working_directory="$(get_working_directory $fullimage_space_needed "tmpfs $nand storage")"
                 rc=$?
                 if [ $rc -ne 0 ]; then
                     echo -e "$(get_localized $lang $rc)" 1>&2
@@ -3111,7 +3118,7 @@ case $source in
             fi
         fi
         if [ $rc -eq 0 ]; then
-           working_directory="$(get_working_directory $fullimage_space_needed "tmpfs nand storage")"
+           working_directory="$(get_working_directory $fullimage_space_needed "tmpfs $nand storage")"
             rc=$?
             if [ $rc -ne 0 ]; then
                 echo -e "$(get_localized $lang $rc)" 1>&2
@@ -3191,7 +3198,7 @@ if [ $rc -eq 0 ]; then
             rc=$?
             if [ $rc -ne 0 ]; then
                 # not enough space on tmpfs, try non-volatile storage now
-               unpack_directory="$(get_working_directory $free_space_for_unpack "nand storage")"
+               unpack_directory="$(get_working_directory $free_space_for_unpack "$nand storage")"
                 rc=$?
                 if [ $rc -ne 0 ]; then
                     echo -e "$(get_localized $lang $rc)" 1>&2

Da muß ich also mal etwas genauer hinsehen ... das hier ist der Knackpunkt:

2018-09-18 19:03:06.516 - mount_ext2_image: src=/var/media/ftp/EXT3/1537289577/filesystem.image, mp=/var/tmp/5878_1537290186/wrapperfs, type=sqfs_dummy256_ext2
2018-09-18 19:03:06.724 - mount_ext2_image: exiting, rc=255

und die Preisfrage ist es nun, was da ein zweites Mounten (das erste hat geklappt und auch das "umount" dort sollte erfolgt sein) dahingehend verhindert, daß da irgendeines der aufgerufenen Kommandos einen Return-Code von -1 ausgibt.

Irgendwelche Inkompatibilitäten in der (erneuerten) BusyBox können es (zumindest auf den ersten Blick) auch nicht sein, denn es gibt ja davor schon einen solchen Aufruf, der auch problemlos funktioniert:

2018-09-18 18:53:08.865 - mount_ext2_image: src=/var/media/ftp/EXT3/1537289577/filesystem.image, mp=/var/tmp/5878_1537289588, type=sqfs_dummy256_ext2
2018-09-18 18:53:09.186 - mount_ext2_image: exiting, rc=0

und zwar für exakt dieselbe Datei.

Ich suche zwar nachher selbst ... hier wäre ich trotzdem an der Ausgabe von "mount" und "losetup -a" in der Pause vorm Einpacken interessiert. Die These wäre, daß aus irgendeinem komischen Grund das Entladen des Images nach dem ersten Mounten nicht stattfindet - wobei mir auch die Phantasie fehlt, was da wohl genau passiert.

Ich habe mal eine neue Version mit etwas erweitertem Debug-Protokoll rund um das "mount_ext2_image()" hochgeladen ... wenn Du möchtest, kannst Du gerne testen - es würde sicherlich helfen.

Wobei auch problemlos die BusyBox mal wieder eine Macke haben kann ... irgendwo stimmt bei einem intern aufgerufenen Applet mal wieder etwas nicht, wie der folgende Test zeigt:

root@FB7490:/var/media/ftp/YourFritz/modfs $ IFS=: set -- $PATH; for p in $*; do echo -n "$p ... "; find $p -name decoder; echo; done
/var/media/ftp/root/bin ...
/var/media/ftp/root ...
/var/custom/bin ... /var/custom/bin/decoder

/bin ...
/var/custom/usr/bin ...
/usr/bin ...
/var/custom/sbin ...
/sbin ...
/var/custom/usr/sbin ...
/usr/sbin ...
root@FB7490:/var/media/ftp/YourFritz/modfs $ IFS=: set -- $PATH; for p in $*; do echo -n "$p ... "; find $p -name head; echo; done
/var/media/ftp/root/bin ...
/var/media/ftp/root ...
/var/custom/bin ...
/bin ...
/var/custom/usr/bin ...
/usr/bin ...
/var/custom/sbin ...
/sbin ...
/var/custom/usr/sbin ...
/usr/sbin ...
root@FB7490:/var/media/ftp/YourFritz/modfs $ head -n 1 /var/tmp/webdav.log
Sep 18 14:52:38 webdavclt[3249]: arg = online
Bus error
root@FB7490:/var/media/ftp/YourFritz/modfs $ busybox head -n 1 /var/tmp/webdav.log
Sep 18 14:52:38 webdavclt[3249]: arg = online
root@FB7490:/var/media/ftp/YourFritz/modfs $

Der erste Aufruf soll nur zeigen, daß Symlinks bzw. Dateien gefunden werden von dem Konstrukt, der zweite zeigt, daß es keinen Symlink für "head" gibt und deshalb der dritte Aufruf durch die "interne Abkürzung" der BusyBox zu den Applets erfolgt und der vierte zeigt dann, wie es bei anderem Aufruf auch ohne "Bus error" ausgehen kann.

 

[Mr.I]

hier wäre ich trotzdem an der Ausgabe von "mount" und "losetup -a" in der Pause vorm Einpacken interessiert. Die These wäre, daß aus irgendeinem komischen Grund das Entladen des Images nach dem ersten Mounten nicht stattfindet - wobei mir auch die Phantasie fehlt, was da wohl genau passiert.

Ich habe mal eine neue Version mit etwas erweitertem Debug-Protokoll rund um das "mount_ext2_image()" hochgeladen ... wenn Du möchtest, kannst Du gerne testen - es würde sicherlich helfen.

Meinst Du die Pause innerhalb des Skripts? Dann stehe ich jetzt möglicherweise auf dem Schlauch, denn ich müsste das Skript ja abbrechen um dann die von Dir genannten Ausgaben abfragen zu können.

Ferner hast Du eine neue Version der 0.5.0-beta hochgeladen oder wie ist das zu verstehen?

Du siehst, ich benötige konkretere Handlungsanweisungen...

Teste morgen Abend dann gerne weiter...

 

[PeterPawn]

Ich denke mal, ich habe die Ursache gefunden.

Es ist dieser Patch für die BusyBox: https://git.busybox.net/busybox/com...e&id=a98db793cffb77a8794c854443b8fe12bad98c0a

Damit wird das bisherige Verhalten, daß ein Loop-Device beim "umount" auch wieder gelöscht wird, wieder aufgehoben ... man muß jetzt also explizit "-d" angeben beim "umount".

Glücklicherweise muß ich da - dank eigener BusyBox für "modfs" - auf nichts weiter Rücksicht nehmen und kann den Switch einfach immer mit angeben.

Ansonsten checke ich immer Änderungen in das GitHub-Repo ein und passe dann ggf. auch die Timestamp für die Version an. Wenn ich daraus dann noch ein neues Archiv auf yourfritz.de mache, dann sieht man das am Zeitstempel in der "modfs"-Datei - ich hatte ja angekündigt, daß ich nicht jedes neue Beta-Archiv hier als "Neuigkeit" unter die Leute bringen will.

Jetzt hat mir jedenfalls erst mal das Aktualisieren der Binärdateien für "modfs" dazwischengefunkt, denn bei der vorher verwendeten 1.24.2 war das Verhalten noch anders.

Die Änderung steht dann mit dem Einchecken ins Repo auch als neues Archiv auf yourfritz.de bereit - die Reihenfolge ist da i.d.R. (sofern es auch ein neues Archiv gibt): Timestamp ändern, modfs einchecken, Archiv erstellen, Archiv kopieren, dann "git push" - wer sich also von GitHub über Änderungen benachrichtigen läßt, der sollte nach einem Anpassen des Zeitstempels im "modfs" (wie gesagt, nur dann gibt es auch ein neues Archiv) auch schon das korrekte Archiv unter dem Namen "modfs-0.5.0.tgz" auf dem Server finden.

 

[Micha0815]

Wo liegt mein Denkfehler/Tippfehler bei der Installation einer neuen Version?

mkdir -p /var/media/ftp/mod-alpha;cd /var/media/ftp/mod-alpha;wget -qO- http://yourfritz.de/modfs-0.5.0.tgz | gunzip -c | tar x

Ich erhalte nur eine README.md und ein modfs-Verzeichnis mit einem Header installiert.
LG

 

[PeterPawn]

Wenn ich die Datei abrufe (5,4 MB vom 18.09.2018 22:32 Uhr), kriege ich auch etwas anderes:

vidar:~ $ wget -qO- http://yourfritz.de/modfs-0.5.0-beta.tgz | tar tvz
drwxrwxr-x peh/gitusers      0 2018-09-17 01:06 bin/
lrwxrwxrwx peh/gitusers      0 2017-12-17 03:13 bin/156 -> Vx180
lrwxrwxrwx peh/gitusers      0 2017-12-17 03:13 bin/213 -> P6ATOM
lrwxrwxrwx peh/gitusers      0 2017-12-17 03:13 bin/220 -> P6ATOM
drwxr-xr-x peh/gitusers      0 2017-08-14 15:24 bin/P6ATOM/
lrwxrwxrwx peh/gitusers      0 2017-12-17 03:13 bin/P6ATOM/busybox -> ../common/busybox.x86
lrwxrwxrwx peh/gitusers      0 2017-12-17 03:13 bin/P6ATOM/busybox.config -> ../common/busybox.config.x86
lrwxrwxrwx peh/gitusers      0 2017-12-17 03:13 bin/P6ATOM/e2fsck -> ../common/e2fsck.x86
lrwxrwxrwx peh/gitusers      0 2017-12-17 03:13 bin/P6ATOM/mke2fs -> ../common/mke2fs.x86
lrwxrwxrwx peh/gitusers      0 2017-12-17 03:13 bin/P6ATOM/mksquashfs3 -> ../common/mksquashfs3.x86
lrwxrwxrwx peh/gitusers      0 2017-12-17 03:13 bin/P6ATOM/mksquashfs4 -> ../common/mksquashfs4.x86
lrwxrwxrwx peh/gitusers      0 2017-12-17 03:13 bin/P6ATOM/mksquashfs4-be -> ../common/mksquashfs4-be.x86
lrwxrwxrwx peh/gitusers      0 2017-12-17 03:13 bin/P6ATOM/openssl -> ../common/openssl.x86
lrwxrwxrwx peh/gitusers      0 2017-12-17 03:13 bin/P6ATOM/unsquashfs3 -> ../common/unsquashfs.x86
lrwxrwxrwx peh/gitusers      0 2017-12-17 03:13 bin/P6ATOM/unsquashfs4 -> ../common/unsquashfs.x86
lrwxrwxrwx peh/gitusers      0 2017-12-17 03:13 bin/P6ATOM/unsquashfs4-be -> ../common/unsquashfs4-be.x86
drwxr-xr-x peh/gitusers      0 2017-08-14 16:35 bin/Vx180/
lrwxrwxrwx peh/gitusers      0 2017-12-17 03:13 bin/Vx180/busybox -> ../common/busybox.24kc
lrwxrwxrwx peh/gitusers      0 2017-12-17 03:13 bin/Vx180/busybox.config -> ../common/busybox.config.24kc
lrwxrwxrwx peh/gitusers      0 2017-12-17 03:13 bin/Vx180/e2fsck -> ../common/e2fsck.24kc
lrwxrwxrwx peh/gitusers      0 2017-12-17 03:13 bin/Vx180/mke2fs -> ../common/mke2fs.24kc
lrwxrwxrwx peh/gitusers      0 2017-12-17 03:13 bin/Vx180/mksquashfs3 -> ../common/mksquashfs3.24kc
lrwxrwxrwx peh/gitusers      0 2017-12-17 03:13 bin/Vx180/mksquashfs4 -> ../common/mksquashfs4.24kc
lrwxrwxrwx peh/gitusers      0 2017-12-17 03:13 bin/Vx180/openssl -> ../common/openssl.24kc
lrwxrwxrwx peh/gitusers      0 2017-12-17 03:13 bin/Vx180/unsquashfs -> ../common/unsquashfs.24kc
drwxr-xr-x peh/gitusers      0 2018-09-17 01:03 bin/common/
-rwxr-xr-x peh/gitusers 1243624 2018-09-17 14:23 bin/common/busybox.34kc.3.10.73
-rw-r--r-- peh/gitusers   27393 2018-09-17 16:20 bin/common/busybox.config.34kc.3.10.73
-rwxr-xr-x peh/gitusers  218532 2017-09-25 17:45 bin/common/decoder.34kc.3.10.73
-rwxr-xr-x peh/gitusers  466472 2017-08-14 01:42 bin/common/e2fsck.34kc.3.10.73
-rwxr-xr-x peh/gitusers  354504 2017-08-14 01:42 bin/common/mke2fs.34kc.3.10.73
-rwxr-xr-x peh/gitusers  358516 2017-08-14 02:13 bin/common/mksquashfs3.34kc.3.10.73
-rwxr-xr-x peh/gitusers  448752 2017-08-14 02:13 bin/common/mksquashfs4.34kc.3.10.73
-rwxr-xr-x peh/gitusers 2022364 2018-09-17 13:46 bin/common/openssl.34kc.3.10.73
-rwxr-xr-x peh/gitusers  393464 2017-08-14 02:13 bin/common/unsquashfs.34kc.3.10.73
-rwxr-xr-x peh/gitusers 1237428 2018-09-16 02:47 bin/common/busybox.34kc.3.10.107
-rw-r--r-- peh/gitusers   27250 2018-09-17 00:37 bin/common/busybox.config.34kc.3.10.107
-rwxr-xr-x peh/gitusers  222924 2018-09-16 03:26 bin/common/decoder.34kc.3.10.107
-rwxr-xr-x peh/gitusers  487400 2018-09-16 02:24 bin/common/e2fsck.34kc.3.10.107
-rwxr-xr-x peh/gitusers  375160 2018-09-16 02:24 bin/common/mke2fs.34kc.3.10.107
-rwxr-xr-x peh/gitusers 2016340 2018-09-16 02:08 bin/common/openssl.34kc.3.10.107
-rwxr-xr-x peh/gitusers  468008 2018-09-16 04:14 bin/common/mksquashfs4.34kc.3.10.107
-rwxr-xr-x peh/gitusers  405740 2018-09-16 04:14 bin/common/unsquashfs.34kc.3.10.107
-rwxr-xr-x peh/gitusers  376500 2018-09-16 04:14 bin/common/mksquashfs3.34kc.3.10.107
drwxr-xr-x peh/gitusers       0 2017-08-14 16:18 bin/scripts/
drwxr-xr-x peh/gitusers       0 2017-12-31 22:10 bin/scripts/functions/
-rw-r--r-- peh/gitusers    3842 2017-06-04 21:45 bin/scripts/functions/yf_base32.function
-rw-r--r-- peh/gitusers    3757 2017-12-31 22:10 bin/scripts/functions/yf_base32_decode.function
-rw-r--r-- peh/gitusers    4091 2017-06-04 21:44 bin/scripts/functions/yf_base64.function
-rw-r--r-- peh/gitusers    3539 2017-12-31 22:10 bin/scripts/functions/yf_base64_decode.function
-rw-r--r-- peh/gitusers    3765 2017-06-04 21:44 bin/scripts/functions/yf_bin2dec.function
-rw-r--r-- peh/gitusers    3125 2017-06-04 21:44 bin/scripts/functions/yf_bin2hex.function
-rw-r--r-- peh/gitusers    2276 2017-04-21 18:36 bin/scripts/functions/yf_bridge_interfaces.function
-rw-r--r-- peh/gitusers    2085 2017-04-28 09:48 bin/scripts/functions/yf_count_of.function
-rw-r--r-- peh/gitusers    2871 2017-04-21 18:36 bin/scripts/functions/yf_dec2hex.function
-rw-r--r-- peh/gitusers    2519 2017-04-30 17:01 bin/scripts/functions/yf_endianess.function
-rw-r--r-- peh/gitusers    3329 2017-04-21 18:36 bin/scripts/functions/yf_endianess_by_routing_table.function
-rw-r--r-- peh/gitusers    2475 2017-04-21 18:36 bin/scripts/functions/yf_find_mountpoint.function
-rw-r--r-- peh/gitusers    3378 2017-05-11 05:51 bin/scripts/functions/yf_fritzos_login_hash.function
-rw-r--r-- peh/gitusers    5912 2017-05-12 04:06 bin/scripts/functions/yf_fritzos_model_settings.function
-rw-r--r-- peh/gitusers    2414 2017-04-21 18:36 bin/scripts/functions/yf_fritzos_partition_device_name.function
-rw-r--r-- peh/gitusers    2404 2017-04-21 18:36 bin/scripts/functions/yf_from_right.function
-rw-r--r-- peh/gitusers    2304 2017-04-21 18:36 bin/scripts/functions/yf_get_bridge.function
-rw-r--r-- peh/gitusers    2384 2017-04-21 18:36 bin/scripts/functions/yf_get_bridge_members.function
-rw-r--r-- peh/gitusers    2824 2017-04-21 18:36 bin/scripts/functions/yf_get_default_gateway_address.function
-rw-r--r-- peh/gitusers    2658 2017-04-21 18:36 bin/scripts/functions/yf_get_default_gateway_interface.function
-rw-r--r-- peh/gitusers    3098 2017-05-11 03:59 bin/scripts/functions/yf_get_first_host_in_subnet.function
-rw-r--r-- peh/gitusers    4110 2017-04-21 18:36 bin/scripts/functions/yf_get_fritzos_partition_by_name.function
-rw-r--r-- peh/gitusers    4204 2017-04-21 18:36 bin/scripts/functions/yf_get_fritzos_partition_by_number.function
-rw-r--r-- peh/gitusers    2455 2017-04-21 18:36 bin/scripts/functions/yf_get_fstype_for_mountpoint.function
-rw-r--r-- peh/gitusers    2326 2017-04-21 18:36 bin/scripts/functions/yf_get_ip_address.function
-rw-r--r-- peh/gitusers    3166 2017-05-11 04:00 bin/scripts/functions/yf_get_last_host_in_subnet.function
-rw-r--r-- peh/gitusers    4287 2017-06-04 21:45 bin/scripts/functions/yf_hex2bin.function
-rw-r--r-- peh/gitusers    2399 2017-04-21 18:36 bin/scripts/functions/yf_hex2dec.function
-rw-r--r-- peh/gitusers    2413 2017-04-21 18:36 bin/scripts/functions/yf_index.function
-rw-r--r-- peh/gitusers    2370 2017-04-28 09:49 bin/scripts/functions/yf_index_of.function
-rw-r--r-- peh/gitusers    3670 2017-04-21 18:36 bin/scripts/functions/yf_initialize_ringbuffer.function
-rw-r--r-- peh/gitusers    3212 2017-05-11 04:00 bin/scripts/functions/yf_ipv4_address.function
-rw-r--r-- peh/gitusers    1978 2017-04-21 18:36 bin/scripts/functions/yf_is_bridge_interface.function
-rw-r--r-- peh/gitusers    2063 2017-04-21 18:36 bin/scripts/functions/yf_is_bridge_member.function
-rw-r--r-- peh/gitusers    1955 2017-05-13 18:00 bin/scripts/functions/yf_is_decimal.function
-rw-r--r-- peh/gitusers    2922 2017-04-21 18:36 bin/scripts/functions/yf_is_fritzos_device.function
-rw-r--r-- peh/gitusers    1965 2017-04-21 18:36 bin/scripts/functions/yf_is_hexadecimal.function
-rw-r--r-- peh/gitusers    2564 2017-04-21 18:36 bin/scripts/functions/yf_is_mountpoint_writable.function
-rw-r--r-- peh/gitusers    1982 2017-04-21 18:36 bin/scripts/functions/yf_is_wireless_interface.function
-rw-r--r-- peh/gitusers    2476 2017-04-21 18:36 bin/scripts/functions/yf_lowercase.function
-rw-r--r-- peh/gitusers    2800 2017-04-28 09:50 bin/scripts/functions/yf_mktemp.function
-rw-r--r-- peh/gitusers    2262 2017-04-21 18:36 bin/scripts/functions/yf_network_interfaces.function
-rw-r--r-- peh/gitusers    5102 2017-05-11 05:22 bin/scripts/functions/yf_pack.function
-rw-r--r-- peh/gitusers    2436 2017-04-21 18:36 bin/scripts/functions/yf_print_ip.function
-rw-r--r-- peh/gitusers    3139 2017-12-31 22:10 bin/scripts/functions/yf_random_string.function
-rw-r--r-- peh/gitusers    5688 2017-04-21 18:36 bin/scripts/functions/yf_readable_size.function
-rw-r--r-- peh/gitusers    2214 2017-04-28 09:50 bin/scripts/functions/yf_reverse_hex.function
-rw-r--r-- peh/gitusers    2821 2017-04-21 18:36 bin/scripts/functions/yf_storage_devices.function
-rw-r--r-- peh/gitusers    2189 2017-04-21 18:36 bin/scripts/functions/yf_str2hex.function
-rw-r--r-- peh/gitusers    2813 2017-05-11 03:31 bin/scripts/functions/yf_string_compare.function
-rw-r--r-- peh/gitusers    2724 2017-12-31 22:10 bin/scripts/functions/yf_substring.function
-rw-r--r-- peh/gitusers    2263 2017-04-21 18:36 bin/scripts/functions/yf_sysfs.function
-rw-r--r-- peh/gitusers    2682 2017-05-12 21:14 bin/scripts/functions/yf_trim.function
-rw-r--r-- peh/gitusers    2477 2017-04-22 11:05 bin/scripts/functions/yf_uppercase.function
-rw-r--r-- peh/gitusers    2282 2017-04-21 18:36 bin/scripts/functions/yf_wireless_interfaces.function
-rw-r--r-- peh/gitusers    2476 2017-04-29 01:10 bin/scripts/functions/yf_word_of.function
-rw-r--r-- peh/gitusers    3653 2016-10-18 03:47 bin/scripts/check_image_signature
-r--r--r-- peh/gitusers   27942 2017-08-14 16:18 bin/scripts/check_signed_image
-rw-r--r-- peh/gitusers   17915 2016-11-19 04:40 bin/scripts/check_update
-rw-r--r-- peh/gitusers     172 2016-10-17 15:58 bin/scripts/wrap_script
-rw-r--r-- peh/gitusers   14702 2017-06-02 10:46 bin/scripts/yf_helpers
drwxr-xr-x peh/gitusers       0 2018-09-16 23:30 bin/VR9_3.10.73/
lrwxrwxrwx peh/gitusers       0 2018-09-16 23:21 bin/VR9_3.10.73/busybox -> ../common/busybox.34kc.3.10.73
lrwxrwxrwx peh/gitusers       0 2018-09-16 23:21 bin/VR9_3.10.73/busybox.config -> ../common/busybox.config.34kc.3.10.73
lrwxrwxrwx peh/gitusers       0 2018-09-16 23:21 bin/VR9_3.10.73/e2fsck -> ../common/e2fsck.34kc.3.10.73
lrwxrwxrwx peh/gitusers       0 2018-09-16 23:21 bin/VR9_3.10.73/mke2fs -> ../common/mke2fs.34kc.3.10.73
lrwxrwxrwx peh/gitusers       0 2018-09-16 23:21 bin/VR9_3.10.73/mksquashfs3 -> ../common/mksquashfs3.34kc.3.10.73
lrwxrwxrwx peh/gitusers       0 2018-09-16 23:21 bin/VR9_3.10.73/mksquashfs4 -> ../common/mksquashfs4.34kc.3.10.73
lrwxrwxrwx peh/gitusers       0 2018-09-16 23:21 bin/VR9_3.10.73/openssl -> ../common/openssl.34kc.3.10.73
lrwxrwxrwx peh/gitusers       0 2018-09-16 23:23 bin/VR9_3.10.73/unsquashfs3 -> ../common/unsquashfs.34kc.3.10.73
lrwxrwxrwx peh/gitusers       0 2018-09-16 23:24 bin/VR9_3.10.73/unsquashfs4 -> ../common/unsquashfs.34kc.3.10.73
lrwxrwxrwx peh/gitusers       0 2018-09-16 23:28 bin/175 -> VR9_3.10.73
lrwxrwxrwx peh/gitusers       0 2018-09-16 23:28 bin/185 -> VR9_3.10.73
lrwxrwxrwx peh/gitusers       0 2018-09-16 23:28 bin/192 -> VR9_3.10.73
lrwxrwxrwx peh/gitusers       0 2018-09-16 23:28 bin/193 -> VR9_3.10.73
lrwxrwxrwx peh/gitusers       0 2018-09-16 23:28 bin/203 -> VR9_3.10.73
lrwxrwxrwx peh/gitusers       0 2018-09-16 23:28 bin/212 -> VR9_3.10.73
lrwxrwxrwx peh/gitusers       0 2018-09-16 23:28 bin/218 -> VR9_3.10.73
drwxr-xr-x peh/gitusers       0 2018-09-16 23:24 bin/GRX5_3.10.73/
lrwxrwxrwx peh/gitusers       0 2018-09-16 23:21 bin/GRX5_3.10.73/busybox -> ../common/busybox.34kc.3.10.73
lrwxrwxrwx peh/gitusers       0 2018-09-16 23:21 bin/GRX5_3.10.73/busybox.config -> ../common/busybox.config.34kc.3.10.73
lrwxrwxrwx peh/gitusers       0 2018-09-16 23:21 bin/GRX5_3.10.73/e2fsck -> ../common/e2fsck.34kc.3.10.73
lrwxrwxrwx peh/gitusers       0 2018-09-16 23:21 bin/GRX5_3.10.73/mke2fs -> ../common/mke2fs.34kc.3.10.73
lrwxrwxrwx peh/gitusers       0 2018-09-16 23:21 bin/GRX5_3.10.73/mksquashfs3 -> ../common/mksquashfs3.34kc.3.10.73
lrwxrwxrwx peh/gitusers       0 2018-09-16 23:21 bin/GRX5_3.10.73/mksquashfs4 -> ../common/mksquashfs4.34kc.3.10.73
lrwxrwxrwx peh/gitusers       0 2018-09-16 23:21 bin/GRX5_3.10.73/openssl -> ../common/openssl.34kc.3.10.73
lrwxrwxrwx peh/gitusers       0 2018-09-16 23:23 bin/GRX5_3.10.73/unsquashfs3 -> ../common/unsquashfs.34kc.3.10.73
lrwxrwxrwx peh/gitusers       0 2018-09-16 23:24 bin/GRX5_3.10.73/unsquashfs4 -> ../common/unsquashfs.34kc.3.10.73
lrwxrwxrwx peh/gitusers       0 2018-09-16 23:32 bin/221 -> GRX5_3.10.73
lrwxrwxrwx peh/gitusers       0 2018-09-16 23:32 bin/225 -> GRX5_3.10.73
lrwxrwxrwx peh/gitusers       0 2018-09-16 23:32 bin/226 -> GRX5_3.10.73
drwxr-xr-x peh/gitusers       0 2018-09-17 01:09 bin/VR9_3.10.107/
lrwxrwxrwx peh/gitusers       0 2018-09-17 01:09 bin/VR9_3.10.107/busybox -> ../common/busybox.34kc.3.10.107
lrwxrwxrwx peh/gitusers       0 2018-09-17 01:09 bin/VR9_3.10.107/busybox.config -> ../common/busybox.config.34kc.3.10.107
lrwxrwxrwx peh/gitusers       0 2018-09-17 01:09 bin/VR9_3.10.107/e2fsck -> ../common/e2fsck.34kc.3.10.107
lrwxrwxrwx peh/gitusers       0 2018-09-17 01:09 bin/VR9_3.10.107/mke2fs -> ../common/mke2fs.34kc.3.10.107
lrwxrwxrwx peh/gitusers       0 2018-09-17 01:09 bin/VR9_3.10.107/mksquashfs3 -> ../common/mksquashfs3.34kc.3.10.107
lrwxrwxrwx peh/gitusers       0 2018-09-17 01:09 bin/VR9_3.10.107/mksquashfs4 -> ../common/mksquashfs4.34kc.3.10.107
lrwxrwxrwx peh/gitusers       0 2018-09-17 01:09 bin/VR9_3.10.107/openssl -> ../common/openssl.34kc.3.10.107
lrwxrwxrwx peh/gitusers       0 2018-09-17 01:09 bin/VR9_3.10.107/unsquashfs3 -> ../common/unsquashfs.34kc.3.10.107
lrwxrwxrwx peh/gitusers       0 2018-09-17 01:09 bin/VR9_3.10.107/unsquashfs4 -> ../common/unsquashfs.34kc.3.10.107
drwxrwxr-x peh/gitusers       0 2017-02-11 12:49 files/
-r--rw-r-- peh/gitusers  144392 2016-02-13 10:30 files/128MB_ext3.gz
-rw-rw-r-- peh/gitusers   29756 2017-02-11 12:49 files/E99-custom
drwxrwxr-x peh/gitusers       0 2016-09-21 10:41 locale/
-r--rw-r-- peh/gitusers   13194 2016-09-25 16:05 locale/de
-r--rw-r-- peh/gitusers   11147 2016-09-25 16:03 locale/en
dr-xrwxr-- peh/gitusers       0 2018-09-17 16:22 modscripts/
-r-xr-xr-- peh/gitusers     664 2016-03-17 11:50 modscripts/copy_binaries
-r-xr--r-- peh/gitusers    1574 2016-02-18 15:09 modscripts/dectcmds.modscript
-r-xr-xr-- peh/gitusers    3646 2016-02-18 13:01 modscripts/edit_rcuser
-r-xr-xr-- peh/gitusers   36506 2017-08-17 14:06 modscripts/gui_boot_manager_v0.4
-r-xr-xr-- peh/gitusers    1392 2016-03-29 04:11 modscripts/mod_custom_images
-r-xr-xr-- peh/gitusers    5916 2018-09-17 15:52 modscripts/mod_leddisplay
-r-xr-xr-- peh/gitusers    2494 2016-10-18 04:05 modscripts/mod_night
-r-xr-xr-- peh/gitusers    1732 2016-03-18 15:14 modscripts/mod_prefer_fonnumber_name
-r-xr-xr-- peh/gitusers    1272 2016-02-18 13:06 modscripts/mod_profile
-r-xr-xr-- peh/gitusers    2223 2016-09-22 15:44 modscripts/mod_rc_tail_sh
-r-xr-xr-- peh/gitusers    3197 2016-07-29 16:10 modscripts/mod_show_name
-r-xr-xr-- peh/gitusers   12453 2018-02-27 23:57 modscripts/mod_show_vpn_on_overview
-r-xr--r-- peh/gitusers     645 2016-02-18 16:03 modscripts/template
-r-xr--r-- peh/gitusers    5266 2016-02-18 14:29 modscripts/yourfritz_hooks
-r-xr-xr-- peh/gitusers    1615 2018-09-15 02:50 modscripts/mod_default_show_mac
-r-xr-xr-- peh/gitusers    2191 2018-09-15 00:22 modscripts/mod_mount_by_label
-r-xr-xr-- peh/gitusers    4262 2018-09-15 00:39 modscripts/mod_swapoff
-r-xr-xr-- peh/gitusers    1144 2016-02-18 16:01 modscripts/mod_telnet_enable
-r-xr-xr-- peh/gitusers    1270 2018-09-15 01:04 modscripts/mod_telnet_start
drwxrwxr-x peh/gitusers       0 2018-09-18 17:03 contrib/
-rw-rw-r-- peh/gitusers    1145 2018-09-18 17:22 contrib/README.md
-rw-rw-r-- peh/gitusers   18092 2017-03-31 17:06 LICENSE
-rw-rw-r-- peh/gitusers   11080 2018-05-09 14:00 BOOTSELECTION.ger
-rwxrwxr-x peh/gitusers  101076 2018-09-18 22:31 modfs
vidar:~ $

Hier fehlt bei Dir also das "-beta" im Dateinamen ... alle Requests für eine Datei "modfs-0*.tgz" werden (mit Ausnahme für diese Beta-Version) auf das Archiv mit der README.md umgeleitet, seitdem ich keine älteren Versionen mehr über den Server an yourfritz.de verteile und stattdessen auf ältere Stände aus dem GitHub-Repository verweise, wo man sich die selbst auschecken kann.

RewriteRule ^/favicon\.ico - [L]
RewriteRule ^/error/.* - [L]
RewriteRule ^/modfs-0\.5\..*-beta\.tgz - [L]
RewriteRule ^/modfs-0.*\.tgz modfs-old-version.tgz [R,L]
RewriteRule ^/$ https://github.com/PeterPawn/YourFritz [R,L]

Ich hatte in einem italienischen Forum noch Links auf irgendwelche "modfs-0.3.x.tgz"-Stände gefunden (auch ein paar Internet-Artikel beziehen sich auf die alten Versionen) und daher dann irgendwann mal konsequent den Schritt gemacht, daß nur noch die Datei "modfs.tgz" über den Server ausgeliefert wird und die ist das jeweils letzte Release-Archiv. Erst für diese Beta habe ich die zusätzliche Rewrite-Regel hinzugefügt.

----------------------------------------------------------------------------------------------------------------------------------

Wobei ich jetzt schon "ansagen" kann, daß sich dieser "Ablauf" bei der Benutzung von "modfs" (und beim Laden der aktuellen Version) ändern wird ... künftig muß in der betreffenden Box der öffentliche Schlüssel aus dem YourFritz-Repo enthalten sein (https://github.com/PeterPawn/YourFritz/blob/master/YourFritz.asc - entweder permanent oder von Hand für den Download aktiviert; wer dem Key vertrauen möchte und es später einfacher haben will, baut ihn gleich mit ein in die nächste Version ... das "modscript" dafür kommt heute noch) und dann erfolgt die "Installation" des "modfs"-Pakets über einen Aufruf von "tr069fwupdate packet" (das kann auch gleich den Download übernehmen) inkl. der Prüfung auf passende Signatur.

Das Paket ist durch die doppelt vorhandenen Binärdateien (1x für 3.10.73 und 1x für 3.10.107) erheblich größer geworden und für diejenigen, die es im "tmpfs" speichern und damit Hauptspeicher für den Rest des Systems blockieren, wird das künftig enthaltene "var/install"-Skript dann die laufende System-Version ermitteln, die richtigen Binärdateien passend verlinken und den Rest der Dateien entsorgen, damit deren Platz frei wird. Das ist zwar nicht die Welt ... aber 2-3 MB sind bei 128 MB gesamt dann schon wieder ein ganz schöner Happen; meine 7490 hat ca. 110 MB im "tmpfs" frei und das bei 256 MB RAM.

Die Alternative wäre eine Art "Starter-Skript", was sich automatisch nur das passende Paket für die jeweilige (laufende) FRITZ!OS-Version vom Server lädt (natürlich auch mit Signaturprüfung) ... aber das erfordert dann von mir die Verwaltung mehrerer passender Pakete - eigentlich nicht so ganz das, was ich wollte.

Außerdem kann man in dieser "var/install" dann tatsächlich noch andere Sachen machen ... z.B. einen ansonsten nicht aktiven Shell-Zugang (über Shell-in-a-Box) extra für den "modfs"-Aufruf einrichten. Da das für das "modfs"-Paket verwendete Format dann dasselbe ist wie für AVM-Updates für Peripherie (z.B. die DECT-Geräte), kann man "modfs" auch dann ausführen lassen (über diesen gesonderten SIAB-Daemon), wenn man ansonsten gar keinen dauerhaft aktiven Shell-Zugang in der eigenen Box aktiviert hat. Wenn der Telnet-Daemon sich nicht mehr über Telefon starten und beenden läßt (das habe ich immer noch nicht geschafft "auszuermitteln"), dann ist es ja ein Bärendienst für die Sicherheit, wenn der jetzt ständig aktiv sein soll, nur damit man irgendwann mal wieder "modfs" anwerfen kann, wenn die nächste Firmware erscheint.

Also habe ich mir eine andere Lösung überlegt und die besteht darin, daß man (mein Vorschlag - wer dem nicht folgen will oder kann, muß halt selbst sehen, wie er den Key in die Firmware kriegt ... einen Weg dazu (über die "bbX"-Einträge im Environment), habe ich letztens hier irgendwo mal angerissen) den YourFritz-Key in die Firmware integrieren läßt und dann kann man (auch ohne aktiven Shell-Zugang, allerdings braucht man irgendein AVM-Gerät, für welches über "sbin/start_dect_update" auf Firmware-Aktualisierungen geprüft wird - da steckt das "tr069fwupdate packet" dann nämlich drin) einfach das "modfs"-Paket unter dem passenden Namen (wie ein Downgrade für irgendein DECT-Gerät) auf einen USB-Stick packen und die Update-Prüfung anwerfen. Die "Installation" läuft dann automatisch ab (und im Gegensatz zu einem "richtigen" Firmware-Update ohne das Herunterfahren des halben Systems) und im Anschluß steht der Prompt über Shell-in-a-Box bereit für den Aufruf (der Download ist dann bereits erledigt) von "modfs".

So in etwa stelle ich mir das vor (in ein bis zwei Wochen oder so, weil ich jetzt wirklich (fast) ohne Unterbrechungen am "modfs" arbeite), wie es künftig ablaufen soll (das hat dann auch gleich wieder ein paar mehr Elemente von "YourFritz", wo ich ja eigentlich hin will) ... wenn man das "modfs" (ausgepackt) permanent irgendwo auf einem USB-Stick vorhält, könnte man sogar noch eine Prüfung einbauen, ob es überhaupt eine neue Version gibt und sich den Download ansonsten sparen.

 

[Micha0815]

auch schon das korrekte Archiv unter dem Namen "modfs-0.5.0.tgz" auf dem Server finden

Das hatte ich angenommen. Aber auch mit modfs-0.5.0-beta.tgz kommt nix an?

 wget: bad adress `yourfritz.de`

Ob server down oder ich zu doof ... egal.
Wenn sämtliche Anleitungen z.B. #1 oder dies nur noch Makulatur sind, wird die Userzahl bzw. Beliebheit eher abnehmen. Mit Dateirechten, mount-Befehlen, Execute-Flags, den korrekten Pfaden, demnächst noch Signaturschlüsseln neben der github-"Nebenwissenschaft" werden die Einsteigerhürden eher höher gehängt, als vereinfacht.
LG and my 2cent

 

[PeterPawn]

Sorry, das ist dann wohl ein (anderer?) Tippfehler, denn zuvor wurde der Server ja noch gefunden. Ich würde hier einfach die Eingaben erneut überprüfen, denn wenn ich raten sollte, fehlt da irgendwo das Protokoll-Präfix an der Adresse und das zum Download verwendete "wget" setzt das Präfix vielleicht nicht von selbst.

Wobei ich die Fehlermeldung auch nur dann reproduzieren kann, wenn ich absichtlich einen nicht existierenden DNS-Namen verwende ... das kann also auch problemlos nur ein temporärer DNS-Fehler gewesen sein (für den ich dann auch immer noch nichts kann):

root@FB7490:/var/media/ftp/YourFritz/modfs $ wget oops.yourfritz.de
wget: bad address 'oops.yourfritz.de'
root@FB7490:/var/media/ftp/YourFritz/modfs $ wget yourfritz.de
Connecting to yourfritz.de (85.214.20.177:80)
Connecting to github.com (192.30.253.113:443)
index.html           100% |***********************************************************************************|   108k  0:00:00 ETA
root@FB7490:/var/media/ftp/YourFritz/modfs $ wget yourfritz.de/modfs.tgz
Connecting to yourfritz.de (85.214.20.177:80)
modfs.tgz            100% |***********************************************************************************|  2636k  0:00:00 ETA
root@FB7490:/var/media/ftp/YourFritz/modfs $

-------------------------------------------------------------------------------------------------------

Mir ist auch einigermaßen unklar, wie man irgendwelche Prognosen hinsichtlich der Einfachheit bei der Bedienung von "modfs" abgeben will, solange man das noch gar nicht in Gänze gesehen hat ... außerdem ist nur das Bessere der Feind des Guten und wenn man lieber "Stillstand" bei so einem Projekt möchte, muß man (a) so konsequent sein, dann lieber beim derzeitigen Release-Stand bleiben zu wollen (dann gehen einem weitere Änderungen automatisch am Sitzfleisch vorbei) und (b) sich mal bei AVM darüber aufregen, daß da ständig geändert wird (wenn auch wohl im Interesse der Sicherheit der "normalen Benutzer"). Ohne diese Änderungen bräuchte es auch meine Anpassungen bzw. Änderungen nicht - was nicht heißen soll, daß ich Änderungen in Richtung mehr Sicherheit nicht ausdrücklich begrüße.

Also nicht allzu überrascht sein, wenn ich das tatsächlich anders sehe ... zumal Du da nach meinem Eindruck auch nur die Hälfte richtig interpretiert hast von meinen Worten.

Ich bin einigermaßen irritiert, warum und wo Du beim Umgang mit "modfs" (außer Du willst meine Arbeit überprüfen oder einen alten Stand benutzen) überhaupt mit "github" als "Nebenwissenschaft" jenseits eines Browser-Links (in irgendeinem Beitrag hier) in Berührung kommen solltest ... mal ganz abgesehen davon, daß nun mal der Umgang mit "git" (was - nur nebenbei bemerkt - auch für Windows existiert) alles andere als kompliziert ist.

Sofern man "Konsument" ist, muß man nicht mal die anderen Prinzipien einer Versionsverwaltung verstehen und nur, weil ein paar Anwender damit ggf. Probleme haben, kann man auch nicht auf die (öffentliche) Versionsverwaltung verzichten. Erstens gehört ein VCS nun mal zu jeder (sinnvollen) Software-Entwicklung dazu und zweitens bietet nur dieses öffentliche Repository den Benutzern die Möglichkeit, ad libitum auch auf eine ältere Version zuzugreifen.

Bei allen "Forderungen" nach einfachen Lösungen muß man also auch die Kirche im Dorf lassen ... und die allereinfachste Lösung (die tatsächlich fast gar keine Beschäftigung mit irgendeinem Thema braucht) ist die Verwendung der originalen AVM-Firmware. Wer da einen Schritt weitergehen möchte, muß sich auch ein paar zusätzliche Kenntnisse aneignen und diese sind nun so gar nicht "FRITZ!Box-spezifisch" und können tatsächlich auch an anderen Stellen noch nützlich sein.

Aus der ganzen Aufzählung von "Einsteigerhürden" in #1490:

Mit Dateirechten, mount-Befehlen, Execute-Flags, den korrekten Pfaden, demnächst noch Signaturschlüsseln neben der github-"Nebenwissenschaft" werden die Einsteigerhürden eher höher gehängt, als vereinfacht.

hätte ich dann genau einen einzigen Punkt tatsächlich zu vertreten ... nämlich den mit den Signaturen. Um deren Prüfung muß man sich noch nicht einmal selbst kümmern, denn das übernimmt ja gerade das FRITZ!OS (und zwar auch das originale von AVM) - genauso wie den Download, das Auspacken und das Starten des Installationsskripts.

Bleibt also die Notwendigkeit, den Schlüssel für die Prüfung irgendwie in die Box zu kriegen ... daß ich dafür (heute noch, wenn ich nicht immer auf irgendwelche "Einwände" reagieren muß) ein neues Skript für "modfs" bereitstellen will, steht irgendwo im letzten Beitrag. Wo ist da irgendeine "zusätzliche Hürde für Einsteiger"? In der Ja-/Nein-Frage, ob der Key installiert werden soll oder nicht?

Alles andere, was da noch so aufgelistet ist an zu beachtenden Dingen bei der Verwendung von "modfs", kam erst nachträglich durch Änderungen seitens AVM hinzu, nachdem es "modfs" bereits gab. Was willst Du mir also konkret mit #1490 sagen? Daß ich besser bei irgendeinem alten Stand von "modfs" und der AVM-Firmware geblieben wäre?

Abgesehen davon, daß ein Punkt "korrekte Pfade" ja wohl kaum als - von mir errichtete - Hürde herhalten kann ... denn die Behandlung solcher Pfade ist Sache des Betriebssystems (ebenso gilt das für Dateirechte bis hin zum Execute-Flag) und wenn das Linux sogar noch auf korrekte Groß-/Kleinschreibung Wert legt, dann kann man mal sehen, wieviel "großzügiger" meine Syntax-Prüfung beim Lesen und Beantworten von Fragen zum "modfs" agiert.

Wem "modfs" am Ende zu kompliziert ist, der kann ja immer noch zu Freetz greifen ... die Verwendung ist ja "keine Pflicht", sondern es handelt sich nur um ein Angebot, das man annehmen kann oder nicht. Wer dann hingeht und mir (mal abseits von der Meinung in #1490) erklärt, das wäre alles noch viel zu kompliziert, was soll ich dann mit demjenigen eigentlich machen? Zustimmen und gut ist's?

Eher nicht ... weil das "Nölen" von so manchem (jetzt muß Du (@Micha0815) Dich nicht wieder direkt angesprochen fühlen) auch durchaus auf eigener Faulheit beruht ... und ich kenne das aus meiner Kindheit tatsächlich noch so, daß ich nichts essen mußte, was mir nicht schmeckte (bis auf wenige Ausnahmen) - aber dann gab es eben auch nichts anderes und ob ich das Vorhandene dann aß oder nicht, war die einzige "freie Auswahl", die ich da hatte.

Wenn solche unbegründete (in meinen Augen) Kritik dann aber unwidersprochen bleibt und auch von anderen gelesen wird, die das am Ende glauben und dadurch schon darauf verzichten, sich selbst ein Bild zu machen (da können sie dann immer noch zu ihrer eigenen Feststellung: "ist mir zu kompliziert" gelangen), dann ist das auch nicht das, was ich gerne hätte - also wird man auch damit leben müssen, wenn ich solche Aussagen dann meinerseits sehr genau lese und auch sehr genau "zerpflücke", sofern es mir möglich ist und angebracht erscheint. Ich habe auch kein Problem, wenn das jemand - auf diese Weise, also mit Argumentation und nicht nur mit Postulaten und Polemik - so mit meinen eigenen Aussagen macht.

Wenn heute Generationen nachwachsen, denen alles vorne und hinten reingeschoben wurde und wird und die mit der simpelsten Kritik nicht mehr umgehen können (@fefe hat diese Gruppen gerade erst als "blauhaarige Schneeflocken und Bronies" zusammenfaßt und auch klargestellt, was er damit eigentlich genau meinte), dann ist das nicht wirklich mein Problem und ich zwinge niemanden, auf mein Angebot(!!!) zurückzugreifen. Aber wer sich da mit mir "anlegt" und die Arbeit schlechtmachen will, der sollte dafür schon gute Argumente bringen und nicht nur "aus dem Bauch heraus" urteilen und schreiben - ansonsten darf er auch nicht "heulen", wenn ich bei Bedarf etwas deutlicher werde.

 

[Micha0815]

Danke, der Hinweis zu einem DNS-Fehler war zielführend. Weshalb ddns wohl mehrfach für mich nicht erkennbar abstürzte kann ich nicht nachhalten. Die Box lief produktiv im Repeater-Modus unter 6.93 und angeschlossene LAN-Clients hatten Internetzugang. Dass "wget" auch als Internet-Verbindungskontrolle herhalten kann, habe ich erst im Nachgang gelernt.
Dazu war ich mir nicht sicher, ob die von mir eingebaute busybox u.U. verantwortlich zeichnete. Nach einem 15-minütigen Power-OFF-Cool-Down hatte sich das Problem von selbst erledigt.

 

[sulihari]

Ich habe die Version modfs-master.zip (Zeitstempel 18.09 22:30) versucht zu verwenden, mit mehreren Anlaeufen. Zuerst hatte ich das unzip der 7490/6.93 zum Auspacken verwendet.
Hier fehlten die Execute Rechte und die Symlinks z.B in bin/185. Wenn es hier eine Option gibt das mit Boardmitteln korrekt und vollstaendig auszupacken, dann bitte ich um einen Hinweis.
Auf einem OS X wurde alles korrekt ausgepackt. Nach Neuverpacken in ein tgz hat es dann auch auf der 7490 mit dem Auspacken funktioniert. Danach lief modfs an, zeigte aber ein bisher unbekanntes Verhalten. Es lief alles normal los. Aber dann als eigentlich die Abfragen zu den gewuenschten Settings kommen sollten, lief es automatisch weiter ohne Stopp.
Alle Abfragen bis auf eine Ausnahme wurden mit ok durchlaufen. Im Debug Log gibt es "progress: mode=3, msg=[1;31m Fehler (3)[0m" und execute_modscript: exiting, rc=3,
und spaeter noch zweimal der Fehler mit rc=1. Es kann sein, das beim Umpacken ein Fehler eingebaut wurde, der zu diesem Verhalten fuehrt. Aber evt. besteht auch ein anderes Problem.
Da ich modfs naturgemaess nur recht selten verwende, fehlt mir die Phantasie was da alles schiefgehen kann.

 

[Mr.I]

Ich habe soeben meine 7490 erfolgreich von 6.93 auf 7.01 per modfs upgedated, telnet-Zugang inklusive.
An dieser Stelle meinen ausdrücklichen Dank, Peter.

Einziger Wehrmutstropfen: Nach dem Reboot bin ich von der Box mit dem Einrichtungsassistenten begrüßt worden. Meine Internet-Zugangsdaten waren nicht mehr vorhanden, ebenso waren die Benennungen meiner Netzwerk-Geräte auf einem alten Stand. Das gleiche Bild übrigens beim Booten aus der anderen Partition mit 6.93 - auch dort sind die Zugangsdaten verschwunden, die zuvor noch vorhanden waren. Naja hat mich jetzt ein paar Minuten gekostet, alles wieder auf Stand zu bringen.
Es scheint aber mit der Beta der Fall zu sein, dass damit Daten gelöscht/überschrieben werden. Bei der "alten" modfs-Version (die ich gestern auch habe durchlaufen lassen) war dies nicht der Fall...

 

[Micha0815]

Ich habe die Version modfs-master.zip (Zeitstempel 18.09 22:30) versucht zu verwenden, mit mehreren Anlaeufen. Zuerst hatte ich das unzip der 7490/6.93 zum Auspacken verwendet.

Willkommen im Club

Nach dem Reboot bin ich von der Box mit dem Einrichtungsassistenten begrüßt worden. Meine Internet-Zugangsdaten waren nicht mehr vorhanden

Hast Du mal versucht diesen abzubrechen und vorher den Haken für die AVM-Benachrichtung (Abwahl) rausgenommen? Nach mehreren Wechsel über das Neustart-GUI (linux_fs_start 0/1) kommt dann mal die Meldung "Update erfolgreich"?
LG

 

[Mr.I]

Hast Du mal versucht diesen abzubrechen und vorher den Haken für die AVM-Benachrichtung (Abwahl) rausgenommen? Nach mehreren Wechsel über das Neustart-GUI (linux_fs_start 0/1) kommt dann mal die Meldung "Update erfolgreich"?
LG

Ich habe den Assistenten sofort abgebrochen, um erstmal die Übersichtsseite der Box laden zu lassen und sehen zu können, auf welchem OS die Box sich denn nun befindet. Erstmal habe ich recherchiert, dass zwar ein Signal von der Box empfangen wird, aber keine Zugangsdaten vorhanden sind. Dann entschloss ich mich ein Reboot auf 6.93 zu machen (ehrlich gesagt war ich nämlich vorher "risikofreudig" und habe kein Backup meiner Einstellungen gemacht; so dachte ich mir, ich boote jetzt nochmal schnell auf dem alten OS, mache ein Backup meiner Einstellungen, boote dann erneut auf 7.01 und kann da mein Backup einfach neu einspielen).
Denkste, in 6.93 waren dann die gleichen Einstellungen verschwunden... Also unverrichteter Dinge wieder auf 7.01 gebootet und dort wieder den Assistenten abgebrochen. Diesmal kam dann der "Update erfolgreich"-Hinweis inkl. Aufforderung auf der Folgeseite, mich doch über Neuigkeiten zu meiner Box mittels myfritz informieren zu lassen. Das habe ich dann ebenfalls abgebrochen und bin wieder auf der Startseite der Box gelandet. Meine Zugangsdaten usw. waren dann nicht wieder aufgetaucht. Also habe ich neu erfasst...

Interessanterweise waren meine Telefonie-Geräte, die Telefon-Zugangsdaten, die Daten der DECT-Geräte, etc. alles noch vorhanden...

 

[PeterPawn]

Die Einstellungen existieren in jeder FRITZ!Box nur einmal (ist nicht 100% korrekt, aber aus der "User-Sicht" stimmt das schon) und damit liegen für beide Partitionen auch immer dieselben Einstellungen vor - ansonsten müßten die ja auch ständig hin und her migriert werden, wenn man ein Update macht oder (mit den Erweiterungen, ansonsten stellt sich die Frage ja gar nicht) auf die andere Partition umschaltet.

Wenn da also in einer Version Daten abhanden gekommen sind, dann gilt das automatisch für beide ... nun ist es aber so, daß "modfs" die Einstellungsdateien gar nicht anrührt. Das macht das FRITZ!OS allerdings schon ... irgendwo hier habe ich davon berichtet, daß beim Wechsel von Versionen ständig irgendwelche "Migrationsmeldungen" durch die Konsolenausgaben geistern. Daß es beim Wechsel der Systemversion (sowohl vor- als auch rückwärts) Probleme geben kann (vorwärts sollte AVM eigentlich abfedern, aber rückwärts gibt es bei AVM gar nicht), ist aber auch nicht wirklich neu ... und war bei der Einführung der "update"-Möglichkeiten direkt in "modfs" (davor ging es ja nur, die bereits installierte Version zu modifizieren) genauso Thema, wie bei der Einführung des "Boot-Managers".

Das Problem mit den Einstellungen würde ich also - sofern es nicht reproduzierbar ist - eher auf die verwendeten FRITZ!OS-Versionen schieben - die einzige Datei im TFFS, an der sich "modfs" tatsächlich zu schaffen macht, ist die "rc.user" (bzw. "debug.cfg") und auch die wird nur dann geändert, wenn da kein Kommando enthalten ist. Es gab einfach zuviele Unklarheiten bei den Leuten, ob die Modifikation (hinsichtlich dieses eigenen "Start-Skripts") nun stattgefunden hat oder nicht ... solange da kein Kommando enthalten war, machte es ja keinen Unterschied. Also wird bei leerer Datei eine Zeile zum Protokollieren im Event-Log eingefügt. Das ist dann aber auch schon alles, wo "modfs" selbst oder irgendeines der von mir bereitgestellten "modscripts" auf Daten im TFFS zugreift.

----------------------------------------------------------------------------------------------------------------

Beim Speichern im GitHub-Repository gehen leider die Dateirechte hinsichtlich des "execute"-Flags kaputt ... z.B. hier zu sehen: https://github.com/PeterPawn/modfs/commit/5bcf3d34e9fbfcccca62ea3463ba7ad9c67036e4 und ich habe keine Idee (bzw. keine belastbare, jenseits von "core.filemode", wobei es bei beiden EInstellungen geändert wird), woran das am Ende liegt.

Das erklärt schon mal die fehlenden Execute-Rechte für die Binärdateien - das ZIP-File von GitHub ist eben doch etwas anderes (hinsichtlich der Dateirechte, der restliche Inhalt ist gleich) als das bereitgestellte TAR-Archiv. Letzteres enthält die korrekten ACL-Flags ... und diese sind auch für die automatische Ausführung der Skripte verantwortlich. Ich hatte ja beschrieben, daß bei Dateien mit gesetztem "x" für die Gruppe, aber nicht für "world" (oder "other"), die Nachfrage erfolgt und für solche, wo das "x" für alle gesetzt ist, das eben nicht der Fall ist. Genau das kann man ja auch mit der "custom_modscripts"-Datei noch nach eigenen Vorstellungen anpassen, so daß bei "bekannten" Modifikationen jeweils die gewünschte Auswahl erfolgt (+, ? oder -) und nur neue Dateien noch "abgefragt" werden.

Wenn hier nach einem Klonen des Repos jetzt für alle "modscripts" das "a+x" gesetzt ist, weiß ich auch nicht, woher das kommt ... bei meinem "master" ist das schon mal nicht der Fall:

vidar:/home/GitHub/modfs $ l modscripts/
total 136
dr-xrwxr-- 1 peh gitusers   624 Sep 19 21:37 ./
drwxrwxr-x 1 peh gitusers  1012 Sep 19 20:07 ../
-r-xr-xr-- 1 peh gitusers   664 Mar 17  2016 copy_binaries*
-r-xr--r-- 1 peh gitusers  1574 Feb 18  2016 dectcmds.modscript*
-r-xr-xr-- 1 peh gitusers  3646 Feb 18  2016 edit_rcuser*
-r-xr-xr-- 1 peh gitusers 36506 Aug 17  2017 gui_boot_manager_v0.4*
-r-xr-xr-- 1 peh gitusers  1392 Mar 29  2016 mod_custom_images*
-r-xr-xr-- 1 peh gitusers  1615 Sep 15 02:50 mod_default_show_mac*
-r-xr-xr-- 1 peh gitusers  5916 Sep 17 15:52 mod_leddisplay*
-r-xr-xr-- 1 peh gitusers  2191 Sep 15 00:22 mod_mount_by_label*
-r-xr-xr-- 1 peh gitusers  2494 Oct 18  2016 mod_night*
-r-xr-xr-- 1 peh gitusers  1732 Mar 18  2016 mod_prefer_fonnumber_name*
-r-xr-xr-- 1 peh gitusers  1272 Feb 18  2016 mod_profile*
-r-xr-xr-- 1 peh gitusers  2223 Sep 22  2016 mod_rc_tail_sh*
-r-xr-xr-- 1 peh gitusers  3197 Jul 29  2016 mod_show_name*
-r-xr-xr-- 1 peh gitusers 12453 Feb 27  2018 mod_show_vpn_on_overview*
-r-xr-xr-- 1 peh gitusers  4262 Sep 15 00:39 mod_swapoff*
-r-xr-xr-- 1 peh gitusers  1144 Feb 18  2016 mod_telnet_enable*
-r-xr-xr-- 1 peh gitusers  1270 Sep 15 01:04 mod_telnet_start*
-r-xr-xr-- 1 peh gitusers  3341 Sep 19 21:37 mod_yourfritz_key*
-r-xr--r-- 1 peh gitusers   645 Feb 18  2016 template*
-r-xr--r-- 1 peh gitusers  5266 Feb 18  2016 yourfritz_hooks*
vidar:/home/GitHub/modfs $ l bin/common/
total 10928
drwxr-xr-x 1 peh gitusers     830 Sep 17 01:03 ./
drwxrwxr-x 1 peh gitusers     196 Sep 17 01:06 ../
-rw-rw-r-- 1 peh gitusers      10 Aug 14  2017 .gitattributes
-rwxr-xr-x 1 peh gitusers 1237428 Sep 16 02:47 busybox.34kc.3.10.107*
-rwxr-xr-x 1 peh gitusers 1243624 Sep 17 14:23 busybox.34kc.3.10.73*
-rw-r--r-- 1 peh gitusers   27250 Sep 17 00:37 busybox.config.34kc.3.10.107
-rw-r--r-- 1 peh gitusers   27393 Sep 17 16:20 busybox.config.34kc.3.10.73
-rwxr-xr-x 1 peh gitusers  222924 Sep 16 03:26 decoder.34kc.3.10.107*
-rwxr-xr-x 1 peh gitusers  218532 Sep 25  2017 decoder.34kc.3.10.73*
-rwxr-xr-x 1 peh gitusers  487400 Sep 16 02:24 e2fsck.34kc.3.10.107*
-rwxr-xr-x 1 peh gitusers  466472 Aug 14  2017 e2fsck.34kc.3.10.73*
-rwxr-xr-x 1 peh gitusers  375160 Sep 16 02:24 mke2fs.34kc.3.10.107*
-rwxr-xr-x 1 peh gitusers  354504 Aug 14  2017 mke2fs.34kc.3.10.73*
-rwxr-xr-x 1 peh gitusers  376500 Sep 16 04:14 mksquashfs3.34kc.3.10.107*
-rwxr-xr-x 1 peh gitusers  358516 Aug 14  2017 mksquashfs3.34kc.3.10.73*
-rwxr-xr-x 1 peh gitusers  468008 Sep 16 04:14 mksquashfs4.34kc.3.10.107*
-rwxr-xr-x 1 peh gitusers  448752 Aug 14  2017 mksquashfs4.34kc.3.10.73*
-rwxr-xr-x 1 peh gitusers 2016340 Sep 16 02:08 openssl.34kc.3.10.107*
-rwxr-xr-x 1 peh gitusers 2022364 Sep 17 13:46 openssl.34kc.3.10.73*
-rwxr-xr-x 1 peh gitusers  405740 Sep 16 04:14 unsquashfs.34kc.3.10.107*
-rwxr-xr-x 1 peh gitusers  393464 Aug 14  2017 unsquashfs.34kc.3.10.73*
vidar:/home/GitHub/modfs $

Die "modscripts" stehen also alle auf "fragen" ... und so soll das auch sein. Die Binärdateien haben alle die passenden "x"-Flags gesetzt ... bei den Text-Dateien fehlt das absichtlich.

Wenn ich das Repository einfach nur klone, haben die Dateien in "modscripts" dann die falschen "x"-Flags und auch die Binärdateien partielle falsche:

vidar:/tmp $ git clone https://github.com/PeterPawn/modfs.git
Cloning into 'modfs'...
remote: Counting objects: 1139, done.
remote: Compressing objects: 100% (34/34), done.
remote: Total 1139 (delta 20), reused 57 (delta 14), pack-reused 1072
Receiving objects: 100% (1139/1139), 14.59 MiB | 8.66 MiB/s, done.
Resolving deltas: 100% (744/744), done.
vidar:/tmp/modfs # l modscripts/
total 132
drwxr-xr-x 1 root root   590 Sep 20 01:55 ./
drwxr-xr-x 1 root root   226 Sep 20 01:55 ../
-rwxr-xr-x 1 root root   664 Sep 20 01:55 copy_binaries*
-rwxr-xr-x 1 root root  1574 Sep 20 01:55 dectcmds.modscript*
-rwxr-xr-x 1 root root  3646 Sep 20 01:55 edit_rcuser*
-rwxr-xr-x 1 root root 36506 Sep 20 01:55 gui_boot_manager_v0.4*
-rwxr-xr-x 1 root root  1392 Sep 20 01:55 mod_custom_images*
-rwxr-xr-x 1 root root  1615 Sep 20 01:55 mod_default_show_mac*
-rwxr-xr-x 1 root root  5916 Sep 20 01:55 mod_leddisplay*
-rwxr-xr-x 1 root root  2191 Sep 20 01:55 mod_mount_by_label*
-rwxr-xr-x 1 root root  2494 Sep 20 01:55 mod_night*
-rwxr-xr-x 1 root root  1732 Sep 20 01:55 mod_prefer_fonnumber_name*
-rwxr-xr-x 1 root root  1272 Sep 20 01:55 mod_profile*
-rwxr-xr-x 1 root root  2223 Sep 20 01:55 mod_rc_tail_sh*
-rwxr-xr-x 1 root root  3197 Sep 20 01:55 mod_show_name*
-rwxr-xr-x 1 root root 12453 Sep 20 01:55 mod_show_vpn_on_overview*
-rwxr-xr-x 1 root root  4262 Sep 20 01:55 mod_swapoff*
-rwxr-xr-x 1 root root  1144 Sep 20 01:55 mod_telnet_enable*
-rwxr-xr-x 1 root root  1270 Sep 20 01:55 mod_telnet_start*
-rwxr-xr-x 1 root root   645 Sep 20 01:55 template*
-rwxr-xr-x 1 root root  5266 Sep 20 01:55 yourfritz_hooks*
vidar:/tmp/modfs $ l bin/common/
total 10928
drwxr-xr-x 1 root root     830 Sep 20 01:55 ./
drwxr-xr-x 1 root root     196 Sep 20 01:55 ../
-rw-r--r-- 1 root root      10 Sep 20 01:55 .gitattributes
-rw-r--r-- 1 root root 1237428 Sep 20 01:55 busybox.34kc.3.10.107
-rwxr-xr-x 1 root root 1243624 Sep 20 01:55 busybox.34kc.3.10.73*
-rw-r--r-- 1 root root   27250 Sep 20 01:55 busybox.config.34kc.3.10.107
-rw-r--r-- 1 root root   27393 Sep 20 01:55 busybox.config.34kc.3.10.73
-rw-r--r-- 1 root root  222924 Sep 20 01:55 decoder.34kc.3.10.107
-rwxr-xr-x 1 root root  218532 Sep 20 01:55 decoder.34kc.3.10.73*
-rw-r--r-- 1 root root  487400 Sep 20 01:55 e2fsck.34kc.3.10.107
-rwxr-xr-x 1 root root  466472 Sep 20 01:55 e2fsck.34kc.3.10.73*
-rw-r--r-- 1 root root  375160 Sep 20 01:55 mke2fs.34kc.3.10.107
-rwxr-xr-x 1 root root  354504 Sep 20 01:55 mke2fs.34kc.3.10.73*
-rw-r--r-- 1 root root  376500 Sep 20 01:55 mksquashfs3.34kc.3.10.107
-rwxr-xr-x 1 root root  358516 Sep 20 01:55 mksquashfs3.34kc.3.10.73*
-rw-r--r-- 1 root root  468008 Sep 20 01:55 mksquashfs4.34kc.3.10.107
-rwxr-xr-x 1 root root  448752 Sep 20 01:55 mksquashfs4.34kc.3.10.73*
-rw-r--r-- 1 root root 2016340 Sep 20 01:55 openssl.34kc.3.10.107
-rwxr-xr-x 1 root root 2022364 Sep 20 01:55 openssl.34kc.3.10.73*
-rw-r--r-- 1 root root  405740 Sep 20 01:55 unsquashfs.34kc.3.10.107
-rwxr-xr-x 1 root root  393464 Sep 20 01:55 unsquashfs.34kc.3.10.73*
vidar:/tmp/modfs $

Mache ich das mit dem ZIP-File von GitHub, kommt da genau dasselbe heraus, wie beim Klonen:

vidar:/tmp $ wget https://github.com/PeterPawn/modfs/archive/master.zip
--2018-09-20 02:16:00--  https://github.com/PeterPawn/modfs/archive/master.zip
Resolving github.com (github.com)... 192.30.253.113, 192.30.253.112
Connecting to github.com (github.com)|192.30.253.113|:443... connected.
HTTP request sent, awaiting response... 302 Found
Location: https://codeload.github.com/PeterPawn/modfs/zip/master [following]
--2018-09-20 02:16:00--  https://codeload.github.com/PeterPawn/modfs/zip/master
Resolving codeload.github.com (codeload.github.com)... 192.30.253.120, 192.30.253.121
Connecting to codeload.github.com (codeload.github.com)|192.30.253.120|:443... connected.
HTTP request sent, awaiting response... 200 OK
Length: 5515184 (5.3M) [application/zip]
Saving to: ‘master.zip’

master.zip                                                  100%[===================================================>]   5.26M  4.98MB/s    in 1.1s

2018-09-20 02:16:02 (4.98 MB/s) - ‘master.zip’ saved [5515184/5515184]

vidar:/tmp $ unzip master
Archive:  master.zip
8a0f2c050af98d450d34790f15b9be0e013b4935
   creating: modfs-master/
  inflating: modfs-master/.gitattributes
  inflating: modfs-master/.gitignore
  inflating: modfs-master/.mc.menu
 extracting: modfs-master/.version
  inflating: modfs-master/BOOTSELECTION.ger
  inflating: modfs-master/LICENSE
  inflating: modfs-master/README.md
   creating: modfs-master/bin/
    linking: modfs-master/bin/156    -> Vx180
    linking: modfs-master/bin/175    -> VR9_3.10.73
    linking: modfs-master/bin/185    -> VR9_3.10.73
    linking: modfs-master/bin/192    -> VR9_3.10.73
    linking: modfs-master/bin/193    -> VR9_3.10.73
    linking: modfs-master/bin/203    -> VR9_3.10.73
    linking: modfs-master/bin/212    -> VR9_3.10.73
    linking: modfs-master/bin/213    -> P6ATOM
    linking: modfs-master/bin/218    -> VR9_3.10.73
    linking: modfs-master/bin/220    -> P6ATOM
    linking: modfs-master/bin/221    -> GRX5_3.10.73
    linking: modfs-master/bin/225    -> GRX5_3.10.73
    linking: modfs-master/bin/226    -> GRX5_3.10.73
   creating: modfs-master/bin/GRX5_3.10.73/
 extracting: modfs-master/bin/GRX5_3.10.73/.gitattributes
    linking: modfs-master/bin/GRX5_3.10.73/busybox  -> ../common/busybox.34kc.3.10.73
    linking: modfs-master/bin/GRX5_3.10.73/busybox.config  -> ../common/busybox.config.34kc.3.10.73
    linking: modfs-master/bin/GRX5_3.10.73/e2fsck  -> ../common/e2fsck.34kc.3.10.73
    linking: modfs-master/bin/GRX5_3.10.73/mke2fs  -> ../common/mke2fs.34kc.3.10.73
    linking: modfs-master/bin/GRX5_3.10.73/mksquashfs3  -> ../common/mksquashfs3.34kc.3.10.73
    linking: modfs-master/bin/GRX5_3.10.73/mksquashfs4  -> ../common/mksquashfs4.34kc.3.10.73
    linking: modfs-master/bin/GRX5_3.10.73/openssl  -> ../common/openssl.34kc.3.10.73
    linking: modfs-master/bin/GRX5_3.10.73/unsquashfs3  -> ../common/unsquashfs.34kc.3.10.73
    linking: modfs-master/bin/GRX5_3.10.73/unsquashfs4  -> ../common/unsquashfs.34kc.3.10.73
   creating: modfs-master/bin/P6ATOM/
 extracting: modfs-master/bin/P6ATOM/.gitattributes
    linking: modfs-master/bin/P6ATOM/busybox  -> ../common/busybox.x86
    linking: modfs-master/bin/P6ATOM/busybox.config  -> ../common/busybox.config.x86
    linking: modfs-master/bin/P6ATOM/e2fsck  -> ../common/e2fsck.x86
    linking: modfs-master/bin/P6ATOM/mke2fs  -> ../common/mke2fs.x86
    linking: modfs-master/bin/P6ATOM/mksquashfs3  -> ../common/mksquashfs3.x86
    linking: modfs-master/bin/P6ATOM/mksquashfs4  -> ../common/mksquashfs4.x86
    linking: modfs-master/bin/P6ATOM/mksquashfs4-be  -> ../common/mksquashfs4-be.x86
    linking: modfs-master/bin/P6ATOM/openssl  -> ../common/openssl.x86
    linking: modfs-master/bin/P6ATOM/unsquashfs3  -> ../common/unsquashfs.x86
    linking: modfs-master/bin/P6ATOM/unsquashfs4  -> ../common/unsquashfs.x86
    linking: modfs-master/bin/P6ATOM/unsquashfs4-be  -> ../common/unsquashfs4-be.x86
   creating: modfs-master/bin/VR9_3.10.107/
    linking: modfs-master/bin/VR9_3.10.107/busybox  -> ../common/busybox.34kc.3.10.107
    linking: modfs-master/bin/VR9_3.10.107/busybox.config  -> ../common/busybox.config.34kc.3.10.107
    linking: modfs-master/bin/VR9_3.10.107/e2fsck  -> ../common/e2fsck.34kc.3.10.107
    linking: modfs-master/bin/VR9_3.10.107/mke2fs  -> ../common/mke2fs.34kc.3.10.107
    linking: modfs-master/bin/VR9_3.10.107/mksquashfs3  -> ../common/mksquashfs3.34kc.3.10.107
    linking: modfs-master/bin/VR9_3.10.107/mksquashfs4  -> ../common/mksquashfs4.34kc.3.10.107
    linking: modfs-master/bin/VR9_3.10.107/openssl  -> ../common/openssl.34kc.3.10.107
    linking: modfs-master/bin/VR9_3.10.107/unsquashfs3  -> ../common/unsquashfs.34kc.3.10.107
    linking: modfs-master/bin/VR9_3.10.107/unsquashfs4  -> ../common/unsquashfs.34kc.3.10.107
   creating: modfs-master/bin/VR9_3.10.73/
 extracting: modfs-master/bin/VR9_3.10.73/.gitattributes
    linking: modfs-master/bin/VR9_3.10.73/busybox  -> ../common/busybox.34kc.3.10.73
    linking: modfs-master/bin/VR9_3.10.73/busybox.config  -> ../common/busybox.config.34kc.3.10.73
    linking: modfs-master/bin/VR9_3.10.73/e2fsck  -> ../common/e2fsck.34kc.3.10.73
    linking: modfs-master/bin/VR9_3.10.73/mke2fs  -> ../common/mke2fs.34kc.3.10.73
    linking: modfs-master/bin/VR9_3.10.73/mksquashfs3  -> ../common/mksquashfs3.34kc.3.10.73
    linking: modfs-master/bin/VR9_3.10.73/mksquashfs4  -> ../common/mksquashfs4.34kc.3.10.73
    linking: modfs-master/bin/VR9_3.10.73/openssl  -> ../common/openssl.34kc.3.10.73
    linking: modfs-master/bin/VR9_3.10.73/unsquashfs3  -> ../common/unsquashfs.34kc.3.10.73
    linking: modfs-master/bin/VR9_3.10.73/unsquashfs4  -> ../common/unsquashfs.34kc.3.10.73
   creating: modfs-master/bin/Vx180/
 extracting: modfs-master/bin/Vx180/.gitattributes
    linking: modfs-master/bin/Vx180/busybox  -> ../common/busybox.24kc
    linking: modfs-master/bin/Vx180/busybox.config  -> ../common/busybox.config.24kc
    linking: modfs-master/bin/Vx180/e2fsck  -> ../common/e2fsck.24kc
    linking: modfs-master/bin/Vx180/mke2fs  -> ../common/mke2fs.24kc
    linking: modfs-master/bin/Vx180/mksquashfs3  -> ../common/mksquashfs3.24kc
    linking: modfs-master/bin/Vx180/mksquashfs4  -> ../common/mksquashfs4.24kc
    linking: modfs-master/bin/Vx180/openssl  -> ../common/openssl.24kc
    linking: modfs-master/bin/Vx180/unsquashfs  -> ../common/unsquashfs.24kc
   creating: modfs-master/bin/common/
 extracting: modfs-master/bin/common/.gitattributes
  inflating: modfs-master/bin/common/busybox.34kc.3.10.107
  inflating: modfs-master/bin/common/busybox.34kc.3.10.73
  inflating: modfs-master/bin/common/busybox.config.34kc.3.10.107
  inflating: modfs-master/bin/common/busybox.config.34kc.3.10.73
  inflating: modfs-master/bin/common/decoder.34kc.3.10.107
  inflating: modfs-master/bin/common/decoder.34kc.3.10.73
  inflating: modfs-master/bin/common/e2fsck.34kc.3.10.107
  inflating: modfs-master/bin/common/e2fsck.34kc.3.10.73
  inflating: modfs-master/bin/common/mke2fs.34kc.3.10.107
  inflating: modfs-master/bin/common/mke2fs.34kc.3.10.73
  inflating: modfs-master/bin/common/mksquashfs3.34kc.3.10.107
  inflating: modfs-master/bin/common/mksquashfs3.34kc.3.10.73
  inflating: modfs-master/bin/common/mksquashfs4.34kc.3.10.107
  inflating: modfs-master/bin/common/mksquashfs4.34kc.3.10.73
  inflating: modfs-master/bin/common/openssl.34kc.3.10.107
  inflating: modfs-master/bin/common/openssl.34kc.3.10.73
  inflating: modfs-master/bin/common/unsquashfs.34kc.3.10.107
  inflating: modfs-master/bin/common/unsquashfs.34kc.3.10.73
   creating: modfs-master/bin/scripts/
  inflating: modfs-master/bin/scripts/check_image_signature
  inflating: modfs-master/bin/scripts/check_signed_image
  inflating: modfs-master/bin/scripts/check_update
   creating: modfs-master/bin/scripts/functions/
  inflating: modfs-master/bin/scripts/functions/yf_base32.function
  inflating: modfs-master/bin/scripts/functions/yf_base32_decode.function
  inflating: modfs-master/bin/scripts/functions/yf_base64.function
  inflating: modfs-master/bin/scripts/functions/yf_base64_decode.function
  inflating: modfs-master/bin/scripts/functions/yf_bin2dec.function
  inflating: modfs-master/bin/scripts/functions/yf_bin2hex.function
  inflating: modfs-master/bin/scripts/functions/yf_bridge_interfaces.function
  inflating: modfs-master/bin/scripts/functions/yf_count_of.function
  inflating: modfs-master/bin/scripts/functions/yf_dec2hex.function
  inflating: modfs-master/bin/scripts/functions/yf_endianess.function
  inflating: modfs-master/bin/scripts/functions/yf_endianess_by_routing_table.function
  inflating: modfs-master/bin/scripts/functions/yf_find_mountpoint.function
  inflating: modfs-master/bin/scripts/functions/yf_fritzos_login_hash.function
  inflating: modfs-master/bin/scripts/functions/yf_fritzos_model_settings.function
  inflating: modfs-master/bin/scripts/functions/yf_fritzos_partition_device_name.function
  inflating: modfs-master/bin/scripts/functions/yf_from_right.function
  inflating: modfs-master/bin/scripts/functions/yf_get_bridge.function
  inflating: modfs-master/bin/scripts/functions/yf_get_bridge_members.function
  inflating: modfs-master/bin/scripts/functions/yf_get_default_gateway_address.function
  inflating: modfs-master/bin/scripts/functions/yf_get_default_gateway_interface.function
  inflating: modfs-master/bin/scripts/functions/yf_get_first_host_in_subnet.function
  inflating: modfs-master/bin/scripts/functions/yf_get_fritzos_partition_by_name.function
  inflating: modfs-master/bin/scripts/functions/yf_get_fritzos_partition_by_number.function
  inflating: modfs-master/bin/scripts/functions/yf_get_fstype_for_mountpoint.function
  inflating: modfs-master/bin/scripts/functions/yf_get_ip_address.function
  inflating: modfs-master/bin/scripts/functions/yf_get_last_host_in_subnet.function
  inflating: modfs-master/bin/scripts/functions/yf_hex2bin.function
  inflating: modfs-master/bin/scripts/functions/yf_hex2dec.function
  inflating: modfs-master/bin/scripts/functions/yf_index.function
  inflating: modfs-master/bin/scripts/functions/yf_index_of.function
  inflating: modfs-master/bin/scripts/functions/yf_initialize_ringbuffer.function
  inflating: modfs-master/bin/scripts/functions/yf_ipv4_address.function
  inflating: modfs-master/bin/scripts/functions/yf_is_bridge_interface.function
  inflating: modfs-master/bin/scripts/functions/yf_is_bridge_member.function
  inflating: modfs-master/bin/scripts/functions/yf_is_decimal.function
  inflating: modfs-master/bin/scripts/functions/yf_is_fritzos_device.function
  inflating: modfs-master/bin/scripts/functions/yf_is_hexadecimal.function
  inflating: modfs-master/bin/scripts/functions/yf_is_mountpoint_writable.function
  inflating: modfs-master/bin/scripts/functions/yf_is_wireless_interface.function
  inflating: modfs-master/bin/scripts/functions/yf_lowercase.function
  inflating: modfs-master/bin/scripts/functions/yf_mktemp.function
  inflating: modfs-master/bin/scripts/functions/yf_network_interfaces.function
  inflating: modfs-master/bin/scripts/functions/yf_pack.function
  inflating: modfs-master/bin/scripts/functions/yf_print_ip.function
  inflating: modfs-master/bin/scripts/functions/yf_random_string.function
  inflating: modfs-master/bin/scripts/functions/yf_readable_size.function
  inflating: modfs-master/bin/scripts/functions/yf_reverse_hex.function
  inflating: modfs-master/bin/scripts/functions/yf_storage_devices.function
  inflating: modfs-master/bin/scripts/functions/yf_str2hex.function
  inflating: modfs-master/bin/scripts/functions/yf_string_compare.function
  inflating: modfs-master/bin/scripts/functions/yf_substring.function
  inflating: modfs-master/bin/scripts/functions/yf_sysfs.function
  inflating: modfs-master/bin/scripts/functions/yf_trim.function
  inflating: modfs-master/bin/scripts/functions/yf_uppercase.function
  inflating: modfs-master/bin/scripts/functions/yf_wireless_interfaces.function
  inflating: modfs-master/bin/scripts/functions/yf_word_of.function
  inflating: modfs-master/bin/scripts/wrap_script
  inflating: modfs-master/bin/scripts/yf_helpers
   creating: modfs-master/contrib/
  inflating: modfs-master/contrib/README.md
   creating: modfs-master/files/
  inflating: modfs-master/files/128MB_ext3.gz
  inflating: modfs-master/files/E99-custom
   creating: modfs-master/locale/
  inflating: modfs-master/locale/de
  inflating: modfs-master/locale/en
  inflating: modfs-master/modfs
   creating: modfs-master/modscripts/
  inflating: modfs-master/modscripts/copy_binaries
  inflating: modfs-master/modscripts/dectcmds.modscript
  inflating: modfs-master/modscripts/edit_rcuser
  inflating: modfs-master/modscripts/gui_boot_manager_v0.4
  inflating: modfs-master/modscripts/mod_custom_images
  inflating: modfs-master/modscripts/mod_default_show_mac
  inflating: modfs-master/modscripts/mod_leddisplay
  inflating: modfs-master/modscripts/mod_mount_by_label
  inflating: modfs-master/modscripts/mod_night
  inflating: modfs-master/modscripts/mod_prefer_fonnumber_name
  inflating: modfs-master/modscripts/mod_profile
  inflating: modfs-master/modscripts/mod_rc_tail_sh
  inflating: modfs-master/modscripts/mod_show_name
  inflating: modfs-master/modscripts/mod_show_vpn_on_overview
  inflating: modfs-master/modscripts/mod_swapoff
  inflating: modfs-master/modscripts/mod_telnet_enable
  inflating: modfs-master/modscripts/mod_telnet_start
  inflating: modfs-master/modscripts/template
  inflating: modfs-master/modscripts/yourfritz_hooks
finishing deferred symbolic links:
  modfs-master/bin/156   -> Vx180
  modfs-master/bin/175   -> VR9_3.10.73
  modfs-master/bin/185   -> VR9_3.10.73
  modfs-master/bin/192   -> VR9_3.10.73
  modfs-master/bin/193   -> VR9_3.10.73
  modfs-master/bin/203   -> VR9_3.10.73
  modfs-master/bin/212   -> VR9_3.10.73
  modfs-master/bin/213   -> P6ATOM
  modfs-master/bin/218   -> VR9_3.10.73
  modfs-master/bin/220   -> P6ATOM
  modfs-master/bin/221   -> GRX5_3.10.73
  modfs-master/bin/225   -> GRX5_3.10.73
  modfs-master/bin/226   -> GRX5_3.10.73
  modfs-master/bin/GRX5_3.10.73/busybox -> ../common/busybox.34kc.3.10.73
  modfs-master/bin/GRX5_3.10.73/busybox.config -> ../common/busybox.config.34kc.3.10.73
  modfs-master/bin/GRX5_3.10.73/e2fsck -> ../common/e2fsck.34kc.3.10.73
  modfs-master/bin/GRX5_3.10.73/mke2fs -> ../common/mke2fs.34kc.3.10.73
  modfs-master/bin/GRX5_3.10.73/mksquashfs3 -> ../common/mksquashfs3.34kc.3.10.73
  modfs-master/bin/GRX5_3.10.73/mksquashfs4 -> ../common/mksquashfs4.34kc.3.10.73
  modfs-master/bin/GRX5_3.10.73/openssl -> ../common/openssl.34kc.3.10.73
  modfs-master/bin/GRX5_3.10.73/unsquashfs3 -> ../common/unsquashfs.34kc.3.10.73
  modfs-master/bin/GRX5_3.10.73/unsquashfs4 -> ../common/unsquashfs.34kc.3.10.73
  modfs-master/bin/P6ATOM/busybox -> ../common/busybox.x86
  modfs-master/bin/P6ATOM/busybox.config -> ../common/busybox.config.x86
  modfs-master/bin/P6ATOM/e2fsck -> ../common/e2fsck.x86
  modfs-master/bin/P6ATOM/mke2fs -> ../common/mke2fs.x86
  modfs-master/bin/P6ATOM/mksquashfs3 -> ../common/mksquashfs3.x86
  modfs-master/bin/P6ATOM/mksquashfs4 -> ../common/mksquashfs4.x86
  modfs-master/bin/P6ATOM/mksquashfs4-be -> ../common/mksquashfs4-be.x86
  modfs-master/bin/P6ATOM/openssl -> ../common/openssl.x86
  modfs-master/bin/P6ATOM/unsquashfs3 -> ../common/unsquashfs.x86
  modfs-master/bin/P6ATOM/unsquashfs4 -> ../common/unsquashfs.x86
  modfs-master/bin/P6ATOM/unsquashfs4-be -> ../common/unsquashfs4-be.x86
  modfs-master/bin/VR9_3.10.107/busybox -> ../common/busybox.34kc.3.10.107
  modfs-master/bin/VR9_3.10.107/busybox.config -> ../common/busybox.config.34kc.3.10.107
  modfs-master/bin/VR9_3.10.107/e2fsck -> ../common/e2fsck.34kc.3.10.107
  modfs-master/bin/VR9_3.10.107/mke2fs -> ../common/mke2fs.34kc.3.10.107
  modfs-master/bin/VR9_3.10.107/mksquashfs3 -> ../common/mksquashfs3.34kc.3.10.107
  modfs-master/bin/VR9_3.10.107/mksquashfs4 -> ../common/mksquashfs4.34kc.3.10.107
  modfs-master/bin/VR9_3.10.107/openssl -> ../common/openssl.34kc.3.10.107
  modfs-master/bin/VR9_3.10.107/unsquashfs3 -> ../common/unsquashfs.34kc.3.10.107
  modfs-master/bin/VR9_3.10.107/unsquashfs4 -> ../common/unsquashfs.34kc.3.10.107
  modfs-master/bin/VR9_3.10.73/busybox -> ../common/busybox.34kc.3.10.73
  modfs-master/bin/VR9_3.10.73/busybox.config -> ../common/busybox.config.34kc.3.10.73
  modfs-master/bin/VR9_3.10.73/e2fsck -> ../common/e2fsck.34kc.3.10.73
  modfs-master/bin/VR9_3.10.73/mke2fs -> ../common/mke2fs.34kc.3.10.73
  modfs-master/bin/VR9_3.10.73/mksquashfs3 -> ../common/mksquashfs3.34kc.3.10.73
  modfs-master/bin/VR9_3.10.73/mksquashfs4 -> ../common/mksquashfs4.34kc.3.10.73
  modfs-master/bin/VR9_3.10.73/openssl -> ../common/openssl.34kc.3.10.73
  modfs-master/bin/VR9_3.10.73/unsquashfs3 -> ../common/unsquashfs.34kc.3.10.73
  modfs-master/bin/VR9_3.10.73/unsquashfs4 -> ../common/unsquashfs.34kc.3.10.73
  modfs-master/bin/Vx180/busybox -> ../common/busybox.24kc
  modfs-master/bin/Vx180/busybox.config -> ../common/busybox.config.24kc
  modfs-master/bin/Vx180/e2fsck -> ../common/e2fsck.24kc
  modfs-master/bin/Vx180/mke2fs -> ../common/mke2fs.24kc
  modfs-master/bin/Vx180/mksquashfs3 -> ../common/mksquashfs3.24kc
  modfs-master/bin/Vx180/mksquashfs4 -> ../common/mksquashfs4.24kc
  modfs-master/bin/Vx180/openssl -> ../common/openssl.24kc
  modfs-master/bin/Vx180/unsquashfs -> ../common/unsquashfs.24kc
vidar:/tmp $ cd modfs-master/
vidar:/tmp/modfs-master $ l modscripts/
total 132
drwxr-xr-x 1 root root   590 Sep 18 22:32 ./
drwxr-xr-x 1 root root   218 Sep 18 22:32 ../
-rwxr-xr-x 1 root root   664 Sep 18 22:32 copy_binaries*
-rwxr-xr-x 1 root root  1574 Sep 18 22:32 dectcmds.modscript*
-rwxr-xr-x 1 root root  3646 Sep 18 22:32 edit_rcuser*
-rwxr-xr-x 1 root root 36506 Sep 18 22:32 gui_boot_manager_v0.4*
-rwxr-xr-x 1 root root  1392 Sep 18 22:32 mod_custom_images*
-rwxr-xr-x 1 root root  1615 Sep 18 22:32 mod_default_show_mac*
-rwxr-xr-x 1 root root  5916 Sep 18 22:32 mod_leddisplay*
-rwxr-xr-x 1 root root  2191 Sep 18 22:32 mod_mount_by_label*
-rwxr-xr-x 1 root root  2494 Sep 18 22:32 mod_night*
-rwxr-xr-x 1 root root  1732 Sep 18 22:32 mod_prefer_fonnumber_name*
-rwxr-xr-x 1 root root  1272 Sep 18 22:32 mod_profile*
-rwxr-xr-x 1 root root  2223 Sep 18 22:32 mod_rc_tail_sh*
-rwxr-xr-x 1 root root  3197 Sep 18 22:32 mod_show_name*
-rwxr-xr-x 1 root root 12453 Sep 18 22:32 mod_show_vpn_on_overview*
-rwxr-xr-x 1 root root  4262 Sep 18 22:32 mod_swapoff*
-rwxr-xr-x 1 root root  1144 Sep 18 22:32 mod_telnet_enable*
-rwxr-xr-x 1 root root  1270 Sep 18 22:32 mod_telnet_start*
-rwxr-xr-x 1 root root   645 Sep 18 22:32 template*
-rwxr-xr-x 1 root root  5266 Sep 18 22:32 yourfritz_hooks*
vidar:/tmp/modfs-master $ l bin/common/
total 10928
drwxr-xr-x 1 root root     830 Sep 18 22:32 ./
drwxr-xr-x 1 root root     196 Sep 18 22:32 ../
-rw-r--r-- 1 root root      10 Sep 18 22:32 .gitattributes
-rw-r--r-- 1 root root 1237428 Sep 18 22:32 busybox.34kc.3.10.107
-rwxr-xr-x 1 root root 1243624 Sep 18 22:32 busybox.34kc.3.10.73*
-rw-r--r-- 1 root root   27250 Sep 18 22:32 busybox.config.34kc.3.10.107
-rw-r--r-- 1 root root   27393 Sep 18 22:32 busybox.config.34kc.3.10.73
-rw-r--r-- 1 root root  222924 Sep 18 22:32 decoder.34kc.3.10.107
-rwxr-xr-x 1 root root  218532 Sep 18 22:32 decoder.34kc.3.10.73*
-rw-r--r-- 1 root root  487400 Sep 18 22:32 e2fsck.34kc.3.10.107
-rwxr-xr-x 1 root root  466472 Sep 18 22:32 e2fsck.34kc.3.10.73*
-rw-r--r-- 1 root root  375160 Sep 18 22:32 mke2fs.34kc.3.10.107
-rwxr-xr-x 1 root root  354504 Sep 18 22:32 mke2fs.34kc.3.10.73*
-rw-r--r-- 1 root root  376500 Sep 18 22:32 mksquashfs3.34kc.3.10.107
-rwxr-xr-x 1 root root  358516 Sep 18 22:32 mksquashfs3.34kc.3.10.73*
-rw-r--r-- 1 root root  468008 Sep 18 22:32 mksquashfs4.34kc.3.10.107
-rwxr-xr-x 1 root root  448752 Sep 18 22:32 mksquashfs4.34kc.3.10.73*
-rw-r--r-- 1 root root 2016340 Sep 18 22:32 openssl.34kc.3.10.107
-rwxr-xr-x 1 root root 2022364 Sep 18 22:32 openssl.34kc.3.10.73*
-rw-r--r-- 1 root root  405740 Sep 18 22:32 unsquashfs.34kc.3.10.107
-rwxr-xr-x 1 root root  393464 Sep 18 22:32 unsquashfs.34kc.3.10.73*
vidar:/tmp/modfs-master $

Das gibt also keinen Unterschied und da bisher ja noch die Binaries aus "VR9/irgendwas" auf die 3.10.73-Versionen verlinkt sind, stören die fehlenden Execute-Rechte für die 3.10.107-Versionen in der Regel auch nicht.

Bleibt am Ende die Frage, warum die ACLs so "zerwürgt" werden beim Einchecken ... wie gesagt, mit "core.filemode=true" und "core.filemore=false" für das Repo ergibt das immer denselben Quatsch (gestartet von einer btrfs-Partition unter openSuSE Tumbleweed).

Gerade dieses Gemähre beim Auspacken will ich in der Zukunft ja mit einem (signierten) TAR-File umgehen können ... wer den Inhalt auf "Integrität" mit dem Repository checken will (jenseits der Signatur), kann sich das ja mit "tar" dann auspacken und es mit dem Klon des Repos (oder auch dem ausgepackten ZIP-File) vergleichen. Wenn ich die Ursache für die falschen Flags der "modscripts" noch finde, versuche ich das im Git-Repo zu korrigieren ... wenn nicht, sorge ich beim Zusammenpacken und Signieren für die richtigen Flags (das geschieht jetzt auch schon, weil ich - vorsichtshalber - vor dem Einpacken noch einmal ein "chmod a-x" über den Ordner mit den Skripten laufen lasse, damit nicht doch versehentlich eines automatisch ausgeführt wird - auch ohne daß es in der "custom_modscripts" angegeben wäre.

Ich wollte nur keine "custom_modscripts"-Datei mit in das Archiv packen (auch damit kann man ja - wenn die Zeilen alle mit "?" beginnen - die Skripte erst mal auf "fragen" stellen), weil die beim Auspacken dann eine ältere Datei (die schon die "richtige Zusammenstellung" an Skripten hätte, weil der Benutzer sie angepaßt hat) wieder überschreiben würde.

Wer das im Moment selbst aus dem Repo auscheckt, muß beim Einpacken als TAR-File auch auf die richtigen Flags achten ... ich würde ohnehin nicht empfehlen, die "master.zip" von GitHub direkt auf der Box zu entpacken. Beim eigenen Einpacken könnten die Kommandos aus der ".mc.menu" für den Ordner helfen ... da sieht man auch, wie ich die einpacken lasse:

1       Compress the current directory to be published on yourfritz.de
        version=$(cat .version)
        Files="bin files locale modscripts contrib LICENSE BOOTSELECTION* modfs"
        chmod o-x modscripts/*
        busybox tar -c --exclude=".git*" --exclude="contrib/custom" $Files | gzip -c9 > "modfs-$version.tgz"
        cp modfs-$version.tgz /autofs/ssh/source/srv/www/vhosts/www.yourfritz.de/
        opwd=$(pwd)
        cd /autofs/ssh/source/srv/www/vhosts/www.yourfritz.de
        rm modfs.tgz
        ln -s modfs-$version.tgz modfs.tgz
        cd $opwd
        echo "Created (and linked) modfs version $version on yourfritz.de"
        tar tvf modfs-$version.tgz

 

[PeterPawn]

Ein Wort zum neuesten "modscript" mit dem Namen "mod_yourfritz_key" ... das installiert den öffentlichen Schlüssel (siehe YourFritz-Repo), mit dem ich künftig auch die "modfs"-Pakete signieren werde, in einem freien "Slot" in der modifizierten Firmware, vorzugsweise als "global_plugin_key.pem", die ansonsten nur in den Boxen in Benutzung ist, wo AVM selbst Plugins anbietet. Das ist m.W. bei keinem der von "modfs" unterstützten Modelle derzeit der Fall ... also bietet sich dieser Name an.

Ansonsten wird (ausgehend von "avm_firmware_public_key9") nach dem ersten freien Namen mit den Endungen von 9 bis 4 (absteigend) gesucht und der Key dort installiert - findet das "modscript" keinen freien Slot (1 bis 3 werden von AVM selbst verwendet und ignoriert vom "modscript"), schlägt die Modifikation fehl.

Das Skript kann problemlos auch mehrfach angewendet werden ... es prüft zuerst, ob der Key schon vorhanden ist. Wer will, kann das Skript auch noch einmal selbst für einen eigenen Key anpassen, der Modulus steht extra in einer Konstantendefinition am Beginn des Skripts und kann problemlos ausgetauscht werden ... dann auch ans Umbenennen und das Ändern der Beschreibung denken.

Wer sich im Moment eine Firmware baut und später möglichst wenig Aufwand beim nächsten "modfs"-Lauf aus dem neuen System heraus haben will, läßt den Key heute mit einbauen. Damit kann ein Fremder (also ich) immer noch nicht so ohne weiteres "fremde Pakete" installieren lassen, weil er sich dazu schon beim Download als "avm.de" ausgeben müßte (bzw. irgendwie ein Paket auf einen USB-Stick schreiben müßte, das auch noch den passenden Namen für ein vorhandenes DECT-Gerät von AVM hat) - also praktisch DNS-Einträge spoofen müßte. Alles andere (von automatischen Update-Prüfungen bis hin zum manuellen Update per Datei) ist zusätzlich gesichert oder braucht den Zugang zum GUI bzw. einem passenden DECT-Gerät.

Gerade weil das so ohne weiteres auch bei korrekter Signatur nicht möglich ist, einfach ein Paket "zu laden" und über den passenden "tr069fwupdate packet"-Aufruf installieren zu lassen (der Name mit dem "tr069" ist hier nur noch Relikt und mit TR-069 hat das nur insofern zu tun, als Firmware-Updates über TR-069 auch durch diese "Prüfung" der Signatur müssen - hoffentlich auch in jedem Falle und ohne "Abkürzungen"), kommt als nächstes ein Patch für eine zusätzliche Seite, über die man so ein Paket hochladen und installieren lassen kann ... die "Firmware-Update per Datei"-Seite ist dazu nämlich ziemlich ungeeignet, weil bei ihrer Verwendung erst mal das halbe System heruntergefahren wird - schließlich würde darüber ja im Normalfall eine neue Firmware installiert und dann gäbe es ohnehin einen Neustart.

Es gibt zwar mit dem DECT-Update vom USB-Stick auch eine Alternative ohne eine solche Seite, aber das braucht erstens irgendein (Peripherie-)Gerät, was solche Updates auch verwendet, so daß die Box das überhaupt "anschaut" und zweitens ist das schon ziemlich "unbequem", vor allem dann, wenn man mal mehrere solcher Pakete nacheinander (und trotzdem als getrennte Archive, weil man das nicht in ein "großes" packen will) installieren lassen will und dazu ständig auf dem USB-Stick die Datei austauschen muß.

 

[PeterPawn]

Neue Beta mit weiteren Skripten:

• mod_exec_on_nand - ändert das "noexec" für den NAS-Storage in ein "exec", funktioniert auf VR9, GRX5 und Puma6 (da ist der NAS-Speicher halt eMMC mit ext4-Format)
• mod_exec_on_usb - ändert das "noexec" für USB-Volumes mit Linux-Dateisystem auf ein "exec"; bei NTFS (sowohl als "ntfs-3g" als auch als "antfs" in F!OS 7) und FAT sind die Flags ja nur "Emulationen" und werden für alle Dateien auf dem Volume entsprechend gesetzt -> daher ist mir das auf solchen Volumes "zu heiß", wieder "unbesehen" die Ausführung von Dateien (mit x-Flag) zu erlauben
• mod_volatile_nas_dir - diese Modifikation mountet zusätzlich noch ein "tmpfs" in einem Unterverzeichnis des NAS; wozu das gut sein kann, erläutere ich weiter unten

Das eigentliche "modfs"-Skript hat zwei Erweiterungen erhalten, mit denen man die "unbeaufsichtigte Ausführung" theoretisch automatisieren kann. Dazu müssen die "Fragen" im Verlauf der Verarbeitung halt irgendwie vorher beantwortet werden und der Weg der Wahl waren für mich hier Environment-Variablen für die Abfragen von "modfs". Für die Modifikationen gibt es mit der "custom_modscripts" ja schon eine Möglichkeit zur Automatisierung - da hat sich also nichts geändert.

Aber im Verlauf der Abarbeitung erwartet "modfs" normalerweise vom Benutzer eine Entscheidung, wo das Arbeitsverzeichnis angelegt werden soll - das kann man mit der Environment-Variablen "MODFS_WORKING_DIR" jetzt schon vorher auswählen und damit diese Frage überspringen.

Das gilt aber nicht automatisch auch für andere Fragen nach Verzeichnissen, wie sie z.B. bei bestimmten Modifikationen gestellt werden, wenn irgendwelche Download-Files gespeichert werden könnten, sofern der Benutzer das möchte.

Wer das vorbelegt, sollte sich darüber im Klaren sein, daß durchaus nicht wenige Daten dorthin geschrieben werden - das verringert also die Lebensdauer von eingebautem Flash-Speicher oder auch von USB-Sticks, die ja auf denselben Technologien basieren.

Am besten zeigt dieser Name auf eine HDD oder eine SSD am USB-Port. Ach so ... der Wert ist das Verzeichnis, in dem das Volume vom FRITZ!OS gemountet wurde; hier bietet es sich also an, mit "volume labels" beim Mounten zu arbeiten, da ansonsten die Namen der Mountpoints nicht zwingend deterministisch sind, weil es die Reihenfolge der Skript-Aufrufe durch den "udevd" auch nicht ist.

Damit man das auch "durchautomatisieren" kann, gibt es mit der Variablen "MODFS_NO_PAUSE_ON_PACK" (der Wert muß "1" sein) noch die Möglichkeit, den "last exit before Vegas" zu deaktivieren und einfach mit dem Packen zu beginnen.

Es gibt an dieser Stelle keine weitere Gültigkeitsprüfung ... wer Mist in den Variablen angibt, kann einiges anrichten. Also bitte mit der gebotenen Sorgfalt zu Werke gehen und zumindest am Beginn das Ergebnis sehr, sehr genau kontrolllieren. Auch ein neues "modscript", das in der "custom_modscripts" noch nicht enthalten ist und somit "fragt" bei der Ausführung, kann die automatische Ausführung unterbrechen ... es gibt, wie gesagt, keine weitere "Intelligenz" rund um diese neuen Variablen, um irgendwelche Fehler schon im Vorfeld zu entdecken (das übernimmt sonst halt der Code, der nur begrenzte Möglichkeiten zur Auswahl anbietet).

Ich habe mal in das Repository ein Beispiel eingecheckt, wie bei mir ein Wrapper-Skript aussehen würde, damit man das nicht immer "von Hand" beim "modfs"-Aufruf alles festlegen muß ... die Kommentare könnten bei einem eigenen File helfen: https://github.com/PeterPawn/modfs/blob/master/modnow.sh

Noch die versprochenen "Überlegungen", die mich zu "mod_volatile_nas_dir" veranlaßt haben:
Es gibt ja einige Aufgaben, bei denen man ständig irgendwelche Dateien erzeugt, die man aber gar nicht für längere Zeit speichern möchte und für die man trotzdem die NAS-Services der FRITZ!Box benutzen möchte als Möglichkeit des Datenaustauschs zwischen verschiedenen Geräten.

Beispiele wären regelmäßige "Snapshots" von einer Überwachungskamera, die nur bei Alarm gesichert werden (ähnlich wie das "freeze" bei einigen Dashcams mit Beschleunigungssensor) müssen oder irgendwelche "Diagramme" für die aktuelle Auslastung der Box (Up-/Downstream) oder das regelmäßig "exportierte" Event-Log (mit "eventsdump") ... für all diese Fälle kann man unterhalb der NAS-Verzeichnisse (denn nur dort können die NAS-Funktionen des FRITZ!OS als "data exchange" genutzt werden) eigentlich aus zwei Gründen einen flüchtigen Speicher ganz gut gebrauchen: Erstens ist RAM an dieser Stelle deutlich schneller, als irgendein Flash-Speicher oder ein USB-Volume (egal, auf welcher Speichertechnologie das basiert) und zweitens haben solche Speicher häufig eine begrenzte Lebensdauer, was die Anzahl der Schreibzyklen angeht.

Daher macht es (in meinen Augen) Sinn, dort auch noch ein "tmpfs" zu mounten - das ist ein Dateisystem, welches verfügbaren Hauptspeicher zum Speichern der Dateien benutzt und damit aber keine dauerhafte Speicherung ermöglicht. Dort abgelegte Dateien treten natürlich zu anderen RAM-Anforderungen in Konkurrenz und daher sollte man ruhig parallel auch Swap-Space bereitstellen ... aber der wird eben vom System nur bei Bedarf auch genutzt, während ansonsten Dateien ständig auf diesen Speicher geschrieben würden.

Wenn man sich damit trotzdem nicht direkt das System abschießen möchte, kann man den zur Verfügung gestellten Platz auch begrenzen ... für viele Anwendungsfälle (z.B. eine rrd-DB) ist das gar kein Problem.

Um das irgendwie beim Modifizieren der Firmware noch an die eigenen Bedürfnisse anzupassen, kann man wieder Environment-Variablen beim Aufruf von "modfs" verwenden. Das Skript "mod_volatile_nas_dir" versteht die Variable "MOD_VOLATILE_NAS_DIR_DIRNAME", wobei "volatile" als Standard angenommen wird, wenn der Wert nicht gesetzt ist. Das ist dann der Name des Unterverzeichnisses im NAS-Basisverzeichnis, in dem das "tmpfs" gemountet wird. Will man die Größe begrenzen (der Standard ist "unlimited"), kann man die Variable "MOD_VOLATILE_NAS_DIR_LIMIT" auf einen gültigen Wert für die "size"-Option beim Mounten eines "tmpfs" setzen (siehe https://www.kernel.org/doc/Documentation/filesystems/tmpfs.txt). Beide Variablen stehen (deaktiviert) auch als Beispiel in der "modnow.sh", die ich oben verlinkt habe.

 

[PeterPawn]

Heute gibt es zwei neue Modifikationen, wobei die eine nur eine ältere ersetzen soll.

------------------------------------------------------------------------------------------

Die erste (mod_telnet_start_as_dtrace) ersetzt das eigentlich für den D-Kanal-Trace im ISDN (und DECT) vorgesehene "dtrace"-Utility mit einem Wrapper-Skript, welches beim Start des "dtrace" über den Telefon-Code (#97*3*) stattdessen eine "telnetd"-Instanz ins Leben ruft und diese so lange stehen läßt, bis mit "#97*2*" das (vermeintliche) "dtrace" wieder gestoppt wird.

Da dieses Skript den Aufruf über den "telefon"-Daemon (als Folge der Code-Sequenz) an der Reihenfolge der Parameter erkennt, kann der D-Kanal-Trace über die Seite für Paketmitschnitte weiterhin "wie gewohnt" genutzt werden.

Wer möchte, kann da natürlich auch ein anderes Programm als den "telnetd" starten lassen ... am Ende war die Idee, die nicht mehr funktionierende "#96*7*"-Folge (das Ausschalten mit "#97*8*" ist anscheinend noch implementiert) zu ersetzen. Da der "telnetd" aber vom "telefon"-Daemon gar nicht mehr gestartet wird (egal, was in der "fx_conf" eingetragen ist), habe ich nach einer (verzichtbaren) Telefonsequenz gesucht (die Verwendung des Telefons ist mir deshalb so "sympathisch", weil es wieder einen weiteren "Zugriffspfad" zur Box braucht, um den Telnet-Daemon zu starten) und bin auf die oben erwähnte gekommen.

Das Ersetzen ist etwas aufwändiger ... zunächst wird das originale Binär-File umbenannt (damit man es später erreichen kann) und dann ein Shell-Skript mit dem folgenden Inhalt an seine Stelle gesetzt:

#! /bin/sh
if [ "$1" = "-D" ] && [ "$2" = "-dect" ]; then
        if [ -z "$(pidof telnetd)" ]; then
                eventadd 1 "Telnet daemon started by dtrace start sequence from phone"
                /usr/sbin/telnetd -l /sbin/ar7login -F &
                telnetd=$!
                trap "kill $telnetd" KILL HUP TERM
                wait $telnetd
                eventadd 1 "Telnet daemon terminated"
        fi
        exit
fi
cp -a "/usr/bin/dtrace.bin" /var/tmp/dtrace
exec /var/tmp/dtrace $*

Bei der typischen Reihenfolge der Parameter eines Aufrufs aus "telefon" heraus, wird eine Nachricht ins Event-Log geschrieben und ein Telnet-Daemon als Vordergrund-Prozess gestartet, der aber wieder in den Hintergrund "geschoben" wird, damit man auf sein Ende warten kann. Gleichzeitig wird für das Shell-Skript eine Behandlung von SIGKILL (+ SIGHUP und SIGTERM) installiert, die den gestarteten Telnet-Daemon abschießt und das Skript wartet dann auf das Ende dieses Prozesses. Damit hat der "telefon"-Daemon nach dem Start-Versuch den erwarteten Kindsprozess und wenn er beim Stoppen mittels "pidof dtrace" nach dem abzubrechenden Prozess sucht, wird er auch fündig. Beim Beenden des Telnet-Daemons wird das auch noch im Event-Log protokolliert - Ordnung muß sein und außerdem sieht der Besitzer so, wann jemand den Service gestartet hat.

Anders als die alte Code-Sequenz startet der "telefon"-Daemon das "dtrace" ja nicht automatisch in Abhängigkeit von einem Flag in der "fx_conf". Wer also trotz aller Warnungen auf einem automatisch gestarteten und dauerhaft aktiven Telnet-Zugang beharren möchte, der muß das vorhergehende Skript "mod_telnet_start" wieder aktivieren ... das wurde von mir mit der Bereitstellung der hier beschriebenen Variante deaktiviert und muß erst wieder mit dem "x"-Flag für die Gruppe zur "Abfrage" freigegeben werden.

Wenn das Ganze von der "capture.lua" aus aufgerufen wird (über das CGI-Programm "capture_notimeout"), wird die bei der Modifikation gesicherte Datei wieder als "dtrace" in ein temporäres Verzeichnis kopiert und dort aufgerufen. Auf diesem Weg wird auch wieder sichergestellt, daß ein "pidof dtrace" eine passende PID finden kann ... die Möglichkeit, das beim "exec"-Aufruf direkt mittels "-a name" zu ändern, kommt leider erst jenseits der BusyBox 1.27.2 hinzu und anders als bei Freetz, kann ich hier nicht darauf bauen, daß im modifizierten System eine solche BusyBox installiert ist. Daher muß dieses "Umbenennen" (bis auf weiteres) erfolgen, weil das GUI in der "capture.lua" auf der Existenz eines solchen Prozesses beharrt, solange der nach seiner Ansicht "gestartet" ist.

------------------------------------------------------------------------------------------

Das zweite Skript reaktiviert das alte "calllog"-Skript bei eingehenden Anrufen ... es gibt zwar den Call-Monitor und der signalisiert auch ausgehende Anrufe (iirc), aber erstens kann da jeder im LAN zugreifen und die "Metadaten" aller Anrufe abgreifen und zweitens erfolgt m.W. dort keine automatische Suche im Telefonbuch (lange nicht mehr getestet - irgendwo hatten wir mal das Thema, wie man das alte "calllog"-Skript ersetzen könnte, als AVM es "abgeschafft" hatte).

Ich hatte ja vor einiger Zeit mal ermittelt, daß AVM die Datei "/var/flash/calllog" tatsächlich noch ausführt bei eingehenden Anrufen ... allerdings nur dann, wenn es sich um eine "private" Version der Firmware handelt, was i.d.R. durch die Environment-Variable "CONFIG_RELEASE=0" signalisiert wird. Ist diese Variable vorhanden, wird das Skript aufgerufen ... also liegt ja nichts näher als dafür zu sorgen, daß dem "telefon"-Daemon (der für diesen Aufruf verantwortlich zeichnet) deutlich mitgeteilt wird (und nur ihm und nicht dem Rest der Firmware), daß es sich um eine solche private Version handelt.

Der Start des "telefon"-Daemons erfolgt aus der "/etc/init.d/rc.voip" heraus und letzten Endes macht diese Modifikation nichts anderes, als dem Aufruf von "telefon" noch die Festlegung dieser Variablen voranzustellen. Ich habe bisher noch keine negativen Auswirkungen bemerkt und habe das inzwischen wieder in Benutzung, seitdem ich es "wiederentdeckt" hatte (wann das war, steht bestimmt irgendwo hier im IPPF).

Das Skript "/var/flash/calllog" wird ja sogar mit in die Export-Datei eingebaut von AVM ... und auch beim Import war es bis vor kurzem noch dabei (hat sich sicherlich auch nicht geändert). Die Modifikation befüllt diese Datei NICHT ... das ist also anders als bei der "debug.cfg" (oder "rc.user"), wo wenigstens ein Protokoll-Kommando eingebaut wird, wenn die Datei leer ist. Hier ist der "Verwender" dafür verantwortlich, daß in der Datei der gewünschte Inhalt landet ... wer das per Shell-Zugriff macht, muß die Regeln für TFFS-Nodes beachten (nur "character oriented I/O" verwenden).

Der große Vorteil des "Nachschlagens" im Telefonbuch ermöglicht es auch hier (so man es möchte), einen Start irgendwelcher Dienste anhand eines eingehenden Anrufs ausführen zu lassen ... wer sich z.B. die eigene Handy-Nummer unter einem passenden Namen in das Telefonbuch einbaut und im Skript auf diesen Namen testet, kann sich auch durch den Anruf eine Shell starten lassen (die damit auch nicht dauerhaft aktiv sein muß) und zwar auf einem Weg, den (ohne großen Aufwand, der es dann wieder einfacher machen würde, wenn man das FRITZ!OS "direkt" angreift) kein Anderer ohne weiteres angreifen kann.

Im einfachsten Falle schreibt man sich beim Erstellen des eigenen Skript-Files erst mal ein

eventadd 1 "calllog: $*"

in die Datei, damit man Format und Reihenfolge der Parameter beim Aufruf erkunden kann.