Erstellt vor 8 Jahren

Zuletzt geändert vor 6 Jahren

#610 assigned enhancement

Save messages of USBRoot script to flash memory or kernel buffer

Erstellt von: AVMBoeder Verantwortlicher:
Priorität: normal Meilenstein: freetz-future
Komponente: freetz-linux Version: devel
Stichworte: USBRoot, log, debug Beobachter:
Product Id: 7270 Firmware Version:

Beschreibung

Since USBRoot is not able to init from a previous created root file system I want read the log output to see what's going wrong.

Sadly, I have no serial console attached to the fritzbox, so the only way to debug is to store the output messages to a file which is stored in the flash memory or to put it into the kernel ring buffer which is accessable via dmesg.

[Forum Thread (german): http://www.ip-phone-forum.de/showthread.php?t=190639]

Änderungshistorie (21)

comment:1 Geändert vor 8 Jahren durch cinereous

  • Status von new nach assigned geändert
  • Verantwortlicher cinereous gelöscht

comment:2 Geändert vor 8 Jahren durch cinereous

Bitte schreib doch beim nächsten mal nicht irgendeinen xbeliebigen Developer da hinein, die "holen" sich die Tickets von selber.

comment:3 Antwort: Geändert vor 8 Jahren durch ralf

Wenn man mit dmesg an die Meldungen kommt, wo liegt dann das Problem? Wenn das Image auch ohne USB läuft (was es tun sollte), dann kann man sich ja anmelden und nachschauen, warum der Wechsel auf USB-Root nicht funktioniert hat.

comment:4 Geändert vor 8 Jahren durch cinereous

Weil die Infos da spärlich sind.

comment:5 als Antwort auf: ↑ 3 Geändert vor 8 Jahren durch AVMBoeder

Genau,
im Kernel Message Buffer stehen nicht die begehrten Infos, welche im Script per "echo" Kommando an die Konsole weitergeben werden. So hat man keine/kaum Chance/n was zum debuggen zu finden…

PS/OT: cinereous) Kann gar nicht nachvollziehen Dich dem Ticket zugewiesen zu haben - wie macht man das bei der Erstellung eines Tickets?

comment:6 Geändert vor 8 Jahren durch cinereous

Keine Ahnung, muss ich zugeben :D

Aber grad mal getestet: "assign to" ist ein Punkt bei der Ticketerstellung, in der du meinen Namen reingeschrieben haben musst

comment:7 Geändert vor 8 Jahren durch derheimi

(In [4806]) e2fsprogs: add patch to disable timestamp checks for date in the future, refs #610

comment:8 Geändert vor 6 Jahren durch kriegaex

Because I do not know if the ticket starter speaks German, I am going to continue in English: Does anybody have an idea about how to implement the initial inquiry, i.e. logging console output to a storage location which is always available and can be read even if the box does not boot correctly or is in a reboot loop? Something which might be recovered after a recover or so? It has been a long time since I implemented the original version of USB root for DS-Mod, and I am not really fit for this topic anymore. I would like to collect opinions and ideas here, so if there is a chance to improve something here I might dig into it later.

P.S.: I know there is kind of a chicken vs. egg problem here if the kernel is broken or so, but… ideas anyway?

Zuletzt geändert vor 6 Jahren von kriegaex (vorher) (Diff)

comment:9 Geändert vor 6 Jahren durch ralph

Maybe if a copy were stored in-memory somewhere, then made available through ADAM2 via symlinking? You'd boot the box, connect to ADAM2 and read the log file(s) from there. That's assuming, of course, this is even possible without rewriting the urlader.

Also, the OP does speak German, cf this entry. ;)

Zuletzt geändert vor 6 Jahren von ralph (vorher) (Diff)

comment:10 Geändert vor 6 Jahren durch ralf

Es gibt von AVM das crashlog im TFFS Speicher. Man müsste dafür aber auch den Weg herausfinden, die Konsolen-Ausgabe abzufangen, und wissen, wann man fertig ist, so dass man alles wegschreiben kann. Für jede Log-Zeile die ganze Datei neu zu schreiben ist vermutlich nicht optimal, aber sicher auch besser als nichts.

comment:11 Geändert vor 6 Jahren durch ralph

