[SOLVED] Switching from udev to eudev

Alien Bob · 11-20-2015, 02:51 PM

Switching from udev to eudev will fail using slackpkg. Use "installpkg /path/to/eudev ; installpkg /path/to/libgudev ; removepkg udev" instead, then proceed with your slackpkg commands as usual.

gordydawg · 11-20-2015, 03:06 PM

Quick question for eudev in -current. I am merely installing -current rather than upgrade as those braver than I are doing here.

The Changelog mentioned regenerating initrd to use eudev (if you're using generic kernel). I'm assuming that's loading a kernel module eudev when creating initrd.gz?

as in the following, with a partial initrd shown:

initrd -c -k 4.1.13 -m eudev ?

cathartes · 11-20-2015, 03:09 PM

Quote:

Originally Posted by speck

I'm not sure if this is an error or just a warning (things seem to be working fine), but I'm seeing the following message repeated a few times in /var/log/messages on pure 64bit current installed in a Virtualbox VM. The /lib/udev/pci-db file does not exist. I also tried to trace back to the files that may be related.

I encountered almost this exact problem following my -current update to eudev using slackpkg, yesterday evening. I resolved the issue by rebuilding the hardware database:

Code:

$ sudo /sbin/udevadm hwdb --update

Might this work for you?

Apart from that, my transition to eudev seems to have been seamless.

Olek · 11-20-2015, 03:11 PM

I found my mistake.
Previously i must made

Code:

upgradepkg eudev

Whitout "--install-new" eudev wasn't installed.

Now I was booted from pendrive, installed eudev and my keyboard working like normal.
Sorry for confusing You.

Alien Bob · 11-20-2015, 03:12 PM

Quote:

Originally Posted by gordydawg

Quick question for eudev in -current. I am merely installing -current rather than upgrade as those braver than I are doing here.

The Changelog mentioned regenerating initrd to use eudev (if you're using generic kernel). I'm assuming that's loading a kernel module eudev when creating initrd.gz?

as in the following, with a partial initrd shown:

initrd -c -k 4.1.13 -m eudev ?

There is no "eudev" kernel module. What is meant here, is that an initrd image contains udev. That will keep working of course, but if you want to get rid of udev in your initrd image then you will have to re-create it from scratch, in which case eudev will get added instead.

gordydawg · 11-20-2015, 03:15 PM

Quote:

Originally Posted by Alien Bob

There is no "eudev" kernel module. What is meant here, is that an initrd image contains udev. That will keep working of course, but if you want to get rid of udev in your initrd image then you will have to re-create it from scratch, in which case eudev will get added instead.

Thanks for clarifying!

Toutatis · 11-20-2015, 03:46 PM

Everything worked very well for me. I have just remarked some new messages with dmesg, but I don't see any consequence:

Quote:

[ 11.945375] udevd[539]: failed to execute '/lib/udev/pci-db' 'pci-db /devices/pci0000:00/0000:00:0a.0/0000:03:00.0': No such file or directory
[ 11.946198] udevd[540]: failed to execute '/lib/udev/pci-db' 'pci-db /devices/pci0000:00/0000:00:0a.0/0000:03:00.1': No such file or directory
[ 11.946229] udevd[541]: failed to execute '/lib/udev/pci-db' 'pci-db /devices/pci0000:00/0000:00:11.0': No such file or directory
[ 11.954266] udevd[542]: failed to execute '/lib/udev/pci-db' 'pci-db /devices/pci0000:00/0000:00:14.1': No such file or directory

cathartes · 11-20-2015, 03:51 PM

Quote:

Originally Posted by Toutatis

Everything worked very well for me. I have just remarked some new messages with dmesg, but I don't see any consequence:

Please see my reply to speck above. Does rebuilding the udev hardware database make these messages go away?

mralk3 · 11-20-2015, 03:59 PM

Quote:

Originally Posted by cathartes

Please see my reply to speck above. Does rebuilding the udev hardware database make these messages go away?

I previously had not upgraded aaa_elflibs. I did notice some errors in syslog so I upgraded aaa_elflibs and reinstalled all new eudev packages. I then rebuilt the hwdb with /sbin/udevadm hwdb --update. I rebooted and do not seem to have any errors in my syslog at this point.

speck · 11-20-2015, 04:15 PM

Quote:

Originally Posted by cathartes

I encountered almost this exact problem following my -current update to eudev using slackpkg, yesterday evening. I resolved the issue by rebuilding the hardware database:

Code:

$ sudo /sbin/udevadm hwdb --update

Might this work for you?

Thanks, that does seem to have removed the error messages. My udev-fu is pretty weak (I still think of HAL as being new).

bormant · 11-20-2015, 04:17 PM

Quote:

Originally Posted by volkerdi

Not one package on this long list actually links to libudev (.so.0 or .so.1).
...
I'd start by making sure that none of those updates were skipped somehow. If that doesn't clear it up then I suspect there's a custom compile somewhere that's pulling in libudev.so.0.

I'll try to recheck list manually so need some more time.

Quick and dirty smoke test:

Code:

# mkdir /tmp/t; cd /tmp/t
# M=http://slackware.osuosl.org/slackware-current
# wget -nv $M/{ChangeLog.txt,slackware/{l/vte-0.28.2-i486-3.txz,xfce/xfce4-session-4.12.1-i486-1.txz}}
2015-11-21 00:43:09 URL:http://slackware.osuosl.org/slackware-current/ChangeLog.txt [212083/212083] -> "ChangeLog.txt" [1]
2015-11-21 00:43:11 URL:http://slackware.osuosl.org/slackware-current/slackware/l/vte-0.28.2-i486-3.txz [371236/371236] -> "vte-0.28.2-i486-3.txz" [1]
2015-11-21 00:43:13 URL:http://slackware.osuosl.org/slackware-current/slackware/xfce/xfce4-session-4.12.1-i486-1.txz [617552/617552] -> "xfce4-session-4.12.1-i486-1.txz" [1]
FINISHED --2015-11-21 00:43:13--
Total wall clock time: 6.6s
Downloaded: 3 files, 1.1M in 4.9s (238 KB/s)

# explodepkg *t?z 
...
# md5sum {,/}usr/bin/vte
a6da38c5193a2b8fbaeba5225af4a386  usr/bin/vte
a6da38c5193a2b8fbaeba5225af4a386  /usr/bin/vte

# readelf -d /usr/bin/vte | grep libudev
 0x00000001 (NEEDED)                     Shared library: [libudev.so.0]

# md5sum {,/}usr/lib/{libxfsm-4.6.so.0.0.0,xfce4/session/splash-engines/{libbalou.so,libsimple.so,libmice.so}}
c8ba2b257481bb20f1462e853f9737e7  usr/lib/libxfsm-4.6.so.0.0.0
26531c16348a302fa1e2e034b1b9fca6  usr/lib/xfce4/session/splash-engines/libbalou.so
0044bb54bf008b44e9ba0cb270f6d0a5  usr/lib/xfce4/session/splash-engines/libsimple.so
9e14e43846fd7924309f311dbe5133fd  usr/lib/xfce4/session/splash-engines/libmice.so
c8ba2b257481bb20f1462e853f9737e7  /usr/lib/libxfsm-4.6.so.0.0.0
26531c16348a302fa1e2e034b1b9fca6  /usr/lib/xfce4/session/splash-engines/libbalou.so
0044bb54bf008b44e9ba0cb270f6d0a5  /usr/lib/xfce4/session/splash-engines/libsimple.so
9e14e43846fd7924309f311dbe5133fd  /usr/lib/xfce4/session/splash-engines/libmice.so

# for f in /usr/lib/{libxfsm-4.6.so.0.0.0,xfce4/session/splash-engines/{libbalou.so,libsimple.so,libmice.so}}; do \
 echo $f; readelf -d $f | grep libudev; done
/usr/lib/libxfsm-4.6.so.0.0.0
 0x00000001 (NEEDED)                     Shared library: [libudev.so.0]
/usr/lib/xfce4/session/splash-engines/libbalou.so
 0x00000001 (NEEDED)                     Shared library: [libudev.so.0]
/usr/lib/xfce4/session/splash-engines/libsimple.so
 0x00000001 (NEEDED)                     Shared library: [libudev.so.0]
/usr/lib/xfce4/session/splash-engines/libmice.so
 0x00000001 (NEEDED)                     Shared library: [libudev.so.0]

If I move /lib/libudev.so.0* somewhere and run startx then it says
xfce4-session: error while loading shared libraries: libudev.so.0: cannot open shared object file: No such file or directory

Toutatis · 11-20-2015, 04:17 PM

Quote:

Originally Posted by cathartes

Please see my reply to speck above. Does rebuilding the udev hardware database make these messages go away?

For me also the error messages disappeared.

volkerdi · 11-20-2015, 04:25 PM

I just put a couple of updates in -current that make some minor adjustments to fix the issues with hwdb --update and the missing pci-db called by udisks.

For anyone who hasn't yet upgraded to eudev, the best way to ensure success is to make sure that a) libudev.so.0 is not missing while anything still requires it, and b) that libudev.so.1 and libgudev-1.0.so.0 are already installed before anything needs them.

To accomplish a), make sure that you have the latest version of aaa_elflibs installed.
To accomplish b), install the eudev and libgudev packages next.

