SEO

zoomzoom udev # uname -a
Linux zoomzoom 2.6.21-gentoo-r4 #12 SMP PREEMPT Sat Dec 15 11:14:08 EST 2007
i686 Pentium III (Coppermine) GenuineIntel GNU/Linux

zoomzoom udev # emerge -p udev

These are the packages that would be merged, in order:

Calculating dependencies... done!
[ebuild R ] sys-fs/udev-115-r1

zoomzoom udev # ls /etc/init.d
acpid dbus functions.sh local net.lo
pwcheck shutdown.sh
alsasound dcron gpm localmount netmount
reboot.sh slapd
atftp depscan.sh hald lvm nfs
reslisa slurpd
bootmisc device-mapper halt.sh mDNSResponderPosix nfsmount
rmnologin sshd
checkfs dhcpd hdparm mdadm nscd
rpc.idmapd sysklogd
checkroot dhcrelay hostname mdnsd ntp-client
rpc.statd udev-postmount
clock diald in.tftpd modules ntpd
rsyncd urandom
consolefont dmeventd ip6tables mysql numlock
runscript.sh xdm
consolekit dnsextd iptables mysqlmanager portmap
samba xinetd
crypto-loop esound keymaps net.eth0 proftpd
saslauthd
cupsd famd lisa net.eth1 pure-ftpd
serial

Somewhere in the upgrade process this systems udev never enabled properly.
On device insert I get no event ie dmesg shows nothing happening.

Ideas what I bolloxed?

/etc/udev/rules.d (appears normal)

Thanks.
-Walt

The sentient life form Walt Shekrota posted the following:

> zoomzoom udev # uname -a
> Linux zoomzoom 2.6.21-gentoo-r4 #12 SMP PREEMPT Sat Dec 15 11:14:08 EST
> 2007 i686 Pentium III (Coppermine) GenuineIntel GNU/Linux
>
> zoomzoom udev # emerge -p udev

The -p stands for --pretend, which makes emerge do nothing but show what it
would do.

You have also executed it without the -p option?

De Vliegende Hollander wrote:

> The sentient life form Walt Shekrota posted the following:
>
>> zoomzoom udev # uname -a
>> Linux zoomzoom 2.6.21-gentoo-r4 #12 SMP PREEMPT Sat Dec 15 11:14:08 EST
>> 2007 i686 Pentium III (Coppermine) GenuineIntel GNU/Linux
>>
>> zoomzoom udev # emerge -p udev
>
> The -p stands for --pretend, which makes emerge do nothing but show what
> it would do.
>
> You have also executed it without the -p option?

I did those to show the system environment you can see there is udev 115 and
this is long past devfsd. I'm looking for someone that has a suspicion what
I missed in the last years upgrades that would break udevs operation. There
appears to be no recognition of usb devices plugged in. I may have left an
option off a kernel build.

-Walt

Walt Shekrota wrote:

> zoomzoom udev # uname -a
> Linux zoomzoom 2.6.21-gentoo-r4 #12 SMP PREEMPT Sat Dec 15 11:14:08 EST
> 2007 i686 Pentium III (Coppermine) GenuineIntel GNU/Linux
>
> zoomzoom udev # emerge -p udev
>
> These are the packages that would be merged, in order:
>
> Calculating dependencies... done!
> [ebuild R ] sys-fs/udev-115-r1
>
> zoomzoom udev # ls /etc/init.d
> acpid dbus functions.sh local net.lo
> pwcheck shutdown.sh
> alsasound dcron gpm localmount netmount
> reboot.sh slapd
> atftp depscan.sh hald lvm nfs
> reslisa slurpd
> bootmisc device-mapper halt.sh mDNSResponderPosix nfsmount
> rmnologin sshd
> checkfs dhcpd hdparm mdadm nscd
> rpc.idmapd sysklogd
> checkroot dhcrelay hostname mdnsd ntp-client
> rpc.statd udev-postmount
> clock diald in.tftpd modules ntpd
> rsyncd urandom
> consolefont dmeventd ip6tables mysql numlock
> runscript.sh xdm
> consolekit dnsextd iptables mysqlmanager portmap
> samba xinetd
> crypto-loop esound keymaps net.eth0 proftpd
> saslauthd
> cupsd famd lisa net.eth1 pure-ftpd
> serial
>
> Somewhere in the upgrade process this systems udev never enabled properly.
> On device insert I get no event ie dmesg shows nothing happening.
>
> Ideas what I bolloxed?
>


What does "ls /dev/.udev" show?

Is udev listed in /proc/mounts?

During bootup does udev start?

How about in /etc/conf.d/rc, does RC_DEVICES=udev?

In /etc/udev/udev.conf... change udev_log=err to udev_log=deubg then
reboot... What does /var/log/messages say??


Its a start... let us know...


--

Jerry McBride (jmcbride@mail-on.us)

Walt Shekrota <walterp@penguinacity.org> wrote:
>
> Somewhere in the upgrade process this systems udev never enabled
> properly. On device insert I get no event ie dmesg shows nothing
> happening.
>
> Ideas what I bolloxed?
>
> /etc/udev/rules.d (appears normal)

1: Check /etc/conf.d/rc
In particular, check the RC_HOTPLUG, RC_COLDPLUG and RC_PLUG_SERVICES
assignments. Normally you'd have yes, no and "" for values, but if you
really need coldplugging, you might want to set it to yes.

