einfach nochmal das Original-AVM image geflasht
Wie wäre es denn (endlich) mal mit ein paar Protokollen? Man kann ja tatsächlich auch beim Flashen viel falsch machen, angefangen bei den korrekten Partition-Namen in EVA.
Insgesamt ist das alles nicht so seeehr logisch und systematisch, was hier geschah und was dann an Rettungsversuchen von Dir unternommen wurde. Das geht damit los, daß die Box lt. Environment in #1 niemals als wirklich vollwertige Retail-Box eingerichtet wurde, denn da steht ja (immer noch) ein
RTL=n in der
DMC-Variablen.
Und wenn die Versuche mit
reset=tffs keinen Einfluß auf das Neuformatieren der NAS-Partition hatten, dann ist das tatsächlich auch so zu erwarten, denn damit wird nur folgendes bewirkt:
Rich (BBCode):
case "${fw_info_env}" in *reset=tffs*)
echo werkseinstellung > /proc/tffs
echo cleanup > /proc/tffs
;;
esac
Da werden also nur die Werkseinstellungen geladen und die alten TFFS-Einstellungen "kondensiert" (bereinigt).
Es gab ja Gründe, warum ich zuerst die Verwendung von
recovered=2 "empfohlen" habe:
Ich würde es mal mit dem Zusatz recovered=2 in firmware_info versuchen, falls tatsächlich beim rsync fälschlicherweise der interne Flashspeicher (also die AVM_MEDIA-Partition) komplett beschrieben wurde (dafür reicht schon ein fehlendes Unterverzeichnis in der Pfadangabe) und jetzt nicht mehr gemountet werden kann, weil da offene Transaktionen existieren bzw. das Dateisystem für die Partition (iirc ist das ext4) erst einmal gefixt werden müßte. Dabei gehen dann allerdings alle Daten in der NAS-Partition flöten.
- denn wenn man in die Firmware schaut, ist es tatsächlich so, daß bestimmte Fehler auch in der NAS-Partition durchaus zu einem Reboot-Request führen können:
Rich (BBCode):
do_fsck()
{
local filesystem="$1"
local partition="$2"
local ret_code=0
fsck="fsck.${filesystem}"
info "Running ${fsck} on ${partition}"
ret_str=$(${fsck} -p ${partition}) || ret_code=$?
if [ $ret_code -ne 0 ]; then
if [ $ret_code -eq 2 ]; then
info "${fsck} on ${partition} failed with request for reboot, rebooting now..."
reboot
fi
if [ $ret_code -eq 1 ] || [ $ret_code -eq 4 ] || [ $ret_code -eq 32 ]; then
info "${fsck} on ${partition} failed non critical?: (${ret_str}($ret_code))"
else
error "${fsck} on ${partition} failed (${ret_str}($ret_code))"
return 1
fi
fi
}
(die Formatierung stammt original aus der AVM-Firmware, mit Ausnahme der Farbe)
Und dieser Code wird immer dann aufgerufen, wenn das Mounten einer Partition nicht auf Anhieb funktioniert:
Rich (BBCode):
if ! mount_partition "${filesystem}" "${partition}" ${mnt_path} "${mount_extra_flags}"; then
do_fsck "${filesystem}" "${partition}" || true
if ! mount_partition "${filesystem}" "${partition}" ${mnt_path} "${mount_extra_flags}"; then
info "Creating new filesystem on ${partition} (${fs_label})"
if ! mkfs.${filesystem} -F -L "${fs_label}" -j -E "${mkfs_extra_flags}" -O "${mkfs_extra_feature}" "${partition}"; then
error "${script}: mkfs on ${partition} failed"
exit 1
fi
if ! mount_partition "${filesystem}" "${partition}" ${mnt_path} "${mount_extra_flags}"; then
error "${script}: Giving up."
exit 1
fi
fi
fi
Zwar wird dann (wenn das Prüfen der Partition mit einem nicht-kritischen Fehler endet) auch versucht, die Partition neu zu formatieren (der
mkfs-Arfruf), aber da muß das System auch erst mal ankommen und nicht schon vorher im o.g. Code neu starten.
Die zusätzliche Info, was man mit dem
reset=something bewirken kann, habe ich Dir nur noch gegeben, weil Du unbedingt der Ansicht warst, mit einem eigenen TFFS-Image hantieren zu müssen - das ist eindeutig NICHT länger erforderlich, wenn auf der Box eine Version >= 07.39 (wobei das erst im Laufe der Labor-Reihe implementiert wurde, iirc, und nicht von Beginn an funktionierte) installiert ist.
Vielleicht gehst Du ja jetzt doch mal systematisch vor und das fängt dann für mich schon damit an, daß man die Veränderungen, die sich ggf. durch den Zusatz von
reset=tffs in
firmware_info ergeben haben, erst einmal überprüft (am besten gleich das ganze Urlader-Environment noch mal zeigen). Denn Deine Vorstellungen hier:
In welchem Bereich liegen eigentlich die Daten für das TFFS Recovery?
stimmen auch nur zum Teil mit der Realität überein. Es gibt allerdings im Bootloader einen Konfigurationsbereich, der sich m.W. auch bei Puma7-Modellen mit einem kühnen
RETR config auslesen lassen müßte und dort findet man dann - neben anderen Daten, u.a. dem CM-Zertifikat der Box - auch die "Geburtsdaten" so einer Box, aus denen die festen Werte beim Start des Loaders restauriert werden und wo es für ein paar andere Werte (
DMC sollte u.a. dazu gehören, deshalb sind da auch persistente Änderungen möglich) Standardvorgaben gibt, die man jedoch ändern KANN.
Insofern entsteht bei mir auch der Verdacht (no offense), daß Du Dich eben doch nicht so gut auskennst mit den Puma7-Boxen und da wäre es doch ganz praktisch, wenn Du uns - und zwar sehr ausführlich - an dem teilhaben lassen würdest, was Du da veranstaltest.
Wenn jetzt nicht mal mehr der Inhalt von
firmware_info mit der Versionsnummer restauriert wird, dann klemmt es offenbar bereits im Skript
/etc/boot.d/core/tffs, denn da steht das hier:
Rich (BBCode):
### puma7-only
sh "/etc/init.d/rc.configspace-v2" || msg_error "rc.configspace-v2 failed."
## cache firmware_info (read once) in front of Puma syncpoint.
fw_info_env=$(grep ^firmware_info "${URLADER_ENV}")
## For Puma, the arm side will be booting a bit slower. This syncpoint will
## be used to avoid a race condition where atom resets firmware_info before
## arm can read it.
. /etc/init.d/rc.core_sync.sh
if [ -n "${Recover_was_here}" ] || case "${fw_info_env}" in *reset=*):;; *) false;; esac ; then
Sync_with_other_cpu FWINFO_up || msg_error "sync firmware_info handling"
fi
## Reset firmware_info to original value
version="$(/etc/version)"
if [ -n "${Recover_was_here}" ]
then
## TAM
if [ -d /data/tam ] ; then
rm -f /data/tam/config
rm -f /data/tam/meta*
fi
fi
case "${fw_info_env}" in *reset=tffs*)
echo werkseinstellung > /proc/tffs
echo cleanup > /proc/tffs
;;
esac
case "${fw_info_env}" in *reset=locale*)
echo "country" > "${URLADER_ENV}"
echo "language" > "${URLADER_ENV}"
;;
esac
case "${fw_info_env}" in *reset=setcountry*)
telefonie_werkseinstellungen "$(echo "$fw_info_env" | sed "s/.*reset=\(setcountry[^,]*\).*/\1/")"
;;
esac
## Reset firmware_info to original value - finalize
echo "firmware_info $version" > "${URLADER_ENV}"
Da muß man also - wenn der Rest funktioniert - GAR NICHTS wieder zurücksetzen an dem Wert in
firmware_info. Wenn das nicht von alleine funktioniert, kommt das System offenbar gar nicht erst bis zu dieser Stelle und das ist dann tatsächlich SEHR früh im Startvorgang.
Warum jetzt plötzlich irgendein Core defekt sein soll, erschließt sich (zumindest mir) nicht - deutlich wahrscheinlicher ist es eben, daß da KEIN funktionierendes System installiert ist und da zuvor bereits ein "sync point" auftrat (der rote Teil oben), kann das praktisch beide Systeme betreffen. Und da ist es nun mal am wahrscheinlichsten, daß DU etwas bei den Änderungen bzw. bei der erneuten Installation eines OS falsch gemacht hast ... die Hardware der Box stirbt ja nicht einfach so.
Genau deshalb mein "Wunsch", daß Du eben NICHT einfach nur davon ausgehst, daß Du schon alles richtig machen würdest und uns stattdessen einfach mal die Protokolle (und zwar vollständig, solange sich darin keine "geheimen" Daten befinden) zeigst ... und das bitte in CODE-Kästen, so daß man das auch ohne eigene Anmeldung lesen kann, denn dann braucht man auch (neben dem HTML-Client) keine Zusatzsoftware auf irgendwelchen mobilen Geräten, mit denen man sich diesen Thread ansieht (auch Textdateien sind deutlich umständlicher im Handling).
EDIT:
Wenn man sich ein angepaßtes System auf der Box installiert und/oder in den
kernel_args zusätzlich ein
no_core_sync setzt, sollten die Punkte für die Synchronisation nicht berücksichtigt werden - allerdings dürfte das dann auch Auswirkungen auf das Zurücksetzen von
firmware_info bzw. auf dessen Auslesen auf dem ARM-Core haben (siehe AVM-Kommentar weiter oben), so daß das wohl tatsächlich nur dazu verwendet werden sollte, einen ständigen Neustart zu verhindern, weil die beiden Systeme nicht synchronisiert werden können. Damit kann man ggf. Zeit schinden, um doch noch zu einer Shell-Instanz in der Box (z.B. SSH oder sogar Telnet) zu kommen, mit der man das (auch ohne Bestückung der Seriellen, die ohnehin nur bei einem
mute=0 in den Kernel-Parametern etwas ausgibt) genauer beleuchten kann.
