as of udev-013-r1 and kernel sources 2.6.1-mm3+ udev now creates all the /dev nodes needed and thus there is no need for devices.tar.bz2. /sbin/rc and /etc/conf.d/halt.sh can be edited to not use the tarball. May I suggest that these are edited so if the kernel sources are greater than mm3 (or love3) and udev-013 is installed then it doesnt use devices.tar.bz2 but udes udev directly Reproducible: Always Steps to Reproduce:
No. There are three reasons: 1) Some things are still not created (std*, fd, core) 2) How do you want to save custom links for devices of drivers not yet sysfs'ified ? 3) Until Greg's patches are in, and a few versions passed, it is not a safe choice, and I do not want to test for 10 (sure, now only two) kernel versions.
could you at least make it easier to use udev? for instance having a 'udev' kernel flag, then checking /proc/cmdline for 'udev' and if it is there then dont extract devices.tar.bz2 but use udev directly. This makes it very easy to revert back to devices.tar.bz2 if something goes wrong (just edit the kernel cmdline in the bootloader) and means you dont have to drag out a livecd if it breaks?
honestly i dont think editing the baselayout script yourself and commenting out the unpacking of the tarball is any harder than doing what you're asking most people wouldnt use requested functionality thus i dont think the 'gain' is worth it
As of 2.6.3-rc1, with azarah's nvidia sysfs patches and the latest udev, I get all this nice stuff created in udev without the tarball (note: I've removed some SYMLINKs from /etc/udev/udev.rules since I like breaking things) theferret root # ls /dev cdroms dsp full initctl kmsg mem null pts sequencer sound stdout urandom console fb gpmctl input log misc port random shm stderr tts vc discs fd ide kmem loop mixer ptmx rd snd stdin tty zero theferret root # ls /dev/input/ mice mouse0 theferret root # ls /dev/misc/ nvram psaux rtc I would suggest that the time for this is not so far away... the only issue to work out is saving custom nodes and permissions. Personally, I don't have a problem with this, since I have a script in /etc/conf.d/local.start I've been using to add nodes: if [ ! -c /dev/misc/svga ] then echo "Creating svgalib device node..." mkdir -p /dev/misc mknod -m 660 /dev/misc/svga c 209 0 chown root:video /dev/misc/svga fi (note, the echo and if are to check if someone's sneaked a sysfs patch in when I wasn't looking...) It would be good if there was a "nice" solution to this problem.
does the alsa stuff get created yet ? nvidia/alsa are my biggest beefs atm :)
alsa does (/dev/snd) as does the oss emulation (/dev/sound) and the latest version of nvidia-kernel has a udev patch, so /dev/nvidia* is created as well :)
i think i'm down to fb nodes and some apple keyboard nodes ... otherwise udev works just as well as devfs
The fb nodes will be taken care of automatically in the next kernel release.
Greg, still have the issue of how to save custom device nodes .... I still think the better option might be to add an option to /etc/conf.d/rc to disable tarball for those that do not want it.
That sounds like a good idea. Oops, the fb patch was taken out of the main kernel tree, sorry for the false alarm about that.
As we are on the topic 8) - have you guys thought about custom symlinks? How bad would it cause people to scream if we could add an option to check all non-sysfs related nodes, and save them in the .tdb, and recreate time? Might even be command line options/commands both - the saving of the extra nodes (with permissions - symlinks as welll?) and then creating them again. Sure, I know - add them to local initscript. I am just thinking more out of a automation point of view ...
People have suggested allowing users to create rules that add "custom" symlinks. I like the idea, but no one has redone the patch so that it will work with the recent udev tree. If that is added, the ability to "save" symlinks would no longer be needed, right?
Nope - custom nodes though? Permissions, etc? Was just thinking something generic ...
Yes, something "generic" will still need to be handled by a tarball somehow, nothing udev can do about it :)
*** Bug 42014 has been marked as a duplicate of this bug. ***
Ok, 1.8.6.13-r1 have RC_DEVICE_TARBALL in /etc/conf.d/rc that will disable this.