Then do the rest of the upgrades in any order that you like. The udev package can be safely removed any time after step a. Once you've done a) and b), doing the rest of the updates with slackpkg should work fine. I'll have to look into how slackpkg is trying to do things to see if it can be better prepared for 14.2...

volkerdi · 11-20-2015, 04:31 PM

Quote:

Originally Posted by bormant

I'll try to recheck list manually so need some more time.

Quick and dirty smoke test:

Code:

# mkdir /tmp/t; cd /tmp/t
# M=http://slackware.osuosl.org/slackware-current
# wget -nv $M/{ChangeLog.txt,slackware/{l/vte-0.28.2-i486-3.txz,xfce/xfce4-session-4.12.1-i486-1.txz}}
2015-11-21 00:43:09 URL:http://slackware.osuosl.org/slackware-current/ChangeLog.txt [212083/212083] -> "ChangeLog.txt" [1]
2015-11-21 00:43:11 URL:http://slackware.osuosl.org/slackware-current/slackware/l/vte-0.28.2-i486-3.txz [371236/371236] -> "vte-0.28.2-i486-3.txz" [1]
2015-11-21 00:43:13 URL:http://slackware.osuosl.org/slackware-current/slackware/xfce/xfce4-session-4.12.1-i486-1.txz [617552/617552] -> "xfce4-session-4.12.1-i486-1.txz" [1]
FINISHED --2015-11-21 00:43:13--
Total wall clock time: 6.6s
Downloaded: 3 files, 1.1M in 4.9s (238 KB/s)

