Jerry McBride wrote:

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

zoomzoom grub # ls /dev/.udev
db failed names rules.d uevent_seqnum

>
> Is udev listed in /proc/mounts?
>
yes

> During bootup does udev start?
>
hmmm no evidence just the line where kernel parms are passed apparently back
a ways I coded udev in the grub line

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

No auto .... would be interesting to try this but I don't want to reboot at
the moment. It is possible that in all the upgrading process over the last
year or more some scripts got messed up.
It's been through a lot ... several compiler upgrades and all the hoops we
all jumped through Obviously I tripped somewhere.

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

yes I'll try this soon.
>
>
> Its a start... let us know...
>
>

Arthur Hagen wrote:

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

ahh this could be a bottleneck cold is set 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".

services not set to start
zoomzoom init.d # ./device-mapper status
* Caching service dependencies ...
[ ok ]
* status: stopped
zoomzoom init.d # ./device-mapper start
* The device-mapper init script is written for baselayout-2
* Please do not use it with baselayout-1
zoomzoom init.d # emerge -p baselayout

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

Calculating dependencies... done!
[ebuild R ] sys-apps/baselayout-1.12.10-r5

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

ok changing this although fstab does not have these.

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


So now what choice did I make that caused baselayout-1 to be used yet have a
script for baselayout-2?
Thanks.
-Walt

Walt Shekrota wrote:

> zoomzoom init.d # ./device-mapper start
> * The device-mapper init script is written for baselayout-2
> * Please do not use it with baselayout-1

Hi Arthur,

I'm thinking this is the beef of the issue?
Would re-emerging udev cause the proper script to be copied?

Thanks.
-Walt

Walt Shekrota <walterp@penguinacity.org> wrote:
> Walt Shekrota wrote:
>
>> zoomzoom init.d # ./device-mapper start
>> * The device-mapper init script is written for baselayout-2
>> * Please do not use it with baselayout-1
>
> Hi Arthur,
>
> I'm thinking this is the beef of the issue?
> Would re-emerging udev cause the proper script to be copied?

It is the proper script, however, you appear to have leftover files from an
older baselayout. In this case, it looks for /lib/librc.so, and if *found*,
it assumes you have the older baselayout.

To fix this:

emerge portage-utils
qfile -o /lib/librc.so

If it returns /lib/librc.so, this file is an orphan:
rm -f /lib/librc.so
else, it belongs to a package, which you can find with:
qfile /lib/librc.so # this time without the -o (for orphan)
If so, emerge -C (uninstall) this package, then:
emerge --update --deep system

After a reboot, your problem starting device-mapper *should* go away.

(You could also use "equery belongs /lib/librc.so" to find what package owns
it, but it's MUCH slower, and doesn't have an "-o" option.)

It's a good idea to from time to time run "qfile -o" on the most commonly
used directories, to find orphan files not owned by any package. Like this:

find /lib -type f | xargs qfile -o

Then check the resulting files. Repeat for other commonly used directories,
like /bin, /sbin, /usr/bin, /usr/sbin, /usr/lib and /etc/init.d. Beware
that some files listed are not really orphans, but created after
installation by a configuration tool or eselect. In particular, you want to
keep:
/lib/cpp
/lib/libgcc_s.so.1
/lib/modules/[kernel version]/*
/usr/bin/[anything to do with gcc/cpp/c++/g++/f77/g77/c89/c99]
/usr/lib/perl5/*.ph # Instead, run: perl-cleaner all
/usr/lib/python*/*.[pyc|pyh] # Instead, run: python-updater

After your system is up-to-date, it's also a good idea to run:
emerge --pretend --depclean
If you don't see a reason to keep the packages listed, re-run the command
without the "--pretend". Afterwards, run "revdep-rebuild" to be on the safe
side.

Do not, on the pain of tearing your hair out, run "emerge --prune". For the
last few months, it's been broken, and will remove slotted packages
(packages that co-exist in different versions) even when the slotted package
is registered in /var/lib/portage/world. Like removing gcc-3.4 because it's
older than gcc 4, even though it's needed, and recorded as gcc:3.4 in
/var/lib/portage/world.

Regards,
--
*Art

Arthur Hagen wrote:

> To fix this:
>
> emerge portage-utils
> qfile -o /lib/librc.so
>
> If it returns /lib/librc.so, this file is an orphan:
> rm -f /lib/librc.so
> else, it belongs to a package, which you can find with:
> qfile /lib/librc.so * *# this time without the -o (for orphan)
> If so, emerge -C (uninstall) this package, then:
> emerge --update --deep system
>
> After a reboot, your problem starting device-mapper should go away.

Arthur,

