[Sammlung] Fragen, Probleme, Lösungen zum Thema "modfs-Starter"

Auf meiner FB 7490 wurde vor etwa 1 Monat modfs-Starter injektion fs4 installiert, da ist keine busybox 1.23.2 sondern definitiv 1.21.1 .
Das will ich mal nicht hoffen, dann hätte jemand Dir eine andere Datei als die von mir bereitgestellte untergeschoben. Dort ist bereits seit Mitte Dez. 2015 die Version 1.23.2 der Busybox enthalten - in beiden Archiven (sowohl für SquashFS 3 als auch 4).

KingTutt schrieb:
aber wenn ich das richtig verstehe, wird da einerseits nur der Kernel kopiert (und nicht das Filesystem) und andererseits frage ich mich, ob das Kopieren nach mtd1 für NAND-Boxen überhaupt noch zutreffend ist?
1. Bei den NOR-Boxen wird zwar nur ein einzelnes File geschrieben, das ist aber die Kombination aus Kernel und SquashFS-Image. Das Zerpflücken in die passenden MTD-Partitionen übernimmt dann ein Scanner im Kernel, der sich anhand der Signatur eines SquashFS-Images den richtigen Beginn im Flash sucht.

2. Das ist bei den NAND-Boxen genau richtig verstanden, wobei es wohl keine Möglichkeit gibt, direkt aus der EVA heraus die NAND-Partitionen zu beschreiben. Genau deshalb macht es ja das AVM-Recovery-Programm (so jedenfalls meine Interpretation) auf diesem Weg.


-Um das umzusetzen, braucht es einen aktuellen Kernel (den kriegt man aus jedem Firmware-Image) und ein dazu passendes SquashFS-Image. Ob das bei einer Version ab 06.50 ein - mit dem Dummy-Header von 256 Byte als SquashFS maskiertes - ext2-Filesystem ist oder ob dabei der Header entfernt werden muß/kann, kann man ja mal mit dem AVM-Recovery-Programm vergleichen, das habe ich seit dem Erscheinen von 06.50 auch noch nicht geprüft. Der Scan-Code im Kernel legt die Vermutung nahe, daß auch das FS 1:1 aus einem Image verwendet werden könnte.

Ansonsten nimmt man halt das Filesystem-Image und entpackt es, ändert die dort enthaltenen Kommandos so ab, wie man es braucht, packt es wieder ordentlich zusammen (inkl. Dummy-Header, wenn nötig) und kopiert es hinter den Kernel in eine Datei. Entweder man entfernt mittels der Tools aus der Freetz-Toolchain oder mittels "dd" die Prüfsumme am Ende des Kernels (die letzten 8 Byte, wie wir später noch sehen werden).

Dann berechnet man ein paar Adressen und überträgt sein neues Image über die EVA in die Box ... so simpel läßt sich das zusammenfassen - aber wir gehen das einmal in einzelnen Schritten durch.

Eine 7490 hat normalerweise 256 MB Hauptspeicher, das sind hexadezimal 0x10000000 Byte (sieben Nullen) ... dieser beginnt an der Adresse 0x800000000 (die drei höchstwertigen Bits geben bei einer MIPS-Architektur den "address space" an, hier arbeiten wir mit "kseg0", was dem physikalischen Hauptspeicher entspricht -> unmapped and cached) und geht bis 0x8FFFFFFF (bzw. 0x90000000, wo eigentlich schon nichts mehr liegt oder was das erste Byte nach dem Hauptspeicher ist).

Damit das System uns jetzt nicht den eigenen Kernel und das Dateisystem überschreibt, verringern wir die Größe des Hauptspeichers entsprechend, am ersten damit "ausgeblendeten Byte" wird dann unsere "Datei" mit Kernel und Dateisystem "gespeichert". Wir nehmen uns also mal ein originales Firmware-Image für die 06.30 (der Einfachheit halber, dann müssen wir uns gar nicht über den Dummy-Header ab Kernel 3.10.73 den Kopf zerbrechen) und entpacken das:
Code:
# mkdir /var/unpack
# tar -C /var/unpack -xf FRITZ.Box_7490.113.06.30.image
# cd /var/unpack/
# find . -name *.image -exec stat -c "%n %s" '{}' \;
./var/tmp/kernel.image [COLOR="#008000"]1961992[/COLOR]
./var/tmp/filesystem.image 21917704
Wir haben also 1961992 Byte Kernel (0x1DF008) und 21917704 Byte Dateisystem (0x14E7008). Die "krummen" Werte kommen natürlich von den Prüfsummen, vom Kernel entfernen wir diese erst einmal sofort:
Code:
# dd if=var/tmp/kernel.image of=kernel.image bs=256 count=$(( 0x1df0 ))
7664+0 records in
7664+0 records out
1961984 bytes (1.9MB) copied, 0.107276 seconds, 17.4MB/s
# stat -c %s kernel.image
[COLOR="#008000"]1961984[/COLOR]
Das Kopieren mit "dd" machen wir in 256-Byte-Blöcken, weil wir dann direkt die hexadezimale Größenangabe (um zwei Stellen am Ende gekürzt, denn 0x100 is eben genau 256) beim Kopieren angeben können und uns weitere Umrechnungen auf diesem Weg ersparen.

So, jetzt haben wir 1961984 Byte Kernel (0x1DF000 - eine schöne "gerade" Größe) und irgendein originales Dateisystem - schön zu wissen, aber wenn wir schon mal so weit sind, können wir auch gleich das Dateisystem passend ändern.

Also entpacken wir es erst einmal:
Code:
# unsquashfs3 var/tmp/filesystem.image
Filesystem on var/tmp/filesystem.image is ZLIB compressed (3:0)
Parallel unsquashfs: Using 2 processors
184 inodes (525 blocks) to write

[==================================================\] 525/525 100%
created 7 files
created 11 directories
created 91 symlinks
created 86 devices
created 0 fifos
# unsquashfs3 -d root squashfs-root/filesystem_core.squashfs var.tar
Filesystem on squashfs-root/filesystem_core.squashfs is ZLIB compressed (3:0)
Parallel unsquashfs: Using 2 processors
1 inodes (1 blocks) to write

[==================================================|] 1/1 100%
created 1 files
created 1 directories
created 0 symlinks
created 0 devices
created 0 fifos
# mv root/var.tar squashfs-root
# rm -r root
Das "unsquashfs3" muß man sich natürlich passend erstellen (und ggf. auch das für Version 4 verwenden, wenn man einen 3er-Kernel nutzt) ... für die Box selbst wäre eines im "modfs"-Archiv enthalten. Für eine x86-Umgebung könnte am ehesten Freetz direkt passend übersetzte Binaries bereitstellen, aber das wird wohl nichts werden bzw. steht auf der Prioritätenliste so weit unten, daß man eher nicht darauf warten sollte. Also einfach einmal die Tools passend übersetzen (man muß ja dafür auch kein komplettes "make" machen) und die Resultate bei den SquashFS-Utilities sichern. Dabei könnte man dann auch gleich noch das "tichksum" für das Berechnen/Entfernen der Prüfsummen sichern, aber solange es nur um das Entfernen geht, reicht das oben gezeigte "dd" aus und es verringert die "Abhängigkeiten".
EDIT 25.07.2016: Ich habe vor einiger Zeit mal dem YourFritz-Repository ein "bin"-Verzeichnis hinzugefügt, in dem die Utilities auch für x64/x86 liegen (zusammen mit einer Signaturdatei, damit man sich von der Authentizität der Binärdateien überzeugen kann) - allerdings nur für die SquashFS-Version 4; hier müßte man also als Basis für das eigene Image dann auf eine Firmware-Version >= 06.50 bei AVM zurückgreifen. Da es gar nicht mehr so einfach ist, eine Version 06.30-Firmware irgendwo aufzutreiben, sehe ich das nicht als entscheidenden Nachteil.

Jedenfalls haben wir jetzt den ausgepackten Inhalt der "wrapper"-Partition vor uns:
Code:
# find squashfs-root/ -type f -exec ls -l '{}' \;
-rw-r-----    1 root     root         30720 Jul 15  2015 squashfs-root/var.tar
-rw-r-----    1 root     root             0 Jul 15  2015 squashfs-root/tmp/mtab
-rwxr-x--x    1 root     root          6470 Jul 15  2015 squashfs-root/sbin/flash_update
-rwxrwxrwx    1 root     root        686304 Jul 15  2015 squashfs-root/lib/libuClibc-0.9.33.2.so
-rwxrwxrwx    1 root     root         31600 Jul 15  2015 squashfs-root/lib/ld-uClibc-0.9.33.2.so
-rw-r-----    1 root     root      21389312 Jul 15  2015 squashfs-root/filesystem_core.squashfs
-rw-r-----    1 root     root           361 Jul 15  2015 squashfs-root/etc/inittab
-rwxr-x---    1 root     root        449244 Jul 15  2015 squashfs-root/bin/busybox
# rm -r var
Wie man sehen kann, besteht dieses Dateisystem wirklich nur aus einigen wenigen Dateien ... im Prinzip bloß einer Busybox und den dort nicht statisch gelinkten Bibliotheken, der "inittab" und dem - aus der "inittab" aufgerufenen - Skript /sbin/flash_update, was den ganzen Kram aus dem Hauptspeicher in die NAND-Partitionen schreibt, wenn es feststellt, daß das System aus dem RAM gestartet wurde. Das "eigentliche" Dateisystem ist in der "filesystem_core.squashfs" untergebracht. Zusätzlich gibt es noch einige Symlinks für die Busybox-Applets ... komischerweise fehlt aber der Symlink für "reboot" bei AVM, was wir später kompensieren müssen. Schon die "var.tar" haben wir uns ja oben extra noch aus dem Root-Dateisystem extrahieren müssen, wir brauchen deren Inhalt später noch.

Schauen wir uns das "flash_update"-Skript von AVM einmal etwas genauer an, so finden wir am Beginn nur ein paar Zuweisungen von "Standard-Variablen" und ein paar Funktionen, die einmal eine Zeile aus /proc/mtd zerlegen und ein paar Meldungen ausgeben, die ohnehin nur jemand mit einer seriellen Konsole sehen würde. Danach wird es aber interessanter:
Code:
[...]
kernel_ram=`grep kernel_ram /proc/mtd`
rootfs_ram=`grep rootfs_ram /proc/mtd`

if [ -z ${kernel_ram_size} ]; then
    exit 0
fi

get_mtd_size kernel_ram_size ${kernel_ram}
get_mtd_size rootfs_ram_size ${rootfs_ram}

if [ $((0x${kernel_ram_size})) -gt $((0x1000)) ]; then
    if [ ${kernel_ram_size} == ${rootfs_ram_size} ]; then
        exit 0
    fi
else
    exit 0
fi
[...]
Hier wird also erst eimal geprüft, ob das System im RAM läuft ... der Scan-Code im Kernel kennzeichnet dann die entsprechenden Partitionen mit einem "_ram"-Suffix in der MTD-Struktur, auf die man über /proc/mtd zugreifen kann. Nur wenn sich für diese Partitionen gültige Größen ermitteln lassen (was bei einem aus dem NAND gestarteten System nicht mehr der Fall ist), wird das Skript überhaupt weiter ausgeführt, ansonsten endet es hier abrupt.

Im weiteren Verlauf geht das Skript dann hin und kopiert den Inhalt der beiden RAM-Partitionen in das NAND-Flash ... aber das wollen wir ja eigentlich gar nicht. Uns würde es ja vollkommen reichen, wenn das Skript an dieser Stelle einfach unsere "wrapper"-Partition mounten und unsere Änderungen an deren Inhalt umsetzen würde.

