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.
I was reading over the changelong for Current, and I'm a little confused by PV's comment for the latest udev update.
Quote:
a/udev-062-i486-1.tgz: Upgraded to udev-062.
This seems to be broken with regard to ALSA devices... I'd suggest
anyone using a 2.6 kernel "chmod 644 /etc/rc.d/rc.udev" unless you want
to help locate and report bugs. It's also possible that this has
something to do with the ever-changing syntax used in the udev.rules
config file. If you find any problems that can be attributed to that,
fixes would be appreciated. For now, rc.udev will be off by default.
My questions:
(1) I do use ALSA, so should I avoid this update?
(2) If this update turns rc.udev off, won't I be throwing out the baby with the bathwater if I apply this update?
Originally posted by dhave I was reading over the changelong for Current, and I'm a little confused by PV's comment for the latest udev update.
My questions:
(1) I do use ALSA, so should I avoid this update?
(2) If this update turns rc.udev off, won't I be throwing out the baby with the bathwater if I apply this update?
Thanks for your help.
1) Its preferable to use ALSA instead of OSS. If you need OSS then use the OSS emulation found in ALSA.
2) I'm not sure of this new update, but for me, udev 054 works well. So i'm personally not going to upgrade udev.
And on a side note, good work on pkgtool.. It is a bit faster now.
Thanks for your reply, xushi. I think I'll hold off on the udev update, too. I was curious, though, what effect it would have on ALSA, which I am using instead of OSS. If I have time next week I'll try to do some testing and see if that turns up anything useful. I've had one or two glitches with udev updates in the past, so I'm a little wary.
Like you, I'm also glad PV returned Jim Hawkin's optimized pkgtool script to Current. By your comment, I was afraid you thought I was one of its authors. I was just doing some unsolicited public relations for it by promoting it on this forum. I had seen how much it speeds things up and, also, I've used it for six months without any problems at all. I think it was Stuart Winter or Jim himself who contacted Pat about adding it back to Current.
I then followed PV's suggestion to chmod 644 rc.udev but then the system wouldn't boot, ending with a message saying something like
Failed to open /dev/hda8 (which is my root partition)
fsck.reiserfs for /dev/hda8 exited with signal 6
I downgraded udev to 054 and all is well again.
Does anyone have clue why fsck didn't work anymore?
And why come out with a newer version of udev if it's already known not to function?
Originally posted by LJSBrokken And why come out with a newer version of udev if it's already known not to function?
Because the current tree is for testing, not production. If you want to run current you should expect something like this from time to time. If you have problems, you should try and figure them out, fix them if possible, and report back to PV and company your results. This is how "stuff" goes from current to stable release.
This is also why I run stable (10.1) at the moment. I'm not saying that current is "unstable", it's just "untested". Most people run current with little or no problems, but every once in a blue moon something like this happens.
I do find it odd that he would put this in current when it's broken. I've been trying to build newer versions of udev ever since 55 and they all break alsa... Current has always been 'stable' to my knowledge and this move confuses me, especially when he knows that it's broken.... Hmmm... Oh well... I just figured alsa is standard with pretty much everyone and that was the whole reason he was waiting to upgrade; until he could get this ironed out...
udev really needs to get a sense of order to it. Seems like it's in constant flux and nothing has really stabilized...
Originally posted by LJSBrokken
And why come out with a newer version of udev if it's already known not to function?
If you read Pat's log, you will know:
....... It's also possible that this has something to do with the ever-changing syntax used in the udev.rules config file. ...................
the syntax is not finalized.....
dare not to upgrade udev packages.
BTW, pkgtool is great now. noticeable performance up!
I keep forgetting that 2.4 is the kernel that comes with 10.1..... If we are running a 2.4 kernel then disabling udev really doesn't matter... Thats why he put a 'broken' udev into current. It's not really broken. Not until 2.6.xx makes it into current.
On a side note, I found a fix for udev and mailed it off to Pat. So... It could be fixed soon.
I've also upgraded udev to 062 and ALSA didn't find the soundcard. After downgrading to 054, it works again well. So if you have troubles with ALSA, downgrading is very problably solution.
2_jong357: thnx for finding patch and moving it to Patric
Well, I don't think you'll find it anytime soon in current. I always run 2.6.xx... As a result, I tend to forget that 10.1 comes with 2.4 as I caught myself doing from above... My work around will break hotplug with 2.4 kernels as Pat pointed out in his reply email.... Thats why you won't see a fix in current. Atleast not mine... So.... If you only run a 2.6.xx kernel, and are not worried about breaking hotplug with 2.4 all you need to do is call upon udevsend to handle hotplug events in the startup script. Put this line right above where udevstart is called.
Code:
echo /sbin/udevsend > /proc/sys/kernel/hotplug
It seems there will be a 10.2 "to put a finishing touch on the whole 2.4 kernel series".... Then 2.4.xx is getting kicked to the curb for 11.0... (I hope that wasn't a state secret or anything...)
Well, anyway.... The above addition to rc.udev works on a 2.6 kernel.... I'm running udev-063 right now with no changes to anything in his source directory except calling upon udevsend in rc.udev...
Originally posted by jong357 It seems there will be a 10.2 "to put a finishing touch on the whole 2.4 kernel series".... Then 2.4.xx is getting kicked to the curb for 11.0... (I hope that wasn't a state secret or anything...)
Well, anyway.... The above addition to rc.udev works on a 2.6 kernel.... I'm running udev-063 right now with no changes to anything in his source directory except calling upon udevsend in rc.udev...
While udevsend can be used as a handler for hotplug events, it will hopefully not become the default, even when Slackware switches to 2.6, because many people want to keep udev out of the loop. It is certainly more elegant to run udevsend when hotplug events take place. E.g. via the to-be depracated /etc/hotplug.d.
Thanks a lot for the workaround, jong357. I'll probably use it, as I run only 2.6.x kernels.
One question, though: what's the downside of just not updating udev, at least for now? Are there significant new features in the post-54 releases of udev that make updating worthwhile?
Originally posted by GlowGlow While udevsend can be used as a handler for hotplug events, it will hopefully not become the default, even when Slackware switches to 2.6, because many people want to keep udev out of the loop. It is certainly more elegant to run udevsend when hotplug events take place. E.g. via the to-be depracated /etc/hotplug.d.
Do you think that "wanting to keep udev out of the loop" is more of a resistance to change type thing, or is it due to some type of hardware problem? I'm really interested to know, because for me, personally, udev it a much better way of handling /dev population than the old way of just pretty much putting something in /dev for every device known to man. Not saying it didn't work, as it work well, but udev is more "elegant", as you put it, IMHO.
LinuxQuestions.org is looking for people interested in writing
Editorials, Articles, Reviews, and more. If you'd like to contribute
content, let us know.