With devfs, one can build CDROM support as a module, and CDROM support is then loaded into the kernel when one tries to use the CDROM. With udev, that is no longer possible, as the cdrom device will belong to the group "disk" instead of the group "cdrom" until the module is loaded, and since the user cannot access the device, the module is not loaded. I assume this could happen with other hardware too, and that it will be a good idea to include a short section on this in the "Known Issues" section. Reproducible: Always Steps to Reproduce: 1. 2. 3.
this isnt just cdrom, this is any module that the user relied on devfs to autoload for them so if a warning is to be added, it should mention that udev does not have the module autoloading feature that devfs has as for the permissions issue, that's probably because you are using RC_DEVICE_TARBALL and the permissions in that are not synced against the current /dev ... that isnt something that should really be documented since it can be a wide variety of differences and we're deprecating the use of it anyways
The permission problem has been fixed, please upgrade to the latest version of udev. As for the autoloading, that's well known...
(In reply to comment #2) > The permission problem has been fixed, please upgrade to the latest version > of udev. Thanks! > As for the autoloading, that's well known... It may be well known, but not by new users. I still think it should be mentioned in udev-guide, so new users (including those using the latest stable udev without the fix) have a better chance of figuring out what is wrong. /Jakob
