Red Hat Bugzilla – Full Text Bug Listing
|Summary:||after fedup system upgrade: cannot open shared objects file libudev.so.0|
|Product:||[Fedora] Fedora||Reporter:||Tobias Vogel <tobias.vogel>|
|Component:||kdelibs||Assignee:||Ngo Than <than>|
|Status:||CLOSED ERRATA||QA Contact:||Fedora Extras Quality Assurance <extras-qa>|
|Version:||18||CC:||admiller, aquarichy, bjoern, dvratil, eturtiainen, ffesti, hackemaier, huygens, jeffsilverm, jgrulich, johannbg, jreznik, kevin, lnykryn, ltinkl, metherid, msekleta, ncrubel, notting, olli.jokinen, Panagiotis.Kavalagios, paulo.fidalgo.pt, rdieter, rnovacek, ry, smparrish, systemd-maint, than, tla, vpavlin, zpavlas|
|Fixed In Version:||4.9.5||Doc Type:||Bug Fix|
|Doc Text:||Story Points:||---|
|Last Closed:||2013-01-23 19:37:21 EST||Type:||Bug|
|oVirt Team:||---||RHEL 7.3 requirements from Atomic Host:|
Description Tobias Vogel 2012-12-17 19:21:40 EST
Description of problem: after a system upgrade using fedup from fedora 17 to 18-tc3 a kernel panic occurs, showing the following error: /init: error while loading shared libraries: libudev.so.0: cannot open shared object file: No such file or directory Version-Release number of selected component (if applicable): (kernel 3.6.10-4.fc18.x86_64)
Comment 1 Paulo Fidalgo 2012-12-28 12:41:51 EST
I do not have a kernel panic but KDE refusing to work due the missing lib. After creating a symlink between libudev.so.1 and libudev.so.0 it worked fine.
Comment 2 Björn Ruberg 2012-12-28 13:01:32 EST
It's not just KDE. The intel x11 driver ( xorg-x11-drv-intel ) refuses to load without the file. In Fedora 17 it is provided by libudev. But that packages is gone in Fedora 18. In the end this means that people using the intel driver and/or KDE will have no graphical environment after upgrade.
Comment 3 Björn Ruberg 2012-12-29 14:07:56 EST
Chrome from the Google-Reps will not work either. I have the problems on two i686 machines I upgraded to Fedora 18 via FedUp.
Comment 4 Paulo Fidalgo 2012-12-31 09:41:52 EST
The relevant part of Xorg.0.log: [ 13.386] (==) Assigned the driver to the xf86ConfigLayout [ 13.386] (II) LoadModule: "intel" [ 13.386] (II) Loading /usr/lib64/xorg/modules/drivers/intel_drv.so [ 13.386] (EE) Failed to load /usr/lib64/xorg/modules/drivers/intel_drv.so: libudev.so.0: cannot open shared object file: No such file or directory [ 13.386] (II) UnloadModule: "intel" [ 13.386] (II) Unloading intel [ 13.387] (EE) Failed to load module "intel" (loader failed, 7)
Comment 5 Paulo Fidalgo 2012-12-31 10:41:41 EST
I've solved the problem by using this command: yum distribution-synchronization --disablepresto Aparently there was an kdelibs left from fc17 and the intel driver as well.
Comment 6 Björn Ruberg 2013-01-02 06:45:13 EST
Yes, that helps. I guess fedUp should do this cleanup after applying the update. I think this bug deserves an high attention as fedUp will currently leave the system broken for a large number of users.
Comment 7 Will Woods 2013-01-02 13:02:06 EST
Fedup doesn't handle this sort of cleanup stuff itself; if there's a problem with the libudev symlinks that's a problem with the package that owns libudev. The tricky bit here is that in F17, libudev is provided by the 'libudev' package (which is a subpackage of udev). In F18, libudev is in systemd-libs. Somewhere between the two, a symlink is being lost (or not properly recreated). Reassigning to systemd.
Comment 8 Kay Sievers 2013-01-02 13:47:10 EST
There is no libudev.so.0 in Fedora 18, only a libudev.so.1. Technically there is nothing lost, it is just not available as udev did an SONAME bump. There cannot be a symlink with that name, as there is no libudev0 ABI provided in Fedora 18. The old libudev package would need to be installed, or a compat package with the old lib would need to be created. It cannot be done with the libudev version from systemd.
Comment 9 Will Woods 2013-01-02 14:02:56 EST
So this could indicate that some packages still need to be rebuilt against the new libudev (or rebuilt updates need to be pushed to the right places) - that's probably the case with Chrome, for instance. (In reply to comment #0) > after a system upgrade using fedup from fedora 17 to 18-tc3 a kernel panic > occurs, showing the following error: > > /init: error while loading shared libraries: libudev.so.0: cannot open > shared object file: No such file or directory Neither dracut initramfs nor the normal system uses /init; do you have some kind of custom boot setup that needs upgrading? (In reply to comment #1) > I do not have a kernel panic but KDE refusing to work due the missing lib. > After creating a symlink between libudev.so.1 and libudev.so.0 it worked > fine. So maybe KDE needs to be rebuilt (or otherwise fixed) to properly use libudev.so.1 - that'd be a kdelibs bug, though. Same for the intel driver problem. (In reply to comment #5) > I've solved the problem by using this command: yum > distribution-synchronization --disablepresto > > Aparently there was an kdelibs left from fc17 and the intel driver as well. Did the distro-sync remove the old kdelibs and intel driver?
Comment 10 Björn Ruberg 2013-01-02 14:11:19 EST
> Did the distro-sync remove the old kdelibs and intel driver? As far as I can tell from the yum.log just the fc18 packages were installed. There were some more than the previously mentioned ones. Many xorg drivers, java, mysql-libs and more. Whether all old versions of them require libudev.0.so I cannot say.
Comment 11 Paulo Fidalgo 2013-01-03 05:30:22 EST
> Did the distro-sync remove the old kdelibs and intel driver? yes, it updates to the fc18 version. Since the old version was linked against libudev.so.0, they cannot be loaded.
Comment 12 Tobias Vogel 2013-01-03 09:25:41 EST
Actually, when I reported the problem I was upgrading from fc17 system running Gnome 3 but I haven't had any kdelibs installed at all. There have occured several oddities though until I got my system back up and running. These are the steps I have taken to finally boot into the upgraded fc18 1) Created a bootable USB-stick to gain access to the system. 2) I had to change the boot-parameters of the bootloader on the stick, because the live-media would only boot if I changed the root-parameter from the label to the actual device (/dev/sdb1 in my case). 3) The installer didn't see the damaged installation which is why I had to escape the installer and chrooted to the system. 4) Doing a "yum clean all" & "yum update" updated a whole bunch of packages and finally solved the libudev-issue but at the same time mixed the pre-installed grub2-bios version with some grub2-efi configuration and messed up so the system got stuck at the grub-shell on the next reboot. 5) I chrooted back via the usb-media as described above, purged both installed grub packages and reinstalled grub2-bios. 6) Finally the system could boot but presented me with the next issue: it just wouldn't let me in. Relabeling the whole drive with the proper SELinux contexts did it.
Comment 13 Richard Schwarting 2013-01-08 01:51:01 EST
distro-sync fixes the problem here, too. F17 -> F18 via fedup. Should fedup do a distro-sync itself? Or when F18 is officially released, will the F18 package's version numbers be greater than F17's?
Comment 14 Lennart Poettering 2013-01-13 17:58:55 EST
I don't see anything to fix here in systemd. If the old library is lost but software depending on it still installed, then this appears to be a problem with the depdency resolver in yum, or somehow otherwise results in a installation with unsatisfied dependencies. The old F17 libudev package included libudev.so.0. On F18 libudev does not exist, but the systemd-libs package includes libudev.so.1. For the package manager these should hence be two entirely different libraries in two entirely different packages, and if they are missing it's the package managers fault. Reassigning to yum.
Comment 15 Rex Dieter 2013-01-15 16:53:54 EST
If a broken kdelibs upgrade path is involved, my fault. f17 kde-4.9.5 went to stable updates yesterday, anyone getting that, then upgrading to f18 today will get a broken upgrade path. f18 kde-4.9.5 is going stable now... that said, based on the evidence so far, hard to say what went wrong exactly. hint: anyone fixing this with distro-sync, if you can post which packages got upgraded/downgrade, that could help diagnose things more.
Comment 16 Todor Buyukliev 2013-01-16 10:25:11 EST
Created attachment 679659 [details] output of "yum distribution-synchronization".
Comment 17 Björn Ruberg 2013-01-16 10:44:48 EST
I did an update from Fedora 17 with KDE 4.9.5 to Fedora 18. Went well (after dist-sync of course). Yesterday the main problem of fedup upgrade before dist-sync upgrade was, that I was not able to login in kde but returned to kdm. So the problem with the intel drivers have been resolved, because X was at least working. Log of the dist sync after that upgrade follows.
Comment 18 Björn Ruberg 2013-01-16 10:45:54 EST
Created attachment 679660 [details] yum.log part of yum distribution-synchronization
Comment 19 Jaroslav Reznik 2013-01-16 10:52:11 EST
(In reply to comment #15) > If a broken kdelibs upgrade path is involved, my fault. > > f17 kde-4.9.5 went to stable updates yesterday, anyone getting that, then > upgrading to f18 today will get a broken upgrade path. > > f18 kde-4.9.5 is going stable now... > > > that said, based on the evidence so far, hard to say what went wrong exactly. > > hint: anyone fixing this with distro-sync, if you can post which packages > got upgraded/downgrade, that could help diagnose things more. Talking to michich today, looks like it is the problem - broken upgrade path.
Comment 20 Rex Dieter 2013-01-16 10:56:46 EST
Thanks for the details, fix is on the way then with: https://admin.fedoraproject.org/updates/FEDORA-2013-0163 sorry.
Comment 21 Rex Dieter 2013-01-16 11:12:22 EST
*** Bug 896095 has been marked as a duplicate of this bug. ***
Comment 22 Rex Dieter 2013-01-16 14:14:49 EST
*** Bug 896137 has been marked as a duplicate of this bug. ***
Comment 23 Kevin Kofler 2013-01-16 15:31:32 EST
"yum distro-sync" will fix it by downgrading KDE SC to 4.9.4; alternatively, you can issue these commands to get the F18 build of KDE SC 4.9.5 (which is the current version in F17 updates): yum install yum-security yum --advisory=FEDORA-2013-0163 update (yum-security provides the --advisory switch.) But FEDORA-2013-0163 is already queued for stable, so this should be sorted out soon.
Comment 24 Kevin Kofler 2013-01-16 18:12:17 EST
Actually, the correct commands are (until the update makes it through to stable): yum install yum-security yum --enablerepo=updates-testing --advisory=FEDORA-2013-0163 update (I forgot the --enablerepo=updates-testing.)
Comment 25 Kevin Kofler 2013-01-23 19:37:21 EST
FEDORA-2013-0163 was pushed to stable on January 16. It should have propagated to all mirrors by now.
Comment 26 Rahul Sundaram 2013-01-24 03:08:04 EST
I think to workaround these sort of problems, it is better if fedup ran yum distro-sync behind the scenes. It is always the safest method.
Comment 27 Jean-Christophe Berthon 2013-01-25 04:21:01 EST
I still add the problem when upgrading from F17 to F18 stable a few days ago. After a painful upgrade (see Bugs #902292 and #903998) I finally reached the KDE login screen but after entering my password the login silently failed and I was brought back to the graphic login prompt. I opened a console and checked the .xsession.errors and found out that KDE was requiring a libudev.so.0 which as you mentionned in this thread does not exist anymore in F18. So I have performed a 'sudo yum distro-sync' and it found new KDE package to install. Then after a reboot (I got a new kernel too), I was able to succesfully login. I am a techie, so this is an easy bug to circumvent. But for a normal user this is a show stopper! It needs urgent correction IMHO.
Comment 28 Esa Turtiainen 2013-01-28 12:16:04 EST
None of the previous tricks worked for me to get google-chrome working after upgrade to F18. The only thing that fixed it was cd /lib64; ln -s libudev.so.1.2.1 libudev.so.0
Comment 29 Björn Ruberg 2013-01-28 12:19:57 EST
Reinstalling google-chrome helps - at least it did for me. Probably you get an updated package that way.
Comment 30 Kevin Kofler 2013-01-28 13:42:27 EST
There are many completely unrelated issues which happen to result in the same error message being conflated in this bug report! I see at least the following: * an xorg-x11-drv-intel upgrade path issue leaving the F17 build (which was linked against the old libudev.so.0) installed, fixed on January 11 (before the official F18 release!) by https://admin.fedoraproject.org/updates/FEDORA-2012-20565 (which is already superseded by an even newer update), * a KDE SC upgrade path issue leaving the F17 builds (which were linked against the old libudev.so.0) installed, fixed on January 16 by https://admin.fedoraproject.org/updates/FEDORA-2013-0163, * an issue with Google Chrome, a proprietary package we do not ship, requiring the old libudev.so.0: This is NOT a Fedora bug at all, check Google's third-party repository for updated builds, and if there aren't any, please complain directly to Google about this issue. As far as I know, we fixed all the packages we were able to fix in Fedora. We cannot fix packages which are not actually part of Fedora.
Comment 31 Kevin Kofler 2013-01-28 13:45:08 EST
Oh, and if you have to manually reinstall the Google Chrome package to get an updated version, assuming you have the Google repository configured, that's also a packaging bug on Google's end (upgrade path issue: the new build apparently has the same or an older Epoch-Version-Release (EVR)) and needs to be reported to Google. (We cannot do anything about that.)
Comment 32 Jeff Silverman 2014-06-26 19:12:17 EDT
I have just installed Fedora 20 and Google Chrome 35 and I am running into the same problem. [jeff@jeff-linux ~]$ /opt/google/chrome/chrome /opt/google/chrome/chrome: error while loading shared libraries: libudev.so.0: cannot open shared object file: No such file or directory [jeff@jeff-linux ~]$ Furthermore, I have done [jeff@jeff-linux ~]$ sudo find / -name "libudev*" -print [sudo] password for jeff: /opt/google/chrome/libudev.so.0 /usr/lib64/libudev.so.1.4.0 /usr/lib64/libudev.so.1 find: ‘/run/user/1000/gvfs’: Permission denied [jeff@jeff-linux ~]$ ls -l /usr/lib64/libudev.so.1* lrwxrwxrwx. 1 root root 16 Jun 26 14:52 /usr/lib64/libudev.so.1 -> libudev.so.1.4.0 -rwxr-xr-x. 1 root root 73792 Jun 21 09:29 /usr/lib64/libudev.so.1.4.0 [jeff@jeff-linux ~]$ [jeff@jeff-linux ~]$ [jeff@jeff-linux ~]$ sudo ln -s /usr/lib64/libudev.so.1 /usr/lib/libudev.so.0 [jeff@jeff-linux ~]$ /opt/google/chrome/chrome /opt/google/chrome/chrome: error while loading shared libraries: libudev.so.0: cannot open shared object file: No such file or directory [jeff@jeff-linux ~]$ ls -l /usr/lib/libudev.so.0 lrwxrwxrwx. 1 root root 23 Jun 26 16:01 /usr/lib/libudev.so.0 -> /usr/lib64/libudev.so.1 [jeff@jeff-linux ~]$ [jeff@jeff-linux ~]$ rpm -q -p Downloads/google-chrome-stable_current_x86_64.rpm google-chrome-stable-35.0.1916.153-1.x86_64 [jeff@jeff-linux ~]$ Is this a Google issue or a Redhat issue? I find a discussion of the problem in Ubuntu mailing lists.
Comment 33 Rahul Sundaram 2014-06-26 19:15:18 EDT
You should report it to Google. Google Chrome isn't included in Fedora and can only be updated by Google.
Comment 34 Panos Kavalagios 2014-06-27 02:38:24 EDT
Jeff please do not report anything. Just use the correct command. According to the Google icon is: /usr/bin/google-chrome-stable which is a symlink to: /opt/google/chrome/google-chrome The command /opt/google/chrome/chrome produces the same error in my environment as well, whereas the above mentioned commands run fine.