Diverse Probleme nach den Update in 0.5-alpha1

TCr82 · 9. September 2012

Hi,

gestern habe ich das Update in 0.5 durchgeführt. Dabei sind einige Probleme aufgetreten:

1. Das Update selbst... es hing bei stop und start von vdr.

Code

Trigger für yavdr-utils werden verarbeitet ...
vdr start/running, process 16637
vdr start/running, process 16834

Musste das ganze manuell mit kill PID beenden. (den Auszug vom kill von stop hab ich nicht mehr, da im screen Terminal getätigt, nur den vom start kill)

Code

root@vdr:~# ps aux|grep start
root       336  0.0  0.0  17224   532 ?        S    21:09   0:00 upstart-udev-bridge --daemon
root       703  0.0  0.0  15180   528 ?        S    21:09   0:00 upstart-socket-bridge --daemon
102        965  0.0  0.1  24260  1572 ?        Ss   21:09   0:00 dbus-daemon --system --fork --activation=upstart
root       987  0.0  0.0  15944   752 ?        Ss   21:09   0:00 xinit /usr/bin/openbox --config-file /etc/openbox/rc.xml --startup /sbin/initctl emit --no-wait openbox-started -- :1 vt7
root      1684  0.0  0.7 105588  7304 ?        S    21:09   0:00 /usr/bin/openbox --config-file /etc/openbox/rc.xml --startup /sbin/initctl emit --no-wait openbox-started
root     16986  0.0  0.1  15228  1052 ?        S    21:20   0:00 start wait-for-job-state WAIT_FOR=vdr TARGET_GOAL=start WAIT_STATE=running WAITER=vdr-frontend WAIT_FOREVER=1
root     17094  0.0  0.1  13792  1412 pts/1    S    21:26   0:00 /bin/bash /usr/share/yavdr/events/music-plugin/90_start-vdr music-plugin
root     17096  0.0  0.1  19632  1196 pts/1    S    21:26   0:00 start vdr
root     17109  0.0  0.0  10888   928 pts/1    S+   21:28   0:00 grep --color=auto start
root@vdr:~# kill 17096
/usr/share/yavdr/events/music-plugin/90_start-vdr: Zeile 5: 17096 Beendet                 start vdr

Alles anzeigen

Danach nochmal dist-upgrade da mehrere Pakete mit Fehlern installiert wurden (wegen dem kill)

Code

Fehler traten auf beim Bearbeiten von:
 vdr-dbg
 vdr-plugin-dvbsddevice
 vdr-plugin-dvbhddevice
 yavdr-essential

Aktueller Status: 3 beschädigt [+3], 1 aktualisierbares Paket [-79]

2. Der Xorg-Server mit OpenBox startet nicht mehr:

Ich musste die Xorg.conf per Hand anpassen. Die Mode-Lines werden nicht mehr ermittelt und somit steht eine leere Mode-Line drin. Ausserdem steht kein Driver mehr unter Device. Ausschlaggebend dass der Xorg Server nicht mehr startet ist auf jeden fall die leere Mode-Line.

Code

[   346.097] (EE) NVIDIA(0): Failed to build requested mode list.

3. X10 FB geht nach dem Update gestern auch bei mir nicht mehr.

seahawk1986 · 9. September 2012

Zitat von aLiEnTxC

1. Das Update selbst... es hing bei stop und start von vdr. Musste das ganze manuell mit kill PID beenden. Danach nochmal dist-upgrade da mehrere Pakete mit fehlern installiert wurden (wegen dem kill)

Dann wurden vermutlich die ganzen Templates nicht vernünftig angewandt, wenn du ihn da mittendrin killst - wie lang hing er denn da beim Beenden des vdr, dass man ihn abschießen musste? Hast du mal ein "sudo apt-get install --reinstall yavdr-utils" angestoßen?

Zitat von aLiEnTxC

2. Der Xorg-Server mit OpenBox startet nicht mehr:

