Thema: Bootcrash mit "serial-log"

Zitat von FrankSteiner

@arn345/Papi2000: versteh ich die Bemerkung zu den Bootloadern richtig, das mit dem alten (offiziellen) Bootloader die initrd.bin gar nicht verwendet wird, sondern vom Kernel direkt ins rootfs.bin uebergegangen wird?

ja. initrd.bin ist quasi ein Mini-Linux.

Bootloader 07.05. sucht beim Start nur nach lcdwaitkey, lcdwarning, lcdsplash, splash, kernel und rootfs sofern ein USB-Stick FAT32 eingesteckt ist. Er flasht dann die Bildchen lcdsplash, splash und anschließend in USB 1.1 Geschwindigkeit kernel und dann rootfs.

Der noch nicht veröffentlichte neue Bootloader sucht beim Start nach lcdwaitkey, lcdwarning, lcdsplash, splash, initrd, kernel und rootfs sofern ein USB-Stick FAT32 eingesteckt ist. Er flasht dann die Bildchen lcdsplash, splash und lädt dann falls vorhanden initrd.bin um anschließend in USB 2.0 Geschwindigkeit kernel und dann rootfs zu flashen. Mit USB 2.0 erfolgt dann natürlich vorallem das lesen des rootfs deutlich schneller.



Die Erstellung rootfs wurde von 4096 auf 4000 geändert und sollte wenn man neuflasht zumindest eine höhere Sicherheit geben, das das rootfs auch zuverlässig initialisiert wird. Somit sollte es zumindest beim Start nicht mehr zu Fehlern bei der Initialisierung rootfs kommen. Abweichende Kernelcrashes sind natürlich etwas anderes.

Wenn Die Wabe bereits angezeigt wird, dann ist das nicht der gleiche Fehler. Sobald die Wabe erscheint, wird bereits versucht Enigma2 zu starten - das ist später als das hier im Thread beschriebene. Aufschluss sollte hier das E2-Log geben.

Ist aber auch müssig - openATV 3 gibt es keine Updates mehr - irgendwann kommst Du um den Flash ohnehin nicht rum.

Hi arn345,

nee, die Wabe wird bei mir nur bei einem erfolgreichen Boot angezeigt, bei meinen Haengern zeigt das TV nur "unsuported image format" o.ae., waehrend im Display das "Gigablue presents" steht, d.h. ich hab schon denselben Fehler wie die andern hier. Hab ich wohl ungeschickt beschrieben, sorry!

Wenn ich die inittab richtig lese, sollte wg. des "wait" das Enigma2-Programm ja erst starten, wenn die runlevel-Scripte durch sind. Kommt die Wabe erst, wenn enigma2.sh startet?

Was ist im Unterschied dazu /usr/share/bootlogo.mvi, das in den runleveln gestartet wird? Kann ich leider nicht anzeigen, weil ich keinen Player fuer mvi finde.

@husky und Gundo: Falls nach dem Flash auf openATV 4.0 der Bug immer noch auftritt, koennt ihr dann mal in /etc/default/rcS die Zeile mit der verbose-Variable auf "VERBOSE=very" setzen und in /etc/init.d/rc in der ersten Zeile noch ein -x hinter das sh setzen, also "#!/bin/sh -x"? Wenn die init-Meldungen nicht irgendwo nach /var/log umgeleitet werden, muesste man dann im serial Log ziemlich genau sehen, an welchem Punkt der Crash auftritt.

