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
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/
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 ]
echo "Creating svgalib device node..."
mkdir -p /dev/misc
mknod -m 660 /dev/misc/svga c 209 0
chown root:video /dev/misc/svga
(note, the echo and if are to check if someone's sneaked a sysfs patch in when I
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
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
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, 18.104.22.168-r1 have RC_DEVICE_TARBALL in /etc/conf.d/rc that will disable this.