Ich musste die Xorg.conf per Hand anpassen. Die Mode-Lines werden nicht mehr ermittelt und somit steht eine leere Mode-Line drin. Ausserdem steht kein Driver mehr unter Device. Ausschlaggebend dass der Xorg Server nicht mehr startet ist auf jeden fall die leere Mode-Line.

D.h. ein Neuerkennen lassen des Bildschirms im Webfrontend hat nicht funktioniert?

Zitat von aLiEnTxC

3. X10 FB geht nach dem Update gestern auch bei mir nicht mehr.

Das ist doch mal eine ausführliche Fehleranalyse... auch wenn du damit sicherlich den Preis für das ratlose Kopfschütteln über der Motorhaube gewonnen hättest hilft das nicht wirklich weiter.

TCr82 · 9. September 2012

Zitat von mini73

Moin!

Wer ein Update macht, ohne vorher bei Launchpad zu gucken, ob es ratsam ist, ist selber Schuld.
Wer diesen Thread nicht abbonniert hat, und damit wichtige Ankündigungen verpasst, ist selber Schuld.

Klartext: Mach kein Update, wenn du die testing-Repositories benutzt!

Lars.

Alles anzeigen

Das hätte man mal vorher lesen müssen

Die meisten Dinge sind ja nicht so schlimm... nur die X10 wäre nicht schlecht

seahawk1986

zu1. ja, habe ich gemacht.. macht er sowieso nach dem dist-upgrade nochmal. Da er ja sieht, dass die genannten Pakete nicht fertig konfiguriert wurden. Und ja es dauerte seeeehr lange.. war also keine Reaktion mehr da.. auch das manuelle beenden des vdrs mit kill brachte kein weiterkommen... deswegen musste ich ja den kill des start und stop prozesses durchführen...

zu2. nein hatte nichts gemacht... als erstes erkanntes das webif gar keinen Monitor da der Xorg nicht lief.. erst nachdem er lief (also ich manuell die xorg.conf angepasst hatte und start openbox) erkannte er wieder im webif den Monitor... aber selbst danach fehlte die ausgefüllte Mode-Line

zu3. ja sorry, wusste nicht wirklich mehr wo ich da ansetzten soll. Hab aber mittlerweile ein wenig rumgeforscht:

in /lib/udev/rules.d/98-eventlircd.rules bzw. in /lib/udev/rules.d/98-eventlircd-names.rules ist die X10 nicht mehr drinnen. Auch in /etc/eventlircd.d/ fehlt die entsprechende Datei.

Code

root@vdr:/etc/eventlircd.d# udevadm info --query=all --attribute-walk --name=/dev/input/event3


