udev-183-2 breaks X

Roken · 2012-05-27 16:07:00

Sorry - the logfile is gone so I can't post the exact error. However, upgraded udev to 183-2 today and X fails to start. A check of the logs showed that a udev library was not found (can't remember which one). Downgraded udev back to 182-4 and all is well.

Unfortunately, I tested with startx after downgrading, and then rebooted, so Xorg-0-log and .old have been overwritten (as has Xorg-1)

via Google I can't find anything. Are there any changes I need to be aware of?

xduugu · 2012-05-27 16:22:35

I guess your system/mirror is not up-to-date. xorg-server 1.12.1.902-2 was rebuild against the new udev package.
https://projects.archlinux.org/svntogit … 9690e89d95

Roken · 2012-05-27 16:38:59

Using catalyst - xorg 1.12 breaks that

falconindy · 2012-05-27 17:02:00

Then you need to recompile your own xorg-server.

Roken · 2012-05-28 19:24:58

OK, it gets stranger. I tried to launch truecrypt to mount one of my encrypted partitions and it failed with:

libudev.so.1: cannot open shared object file

locate libudev.so only showed /usr/lib/libudev.so, /usr/lib/libudev.so.0 and /usr/lib/libudev.so.0.13.1, which I find kinda odd. I manually created a link /usr/lib/libudev.so.1 to /usr/lib/libudev.so.0.13.1, which has got truecrypt working. However, googling gives me no information about this, and I have no idea either where the lib went, or if it ever existed at all, and nothing to suggest why truecrypt is only just failing.

What is the significance of .1 (rather than .0) and is there a cleaner fix? I'm pretty sure I can upgrade udev again if I can solve this.

xduugu · 2012-05-28 21:03:16

That's exactly the reason why partial upgrades are not supported. Truecrypt and many other packages are compiled against udev 183 and does not work with older udev versions anymore. You have two options: either perform a full system upgrade (pacman -Syu) or disable all testing repositories and run pacman -Syuu. The latter is only a temporary solution, though.

Roken · 2012-05-28 23:18:41

Except I haven't done a partial upgrade. With the exception of libasound (and now udev - since yesterday) I have everything updated, although I use the xorg111 repository for xorg to prevent the 1.12 breakage with catalyst. When catalyst works with 1.12 I'll update xorg as well.

I'll keep my question live, though, since it's something I've encountered without really understanding the significance. What is the significance of .so.1 libraries against .so.0?

Last edited by Roken (2012-05-28 23:19:50)

xduugu · 2012-05-28 23:40:13

In the end, it does not make a difference whether you hold the udev upgrade back or downgrade to an old package with a incompatible shared library.
The major version of the udev library was increased, because its not ABI-compatible with older releases. That's why several packages had to be recompiled against the new udev release.

http://cgit.freedesktop.org/systemd/systemd/tree/NEWS wrote:

* libudev no longer provides these symbols:
udev_monitor_from_socket()
udev_queue_get_failed_list_entry()
udev_get_{dev,sys,run}_path()
The versions number was bumped and symbol versioning introduced.

Roken · 2012-05-30 15:13:26

OK, after pacman telling me now that it was going to dump udev and replace it with systemd-tools I let it go ahead, and immediately had the same problem with libudev.so.0 (so.1 now gets put there with systemd-tools). This time I just reversed my previous fix, making a link from libudev.so to libudev.so.0 and tried again. This time X starts properly, and mounting removable drives, phone etc. all seem to work just fine. No obvious problems as yet.

It does seem that those of us tied to xorg111 will hit more problems in the future though. I wish they'd fix catalyst to work with xorg1.12 PDQ.

falconindy · 2012-06-01 18:49:00

Roken wrote:

It does seem that those of us tied to xorg111 will hit more problems in the future though. I wish they'd fix catalyst to work with xorg1.12 PDQ.

Or you know... you could just recompile xorg against the new udev.

jelly · 2012-06-01 18:51:53

Roken wrote:

OK, after pacman telling me now that it was going to dump udev and replace it with systemd-tools I let it go ahead, and immediately had the same problem with libudev.so.0 (so.1 now gets put there with systemd-tools). This time I just reversed my previous fix, making a link from libudev.so to libudev.so.0 and tried again. This time X starts properly, and mounting removable drives, phone etc. all seem to work just fine. No obvious problems as yet.
It does seem that those of us tied to xorg111 will hit more problems in the future though. I wish they'd fix catalyst to work with xorg1.12 PDQ.

That's more a problem of unsupported repo's not keeping up with official repo's.

Arch Linux

#1 2012-05-27 16:07:00

udev-183-2 breaks X

#2 2012-05-27 16:22:35

Re: udev-183-2 breaks X

#3 2012-05-27 16:38:59

Re: udev-183-2 breaks X

#4 2012-05-27 17:02:00

Re: udev-183-2 breaks X

#5 2012-05-28 19:24:58

Re: udev-183-2 breaks X

#6 2012-05-28 21:03:16

Re: udev-183-2 breaks X

#7 2012-05-28 23:18:41

Re: udev-183-2 breaks X

#8 2012-05-28 23:40:13

Re: udev-183-2 breaks X

#9 2012-05-30 15:13:26

Re: udev-183-2 breaks X

#10 2012-06-01 18:49:00

Re: udev-183-2 breaks X

#11 2012-06-01 18:51:53

Re: udev-183-2 breaks X

Board footer