[SOLVED] possible problems with udev; systemd & slackware
SlackwareThis Forum is for the discussion of Slackware Linux.
Notices
Welcome to LinuxQuestions.org, a friendly and active Linux Community.
You are currently viewing LQ as a guest. By joining our community you will have the ability to post topics, receive our newsletter, use the advanced search, subscribe to threads and access many other special features. Registration is quick, simple and absolutely free. Join our community today!
Note that registered members see fewer ads, and ContentLink is completely disabled once you log in.
If you have any problems with the registration process or your account login, please contact us. If you need to reset your password, click here.
Having a problem logging in? Please visit this page to clear all LQ-related cookies.
Get a virtual cloud desktop with the Linux distro that you want in less than five minutes with Shells! With over 10 pre-installed distros to choose from, the worry-free installation life is here! Whether you are a digital nomad or just looking for flexibility, Shells can put your Linux machine on the device that you want to use.
Exclusive for LQ members, get up to 45% off per month. Click here for more info.
When dhcpcd loads, it reports 'dhcpcd[23625]: dlsym: /lib/dhcpcd/dev/udev.so: undefined symbol: dev_init' the developer of dhcpcd points to my version of udev.
So it is time to replace dhcpcd with ISC dhclient? Slackware bundles the ISC dhcp package anyway, so what is the point of using dhcpcd? It doesn't even support DHCPv6.
When dhcpcd loads, it reports 'dhcpcd[23625]: dlsym: /lib/dhcpcd/dev/udev.so: undefined symbol: dev_init' the developer of dhcpcd points to my version of udev.
The code that generates this error was introduced after dhcpcd 6.0.5 (version that ships with Slackware 14.1). You should mention your system is not stock Slackware.
To see if I could reproduce, I built dhcpcd 6.1.2, which does have the relevant code, on stock Slackware64-14.1.
Unlike yours, my dhcpcd looks for & finds udev.so in /usr/lib64/dhcpcd/dev (not /lib/dhcpcd/dev) and has no issue getting the address for dev_init (symbol confirmed present).
Technically you probably could import LFS's systemd-extracted udev package for Slackware, but you'd need to possibly adjust the scripts for the rule sets accordingly, and to install install other extras for things like gudev, gobject files, and keymaps you'd need their dependencies, which I know those require gobject-introspection, Glib, Gperf, as well as optionals like pciutils, usbutils, and acl to function.
I don't know how much of systemd-udev is different from classic udev, but from my experience with it, it works fairly much the same.
I build dhcpcd from source. I started doing it because I had a problem with dhcpcd and wanted to see if a custom build would solve it. I found out that my problem was my own ignorance about how dhcpcd worked. I keep on building my own version because I want its log entries to go to a file dedicated for that purpose, so I wrote a script to modify the source for that; I'm on the developer's mailing list so I get alerts of upgrades.
This particular problem, dev_init not being found, doesn't seem to cause me a problem. I told the dhcpcd developer in case the information would be of use to him; maybe a problem lurks. He suggested it could be my udev. That's what sent me to looking into more recent udev packages. I only mentioned it because enorbet asked. Finding out about the status of udev in Slackware filled my bill. I wasn't expecting a kind of Spanish Inquisition.
Ummm did I miss something? I didn't see anyone treat OP disrespectfully. The questions are either to gain advantage to help OP or oneself. Don't forget that even face-to-face speech can easily be misinterpreted. Text with zero body language even moreso. It seems wise to avoid being quick to taking offense online, IMHO.
Ummm did I miss something? I didn't see anyone treat OP disrespectfully. The questions are either to gain advantage to help OP or oneself. Don't forget that even face-to-face speech can easily be misinterpreted. Text with zero body language even moreso. It seems wise to avoid being quick to taking offense online, IMHO.
I don't know whether you missed anything. I didn't take offense; I didn't think anyone treated me disrespectfully; I didn't say anyone did.
I asked one question. I got an answer. Then enorbet asked me a peripheral question about why I wanted a new udev. I was glad to answer. Then people tried to diagnose the cause of the warning dhcpcd reported, the reason why I asked the original question. I didn't mind, but I didn't ask for it. I hoped that the reference to the Spanish Inquisition would tip readers to irony deployed for humorous purpose. Perhaps I'm too old: kids these days aren't up on their Monty Python.
I don't know whether you missed anything. I didn't take offense; I didn't think anyone treated me disrespectfully; I didn't say anyone did.
I asked one question. I got an answer. Then enorbet asked me a peripheral question about why I wanted a new udev. I was glad to answer. Then people tried to diagnose the cause of the warning dhcpcd reported, the reason why I asked the original question. I didn't mind, but I didn't ask for it. I hoped that the reference to the Spanish Inquisition would tip readers to irony deployed for humorous purpose. Perhaps I'm too old: kids these days aren't up on their Monty Python.
'Tis but a scratch
and now for something completely different -----
Quote:
Originally Posted by Linus Torvalds
I don't know where the problem started in udev, but the report I saw
was that udev175 was fine, and udev182 was broken, and would deadlock
if module_init() did a request_firmware(). That kind of nested
behavior is absolutely *required* to work, in order to not cause
idiotic problems for the kernel for no good reason.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.