problem actually described in the end of post, after the '***' I first mount /dev/hda1 on /, and /dev/hda2 on /mnt/opts then, /opt/doublehp is a symlink to /mnt/opts/doublehp now, you know that /opt/doublehp/* is not in the same partition and filesystem as / now, do the following: mkdir -p /opt/doublehp/updatefstab cd /opt/doublehp/updatefstab wget http://doublehp.free.fr/updatefstab/updatefstab.automount.sh wget http://doublehp.free.fr/updatefstab/updatefstab.rules chmod +x updatefstab.automount.sh cd /etc/udev ln -s ../../../opt/doublehp/updatefstab/updatefstab.automo scripts/updatefstab.automount.sh ln -s ../../../opt/doublehp/updatefstab/updatefstab.rules rules.d/60-updatefstab.rules (relative links to files in /opt) plug a device: scripts not run ( you can check that easily: no log file has been created in /tmp when you sort /tmp by dates). now, still in /etc/udev rm scripts/updatefstab.automount.sh /updatefstab/updatefstab.rules cp -a /opt/doublehp/updatefstab / ln -s /updatefstab/updatefstab.automo scripts/updatefstab.automount.sh ln -s /updatefstab/updatefstab.rules rules.d/60-updatefstab.rules replug USB device, it gets mounted. ************************** what I can conclude from that is that udev can follow symlinks, if they point to absolute locations on the same partition/file system, BUT NOT when they point to relative locations to different partition.
Try restarting udevd, I do not think that it can detect rule changes from symlinks, due to the way inotify is used (you do have inotifiy built into your kernel, right?) What kernel version are you using? To restart udevd, as root: killall udevd /sbin/udevd --daemon
I thought udev had been conceived as NEVER TO BE a daemon to restart :S Linux moon_gen 2.6.14-gentoo-Gentoo-moon_02 #4 PREEMPT Wed Dec 14 10:44:54 CET 2005 i686 Pentium III (Coppermine) GenuineIntel GNU/Linux killall udevd /sbin/udevd --daemon does solve for a time, until next reboot. The workaround would then be to add that pair of commands in /etc/conf.d/locat.start at the moment, and find a better suitable place later on ... seems like udev drops files that are not readable at boot time, likely because the target partition was not mounted yet ... maybe the best place to reload udev would be chronologically just after /etc/runlevels/default/netmount and /etc/runlevels/boot/localmount I mean really twice ... how do you think inotifiy would help ? since I dont know what it is, I dont think I put it. Since I dont know the option name in kspace, I let you grab my conf: http://doublehp.free.fr/moon_02
ok, the fix is simple, do not do this. Put the rules in the directory and don't use a separate partition, especially for one that is not mounted at init time.
I can not accept personally your closing reason: udev IS designed to be a 'not to be restarted' daemon, just like elektra/reg-base. /opt/doublehp *IS* mounted at boot time !!! and especially for large systems (like cybercaf), it may be really easier to put some rules on network volumes, thus link some parts of /etc/udev to some NFS server ... I have always known that local files do works fine, but were not really sure why sometimes symlink fails. But I decide to open a bug because I 'still' think udev need improovement. (leaving closed)
Try building your kernel with inotify support and see if this fixes the problem. inotify is what udev uses to detect if the files have changed, if they aren't present when udevd starts up, how do you expect them to be read?
Oh, and udevd can just be restarted to reread the config files, see the man page for how to do this.
