rc.M reports failed devices are not directories: uevent: Not a directory

mokele · 11-02-2006, 08:36 PM

When booting about 20 lines like this one:
/etc/rc.d/rc.M line 93: /dev/.udev/failed/devices@platform@vga16fb.0/uevent: Not a directory
appeared

I found something similar in linuxpackages.net

This happened after upgrading udev. I commented these
lines in rc.M:

Code:

if cat /proc/mounts | grep -wq sysfs ; then
  if ! grep -wq nohotplug /proc/cmdline ; then
    if [ -x /etc/rc.d/rc.udev ]; then
      if [ -d /dev/.udev/failed ]; then
       for i in /dev/.udev/failed/*; do
         echo "add" > "${i}/uevent"  
       done
      fi
    elif [ -x /etc/rc.d/rc.hotplug ]; then
      . /etc/rc.d/rc.hotplug start
    fi
  fi
elif [ -x /etc/rc.d/rc.hotplug -a -w /proc/sys/kernel/hotplug ]; then  
  if ! grep -wq nohotplug /proc/cmdline ; then
    . /etc/rc.d/rc.hotplug start
  fi
fi

..and everything worked fine, I could even mount
my sdX's with no problem, but I don't like that
solution. That snippet look pretty important to
just comment it.

Is there any other solution?

-W

milestoneiii · 11-04-2006, 09:08 AM

I've had the same problem. I previously used Gentoo, and when a Windows scandisk somehow corrupted my linux partition, I decided not to go through all the compile times, and went with Slack 11. The fresh install worked nicely, but I want an SMP kernel, so I used the same config file from gentoo. Everything went great, except the error in rc.M line 93. I just commented that whole line out though. As for the real fix, I don't know. Just thought I'd let you know you're not alone, and so far, commenting it out doesn't affect anything for me

mokele · 11-04-2006, 03:17 PM

Quote:

Originally Posted by milestoneiii

Just thought I'd let you know you're not alone, and so far, commenting it out doesn't affect anything for me

Thanks.

I really thaught I was alone on this one. After 2 or 3
views of my posts I usually get answers, and after 45
views in this one I really thaugt I was alone.

But you know, further reading and searching has pay good
results so far. I'm not sure if the solution I figured
is the best. So I'm going to post what I did (and worked)
and if any script porgrammer is arround you can tell me
if this is my best choice,or something better could be
done.

I read the /usr/share/doc/udev-103/RELEASE-NOTES document
in the section: udev 099, as suggested here. And I wandered
if inserting the `udevtrigger' instruction somewhere should
work. So I commented and inserted this way in rc.M:

Code:

       for i in /dev/.udev/failed/*; do
         udevtrigger --retry-failed
         #echo "add" > "${i}/uevent"
       done

That worked fine, no more rc.M: Line 93 errors.

The only thing I have to figure out now is a SCSI error
thats coming out after LUNS scanning.

-W

milestoneiii · 11-05-2006, 07:58 PM

Thank you so much for the information. I'll give that a try as well!

mokele · 11-10-2006, 04:39 PM

update.

As I wrote at the end of post #3 I was having
a little problem with a SCSI error.

Error: SCSI subsystem not active.

This error was produced by the new /etc/rc.d/rc.scanluns
script. I opened /etc/rc.d/rc.scanluns on an editor and reading
the comments I remembered that I enabled the `scan all LUNs'
as built-in when I compiled my kernel to use my memory
card-reader since those media readers use the USB and
SCSI systems, so the rc.scanluns script is not needed as
I understood from the script comments.

To configure `scan all LUNs' In SCSI support when compiling
kernel from source enable this:

Code:

[*] SCSI device support
[*] SCSI disk support
[*] Probe all LUNs on each SCSI device

So the solution was to once more edit the /etc/rc.d/rc.M
script, and comment this:

Code:

# Look for additional USB/SCSI/IEEE1394/etc devices on multiple LUNs:
#if [ -x /etc/rc.d/rc.scanluns ]; then
#  . /etc/rc.d/rc.scanluns
#fi

Thanks to Pat V for the very well commented scritps

-W

GrapefruiTgirl · 02-20-2007, 03:36 PM

(deleted irrelevant content)