Auf jeden Fall erst nach dem Laden des dvb-Moduls (sieht man in der oops-Meldung), also nach S04modutils.sh (daher hat's wohl nichts mit dem ext4 zu tun, wie ich erst dachte, denn die Platten werden schon im Script davor gemountet). Und vermutlich noch vor Erreichen von runlevel 3, da dort als erstes das Netzwerk startet, was ja wohl schon nicht mehr klappt.
Vielleicht koennen wir's genauer eingrenzen...

cu,
Frank

P.S.: Ihr koenntet auch direkt in jedem Script in /etc/init.d/ ein -x hinter das /bin/sh setzen, dann sieht man direkt ganz genau welcher Befehl in welchem Script den Bug ausloest. Vorausgesetzt, er tritt nicht asynchron in irgendeinem Modul oder Daemon auf :-/

... Falls nach dem Flash auf openATV 4.0 der Bug immer noch auftritt, ...

Der Bootcrash tritt bei meinen beiden QUAD´s auf. Sowohl mit ATV3 wie auch mit ATV4.

Also folgendes soll ich mal machen:

1 ./etc/default/rcS

Code:

VERBOSE=very

2. /etc/init.d/rc

Code:

#!/bin/sh -x

3. in jedem Script in /etc/init.d/ ein -x hinter das /bin/sh setzen

Damit ist der komplette Inhalt von /etc/init.d/ gemeint, oder nur *.sh Dateien ?

Code:

alsa-state
autofs
avahi-daemon
banner.sh
bootlogd
bootlogo
bootmisc.sh
busybox-cron
checkroot.sh
dbus-1
ddbootup
devpts.sh
dmesg.sh
dropbear
functions
functions.initscripts
fuse
halt
hostname.sh
inetd.busybox
mdev
modload.sh
modutils.sh
mountall.sh
mountnfs.sh
networking
nfscommon
nfsserver
populate-volatile.sh
portmap
rc
rcS
read-only-rootfs-hook.sh
reboot
rmnologin.sh
rpcbind
samba
save-rtc.sh
sendsigs
single
sysfs.sh
syslog
syslog.busybox
umountfs
umountnfs.sh
urandom
volatile-media.sh

Dann schmeiß ich mal den serial-Log an. Meine Kiste stürzt ca. 1x am Tag ab. Mal sehen ob ich den Crash einfangen kann.

Gruß Gundo

@Frank Steiner
Ich hab den Log mit einem Normalen verglichen, an der Stelle wo es nicht weiter geht, kommt normal folgendes:

Code:

fb0: brcmfb frame buffer deviceinput: gigablue remote control as /devices/virtual/input/input2
DVB: registering new adapter (gbquad)
DVB: registering adapter 0 frontend 0 (BCM7356 DVB-S2 NIM (internal))...
DVB: registering adapter 0 frontend 0 (BCM7356 DVB-S2 NIM (internal))...
DVB: registering adapter 0 frontend 0 (GIGA DVB-C/T NIM (SI))...

Die interne sata HDD wird einen Schritt vorher eingebunden.
Das da ein recovery gemacht wurde, liegt wohl am harten Ausschalten, weil die Quad vor dem LOG auch nicht booten wollte.

Ich stelle die gewünschten Parameter mal um, allerdings hab ich seit letztem Bootstopp keine mehr gehabt....

Heute mal das aktuelle Image getestet, auch hier wieder Bootcrash.

Dann in das aktuelle Image den Treiber vom 2.11. reinkopiert, Bootcrash immer noch vorhanden.

@Gundo: in allen Dateien in /etc/init.d. Das sind alles Scripte, egal ob die auf .sh enden oder nicht. Das -x bewirkt, dass jeder Befehl, der in dem Script ausgefuehrt, auf dem Terminal ausgegeben wird. Viel Erfolg :-)

@husky: Das sieht man leider nichts, weil eben keine Ausgaben ausser den kernel-Meldungen kommen. Darum muessen wir das mit dem -x mal versuchen.

@mike99: Laut jule_666 gibt's mit dem Treiber vom 2.11. auch gelegentliche Abstuerze, mit dem Treiber vom 20.08 angeblich nicht. Allerdings soll der Probleme mit Sound haben, siehe http://www.opena.tv/forum/showthread...8859#post48859

Ich muss den mal testen, wenn ich auf 4.0 geflashed habe, aber das geht fruehestens am Wochenende.

@FrankSteiner:
Kurze Verständnisfrage:

2. /etc/init.d/rc

Code:

#!/bin/sh -x

Bedeutet die Raute am Beginn der 1.Zeile nicht, dass diese Zeile auskommentiert ist, also ignoriert wird? Oder wird das durch das Ausrufezeichen dahinter doch interpretiert?

In diesem Fall ist das kein Kommentar. Das ist der sogenannte shebang:
http://de.m.wikipedia.org/wiki/Shebang

Quad/Quadplus
http://archiv.openmips.com/beta/giga...d-20140415.zip
http://archiv.openmips.com/beta/giga...s-20140415.zip

fixed rcu short key delay
fixed rcu kernel panic

Bitte mal testen - zumindest einige der Logs hatten RCU kernel panic.