Recently I imaged my slack install to a new machine.

I had udev rules set up to mount an external DVD and some other devices. These udev rules for were working prior to the new computer.

I'd put these rules in a new file, so as not to disturb the default setup. For reasons of priority, I'd set the filename to start with two zeros. This (in theory) forced my file to be evaluated before any of the other rules.

One specific example from that rules file, for the external DVD drive:

The values for model and symlink were obtained from the actual drive and were verified by the fact that the above rule used to work.

In experimenting using trial and error to get it to work on the new computer, the rule has been changed to:
The above line is silly because it fails to account for devices moving around (ie, it won't always be sr1). it's not a good permanent rule. However, in my testing session I'd already verified that the drive was on sr1. This silly rule should see that drive no matter what! I rebooted and yet still the
/dev/dvdburner" symlink was not created.

Is udev not running? No, that can't be it ... the machine would not be able to boot without udev.

Again:

• udev rules worked on computer 1
• linux was imaged to computer 2
• udev rules fail on computer 2

So ... what is wrong?

Are the other comparisons failing? Too many spaces? Not enough spaces?
Use udevinfo to check the attributes of the devices and check against your rules:

udevinfo -a -p /sys/block/hdb

(or whatever device entry matches your devices)

That's the thought process I went though back when I first made and debugged those rules some years ago.

Let me phrase the question a different way.

At boot up time, a process is run. I don't know what it is called, so we'll call it the "udev startup and look and and run the udev rules" program.

Maybe, due to some error in file permisions or some such during the imaging of the system to the new machine, the "udev startup and .." etc process is not being started at bootup. or it is being started but it terminates right away. So, we get new questions ...

• What is the name of the process that actually evaluates and acts on the udev rules files?
• What is a way to see if said process is running or not?

I had this same issue with my slack box.....the problem for me was while the machine was doing coldplugging udev would hang for what seemed like forever (bout 45 sec) failing to make symlinks and junk.....then it would proceed to boot as normal.... I found that my /etc/rc.d/rc.S script was misconfigured from the start.....the default script was starting udev while the filesystem was in read only mode which wouldnt allow udev to write the symlinks.....I just edited the script to start udev a few processes later (after filesystem goes rw) and it worked fine.
I was using vector version of slack so it may differ a bit for you.
hope this helps.

That would be 'udevd', which on Debian is typically invoked by rc.S/S??udev

Typically 'udevtrigger' will have to be run immediately after starting udev so that the built-in modules can 'play back' events and create the device entries for other programs to use; this is why udevd has such a high priority in the rc.S script list.

ps -e|grep udevd

Thanks for the info. I've used it to discover that my system does not have udevd running. Weird. I begin to suspect that the protection bits on some file somewhere that were changed during the imaging process and this is messing up udev. udevd itself (/sbin/udevd) seems to have correct permissions.

As a kludge, i decided to just forcibly start udevd (without any "is it already running?" checks) from rc.local. This worked in that I can do a "ps -e | grep udevd" and I can see that udevd is runnung. However, my udev rules are still being ignored. Serious wtf.