Udevadm info starts with the device specified by the devpath and then
walks up the chain of parent devices. It prints for every device
found, all possible attributes in the udev rules key format.
A rule to match, can be composed by the attributes of the device
and the attributes from one single parent device.


  looking at device '/devices/pci0000:00/0000:00:1d.1/usb6/6-1/6-1:1.0/rc/rc0/input3/event3':
    KERNEL=="event3"
    SUBSYSTEM=="input"
    DRIVER==""


  looking at parent device '/devices/pci0000:00/0000:00:1d.1/usb6/6-1/6-1:1.0/rc/rc0/input3':
    KERNELS=="input3"
    SUBSYSTEMS=="input"
    DRIVERS==""
    ATTRS{name}=="X10 Wireless Technology Inc USB Receiver"
    ATTRS{phys}=="usb-0000:00:1d.1-1/input0"
    ATTRS{uniq}==""
    ATTRS{properties}=="0"


  looking at parent device '/devices/pci0000:00/0000:00:1d.1/usb6/6-1/6-1:1.0/rc/rc0':
    KERNELS=="rc0"
    SUBSYSTEMS=="rc"
    DRIVERS==""
    ATTRS{protocols}=="other"


  looking at parent device '/devices/pci0000:00/0000:00:1d.1/usb6/6-1/6-1:1.0':
    KERNELS=="6-1:1.0"
    SUBSYSTEMS=="usb"
    DRIVERS=="ati_remote"
    ATTRS{bInterfaceClass}=="ff"
    ATTRS{bInterfaceSubClass}=="00"
    ATTRS{bInterfaceProtocol}=="00"
    ATTRS{bNumEndpoints}=="02"
    ATTRS{supports_autosuspend}=="0"
    ATTRS{bAlternateSetting}==" 0"
    ATTRS{bInterfaceNumber}=="00"


  looking at parent device '/devices/pci0000:00/0000:00:1d.1/usb6/6-1':
    KERNELS=="6-1"
    SUBSYSTEMS=="usb"
    DRIVERS=="usb"
    ATTRS{bDeviceSubClass}=="00"
    ATTRS{bDeviceProtocol}=="00"
    ATTRS{devpath}=="1"
    ATTRS{idVendor}=="0bc7"
    ATTRS{speed}=="1.5"
    ATTRS{bNumInterfaces}==" 1"
    ATTRS{bConfigurationValue}=="1"
    ATTRS{bMaxPacketSize0}=="8"
    ATTRS{busnum}=="6"
    ATTRS{devnum}=="2"
    ATTRS{configuration}==""
    ATTRS{bMaxPower}=="  2mA"
    ATTRS{authorized}=="1"
    ATTRS{bmAttributes}=="80"
    ATTRS{bNumConfigurations}=="1"
    ATTRS{maxchild}=="0"
    ATTRS{bcdDevice}=="0100"
    ATTRS{avoid_reset_quirk}=="0"
    ATTRS{quirks}=="0x0"
    ATTRS{version}==" 1.10"
    ATTRS{urbnum}=="219"
    ATTRS{manufacturer}=="X10 Wireless Technology Inc"
    ATTRS{removable}=="unknown"
    ATTRS{idProduct}=="0006"
    ATTRS{bDeviceClass}=="00"
    ATTRS{product}=="USB Receiver"


  looking at parent device '/devices/pci0000:00/0000:00:1d.1/usb6':
    KERNELS=="usb6"
    SUBSYSTEMS=="usb"
    DRIVERS=="usb"
    ATTRS{bDeviceSubClass}=="00"
    ATTRS{bDeviceProtocol}=="00"
    ATTRS{devpath}=="0"
    ATTRS{idVendor}=="1d6b"
    ATTRS{speed}=="12"
    ATTRS{bNumInterfaces}==" 1"
    ATTRS{bConfigurationValue}=="1"
    ATTRS{bMaxPacketSize0}=="64"
    ATTRS{authorized_default}=="1"
    ATTRS{busnum}=="6"
    ATTRS{devnum}=="1"
    ATTRS{configuration}==""
    ATTRS{bMaxPower}=="  0mA"
    ATTRS{authorized}=="1"
    ATTRS{bmAttributes}=="e0"
    ATTRS{bNumConfigurations}=="1"
    ATTRS{maxchild}=="2"
    ATTRS{bcdDevice}=="0304"
    ATTRS{avoid_reset_quirk}=="0"
    ATTRS{quirks}=="0x0"
    ATTRS{serial}=="0000:00:1d.1"
    ATTRS{version}==" 1.10"
    ATTRS{urbnum}=="33"
    ATTRS{manufacturer}=="Linux 3.4.4-030404-generic uhci_hcd"
    ATTRS{removable}=="unknown"
    ATTRS{idProduct}=="0001"
    ATTRS{bDeviceClass}=="09"
    ATTRS{product}=="UHCI Host Controller"


  looking at parent device '/devices/pci0000:00/0000:00:1d.1':
    KERNELS=="0000:00:1d.1"
    SUBSYSTEMS=="pci"
    DRIVERS=="uhci_hcd"
    ATTRS{irq}=="19"
    ATTRS{subsystem_vendor}=="0x1849"
    ATTRS{broken_parity_status}=="0"
    ATTRS{class}=="0x0c0300"
    ATTRS{consistent_dma_mask_bits}=="32"
    ATTRS{dma_mask_bits}=="32"
    ATTRS{local_cpus}=="00000000,00000000,00000000,00000000,00000000,00000000,00000000,00000003"
    ATTRS{device}=="0x2831"
    ATTRS{enable}=="1"
    ATTRS{msi_bus}==""
    ATTRS{local_cpulist}=="0-1"
    ATTRS{vendor}=="0x8086"
    ATTRS{subsystem_device}=="0x2831"
    ATTRS{numa_node}=="-1"


  looking at parent device '/devices/pci0000:00':
    KERNELS=="pci0000:00"
    SUBSYSTEMS==""
    DRIVERS==""

