Bugzilla – Bug 551929
kvm keyboard+mouse disabled in X11 after zypper dup due to hald-addon-input not running
Last modified: 2010-04-13 15:16:51 UTC
Created attachment 325174 [details] Xorg log with sax-generated config User-Agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.8.1.23) Gecko/20090912 SUSE/1.1.18-1.2 SeaMonkey/1.1.18 On a Kernel-Virtual-Machine (KVM) after zypper dup from 11.1 both with SaX2-generated config and without xorg.conf there is no way to get X11 to accept input. Making it worse is that even Ctrl+Alt+F1 is not working to get to console (via kvm console command "sendkey ctrl-alt-f1"). Only thing that helped, was logging in via ssh and rcxdm stop. There keyboard and mouse(gpm) worked. There was a similar behaviour with VirtualBox without xorg.conf on RC1 which was fixed with RC2. Reproducible: Always Steps to Reproduce: 1. qemu-img create opensuse-11.2-dup.raw 8G qemu-kvm -m 2048 -net nic,model=e1000,macaddr=52:54:00:12:34:56 -net vde -hda opensuse-11.2-dup.raw -cdrom openSUSE-11.1-KDE4-LiveCD-i686.iso qemu-kvm -m 2048 -net nic,model=e1000,macaddr=52:54:00:12:34:56 -net vde -smp 4 -hda opensuse-11.2-dup.raw 2. do 11.1 updates 3. follow http://en.opensuse.org/index.php?title=Upgrade/11.2&oldid=108417 Actual Results: no keyboard/mouse works at all Expected Results: keyboard+mouse should work as in 11.1 (or a fresh install of 11.2-RC1 - not sure if I tried that)
evdev driver is not being loaded. No idea why. Maybe hald is not running? Please check this.
# ps ax|grep hal 1230 ? Ss 0:00 /usr/sbin/hald --daemon=yes 1240 ? S 0:00 hald-runner - I notice that on a working system there is such a thing as hald-addon-input: Listening on /dev/input/event0 ... so pretty likely there is something bad wil HALd causing this. # ll /dev/input/ insgesamt 0 drwxr-xr-x 2 root root 120 3. Nov 05:41 by-path crw-r----- 1 root root 13, 64 3. Nov 05:41 event0 crw-r----- 1 root root 13, 65 3. Nov 05:41 event1 crw-r----- 1 root root 13, 66 3. Nov 05:41 event2 crw-r----- 1 root root 13, 67 3. Nov 05:41 event3 crw-r----- 1 root root 13, 63 3. Nov 05:41 mice crw-r----- 1 root root 13, 32 3. Nov 05:41 mouse0 and restarting hald does not help either
Yes, I believe you need hald-addon-input running. Kay?
Sorry, I have no idea what this part of HAL is doing, or if it is needed.
Obviously it is needed. Question is. Why isn't it started?
When it's obvious, what does it do?
Without hald-addon-input running the Xserver doesn't load evdev driver for mouse/keyboard support. I can't say what hald-addon-input exactly does. For sure you know more about HAL than I do.
got another such case - this time in a VirtualBox system. installed gnome from official 11.1-DVD.iso, install updates, dup to factory-snapshot. no hal running there at all -> no mouse/keyboard in X11 and the only messages I see in /var/log are Nov 3 16:34:32 linux-ilbh kernel: [ 424.252053] powernow-k8: No frequency change capabilities detected Nov 3 16:34:32 linux-ilbh kernel: [ 424.355714] powernow: This module only works with AMD K7 CPUs Nov 3 16:34:32 linux-ilbh rchal: CPU frequency scaling is not supported by your processor. Nov 3 16:34:32 linux-ilbh rchal: boot with 'CPUFREQ=no' in to avoid this warning. Nov 3 16:34:33 linux-ilbh rchal: Cannot load cpufreq governors - No cpufreq driver available
this is why hald does not run on VBox: # /usr/sbin/hald --daemon=no Runner started - allowed paths are '/usr/lib/hal:/usr/lib/hal/scripts:/usr/bin' Run started hal-system-power-pm-is-supported (20000) (0) ! full path is '/usr/lib/hal/hal-system-power-pm-is-supported', program_dir is '/usr/lib/hal' pid 5000: rc=0 signaled=0: /usr/lib/hal/hal-system-power-pm-is-supported *** [DIE] device_info.c:rules_match_and_merge_device():1115 : Rule is NULL on jump
Is there some easy workaround for those that hit this bug? create a xorg.conf with loadmodule "evdev" or such? Even then, this could cause major headaches for users who dont know how to boot other runlevels from grub or dont know how to work there.
Just finished an Upgrade from a 11.1-full-DVD-install (7GB) to 11.2-RC2 via the DVD's upgrade method and see a similar effect (no keyboard+mouse (plus sometimes the screen even turns black)). hald running processes are very interesting there, too: 1336 ? Ss 0:00 /usr/sbin/hald --daemon=yes 1347 ? S 0:00 hald-runner 1473 ? S 0:00 /usr/lib/hal/hald-addon-macbook-backlight 1476 ? S 0:00 /usr/lib/hal/hald-addon-macbook-backlight 1477 ? S 0:00 /usr/lib/hal/hald-addon-macbook-backlight 1478 ? S 0:00 /usr/lib/hal/hald-addon-macbook-backlight 1479 ? S 0:00 /usr/lib/hal/hald-addon-macbook-backlight 1481 ? S 0:00 /usr/lib/hal/hald-addon-macbook-backlight 1482 ? S 0:00 /usr/lib/hal/hald-addon-macbook-backlight 1485 ? S 0:00 /usr/lib/hal/hald-addon-macbook-backlight 1489 ? S 0:00 /usr/lib/hal/hald-addon-macbook-backlight 1495 ? S 0:00 /usr/lib/hal/hald-addon-macbook-backlight 1498 ? S 0:00 /usr/lib/hal/hald-addon-macbook-backlight 1502 ? S 0:00 /usr/lib/hal/hald-addon-macbook-backlight 1503 ? S 0:00 /usr/lib/hal/hald-addon-macbook-backlight 1504 ? S 0:00 /usr/lib/hal/hald-addon-macbook-backlight 1505 ? S 0:00 /usr/lib/hal/hald-addon-macbook-backlight 1506 ? S 0:00 /usr/lib/hal/hald-addon-macbook-backlight 1507 ? S 0:00 /usr/lib/hal/hald-addon-macbook-backlight 1508 ? S 0:00 /usr/lib/hal/hald-addon-macbook-backlight 1509 ? S 0:00 /usr/lib/hal/hald-addon-macbook-backlight 1510 ? S 0:00 /usr/lib/hal/hald-addon-macbook-backlight 1511 ? S 0:00 /usr/lib/hal/hald-addon-macbook-backlight 1512 ? S 0:00 /usr/lib/hal/hald-addon-macbook-backlight 1513 ? S 0:00 /usr/lib/hal/hald-addon-macbook-backlight 1514 ? S 0:00 /usr/lib/hal/hald-addon-macbook-backlight 1515 ? S 0:00 /usr/lib/hal/hald-addon-macbook-backlight 1516 ? S 0:00 /usr/lib/hal/hald-addon-macbook-backlight 1518 ? S 0:00 /usr/lib/hal/hald-addon-macbook-backlight 1519 ? S 0:00 /usr/lib/hal/hald-addon-macbook-backlight 1536 ? S 0:00 /usr/lib/hal/hald-addon-macbook-backlight 1541 ? S 0:00 /usr/lib/hal/hald-addon-macbook-backlight 1542 ? S 0:00 /usr/lib/hal/hald-addon-macbook-backlight 1548 ? S 0:00 /usr/lib/hal/hald-addon-macbook-backlight 1550 ? S 0:00 /usr/lib/hal/hald-addon-macbook-backlight 1566 ? S 0:00 /usr/lib/hal/hald-addon-macbook-backlight 1578 ? S 0:00 /usr/lib/hal/hald-addon-macbook-backlight 1581 ? S 0:00 /usr/lib/hal/hald-addon-macbook-backlight 1584 ? S 0:00 /usr/lib/hal/hald-addon-macbook-backlight 1586 ? S 0:00 /usr/lib/hal/hald-addon-macbook-backlight 1589 ? S 0:00 /usr/lib/hal/hald-addon-macbook-backlight 1593 ? S 0:00 /usr/lib/hal/hald-addon-macbook-backlight 1610 ? S 0:00 /usr/lib/hal/hald-addon-macbook-backlight 1618 ? S 0:00 /usr/lib/hal/hald-addon-macbook-backlight 1623 ? S 0:00 /usr/lib/hal/hald-addon-macbook-backlight 1625 ? S 0:00 /usr/lib/hal/hald-addon-macbook-backlight 1631 ? S 0:00 /usr/lib/hal/hald-addon-macbook-backlight 2040 ? S 0:00 /usr/lib/hal/hald-addon-macbook-backlight
Created attachment 325652 [details] hald output from DVD upgrade in KVM
after another zypper dup, and rchal restart, hald-addon-input was started and X11 keyboard+mouse worked, even though, hal package was not updated. list of packages installed today: yast2-tv bundle-lang-kde-en bundle-lang-kde-de bundle-lang-kde-ar xorg-x11-server xorg-x11-libX11-ccache xorg-x11-Xvnc x11-input-wacom virtualbox-ose-kmp-default sax2-tools satsolver-tools preload-kmp-default preload polkit-gnome marble libkdepimlibs4 libkcompactdisc4 libkcddb4 kmix kdemultimedia4 kdebase4-workspace-ksysguardd kde4-kgreeter-plugins aria2 libbluetooth3 kopete-protocol-facebook ndiswrapper-kmp-default OpenOffice_org-ure xorg-x11-driver-virtualbox-ose xorg-x11-driver-video-radeonhd x11-input-wacom-tools sax2-libsax libzypp libkdepim4 libakonadi4 kscd kipi-plugins kio_audiocd kdepimlibs4 digikam amarok OpenOffice_org-writer bluez zypper sax2-libsax-perl sax2 python-kde4 libqdialogsolver1 korganizer knotes kdepim4 kdebase4-workspace akregator sax2-ident sax2-gui kupdateapplet kontact kmail kdm kdepim4-wizards kdeartwork4-screensaver kaddressbook NetworkManager-kde4-libs kwin kupdateapplet-packagekit NetworkManager-kde4 so I wonder, why hal suddenly started to work.
Oh, interesting. Let's hope it's just fine now. :)
Created attachment 327702 [details] hald output after zypper dup in KVM notable: "hald-addon-input" being started still 51 "hald-addon-macbook-backlight" processes started this time no text between "woohoo" strings
seen again after zypper dup from 11.1 to 11.2-final per http://en.opensuse.org/index.php?title=Upgrade/Supported&oldid=110950 no keyboard/mouse, even though there is a process hald-addon-input: Listening on /dev/input/event0 /dev/input/event2
The upgrade page had someone with a similar problem and I could verify that his workaround worked for me. Uncommenting in /etc/X11/xorg.conf option "AutoAddDevices" "off"
I've run into this one as well after upgrading my 11.0 to 11.2-final (x86_64). Using the 11.0 xorg.conf file and adding the option line specified in Comment 17 got it to work just fine. Hammering on it before I got to that point showed that evdev wasn't working correctly. Looking for hald-addon-input processes I do see this: 1939 ? S 0:00 hald-addon-input: Listening on /dev/input/event2 /dev/input/event1 /dev/input/event5 /dev/input/event3 Which isn't any of the input lines I'd expect it to be listening to.
I have just try the C17 option. Now (after digging several weeks) I can use the vmware console (directly or inside firefox ) without problems.. Many thanks for the tips.
*** Bug 585617 has been marked as a duplicate of this bug. ***
(In reply to comment #7) > Without hald-addon-input running the Xserver doesn't load evdev driver for > mouse/keyboard support. I can't say what hald-addon-input exactly does. For > sure you know more about HAL than I do. I don't think so. This addon only handle some special buttons/keys and update some hal properties and send a message via DBus if one of these buttons where pressed. If the Xserver depends on this addon, then we have a bug in the Xserver.
(In reply to comment #15) > Created an attachment (id=327702) [details] > hald output after zypper dup in KVM > > notable: "hald-addon-input" being started > still 51 "hald-addon-macbook-backlight" processes started > this time no text between "woohoo" strings Please provide full lshal output from this machine in this error case.
I might not have that VM anymore, but I did a new install+upgrade today with KVM and the 11.1+11.2 i686 DVD. On first try, choosing minimal X it worked, but on second try choosing KDE on 11.1-install, and doing some zypper up, HAL was not starting hald-addon-input after upgrade. # ps ax|grep hal 1122 ? Ss 0:00 /usr/sbin/hald --daemon=yes 1128 ? S 0:00 hald-runner
Created attachment 354061 [details] lshal output from KVM where no hald-addon-input started
Created attachment 354063 [details] full output from hald --daemon=no again two woohoo strings
Found another workaround http://kmandla.wordpress.com/2008/11/30/hal-xserver-153-and-allowemptyinput/ adding to /etc/X11/xorg.conf (which still exists from 11.1) in Section "ServerLayout" Option "AllowEmptyInput" "false" EndSection
(In reply to comment #25) > Created an attachment (id=354063) [details] > full output from hald --daemon=no > > again two woohoo strings You can ignore them, this is (useless) debug message from the storage prober.
(In reply to comment #24) > Created an attachment (id=354061) [details] > lshal output from KVM where no hald-addon-input started see comment #21. Looks as if your installation got mixed up (I have no idea why). Maybe a manual hald-generate-fdi-cache and a restart of HAL helps.
Btw. did you try if it works with a fresh 11.2 install and not 11.1 updated to 11.2?
/usr/lib/hal/hald-generate-fdi-cache did indeed help. afterwards, there are 3595 pts/2 S+ 0:00 hald-addon-input: Listening on /dev/input/event0 /dev/input/event3 3609 pts/2 S+ 0:00 hald-addon-storage: polling /dev/sr0 (every 16 sec) 3614 pts/2 S+ 0:00 hald-addon-acpi: listening on acpid socket /var/run/acpid.socket and keyboard+mouse work. This was also always fine on a fresh install of 11.2. So why did the upgrade not run hald-generate-fdi-cache ?
(In reply to comment #30) > So why did the upgrade not run hald-generate-fdi-cache ? It should be not needed since HAL should detect the changes of fdi-file automatically on restart. When we update the package for some other bugs, I will include a workaround on package installation.