Warte auf "Seeadler". Er kann Dir bestimmt helfen. Wenn ihm das gelingt, so befördere ihn zum Kondor. 
Ich bin müde und muss heute nochmals Skifahren. Macht aber Spaß! Meine Frau hat jetzt eine weise Hose. Sieht bezaubern aus. Die Hose und meine Frau erst rechr. 
Albert
Hmmm....
Also: Nachdem ich linux-media-dkms installiert hatte (und ohne funktionierende Fernbedienung (=mit rc_core und imon modulen aus dem Paket)) ist der Rechner jedesmal sauber hochgefahren.
Allerdings habe ich ihn nicht per ACPI Wakeup aufwachen lassen, sondern wenn, dann immer manuell gestartet = im BIOS F8, als Bootdevice die SSD ausgewählt.
Ohne Fernbedienung war die Kiste nicht Familienkompatibel
Nachdem ich die imon Module aus dem dkms update Verzeichnis genommen habe und so (in Sachen Fernbedienung) auf die alten Module gewechselt bin, tat die Fernbedienung wieder. (Siehe auch meinen separaten Thread dazu).
Also -> yavdr0.4 von der SSD als Standard-Boot-Device eingerichtet - und prompt bleibt die Kiste bei einem der nächsten Starts wieder hängen.
Aber eben nicht immer...
Zufall? Oder mag es tatsächlich an den alten imon Modulen liegen?
Was kann ich noch tun, um der Sache auf den Grund zu gehen?
Leider findet sich nichts in den Logs - und auf dem Bildschirm sieht man "nur" das yavdr Logo. Siehe auch in meinen Videos. Kann man das noch irgendwie ausschalten?
Es scheint das Logo zu sein, was irgendwie beim Start von X oder vom vdr o.ä. geladen wird - den Boot-Splash habe ich ja ausgeschaltet.
Das Logo kommt offensichtlich bevor der syslogd seinen Dienst aufnimmt.
Vieleicht versteckt sich ja "hinter" dem Logo noch irgendwelche Wertvolle Information.
Ich habe immernoch das gleiche Problem; beim Start von der SSD bleibt er manchmal beim booten mit yavdr Logo hängen. Kein Umschalten auf andere Konsole möglich, kein ssh, keine Einträge in den Logs...
Ich habe das auch ab und zu, merke es daran, dass das grüne yavdr-Start-Logo nicht mehr pulsiert. Dann weiss ich, das ein Reset fällig ist 
Ich vermute, das es irgendwie mit der Einschaltreihenfolge meiner Geräte zu tun hat! Ist der Fernseher schon eingeschaltet -> booten funzt, schalte ich zuerst FS und gleich danach HTPC ein -> funzt meistens (FS muss auch erst mal "booten"), schalte ich hingegen NUR den HTPC ein (z.B. remote zum apt-Update), funzt es auch. Könnte daher auch ein Problem mit der Erkennung des Bildschirms sein... Ich hab übrigens gar keine DVB-Hardware drin, ist ein reiner VDR-Client mit streamdev.
Ich vermute, das es irgendwie mit der Einschaltreihenfolge meiner Geräte zu tun hat!
Diese Vermutung hatte ich auch schonmal, aber konnte sie bisher nicht bestätigen. In jeder Konstellation (zuerst Bildschirm an, Bildschirm gar nicht an, zuerst Rechner an) ist er schon hängen geblieben. Vom Gefühl her bleibt er am ehesten hängen, wenn der Rechner per ACPI Wakup aus S5 aufwacht und hochfahren soll (zum Aufnehmen) - der Bildschirm dabei aus ist. Mag aber auch sein, dass ich das nur als besonders störend in Erinnerung habe...
Wir bekommt man denn das pulsierende yavdr Logo ausgeschaltet? Keiner eine Idee dazu?
Oder wenigstens den syslogd vorher gestartet?
Ich bin kurz davor, die SSD rauszuwerfen und wieder von ner normalen Platte zu booten. Da hatte ich das Thema nicht.
Ich glaube, ich habe den Fehler gefunden - wenn ich nur einen Fehler habe
Ich habe nun zusätzlich in grub.cfg noch gfxpayload=text gesetzt (statt gfpayload=$linux_gfx_mode) - also so:
menuentry 'Ubuntu, mit Linux 2.6.38-13-generic' --class ubuntu --class gnu-linux --class gnu --class os {
recordfail
set gfxpayload=text
insmod part_msdos
insmod ext2
set root='(/dev/sda,msdos1)'
search --no-floppy --fs-uuid --set=root 8c08026c-ba20-4f6d-999e-7df8d7935336
linux /boot/vmlinuz-2.6.38-13-generic root=UUID=8c08026c-ba20-4f6d-999e-7df8d7935336 ro vmalloc=256m vga=792 noresume nohz=off acpi_enforce_resources=lax noplymouth
initrd /boot/initrd.img-2.6.38-13-generic
}...und siehe da - ich konnte beim Hänger sehen, wo es klemmt.
[Blockierte Grafik: http://www.on123.de/vdr/vdr_uuid.jpg]
Er hängt beim mounten einer Partition laut fstab, die er (trotz korrekter UUID) nicht einbinden kann. Der fsck auf dem nicht gefundenen Verzeichnis bleibt hängen und wartet auf ein I (Ignorieren) S (Einhängen überspringen) oder M (Manuelle Wiederherstellung)...
Mit nem M die manuelle Widerherstellung gestartet,
fsck /dev/sdb3 -> keine Fehler.
In /dev/disk/by-uuid/ fehlt der Symlink.
per Devicename gemounted (mount /dev/sdb3 /srv/vdr/video.01)
und nochmal schnell das dmesg bis dahin in eine Textdatei gesichert.
Rettungskonsole verlassen und gestartet.
Nach dem Start ist der Symlink da.
Irgendwie scheint die Platte/die Partition noch nicht erkannt worden zu sein - ist bestimmt beleidigt, weil sie gegen die SSD ausgetauscht wurde
Oder es ist ein ähnliche Problem wie das hier, trotz neuerem Kernel. Das würde zumindest erklären, warum es manchmal hängt - und manchmal nicht.
Ich habe die Partition jetzt in der /etc/fstab mal mit dem Device (dev/sdb3) statt UUID eingetragen - vielleicht hilft es.
Wenn Ihr noch Ideen dazu habt, gerne.
Ich bin jetzt erstmal optimistisch, dass es so in Zukunft funktioniert.
Und um die nicht passenden Module werde ich mich auch noch kümmern - kommt von meinem imon-Fernbedienungs Reparatur-Gebastel.
Hier noch das dmesg, nachdem er dann nach Verlassen der Rettungskonsole oben war.
Da tummeln sich ja Hardwaregeräte auf denselben Interrupts. Das geht bis heute manchmal ins Auge...
Probier mal die Kiste mit deaktiviertem Apic zu booten. Dazu an die Kernelbootzeile mal "noapic nolapic" anhängen. Auch mal alternativ testen "pci=routeirq"
Grüz!
Hibbelharry
Ich vermute, das es irgendwie mit der Einschaltreihenfolge meiner Geräte zu tun hat!
Das ist Unsinn. Deswegen speichert yaVDR den EDID ab, dass die Einschaltreihenfolge gerade bei Timer-Aufnahmen keine Rolle spielen darf.
Bin für jeden(!) Tipp dankbar...
Kommentiere mal in /etc/default/grub den acpi_enforce_resources=lax versuchsweise aus. Danach update-grub2 ausführen. Reboot nicht vergessen.
Albert
@DaKilla: hatte ich auch schon - kein Erfolg. Als nächstes kommt pci=routeirq rein. Genaugenommen ist es schon drin, darf aber jetzt wegen Tatort nicht neu starten
Und außerdem merke ich es ja leider erst, wenn er eine Woche sauber startet ohne hängen zu bleiben...
Ich find' sowas immer total doof, wenn man nicht direkt weiss, ob es funktioniert.
Ich find' sowas immer total doof, wenn man nicht direkt weiss, ob es funktioniert.
Wer nicht?
Albert
Hallo, hast du schon einmal versucht, YaVDR über eine normale Festplatte (zu installieren und) zu booten?
Ich weiss, es ging mit der alten Festplatte, dennoch würds mich interessieren. Schließlich tritt das Problem ja auch mit 0.3 auf, oder?
So könnte man wenigstens feststellen, ob der Defekt an der Hardware liegt und ob es wirklich an der SSD ist.
Schon von einem wirklichen Defekt an der SSD ausgegangen? Die M4 hat zwar keine Sandforce-Controller, aber ein Defekt könnte dennoch auftreten.
Ich erinnere mich dunkel, dass die VM Versionen abgespeckte OEM-Varianten sind.
Mit einer Festplatte noch nicht, aber mit einem USB Stick. Gleiches Problem. Daher halte ich aktuell einen Defekt der SSD/KABEL/Controller für unwahrscheinlich.
Also wenn das System auch mit über ein über den USB-Stick gebootetes Betriebssystem sich ebenfalls ab und an aufhängt- dann sollte man eigentlich schon davon ausgehen können, dass etwas am Controller/Board/Peripherie defekt ist.
Also wenn das System auch mit über ein über den USB-Stick gebootetes Betriebssystem sich ebenfalls ab und an aufhängt- dann sollte man eigentlich schon davon ausgehen können, dass etwas am Controller/Board/Peripherie defekt ist.
Was Du nicht sagst! Danach suchen wir schon die ganze Zeit. Wenn Du noch sagen könntest, was da nicht mitspielt, das wäre echt spitze.
Albert
Also wenn das System auch mit über ein über den USB-Stick gebootetes Betriebssystem sich ebenfalls ab und an aufhängt- dann sollte man eigentlich schon davon ausgehen können, dass etwas am Controller/Board/Peripherie defekt ist.
Danke für Deine Antwort.
Ich denke mit dem "USB-Stick Test" habe ich einen defekt an der SSD, dem Kabel und dem SATA Controller weitestgehend ausgeschlossen. Es sei denn, ich habe mir die Fehler gleich mit "dd" auf den USB Stick kopiert; dann dürfte er aber vom USB Stick nie durchbooten - tut er aber.
Um auszuschließen, dass ich mir Fehler mitkopiert habe, wäre wahrscheinlich eine frische Installation auf einer normalen Festplatte der einzige Weg. Allerdings ist meine besser Hälfte schon ein wenig genervt
Werde ich trotzdem mal versuchen.
Das Board/die Hardware scheint ja soweit zu tun. Zumindest der von der Platte gebootete yavdr 0.3 tut einwandfrei auf der selben Hardware.
Vielleicht hat eine meiner Komponenten keine Lust auf ein 64Bit OS?!
Aber wieso hat dann der yavdr0.3 auf der SSD ebenfalls gehangen?
Also: Clean Install auf einer Festplatte als nächster Test? Und wenn ich dran denke den memtest86 über Nacht laufen lassen?
Sie haben noch kein Benutzerkonto auf unserer Seite? Registrieren Sie sich kostenlos und nehmen Sie an unserer Community teil!