Alles anzeigen

Das muss jemand von euch dort entfernt haben... denn hier steht dass es dort geladen wird.
Evtl. hat sich das ja geändert oder ich habe da was übersehen.

seahawk1986 · 9. September 2012

Zitat von aLiEnTxC

in /lib/udev/rules.d/98-eventlircd.rules bzw. in /lib/udev/rules.d/98-eventlircd-names.rules ist die X10 nicht mehr drinnen.

Zitat von aLiEnTxC

Das muss jemand von euch dort entfernt haben... denn hier steht dass es dort geladen wird.
Evtl. hat sich das ja geändert oder ich habe da was übersehen.

Ja, ati_remote hat die Seiten gewechselt und bindet die X10 mit dem Kernel von precise als rc-core Empfänger ein (hatte ich aber auch geschrieben: http://www.yavdr.org/documentation/0.5/de/ch02s03.html#X10). In den Treibern gab es in den letzten Kernel-Versionen und dem dazu passenden media tree viele Namensänderungen. Da hilft nur nachsehen was für eine Keytable und Treiber dafür geladen werden und dann ggf. den Header und die Regel in /etc/rc_maps.cfg entsprechend anzupassen. Wir haben zwei Typen der X10 im Team und dafür sind die Regeln gepflegt, der Rest erfolgt auf Zuruf...

TCr82 · 9. September 2012

hmm..

Code

ir-keytable
Found /sys/class/rc/rc0/ (/dev/input/event3) with:
	Driver ati_remote, table rc-medion-x10
	Supported protocols: other 
	Enabled protocols: 
	Repeat delay = 150 ms, repeat period = 125 ms
ir-keytable -r
scancode 0x0002 = KEY_POWER2 (0x164)
scancode 0x0004 = KEY_PROG3 (0xca)
scancode 0x0005 = KEY_IMAGES (0x1ba)
scancode 0x0006 = KEY_AUDIO (0x188)
Enabled protocols:

Alles anzeigen

ok, scheint geladen zu sein... geht aber trotzdem nicht mehr.

TCr82 · 9. September 2012

Evtl. liegt es daran:

/lib/udev/rc_keymaps/rc-medion-x10

Code

# table rc-medion-x10, type:other
0x0000 = KEY_MUTE
0x0002 = KEY_POWER2
0x0004 = KEY_PROG3
<<<<<<< HEAD
0x0005 = KEY_IMAGES
0x0006 = KEY_AUDIO
=======
0x0005 = KEY_AUDIO
0x0006 = KEY_MODE
>>>>>>> 7735beb593c1046cf91b955541f6b710e6916fcb
0x0008 = KEY_VOLUMEDOWN
0x0009 = KEY_VOLUMEUP
0x000b = KEY_CHANNELUP
0x000c = KEY_CHANNELDOWN
0x000d = KEY_1
0x000e = KEY_2
0x000f = KEY_3
0x0010 = KEY_4
0x0011 = KEY_5
0x0012 = KEY_6
0x0013 = KEY_7
0x0014 = KEY_8
0x0015 = KEY_9
0x0016 = KEY_SUBTITLE
0x0017 = KEY_0
<<<<<<< HEAD
0x0018 = KEY_TIME
0x0019 = KEY_PROG4
0x001a = KEY_UP
0x001b = KEY_SETUP
0x001c = KEY_TV
0x001d = KEY_LEFT
0x001e = KEY_OK
0x001f = KEY_RIGHT
0x0020 = KEY_FN
=======
0x0018 = KEY_VIDEO
0x0019 = KEY_TIME
0x001a = KEY_UP
0x001b = KEY_SETUP
0x001c = KEY_TV
0x001d = KEY_LEFT
0x001e = KEY_OK
0x001f = KEY_RIGHT
0x0020 = KEY_FN
=======
0x0018 = KEY_VIDEO
0x0019 = KEY_TIME
0x001a = KEY_UP
0x001b = KEY_SETUP
0x001c = KEY_IMAGES
0x001d = KEY_LEFT
0x001e = KEY_OK
0x001f = KEY_RIGHT
0x0020 = KEY_SCREEN
>>>>>>> 7735beb593c1046cf91b955541f6b710e6916fcb
0x0021 = KEY_BACK
0x0022 = KEY_DOWN
0x0023 = KEY_NEXT
0x0024 = KEY_REWIND
0x0025 = KEY_PLAY
0x0026 = KEY_FASTFORWARD
0x0027 = KEY_RECORD
0x0028 = KEY_STOP
0x0029 = KEY_PAUSE
0x002c = KEY_PROG1
0x002d = KEY_PVR
<<<<<<< HEAD
0x002e = KEY_RADIO
0x002f = KEY_EPG
0x0030 = KEY_CHANNEL
0x0031 = KEY_FAVORITES
>>>>>>> 7735beb593c1046cf91b955541f6b710e6916fcb
0x0032 = KEY_RED
0x0033 = KEY_GREEN
0x0034 = KEY_YELLOW
0x0035 = KEY_BLUE
0x0036 = KEY_INFO
0x0037 = KEY_MENU
0x0038 = KEY_ESC
<<<<<<< HEAD
0x0039 = KEY_SCREEN
0x003a = KEY_MODE
=======
0x0039 = KEY_FN
0x003a = KEY_PROG2
>>>>>>> 7735beb593c1046cf91b955541f6b710e6916fcb

Alles anzeigen

Schaut als als hätte es da ein patch fehler gegeben...

die <<< und >>> und ==== passen da glaub nicht rein?

seahawk1986 · 9. September 2012

Ich sehe gerade, dass da was beim mergen der Keytable schiefgegangen ist - ein neues yavdr-remote sollte bald gebaut sein, du kannst so lange diese Keytable nach /lib/udev/rc_keymaps/rc-medion-x10 kopieren: https://raw.github.com/yavdr/y…/rc_keymaps/rc-medion-x10

TCr82 · 9. September 2012

jupp, geht wieder nach:

Code

wget https://raw.github.com/yavdr/yavdr-remote/testing-0.5/rc_keymaps/rc-medion-x10 -O /lib/udev/rc_keymaps/rc-medion-x10
ir-keytable -c -w /lib/udev/rc_keymaps/rc-medion-x10

Danke auf jeden fall... nur eins was noch geklärt werden sollte:

Wieso die Mode-Line nicht mehr korrekt in der xorg.conf-yavdr landet.

seahawk1986 · 9. September 2012

Zitat von aLiEnTxC

ur eins was noch geklärt werden sollte:

Wieso die Mode-Line nicht mehr korrekt in der xorg.conf-yavdr landet.

Ja, da kann ich aber leider nichts zur Problemlösung beitragen (bei meinem Rechner klappt es), das Problem scheinen aber auch andere zu haben: [yaVDR 0.5-alpha1] Erkennung der Anzeigeeinstellung funktioniert nicht

TCr82 · 9. September 2012

nochmal danke fürs update von yavdr-remote... ist mittlerweile schon installiert (somit sind auch die manuellen Änderungen nicht mehr nötig)

Diverse Probleme nach den Update in 0.5-alpha1

Jetzt mitmachen!

Teilen

Benutzer online in diesem Thema