Bug#783637: Installation fails because starting colord fails on missing libudev.so.0
The reason the upgrade failed when starting X was that colord couldn't start because it was missing libudev.so.0 as reported: "/usr/lib/colord/colord: error while loading shared libraries: libudev.so.0: cannot open shared object file: No such file or directory" colord also depends on libusb-1.0.so.0 in /usr/local/lib, see below: $ ldd /usr/lib/colord/colord|grep -E libudev\|libusb libusb-1.0.so.0 = /usr/local/lib/libusb-1.0.so.0 (0x7f08bcd66000) libudev.so.1 = /lib/x86_64-linux-gnu/libudev.so.1 (0x7f08bb256000) So why does colord complain about missing libudev.so.0 when ldd says it depends on libudev.so.1? So I think colord is looking for libusb-1.0.0.so.0 in the wrong place, using /usr/local/lib although you say nothing in debian uses /lib/local. libusb-1.0.so.0 is provided by package libusb-1.0-0: "File list of package libusb-1.0-0 in jessie of architecture amd64 /lib/x86_64-linux-gnu/libusb-1.0.so.0 /lib/x86_64-linux-gnu/libusb-1.0.so.0.1.0 /usr/share/doc/libusb-1.0-0/README /usr/share/doc/libusb-1.0-0/changelog.Debian.gz /usr/share/doc/libusb-1.0-0/changelog.gz /usr/share/doc/libusb-1.0-0/copyright" A symlink in /usr/local/lib to /usr/x86_64-linux-gnu/libusb-1.0.0.so.0 should be a valid fix, the files being the same: $ sudo ln -s /lib/x86_64-linux-gnu/libusb-1.0.so.0 /usr/local/lib/libusb-1.0.so.0 X starts correctly after doing this. (Others have had similar issues elsewhere: eg https://github.com/LightTable/LightTable/issues/161, and been rightly warned off linking different versions of libraries.) Probably this needs to be moved to a colord bug? Michael On Tue, 05 May 2015 23:29:06 +0300 Michael Tokarev m...@tls.msk.ru wrote: 05.05.2015 21:13, Michael Lager wrote: I can't remove libusb-1.0-0 package which provides libusb-1.0.so.0 because 93 packages depend on it including gdm3, gnome, cups and many others and that would render jessie practically useless. The version required by jessie is given as 2:1.0.19-1:amd64 and this is what is installed. So the symlink works. I told you the solution is to remove the library you installed manually in /usr/local/lib which is named libusb-1.0.so.0. No package in debian provides any library in /usr/local, all libs are installed to /usr/lib or /lib. The library you have in /usr/local/lib is not from debian, it is something you installed most likely from source. You shouldn't remove the debian-supplied library but the one you installed outside of debian. [] Anyway, the whole point was to say that the upgrade failed when trying to start the display manager and to suggest a cure. I don't think it was anything I installed that caused this. Have you a better one? The whole point is that what you did is WRONG. So if you don't listen to advise several people offered to you, at least others hopefully wont repeat your mistake after finding your "fix" in this bugreport. Thanks, /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org
Bug#783637: Installation fails because starting colord fails on missing libudev.so.0
Michael Lager, le Wed 06 May 2015 14:32:23 +0100, a écrit : The reason the upgrade failed when starting X was that colord couldn't start because it was missing libudev.so.0 as reported: /usr/lib/colord/colord: error while loading shared libraries: libudev.so.0: cannot open shared object file: No such file or directory colord also depends on libusb-1.0.so.0 in /usr/local/lib, see below: $ ldd /usr/lib/colord/colord|grep -E libudev\|libusb libusb-1.0.so.0 = /usr/local/lib/libusb-1.0.so.0 (0x7f08bcd66000) libudev.so.1 = /lib/x86_64-linux-gnu/libudev.so.1 (0x7f08bb256000) So why does colord complain about missing libudev.so.0 when ldd says it depends on libudev.so.1? Because colord also depends on libusb-1.0.so.0, and you have a /usr/local/lib/libusb-1.0.so.0 which comes from whatever you installed by hand. And *that /usr/local/lib/libusb-1.0.so.0 depends on libudev.so.0. That was the whole point of the objdump magic loop I asked you to run: objdump -x /usr/lib/colord/colord | grep NEEDED NEEDED libusb-1.0.so.0 /usr/local/lib/libusb-1.0.so.0 NEEDED libudev.so.0 *That* thing is the culprit. And it's not Debian which shipped it, you installed it by hand somehow. So I think colord is looking for libusb-1.0.0.so.0 in the wrong place, No, /usr/local/lib is expected to be looked for before /usr/lib, that's completely normal. using / usr/local/lib although you say nothing in debian uses /lib/local. Nothing in Debian *provides* anything int /usr/local/lib. So your /usr/local/lib/libusb-1.0.so.0 does not come from Debian. So the bug is not in Debian. libusb-1.0.so.0 is provided by package libusb-1.0-0: /lib/x86_64-linux-gnu/libusb-1.0.so.0 is, but /usr/local/lib/libusb-1.0.so.0 is not. A symlink in /usr/local/lib to /usr/x86_64-linux-gnu/libusb-1.0.0.so.0 should be a valid fix, It would be an odd fix. Just remove these libusb files from /usr/local/lib. (Others have had similar issues elsewhere: eg [1]https://github.com/LightTable/ LightTable/issues/161, and been rightly warned off linking different versions of libraries.) Yes. Mixing library versions is just asking for even more obscure bugs. Probably this needs to be moved to a colord bug? Again, colord is not a culprit at all here. Whatever made you put /usr/local/lib/libusb-1.0.so.0 is. Samuel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#783637: Installation fails because starting colord fails on missing libudev.so.0
This was an upgrade from debian wheezy to jessie and a report (as requested) on how it went. I just hope this can be put right for others wishing to upgrade and finding it doesn't work. My work-around was to create a symbolic link (result as below) for the missing file based on the pattern for symbolic links elsewhere: jessie now works OK. $ ll|grep udev lrwxrwxrwx 1 root root 21 Apr 16 16:53 libgudev-1.0.so.0 - libgudev-1.0.so.0.2.0 -rw-r--r-- 1 root root42920 Apr 16 16:53 libgudev-1.0.so.0.2.0 lrwxrwxrwx 1 root root 38 Apr 16 16:53 libudev.so - /lib/x86_64-linux-gnu/libudev.so.1.5.0 lrwxrwxrwx 1 root root 10 Apr 28 11:10 libudev.so.0 - libudev.so lrwxrwxrwx 1 root root 12 Apr 29 10:34 libudev.so.1 - libudev.so.0 Michael On Mon, 4 May 2015 18:04:02 +0200 Samuel Thibault sthiba...@debian.org wrote: Michael Lager, le Mon 04 May 2015 12:54:14 +0100, a écrit : /usr/local/lib/libusb-1.0.so.0 NEEDED libudev.so.0 NEEDED librt.so.1 NEEDED libpthread.so.0 NEEDED libc.so.6 dpkg-query: no path found matching pattern /usr/local/lib/libusb-1.0.so.0 We can not support the dependencies of locally-installed software. Either remove that software, or install the required dependencies (here, fetch the libudev0 package from wheezy) Samuel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#783637: Installation fails because starting colord fails on missing libudev.so.0
05.05.2015 14:55, Michael Lager wrote: This was an upgrade from debian wheezy to jessie and a report (as requested) on how it went. I just hope this can be put right for others wishing to upgrade and finding it doesn't work. My work-around was to create a symbolic link (result as below) for the missing file based on the pattern for symbolic links elsewhere: jessie now works OK. $ ll|grep udev lrwxrwxrwx 1 root root 21 Apr 16 16:53 libgudev-1.0.so.0 - libgudev-1.0.so.0.2.0 -rw-r--r-- 1 root root42920 Apr 16 16:53 libgudev-1.0.so.0.2.0 lrwxrwxrwx 1 root root 38 Apr 16 16:53 libudev.so - /lib/x86_64-linux-gnu/libudev.so.1.5.0 lrwxrwxrwx 1 root root 10 Apr 28 11:10 libudev.so.0 - libudev.so lrwxrwxrwx 1 root root 12 Apr 29 10:34 libudev.so.1 - libudev.so.0 So for someone who finds this, don't do this, this is WRONG. The libs are named the way they are for a purpose, because symbols in libudev.so.0 are not compatible with these in libudev.so.1 and so on. Sometimes such symlinking makes some executable to start so seemingly this smells like a solution, but it is quite possible that this executable will just crash when asked to do something real. Sometimes this doesn't work at all. This has nothing to do with upgrade from wheezy to jessie really. You have locally installed alternative libusb-1.0.so.0. This library is not recorded in the dpkg database so apt/dpkg doesn't know about it and doesn't know that it needs libudev.so.0. This is a library you installed manually. The solution is to either install libudev0 package to make your libusb-1.0 to work (and maybe record that libudev0 is needed so it wont be removed by a chance), or, better yet, just remove your libusb-1.0, because jessie comes with its own, most likely never version, and together with support. Your situation is rare, because it is uncommon to install 3rd party libraries like this, and even less common to come across such an issue. But the solution you offered is _wrong_. Thanks, /mjt On Mon, 4 May 2015 18:04:02 +0200 Samuel Thibault sthiba...@debian.org wrote: Michael Lager, le Mon 04 May 2015 12:54:14 +0100, a écrit : /usr/local/lib/libusb-1.0.so.0 NEEDED libudev.so.0 NEEDED librt.so.1 NEEDED libpthread.so.0 NEEDED libc.so.6 dpkg-query: no path found matching pattern /usr/local/lib/libusb-1.0.so.0 We can not support the dependencies of locally-installed software. Either remove that software, or install the required dependencies (here, fetch the libudev0 package from wheezy) Samuel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#783637: Installation fails because starting colord fails on missing libudev.so.0
I can't remove libusb-1.0-0 package which provides libusb-1.0.so.0 because 93 packages depend on it including gdm3, gnome, cups and many others and that would render jessie practically useless. The version required by jessie is given as 2:1.0.19-1:amd64 and this is what is installed. So the symlink works. libudev0 package is not in jessie, only wheezy. jessie has libudev1. The other missing library was reported as : linux-vdso.so.1 objdump: 'linux-vdso.so.1': No such file dpkg-query: no path found matching pattern *linux-vdso.so.1* Anyway, the whole point was to say that the upgrade failed when trying to start the display manager and to suggest a cure. I don't think it was anything I installed that caused this. Have you a better one? Michael On Tue, 05 May 2015 15:42:08 +0300 Michael Tokarev m...@tls.msk.ru wrote: 05.05.2015 14:55, Michael Lager wrote: This was an upgrade from debian wheezy to jessie and a report (as requested) on how it went. I just hope this can be put right for others wishing to upgrade and finding it doesn't work. My work-around was to create a symbolic link (result as below) for the missing file based on the pattern for symbolic links elsewhere: jessie now works OK. $ ll|grep udev lrwxrwxrwx 1 root root 21 Apr 16 16:53 libgudev-1.0.so.0 - libgudev-1.0.so.0.2.0 -rw-r--r-- 1 root root 42920 Apr 16 16:53 libgudev-1.0.so.0.2.0 lrwxrwxrwx 1 root root 38 Apr 16 16:53 libudev.so - /lib/x86_64-linux-gnu/libudev.so.1.5.0 lrwxrwxrwx 1 root root 10 Apr 28 11:10 libudev.so.0 - libudev.so lrwxrwxrwx 1 root root 12 Apr 29 10:34 libudev.so.1 - libudev.so.0 So for someone who finds this, don't do this, this is WRONG. The libs are named the way they are for a purpose, because symbols in libudev.so.0 are not compatible with these in libudev.so.1 and so on. Sometimes such symlinking makes some executable to start so seemingly this smells like a solution, but it is quite possible that this executable will just crash when asked to do something real. Sometimes this doesn't work at all. This has nothing to do with upgrade from wheezy to jessie really. You have locally installed alternative libusb-1.0.so.0. This library is not recorded in the dpkg database so apt/dpkg doesn't know about it and doesn't know that it needs libudev.so.0. This is a library you installed manually. The solution is to either install libudev0 package to make your libusb-1.0 to work (and maybe record that libudev0 is needed so it wont be removed by a chance), or, better yet, just remove your libusb-1.0, because jessie comes with its own, most likely never version, and together with support. Your situation is rare, because it is uncommon to install 3rd party libraries like this, and even less common to come across such an issue. But the solution you offered is _wrong_. Thanks, /mjt On Mon, 4 May 2015 18:04:02 +0200 Samuel Thibault sthiba...@debian.org wrote: Michael Lager, le Mon 04 May 2015 12:54:14 +0100, a écrit : /usr/local/lib/libusb-1.0.so.0 NEEDED libudev.so.0 NEEDED librt.so.1 NEEDED libpthread.so.0 NEEDED libc.so.6 dpkg-query: no path found matching pattern /usr/local/lib/libusb-1.0.so.0 We can not support the dependencies of locally-installed software. Either remove that software, or install the required dependencies (here, fetch the libudev0 package from wheezy) Samuel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#783637: Installation fails because starting colord fails on missing libudev.so.0
05.05.2015 21:13, Michael Lager wrote: I can't remove libusb-1.0-0 package which provides libusb-1.0.so.0 because 93 packages depend on it including gdm3, gnome, cups and many others and that would render jessie practically useless. The version required by jessie is given as 2:1.0.19-1:amd64 and this is what is installed. So the symlink works. I told you the solution is to remove the library you installed manually in /usr/local/lib which is named libusb-1.0.so.0. No package in debian provides any library in /usr/local, all libs are installed to /usr/lib or /lib. The library you have in /usr/local/lib is not from debian, it is something you installed most likely from source. You shouldn't remove the debian-supplied library but the one you installed outside of debian. [] Anyway, the whole point was to say that the upgrade failed when trying to start the display manager and to suggest a cure. I don't think it was anything I installed that caused this. Have you a better one? The whole point is that what you did is WRONG. So if you don't listen to advise several people offered to you, at least others hopefully wont repeat your mistake after finding your fix in this bugreport. Thanks, /mjt -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#783637: Installation fails because starting colord fails on missing libudev.so.0
Hi - thanks.
Requested information:
objdump -x /usr/lib/colord/colord | grep NEEDED
NEEDED libm.so.6
NEEDED libsqlite3.so.0
NEEDED libpolkit-gobject-1.so.0
NEEDED liblcms2.so.2
NEEDED libgudev-1.0.so.0
NEEDED libgusb.so.2
NEEDED libusb-1.0.so.0
NEEDED libsystemd.so.0
NEEDED libcolordprivate.so.2
NEEDED libgthread-2.0.so.0
NEEDED libgio-2.0.so.0
NEEDED libgobject-2.0.so.0
NEEDED libgmodule-2.0.so.0
NEEDED libglib-2.0.so.0
NEEDED libpthread.so.0
NEEDED libc.so.6
and ...
for i in $(ldd /usr/lib/colord/colord | cut -d '' -f 2 | cut -d '('
-f 1) ; do echo $i ; objdump -x $i | grep NEEDED ; dpkg -S $i ; done
linux-vdso.so.1
objdump: 'linux-vdso.so.1': No such file
dpkg-query: no path found matching pattern *linux-vdso.so.1*
/lib/x86_64-linux-gnu/libm.so.6
NEEDED libc.so.6
libc6:amd64: /lib/x86_64-linux-gnu/libm.so.6
/usr/lib/x86_64-linux-gnu/libsqlite3.so.0
NEEDED libpthread.so.0
NEEDED libdl.so.2
NEEDED libc.so.6
libsqlite3-0:amd64: /usr/lib/x86_64-linux-gnu/libsqlite3.so.0
/usr/lib/x86_64-linux-gnu/libpolkit-gobject-1.so.0
NEEDED libgio-2.0.so.0
NEEDED libgobject-2.0.so.0
NEEDED libglib-2.0.so.0
NEEDED libsystemd.so.0
NEEDED libpthread.so.0
NEEDED libc.so.6
libpolkit-gobject-1-0:amd64:
/usr/lib/x86_64-linux-gnu/libpolkit-gobject-1.so.0
/usr/lib/x86_64-linux-gnu/liblcms2.so.2
NEEDED libm.so.6
NEEDED libpthread.so.0
NEEDED libc.so.6
liblcms2-2:amd64: /usr/lib/x86_64-linux-gnu/liblcms2.so.2
/usr/lib/x86_64-linux-gnu/libgudev-1.0.so.0
NEEDED libudev.so.1
NEEDED libgio-2.0.so.0
NEEDED libgobject-2.0.so.0
NEEDED libglib-2.0.so.0
NEEDED libdl.so.2
NEEDED libpthread.so.0
NEEDED libc.so.6
libgudev-1.0-0:amd64: /usr/lib/x86_64-linux-gnu/libgudev-1.0.so.0
/usr/lib/x86_64-linux-gnu/libgusb.so.2
NEEDED libgthread-2.0.so.0
NEEDED libgio-2.0.so.0
NEEDED libusb-1.0.so.0
NEEDED libgudev-1.0.so.0
NEEDED libgobject-2.0.so.0
NEEDED libglib-2.0.so.0
NEEDED libpthread.so.0
NEEDED libc.so.6
libgusb2:amd64: /usr/lib/x86_64-linux-gnu/libgusb.so.2
/usr/local/lib/libusb-1.0.so.0
NEEDED libudev.so.0
NEEDED librt.so.1
NEEDED libpthread.so.0
NEEDED libc.so.6
dpkg-query: no path found matching pattern /usr/local/lib/libusb-1.0.so.0
/lib/x86_64-linux-gnu/libsystemd.so.0
NEEDED librt.so.1
NEEDED liblzma.so.5
NEEDED libgcrypt.so.20
NEEDED libresolv.so.2
NEEDED libdl.so.2
NEEDED libpthread.so.0
NEEDED libc.so.6
NEEDED ld-linux-x86-64.so.2
libsystemd0:amd64: /lib/x86_64-linux-gnu/libsystemd.so.0
/usr/lib/x86_64-linux-gnu/libcolordprivate.so.2
NEEDED libm.so.6
NEEDED libudev.so.1
NEEDED liblcms2.so.2
NEEDED libgthread-2.0.so.0
NEEDED libgio-2.0.so.0
NEEDED libgobject-2.0.so.0
NEEDED libgmodule-2.0.so.0
NEEDED libglib-2.0.so.0
NEEDED libpthread.so.0
NEEDED libc.so.6
libcolord2:amd64: /usr/lib/x86_64-linux-gnu/libcolordprivate.so.2
/usr/lib/x86_64-linux-gnu/libgthread-2.0.so.0
NEEDED libpthread.so.0
NEEDED libglib-2.0.so.0
NEEDED libc.so.6
libglib2.0-0:amd64: /usr/lib/x86_64-linux-gnu/libgthread-2.0.so.0
/usr/lib/x86_64-linux-gnu/libgio-2.0.so.0
NEEDED libgobject-2.0.so.0
NEEDED libgmodule-2.0.so.0
NEEDED libglib-2.0.so.0
NEEDED libz.so.1
NEEDED libselinux.so.1
NEEDED libresolv.so.2
NEEDED libc.so.6
libglib2.0-0:amd64: /usr/lib/x86_64-linux-gnu/libgio-2.0.so.0
/usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
NEEDED libglib-2.0.so.0
NEEDED libffi.so.6
NEEDED libc.so.6
libglib2.0-0:amd64: /usr/lib/x86_64-linux-gnu/libgobject-2.0.so.0
/usr/lib/x86_64-linux-gnu/libgmodule-2.0.so.0
NEEDED libdl.so.2
NEEDED libglib-2.0.so.0
NEEDED libc.so.6
libglib2.0-0:amd64: /usr/lib/x86_64-linux-gnu/libgmodule-2.0.so.0
/lib/x86_64-linux-gnu/libglib-2.0.so.0
NEEDED libpcre.so.3
NEEDED libpthread.so.0
NEEDED libc.so.6
Bug#783637: Installation fails because starting colord fails on missing libudev.so.0
Michael Lager outbo...@lager.freeserve.co.uk (2015-05-04): dpkg-query: no path found matching pattern /usr/local/lib/libusb-1.0.so.0 Here's your problem. On a jessie system, this file (located under /usr/lib rather than /usr/local/lib), has a dependency on libudev.so.1 instead of libudev.so.0. Move it aside (or delete it entirely), and enjoy. Mraw, KiBi. signature.asc Description: Digital signature
Bug#783637: Installation fails because starting colord fails on missing libudev.so.0
Michael Lager, le Mon 04 May 2015 12:54:14 +0100, a écrit : /usr/local/lib/libusb-1.0.so.0 NEEDED libudev.so.0 NEEDED librt.so.1 NEEDED libpthread.so.0 NEEDED libc.so.6 dpkg-query: no path found matching pattern /usr/local/lib/libusb-1.0.so.0 We can not support the dependencies of locally-installed software. Either remove that software, or install the required dependencies (here, fetch the libudev0 package from wheezy) Samuel -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#783637: Installation fails because starting colord fails on missing libudev.so.0
See attached.
Err, this is really not the way to submit bug reports: just copy/paste
the text in the mail, that'll make it *way* easier to process for
everybody.
Boot method: Upgrade from Debian 7.8 in terminal inside Firefox via network?
So this is not actually an installation.
2. on first boot system presented blank screen with underscore in top left
corner, but nothing moved; Ctrl-F1 brought login, which worked giving access
to system. On investigation, /var/log/syslog.1 contains:
Apr 28 07:46:34 master dbus[791]: [system] Activating via systemd: service
name='org.freedesktop.ColorManager' unit='colord.service'
Apr 28 07:46:34 master colord[8935]: /usr/lib/colord/colord: error while
loading shared libraries: libudev.so.0: cannot open shared object file: No
such file or directory
Apr 28 07:46:34 master systemd[1]: colord.service: main process exited,
code=exited, status=127/n/a
Apr 28 07:46:34 master systemd[1]: Failed to start Manage, Install and
Generate Color Profiles.
Apr 28 07:46:34 master systemd[1]: Unit colord.service entered failed state.
There is no libudev.so.0
There is /lib/x86_64-linux-gnu/libudev.so.1
So some binary has bogus dependencies. That's what we need to track.
1. script was taken: click on
https://drive.google.com/file/d/0ByWd4khD1zRxS001bzJoeWVIQUk/view?usp=sharing
and
Notably,
Selecting previously unselected package libcolord2:amd64.^M
Preparing to unpack .../libcolord2_1.2.1-1+b2_amd64.deb ...^M
And this version does not directly depend on libudev, but on libgudev,
and:
Preparing to unpack .../libgudev-1.0-0_215-17_amd64.deb ...^M
Unpacking libgudev-1.0-0:amd64 (215-17) over (204-14~bpo70+1) ...^M
But this version depends on libudev.so.1, not libudev.so.0, so there's
something from happening.
Please post the output of:
objdump -x /usr/lib/colord/colord | grep NEEDED
and:
for i in $(ldd /usr/lib/colord/colord | cut -d '' -f 2 | cut -d '(' -f 1) ;
do echo $i ; objdump -x $i | grep NEEDED ; dpkg -S $i ; done
Samuel
--
To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#783637: Installation fails because starting colord fails on missing libudev.so.0
Package: installation-reports Version: jessie See attached. Debian 8 installation report.odt Description: application/vnd.oasis.opendocument.text Debian 8 installation report.20150428.pdf Description: Adobe PDF document