# explodepkg *t?z 
...
# md5sum {,/}usr/bin/vte
a6da38c5193a2b8fbaeba5225af4a386  usr/bin/vte
a6da38c5193a2b8fbaeba5225af4a386  /usr/bin/vte

# readelf -d /usr/bin/vte | grep libudev
 0x00000001 (NEEDED)                     Shared library: [libudev.so.0]

# md5sum {,/}usr/lib/{libxfsm-4.6.so.0.0.0,xfce4/session/splash-engines/{libbalou.so,libsimple.so,libmice.so}}
c8ba2b257481bb20f1462e853f9737e7  usr/lib/libxfsm-4.6.so.0.0.0
26531c16348a302fa1e2e034b1b9fca6  usr/lib/xfce4/session/splash-engines/libbalou.so
0044bb54bf008b44e9ba0cb270f6d0a5  usr/lib/xfce4/session/splash-engines/libsimple.so
9e14e43846fd7924309f311dbe5133fd  usr/lib/xfce4/session/splash-engines/libmice.so
c8ba2b257481bb20f1462e853f9737e7  /usr/lib/libxfsm-4.6.so.0.0.0
26531c16348a302fa1e2e034b1b9fca6  /usr/lib/xfce4/session/splash-engines/libbalou.so
0044bb54bf008b44e9ba0cb270f6d0a5  /usr/lib/xfce4/session/splash-engines/libsimple.so
9e14e43846fd7924309f311dbe5133fd  /usr/lib/xfce4/session/splash-engines/libmice.so

# for f in /usr/lib/{libxfsm-4.6.so.0.0.0,xfce4/session/splash-engines/{libbalou.so,libsimple.so,libmice.so}}; do \
 echo $f; readelf -d $f | grep libudev; done
/usr/lib/libxfsm-4.6.so.0.0.0
 0x00000001 (NEEDED)                     Shared library: [libudev.so.0]
/usr/lib/xfce4/session/splash-engines/libbalou.so
 0x00000001 (NEEDED)                     Shared library: [libudev.so.0]
/usr/lib/xfce4/session/splash-engines/libsimple.so
 0x00000001 (NEEDED)                     Shared library: [libudev.so.0]
/usr/lib/xfce4/session/splash-engines/libmice.so
 0x00000001 (NEEDED)                     Shared library: [libudev.so.0]

If I move /lib/libudev.so.0* somewhere and run startx then it says
xfce4-session: error while loading shared libraries: libudev.so.0: cannot open shared object file: No such file or directory

Thanks, it appears there are indeed some problems only on the 32-bit side. Strangely, none of those things are linked to libudev on x86_64.

Looking into it now.

bgeer · 11-20-2015, 04:34 PM

Well, my 2 systems still appear to work. However...

I removed udev & installed eudev & libgudev in that order, than ran slackpkg update/install-new/upgrade-all which complained about gpg. I then turned GPG checking off (by editing /etc/slackpkg/slackpkg.conf) & completeed the slackpkg sequence.

I *may* have run "slackpkg update" prior to removing udev & installing eudev/libgudev...can't remember exactly. Maybe that was my problem with gpg.

Re-reading AlienBob's post #32, maybe I should have installed eudev/libgudev first, then removed udev.

After reboot, I had to run "sudo /sbin/udevadm hwdb --update" to get rid of the pci-db error.

Of course, I restored slackpkg.conf to GPG checking ON after all was said & done.

Also, I grabbed everything from my favorite mirror which I believe updates overnight, so any adjustments made today would not have been available yet.

Also, my 2 systems are 64-current.