Ich hab das gleiche Problem und würde auch gerne wissen wie man die Bootlog ausgaben zu Gesicht bekommen kann. WIe gehlhajo schon schrieb gibts die black.conf inder 0.4 nicht mehr und in der Troubleshooting Sektion vom yavdr wiki habe ich diesbezüglich auch nichts entdecken können. Wenn also jemand nen tipp hat... 
reicht es nicht <esc> zu drücken damit der bootsplash verschwindet
evtl mal die konsolen durchswitchen
yaVDR = Plymouth!? Mir war so als hätte ich das mal hier gelesen.
Gibts da keine Tastenkombination um das Bootsplash zu deaktivieren und die Meldungen zu sehen? Mal die Plymouth Anleitung lesen. Oder einen weiteren Eintrag im grub Menu machen um ohne Plymouth zu starten.
cu
Siehst du eigentlich die Bios-Meldungen auf dem TV ?
Bei meinem Mainboard (siehe Signatur) gibt standardmässig nur der VGA ein Signal aus wenn kein Gerät am HDMI erkannt wird (also z.b. wenn der Beamer noch nicht eingeschaltet war beim Booten).
Erst wenn der X-Server mit der erzwungenen HDMI Ausgabe hochkommt gibt es ein Bild.
reicht es nicht <esc> zu drücken damit der bootsplash verschwindet
evtl mal die konsolen durchswitchen
Im Fehlerfall sehe ich die BIOS Meldung, danach wird der Bildschirm dauerhaft schwarz und es ist kein Konsolen wechseln per Tastatur möglich, der Rechner reagiert auf keinerlei Tastendruck (außer dem RESET-Schalter oder 4-Sekündiger PowerButton drücken am Gehäuse). Auch keinerlei SSH Verbindung ist möglich. Ich vermute das er in nem Kernel-Oops oder sowas ähnliches hängt. Sollte es "nur" ein Display/Xserver Problem sein, müsste der Rechner ja trotzdem per SSH erreichbar sein.
Bin selber ein wenig weiter gekommen:
In der grub.cfg den Kernelparameter ändern. (Achtung: Die grub.cfg wird generiert, Änderung hier sind also mit dem nächsten Update eh wieder futsch, aber zum testen kann man hier auch direkt dran rumfrickeln)
- Die vorhandenen Kerneloption "splash", "quiet" und "vt.handoff=7" entfernen.
- Die Kernelparameter "nosplash" und "-v noplymouth" hinzufügen (Ob die Parameter bei yavdr unbedingt notwendig sind weis ich nicht, bei nem "normalen" Desktop-Ubuntu sind sie es)
Damit kann ich jetzt beim Booten die Logausgaben sehen. Und in der tat sehe ich für den Bruchteil einer Sekunde eine Ausgabe die nach Callstackausgabe ausschaut (-> Kernel Oops?). "Leider" friert die Kiste dort nicht sofort ein, sondern er scheint noch das Frontend/Xserver gestartet zu bekommen bevor der Rechner sich dann ins Nirvana verabschiedet (d.h. die Logausgaben werden schon wieder von nem später aufgeschalteten schwarzen Bildschirm überdeckt, grummel...).
Ich habs geschaft einen "screenshot" vom Callstack zu machen, hat zwar ein paar Versuche mit der Digicam gekostet, aber am Ende stimmte das Timing.
Wenn ich den Callstack richtig lese scheint hier "grep" bei nem strlen Aufruf mit nem pagefault die Grätsche zu machen, wie kann denn das passieren? Und um die Antwort auf die gleich kommende Frage vorweg zu nehmen: Ja, ich habe bereits nen memtest86 laufen lassen (für ca.8 Stunden, kein Fehler detektiert) und yavdr habe inzwischen auch mehr als einmal frisch&sauber neu installiert.
Update: Jetzt habe ich es auch geschafft die Ausgaben abzulichten die noch nach dem Callstack (und kurz vom dem Systemfreeze) kommen, da sieht man glaub ich auch wo der "grep" aufruf herkommt der fehlschlägt (grep -q Intel .*ICH $IOPORTS). Zur Information: Nach der Ausgabe mit dem Timestamp 7.841847 steht das System.
Die /etc/default/grub kannst auch Templaten, dann bleiben die Änderung erhalten - FYI
Schieb doch erstmal den symlink /etc/rc2.d/S05loadcpufreq beiseite und sieh nach ob er dann besser läuft. Wenn ja dann scheint es wohl an dem Zugriff auf /proc/ioports zu liegen. Mach doch mal ein
sudo cat /proc/ioportsund sieh nach ob er dann auch abschmiert.
Gerald
Hallo Gerald,
okay, ich hab die Datei /etc/rc2.d/S05loadcpufreq mal weggeschubst und ohne die Datei habe ich den Systemfreeze beim Booten bisher nicht mehr reproduzieren können. Die Kiste ist bisher immer aufgestartet und ich hab nen laufenden VDR mit Bild+Ton, soweit so gut. Wenn ich "cat /proc/ioports" ausführe, habe ich zwei verschiedene Ergebnisse beobachtet. Beim ersten Versuch beendete sich cat sofort mit ner "Getötet" meldung (Reproduzierbar), mit jedem weiteren aufruf von cat /proc/ioports gabs nen weiteren Callstack im dmesg log (siehe unten). Dann habe ich den Rechner rebootet und es nochmal probiert, diesmal funktionierte die cat Ausgabe, es gab keinen Absturz.
Versuch #1:
cat /proc/ioports
Getötet
dmesg:
[ 60.155969] BUG: unable to handle kernel paging request at ffffffffa19334b1
[ 60.155977] IP: [<ffffffff812e1e4b>] strnlen+0xb/0x40
[ 60.155987] PGD 1a05067 PUD 1a09063 PMD 103eeb067 PTE 0
[ 60.155995] Oops: 0000 [#2] SMP
[ 60.155999] last sysfs file: /sys/devices/pci0000:00/0000:00:1f.2/host1/target1:0:0/1:0:0:0/block/sdb/uevent
[ 60.156004] CPU 2
[ 60.156007] Modules linked in: tda10023 snd_hda_codec_hdmi snd_hda_codec_realtek tda10021 snd_hda_intel snd_hda_codec snd_hwdep snd_pcm snd_seq_midi snd_rawmidi snd_seq_midi_event snd_seq joydev ppdev nfsd budget_av exportfs saa7146_vv nfs lirc_dev lockd fscache nfs_acl auth_rpcgss sunrpc videodev nvidia(P) v4l2_compat_ioctl32 videobuf_dma_sg videobuf_core budget_core snd_timer snd_seq_device dvb_core snd psmouse serio_raw parport_pc soundcore saa7146 snd_page_alloc ttpci_eeprom lp parport usbhid hid ahci xhci_hcd libahci e1000e vesafb
[ 60.156070]
[ 60.156074] Pid: 1896, comm: cat Tainted: P D C 2.6.38-13-generic #54-Ubuntu /DH67CL
[ 60.156083] RIP: 0010:[<ffffffff812e1e4b>] [<ffffffff812e1e4b>] strnlen+0xb/0x40
[ 60.156090] RSP: 0018:ffff8800d9d8dcc8 EFLAGS: 00010286
[ 60.156094] RAX: 0000000000000000 RBX: ffff880103edb173 RCX: 0000000000000000
[ 60.156098] RDX: ffffffffa19334b1 RSI: ffffffffffffffff RDI: ffffffffa19334b1
[ 60.156102] RBP: ffff8800d9d8dcc8 R08: 000000000000ffff R09: 000000000000ffff
[ 60.156105] R10: 0000000000000000 R11: 0000000000000003 R12: ffffffffa19334b1
[ 60.156109] R13: ffff880103edc000 R14: 0000000000000000 R15: 000000000000ffff
[ 60.156114] FS: 00007fc7bf0d7720(0000) GS:ffff8800e6f00000(0000) knlGS:0000000000000000
[ 60.156118] CS: 0010 DS: 0000 ES: 0000 CR0: 0000000080050033
[ 60.156122] CR2: ffffffffa19334b1 CR3: 00000000dc397000 CR4: 00000000000406e0
[ 60.156126] DR0: 0000000000000000 DR1: 0000000000000000 DR2: 0000000000000000
[ 60.156130] DR3: 0000000000000000 DR6: 00000000ffff0ff0 DR7: 0000000000000400
[ 60.156134] Process cat (pid: 1896, threadinfo ffff8800d9d8c000, task ffff8800dc1cc4a0)
[ 60.156137] Stack:
[ 60.156140] ffff8800d9d8dd08 ffffffff812e3fee ffff8800d9d8dce8 ffff880103edb173
[ 60.156147] ffffffff817db9d2 ffff8800d9d8dd98 ffffffff817db9d2 ffff880103edc000
[ 60.156154] ffff8800d9d8dd88 ffffffff812e5121 ffffea000302ffff ffff88010d105f80
[ 60.156161] Call Trace:
[ 60.156168] [<ffffffff812e3fee>] string.clone.3+0x3e/0xd0
[ 60.156174] [<ffffffff812e5121>] vsnprintf+0x221/0x620
[ 60.156181] [<ffffffff81185e08>] seq_printf+0x58/0x90
[ 60.156189] [<ffffffff81173ad5>] ? do_filp_open+0x195/0x7c0
[ 60.156196] [<ffffffff8106db28>] r_show+0x78/0x80
[ 60.156202] [<ffffffff811861a6>] seq_read+0x256/0x3f0
[ 60.156207] [<ffffffff81185f50>] ? seq_read+0x0/0x3f0
[ 60.156214] [<ffffffff811c03bf>] proc_reg_read+0x7f/0xc0
[ 60.156220] [<ffffffff81164fb3>] vfs_read+0xc3/0x180
[ 60.156225] [<ffffffff811650c1>] sys_read+0x51/0x90
[ 60.156232] [<ffffffff8100c002>] system_call_fastpath+0x16/0x1b
[ 60.156235] Code: 31 c0 80 3f 00 55 48 89 e5 74 11 48 89 f8 66 90 48 83 c0 01 80 38 00 75 f7 48 29 f8 c9 c3 66 90 55 31 c0 48 85 f6 48 89 e5 74 2a <80> 3f 00 74 25 48 83 ee 01 48 89 f8 eb 10 0f 1f 80 00 00 00 00
[ 60.156293] RIP [<ffffffff812e1e4b>] strnlen+0xb/0x40
[ 60.156299] RSP <ffff8800d9d8dcc8>
[ 60.156301] CR2: ffffffffa19334b1
[ 60.156306] ---[ end trace c3c5733c8617f767 ]---
Versuch #2:
cat /proc/ioports
0000-03af : PCI Bus 0000:00
0000-001f : dma1
0020-0021 : pic1
0040-0043 : timer0
0050-0053 : timer1
0060-0060 : keyboard
0064-0064 : keyboard
0070-0071 : rtc0
0080-008f : dma page reg
00a0-00a1 : pic2
00c0-00df : dma2
00f0-00ff : fpu
0290-029f : pnp 00:02
03b0-03df : PCI Bus 0000:00
03c0-03df : vesafb
03e0-0cf7 : PCI Bus 0000:00
03f8-03ff :
0400-0453 : pnp 00:08
0400-0403 : ACPI PM1a_EVT_BLK
0404-0405 : ACPI PM1a_CNT_BLK
0408-040b : ACPI PM_TMR
0410-0415 : ACPI CPU throttle
0420-042f : ACPI GPE0_BLK
0450-0450 : ACPI PM2_CNT_BLK
0454-0457 : pnp 00:09
0458-047f : pnp 00:08
04d0-04d1 : pnp 00:06
0500-057f : pnp 00:08
0cf8-0cff : PCI conf1
0d00-ffff : PCI Bus 0000:00
1180-119f : pnp 00:08
d000-dfff : PCI Bus 0000:04
d000-d003 : 0000:04:00.2
d010-d017 : 0000:04:00.2
d010-d012 : parport0
d013-d017 : parport0
d020-d027 : 0000:04:00.1
d020-d027 : serial
d030-d037 : 0000:04:00.0
d030-d037 : serial
e000-efff : PCI Bus 0000:01
e000-e07f : 0000:01:00.0
f000-f01f : 0000:00:1f.3
f020-f03f : 0000:00:1f.2
f020-f03f : ahci
f040-f05f : 0000:00:19.0
f060-f063 : 0000:00:1f.2
f060-f063 : ahci
f070-f077 : 0000:00:1f.2
f070-f077 : ahci
f080-f083 : 0000:00:1f.2
f080-f083 : ahci
f090-f097 : 0000:00:1f.2
f090-f097 : ahci
Alles sehr merkwürdig....
Was ich noch beobachtet habe ist, das die Anzahl der vorhandenen CPUs einen Einfluss auf die Reproduzierbkeit zu scheinen habe. D.h. wenn ich bei dem vorhandenen i3 2120 die beiden Kerne + Hyperthreading aktiv habe, tritt der Freeze beim Boot extrem häufig auf. Schalte ich Hypethreading ab, reduziert sich reproduzierbarkeit drastisch. Schalte ich dann auch noch den zweiten Kern im BIOS ab, wirds noch "besser". Damit habe ich den Crash gar nicht mehr hinbekommen. Riecht ja irgendwie nach Racecondition...
Dann habe wir ja schon mal geklärt, dass es kein yaVDR-Problem ist. Sieht für mich stark nach dem Kernel aus. Also Ubuntu-Problem. Einen Workaround hast du ja jetzt. Einfach mal sehen, ob sich in Zukunft mit neueren Kernels was ändert. Kannst ja vielleicht einen Bug-Report bei Ubuntu machen.
Gerald
Ich glaub ich habe jetzt die Ursache des Kernel-Oops gefunden!
In meinem Fall habe ich nämlich lirc homebrew support für ttyS0 im Webinterface aktiviert gehabt. Wie ich jetzt aber gesehen habe, meldet meine I/O Port Karte ihre Serialports nicht bei ttyS0 beginnend, sondern by ttyS4 (IO-Port Adresse ist auch ne andere als die übliche 0x2f8, 0x3f8 ). Da mein Board aber keinerlei COM Legacyports bei 0x3f8/ttyS0 besitzt, hat lirc beim modprobe erstmal versucht auf diesen Standardport zuzugreifen, hat dann gemerkt das es nicht geht und es gab eine Meldung das dieses Module nicht geladen werden konnte:
[ 243.853261] lirc_dev: IR Remote Control driver registered, major 250
[ 243.853407] lirc_serial: module is from the staging directory, the quality is unknown, you have been warned.
[ 243.855529] lirc_serial: port existence test failed, cannot continue
Nach so einem modprobe lirc_serial versuch crasht dann auch 100% reproduzierbar "cat /proc/ioports".
Deaktiviere ich lirc im Webinterface bzw. ich übergebe dem module beim laden die korrekte io-port adresse, gibts auch keinen kernel-oops mehr.
Auslöser des ganzen war also die nicht valide Lircconfiguration meinerseits. Allerdings hätte ich erwartet das in so einem Fall (module kann nicht auf resourcen zugreifen und das module wird gleich wieder entladen) lirc halt einfach "nicht funktioniert" und nicht die Kernel internen Speicherbereich schrottet. Der Spruch der beim laden von lirc_serial kommt ("lirc_serial: module is from the staging directory, the quality is unknown, you have been warned.") ist also durchaus ernst zu nehmen.
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!