Thanks to Derrick 'dman' Hudson, I'm now the proud admin of a udev-enabled machine. This has raised a few questions over the last few days which I have mostly fixed, with a couple of exceptions. For those things that I've already solved, I'll include both the question and the answer for the benefit of future archive searches. (The unanswered question, for those inclined to help, is at the bottom.) Q: What exactly IS udev? A: To put it quite simply, it's the successor to devfs. Gone are the days of a few hundred entries under /dev. With devfs, you only get what you currently have active. And it's all in userspace. Among the benefits, are static names for devices. So, for example, that external Zip drive will ALWAYS be /dev/sdb, regardless of when you plug it in or what else is there at the time. For a somewhat more technical look, take a look at: http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev_vs_devfs http://www.kernel.org/pub/linux/utils/kernel/hotplug/udev-FAQ http://packages.debian.org/unstable/admin/udev Q: Ok, that's great. So how do I use it? A: For starters, make sure you're running a 2.6 series kernel. If not, upgrade in whatever manner you see fit. (Use a Debian pre-compiled package, roll your own using make-kpkg, say incantations over a bucket of penguin eggs, whatever.) Once you're up and running, install udev. (apt-get install udev) You MAY be able to just start it up via /etc/init.d/udev start, but I had to do a reboot. YMMV. Note, if you've rolled your own kernel, make sure you've selected devpts support and UNIX98 PTY support. (CONFIG_UNIX98_PTYS=y and CONFIG_DEVPTS_FS=y, respectively.) This is necessary for such inconsequential things as having an xterm, being able to ssh into your machine, etc. You know, nothing too important or anything. :) Also, while you CAN certainly keep devfs support in (CONFIG_DEVFS_FS) I would suggest against it unless you KNOW you'll need it. Life is much simpler without it. Once the kernel is up and running, you'll need to add an entry to your fstab for the devpts if it's not already there. (For me, it wasn't.) This will be something along the lines of: devpts /dev/pts devpts defaults 0 0 With that done, mount /dev/pts, and you should be mostly up and running. If you're not using an NVIDIA video card (With the binary NVIDIA drivers) or ALSA for sound, you're all done! If, on the other hand, you're using either of those, keep reading. Q: My NVIDIA card has stopped working! A: This is due to the fact that udev dynamically generates /dev entries. Unfortunately, the nvidia module doesn't make its presence known, so udev can't make the proper entries for it. This can be solved in two ways: 1) Create a boot script, something like /etc/init.d/nvidia, that will automatically create those devices at boot. It could look something like this: --- begin bash script --- #! /bin/bash for i in `seq 0 7`; do mknod /dev/nvidia$i c 195 $i chown :video /dev/nvidia$i chmod 660 /dev/nvidia$i done mknod /dev/nvidiactl c 195 255 chown :video /dev/nvidiactl chmod 660 /dev/nvidia$i --- end bash script --- This will create 8 nvidia devices. The reason it creates 8 is because this is how many the NVIDIA installer creates for you normally. Nothing more. :) 2) Patch the NVIDIA drivers to have them notify the system once they're loaded. Note that this SHOULD work with the debian packages for the drivers, but I haven't tried it. I use the self-installing drivers directly from NVIDIA. Download the 5336 NVIDIA drivers from www.nvidia.com. Download the patch from: http://lkml.org/lkml/diff/2004/2/1/56/1 or from my local copy: http://www.the-love-shack.net/geek/NVIDIA-Linux-x86-1.0-5336-basic-sysfs-support.patch (Note that all following filenames are the ones I happened to have. Your filenames may be different.) Unpack the archive: sh NVIDIA-Linux-x86-1.0-5336-pkg1.run -x Copy the patch into the directory that was the drivers were extracted into. (Assuming the above command line, that would be NVIDIA-Linux-x86-1.0-5336-pkg1) Now patch the drivers: patch -p1 < NVIDIA-Linux-x86-1.0-5336-basic-sysfs-support.patch And now install the drivers by running the nvidia installer within that directory: ./nvidia-installer I'm not really sure if the final step is even necessary, but I did and it didn't break anything. (Whether or not it made anything work I don't know since I did it before patching the drivers.) Edit /etc/udev/udev.rules and add the following two lines to it: KERNEL="nvidia[0-9]*", NAME="%k" KERNEL="nvidiactl", NAME="%k" Finally, regardless of which of the two options you chose, load the module at boot rather than letting it be autoloaded by X. The easiest way is to add 'nvidia' to the bottom of /etc/modules. Now you're up and running. Q: Ok, everything else is working great, except that I keep losing my ALSA mixer settings now. (Partially unsolved) A: This appears to be because udev can't create all of the relevant ALSA entries fast enough. The alsa load script loads the modules and then restores the mixer settings immediately. Since udev takes a bit to get the proper entries made, there are no devices to restore those mixer settings to. So to fix this, we slow down the alsa mixer restore bit of the load script. Just add this line: sleep 10 To your /etc/init.d/alsa script. It goes at ABOUT line 106. Right before this line: if [ "$alsactl_store_on_shutdown" = "true" ]; then I've tried shorter delays than 10 seconds, but this is the only one that consistently works. Note that I'm relatively sure that there must be a better way to do this, I'm just really not sure what it is. You could pre-load the alsa modules like the nvidia module, but that's just a workaround. For an actual fix, it might actually be something within udev. I'm not really sure. So any ideas? -- Alex Malinovich Support Free Software, delete your Windows partition TODAY! Encrypted mail preferred. You can get my public key from any of the pgp.net keyservers. Key ID: A6D24837
Attachment:
signature.asc
Description: This is a digitally signed message part