Eigentlich ist ja dafür genau die serielle Konsole da. Läßt diese sich vielleicht einfach unbesehen, eins zu eins woanders hin umleiten? LAN wäre ideal, da immer vorhanden, aber ein einfacher Dump auf USB wäre auch noch vertretbar (mit eindringlichen Warnungen, daß der Inhalt des Sticks/der Festplatte das NICHT überlebt).

In jedem Fall wäre das eine Funktionalität, die weniger Freetz als vielmehr der Kernel bereitstellen müßte.

comment:12 Antwort: Geändert vor 6 Jahren durch ralf

Klar ist dafür die serielle Konsole da. Es geht hier darum, ob man auch eine Lösung findet für den Fall, dass jemand die Box nicht öffnen will/kann.

Wenn wir eine entsprechende Funktion wollen, dann wird diese nicht von AVM kommen, dann müssen wir schon selbst etwas tun.

comment:13 Geändert vor 6 Jahren durch kriegaex

Ich denke weiterhin laut, relativ ungefiltert. Erst mal Brainstorming, filtern können wir später noch. Also:

Vielleicht haben wir hier ja einen Kernel-Hacker, wer weiß?

Klar ist, daß man über EVA-FTP Partitionen herunterladen kann, also z.B. auch den Inhalt von TFFS oder JFFS. Ein RAM-Puffer ist ungeeignet, wenn er einen Reboot überleben muß. Etwas übers Netzwerk zu schicken oder auf einen USB-Speicher zu schreiben, sind gute Möglichkeiten, wenn man es denn schafft, zu dem Zeitpunkt den Speicher zu mounten bzw. das Netzwerk hochzufahren. Diese zwei Anforderungen sind vermutlich mit die problematischsten, wenn die Box nicht sauber booten will, weil etwas in der FW oder dem Kernel nicht paßt bzw. USB-Root eben nicht startet, weil der Stick nicht sauber gemountet werden kann.

Der Königsweg wäre sicher, eine versteckte Funktion im Bootloader zu finden, die so etwas bereits ermöglicht, aber das ist wohl Wunschdenken.

comment:14 als Antwort auf: ↑ 12 Geändert vor 6 Jahren durch ralph

Replying to ralf:

Klar ist dafür die serielle Konsole da. Es geht hier darum, ob man auch eine Lösung findet für den Fall, dass jemand die Box nicht öffnen will/kann.

Eben. Deswegen ja auch die Überlegung, eben diese Ausgaben abzugreifen und woandershin zu schicken. raw-Daten würden ja schon reichen - mehr würde man vermutlich ohnehin nicht bekommen.

Wenn die Box einen internen Speicher hat, wäre das potentiell auch eine Option. Nur haben den derzeit die wenigsten Boxen.

Das grundlegende Problem ist doch, daß wir keine Ahnung haben, was für Daten und (insbesondere!) wieviele Daten zu schreiben sind. Daher müßte, meiner Meinung nach, jedes einzelne Bit sofort extern weggeschrieben werden - sei das auf die serielle Konsole oder wohin auch immer. Ansonsten müßte man nämlich ständig den noch verfügbaren Speicherplatz überwachen und /das/, denke ich mal, wird wohl nicht so ohne weiteres machbar sein.

Schlußendlich gibt es ja auch kein EOF. End-of-file ist gleich kerneloops - ob das dann auch ordentlich gespeichert wird, ist fraglich. Insbesondere interessiert ja schließlich diese letzte Ausgabe vor dem Kerneltod. Wenn diese verloren geht, weil der Kernel sich *vorm* Schreiben verabschiedet hat, hat man vermutlich nicht viel davon.

comment:15 Geändert vor 6 Jahren durch ralf

Evtl. kann man etwas einbauen um Meldungen in dem Flash-Bereich, der für das TFFS verwendet wird, unterzubringen.

Einfacher wäre es, wenn man festlegt, dass die Firmware nicht bis zum letzten Byte voll sein darf, sondern in mtd1 mindestens der letzte Block frei sein muss. Ein Block sind 64kB, in den größeren Boxen entsprechend mehr. Da man das nur verwenden würde, wenn die Box erst gar nicht bootet, sollte es für eine minimale Konfiguration reichen, außer bei den ganz kleinen Boxen, wo man schon jetzt auf jedes Byte achten muss.

