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.
Problem: My computer boots in 3m:9s, 2m:12s of which is spent by udev initialising itself or whatever it does. This is absolutely ridiculous. How do I fix it?
I don't even know why udev is being used. Before I changed to the 2.6 line of kernels, devfs was used, and I thought devfs was merely deprecated with 2.6. I've tried and tried to get devfs back, but no such luck. Otoh, the little I've been able to understand of what I've read about udev makes me think udev is a better system, and that it would be more desirable to get udev working properly instead of going back to devfs.
Experience level: I've been a linux user for several years now, but am still mostly a semi-competent curious newbie who likes to rtfm.
Caveats: My linux box is a wreck, and has been since January (the withdrawal symptoms still haven't dissipated). I'm forced to use this winbox for anything more productive than timing udev. This means any screen output you want to see has to be captured by camera and uploaded via my dial-up connection. I've got the time if you've got the time.
And as an aside, if you are now at 2.6.13 or later you can't go back to devfs. As of that release, it is not only deprecated, but gone.
Well, the code was still there, but ...
According to udevinfo, I'm using 0.26. Should I upgrade to 0.91 (latest)?
According to /etc/udev/udev.conf, logging is enabled. Where is the log kept? "slocate udev" doesn't turn up anything that looks like a log, and nothing jumped out at me in /var/log/.
Re-reading through some udev information, I'm seeing all kinds of stuff about udev rule files and what not. Excuse the probably stupid question, but do I need to make one? I assumed an unoptimised setup would be in place by default (err, just not this inefficient..). If so, then any links to friendly guides to setting up udev that you guys have offhand would be appreciated (just in case I miss them when googling).
syg00-- You have saved my sanity. I would've sworn I used devfs when I first switched, back in 2.6.9 era. Now I'm at 2.6.15 .
satinet-- I don't think I have any wierd hardware. Just the K8n4-e deluxe mainboard, athlon 64 processor, and an Radeon x300 gfx card. Technical specs are linked to in my sig.
I cut my udev time to near nothingness by recompiling the kernel with as much builtin as possible. Since hotplug has less modules it needs to try, it takes less time.
As of the more recent udev releases, hotplug isn't even used anymore.
026 is a VERY early release(Infact kernels 2.6.16+ require 071 or higher, and even they are fairly old). Slackware is ancient in it's support for udev.
I know that using Udev 090 on my slackware 10.0 box with a self built 2.6.16 kernel, my boot time is significantly faster than when on 2.4 using hotplug.
the udev in -current has been upgraded to 0.71 to conform the minimum requirement for 2.6.16.9 kernel. I'm using Piter Punk's udev (0.90) and it worked here
The version of udev you report comes from Slackware 10.0, released in Jun 2004. That's quite old for a Slackware system and I would advise you that if the command:
cat /etc/slackware-version
reports 10.0, you should update incrementally to 10.1, 10.2 etc. FIRST before jumping straight in with a high-numbered version of udev. The chances are that your problems stem not just from the version of udev but associated libraries, kernel modules, etc. that are trying to load. Upgrading incrementally will ensure that all libraries etc. are in line with each other.
Additionally, there are likely to be severe security issues with software that old unless you've been updating it regularly (even 10.0 is still having security fixes released for it as evidenced by it's changelog: http://download.mirror.ac.uk/sites/f...ChangeLog.txt).
However, your sig seems to indicate that this computer is slowly being left to rot, which will make EVERYTHING on it ten times harder. This is like complaining that your computer is slow to boot up when you're still running Windows 98.
Personally, I'd wipe it and start afresh with either Slackware 10.2 (if you want a guaranteed working system) or Slackware-current (if you want the thing to work and have the VERY latest version of everything). Or wait for Slackware 11.0. Wiping and restarting is going to be a lot easier than trying to slowly upgrade this machine until things start to work properly again.
Oops. And the memories all come back. I used to have Slack 10, then I upgraded all my hardware, downloaded Slack 10.2, used the sata.i kernel without installing 10.2, forgot I didn't upgrade, started personalising whatever latest (stable) kernel I could get my hands on, and everything broke.
I'll be back in an hour or so after I install 10.2..
Correct me if I'm wrong but I think you would still need hotplug working for udev to work? I did try once to turn off hotplug but udev wouldn't load alsa drivers...
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.