You are not logged in.

#1 2014-03-26 10:08:39

quequotion
Member
From: Oita, Japan
Registered: 2013-07-29
Posts: 813
Website

[SOLVED] libevdev 1.0.1-1; disabled input at lightdm (actually in X)

Not actually a kernel or hardware issue, but easily mistaken for one (which forum is appropriate for that?)

Just ran into this invisible upgrade disaster a moment ago: libevdev doesn't provide /usr/lib/libevdev.so.1 so as soon as X loads (with lightdm in my case), the mouse and keyboard stop working.

I dug through the deepest crate in the darkest back corner of my closet to pull out an old PS/2 keyboard just to verify that it wasn't a problem with my unifying keyboard's USB transceiver driver (ie, a kernel problem).

Since there was no means to use the computer, I had to go in from a livecd and check the Xorg log (/var/log/Xorg.0.log) where I found several complaints of "/usr/lib/libevdev.so.1" not found.

To work around this I made a symlink from libevdev.so.2.0.0 to libevdev.so.1

$ cd /usr/lib
$ ln -s libevdev.so.2.0.0 libevdev.so.1

Posted in case anyone else runs across the same panic-inducing problem.

EDIT: fix may be too strong a word.

Last edited by quequotion (2014-03-26 14:01:19)

Offline

#2 2014-03-26 13:07:02

brain0
Developer
From: Aachen - Germany
Registered: 2005-01-03
Posts: 1,382

Re: [SOLVED] libevdev 1.0.1-1; disabled input at lightdm (actually in X)

First of all, this is not a correct solution. The reason that the libraries have a different major version numbers is that they are incompatible. Second, our Xorg stack currently does not use libevdev.

Offline

#3 2014-03-26 13:50:23

quequotion
Member
From: Oita, Japan
Registered: 2013-07-29
Posts: 813
Website

Re: [SOLVED] libevdev 1.0.1-1; disabled input at lightdm (actually in X)

brain0 wrote:

First of all, this is not a correct solution. The reason that the libraries have a different major version numbers is that they are incompatible. Second, our Xorg stack currently does not use libevdev.

I agree it isn't correct. The correct solution would be to have two libevdev packages that could be installed simultaneously and update packages that need the old version to depend on the legacy package, or for the single package that is available to provide an alias for the old library. Somehow neither has happened and by the time I could get either done myself, Xorg would be deprecated.

This is an interim hack until I can figure out why it had to be done, if I ever find a reason to do so. The point is, just in case anyone runs across the same problem this is one way to make their computer usable again. I've run across this specific type of problem fairly often; of course faking an old library isn't ideal and doesn't always work, but most of the time the newer library version is backwards-compatible. Sometimes this sort of hack is the only way to get around conflicting package versions (safer than forcing conflicting packages to install and overwrite each other). In the end it will probably be made irrelevant by the dependent package's migration to the newer library, and I'll have a redundant symlink to someday get around to deleting or forget about entirely.

I'm using xorg-server-git (xorg.server.1.15.0.627.gf34dc7f-1, not far from arch's version) which I should probably update.

Last edited by quequotion (2014-03-26 14:04:23)

Offline

#4 2014-05-03 22:26:42

quequotion
Member
From: Oita, Japan
Registered: 2013-07-29
Posts: 813
Website

Re: [SOLVED] libevdev 1.0.1-1; disabled input at lightdm (actually in X)

I keep having to do this after most upgrades (probably whenever evdev gets upgraded). Same problem, same solution.

As was pointed out, my solution is an interim hack (which happens to work without any percievable complications thus far).

Lightdm wants libevdev.so.1 and it's not there, which means evdev isn't installing correctly; there should either be a legacy package for it of which  I am unaware and that lightdm fails to depend on; lightdm should depend on libevdev.so instead; or... I have no idea..

Offline

#5 2014-07-22 22:42:52

quequotion
Member
From: Oita, Japan
Registered: 2013-07-29
Posts: 813
Website

Re: [SOLVED] libevdev 1.0.1-1; disabled input at lightdm (actually in X)

Ok, new problem:

Not only was libevdev.so.1 missing again, but this time I also upgraded Xorg and things are much worse.

Xorg.0.log says that the evdev module (evdev_drv.so, 2.9.0) was compiled for 1.15.1 (previous xorg version) and it's major ABI version is 20, which is not compatible with Xorg 1.16's 21...

So, input locks up as soon as lightdm loads. How can I install (compile?) a new version of evdev without keyboard or mouse access?

Offline

#6 2014-07-23 09:03:49

Padfoot
Member
Registered: 2010-09-03
Posts: 381

Re: [SOLVED] libevdev 1.0.1-1; disabled input at lightdm (actually in X)

Seems you have a mix of non official packages installed and that is causing your issue with dependency hell. I am using lightdm with xorg 1.15 and all is working perfectly. xorg pulls in xf86-input-evdev which in turn pulls in libevdev and all works as expected.

In your posts above, you have mentioned using a git version of xorg and in the last post xorg 1.16, neither of which are in the official repositories (xorg 1.16 is in testing, but breakage is expected when mixing testing with core).

Yes, lightdm should have a dependency on xorg-server (perhaps raise a packaging bug for that) but with the official packages it all works as expected. If you are going to install unofficial packages, ensure dependency versions match otherwise you will end up with breakaged just as you have now.

Suggest installing the official xorg and xf86-input-evdev and your system will thankyou.

Cheers.

Offline

#7 2014-07-23 11:41:54

quequotion
Member
From: Oita, Japan
Registered: 2013-07-29
Posts: 813
Website

Re: [SOLVED] libevdev 1.0.1-1; disabled input at lightdm (actually in X)

>>Padfoot
It's true, I brought this upon myself. I also found a way to recover from my folly. I try to excuse my obsessive hoarding of bleeding edge packages by equating it with the dangers of fronteir exploration: stupid, but necessary.

So, booting with the kernel parameter "single" triggers recovery mode, doesn't load xorg or evdev, and allows terminal access with a working keyboard driver.

The next trick was installing xf86-input-evdev-git, rebuilding it against the updated xorg-server-git. I probably didn't go about this the best way:

The PKGBUILD was still cached by aura. Perhaps I should have tried going through aura while logged in as root (recovery mode). Instead, I decided to run makepkg on the PKGBUILD, but root shouldn't do that, but  "sudo -u myself makepkg" worked.

Incidentally, I nearly lost hope when I couldn't get an internet connection (currently only available through a tethered android device) by dhcpcd; luckily I was able to activate NetworkManager.

Offline

Board footer

Powered by FluxBB