LinuxQuestions.org

LinuxQuestions.org (/questions/)
-   Slackware (http://www.linuxquestions.org/questions/slackware-14/)
-   -   udev update question (from Current Changelog) (http://www.linuxquestions.org/questions/slackware-14/udev-update-question-from-current-changelog-343394/)

dhave 07-15-2005 05:41 AM

udev update question (from Current Changelog)
 
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?

Thanks for your help.

xushi 07-15-2005 06:02 AM

Re: udev update question (from Current Changelog)
 
Quote:

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.

dhave 07-15-2005 06:30 AM

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.

BroX 07-15-2005 07:23 AM

I upgraded udev, and indeed it broke alsa.

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?

Cheers, Leon.

xushi 07-15-2005 07:26 AM

hehe, sorry, i meant to say

And on a side note, good work has been done on pkgtool.. It is much faster now.
:D

MMYoung 07-15-2005 08:08 AM

Quote:

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.

Later,
MMYoung

BroX 07-15-2005 08:39 AM

Yeah makes sense ;)
I guess -current is always so 'stable' that it caught me by surprise this time.

jong357 07-16-2005 01:55 PM

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... :mad: 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...

kaon 07-16-2005 10:20 PM

Quote:

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!

jong357 07-17-2005 12:45 PM

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... :rolleyes: 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.

Roger Krowiak 07-17-2005 01:27 PM

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

jong357 07-17-2005 02:29 PM

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...

GlowGlow 07-17-2005 05:22 PM

Quote:

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.

dhave 07-17-2005 05:30 PM

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?

MMYoung 07-17-2005 05:34 PM

Quote:

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.

Just wondering,
MMYoung


All times are GMT -5. The time now is 02:45 PM.