hotplug udev headaches [RESOLVED]

platojones · Last edited by platojones on Sun Nov 07, 2004 5:29 pm; edited 1 time in total

After spending the better part of a day on this, I've finally realized that using hotplug-base for udev management is BAD! It simply doesn't work with my setup. I just switched to a pure udev system, from devfs, and have been seeing udev inconsistently creating device nodes. After bootup, if I ran udevstart, the desired devices would appear, and everything would work fine...until the next reboot. I could see that udev was starting, but started to become suspicious about that "Using /sbin/hotplug for udev management..." message I was seeing when udev started up. After digging around, I discovered that the rc script was making the determination to use hotplug as the udev mgt agent, and that there was appearently another alternative. If it sees the /sbin/hotplug script as executable in /sbin, it uses hotplug. It could use udev as the management agent with a minor change to the script. I did a simple quick mod to the rc script, and bingo, I am using udev for udev management. Of course, udev has been working perfect since I made that change.

I've been running on the gentoo-dev-sources-2.6.9-rc1 kernel and I'm running udev-030, with hotplug-base-20040401. Of course I tried the ~x86 versions of those ebuilds and the results were the same. Looking in bugs database, I noticed a few, mostly unresolved issues with hotplug-base/udev. I don't know if others are having this issue, but if you are, it might be worth a try to unmerge hotplug-base completely (if you don't need hotplugging) or try that simple mod to the rc script. I'm torn about submitting a bug about this, since one is sitting out there right now as resolved, only I think it isn't, and nobody has re-opened it.

Anybody else seen this issue or know anything else about this. I'd prefer not to modify a key system script like rc, but I didn't have a choice. I needed hotplugging and udev.

[UPDATE] BTW, I don't think what is did is a the real solution to the problem, since /proc/sys/kernel/hotplug now has udev as the hotplug agent, instead of hotplug. But this does work for now. I think there is definitely something wroing with the current hotplug/udev interaction.

[RESOLVED] After fiddling around with UDEV/hotplug some more, I restored the original rc script and now everything mysteriously works. Don't ask me why, but it just does. Sorry about this thread, I was just mystified why alsa would load on one boot and not on another. The rc script change fixed it, but I was never comfortable about it, since I saw other people on the forums were not having the issue I was. Now that asla loads correctly, along with everything else on my pure UDEV system, it's not an issue anymore.

melteye · n00b Joined: 28 Feb 2004 Posts: 36

which rc did you edit?

platojones · Posted: Sat Nov 06, 2004 12:05 am Post subject:

Actually, it was the /sbin/rc script itself. That's where it does the udev/hotplug determination.

infirit · Posted: Wed Nov 17, 2004 6:49 pm Post subject:

I'll edit it also as hotplug is really not working as a UDEV manager. An example:

In permissions.d.

dsd · Posted: Wed Nov 17, 2004 8:11 pm Post subject:

another common cause of the issue described here is not having CONFIG_HOTPLUG enabled in the kernel. udev wont know about new devices unless the kernel talks to it.

edit: also as for the permissions problem, thats pam kicking in with its own rules (/etc/security/console.perms) when you login
_________________
http://dev.gentoo.org/~dsd

tuppe666 · Guru Joined: 02 Mar 2004 Posts: 423

My UDEV just got updated(by about a million revisions)
I had to change two things add coldpugging.
and add mprobe snd-intel8x0 to my modules file.

I do have a spanking new /media directory though

infirit · Posted: Sat Nov 20, 2004 1:58 pm Post subject:

dsd · Posted: Sat Nov 20, 2004 5:21 pm Post subject:

for those who dont use pam, or those who use pam but not pam's permission changing
_________________
http://dev.gentoo.org/~dsd

Loial · n00b Joined: 24 Mar 2003 Posts: 29

what should I do then if I have both udev permissions and pam permissions set to 0660 root.audio or root.video for /dev/snd/* and /dev/v4l/* respectively and still get these permisions?

/dev/snd:
total 0
drwxr-xr-x 2 root root 180 Dec 25 13:57 .
drwxrwxrwt 16 root root 3300 Dec 25 13:57 ..
crw-rw---- 1 root root 116, 0 Dec 25 13:57 controlC0
crw-rw---- 1 root root 116, 24 Dec 25 13:57 pcmC0D0c
crw-rw---- 1 root root 116, 16 Dec 25 13:57 pcmC0D0p
crw-rw---- 1 root root 116, 25 Dec 25 13:57 pcmC0D1c
crw-rw---- 1 root root 116, 17 Dec 25 13:57 pcmC0D1p
crw-rw---- 1 root root 116, 1 Dec 25 13:57 seq
crw-rw---- 1 root root 116, 33 Dec 25 13:57 timer

/dev/sound:
total 0
drwxr-xr-x 2 root root 160 Dec 25 13:57 .
drwxrwxrwt 16 root root 3300 Dec 25 13:57 ..
crw-rw---- 1 root root 14, 12 Dec 25 13:57 adsp
crw-rw---- 1 root root 14, 4 Dec 25 13:57 audio
crw-rw---- 1 root root 14, 3 Dec 25 13:57 dsp
crw-rw---- 1 root root 14, 0 Dec 25 13:57 mixer
crw-rw---- 1 root root 14, 1 Dec 25 13:57 sequencer
crw-rw---- 1 root root 14, 8 Dec 25 13:57 sequencer2

running udevstart then changes them to 0660 root.audio and root.video
Isn't that strange?
this is supposed to be a udev only machine, but maybe I have something configured wrong...

Thanks

aetius · Tux's lil' helper Joined: 09 Jul 2004 Posts: 118

See:

https://bugs.gentoo.org/show_bug.cgi?id=72119

and

https://bugs.gentoo.org/show_bug.cgi?id=31877

That might help.