I have baselayout 1.8.10 and udev 024-r1, kernel 2.6.5 I am using a pure udev-system, RC_DEVICE_TARBALL="no" in /etc/conf.d/rc When modules listed in /etc/modules.autoload.d/kernel-2.6 are loaded the respective nodes in /dev won't appear. For example i have "sr_mod" in /etc/modules.autoload.d/kernel-2.6, and it gets loaded, but /dev/sr0 is missing. Doing "rmmod sr_mod; modprobe sr_mod" will make /dev/sr0 appear. Reproducible: Always Steps to Reproduce: 1. RC_DEVICE_TARBALL="no" in /etc/conf.d/rc 2. Put a module into /etc/modules.autoload.d/kernel-2.6, which should make udev create a /dev node. 3. Reboot Actual Results: The respective /dev node is not created Expected Results: The respective /dev node should be created
I have found a solution to the problem, but i don't know if it's the best way to solve it: Adding this to the end of the start() function of /etc/init.d/modules: if [ -e "/dev/.udev" ] then udevstart fi This will create /dev-nodes for every device found in /sys, if it's run on an udev system
This problem does not occur if I don't use udevsend/udevd. This can be done by changing the symlink /etc/hotplug.d/default/udev.hotplug from ../../../sbin/udevsend to ../../../sbin/udev (as it was before udev-018-r1). Then, the udevstart fix isn't needed.
Created attachment 29335 [details, diff] The udevstart-fix
Created attachment 29336 [details, diff] The fix for not using udevsend/udevd The "udevstart-fix" and this one make obsolete each other.
I guess this is the same problem that affects a lot of users that load the nvidia module in modules.autoload and that have to manually create the device nodes for nvidia during boot (for instance with udevstart in /etc/conf.d/local.start) I tried to investigate and I found that there is some bad interaction of the /sbin/rc script with the udevd deamon: At boot, /sbin/rc mounts /proc and /sys, populates /dev running a lot of times /sbin/udev, and then runs /sbin/udevd in the background (line 245). After a few seconds, it's time to load the modules in /etc/modules.autoload.d/kernel-2.6, so for instance "modprobe nvidia" is run, which fires a hotplug event and so there's a call to /sbin/udevsend. udevsend contacts the running udevd, delivers the message and exits. udevd now has to call udev to create the device nodes, but first it waits a bit to make sure there are no other messages arriving with an earlier timestamp. So after a couple of seconds the devices are not created yet, and something occurs that wipes out of the system all the user processes (at least those called by /sbin/rc). I can't say very well what happens (maybe it's related to the runlevel switch?), but you will see that at the end of the boot, there's no process udevd running. So, in my opinion, /sbin/rc should not start directly udevd. In fact /sbin/rc could even avoid to start udevd _at all_: if udevsend is called and there's no udevd running, udevsend will take care of starting it. In fact, I commented out the line in /sbin/rc that starts udevd, now the device nodes get created and at the end of the boot I have udevd running on my system (called by udevsend).
I did the same thing, that is commented out the part that starts udevd in /sbin/rc. I also noticed, like you did, that after boot udevd isn't running (ironically, it _was_ running when I booted in devfs mode instead). So everything seems to work just by doing that? I still have udev.hotplug pointing directly to udev instead of udevd, at the moment.
The definitive test for the gentoo init system is on a udev-only machine with udev.hotplug pointing to /sbin/udevsend. In fact calling directly /sbin/udev avoids all these troubles, as gentoo@gogi.tv pointed out.
Yes.. I am running pure-udev and using udev directly. I was wondering if just not starting udevd in /sbin/rc would fix it.
Created attachment 29463 [details, diff] Patch for /sbin/rc, makes rc not start udevd directly Okay, here is a patch for /sbin/rc, what #5 and #6 mentioned. It works for me, too. This obsoletes the udevstart-fix which is bad anyway. But I still don't know why it works if udevd is not started separately.
This error doesn't only uccur when udev ist started from /sbin/rc, but also when you start it later. Example: <running system with a good udevd running> # rmmod tun -- /dev/tun goes away # killall udevd -- udevd is killed # udevd & -- udevd is started # modprobe tun -- nothing happens # rmmod tun -- nothing happens # modrobe tun -- /dev/tun is created only now (after loading the module twice) # rmmod tun -- /dev/tun is removed again # killall udevd -- udevd is killed BUT if you don't start udevd yourself from the shell, everything works as expected: # rmmod tun -- /dev/tun goes away # killall udevd -- udevd is killed # modprobe tun -- udevd is started and /dev/tun is created # rmmod tun -- /dev/tun goes away And please note: The udevd/udevsend manpage (it is ONE manpage) doesn't mention udevd in "SYNOPSIS", so maybe udevd SHOULD ACTUALLY NEVER be started directly, but only through udevsend. If that's true, the /sbin/rc patch is correct and the good one.
I use udev since 016 and all work fine, with 024-r1 i try to set the dev-tarball to "no" but my dev wasn't populate. If use old udev.rules all work well.
Created attachment 29494 [details, diff] Patch for /sbin/rc, makes rc not start udevd directly
GregKH, would you mind taking a look at this to determine the best course of action? If baselayout changes are needed, please let me know.
When removing the /sbin/rc section pertaining to startup of udevd *and* having the ide-cd driver included in the kernel (ie. not as a module), udev creates the /dev/hdc and /dev/cdroms/cdrom0 devices. However, whenever I've built the cdrom drivers as modules (and tried hdc=ide-scsi|ide-cd|cdrom), udev has failed to create the /dev/hdc and /dev/cdroms/cdrom0 devices. May be worthwhile to document this as a restriction for udev (that PCI block devices attached during boot cannot be modules, or the modules have to be included in /etc/modules.autoload.d/kernel-2.6) This me worry about what other devices may be "missed" as well...
(Thomas Sjolshagen) > [...] cannot be modules, or the modules have to be included in /etc/modules.autoload.d/kernel-2.6. Do you mean that, if you put the the modules into /etc/modules.autoload.d/kernel-2.6 the nodes are created, but if you do modprobe manually, they aren't?
No, I mean; if I (assuming the /sbin/rc change has been made) add the module to /etc/modules.autoload.d/kernel-2.6, the nodes are created. If I manually modprobe ide-cd, the nodes are created. If I do neither, the module isn't loaded (during the module dependency stuff), and thus the device nodes aren't created either (which, prior to disabling the tarball w/RC_DEVICE_TARBALL="no" in /etc/conf.d/rc , was not the case - as in, prior to disabling the tarball, w/o manually adding the ide-cd module or having it in kernel-2.6, the cdrom device was available and the module got loaded "on its own"). More clear? // Thomas
Not clear at all :) In short, if the module isn't loaded, the device nodes will not get created, it's as simple as that. So, if you need your cd module, put it in the autoload file, that's what I do. I've created a separate bug with a patch in it, 48629 that will fix the startup issues with udev for the other things reported in this long bug history. If that patch does not solve your issues, please create a new bug so we can try to figure this out.