Alternativ kann man herausfinden, welcher der beiden TFFS-Bereiche gerade frei ist und von dem den letzten Block verwenden. Man müsste nur sicherstellen, dass nicht etwas ins TFFS geschrieben wird. Also insbesondere das AVM Crashlog müsste man dafür deaktivieren, was aber auch nicht weiter schlimm sein sollte. Es wäre ja ein spezieller Debug-Modus, den man nur aktiviert, wenn das Booten nicht funktioniert. Oder man ändert das TFFS so, dass es den letzten Block grundsätzlich nicht verwendet. Für eine nicht zu ausgefallene Konfiguration sollte das reichen. 64kB an Meldungen sollte auch in den meisten Fällen reichen.

comment:16 Geändert vor 6 Jahren durch hippie2000

bei passender beschränkung reichts ggf auch einfach zukunftssucher die von avm bereits im tffs reservierten minors für crash.log und panic zu nutzen.

das feature sollte aber für den notfall sein und default off…

comment:17 Antwort: Geändert vor 6 Jahren durch oliver

Vielleicht sollten wir mal mit was einfachem anfangen, bevor es komplex wird…

Wenn wir davon ausgehen, dass es im Normalfall nicht zu einem Reboot Loop kommt (außer es passiert ein Oops, den wir dann aber im AVM crash.log haben, z.B. weil der User squashfs unmount angehakt hat), dann sollte es doch möglich sein, dass wir das Log in einer Datei unter /dev ablegen. Im Erfolgsfall wird /dev/.hotplug-cache schon für das Cachen der Hotplug Events (nur bei Firmwares ohne udev) verwendet. Derzeit wird das /dev tmpfs im Fehlerfall wieder entladen. Das könnten wir ändern und das Logfile würde den Start überleben.

comment:18 als Antwort auf: ↑ 17 ; Antwort: Geändert vor 6 Jahren durch hippie2000

Replying to oliver:

Derzeit wird das /dev tmpfs im Fehlerfall wieder entladen. Das könnten wir ändern und das Logfile würde den Start überleben.

Das ist natürlich sehr viel eleganter, in brenzligen situationen in's tffs zu schreiben ist immer riskant. avm gibt ja selbst ne warnung vorher aus wenn sie es tun (writing to tffs on panic oder so)…

comment:19 als Antwort auf: ↑ 18 Geändert vor 6 Jahren durch oliver

Leider scheint das Kopieren der fds nicht so einfach zu sein. Ich habe nur diesen länglichen Schnipsel gefunden:

logfile=shtee.log
pipe=shtee.$$.pipe
mkfifo $pipe

echo starting
exec 3>&1
tee $logfile <$pipe >&3 &
teepid=$!
exec 1>$pipe

echo this is a test to see how well this is working

exec 1<&3 # close pipe
wait $teepid
rm $pipe

Process substitution geht wohl nicht mit ash.

comment:20 Geändert vor 6 Jahren durch oliver

Ungetestet, könnte in die Richtung gehen:

  • make/usbroot/files/root/etc/init.d/rc.usbroot

     
    6363OLDROOT=oldroot 
    6464HOTPLUG= 
    6565HOTPLUGCACHE=.hotplug-cache 
     66LOGFILE=.usbroot-log 
     67PIPE=tee.$$.pipe 
    6668 
    6769USBROOT_UNMOUNTOLDROOT='yes' 
    6870[ -f /mod/etc/conf/usbroot.cfg ] && . /mod/etc/conf/usbroot.cfg 
     
    409411 
    410412# Unmount stuff before pivot_root 
    411413unmount_virtualfs() { 
    412     for i in /dev /proc/bus/usb /proc $SYSFS; do 
     414    for i in /proc/bus/usb /proc $SYSFS; do 
    413415        umount "$i" 
    414416    done 
    415417} 
     
    580582 
    581583if [ "$PPID" == "0" ]; then 
    582584    echo "*** $0 called as an init process, start setting up USB root ... ***" 
     585     
     586    mkfifo /dev/$PIPE 
     587    exec 3>&1 
     588    tee /dev/$LOGFILE <$PIPE >&3 & 
     589    teepid=$! 
     590    exec 1>$PIPE 
     591     
    583592    start 
     593     
     594    exec 1<&3 # close pipe 
     595    wait $teepid 
     596    rm /dev/$PIPE 
     597     
    584598    echo "*** Switching to init ... ***" 
    585599    exec init >/dev/console 2>&1 <&1 
    586600fi 

comment:21 Geändert vor 6 Jahren durch cuma

Funktioniert das so? Mag das jemand testen?

Hinweis: Hilfe zur Verwendung von Tickets finden Sie in TracTickets.