the creation of things like zero causes many recursive operations (like grep) to take off and never come back side node, src_install() in the udev ebuilds lack any sort of error checking
I don't understand, what is going on here that would put stuff in /lib? What version of udev? What kernel version? And, any pointers as to what you feel I should be doing in scr_install()?
read the ebuild # Create some nodes that we know we need. # set the time/date so we can see in /dev which ones we copied over # in the udev-start.sh script mkdir ${D}/lib/udev/devices mknod ${D}/lib/udev/devices/null c 1 3 chmod 666 ${D}/lib/udev/devices/null touch -t 200010220101 ${D}/lib/udev/devices/null ......
$ ls -la /lib/udev/devices/ crw------- 1 root tty 5, 1 2006-03-30 12:47 console crw-rw-rw- 1 root root 1, 3 2006-03-30 12:47 null crw-rw-rw- 1 root root 1, 5 2006-03-30 12:47 zero udev-087
Yes, it's required that we create those device nodes in /lib, as it is part of the way that udev starts up. We copy any device nodes in /lib/udev/devices to /dev to seed the tree with some initial nodes that we are required to have. It also allows users and packages to add device nodes there if they want them to be "persistant" accross reboots, and if some kernel drivers don't support udev support (like nvidia). This is the distro-agnosistic way of doing things, not a Gentoo specific thing. I thought you were referring to udev run-time behavior. So, am closing this, as it isn't a bug.
> This is the distro-agnosistic way of doing things, not a Gentoo specific > thing. considering Gentoo already provides a way to save/restore device nodes across reboot, i'd say /lib/udev/devices/ isnt needed by default on a Gentoo system > So, am closing this, as it isn't a bug. sure it is, device nodes dont belong in /lib
Yes, Gentoo provides a way to save _all_ device nodes if you so desire, but that is very different from what this feature does. For example, say a x driver wants to provide device nodes to the system, as it is not allowed to work directly with udev due to some licensing issues. The package for it can just drop the device nodes directly into /lib/udev/devices/ and they will be automatically created properly every time at boot. This will then work with people who do use the tarball to save all device nodes, and those who do not. It is a standardized cross-distro solution for the problem of initial device nodes needed by udev and other packages like the above mentioned example. And as such, we (Gentoo) will also be following this standard. And what's the big problem of device nodes in other portions of the file tree? They don't cause a security problem, and are harmless. If you are having problems with grep, use the proper command line argument to have it skip device nodes ("-D skip"). So, am closing this bug, as it's not a problem. If you think the ebuild should handle error conditions a bit better, please post a patch for that issue, as a separate bug.
(In reply to comment #4) > It also allows users and packages to add device nodes there if they want them > to be "persistant" accross reboots, and if some kernel drivers don't support > udev > support (like nvidia). At least nvidia video drivers do have support for udev, I don't know about the other ones, though. And I think it is unfortunate that you don't even see this whole mess of device nodes in /lib as a problem, but it looks like you won't change your mind anytime soon, so I'll leave it at that.
No, nvidia can not support udev, due to licensing issues (it might have for very old kernels, but not today.) And if you disagree with this design decision, please talk to the upstream maintainers about it on the linux-hotplug-devel mailing list.
> (In reply to comment #8) > No, nvidia can not support udev, due to licensing issues (it might have for > very old kernels, but not today.) I'm sorry, you are right, I did not read correctly. > And if you disagree with this design decision, please talk to the upstream > maintainers about it on the linux-hotplug-devel mailing list. To me it looks obvious that what this bug is about is not a good idea, and I probably will not convince any of the maintainers otherwise. And now I will really leave this alone. I am not particularly fond of this hotplug stuff in its current incarnation anyway, I guess it shows sometimes. :-)
Greg, there's still an issue with this on nodev-mounted /var (mentioned in Bug 128799). mknod won't work sandboxed in ${D}, like in src_install() currently - needs to be done in an unsandboxed phase on live filesystem, otherwise it breaks.
Jakub, the odds of a "nodev" mounted /var is very unlikely. But even if it does happen, simply remounting it for merging udev is acceptable, right? If not, can you provide a patch to the ebuild showing how you would propose we create this on the fly? If you do so, please create a new bug for this and attach it there.
(In reply to comment #11) > If not, can you provide a patch to the ebuild showing how you would propose > we create this on the fly? If you do so, please create a new bug for this > and attach it there. Attached to Bug 128693, solving the issue there as well. Thanks.
> And if you disagree with this design decision, please talk to the upstream > maintainers about it on the linux-hotplug-devel mailing list. this isnt an upstream issue the udev ebuild shouldnt be creating the device nodes
Ok, then how do you suggest we seed the /lib/udev/devices/ directory with the initial device nodes that we need? And then later, how will other ebuilds drop device nodes in there?
> Ok, then how do you suggest we seed the /lib/udev/devices/ directory > with the initial device nodes that we need? why are they needed ? udev startup has no problem creating them on my machines both `udevstart` generates null/zero/console as does the trigger_events() code in udev-start.sh: list="$list $(echo /sys/class/*/*/uevent)" /sys/class/mem/zero/uevent /sys/class/mem/null/uevent /sys/class/tty/console/uevent > And then later, how will other ebuilds drop device nodes in there? the only ebuilds that should create device nodes are ones that install kernel modules ... and kernel modules should be written so that they hook into /sys and udev creates the nodes for them
Due to licensing issues, not all kernel modules can use /sys (think non-gpl kernel modules.) So for those types of modules, we need to have a solution. Also, these nodes are required for booting on a box with a completly empty /dev tree. Odds are this is working for you as you have a populated /dev tree on your root filesystem. Mount it somewhere else and take a look. If you empty your /dev out, you will need these device nodes in order to be able to see anything at boot time.
> Also, these nodes are required for booting on a box with a completly empty > /dev tree. Odds are this is working for you as you have a populated /dev tree > on your root filesystem. Mount it somewhere else and take a look. i'm fully aware of the empty /dev situation ... i wrote the code in baselayout that allows Gentoo to boot with an empty /dev but really, what does that have to do with anything ? when udev is run, / is readonly, so it's impossible for udev to copy the device nodes from /lib/udev/devices/ to the /dev that lives on / again, not that the readonly / matters, as before udev is run, /dev is mounted on ramfs/tmpfs/whatever so it's going to be empty for everyone. and when udev is started, it properly creates the device nodes null/zero/console. so having the code automatically copy /lib/udev/devices/ only succeeds in overwriting nodes that already exist i thought you said this /lib/udev/devices/ thing was from upstream ? it's our Gentoo udev-start.sh file that's using it, not udev itself
as noted, the three device nodes udev itself creates arent actually needed
so what's the deal ? can we punt these things now ?
No, I'll do it, there need to be some work done on this package, due to the last mess that happened...
*** Bug 137135 has been marked as a duplicate of this bug. ***
Fixed in udev-104-r3. The devices are no longer created from ebuild, but the dir is kept, as this positions seems pretty wide-spread to store custom device-nodes there.
