udev errors
 

Well, I normally fix my own problems, but I would appreciate any help on this one...

I am up to date with current, and have udev-097-i486-9 installed (yes, that is very recent, not even on all the mirrors yet) but had same problem with udev-097-i486-8.

I saw a couple of other posts which leads me to think I am not an isolated case.

At boot I get a very large number of messages, here is an example:

udevd-event[1647]: udev_node_symlink: symlink(rd/6, /dev/ram6) failed: File exists
(ok, I probably dont need ram6, but there are hundreds of these messages, that one was just near the end)

When I look in /dev, there are entries there which are old, they go back to 2003 etc, yet I read that /dev entries are now created dynamically on boot, so should I have a clean out? Could I delete all the old entries?

Also, the new udev is loading modules I dont really want, eg 2 different nic drivers. I used to be able to control this with hotplug's blacklist, but how does one do that with udev?

tobyl

I've encountered the same problem. I don't think clearing them out will fix it either. I jotted down some of the existing files and then used my slackware install cd to boot and mounted the drive so that I could delete several of the existing files under /dev that udev was complaining about. Rebooted and still got the same error messages.

Ya I even got a crash to run fsck when I updated.....
What I normally do is BEFORE I upgrade
Then install the new version and When I rebooted I wasn't greeted by a crash fof doom. This may not work for everyone but give a try.

Ok, I am starting to get the hang of this (I think)
This is worth a read:

http://vrfy.org/log/recent-state-of-udev.html

at the end is this, which got me saying "Ah, I see"

Files from udev, replacing the hotplug packages content

/etc/hotplug/*.agent -> no longer needed or moved to /lib/udev
/etc/hotplug/*.rc -> replaced by /sys/*/uevent trigger
/etc/hotplug/blacklist -> replaced by "blacklist" option in modprobe.conf
/etc/dev.d/* -> replaced by udev rule RUN key
/etc/hotplug.d/* -> replaced by udev rule RUN key
/sbin/hotplug -> replaced by udevd listening to netlink, only used in
initramfs, until the rootfs can be mounted, than it is disabled

/etc/udev/udev.conf -> main udev config file
/etc/udev/rules.d/* -> udev event matching rules
/lib/udev/devices/* -> static /dev content
/lib/udev/* -> helper programs called from udev rules

/dev/* -> replaced by dynamic udev and static content
in /lib/udev/devices/*

the last line is particularly enlightening.

I have now moved my modprobe.conf to /etc/modprobe.d/modprobe.conf
and I am experimenting with the new way of blacklisting
edit: not sure how yet, /etc/modprobe.d/blacklist perhaps

to be continued....

tobyl

Well I took a better look at rc.udev as well and then a look at my kernel and noticed that I didn't have tmpfs compiled in even though it seemed to appear in /proc/filesystems

So I recompiled adding tmpfs and now I'm just down to 3 udev error messages rather than a few dozen.

Sep 13 14:15:46 cartman udevd-event[1843]: udev_node_symlink: symlink(md/0, /dev/md0) failed: File exists
Sep 13 14:15:46 cartman udevd-event[1839]: udev_node_symlink: symlink(md/1, /dev/md1) failed: File exists
Sep 13 14:15:46 cartman udevd-event[1841]: udev_node_symlink: symlink(md/2, /dev/md2) failed: File exists

This system is using software raid so I'm not sure what's the issue now.

What prompted me to check tmpfs is when I did an

/etc/rc.d/rc.udev stop
/etc/rc.d/rc.udev start

I got this message

mount: wrong fs type, bad option, bad superblock on tmpfs,
missing codepage or other error
In some cases useful info is found in syslog - try
dmesg | tail or so

Starting udevd: /sbin/udevd --daemon

The message went away once I made sure tmpfs was added

located under File Systems -> Pseudo Filesystems and labeled as

"Virtual memory file system support (former shm fs)"

Hi neural,

Yes, I noticed from dmesg as it flashed by that I did not have tmpfs compiled in either, I will recompile tomorrow. I'm sure thats the main problem.
I guess your software raid is writing to /dev before udev


in /etc/udev/rules.d/udev.rules:

# md block devices
KERNEL=="md[0-9]*", NAME="md/%n", SYMLINK+="%k", GROUP="disk"

your new /dev might show slightly later modified times for md 3-9 when udev catches up?

tobyl

edit: recompiled with tmpfs as neural did, no errors now...

Update udev.rules to get rid of the symlink error
 

I found that if I update the md rule in udev.rules as follows,
that the error messages seem to go away (at least I can't see
them anymore as the boot quickly scrolls by):

Find the md[0-9] rule
Change it to md[0-15]

This is because there are now 0-15 md entries in /dev,
(I happen to be using 0-10) and this seemed to be
the problem.

Still getting errors, never mind
 

I'm still getting errors with symlinks, never mind my previous "solution." Hopefully someone will figure this one out, even though it's not really a problem.

could you post an example of the errors?
Are they of the type

...........failed: File exists ?

tobyl

Found this on Google, mid december 2006, was getting the same udev symlinks errors.

Compiled in tmpfs, and everything was back to normal.

On both of my slack 11 boxes I am got down to 1 error message and the only way to get rid of them was to compile inotify in the kernel.

Still got 1 though....

Chikne, if your last udev error has something to do with the floppy disk drive (/dev/fd0) I have a tempararly fix, it might not be the best solution to the problem but it works so far.

This fix takes the syslinks and kills them and forces one to use the raw device node, Kernel 2.6.x for some reason like auto load fd0 near the start of everything (even before the filesystem is actually mounted) so I just changed my udev script like so:

edit /etc/udev/rules.d/udev.rules

Replace:
#KERNEL=="fd[0-9]*", NAME="floppy/%n", SYMLINK+="%k", GROUP="floppy", PROGRAM="/lib/udev/floppy-extra-devs.sh %k %b %n"

With this:
KERNEL=="fd[0-9]*", NAME="floppy/%n", GROUP="floppy", PROGRAM="/lib/udev/floppy-extra-devs.sh %k %b %n"


All this does it tell udev not to make symlinks to devices that already exist with the same name as the floppy device node.

Thanks, all I did was to actually comment out the line and it fixed it. I don't use floppy anyway so....

Did you find that hack yourself?

Yea, I missed around with the Udev scripts, I have alot of hacks to the default install to make it what I want to do.

It's weird that the problem is there out of the box though isn't it? Not that it was doing any harm but you know what I mean ....

Well it's not really "out of the box" it didn't seem to me that Pat tested any 2.6 kernels that where included, he just said what the hell and included them for the sake of including them, there are also a number of other features that it seems he did not test, like if you have a Creative Live!Drive the permissions on the midi interface that allows the remote to work has the wrong permissions. There are several other things like this, but it's not a problem at all, well not for me anyways. I like a challenge every now and then.