Da wir außerdem "wissen", daß unser Skript nicht ebenfalls in die yaffs2-Partition kopiert und damit bei jedem Start erneut abgearbeitet wird, können wir uns auch die ganzen Tests sparen, die AVM dort vornimmt. Ein Skript für unsere Zwecke könnte z.B. in etwa so aussehen:
Code:
#! /bin/sh
#=========================================================================
#
# which file has to be copied to the yaffs2 partition
#
#=========================================================================
image="${1:-/filesystem_\$CUSTOM.squashfs}"
#=========================================================================
#
# modify active (a) or inactive (i) partition
#
#=========================================================================
modify_system=${2:-a}
#=========================================================================
#
# check for free space before copying the image to the target partition
# this should be set to 0, if we overwrite an existing file there, which
# is a little bit larger
#
#=========================================================================
check_space=${3:-1}
#=========================================================================
#
# some defaults
#
#=========================================================================
TMP="/var"
URLADER_ENV="/proc/sys/urlader/environment"
SYSTEM_SELECTOR="linux_fs_start"
FS_PARTITION="filesystem"
INACTIVE_PREFIX="reserved-"
MTDBLOCK="/dev/mtdblock"
MOUNTFS="$TMP/yaffs2"
INSTALL="sbin/flash_update"
REBOOT="/bin/busybox reboot"
WRAPPER="/wrapper"
ROOTFS="filesystem_core.squashfs"
CUSTOM="custom"
TARGETFILE="filesystem_$CUSTOM.squashfs"
#=========================================================================
#
# some helper functions
#
#=========================================================================
# dismount the yaffs2 partition securely
dismount()
{
	[ $mounted -eq 1 ] && umount $MOUNTFS || mount -o remount,ro $MOUNTFS
}
# detect SquashFS version used in the target system to distinguish between
# kernel versions
detect_version()
{
	[ "$(dd if=$MOUNTFS/$ROOTFS of=/proc/self/fd/1 count=2 bs=1 skip=28 2>/dev/null)" == $'\x04' ] && echo 3 || echo 2
}
# install extension handling for kernel versions 2.6.32
install_kernel_2()
{
	cat >$MOUNTFS/$INSTALL <<ENDOFSCRIPT
#! /bin/sh
#
# version for kernel 2.6.32 - AVM firmware < 06.50 (/dev not bind mounted)
#
# start a detached shell to execute the $CUSTOM script, we've to exit here
# to let the init process continue
#
/usr/bin/nohup /bin/sh -x $WRAPPER/start_$CUSTOM.sh >$WRAPPER/dev/null 2>&1 &
exit 0
ENDOFSCRIPT
	cat >$MOUNTFS/start_$CUSTOM.sh <<ENDOFSTART
#! /bin/sh
#
# let the OS settle a bit
#
sleep 5
#
# wait until tmpfs is mounted on /var
#
while true; do
        grep -q "^tmpfs /var tmpfs" /proc/mounts 2>/dev/null && break
        sleep 2
done
#
# check for "uninstall" request
# wait until start has finished in this case, we'll use the running "run_clock"
# as "decision helper"
#
if [ -f $WRAPPER/remove_$CUSTOM.flag ]; then
        while true; do
                pidof run_clock >/dev/null 2>&1 && break
        done
        cat >/var/remove_$CUSTOM.sh <<EOI
mount -o remount,rw $WRAPPER
rm $WRAPPER/remove_$CUSTOM.flag
rm $WRAPPER/remove_$CUSTOM.sh
rm $WRAPPER/start_$CUSTOM.sh
rm $WRAPPER/filesystem_$CUSTOM.squashfs
echo "exit 0" >$WRAPPER/$INSTALL
sync
mount -o remount,ro $WRAPPER
exit 0
EOI
    	nohup sh -x /var/remove_$CUSTOM.sh >/var/tmp/remove_$CUSTOM.out 2>&1 &
        exit 0
fi
#
# mount our additional SquashFS image to /var/$CUSTOM
#
mkdir -p /var/$CUSTOM
mount -t squashfs $WRAPPER/$TARGETFILE /var/$CUSTOM
grep -q "^/dev/loop[0-9] /var/$CUSTOM squashfs" /proc/mounts || exit 1
#
# wait until lan device was started
#
while true; do
        ifconfig lan 2>/dev/null | grep -q ".*UP.*RUNNING.*" && break
        sleep 2
done
#
# start the init script (etc/init.d/rc.$CUSTOM) of the mounted extension
#
nohup sh -x /var/$CUSTOM/etc/init.d/rc.$CUSTOM >/var/tmp/rc.$CUSTOM.log 2>&1 &
ENDOFSTART
	cat >$MOUNTFS/remove_$CUSTOM.sh <<ENDOFREMOVE
mount -o remount,rw $WRAPPER
touch $WRAPPER/remove_$CUSTOM.flag
sync
echo "The $CUSTOM extension will be removed during next restart."
exit 0
ENDOFREMOVE
	chmod u+x $MOUNTFS/start_$CUSTOM.sh $MOUNTFS/remove_$CUSTOM.sh $MOUNTFS/sbin/flash_update
}
# install extension handling for kernel versions 3.10++
install_kernel_3()
{
	cat >$MOUNTFS/$INSTALL <<ENDOFSCRIPT
#! /bin/sh
#
# version for kernel 3.10.73 - AVM firmware 06.50+ (assumption only)
#
# create a shell script to be called from a detached shell
# only /dev is writable here, it's very early after kernel was loaded
#
cat >/dev/delayed_start.sh <<'EOT'
#
# let the OS settle a bit
#
sleep 5
#
# wait until tmpfs is mounted on /var
#
while true; do
				grep -q "^tmpfs /var tmpfs" /proc/mounts 2>/dev/null && break
        sleep 2
done
#
# check for "uninstall" request
# wait until start has finished in this case, we'll use the running "run_clock"
# as "decision helper"
#
if [ -f $WRAPPER/remove_$CUSTOM.flag ]; then
        while true; do
                pidof run_clock >/dev/null 2>&1 && break
        done
        mount -o remount,rw $WRAPPER
        rm $WRAPPER/remove_$CUSTOM.flag
        rm $WRAPPER/remove_$CUSTOM.sh
        rm $WRAPPER/filesystem_$CUSTOM.squashfs
        echo "exit 0" >$WRAPPER/sbin/flash_update
        sync
        mount -o remount,ro $WRAPPER
        exit 0                                                                                                                                                                                                                              ]
fi
#
# mount our additional SquashFS image to /var/$custom
#
mkdir -p /var/$CUSTOM
mount -t squashfs $WRAPPER/$TARGETFILE /var/$CUSTOM
grep -q "^/dev/loop[0-9] /var/$CUSTOM squashfs" /proc/mounts || exit 1
#
# wait until lan device was started
#
while true; do
        ifconfig lan 2>/dev/null | grep -q ".*UP.*RUNNING.*" && break
        sleep 2
done
#
# start the init script (etc/init.d/rc.$CUSTOM) of the mounted extension
#
nohup sh -x /var/$CUSTOM/etc/init.d/rc.$CUSTOM >/var/tmp/rc.$CUSTOM.log 2>&1 &
EOT
#
# start a detached shell to execute the created script, we've to exit here
# to let the init process continue
#
nohup sh -x /dev/delayed_start.sh >/dev/delayed_start.out 2>&1 &
exit 0
ENDOFSCRIPT
	cat >$MOUNTFS/remove_$CUSTOM.sh <<ENDOFREMOVE
mount -o remount,rw $WRAPPER
touch $WRAPPER/remove_$CUSTOM.flag
sync
echo "The $CUSTOM extension will be removed during next restart."
exit 0
ENDOFREMOVE
	chmod u+x $MOUNTFS/remove_$CUSTOM.sh
}
#=========================================================================
#
# first we have to mount some things
#
#=========================================================================
# the procfs may be mounted multiple times without error, so we
# can do this without any further checks
mount -t proc proc /proc 2>/dev/null
#=========================================================================
#
# let's try to log to the "config" partition, if needed ... uncomment the
# following lines to enable debug output and don't forget to create the
# base directory "/log"
#
#=========================================================================
#log=$(sed -n -e "s/mtd\([0-9]\{1,2\}\):.*\"config\"\$/\1/p" /proc/mtd)
#mount -t yaffs2 $MTDBLOCK$log /log
#exec 2>/log/update_yaffs2.log
#set -x
#=========================================================================
#
# if tmpfs isn't mounted yet, we're running from memory loaded system
#
#=========================================================================
if ! grep -q "tmpfs $TMP" /proc/mounts; then
	mount -t tmpfs tmpfs $TMP
	tar xf /var.tar
	if ! grep -q "devtmpfs .*/dev" /proc/mounts; then
		tar cf $TMP/dev.tar /dev
		mount -t tmpfs tmpfs /dev
		tar xf $TMP/dev.tar
		rm $TMP/dev.tar
	fi
	mount -t sysfs sysfs /sys
else
	REBOOT="exit 1"
