Irgendwo im Filesystem steht ein Init-Skript (
/etc/init.d/E16-filesystem-update), wo man die korrekten Pfade nachlesen kann - beim Puma7 kenne ich das (oben schon "zugegeben") nicht im Detail und bei den Puma6-Modellen hat AVM da im Laufe der Zeit auch geändert (auch wenn bei 6490/6590 m.W. noch kein Intel Unified Image verwendet wurde). Nach dem Inhalt dieses Skripts müßte es eine Partition mit dem Bezeichnung
update_tmp geben (in
/proc/avm_partitions) und die wird dann unter
/var/remote gemountet. DAS müßte diese Austausch-Partition sein, wobei ich das bei einer Puma7-Box eben noch nie selbst untersucht habe - da mußt Du jetzt halt mal etwas Phantasie beweisen und mit ein paar Kommandos selbst auf die Suche gehen.
Am einfachsten schaut man mal mit
mount nach, was da überhaupt eingebunden wird, in der
/proc/avm_partitions findet man die Namen der Devices und Partitions und wenn man tatsächlich
mount-Aufrufe mitloggen will, ginge das wieder über die (iirc weiter oben in diesem Thread) schon einmal erwähnte Vorgehensweise, das
mount-Kommando im System mit einem Wrapper-Skript zu ersetzen (ich nehme mal an, daß AVM da ganz normal
mount aufrufen würde (wenn überhaupt "dynamisch" gemountet wird) und nicht direkt die Syscalls verwendet). Auch
blkid sollte vorhanden sein (zeigt die gefundenen Block-Devices (Storage/Partitionen) an und die gefundenen Dateisysteme).
Wobei ein Blick auf die Libraries, die von
burnuimg eingebunden werden, mich eher daran zweifeln läßt, daß dort tatsächlich (erst) das Kopieren der Datei auf eine Austausch-Partition stattfindet (zumindest in der
/sbin/burnuimg auf dem ATOM-Core) - da sind keine (dateibasierten) I/O-Funktionen zu finden und auch (außer
aicmd_docommand) nichts, was sich nach "Kommando ausführen" anhört:
Rich (BBCode):
vidar:/home/FritzBox/FB6591/ATOM $ nm -D sbin/burnuimg
0000146c R _IO_stdin_used
w _ITM_deregisterTMCloneTable
w _ITM_registerTMCloneTable
00003070 B __bss_start
w __cxa_finalize
w __gmon_start__
U __libc_start_main
U __stack_chk_fail
00003070 D _edata
00003098 B _end
U _getargs
U _getargs_init
U aicmd_docommand
U avmipc_create
U avmipc_destroy
U avmipc_msg_register
U crashdump_init
U csock_add_streamfd
U csock_close
U csock_copy_from_ibuf
U csock_exit
U csock_get_writecbuf
U csock_getline
U csock_iflush
U csock_output_bytes_leftq
U csock_printf
U csock_remove_fd
U csock_select
U csock_select_with_msecs
U csock_sendfile
U csock_setobuf
U ctrlerrmsg
U debug_gethandle
U debug_option
U debug_set
00000ba0 T main
U opt_usage
U setpgmname
U signal
U strcmp
U strstr
vidar:/home/FritzBox/FB6591/ATOM $
, dafür aber offensichtlich Funktionen, um Daten über einen Socket zu senden.
Da aber obendrein auch die Funktionen zum Lesen von Dateien fehlen (wenn man nicht bei einem
csock_sendfile tatsächlich auch einen Namen angeben kann in irgendeiner Variante), könnte ich mir auch gut vorstellen, daß der
pumaglued erst dafür zuständig ist (der läuft auf dem ARM-Core und mit dem wird vermutlich über das
aicmd_docommand kommuniziert), die Daten vom ATOM- auf den ARM-Core zu schaffen, wenn der sein
uimg update-Kommando kriegt ... oder vielleicht liest der die auch "live" vom ATOM-Core (dann aber vermutlich auch nicht direkt aus
/var), wobei mir dafür wieder die Anzeichen in der (oben protokollierten) Kommunikation mit ihm fehlen, denn es macht ja nur wenig Sinn, dem
burnuimg einerseits einen Parameter für den Dateinamen zu spendieren und andererseits ein
firmware-update.uimg irgendwo fest zu verdrahten. Und irgendwie müßte dann ja auch der
pumaglued erfahren, welche Datei er eigentlich benutzen soll für das Update ...
Was man ggf. noch machen könnte (wobei das immer weitergehende Kenntnisse verlangt), wäre die Verwendung eines
strace (sollte sich mit Freetz-NG bauen lassen), um die Systemaufrufe von
burnuimg mal zu protokollieren - aber auch das ist nur ein weiterer "Ansatz", wenn einem ansonsten nichts mehr einfällt, weil letztlich die eigentlichen Syscalls (die man damit protokolliert) ja gar nicht aus dem Binary direkt erfolgen, sondern aus irgendwelchen Libraries, die von diesem eingebunden werden und für alles fehlen die Quellen. Man kriegt damit also auch nur einen begrenzten "Ablaufplan" und kann vielleicht noch sehen, ob da Daten aus einer Datei in einem VFS gelesen werden und welche das ist.
Eigentlich soll diese "Kontrolle" auch nur sicherstellen, daß tatsächlich die richtige Datei auf dem ARM-Core verarbeitet wird (also der irgendwie auf die
uimg-Datei zugreifen kann) und der berichtete Fehler nicht daher kommt, daß schon dieser Zugriff nicht möglich ist (warum auch immer das dann so sein könnte).
Das mit dem Kopieren/Sharen über die "scratch partition" war nur meine Annahme, auch weil die eben
update_tmp benannt ist und auf beiden Cores gemountet wird (iirc, den ARM-Teil schaue ich das jetzt nicht auch noch an - kann man leicht selbst vergleichen, ob die
E16-... übereinstimmen oder nicht). Fun-Fact am Rande: Eine Zeitlang wurden diese Partitionen sogar zwischen den Cores über NFS geteilt - mittlerweile ist das aber wohl (zumindest bei den Puma7-Geräten) auch wieder Geschichte und wie das konkret in welcher Abfolge jetzt implementiert ist, muß man eben erst einmal erkunden, solange es nicht schon eine Beschreibung dazu gibt, die mir entgangen wäre.