2: Run "rc-update -v show", and verify that the required services are
actually set to start (that they're present in /etc/init.d isn't enough).
If a service you need (like e.g. device-mapper or udev-postmount) isn't
enabled for your runlevel (likely "default"), add it with "rc-update add
[SERVICE] default".

3: If you have entries for udev, proc, sys, dev or /dev/pts in /etc/fstab,
remove them. The system now creates these mounts itself. (Or,
alternatively, leave them in and set RC_USE_FSTAB="y" in /etc/conf.d/rc, but
then you're on your own to get them exactly right.)

If none of the above helps, take a look at the scripts in /lib/udev. They
may be quite valuable in finding out what's wrong, especially if you put
"set -x" as the first command in the scripts to have the shell echo out
whatever it does.

Regards,
--
*Art

Arthur Hagen wrote:

> dmsetup -l

hmmm
dmsetup -l
dmsetup: invalid option -- l
Couldn't process command line.

Is this for lvm? Has does that work with udev?
What is it you were shooting for with the 'l' option?

Thanks an aweful lot Arther.
I appreciate it.
-Walt

Walt Shekrota <walterp@penguinacity.org> wrote:
> Arthur Hagen wrote:
>
>> dmsetup -l
>
> hmmm
> dmsetup -l
> dmsetup: invalid option -- l
> Couldn't process command line.

Oops, my bad, going from memory. It's actually "dmsetup ls", which should
list all your dm devices, and give you an error if it can't communicate with
the kernel device mapper.

Regards,
--
*Art

Arthur Hagen wrote:

> Oops, my bad, going from memory. *It's actually "dmsetup ls", which should
> list all your dm devices, and give you an error if it can't communicate
> with the kernel device mapper.
>
> Regards,


No devices found.

You know I wonder if when I built a new kernel I didn't build in the device
mapper support correctly and it had been the other way.

But you said the baselayout is 1 not 2 now and the experimental enablement
doesn't sound like something I would do. Does it select the baselayout
based on whether udev is in the kernel maybe?

udevd started with trace instead of daemon provides no output when events
should be sensed. I assume it isn't wrong but whatever passes this info on.
There is also a udevmonitor which basically says the same thing, nothing
while on another system provides a full verbosity of events.
So a guess might be there is another setting in the kernel compile that I
totally missed. While the tail end of help on CONFIG_BLK_DEV_DM: does not
seem to indicate a missing option sometimes they are incomplete.

On this system I have raid but not raid on lvm, would that have become a
problem? There really is no lvm in usage right now so the 'dmsetup ls'
is not suprising to be empty unless it is also supposed to list udev stuff.

Thanks.
-Walt

Walt Shekrota <walterp@penguinacity.org> wrote:
> Arthur Hagen wrote:
>
>> Oops, my bad, going from memory. It's actually "dmsetup ls", which
>> should list all your dm devices, and give you an error if it can't
>> communicate with the kernel device mapper.
>
> No devices found.

That's good. It means it's working. If it wasn't, you'd get something like
(from a system where it's been removed the kernel):

# dmsetup ls
/proc/misc: No entry for device-mapper found
Is device-mapper driver missing from kernel?
Failure to communicate with kernel device-mapper driver.
Command failed

In other words, what I think you should do is simply remove device-mapper
from the init (with "rc-update del device-mapper"), since it only serves a
purpose for services needing the daemon, and not those that use the kernel
directly.

> But you said the baselayout is 1 not 2 now and the experimental
> enablement doesn't sound like something I would do. Does it select
> the baselayout based on whether udev is in the kernel maybe?

No, baselayout-2 appears to be marked as experimental for all arches.
# grep KEYWORDS /usr/portage/sys-apps/baselayout/baselayout-2*.ebuild
KEYWORDS="~alpha ~amd64 ~arm ~hppa ~ia64 ~m68k ~ppc ~ppc64 ~s390 ~sh ~sparc
~sparc-fbsd ~x86 ~x86-fbsd"

The only advantage I can think of to run the daemon is if you have non-root
processes that need to map devices -- they wouldn't be able to talk directly
to the kernel.

> On this system I have raid but not raid on lvm, would that have
> become a problem? There really is no lvm in usage right now so the
> 'dmsetup ls'
> is not suprising to be empty unless it is also supposed to list udev
> stuff.

No, just dm devices. AFAICT, udev uses dm, but not the other way around.
Of course, you might have a different problem with udev -- there were some
major changes a couple of months ago, which required user intervention.
See http://www.gentoo.org/doc/en/udev-guide.xml for more information and
troubleshooting of udev.

Regards,
--
*Art

Arthur Hagen wrote:

> In other words, what I think you should do is simply remove device-mapper
> from the init (with "rc-update del device-mapper"), since it only serves a
> purpose for services needing the daemon, and not those that use the kernel
> directly.


Its not set..
from all signs udev appears running just not processing events!
I occasionally see things just not events.

The commands appear to work like udevcontrol, udevstart etc.
Perhaps my rules files got messed up somehow.
This all happened sometime in the last year I can't say when. Occasionally I
plug a usb memory so I know it was working.

I do weekly emerges in an automated fashion which has kept these two systems
up to date. The other one still processes udev events properly. I have
rules to do backups and special tasks on that system.

I'll have to dig deeper to why events happen.

-Walt