Solange es keinen besonderen Grund gibt, würde ich "FREETZ_PATCH_FREETZMOUNT" auslassen ... das ist dann die oben im meinem Screenshot schon gezeigte Einstellung, die zu deaktivieren wäre.
Allerdings ist es - angesichts der verwendeten Konfiguration, die nur eine Besonderheit aufweist, auf die ich gleich noch einmal zurückkomme - unklar, wo der Unterschied zwischen Freetz und der originalen Firmware liegen soll ... zumindest an der Stelle, wo diese Meldung erzeugt wird.
Die Nachricht (sie trägt die Nummer 137) kommt ohnehin aus dem AVM-Teil, der von Freetz eigentlich gar nicht ausgetauscht wird und tritt normalerweise dann auf, wenn auf einem USB-Volume keine Partition gefunden wird, die größer als 0 Byte ist:
Code:
poll_scsi_device() {
local COUNT=0
local DEVICE=""
local SCSI_DEVICE_PATH=$1
local UDEVICE=""
local USB_SYS_PATH=`echo ${SCSI_DEVICE_PATH} | grep -o "/.*usb[0-9]*/[^\:]*/"`
if [ $((USE_USB_PROCFS)) -gt 0 ]; then
eval `udevadm info -p ${USB_SYS_PATH} -q property | grep "DEVICE="`
UDEVICE=${DEVICE##/proc/bus/usb/}
else
local DEVNAME=""
eval `udevadm info -p ${USB_SYS_PATH} -q property | grep "DEVNAME="`
DEVICE="$DEVNAME"
UDEVICE=${DEVNAME##/dev/bus/usb/}
fi
test -z "$UDEVICE" && return
touch ${DEVMAP}
while [ $((COUNT)) -lt 5 ]; do
COUNT=$((COUNT+1))
sleep 7
test -d ${SYSFS}/${SCSI_DEVICE_PATH} || return
test -e ${DEVICE} || return
grep -q "^$UDEVICE=" ${DEVMAP} && return
done
local USBDEV=`echo ${UDEVICE##00}|tr -d '/'`
local NOT_EMPTY=0
for SD_SIZE in $(cat $SYSFS/$SCSI_DEVICE_PATH/../../../../../*/*/*/scsi_device/*/device/block/*/size); do
if [ $SD_SIZE -gt 0 ]; then
NOT_EMPTY=1
break
fi
done
test -e ${DEVICE} || return
grep -q "^$UDEVICE=" ${DEVMAP} && return
if [ $NOT_EMPTY -gt 0 ]; then
echo "${UDEVICE}=#failed" >> ${DEVMAP}
eventadd 142 $USBDEV
else
echo "${UDEVICE}=#empty" >> ${DEVMAP}
eventadd 137 $USBDEV
fi
msgsend upnpdevd update_usb_infos
}
Findet dieser Code innerhalb von 35 Sekunden nach seinem Start weder eine Partition mit einer Size größer 0, noch einen Eintrag für das erfolgreiche Mounten einer Partition von diesem Gerät in der Datei "/var/tmp/mediadevmap", kommt es zu dieser Meldung im Eventlog (das "eventadd 137" fast am Ende). Klappt nur das Mounten nicht und es "erscheint" wenigstens eine Partition mit einer Größe > 0, wird eine andere Nachricht (142) ausgegeben.
Das Mounten erfolgt normalerweise parallel zu dieser 35-Sekunden-Schleife ... das ist durch den "udevd" ja alles event-getrieben. Jetzt gibt es mehrere Möglichkeiten ... entweder das Mounten in Freetz dauert deutlich länger (konkret zu lange für die 5 x 7 Sekunden oben) und erfolgt erst später doch noch oder es gibt ein Problem innerhalb der ersetzten Routinen:
https://github.com/Freetz/freetz/blob/master/patches/scripts/197-add_freetzmount.sh#L41 und es wird tatsächlich nichts gemountet (auch nicht später). Das erklärt dann allerdings noch nicht, warum gar kein Block-Device von diesem Gerät "eingerichtet" wird, das eine Size > 0 hat.
Jedenfalls ist die Konfigurationsdatei ja nur der "Grundstock" an Informationen, die man für eine Diagnose braucht. Der nächste Schritt ist es jetzt, die Ausgabe von "cat /proc/diskstats" unter beiden Systemen miteinander zu vergleichen (aus der AVM-Variante erkennt man dann auch gleich die Partitionierung) und am besten auch gleich die Ausgabe von "blkid" dazuzupacken. Dann gilt es unter Freetz noch einen Test zu machen, ob es einen Unterschied ergibt, wenn das Gerät bereits direkt beim Start angesteckt ist und erkannt werden soll oder wenn es erst später hinzugefügt wird. Klappt es später, deutet das darauf hin, daß beim Start das System doch länger als die 35 Sekunden benötigt. Anhand von "blkid" sollte man wenigstens eine Idee kriegen, welche Dateisysteme denn nun benötigt werden für dieses USB-Gerät.
---------------------------------------------------------------------------------------------------------------------------
Da komme ich dann auch wieder auf die "Merkwürdigkeit" in der Konfiguration zurück ... einerseits sollen hier die Plugins wieder integriert werden, andererseits ist keines von ihnen dafür ausgewählt :
Code:
166 FREETZ_AVMPLUGINS_INTEGRATE=y
169 # Plugin selection
173 # Select plugin(s) for integration
175 # FREETZ_AVMPLUGINS_TAM is not set
176 # FREETZ_AVMPLUGINS_WLAN is not set
2186 FREETZ_AVM_HAS_PLUGINS_UPDATE=y
2187 FREETZ_AVM_HAS_PLUGIN_TAM=y
2188 FREETZ_AVM_HAS_PLUGIN_WLAN=y
[ WEBCM_INTERPRETER - also die Sprachdatenbank(en) - ist bei der deutschen Version leer und wird in Freetz daher auch nicht angeboten. ]
Das verwirrte mich am Anfang einigermaßen (jedenfalls das INTEGRATE=y ohne weitere Remove-Patches) ... denn das würde natürlich nicht funktionieren, weil das erzeugte Image zu groß wäre bei dieser Konfiguration.
Solange man nicht wirklich eines der Plugins integrieren lassen will, sollte man die Einstellung auch nicht wählen, weil auch ohne Auswahl mind. eines Plugins die Verarbeitung innerhalb des Systems bereits geändert wird:
https://github.com/Freetz/freetz/blob/master/fwmod#L898
Im Ergebnis dürftest Du in Deinem Image gar kein WLAN haben und auch keine AB-Texte (bzw. die Plugins würden nicht gestartet, weil ja "/sbin/start_plugin.sh" überschrieben wurde) ... war das tatsächlich so beabsichtigt?