It was an orphan and I removed it.
The device-mapper start still gets that message

* The device-mapper init script is written for baselayout-2
* Please do not use it with baselayout-1

Do you think reboot would change that?
Thanks.
-Walt

This is fallout from just such hair pulling. I remember in the process up
upgrading so many things I had to do revdep rebuilds frequently.
It's amazing the system is fairly coherent with the exception of udev.

Walt Shekrota <walterp@penguinacity.org> wrote:
> Arthur Hagen wrote:
>
>> To fix this:
>>
>> emerge portage-utils
>> qfile -o /lib/librc.so
>>
>> If it returns /lib/librc.so, this file is an orphan:
>> rm -f /lib/librc.so
>> else, it belongs to a package, which you can find with:
>> qfile /lib/librc.so # this time without the -o (for orphan)
>> If so, emerge -C (uninstall) this package, then:
>> emerge --update --deep system
>>
>> After a reboot, your problem starting device-mapper should go away.
>
> Arthur,
>
> It was an orphan and I removed it.
> The device-mapper start still gets that message
>
> * The device-mapper init script is written for baselayout-2
> * Please do not use it with baselayout-1
>
> Do you think reboot would change that?

Actually, I believe the message is harmless, and that device-mapper
shouldn't start from init.d when using baselayout-1 (which is the current
one -- baselayout-2 is experiemental). Just turn it off (rc-update del
device-mapper), and add it to the kernel instead:

make menuconfig

Device Drivers --->
[*] Multiple devices driver support (RAID and LVM) --->
<M> Device mapper support (NEW)

make modules_install

Then add the following to /etc/modules.autoload.d/kernel-2.6:
dm-mod

THEN reboot and cross your fingers.

Of course, if you don't need lvm or dm support, like if you run RAID or
hot-swappable drives, you probably don't need it at all. USB devices (which
I believe was your original issue here) don't usually require dm support to
be recognized. I much prefer to use autofs for floppies, CDs and USB
drives.

Alternatively, you can go experimental and add "sys-apps/baselayout ~x86" to
/etc/portage/package.keywords. That will give you baselayout-2, which comes
with a new and working /lib/librc.so, but again, you're then on an
experimental build.

Regards,
--
*Art

Arthur Hagen wrote:

> Actually, I believe the message is harmless, and that device-mapper
> shouldn't start from init.d when using baselayout-1 (which is the current
> one -- baselayout-2 is experiemental). *Just turn it off (rc-update del
> device-mapper), and add it to the kernel instead:
>
> make menuconfig
>
> Device Drivers *--->
>
>[*] Multiple devices driver support (RAID and LVM) *--->
> <M> * Device mapper support (NEW)
>
> make modules_install
>
> Then add the following to /etc/modules.autoload.d/kernel-2.6:
> dm-mod
>
> THEN reboot and cross your fingers.
>
> Of course, if you don't need lvm or dm support, like if you run RAID or
> hot-swappable drives, you probably don't need it at all. *USB devices
> (which I believe was your original issue here) don't usually require dm
> support to be recognized. *I much prefer to use autofs for floppies, CDs
> and USB drives.


Hmmm ok well I think I am full circle back at the beginning.
I was not aware of this expermental path thus had not started device-mapper
in init.d.
So going back to my current kernel untouched.
it has dm_mod loaded as a module

? <M> Multipath I/O support
? ?
? ? <M> Faulty test module for MD
? ?
? ? <M> Device mapper support
? ?
? ?[*] Device mapper debugging support

so I think device mapper is enabled but whatever hot mechanism that enables
USB somehow got turned off. Do you know how to verify dev mapper working in
this kernel enablement?
I am using raid.
Thanks for all your thought and help.
-Walt

Walt Shekrota <walterp@penguinacity.org> wrote:
>
> so I think device mapper is enabled but whatever hot mechanism that
> enables USB somehow got turned off. Do you know how to verify dev
> mapper working in this kernel enablement?

"dmsetup -l" should work.

Regards,
--
*Art

Arthur Hagen wrote:

> 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

Yes I wish I could remember the circumstances.
I was suspicious of the 21 kernel I had so I advanced to 23 (with same build
choices). It did not cure the issue but in reboot I see an endless spin of
udev messages on shutdown and a rather lengthy but finite spin on startup.
(I suspect udev is just disabling or something)

I wanted to be sure my port(s) had not gone bad on the board so on repower I
see my usb hub cycle up but shortly after go off.

My disablement thoughts are based on the fact the system seems usable and
activity is under control. I'll have to go back through the daemon.log to
see if there are any breadcrumbs there sure are a lot of messages.
Thanks.
-Walt