fi
#=========================================================================
#
# we check the image to be written first, if it's missing, there's
# nothing to do for us
#
#=========================================================================
eval image=$(echo $image)
filesize=$(stat -c "%s" $image)
[ ${#filesize} -eq 0 ] && $REBOOT # usually our image is missing
#=========================================================================
#
# now we've to select the right partition, where we should write into
#
#=========================================================================
current=$(sed -n -e "s/^$SYSTEM_SELECTOR\t\([01]\)\$/\1/p" $URLADER_ENV)
[ ${#current} -eq 0 ] && $REBOOT # missing or invalid selector value
[ $modify_system == a -o $modify_system == i ] || $REBOOT # invalid value
[ $modify_system == a ] && prefix="" || prefix="$INACTIVE_PREFIX"
mtd=$(sed -n -e "s/mtd\([0-9]\{1,2\}\):.*\"$prefix$FS_PARTITION\"\$/\1/p" /proc/mtd)
[ ${#mtd} -eq 0 ] && $REBOOT # filesystem partition not found
#=========================================================================
#
# now let's mount the partition somewhere, from this point on we will
# unmount the filesystem before we reboot the device
#
#=========================================================================
mounted=0
if [ $modify_system == a ] && [ "$REBOOT" == "exit 1" ]; then # running system
	MOUNTFS=$WRAPPER
	mount -o remount,rw $MOUNTFS || $REBOOT
else
	mkdir -p $MOUNTFS
	mount -t yaffs2 $MTDBLOCK$mtd $MOUNTFS || $REBOOT # do or die
	mounted=1
fi
error_occured=0
#=========================================================================
#
# we could check the available space here, but it will be useless, if
# we're overwriting an existing file
#
#=========================================================================
if [ $check_space -eq 1 ]; then
	freeblocks=$(df $MOUNTFS | grep $MOUNTFS | sed -n -e "s_^[^ ]*[ \t]*[0-9]*[ \t]*[0-9]*[ \t]*\([0-9]*\).*_\1_p")
	if [ ${#freeblocks} -ne 0 ]; then
		freesize=$(( freeblocks * 1024 ))
		if [ $freesize -le $filesize ]; then
			error_occured=1 # image too large
		fi
	else
		error_occured=1 # unexpected output of "df"
	fi
fi
[ $error_occured -ne 0 ] && dismount $MOUNTFS
[ $error_occured -ne 0 ] && $REBOOT
#=========================================================================
#
# now we can copy the image file to the partition
#
#=========================================================================
cp -a $image $MOUNTFS/$TARGETFILE
[ $? -ne 0 ] && error_occured=1 # error during copy operation
[ $error_occured -ne 0 ] && dismount $MOUNTFS
[ $error_occured -ne 0 ] && $REBOOT
#=========================================================================
#
# now we'll prepare the startup of own extensions, if necessary
#
#=========================================================================
version=$(detect_version)
if [ $version == 3 ]; then
	install_kernel_3
else
	install_kernel_2
fi
#=========================================================================
#
# now we'll unmount the yaffs2 partition and reboot the device
#
#=========================================================================
sync
dismount $MOUNTFS
$REBOOT
#=========================================================================
#
# end of script
#
#=========================================================================
Das o.a. Skript gibt es auch unter der URL http://yourfritz.de/update_yaffs2 oder unter https://github.com/PeterPawn/YourFritz/blob/master/update_yaffs2/update_yaffs2 als Download.

Das gezeigte Skript schreibt in der o.a. Form die Datei "filesystem_custom.squashfs" aus dem Start-Dateisystem in die aktive yaffs2-Partition und prüft vorher, ob der dort noch freie Speicherplatz dafür ausreicht. Dasselbe Skript kann auch verwendet werden, um aus einer "normalen Shell" heraus die notwendigen Dateien in die yaffs2-Partition zu kopieren und parallel dazu gleich noch den Aufruf dieser Erweiterungen beim Start des Systems zu organisieren. Diese Version entscheidet anhand der Version des SquashFS für die "filesystem_core.squashfs" in der Zielpartition darüber, ob der Weg zum Starten der Erweiterung bei einem 2.6.32-Kernel oder bei einem 3.10.73-Kernel benötigt wird.

Jetzt müssen wir also nur unser neues Dateisystem entsprechend präparieren, wir nehmen als "custom image file" mal die SquashFS4-Version von "modfs-Starter" her - weil das "Zielsystem" eine 113.06.51 ist, obwohl unser "in-memory image" mit einer 113.06.30 erstellt wird:
Code:
# wget -O - http://yourfritz.de/inject_shellinabox_vr9_nand_sqfs4.tar | tar -x -O ./var/tmp/filesystem.image >squashfs-root/filesystem_custom.squashfs
Connecting to yourfritz.de (85.214.20.177:80)
-                    100% |***********|   527k  0:00:00 ETA
Im Anschluß schreiben wir unsere neue "Initialisierungsdatei" und passen die "etc/inittab" entsprechend an, denn wir wollen die Kommandos vor "flash_update" ja nicht ausführen. Also schreiben wir die "inittab" einfach gleich komplett neu und löschen die "flash_update" von AVM, damit die uns nicht irgendwann doch noch auf die Füße fällt und auch das "root-Filesystem", denn das nimmt nur unnötigen Platz weg:
Code:
# wget -O squashfs-root/update_yaffs2 http://yourfritz.de/update_yaffs2
Connecting to yourfritz.de (85.214.20.177:80)
update_yaffs2        100% |***********| 10979   0:00:00 ETA
# chmod a+x squashfs-root/update_yaffs2
# echo -e "null::sysinit:/bin/sh /update_yaffs2\nnull::shutdown:/bin/busybox umount /var/yaffs2\nnull::shutdown:/bin/busybox umount /log" >squashfs-root/etc/inittab
# rm squashfs-root/sbin/flash_update squashfs-root/filesystem_core.squashfs squashfs-root/etc/mtab
# mkdir squashfs-root/log squashfs-root/sys
# ln -s /var/tmp/mtab squashfs-root/etc/mtab
Dann müssen wir jetzt nur noch die resultierende Verzeichnisstruktur wieder in ein SquashFS-Dateisystem verwandeln, damit der Kernel damit etwas anfangen kann - nicht vergessen, daß das hier verwendete Format zum "in-memory kernel" passen muß, nicht zum Zielsystem:
Code:
# mksquashfs3 squashfs-root/ filesystem.image
Parallel mksquashfs: Using 2 processors
Creating big endian 3.1 filesystem on filesystem.image, block size 65536.
[===================================|] 30/30 100%
Exportable Big endian filesystem, data block size 65536, compressed data, compressed metadata, compressed fragments, duplicates are removed
Filesystem size 1134.25 Kbytes (1.11 Mbytes)
        67.63% of uncompressed filesystem size (1677.09 Kbytes)
Inode table size 1241 bytes (1.21 Kbytes)
        26.47% of uncompressed inode table size (4688 bytes)
Directory table size 1660 bytes (1.62 Kbytes)
        70.31% of uncompressed directory table size (2361 bytes)
Number of duplicate files found 1
Number of inodes 195
Number of files 7
Number of fragments 1
Number of symbolic links  91
Number of device nodes 86
Number of fifo nodes 0
Number of socket nodes 0
Number of directories 11
Number of uids 1
        root (0)
Number of gids 0
Nun haben wir also einen Kernel und ein Dateisystem:
Code:
# stat -c "%n %s" *.image
filesystem.image 1167360
kernel.image 1961984
Kurze Kontrolle der Größe des Dateisystems ... 1167360 ist auch hexadezimal eine "runde" Zahl: 0x11D000 - also sieht das auch gut aus. Das SquashFS-Image ist in unserem Falle immer ein Vielfaches von 64 KByte groß (das ist die Blockgröße des Images). Bullshit ... die Blockgröße gilt nur innerhalb der Daten des Images, die Verwaltungsstrukturen werden nur in der benötigten Größe gespeichert - aber die Größe ist trotzdem in Ordnung, damit unser resultierendes Image an einer vernünftigen Boundary im Speicher landet.

Nun fügen wir den Kernel und das Dateisystem zusammen:
Code:
# cat kernel.image filesystem.image >memory.image
# stat -c %s memory.image
3129344
Unsere neue Datei für den Upload im Bootloader ist also 3129344 Byte groß, das sind in hex dann 0x2FC000. Wir hatten 0x10000000 als Hauptspeichergröße, die verringert sich jetzt um 0x2FC000 auf 0xFD04000 - den Wert merken wir uns.

Zunächst einmal kopieren wir jetzt unsere neue Datei an eine Stelle, wo wir sie später noch erreichen können und dann überlegen wir uns, wie so eine FTP-Session am Ende aussehen müßte.
Code:
220 ADAM2 FTP Server ready
USER adam2
331 Password required for adam2
PASS adam2
230 User adam2 successfully logged in
SYST
215 AVM EVA Version 1.1964 0x0 0x740D
TYPE I
200 Type set to BINARY
MEDIA SDRAM
200 Media set to MEDIA_SDRAM
SETENV memsize 0x0fd04000
200 SETENV command successful
SETENV kernel_args_tmp mtdram1=0x8fd04000,0x90000000
200 SETENV command successful
TYPE I
200 Type set to BINARY
MEDIA SDRAM
200 Media set to MEDIA_SDRAM
P@SW
227 Entering Passive Mode (192,168,178,1,12,13)
STOR 0x8fd04000 0x90000000
150 Opening BINARY data connection
226 Transfer complete
So sollte/würde eine FTP-Session zur EVA aussehen, wenn wir unser oben erstelltes Image in den Speicher übertragen wollen. Das Problem hierbei ist das "STOR"-Kommando, welches das "richtige" Server-Kommando ist, das sich hinter einem FTP-Kommando "put" auf der Client-Seite "versteckt". Nun kann zwar jeder bessere FTP-Client sogar automatisch anhand des "P@SW"-Kommandos (oder auch "PASV") den richtigen Port ermitteln und sogar die in einem "put"-Kommando angegebene Datei automatisch richtig übertragen, aber der kennt eben die "serverseitige" Form des hier benötigten "STOR"-Kommandos nicht, der würde nur ein "STOR dateiname_auf_dem_server" daraus machen.

Also müssen wir uns unseren eigenen "FTP-Client" basteln, alles was wir dazu unter einem Linux-System benötigen, sind die Kommandos "mkfifo", "nc" und eine nicht zu einfache Shell, selbst die "ash" aus der Busybox sollte ausreichen.

Ein entsprechendes Shell-Skript sähe z.B. so aus:
Code:
#! /bin/sh
#
# file to transfer to the router
#
filename="$1"
#
# some constants to be changed, if needed
#
box_ip=192.168.178.1
box_port=21
box_user=adam2
box_pass=adam2
passive_ftp="P@SW"
[ ${#TMP} -eq 0 ] && TMP=/tmp
tmpdir=$TMP/tmp_$(date +%s)_$$
writefifo=$tmpdir/write
readfifo=$tmpdir/read
storefifo=$tmpdir/store
outstream=7
instream=8
upstream=9
logstream=3
logfile=$0.log
envfile=$tmpdir/env
startaddress=0x80000000
#
# helper functions
#
read_ftp_response()
{
	local line="   -" rc=0 instream="$1" log="$2"
	while read -u $instream -r line; do
		[ ! -z "$log" ] && echo "$line" >&$log
		[ "${line:3:1}" != "-" ] && break
	done
	rc=$?
	echo "$line"
	return $rc
}
write_ftp_command()
{
	local outstream="$2" cmd="$1" log="$3"
	[ ! -z "$log" ] && echo "$cmd" >&$log
	echo "$cmd" >&$outstream
}
login_to_box()
{
	local instream="$1" outstream="$2" log="$3" lines=0
	write_ftp_command "USER $box_user" $outstream $log
	while [ $lines -lt 10 ]; do
		line="$(read_ftp_response $instream $log)"
		ec=${line:0:3}
		if [ x$ec == x331 ]; then
			write_ftp_command "PASS $box_pass" $outstream $log
		else
			if [ x$ec == x230 ]; then
				return 0
			fi
		fi
		lines=$(( lines++ ))
	done
}
get_environment()
{
	local instream="$1" outstream="$2" log="$3" lines=0
	write_ftp_command "TYPE I" $outstream $log
	line="$(read_ftp_response $instream $log)"
	ec=${line:0:3}
	if [ x$ec != x200 ]; then
		return 1
	fi
	write_ftp_command "MEDIA SDRAM" $outstream $log
	line="$(read_ftp_response $instream $log)"
	ec=${line:0:3}
	if [ x$ec != x200 ]; then
		return 1
	fi
	write_ftp_command "$passive_ftp" $outstream $log
	line="$(read_ftp_response $instream $log)"
	ec=${line:0:3}
	if [ x$ec == x227 ]; then
		data_conn=$(echo $line | sed -n -e 's/.*(\([0-9]*\),\([0-9]*\),\([0-9]*\),\([0-9]*\),\([0-9]*\),\([0-9]*\)).*/data_ip=\1.\2.\3.\4 data_port=\$(( \5 * 256 + \6 ))/p')
		if [ ${#data_conn} -eq 0 ]; then
			return 1
		fi
		eval "$data_conn"
		nc -d -w 60 $data_ip $data_port >$envfile &
		data_connection=$!
		sleep 1
		write_ftp_command "RETR env" $outstream $log
		line="$(read_ftp_response $instream $log)"
		ec=${line:0:3}
		if [ x$ec == x150 ]; then
			line="$(read_ftp_response $instream $log)"
			ec=${line:0:3}
			if [ x$ec == x226 ]; then
				if [ -d /proc/$data_connection ]; then
					kill $data_connection 2>/dev/null &
					wait $data_connection 2>/dev/null
				fi
				data_connection=""
				echo $envfile
				return 0
			fi
		else
			return 1
		fi
	else
		return 1
	fi
}
upload_image()
{
	local instream="$1" outstream="$2" log="$3" file="$4" memsize="$5" startaddr="$6" endaddr="$7"
	eval "exec $upstream<>$storefifo"
	if [ $? -ne 0 ]; then
		return 1
	fi
	write_ftp_command "SETENV memsize $memsize" $outstream $logstream
	line="$(read_ftp_response $instream $log)"
	ec=${line:0:3}
	if [ x$ec != x200 ]; then
		eval "exec $upstream>&-"
		rm $storefifo
		return 1
	fi
	write_ftp_command "SETENV kernel_args_tmp mtdram1=$startaddr,$endaddr" $outstream $logstream
	line="$(read_ftp_response $instream $log)"
	ec=${line:0:3}
	if [ x$ec != x200 ]; then
		eval "exec $upstream>&-"
		rm $storefifo
		return 1
	fi
	write_ftp_command "TYPE I" $outstream $log
	line="$(read_ftp_response $instream $log)"
	ec=${line:0:3}
	if [ x$ec != x200 ]; then
		eval "exec $upstream>&-"
		rm $storefifo
		return 1
	fi
	write_ftp_command "MEDIA SDRAM" $outstream $log
	line="$(read_ftp_response $instream $log)"
	ec=${line:0:3}
	if [ x$ec != x200 ]; then
		eval "exec $upstream>&-"
		rm $storefifo
		return 1
	fi
	write_ftp_command "$passive_ftp" $outstream $log
	line="$(read_ftp_response $instream $log)"
	ec=${line:0:3}
	if [ x$ec == x227 ]; then
		data_conn=$(echo $line | sed -n -e 's/.*(\([0-9]*\),\([0-9]*\),\([0-9]*\),\([0-9]*\),\([0-9]*\),\([0-9]*\)).*/data_ip=\1.\2.\3.\4 data_port=\$(( \5 * 256 + \6 ))/p')
		if [ ${#data_conn} -eq 0 ]; then
			eval "exec $upstream>&-"
			return 1
		fi
		eval "$data_conn"
		nc -w 3 $data_ip $data_port <&$upstream 2>/dev/null 1>&2 &
		data_connection=$!
		sleep 1
		write_ftp_command "STOR $startaddr $endaddr" $outstream $logstream
		line="$(read_ftp_response $instream $log)"
		ec=${line:0:3}
		if [ x$ec == x150 ]; then
			cat $file >$storefifo
			line="$(read_ftp_response $instream $log)"
			ec=${line:0:3}
			if [ x$ec == x226 ]; then
				if [ -d /proc/$data_connection ]; then
					kill $data_connection 2>/dev/null &
					wait $data_connection 2>/dev/null
				fi
				data_connection=""
				eval "exec $upstream>&-"
				rm $storefifo
				return 0
			fi
			eval "exec $upstream>&-"
			rm $storefifo
			return 1
		else
			eval "exec $upstream>&-"
			rm $storefifo
			return 1
		fi
	else
		eval "exec $upstream>&-"
		rm $storefifo
		return 1
	fi
}
#
# check file size
#
if [ x$filename == x ]; then
	echo "Missing file name."
	exit 1
fi
filesize=$(stat -c %s $filename)
if [ $? -ne 0 ]; then
	echo "Missing file '$filename'"
	exit 1
fi
#
# check, if "mkfifo" and "nc" are present and usable
#
mkfifo 2>/dev/null
if [ $? -eq 127 ]; then
	echo "Missing usable 'mkfifo' command."
	exit 1
fi
nc 2>/dev/null
if [ $? -eq 127 ]; then
	echo "Missing usable 'nc' command."
	exit 1
fi
#
# build redirections for FTP with "nc"
#
mkdir -p $tmpdir
mkfifo $writefifo
rc=$?
if [ $rc -ne 0 ]; then
	echo "Error $rc creating write fifo $writefifo."
	rm -r $tmpdir
	exit 1
fi
mkfifo $readfifo
rc=$?
if [ $rc -ne 0 ]; then
	echo "Error $rc creating read fifo $readfifo."
	rm $writefifo
	rm -r $tmpdir
	exit 1
fi
mkfifo $storefifo
rc=$?
if [ $rc -ne 0 ]; then
	echo "Error $rc creating upload fifo $storefifo."
	rm $writefifo
	rm $readfifo
	rm -r $tmpdir
	exit 1
fi
eval "exec $outstream<>$writefifo"
rc=$?
if [ $rc -ne 0 ]; then
	echo "Error $rc connecting write fifo to output stream."
	rm $writefifo
	rm $readfifo
	rm $storefifo
	rm -r $tmpdir
	exit 1
fi
eval "exec $instream<>$readfifo"
rc=$?
if [ $rc -ne 0 ]; then
	echo "Error $rc connecting read fifo to input stream."
	eval "exec $outstream>&-"
	rm $writefifo
	rm $readfifo
	rm $storefifo
	rm -r $tmpdir
	exit 1
fi
eval "exec $logstream<>$logfile"
rc=$?
if [ $rc -ne 0 ]; then
	echo "Error $rc connecting log stream to log file."
	eval "exec $instream>&-"
	eval "exec $outstream>&-"
	rm $writefifo
	rm $readfifo
	rm $storefifo
	rm -r $tmpdir
	exit 1
fi
#
# now open a connection to the box
#
nc $box_ip $box_port <&$outstream >&$instream 2>/dev/null &
control_connection=$!
data_connection=""
line="$(read_ftp_response $instream $logstream)"
ec=${line:0:3}
if [ x$ec == x220 ]; then
	login_to_box $instream $outstream $logstream
	if [ $? -eq 0 ]; then
		write_ftp_command "SYST" $outstream $logstream
		line="$(read_ftp_response $instream $logstream)"
		ec=${line:0:3}
		if [ x$ec == x215 ]; then
			syst=$(echo "$line" | sed -n -e "s/.*\(AVM EVA\).*/\1/p")
			if [ ${#syst} -ne 0 ]; then
				echo "Found AVM bootloader: ${line:4}"
				environment=$(get_environment $instream $outstream $logstream)
				if [ $? -eq 0 ]; then
					hwrev=$(sed -n -e "s/^HWRevision *\(.*\)\r\$/\1/p" $environment)
					echo "Found hardware revision: $hwrev"
					memsize=$(sed -n -e "s/^memsize *\(.*\)\r\$/\1/p" $environment)
					echo "Memory size is $memsize $(printf "(%u MB)" $(( $memsize / 1024 / 1024 )))"
					echo "Image size is $(printf "0x%06x" $filesize) $(printf "(%u MB)" $(( filesize / 1024 / 1024 )))"
					setmemsize=$(printf "0x%08x" $(( memsize - filesize )))
					echo "Setting temporary memory size to: $setmemsize"
					imagestartaddr=$(printf "0x%08x" $(( startaddress + setmemsize )))
					imageendaddr=$(printf "0x%08x" $(( startaddress + memsize )))
					echo "Setting temporary kernel args to: mtdram1=$imagestartaddr,$imageendaddr"
					upload_image $instream $outstream $logstream $filename $setmemsize $imagestartaddr $imageendaddr
					if [ $? -eq 0 ]; then
						echo "Image uploaded to device."
					fi
				fi
			else
				echo "Unexpected system found: ${line:4}"
			fi
		fi
	else
		echo "Login failed."
	fi
else
	echo "Error connecting to FRITZ!Box boot loader."
fi
if [ ${#data_connection} -ne 0 ]; then
	if [ -d /proc/$data_connection ]; then
		kill $data_connection 2>/dev/null &
		wait $data_connection 2>/dev/null
	fi
fi
if [ ${#control_connection} -ne 0 ]; then
	if [ -d /proc/$control_connection ]; then
		kill $control_connection 2>/dev/null &
		wait $control_connection 2>/dev/null
	fi
fi
eval "exec $logstream>&-"
eval "exec $instream>&-"
eval "exec $outstream>&-"
rm $writefifo
rm $readfifo
rm -r $tmpdir
exit 1
Das gibt es auch zum Download unter der URL https://github.com/PeterPawn/YourFritz/blob/master/eva_tools/eva_to_memory ... erspart einem das mühsame Abtippen.

Das Skript wird mit dem Namen der zu verwendenden Image-Datei als Parameter aufgerufen und berechnet dann die Werte anhand von "memsize" und der Image-Größe gleich selbst, das spart Vorarbeiten. Allerdings erwartet es eine FRITZ!Box, die sich bereits im FTP-Modus des Bootloaders befindet. Das erreicht man z.B. durch die Verwendung eines falschen Recovery-Programms ... das hat dann keine andere Aufgabe, als die Box in diesen Modus zu bringen.

Das hilft zwar dem "nur Windows"-Benutzer noch nicht weiter, aber das gezeigte Skript sollte auf fast jedem beliebigen Linux-Host (von der STB bis zum RasPi) laufen können ... das ist ja auch schon etwas. Unter Windows baut man sich dann halt mit der PowerShell und dem NetClient der .NET-Library ein passendes Skript zusammen ... wobei ich auch niemanden von der Benutzung des ruKernelTools abhalten will, wenn dieses auch mit solchen Images umgehen können sollte (was ich nicht testen werde).

BTW ... das, was ich oben in einzelnen Schritten und Kommandos erläutert habe, kann man natürlich ebenfalls automatisieren, damit man diese Kommandos nicht jedesmal von Hand ausführen muß. Allerdings braucht es (normalerweise) diesen ganzen Aufwand auch nur ein einziges Mal, denn man hat dann ja ein Grundgerüst für die Modifikation der Box und muß nur noch jeweils die "Nutzlast" (also die Datei "filesystem_custom.squashfs") darin ersetzen, bevor man das SquashFS wieder zusammenpackt und hinter den Kernel kopiert ... das Ergebnis ist dann ja wieder die auf die Box zu ladende Datei. Die ganzen anderen Arbeiten zur Vorbereitung fallen nur einmalig an.
 
Zuletzt bearbeitet:
@koy... Herzlichen Dank für die Codes.

Bezüglich
...die busybox nach /var/tmp kopieren, und gleich in /var/tmp/bin installieren mit...Code: mkdir /var/tmp/bin && /var/tmp/busybox --install -s /var/tmp/bin
müsste das, wegen runtergeladener binary (busybox-mips), nicht heissen
mkdir /var/tmp/bin && /var/tmp/busybox-mips --install -s /var/tmp/bin ? (sorry wegen der Fragerei, bin jedoch ziemlich neu bim modifizieren einer FB, meiner ersten...).

Bezüglich dem vorangehenden code, ist das Path setzen klar, aber wozu dient das "PSl=$(echo -e ... ? Und das Setzen von "alias ls ..." ist das grad nur eine Erleichterung um Argument -AFp und Farbe zu setzen ?

Wäre das dann so, dass die neu installierte busybox weiter unter /var/tmp/bin laufen würde (auch nach reboot) ? Oder wird nach reboot die vorher vorhandene busybox erneuert/updated zur höheren Version ?


@PeterPawn - habe die fs4 nochmals von deiner Seite runtergeladen und auf die FB eingespielt - wird jetzt tatsächlich 1.23.2 angezeigt, DANKE (Versions-Konfusion geklärt...).
 
Zuletzt bearbeitet:
Wollte das sh Script mal laufen lassen (unter der URL http://yourfritz.de/update_yaffs2 ), bekomme aber direkt die nachfolgende Meldung (grundsätzlich klar, weil die filesystem_custom.squashfs sich im Ordner /wrapper befindet). Es erfolgte bei laufendem System.
# sh update_yaffs2
stat: can't stat '/filesystem_custom.squashfs': No such file or directory
 
stat: can't stat '/filesystem_custom.squashfs': No such file or directory
Ja, genau für diesen Anwendungsfall sind die drei möglichen Werte dann natürlich als Parameter anzugeben. Der erste ist der "Ursprungsname" des SquashFS-Images, der zweite eben "a" oder "i" für das Zielsystem und der dritte (0 oder 1) gibt an, ob vorher der noch freie Platz in der Partition geprüft werden soll.

Ich dachte eigentlich, das ginge aus den Kommentaren im Shell-Skript hervor, daß da bis zu drei Parameter angegeben werden können und - bei entsprechender Umgebung beim Aufruf - eben auch müssen. Daß ein Aufruf ohne die Absicht, eine andere "filesystem_custom.squashfs" zu schreiben, eigentlich sinnlos ist, brauche ich sicherlich nicht zu erwähnen ... es ging bei dieser (erweiterten) Form der "Installation" in die yaffs2-Partition eher darum, sowohl das Schreiben in die aktive Partition zu unterstützen als auch in die inaktive.

Die Eignung für "dual use" (einmal aus einem gestarteten "in-memory image" heraus und einmal aus einer Shell auf der Box) ist auch nur ein Nebeneffekt, nachdem ich die bisher von mir verwendeten Skriptdateien zu einer einzelnen für die Veröffentlichung zusammengefaßt habe, um zu viel Wildwuchs zu vermeiden.

In der derzeitigen Form ist das zumindest mal geeignet, eine "frische" Installation vorzunehmen. Beim Ersetzen einer vorhandenen SquashFS-Datei im aktiven System, die zudem noch aktuell in Benutzung ist, ist das aber in dieser Form auch nicht zu verwenden, weil dafür die gerade benutzte Datei erst einmal umbenannt werden müßte (dabei sollte sich die Inode-Nummer nicht ändern und die aktuell gemountete Image-Datei bleibt verwendbar) und dann erst die neue Datei geschrieben werden könnte. Das erfordert aber auch noch weitere Sicherheitsvorkehrungen (u.a. muß der Platz für die alte und die neue Datei parallel vorhanden sein) und ist "nicht Gegenstand dieses Skriptes".

Für mich selbst habe ich das auch noch in etwas erweiterter Form, bei der die verwendete Zeichenkette für "custom" anhand eines Kernel-Parameters in "kernel_args" gesetzt wird und man damit durch diesen Parameter zwischen verschiedenen "custom images" auswählen kann. Eines dieser Images enthält auch bei mir nur eine "ShellInABox"-Installation in minimaler Größe und wird dazu verwendet, u.a. das oben beschriebene Dilemma zu lösen - solange die "aktive Erweiterung" dieses kleine SIAB-Image ist, kann man jede andere Erweiterungsdatei auch problemlos ersetzen/überschreiben, wobei man sich dann ggf. selbst einen Gefallen tut, wenn man entweder vorher von Hand alte Image-Dateien löscht oder die Prüfung auf freien Platz in der Partition abschaltet (dafür ist die optional gestaltet), weil mir das "Ausrechnen" des benötigten Platzes anhand von aktuell freiem und durch eine ältere Version belegten Platzes zuviel Aufwand im Skript war/ist und das für "Leser" ja nicht gerade nachvollziehbarer wird.

Da so ein zusätzlicher Parameter in "kernel_args" sowohl aus einem beliebigen laufenden System heraus gesetzt werden kann (das Urlader-Environment teilen sich ja die beiden denkbaren Systeme in der Box) als auch aus dem Bootloader heraus, kann man auf diesem Weg eigentlich jederzeit auswählen, was die Box beim nächsten Start als Erweiterung laden soll. Bisher habe ich halt einzelne Images verwendet (siehe auch die "yourfritz"-Modifikationen im Rahmen von modfs und die bisher veröffentlichten Teile von "YourFritz" als Framework) - künftig ist es wohl doch sinnvoller, ein neues SquashFS-Image mit allen installierten Erweiterungen zu erzeugen und nur dieses eine Image dann zu mounten.
 
@PeterPan
Ich hoffe ich habe es nirgends überlesen: Gibt es die Dateien aus dem SquashFS 4-Image irgendwo auf dem GitHub Account zum download oder habe ich auf einem nativen Linux System irgend eine Möglichkeit, mir den Inhalt aus dem Image zu extrahieren? Wenn ich mich richtig erinnere, kann das normale Linux mount -t squashfs nicht mit dem AVM Kram umgehen..

Ich würde mir gerne Dein binary von shell in a box einfach in ein AVM Image .51 mit einpacken und starten lassen, damit ich spätere modifizierte FW Updates auch ohne dem Umweg über EVA mit SIAB einspielen kann. Wenn ich Deine Ausführungen hier richtig verstanden habe, müsste man doch ein FW Update auch einfach von der Shell aus anstoßen können? Zwar wird man nicht einfach das /va/install script aus dem AVM Image nehmen können (da ist ja der Konsistenz Check der Datei eingebaut) aber etwas leicht abgewandeltes müsste es doch machen? :confused:
 
Gibt es die Dateien aus dem SquashFS 4-Image irgendwo auf dem GitHub Account zum download
Nein.

KingTutt schrieb:
oder habe ich auf einem nativen Linux System irgend eine Möglichkeit, mir den Inhalt aus dem Image zu extrahieren?
Ja.

KingTutt schrieb:
Wenn ich mich richtig erinnere, kann das normale Linux mount -t squashfs nicht mit dem AVM Kram umgehen.
Richtig. Aber es gibt entweder Freetz zum Bauen eines eigenen "unsquashfs4" - inzwischen braucht es ja dafür auch keine gesonderten Patches mehr - oder Du nimmst einfach die x86-Form der Binaries von http://yourfritz.de/7490/x86/squashfs-tools.tar.xz ... die enthaltenen Dateinamen (eine Liste gibt es nicht auf dem Server, auch kein automatisches Indexing) wären:

unsquashfs3
mksquashfs3
unsquashfs4-be
mksquashfs4-be

und diese sollten auch nicht mit einem event. vorhandenen "unsquashfs" (für SquashFS4-LE) und "mksquashfs" aus dern "offiziellen" SquashFS-Tools kollidieren. Ob ich die schon früher irgendwo verlinkt hatte, weiß ich nicht genau ... ich übernehme auch keinerlei Garantie für solche Binaries (auch wenn die da natürlich deshalb liegen, weil ich die auch selbst regelmäßig benutze und sie dann von dort lade). Die Dateien gibt es jeweils auch einzeln, wenn man den Namen der Archivdatei gegen den Dateinamen tauscht. Die liblzma.a ist statisch gelinkt, die Binaries brauchen nur die libz.so und ansonsten eben ganz normale "C libraries" (libc.so, libpthread.so, libm.so), die auf jedem halbwegs "normalen" System ohnehin vorhanden sein sollten. Eine komplett statisch gelinkte Variante habe ich auch nicht ... bisher ist mir noch kein x86-Linux untergekommen, das mit den Binaries nicht klarkam.

KingTutt schrieb:
aber etwas leicht abgewandeltes müsste es doch machen?
Logisch ... die Frage ist nur, was man alles bei so einem Update machen will/muß.

Am Ende macht "modfs" ja auch nichts anderes ... man könnte sogar noch darüber nachdenken, in "modfs" das Entpacken/Modifizieren/Einpacken einfach optional wegzulassen und nur die richtigen Daten an die richtige Stelle zu übertragen, die Funktionen sind ja ohnehin schon vorhanden.

Wobei ich im Moment auch etwas verwirrt bin ... ob der Quelle so einer "modifizierten Firmware" für die Installation. Wenn das mit Freetz passiert und Freetz ist auf der Box vorhanden, kann so ein Update auch nach wie vor über Freetz eingespielt werden und wenn es mit "modfs" erfolgt, dann kann ja auch gleich "modfs" die Installation übernehmen.

Nur bei einem extern modifizierten Image (was dann bei einem x86-Host ja wieder die o.a. x86-Binaries bräuchte) könnte sich also so eine Frage überhaupt nur stellen ... das irritiert mich schon etwas, weil ich den "use case" gerade nicht so richtig sehe.

Außer Du willst die SIAB-Installation immer anstelle von Telnet (oder auch parallel) in Deine Box einbauen lassen, dann verstehe ich das wieder - aber der Zusammenhang zur "Installationsfrage" bleibt dann wieder unklar.

Bei der Übernahme von SIAB in binärer Form aber auch die andere(n) Datei(en) im enthaltenen SquashFS-Image nicht vergessen (die libprivatekeypassword.so), sonst kann SIAB mit dem Zertifikat im FRITZ!OS nichts anfangen.
 
Nur bei einem extern modifizierten Image (was dann bei einem x86-Host ja wieder die o.a. x86-Binaries bräuchte) könnte sich also so eine Frage überhaupt nur stellen ... das irritiert mich schon etwas, weil ich den "use case" gerade nicht so richtig sehe.
Ich habe mir die original AVM Firmware immer mit der Freetz Tools entpackt, gepatched und wieder zusammengepackt. Da KDG mir die Zugangsdaten für VoIP nicht rausgerückt hat und AVM es nicht zuläßt, KDG SIP Accounts zu löschen, habe ich mir diese Option in der GUI freigepatched und dann die FW (ohne Freetz) wieder aufgespielt. Mit der .51 fällt die Option meine eigene FW per GUI aufzuspielen und ich hätte gerne etwas eleganteres, als immer per EVA ran zu müssen.
Außer Du willst die SIAB-Installation immer anstelle von Telnet (oder auch parallel) in Deine Box einbauen lassen, dann verstehe ich das wieder - aber der Zusammenhang zur "Installationsfrage" bleibt dann wieder unklar.
Sicherlich könnte ich beim Patchen auch Telnet wieder aktivieren, aber da das nicht so sicher ist, dachte ich mit, SIAB wäre eine gute Alternative. Ich würde mir quasi SIAB immer dazu packen, um auch beim nächsten Update meine eigene FW aufspielen zu können.
Bei der Übernahme von SIAB in binärer Form aber auch die andere(n) Datei(en) im enthaltenen SquashFS-Image nicht vergessen (die libprivatekeypassword.so), sonst kann SIAB mit dem Zertifikat im FRITZ!OS nichts anfangen.
Das hätte ich gemacht (aber Danke noch einmal für den ausdrücklichen Hinweis) und versucht, mir eine eigene rc.custom in /etc/init.d/ an zu legen, in der Hoffnung, dass das gesamte Verzeichnis beim Systemstart abgearbeitet wird. Allerdings ist mir halt noch nicht ganz klar, wie ich mit SIAB dann so ein eigenes Image installieren müsste...
Vermutlich könnte ich das mit einem der Scripte machen (update_xxx) aber so weit bin ich halt noch nicht gekommen das nach zu vollziehen :)
 
versucht, mir eine eigene rc.custom in /etc/init.d/ an zu legen, in der Hoffnung, dass das gesamte Verzeichnis beim Systemstart abgearbeitet wird.
Das ist eine gute Idee, aber der Dateiname wäre der falsche ... wirf mal einen Blick in die rc.S in /etc/init.d einer AVM-Firmware.
 
Danke für den Hinweis. es wird dann wohl auf etwas all "E47-siab" hinauslaufen wenn ich das richtig verstanden hab. Und zum Updaten meiner angepassten FW könnte ich in der Tat dann Dein modfs mit dem Parameter update nehmen und ihm einfach mein Image als Input geben. Wenn das modfs update immer in die inaktive partition installiert, könnte man im Anschluss sogar noch mit Deinem switch_system zum vorhergehenden Image zurück kehren...
 
1. "modfs" kennt sogar einen Aufruf mit "modfs undo", bei dem eine Umschaltung des Systems wieder rückgängig gemacht wird.

2. Derzeit würde "modfs" aber das (Firmware-)Image immer noch auspacken und dann auch das dort enthaltene Wurzeldateisystem entpacken zum Modifizieren. Das wäre bei einem bereits modifizierten Root-FS absolut unnötig (und dauert auch lange), da könntest Du ja dann auch in Erwägung ziehen, das gleich komplett mit "modfs" zu machen und die Änderungen, die Du ansonsten über die Freetz-Toolchain vornimmst, gleich in ein "modscript" zu verpacken oder auf irgendeinem anderen Weg in der Pause vor dem Packen (genau dafür wird die ja eingelegt) umzusetzen. Zwar ist der zeitliche Aufwand dafür ggf. etwas höher wegen des schwächeren Prozessors (ein kompletter Lauf mit der 06.51 dauert bei mir aber unter 10 Minuten, das Einpacken braucht am längsten und die Zeit dürfte mehr von der Anbindung des verwendeten Speichers beeinflußt werden als vom Prozessor, denn das ist überwiegend ein VR9 und m.W. gibt es keine Modelle mit einem deaktivierten Kern), aber dafür braucht man keine VM (oder eine gesonderte Installation) für Freetz ... solange man nicht auch auf dem Desktop unter Linux arbeitet, ist das zumindest weniger Arbeit.

3. Ob ich "modfs" noch einen "install"-Modus für fremde Images beibringe, weiß ich noch nicht so richtig ... angesichts der AVM-Änderungen wäre das sogar eine Überlegung wert. Solange Du den Kernel nicht ersetzen mußt (was nur bei einem Versionswechsel der Fall sein sollte, ich habe irgendwann sogar mal festgestellt, daß die VR9-Kernel über mehrere Modelle identisch waren ... offenbar baut AVM die auch nicht jedesmal neu), reicht sogar die Verwendung von https://github.com/PeterPawn/YourFritz/blob/master/update_yaffs2/install_inactive_rootfs aus, um nur das Root-Dateisystem auszutauschen, denn die anderen Dateien im yaffs2 (ist ja nur noch ein Busybox mit zwei Libraries und die /sbin/flash_update als Shell-Skript) laufen ja unabhängig vom FRITZ!OS und müssen nicht einmal zwangsläufig zum Root-FS passen, solange der Kernel damit klarkommt. Das hat dann auch noch den Vorteil, daß man ein "Update" machen kann, ohne den Rest des yaffs2-Inhalts (z.B. ein "custom image" a la SIAB als "modfs-Starter") dabei zu verlieren, was bei der Verwendung des AVM-Skripts /var/install immer der Fall ist (auch der Freetz-Installationsprozess startet ja dieses Skript). Zwar hat so eine "saubere Installation" auch ihre Vorteile, aber in einigen Szenarien ist das auch nachteilig.
 
Ich wollte nicht mehr antworten, da das in dem Thread nichts zu suchen hat. Aber unkommentiert kann ich es auch nicht stehen lassen.

@reallhacker:
Danke für die Aufklärung - ich habe tatsächlich "gelernt", daß es einen neuen Branch 0.7 gibt.
Schoen wenn ich helfen konnte!

Das ist nett, aber für mich trotzdem vollkommen uninteressant.

Warum?

Wie Dir vielleicht entgangen ist, brauche ich das gar nicht selbst - insofern bellst Du bei mir den falschen Baum an.
Sorry, ich belle gar niemanden an und dich schon gar nicht!

Eine Empfehlung an andere für ein "closed source"-Programm, das - ob zurecht oder nicht, interessiert dabei gar nicht - bei AV-Lösungen die Alarmglocken klingeln läßt, kann ich trotzdem nicht mit meinen Ansichten vereinbaren, egal was Du dazu denken magst.
Das sei dir unbenommen!

Das ist auch nicht vollkommen neu für r@iner, insofern brauchst Du da gar nicht "in die Bresche springen" ...
Ich weiss nicht wo deine Ton jetzt herkommt, aber dass es Fehlalarme gibt ist nun wirklich nichts neues. Beim ruKernelTool ist das so lange der Fall wie es das Programm gibt. Darauf hat R@iner von Anfang an hingewiesen:
http://rukerneltool.rainerullrich.de/#viren
http://rukerneltool.rainerullrich.de/FAQ.html#1.36
http://blog.nirsoft.net/2009/05/17/antivirus-companies-cause-a-big-headache-to-small-developers/

und ich bin bei "open source" durchaus in der Lage (und mache das meistens auch, z.B. beim FBEditor), mir ein eigenes Bild vom "Innenleben" der Software zu machen. Das genau geht beim ruKernelTool nicht und insofern ist das nicht nur persönliche Ansichtssache, wie man zu so einem Programm steht (ich mache die Leute sogar darauf aufmerksam, daß sie den von mir veröffentlichten Sachen mißtrauen sollen und lieber selbst noch einmal nachsehen sollten - wie soll das da erst bei CS von anderen aussehen?) ... wenn man es durch andere Lösungen ersetzen kann, braucht es das schlicht nicht, schon gar nicht mit den damit einhergehenden Einschränkungen.
Dann darfst Du keinen PC benutzen, denn dort ist das Bios schon closed source. Weiter geht es mit Windows als OS.

Schon das von Dir ebenfalls verlinkte Changelog zeigt nämlich sehr deutlich, warum das eben nicht die Lösung sein kann ... die derzeit aktuelle Version (0.7.0.4 vom 07.02.2016) funktioniert noch genau bis morgen abend (09.02.2016 23:00 Uhr).
Du hast anscheinen nicht alles gelesen. Das ruKernelToolX ist noch nicht oeffentlich verfuegbar, daher ist das kein Argument. Aber auch das ruKernelTool hat ein Ablaufdatum, was mich anfangs auch stoerte, heute finde ich seine Loesung gut durchdacht und ich arbeite immer mit der letzten Programmversion:
http://rukerneltool.rainerullrich.de/FAQ.html#1.36

Wenn mir ein Programm genau dann, wenn ich es dringend brauchen würde, den Dienst wegen so einer ablaufenden Zeit verweigert (und ich mir bei womöglich nicht funktionierendem Router dann erst auf irgendwelchen anderen Wegen eine neue Version davon besorgen muß), dann ist das einfach keine Lösung, die ich akzeptieren kann und die ich jemand anderem empfehlen würde. Da kannst Du gar nichts gegen machen ... jede andere "Lösung" kann man sich "auf Vorrat" hinlegen und bei Bedarf darauf zurückgreifen.
Dann hole ich mir aktuell das Programm und gut ist.

BTW ... woher Du die Aussage

nimmst, scheitert bei mir schon an dem Verständnis, woher Du wissen willst, daß es sich tatsächlich um einen Fehlalarm handelt. Das ist eben genau das "closed source"-Problem. Wenn Du zu den Leuten gehörst, die bei solchen Alarmmeldungen auch schon mal auf "trotzdem verwenden" gehen, wenn es denn nur dringend genug ist, hätte ich da noch die eine oder andere "Spezialversion" für Dich - bei Interesse Deinerseits.
Fehlalarme gehoeren zu Virenscanner, das kannst auch Du nicht leugnen. Mein Virenscanner stoert sich an AutoIt. Was sagt deiner? Da vertraue ich R@iner mehr als meinem Virenscanner. Das ruKernelTool gibt in der Debuglog ausfuehrlich Auskunft darueber was es macht. Selten so ein gespraechiges Programm gesehen! Ich sehe daher keinen Grund, R@iner und dem ruKernelTool zu misstrauen.
http://rukerneltool.rainerullrich.de/FAQ.html#1.36
Ich erinnere mich noch leise daran dass R@iner jedem Einsicht in die Sourcen anbot. Frag ihn doch einfach.

kind regards
DMC
 
Sorry, ich belle gar niemanden an und dich schon gar nicht!
Wenn Du das als Redewendung nicht kennst, tut es mir leid ... das war gar nicht persönlich gemeint: http://idioms.thefreedictionary.com/bark+up+the+wrong+tree, also: Please calm down.

realhacker schrieb:
Ich weiss nicht wo deine Ton jetzt herkommt,
Da hast Du offenbar etwas "in den falschen Hals bekommen" (s.o.) ... Achtung, das ist auch nur eine Redewendung, ich denke nicht, daß Du unmittelbar medizinische Hilfe benötigst.

realhacker schrieb:
aber dass es Fehlalarme gibt ist nun wirklich nichts neues. Beim ruKernelTool ist das so lange der Fall wie es das Programm gibt.
Was ändert das jetzt daran, daß es

  1. die Anwender verunsichert
  2. je nach AV-Lösung für jede neue Programmversion (die ja auch zwangsweise folgt aus der Handhabung mit dem Ablaufdatum) erneut auftritt
  3. es einem verantwortungsvollen Berater einfach genetisch schon unmöglich sein sollte, so eine generelle "Empfehlung": "Dann schalte die AV-Funktion (ob für das ruKernelTool oder vollständig, ist dabei nebensächlich) einfach ab." von sich zu geben

realhacker schrieb:
Du hast anscheinen nicht alles gelesen.
Doch ... denke schon. Das "Ablaufdatum" war zwar in diesem Falle besonders nahe, aber das Prinzip ist nun schon seit Jahren immer dasselbe und das nur aus Gründen, zu denen ich meine eigene Position habe. Da ich eine solche Position auch jedem anderen zugestehe, kritisiere ich auch nicht diese Haltung an sich (jeder darf seine Arbeit so publizieren, wie er es für richtig hält), nur die daraus für die "Benutzer" der Software erwachsenden Konsequenzen, wenn es sich um Einschränkungen handelt.

Und um auf das "nicht alles gelesen" zurückzukommen:
Dann darfst Du keinen PC benutzen, denn dort ist das Bios schon closed source. Weiter geht es mit Windows als OS.
, das dürfte hier eher auf Dich zutreffen, denn in demselben Beitrag schreibe ich auch:
PeterPawn schrieb:
wenn man es durch andere Lösungen ersetzen kann
und diese Option habe ich für das OS eines PC tatsächlich (und nutze sie partiell auch, aber wenn meine Kunden mit Windows arbeiten wollen, sind entsprechende Sachkenntnis und eigene Erfahrungen auch mit Windows nun einmal unumgänglich), beim BIOS wird es da schon wesentlich enger mit möglichen Alternativen.

Wenn ich keine gangbaren Alternativen habe, greife ich auch schon mal auf Wege zurück, die weniger gut mit meinen Ansichten harmonieren ... ich würde z.B. als Berliner eher Freizeitdrogen beim Dealer um die Ecke kaufen als sie selbst herzustellen/anzubauen ... obwohl natürlich der verbotene Handel mit Rauschmitteln ein Straftatbestand ist, dem ich mit einem Kauf Vorschub leisten würde, stellte ich in so einem Falle wahrscheinlich meine Prinzipien eher hinten an - nur ein vollkommen absurdes Beispiel, um nicht schon wieder in die "Auto-Kiste" greifen zu müssen.

realhacker schrieb:
Dann hole ich mir aktuell das Programm und gut ist.
Dann gehörst Du entweder zu den wenigen Menschen, die in die Zukunft sehen können ("Next"-Fan?) und somit wissen, wann sie das ruKernelTool in der aktuellen Version benötigen werden oder Du hast es auf dem generellen "Update-Plan", was dann wieder zu der Frage bei mir führt, wieviele "Leichen" in Form abgelaufener ruKernelTool-Versionen in Deiner AV-Lösung wohl liegen mögen (ich unterstelle Dir mal die Benutzung einer solchen). Wenn ich ausdrücklich noch schreibe, daß es eben für manche Leute nicht so einfach ist, sich bei einer nicht funktionierenden FRITZ!Box eine neue Version zu besorgen (schon die Frage, wie man so einen Download vom Smartphone/Tablet auf einen PC kriegt - solange es kein Windows-Tablet ist, funktioniert m.W. das ruKernelTool nicht auf einem solchen Tablet, die Frage der LAN-Verbindung stelle ich dabei noch gar nicht - ist für viele ein nicht-triviales Problem), dann paßt Deine Antwort oben sicherlich eher nicht zu meinem Einwand.

realhacker schrieb:
Fehlalarme gehoeren zu Virenscanner, das kannst auch Du nicht leugnen.
Das leugne ich auch nicht ... aber ich muß trotzdem nicht hingehen und meine eigene Empfehlung (das ist meine Reputation, die da riskiert wird) für ein "closed source"-Programm abgeben, wenn das bekanntermaßen solche Ausnahmen erfordert. Es gibt nämlich durchaus auch genug Leute, die solchen Empfehlungen dann nicht unbedingt differenziert folgen und beim nächsten Katzenvideo eine deutlich niedrigere Hemmschwelle haben, die nächste Ausnahme zuzulassen, denn "der ??? hat das ja letztens gesagt, daß man das machen kann" - wenn Du diesen Unterschied nicht sehen kannst oder willst, tut es mir leid und auch der restlichen Argumentation mit
realhacker schrieb:
Das ruKernelTool gibt in der Debuglog ausfuehrlich Auskunft darueber was es macht. Selten so ein gespraechiges Programm gesehen! Ich sehe daher keinen Grund, R@iner und dem ruKernelTool zu misstrauen.
kann ich irgendwie nicht ganz folgen. Wenn eine ausführliche Protokollierung für Dich ein Grund ist, einem Programm zu vertrauen, dann leben wir in vollkommen verschiedenen Welten - ich kann mir in meiner (paranoiden) Verwirrung tatsächlich vorstellen, daß es Programme gibt, die das eine in ihr Protokoll schreiben und etwas anderes ausführen. Das hat auch überhaupt nichts mit r@iner zu tun ... diese Grundhaltung nehme ich ggü. vielen anderen "closed source"-Programmen auch ein und nerve damit meine Umgebung, wenn ich ihnen immer wieder erkläre, daß der blinde Download irgendwelcher Software aus dem Internet (und das ist beim ruKernelTool eben in regelmäßigen Intervallen immer wieder notwendig) so gar keine richtig kluge Idee ist.

realhacker schrieb:
Ich erinnere mich noch leise daran dass R@iner jedem Einsicht in die Sourcen anbot. Frag ihn doch einfach.
Was ist denn jetzt der Unterschied, ob ein Fremder dem Wort von r@iner oder meinem einfach vertrauen soll? Wenn dieser Dritte das macht, ist das seine Sache (egal ob er r@iner oder mir vertraut) ... selbst eine erfolgreiche Bitte an r@iner und ein Code-Review meinerseits würde ja noch lange nicht sicherstellen, daß die zum Download angebotene kompilierte Version tatsächlich auf diesen Quellen beruht.

Insofern reden wir in diesem Punkt ganz offensichtlich aneinander vorbei und der Standpunkt "pro oder contra FOSS" mag ja noch persönliche Ansichtssache sein, aber wenn man seine berufliche Reputation riskieren soll, dann macht man das dort, wo es notwendig ist (und Kunden sind selbst mit dem FOSS-Argument nur schwer von Windows zu Linux zu migrieren) und verzichtet an anderen Stellen darauf. Das ruKernelTool wäre so eine, denn es gäbe andere Alternativen als AutoIt wie z.B. "freie PowerShell-Skripte" und darüber habe ich mich mit r@iner schon ausgetauscht, als er noch in einem DaCube-Forum eine Heimat für das ruKT hatte.

Warum Du da jetzt eine Notwendigkeit siehst, das ruKernelTool zu "verteidigen" (ich will es gar nicht schlecht machen, ich habe konkrete Kritikpunkte geäußert und Du hast diese entweder mit dem Tenor "alles doch kein Beinbruch oder machen doch alle so" weggewischt oder mir "workarounds" vorgeschlagen, die aber auch am Thema vorbeigehen, weil ich mir selbst durchaus zu helfen weiß und solch ein "workaround" ja den Punkt, an dem sich meine Kritik festmacht, noch lange nicht behebt) verstehe ich weiterhin nicht ... ich habe weder geschrieben, daß das ruKernelTool unbenutzbar wäre (ich habe im "modfs" sogar noch einen Verweis auf das ruKernelTool drin) noch habe ich jemandem von dessen Verwendung abgeraten ... es ist schon ein feiner Unterschied, ob man ein bestimmtes Programm empfiehlt für eine bestimmte Problemstellung oder ob man es nur erwähnt, daß das Problem auch damit zu lösen wäre. Den FBEditor empfehle ich z.B. mit schöner Regelmäßigkeit auch dann, wenn ich ihn selbst gar nicht nutze, weil ich dafür eine eigene Lösung habe - da kann ich das auch, weil man die Quellen eben ansehen kann und JFritz auf der anderen Seite hat von mir "auch schon sein Fett weg", weil man dort eben die Quellen nicht öffentlich einsehen kann und (meines Wissens) darunter auch Bestandteile von anderen Autoren sind, die ihre Arbeit unter die GPL gestellt haben.

Wenn es bei meinen Vorschlägen z.B. darum geht, wie ein Benutzer seine FRITZ!Box in den FTP-Modus bringen kann, dann braucht es eben kein ruKernelTool (da spielt jetzt die FOSS-Frage weniger ein Rolle als ein AV-Alarm) ... es reicht vollkommen aus, ein falsches Recovery-Programm von AVM (das ich mir im Extremfall 3 Jahre lang unverändert liegen lassen kann) zu verwenden. Den kleinen "Zusatzaufwand", einen FTP-Client per Kommandozeile zu starten und sich in der EVA anzumelden, sollte dann noch jeder hinbekommen ... mehr macht das ruKernelTool eben bei "In Adam2 halten" auch nicht und die ganz Harten brauchen nicht einmal das Recovery-Programm, um eine FRITZ!Box in den FTP-Modus zu bringen.

Ob dazu beim ruKT immer noch irgendwelche Kopfstände zum (De-)Aktivieren von "media sensing" o.ä. gemacht werden (müssen), weiß ich gar nicht genau ... aber ich weiß, daß es in > 90% der Fälle (bei einem modernen PC) entweder gar nicht erforderlich ist oder inzwischen wesentlich einfacher geht (über "netsh", ob das vom ruKT inzwischen vielleicht sogar so umgesetzt wird, weiß ich allerdings auch nicht).

Auch die Bedienung des ruKernelTools erfordert eben einiges an Einarbeitungsaufwand (oder sind die Informationen auf der Webpräsenz so umfangreich, weil r@iner auch so gerne schreibt wie ich das tue?) und wenn man diese Zeiten alle gegeneinander aufrechnet (und zwar mit allem, von Beginn des Lesens über den Download bis zum Ergebnis), dann ist das ruKernelTool die "Blackbox"-Lösung, die einem das alles irgendwie abnimmt, aber am Ende eigentlich denselben Zeiteinsatz erforderlich macht und das eigene Wissen, was man sich bei meinen Vorschlägen erarbeiten kann, wäre eine Alternative. Zumindest hat letzteres den Vorteil (meiner Ansicht nach), daß man sich auch mal bei einem unerwarteten Ergebnis eher zu helfen weiß, wenn man denn erst einmal verstanden hat, was man da eigentlich gerade macht.
 
Ausgehend vom aktiven System, kann man auf dem inaktiven System das Verzeichnis '/ ' erreichen/mounten (wo auch '/bin' zu finden ist? Konnte bisher nur das '/wrapper' (und darunter) ausfindig machen und mounten (den mtdblock3...der mtdblock4 enthält nur lost+found, sonst nichts).
 
@coco722:
Ich bleibe bei meiner Empfehlung, noch einmal etwas genauer zu lesen ... irgendwo habe ich mal beschrieben (steht sogar in rot da), daß eben ein SquashFS-Image (das ist per Definition read-only) bei Start gemountet wird und dann da gesamte System mittels "pivot_root" auf dieses FS als Wurzeldateisystem umgeschaltet wird. Damit stellt sich Deine Frage eigentlich überhaupt nicht ... nicht einmal für das inaktive System. Zwar gibt es in dessen yaffs2-Partition auch ein "bin"-Verzeichnis, das enthält aber nicht die Busybox, die in einem "fertig gestarteten" FRITZ!OS verwendet wird und das andere "bin"-Verzeichnis ist halt Bestandteil des SquashFS-Images und damit per se nicht beschreibbar. Vielleicht findest Du ja doch einmal die Zeit, das zu lesen und zu verstehen (dazu gehört dann auch die Recherche unbekannter Begriffe wie "SquashFS" und "pivot_root") ... dann klären sich einige Fragen praktisch von alleine.

Noch genauer werde ich jetzt nicht ... das verstehende Lesen kann und will ich Dir nicht abnehmen und #73 ist bei weitem keine substantiierte Frage ... das ist das Ergebnis irgendwelcher Experimente, gegen die auch nichts zu sagen ist. Aber wenn man dabei dann etwas nicht versteht, sollte man eben erst einmal nach einer Antwort suchen und nicht einfach wieder recht blauäugig erneut nachfragen und nach Deinen Fragen zu urteilen, hast Du noch nicht einmal eine korrekte Vorstellung von einem SquashFS-Image.

Vielleicht fühlt sich ja jemand anderes berufen, Dir diese Einzelheiten noch einmal "mundgerecht" zu servieren, aber ich fände es dann tatsächlich nett, wenn das in einen gesonderten Thread erfolgen würde ... es bläht diesen nur weiter auf und hat mit dem Thema "modfs-Starter" praktisch nichts mehr zu tun.
 
@coco722:
Ich bleibe bei meiner Empfehlung, noch einmal etwas genauer zu lesen ... irgendwo habe ich mal beschrieben (steht sogar in rot da), daß eben ein SquashFS-Image (das ist per Definition read-only) bei Start gemountet wird und dann da gesamte System mittels "pivot_root" auf dieses FS als Wurzeldateisystem umgeschaltet wird. Damit stellt sich Deine Frage eigentlich überhaupt nicht ... nicht einmal für das inaktive System.

Danke, der erste Teil (als Quote) beinhaltet bereits eine konkrete Antwort. Den ganzen Rest hätte man sich sparen können, der zeugt mehr von Überheblichkeit (durchaus berechtigt für dich als Profi, aber nicht nützlich/hilfreich) und weiterhin geringschätzige Belehrungen, die sehr abfällig im Ton sind.
Und tatsächlich, das hat nichts mit dem Thema zu tun.
Schön und angemessen wär es: man kann helfen oder was nettes sagen, oder man lässt es einfach bleiben.
Sonstige Kommentare, Vermutungen, Anmerkungen (auch seitens der anderen Forenmitglieder, was jemand anscheinend versteht oder nicht, oder ob jemand ...wie Bohnenstroh ist, u.s.w.) sind nicht ein anzustrebendes Niveau. Und hierbei handelt es sich nicht nur um eine persönliche Meinung/Empfindung meinerseits, es gibt etliche andere, die genauso "betroffen" waren über gewisse Umgangstöne hier.
 
Zuletzt bearbeitet:
der zeugt mehr von Überheblichkeit (durchaus berechtigt für dich als Profi, aber nicht nützlich/hilfreich) und weiterhin geringschätzige Belehrungen, die sehr abfällig im Ton sind.
Tut mir zwar leid, wenn Du das so siehst, aber vorherige - mehr oder weniger verklausulierte - Bemerkungen in dieser Richtung haben ja offenbar nichts gefruchtet und ich hätte das durchaus auch noch drastischer formulieren können ... vielleicht dann mit einem Ordnungsgong seitens der Moderation, aber Du hast auch eine nicht zu unterschätzende Impertinenz bei der Wiederholung von Fragen in mehreren Threads entwickelt.

Heute morgen "bat" ich Dich, Dir einige Sachen anzulesen (und zwar hier um 06:41 Uhr) und um 12:03 Uhr stellst Du dann die nächste "Frage", die deutlich zeigt, daß Du entweder nichts zum SquashFS gelesen hast oder es (und das, obwohl Du nach eigenen Angaben Informatikerin bist) nicht verstanden hast (was dann aber eher zu Fragen zum SquashFS als zum FRITZ!OS führen sollte).

Da entsteht bei mir tatsächlich der Eindruck, daß das "Beschäftigungstherapie" hier ist und so werde ich dann schon mal etwas deutlicher - gerne auch "überheblicher", wobei ich mir eigentlich einbilde, gerade auch Fragen zu "Basiswissen" noch freundlich beantworten und ausführlich erklären zu können oder gleich zu erklären, daß es dafür genug andere (und bessere) Quellen im Internet gibt. Aber das alles eben nur einmal und nicht solange, bis es mir (und anderen Lesern) zu den Ohren rauskommt.

Wenn Du tatsächlich der Meinung bist, Du hättest lieber "Privatkonsultationen" anstatt die (wiederholten) Hinweise auf zu lesende Stellen aufzugreifen, dann kann man Dir kaum helfen ... selbst ausbleibende Antworten halten/hielten Dich ja offensichtlich nicht davon ab, immer wieder dieselben oder zumindest sehr ähnliche Fragen in wechselnden Threads dann noch einmal zu stellen ... so langsam kann ich die eisbaerin dann doch verstehen.

Der Umgangston hier ist in aller Regel auch ein freundlicher und auch Du kannst Dich eigentlich darüber eher nicht beklagen. Wenn man sich Deine Beiträge noch einmal zu Gemüte führt (ich greife mal einfach den hier weiter vorne stehenden heraus, ausnahmsweise auch als Vollzitat):
coco722 schrieb:
Wollte das sh Script mal laufen lassen (unter der URL http://yourfritz.de/update_yaffs2 ), bekomme aber direkt die nachfolgende Meldung (grundsätzlich klar, weil die filesystem_custom.squashfs sich im Ordner /wrapper befindet). Es erfolgte bei laufendem System.
# sh update_yaffs2
stat: can't stat '/filesystem_custom.squashfs': No such file or directory
dann stellt sich für mich schon die Frage, warum man darauf überhaupt antworten sollte - es ist ja nicht einmal eine klare "Frage" zu erkennen und man muß mehr oder weniger raten, was eigentlich Dein Anliegen ist.

Trotzdem habe ich das getan und dabei versucht, den Grund für diese Fehlermeldung zu erläutern und dort war ich sicherlich auch noch alles andere als unfreundlich (obwohl auch das sehr deutlich gezeigt hatte, daß Du da praktisch alle Zusammenhänge durcheinanderwirfst).

Wenn Du dann aber auf mehrere Hinweise, an die Stelle ständig wiederholter Fragen doch einfach mal das eigene Suchen und Lesen zu setzen, so gar nicht zu reagieren scheinst (Deine Beiträge, der meinerseits zu den Antworten #405 und #406 im anderen Thread geführt haben - das ist jetzt fünf Tage her und es hat sich nach meinem Dafürhalten nichts geändert - hast Du ja gelöscht), dann bleibt wohl nur noch die Option, Dich tatsächlich zu ignorieren oder Du nimmst Dir das einfach einmal zu Herzen (oder erklärst uns hier mal deutlich, warum Du Dein Vorgehen für berechtigt/sinnvoll hältst und was neben Deiner eigenen Person auch noch die anderen Leser/Schreiber hier davon haben) und überlegst Dir Deinerseits, ob wirklich jede dieser Fragen notwendig war.

Jetzt einfach auf beleidigt umzuschalten, ist zwar auch eine Möglichkeit, aber das bringt am Ende sicherlich auch nicht das erwartete Ergebnis und auch der Hinweis, wie betroffen andere waren über "gewisse Umgangstöne", beeindruckt mich nicht wirklich - ich kann zwar auch unfreundlich, aber meistens ist es doch eher sachlich und wenn jemand triefende Freundlichkeit vermißt, dann ist das ohnehin nicht mein Metier - distanzierte Höflichkeit ist das Maximum, zu dem ich mich aufraffen kann.

Ich denke, ich habe lange genug auch freundlich (im Rahmen meiner Möglichkeiten), sachlich und ausführlich auf Deine Fragen geantwortet und auch oft genug darauf hingewiesen, daß vieles davon schon mehrfach beantwortet wurde. Wenn Du der Meinung bist, Du brauchst in jedem Falle eine persönliche Frage und eine Antwort, dann solltest Du das überdenken und mehr die Frage nach dem Nutzen für andere berücksichtigen ... ist so etwas nur das Wiederkauen bereits bekannter Themen, verschlechtert sich das Verhältnis sinnvoller (und unterschiedlicher) Ergebnisse für jeden späteren Suchenden, wenn solche Fragen/Antworten immer wieder auftauchen und dann auch immer wieder genauso beantwortet werden. Wenn bei Suchergebnissen nach Relevanz sortiert die ersten zehn Beiträge/Threads nur immer dasselbe enthalten und erst der elfte einen anderen Aspekt einbringt, werden die wenigsten genau diesen elften Treffer finden/lesen, weil ihnen die zehn davor (von denen einer auch gereicht hätte) die Geduld geraubt haben.

So, habe die Ehre ... und Grüße an alle gelernten Informatiker(innen) da draußen, die auch Recherchen im Internet beherrschen - sorry, aber dieser "Seitenhieb" mußte tatsächlich noch sein, weil ich von jemandem, der sich diese Ausbildung attestiert, auch entsprechende Kompetenzen erwarte (ansonsten sollte er/sie das gar nicht erst erwähnen).
 
Lieber PeterPawn, bei aller Bewunderung für dein Können und bei allem Respekt:

Ist es wirklich ein MUSS, solch Zurechtweisungs-Texte auszuformulieren !?

Ich kann verstehen, wenn du so "gestrickt" bist:
Aussage 1:
ich hätte das durchaus auch noch drastischer formulieren können
... oder
Aussage 2:
distanzierte Höflichkeit ist das Maximum, zu dem ich mich aufraffen kann.
.

Aber das Nachfolgende ist schlicht und einfach respektlos, zumindest nicht ok:

Beispiel 1: - unverhältnismässege Androhungen, wie z.B.
vielleicht dann mit einem Ordnungsgong seitens der Moderation,
Beispiel 2: - unnötige, abfällige Bewertungen , wie
Du hast auch eine nicht zu unterschätzende Impertinenz
Beispiel 3: - unnötige "Seitenhiebe", wie
sorry, aber dieser "Seitenhieb" mußte tatsächlich noch sein
.

Ein absolutes no-go ist jedenfalls die Unterstützung bzw. direkte oder indirekte Gutheissung einer Beleidigung (egal aus welchen undefinierbaren Gründen/Motiven):
... so langsam kann ich die eisbaerin dann doch verstehen.
Denn dabei ging es um folgende einleitende Aussage als Post-Antwort, Zitat "Du bist so...wie Bohnenstroh." Zitat Ende.

DAS ist aber absolut inakzeptabel, egal von wem oder warum, ebenso egal ob in einem Forum oder sonstwo. Und wenn du das nicht glaubst, schau dir mal diesbezügliche Benimmregeln, Hausordnungen, AGB's, "Compliance" Regeln von Konzernen, oder allein die Gesetzeslage an, bezüglich einem Umgang im öffentlichen Umfeld.

Also bitte etwas mehr Respekt, bzw. zumindest bitte um höflich angemessen Umgang, auch deinerseits.
Ein bekanntes Lied heisst: R E S P E C T .

Es ist zwar schön, von deinem know-how was abzubekommen, aber deine Zurechtweisungen darfst du dir sparen, ich bin weder ein kleines Kind, noch deine Tochter oder Ehefrau (falls du mir der auch so umgehen solltest). Das lasse ich mir weder bieten, noch gefallen. PUNKT.

Übrigens, immer und jederzeit ein dickes DANKESCHÖN an dich für deine Arbeit, für das Teilen deiner Erkenntnisse in Form von Skipten und Erklärungen. Das bedeutet aber nicht, dass man sich alles gefallen lassen muss. Gell !?
 
Zuletzt bearbeitet:
Liebe coco722,

leider gehst Du zwar ausführlich auf meine "Verfehlungen" in Bezug auf Sitte und Anstand ein und vergißt darüber vollkommen, Dich mit dem Kernpunkt der ganzen Kritik auseinanderzusetzen ... Du schreibst nur viele (anderswo hier bereits beantwortete oder problemlos im gesamten Internet recherchierbare) Fragen und läßt eigene Anstrengungen an dieser Stelle weitgehend vermissen.

Stellt sich dann jemand hin und erklärt Dir Zusammenhänge (z.B. Joe_57 hier), dann kann man sich die Reaktion meist auch "hinter den Spiegel stecken" (von der Konfusion, die im Text
coco722 schrieb:
@Joe: Es war ja auch gemeint mit "der statische Link" ... "eine statisch gelinkte Busybox 1.24.1" (eine etwas abgekürzte Ausdrucksweise, welche durchaus im Kontext verständlich sein dürfte, benötigt keine unnütze Bemerkung darüber was da nix steht).
Die Inputzeile für diesen statischen Link, oder besser gesagt "eine statisch gelinkte Busybox" wär hilfreich. Und natürlich die binary der busybox 1.24.1 (weil offensichtlich schon vorhanden bei PP).
zum Ausdruck kommt, ganz zu schweigen) und auf der anderen Seite hast Du dann auch so Deine "Befindlichkeiten", wie man z.B. hier lesen kann.

Ich habe irgendwie nicht den Eindruck, daß nur ich so meine Probleme mit Dir habe ... insofern ist es eben auch ein Zeichen von Respekt (wenn Du den für Dich einforderst), wenn Du die Hilfen und Tipps der Leute auch annimmst, die Dir hier angetragen werden und in die diese Leute auch Zeit und Mühe investieren/investiert haben und wenn Du sie nicht einfach ignorierst (oder zumindest so reagierst, daß man diesen Eindruck gewinnen muß).

Wenn Du das auf die Reihe bekommst, kriegst Du auch den Respekt, den Du erwartest ... und Du kannst absolut nicht behaupten, daß man Dir diesen von Beginn an verweigert hätte.

Und wenn Du jetzt erwartet hattest, daß die Frage
coco722 schrieb:
Ist es wirklich ein MUSS, solch Zurechtweisungs-Texte auszuformulieren !?
mit "nein" beantwortet wird, dann hättest Du eben nicht noch die Bemerkungen zu dem Dir angeblich nicht entgegengebrachten Respekt nachlegen dürfen - das kann man nun mal nicht so stehen lassen als Vorwurf.
 
Lieber PeterPawn, du musst wohl das letzte Wort haben. Du bist der Beste und ich ganz und gar nicht - ist es das was du hören willst !??

Wie gesagt, ich erbitte etwas Respekt, Anstand oder zumindest eine minimale Höflichkeit (von demjenigen, wer für mehr nicht im Stande ist). Das ist weder zu viel verlangt, noch zu viel erwartet.

PeterPawn: "Ich habe irgendwie nicht den Eindruck, daß nur ich so meine Probleme mit Dir habe ..."
Also hast du tatsächlich Probleme mit mir !!? Sehr interessant zu erfahren und zu wissen...

Es ist durchaus verständlich, wenn man "Befindlichkeiten" zeigt zu unhöflich/patzigem Verhalten, da machen es dir wohl andere nach mit dieser gewissen "Brummbär"-Attitude, und andere bzw. anders-denkende werden möglichst rausgeekelt (zumindest lassen sich solche Tendenzen erkennen).
 
Zuletzt bearbeitet:
Du bist der Beste und ich ganz und gar nicht - ist es das was du hören willst !??
Na endlich, das hat ja gedauert ... genau das wollte ich lesen und die ganzen anderen (sachlichen) Antworten habe ich nur geschrieben, damit es genau zu diesem Ergebnis kommt. m)

coco722 schrieb:
Wie gesagt, ich erbitte etwas Respekt, Anstand oder zumindest eine minimale Höflichkeit (von demjenigen, wer für mehr nicht im Stande ist). Das ist weder zu viel verlangt, noch zu viel erwartet.
Es gibt irgendein Sprichwort mit einem Wald und wie man dort hineinruft ... und ich bin tatsächlich auch "kindisch" genug, solche Diskussionen (sind es überhaupt welche oder verdienen sie den Namen nur, wenn man auf die Argumente (meinetwegen auch "Vorwürfe") der Gegenseite auch einmal eingeht?) bis zum bitteren Ende zu führen. Richtig spaßig wird es aber erst, wenn ich jetzt zum "Anführer" der Brummbären, die auf die arme coco722 einprügeln, auserkoren werde.
 
Holen Sie sich 3CX - völlig kostenlos!
Verbinden Sie Ihr Team und Ihre Kunden Telefonie Livechat Videokonferenzen

Gehostet oder selbst-verwaltet. Für bis zu 10 Nutzer dauerhaft kostenlos. Keine Kreditkartendetails erforderlich. Ohne Risiko testen.

3CX
Für diese E-Mail-Adresse besteht bereits ein 3CX-Konto. Sie werden zum Kundenportal weitergeleitet, wo Sie sich anmelden oder Ihr Passwort zurücksetzen können, falls Sie dieses vergessen haben.