udev -- 全资料
Computer Help for the New and Veteran User for Linux
UDEV Primer
Udev Primer for 2.6 kernel.Haven't updated this for awhile, until recently when a kind soul found an error in one of the rules, rules have changed since I wrote it. As of kernel-2.6.13 using devfs is no longer an option and I believe most people are using udev now instead of devfs. That being said, most of this document is probably not relevent anymore, but feel free to read it cause you might actually find something you can use. If I have a issue now, it is usually finding out what udev is calling my device when I plug it in. Udevmonitor command is helpful in finding that info, I make a little snippet on that in the Snippet of How to Write UDEV Rules section. Then later HAL and DBUS came along and made using Udev even easier. About the only thing I have to change anymore is permissions so the user can access device or find out what the device is being called. Otherwise I am leaving this up for legacy sake, you can see what we had to go thru when udev first came into use and you might actually find something helpful.
If you do find something relevent to today and needs clarified,... let me know so I can look into it. Otherwise my spare time is spent working on my Stock Portfolio App for Linux, playing HL2, fishing,...
If you already have UDEV installed and working you might want to read DSD's Guide on Writing UDev Rules. In the links at the bottom.
Little preliminary first. What is going on in the 2.6 kernel with Devfs? Straight from the horse mouth:
Note that devfs has been obsoleted by udev,http://www.kernel.org/pub/linux/utils/kernel/hotplug/
It has been stripped down to a bare minimum and is only provided for
legacy installations that use its naming scheme which is
unfortunately different from the names normal Linux installations
use.
RECENT CHANGES to Primer:
1) Fixed a rule for scanner that has changed since first wrote this and added another for same device.
2) Changed Intro above letting readers know most of the document is not relevent anymore.
3) Added a little about udevmonitor commmand and removed references to udevread.py (changes broke it and wasn't worth fixing).
INDEX Most recent x86 stable udev version 115-r1, x86_64 stable version 114, unstable 116-r1.
- What is UDEV?
- Steps to Setting Up UDEV.
a) Kernel configuration.
1) Kernel-2.6.13 and greater configuration.
2) Pre 2.6.13 Kernel configuration.
b) Emerge Udev.
c) Setup Hotplug.
d) Sys folder.
e) Fstab mounting.
f) Update baselayout.
g) Edit the scripts.
1) Newer Baselayout ( >=1.11.13-r1 ).
2) Baselayout ( >=1.8.6.13-r1 <=1.11.13-r1).
3) Old Baselayout ( <1.8.6.13-r1 )
h) Console & Null devices.
i) Nvidia drivers.
j) Bootloader.
k) Rebooting Results.
- Problem Devices.
- Snippet of How to Write UDEV Rules.
- Misc Devices: Palm Pilots, Flash Drive (Thumb, Pen,..)
- Links
What is UDEV?
In a nutshell UDEV is an replacement of DEVFS in user-space using sysfs and /sbin/hotplug. It will create and destroy /dev entries based on the current system configuration. It does this by watching the /sbin/hotplug events on the system, and readinginformation about these events from sysfs.
Udev works entirely in user-space, using /sbin/hotplug calls that the kernel makes whenever a device is added or removed from the kernel. All naming policy, and permission control is done in user-space.
Link to read for more information.
http://ftp.kernel.org/pub/linux/utils/kernel/hotplug/udev-FAQWell your first question is probably: How do I get started with udev?
It isn't that hard at all. Unless you have never compiled a kernel, which really isn't in the scope of this tutorial.
Steps to Setting Up UDEV.
- Newer Kernels (>= 2.6.13)
Like mentioned above you need to install and setup the 2.6 Kernel. This example is for a 2.6.14 kernel. For older kernels see below this in same section.
As of kernel-2.6.13 choosing devfs is no longer an option. If you want devfs as an option, see below and choose one less than 2.6.13 .
#
# General setup
#
CONFIG_HOTPLUG=y
#
# File systems
#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
CONFIG_SYSFS=y
CONFIG_TMPFS=y <--- Will look for this first if not avail. will use ramfs.
CONFIG_RAMFS=y Believe ramfs is enabled by default and is not
# option, tmpfs is called: Virtual memory file system support (former shm fs)
Older kernels (pre 2.6.13)
Like mentioned above you need to install and setup the 2.6 Kernel. Your best bet for kernels to use right now are: >mm-sources-2.6.1-mm3 (right now I am using: 2.6.4-gentoo-r1) or >gentoo-dev-sources-2.6.1 or >development-sources-2.6.2. Watch the Greater-Than sign and get a kernel newer than. Udev will work with some of the lesser kernels, but improvements have been made, so it will improve your success with a newer kernel. The important part of the configuration is shown below. Also note: You can still compile in DEVFS if you want and choose which to use at boot, so don't feel you cannot compile devfs in kernel to use udev. See the editing lilo or grub section for more details. If for some reason you do not see one of the kernel options you need below in your kernel, keep reading, some kernels are different.
Initrd Note: It would appear that if you want to use initrd , which I don't use, you do have to either use the tarball or Compile your kernel with Devfs support or you will get an error about 'devfs not mounting on /dev' . Doesn't mean you have to use it, just have it compiled in the kernel.
Genkernel Note: If you are using the genkernel, it looks like version 3.0.2f has been setup to work with Udev. Compile your genkernel with the --udev option. For example: genkernel --save-config --menuconfig --udev all
Also: when you write your Lilo or Grub bootloader you will need to use udev instead of gentoo=nodevfs , which is used with manually compiled kernels (pre 2.6.13). Otherwise despite your best effort it still won't use Udev. See the bootloader section if you need examples. Apart from the kernel and bootloader option, the rest of the primer should apply.
NOTE: DO NOT Enable Devfs to Automatically mount at Boot!! Haven't seen this before, but at least as of baselayout-1.8.6.13-r1 it will ignore your 'nomount' option in the bootloader. It will try to load devfs no matter what setting you have in the /etc/conf.d/rc file. Your system will not boot and will fail at 'checking root filesystem'. The filesystem isn't corrupt though. You will need to chroot from somewhere else and take OUT the option to Automatically mount Devfs at boot and recompile the kernel. You might even have to do it with 'make mrproper' before running 'make menuconfig'. Before running 'make mrproper' be sure to copy your .config somewhere safe or lose it. Note: You will not see the option for 'Automatically mount at boot' for devfs unless you have enabled devfs. Then it is still not enabled unless you enable it!
There are some options in the config that do not show up during menuconfig that will if you look at the .config itself. So if you want to check the file itself, this is what it should look like. Also in some kernels CONFIG_HOTPLUG might appear somewhere else, like in General Setup. You could grep what you are looking for in the .config file and then go back to menuconfig to set it. (hint)
mm-sources-2.6.3-rc1-mm1 example:
# Bus options (PCI, PCMCIA, EISA, MCA, ISA)
#
CONFIG_HOTPLUG=y
#
# File systems
#
# Pseudo filesystems
#
CONFIG_PROC_FS=y
CONFIG_PROC_KCORE=y
CONFIG_SYSFS=y
# CONFIG_DEVFS_FS is not set <--- Can say 'Y if want, will have to add gentoo=nodevfs to boot-loader to boot with udev.
CONFIG_DEVPTS_FS=y Do Not set Devfs to load Automatically at Boot!!!
# CONFIG_DEVPTS_FS_XATTR is not set Also: as of 2.6.4 kernel, DEVPTS_FS option is not avail. Enabled in kernel.
CONFIG_TMPFS=y
# CONFIG_HUGETLBFS is not set
# CONFIG_HUGETLB_PAGE is not set
CONFIG_RAMFS=yYou can still compile DEVFS (CONFIG_DEVFS_FS) in the kernel if you want, but see warning above. If you do, there are some boot options for lilo or grub that will mention later, where you can switch between the two. Remember though that devfs has been stripped down. Also make note that if you make changes in devfs and reboot the changes won't be saved for udev. The only way to save device state with udev is if using the /lib/udev-state/devices.tar.bz2 in the default Gentoo Udev install. If your running a pure udev system (ie. Not using devices.tar.bz2), then no changes will be saved, it is dynamic device creation. If you want to make changes to your devices in udev, you could try adding to the /etc/udev/rules.d/10-local.rules file. You will have to create that file, try not to edit the 50-udev.rules in there. That is the Default rules, add your own rules to the 10-local.rules you will/can create. You will not have to make your own rules to get started for most systems. If you need to though, create your own where mentioned.
- Next: emerge udev . Get at least version 024-r1, earlier versions still work, but you might run into more problems. So best to get the latest. Udev also depends on hotplug. So it will emerge them also if you don't have them.
- Add Hotplug to your boot run-level: rc-update add hotplug boot. Note: You might want to check that you don't have hotplug also set for default run-level. You can check with: rc-update -s or rc-update show . Which will display something like this (shortened):
bash-2.05b# rc-update -s
alsasound | boot
hdparm | default
hostname | boot
hotplug | boot
If you do then: rc-update del hotplug default to remove it and only Keep it in boot level.
- Looks like Gentoo is now creating the /sys folder in root for you to mount sysfs on. At least on new installs, might as well if changing to udev also. Best that you still check for the time being and if not being created in / , then create it manually. With: mkdir /sys
- Gentoo is now handling the mounting of devpts and sys now. So you don't have to add an either entry to /etc/fstab. The /sbin/rc script is handling it now. You can check with df -a. I haven't had any issues with them in fstab, but if you do, it is safe to remove those entries now. If you are having a problem with devpts or sys not mounting and not being able to open a console session, you should probably look for other issues causing this.
Note that devfs no longer manages /dev/pts! If you are using UNIX98
ptys, you will also need to enable (and mount) the /dev/pts
filesystem (CONFIG_DEVPTS_FS).
Now at this point you might think you actually have udev, sysfs and hotplug installed and ready to go. Sorry, but NO. Until sysfs is mounted, /dev mounted in tmpfs (or ramfs if you don't have tmpfs enabled in kernel) and hotplug started you aren't really doing anything. You will see changes in /sys if remove or add devices, but the system is not doing anything with this information.
- The next item you need is the new baselayout. It contains the necessary init scripts to start this up. You need to: emerge baselayout . The earliest workable version is baselayout-1.8.6.13, where you don't have to modify halt.sh and /sbin/rc. Since udev is still a work in progress get at least that version and newer if possible. Above version does have the necessary init scripts,... I would get the newest version though!
One file you might notice if you look, is in /lib/udev-state called devices.tar.bz2 . This is where the current state of /dev will be saved from tmpfs (or ramfs) when you shut down and where it will get it when you boot.
Saving the state of /dev kind of goes against the grain of what UDEV is all about doesn't it? Udev is suppose to be a dynamic filesystem that creates only the devices on your system and only when needed, for example: your scanner isn't plugged in, you don't need a device for it, so it is not created. You plug it in, then udev creates the device. If the state of /dev is saved, then it would be there next time, even if not plugged in. The reason for doing so was because at first only the basic devices needed were created by Udev. Devices like block (harddrives), tty,... UDEV has come a long way now and has most of the functionality you need now. So it is possible to run a Pure Udev system now. There are a few problems, but there are work-arounds for them.
Sometime in the future Gentoo will probably remove the devices.tar.bz2 file, when udev gets further along. It looks like udev is getting closer to making that happen.
Make sure you put the new config files in place that need updating by running etc-update. If you don't, then it won't save your current /dev folder in /lib/udev-state/devices/devices.tar.bz2 . Even if your not planning on using the default devices.tar.bz2 and want to run a pure udev system, it won't have the necessary scripts in place to use udev.
- Edit the scripts: If you are satisfied running the default Gentoo setup for now you can skip this section. Sooner or later you won't have to make this choice anyway. To run a pure udev system though edit the two scripts below. Note: You can switch back to using the tarball at anytime if find running pure udev does not work for you. Just change RC_DEVICE_TARBALL back to yes.
Note: If you are using >=baselayout-1.8.6.13-r1 you do not have to edit /etc/init.d/halt.sh or /sbin/rc. For old baselayout ( <1.8.6.13-r1 ) see next section.
Newer Baselayout ( >=1.11.13-r1 )
As of at least since newer baselayout-1.11.13-r1 you will only need to edit /etc/conf.d/rc still, but options changed slightly. Here are the relevant parts: (default setting)
# Use this variable to control the /dev management behavior.
# auto - let the scripts figure out what's best at boot
# devfs - use devfs (requires sys-fs/devfsd)
# udev - use udev (requires sys-fs/udev)
# static - let the user manage /dev
RC_DEVICES="auto" <--- auto works fine or change to udev,...
# UDEV OPTION:
# Set to "yes" if you want to save /dev to a tarball on shutdown
# and restore it on startup. This is useful if you have a lot of
# custom device nodes that udev does not handle/know about.
RC_DEVICE_TARBALL="yes" <--- changed to no on later baselayouts
New Baselayout ( >=1.8.6.13-r1 <1.11.13-r1)
As of new baselayout-1.8.6.13-r1 you will only need to edit /etc/conf.d/rc. Here are the relevant parts: (default setting)
# Set to "yes" if you want to save /dev to a tarball on shutdown
# and restore it on startup. This is useful if you have a lot of
# custom device nodes that udev do not handle/know about.
# (ONLY used by UDEV enabled systems!)
RC_DEVICE_TARBALL="yes"
# Set to "yes" if you want devfsd to start upon bootup. This is
# the default for Gentoo.
# Set to "no" only if you understand the full implications. A
# number of files may need to be altered (i.e. /etc/inittab,
# /etc/fstab, etc.).
# Also note that it does _NOT_ start for UDEV enabled systems,
# even if RC_DEVFSD_STARTUP="yes" ...
RC_DEVFSD_STARTUP="yes"
Note: With the baselayout-1.11.13-r1 and newer you do not have to add gentoo=noudev or gentoo=nodevfs to the bootloader (ie. kernel param) any longer. If you have a udev enabled system and /etc/conf.d/rc is set to auto or udev, it will boot using udev without using gentoo=nodevfs. If you have a device that needs earlier detection and is not working without it, then put gentoo=nodevfs back in bootloader and try it, /sbin/rc still looks for it. Also, with newer kernels like 2.6.14 (since 2.6.13) devfs is no longer an option in the kernel. So with those kernels nodevfs is irrelevant.
After a lot of trial and error. This is how you can setup these options: (Note: do not use 'devfs=nomount' in your bootloader, the /sbin/rc is not looking for that option, it looks for 'gentoo=nodevfs' or 'gentoo=noudev')
Below part is really only relevant from baselayout-1.8.6.13-r1 to pre 1.11.13-r1 because /etc/conf.d/rc options have changed. So you can skip this if doesn't apply to you. Also with newer kernels like 2.6.14, devfs is no longer an option in the kernel.
This is default setting. You can still boot to Devfs or Udev. If have the same or different kernel setup to use either, then have the proper options shown below for lilo or grub (ie. gentoo=noudev or gentoo=nodevfs)
Devfs or Udev (with Tarball)
RC_DEVICE_TARBALL="yes"
RC_DEVFSD_STARTUP="yes"
This next setting is to Not use the Tarball (devices.tar.bz2), but still be able to boot to devfs if desire. If have the same or different kernel setup to use either, then have the proper options shown below for lilo or grub (ie. gentoo=noudev or gentoo=nodevfs)
Devfs or Udev (without Tarball (ie. pure udev))
RC_DEVICE_TARBALL="no"
RC_DEVFSD_STARTUP="yes"
This next setting is to Not use the Tarball or Do use the Tarball (devices.tar.bz2). But you will not be able to boot to Devfs at all!
Udev (with Tarball) and NO Devfs
RC_DEVICE_TARBALL="yes"
RC_DEVFSD_STARTUP="no"
OR
Udev (without Tarball (ie. pure udev)) and NO Devfs
RC_DEVICE_TARBALL="no"
RC_DEVFSD_STARTUP="no"
After this many variables have been introduced, I can't wait for Devfs to be totally gone, so it is no longer an option!
- Old Baselayout ( <1.8.6.13-r1 )
/etc/init.d/halt.sh
# We need to properly terminate devfsd to save the permissions
If you just comment out in this file (as root), where the blue ## are, you will stop it from saving the state of /dev into the devices.tar.bz2 file when you shut down. This part of the script where it saves the /dev state is near the top of halt.sh
if [ -n "`ps --no-heading -C 'devfsd'`" ]
then
ebegin "Stopping devfsd"
killall -15 devfsd &>/dev/null
eend $?
elif [ ! -e /dev/.devfsd -a -e /dev/.udev ]
then
ebegin "Saving device nodes"
##cd /dev
##try tar -jclpf "/tmp/devices-$$.tar.bz2" *
##try mv -f "/tmp/devices-$$.tar.bz2" /lib/udev-state/devices.tar.bz2
eend 0
fi
/sbin/rc
There is just one line in this file (as root) to comment out where the blue ## is at. This will prevent /sbin/rc from populating /dev from the contents of devices.tar.bz2 file when you start up.
# Fix weird bug where there is a /dev/.devfsd in a unmounted /dev
mymounts="$(awk '($3 == "devfs") { print "yes"; exit 0 }' /proc/mounts)"
if [ -e "/dev/.devfsd" -a "${mymounts}" != "yes" ]
then
rm -f /dev/.devfsd
fi
if [ "${udev}" = "yes" ]
then
ebegin "Mounting ramfs at /dev"
try mount -n -t ramfs none /dev
eend $?
ebegin "Configuring system to use udev"
einfo " Populating /dev with device nodes..."
##try tar -jxpf /lib/udev-state/devices.tar.bz2 -C /dev
populate_udev
if [ -e /proc/sys/kernel/hotplug -a -x /sbin/hotplug ]
then
einfo " Using /sbin/hotplug for udev management..."
elif [ -e /proc/sys/kernel/hotplug ]
then
einfo " Setting /sbin/udev as hotplug agent..."
echo "/sbin/udev" > /proc/sys/kernel/hotplug
else
ewarn " Kernel was not compiled with hotplug support!"
fi
eend 0
# Create problematic directories
mkdir -p /dev/{pts,shm}
# Same thing as /dev/.devfsd
touch /dev/.udev
- If this is a new install and configuring it for a Pure UDEV system, or you get an error when you finally reboot after installing udev and setting it correctly like this: WARNING: Unable to open an initial console. It is because there is no /dev/console and /dev/null. What is happening is that /dev/console is needed before udev is populating the /dev folder. You can try this by manually deleting all static devices in /dev folder from another system, then rebooting to the udev system. You will get the console error. You will also notice that it is faulting at a time before it normally loads udev. If you just make /dev/console though it will then fail for /dev/null. So it needs both of those static in /dev, at least for the time being. The fix for now is to manually create them in your /dev folder.
cd /dev
mknod -m 660 console c 5 1
mknod -m 660 null c 1 3
This will create the /dev/console and /dev/null statically in your /dev folder.
- NVIDIA DRIVERS: Sysfs can now only be used by code using the GPL. So udev won't create the nvidiadevice nodes now. Nvidia will have to take care of creating the device nodes. Nvidia-glx will create the device nodes when X starts.Unfortunetly Nvidia has not fixed this issue with legacy cards. So if you have an older card like: RivaTNT, then you willhave to create the device nodes yourself. See problem devices in the Nvidia Drivers section below on how to proceed. Also see /usr/share/doc/nvidia-kernel-<version>/README.gz in Appendix A to find if your card is Unsupported (legacy) now. The latest version for legacy cards is nvidia-kernel-1.0.7174 and nvidia-glx-1.0.7174-r5
If still having problems with nvidia devices not being created in /dev make sure that you have put nvidia in your /etc/modules.autoload.d/kernel-2.6 file to load at boot. If it isn't in there you won't create the nvidia devices either. So before pulling your hair out, use lsmod command to see that it got loaded.
- Lilo or Grub. This should be the last thing your need to edit: (See problem devices below before you reboot).
If you did not compile DEVFS into the kernel OR are using a >=kernel-2.6.13 (devfs is no longer an option). You are set to go. There is nothing you need to add to the boot-loaders. If you did compile DEVFS into the kernel (Did you compile Devfs to automatically load at boot? If so, go back and recompile the kernel without that option. Last warning!) You need to make a couple decisions. Gentoo will want to load devfs at boot if you compiled it into the kernel, even if you have udev. So here are a few options:
Option 1: Don't load devfs, use udev: You will need to add --> gentoo=nodevfs
Option 2: Don't load udev, use devfs: You will need to add --> gentoo=noudev
Option 3: Have two options in grub or lilo that let you boot to the same kernel, but with either udev or devfs: You need to add two boot options to lilo or grub. One with first option, the other with second option.
Genkernel Options 1: Don't load devfs, use udev: You will need to add --> udev
Genkernel Options 2: Don't load udev, use devfs: You will need to add --> devfs
Lilo examples:
Option 1: Don't load devfs, use udev.
# Udev system mm1 2.6.3 kernel
image ="/boot/bzImage-2.6.3-rc1-mm1"
root="/dev/hdb2"
label="GentooUDEV"
append = "gentoo=nodevfs ide0=ata66 ide1=ata66 hdc=ide-cd"
read-only
Option 2: Don't load udev, use devfs.
# Devfs system mm1 2.6.3 kernel
image ="/boot/bzImage-2.6.3-rc1-mm1"
root="/dev/hdb2"
label="GentooDEVFS"
append = "gentoo=noudev ide0=ata66 ide1=ata66 hdc=ide-cd"
read-only
Option 3: Choose which to use at boot.
# Udev system mm1 2.6.3 kernel
image ="/boot/bzImage-2.6.3-rc1-mm1"
root="/dev/hdb2"
label="GentooUDEV"
append = "gentoo=nodevfs ide0=ata66 ide1=ata66 hdc=ide-cd"
read-only
# Devfs system mm1 2.6.3 kernel
image ="/boot/bzImage-2.6.3-rc1-mm1"
root="/dev/hdb2"
label="GentooDEVFS"
append = "gentoo=noudev ide0=ata66 ide1=ata66 hdc=ide-cd"
read-only
Genkernel Options 1: Don't load devfs, use udev.
# Udev system kernel-2.6.10
image="/boot/kernel-2.6.10-gentoo-r6"
root="/dev/ram0"
label="GenKernel-2.6.10"
append="udev init=/linuxrc real_root=/dev/hda4 video=vesafb:ywrap,vga=0x31B"
initrd="/boot/initrd-2.6.10-gentoo-r6"
Genkernel Options 2: Don't load udev, use devfs.
# Devfs system kernel-2.6.10
image="/boot/kernel-2.6.10-gentoo-r6"
root="/dev/ram0"
label="GenKernel-2.6.10"
append="devfs init=/linuxrc real_root=/dev/hda4 video=vesafb:ywrap,vga=0x31B"
initrd="/boot/initrd-2.6.10-gentoo-r6"
Grub example: Pretty much the same, just different boot-loader.
Option 1: Don't load devfs, use udev.
title=Gentoo UDEV
root (hd0,0)
kernel (hd0,0)/bzImage-2.6.3-rc1-mm1 root=/dev/hda3 gentoo=nodevfs
Another Grub example:
title=Gentoo Main
root (hd0,5)
kernel /bzImage-2.6.4-gentoo-r1 root=/dev/hda7 gentoo=nodevfs hdc=ide-cd ide0=ata66 ide1=ata66 vga=791
If you did not compile DEVFS in the kernel and want to at a later date, recompile your kernel with DEVFS support. Then just go back and edit your boot-loader and add the appropriate changes like above and use one or the other or both. Just can't use udev or devfs at the same time. Sorry, one per customer. Again, I stress: Do Not compile the Kernel to Automatically load Devfs at Boot!!! (Really, really, this is the last warning!!) If your using a >=kernel-2.6.13 then DEVFS is no longer an option to use.
- Problem Devices
Always check your /var/log/error_log_files first, they might have useful clues.
Edit the devices.tar.bz2: Some people are opting to use the default Gentoo udev install and simply change their devices.tar.bz2 to contain only the devices that they need that are not being created by udev. So if your wanting to do this for devices like console and null and/or others. One simple way is by using Ark. There are other ways graphically and commandline. I simply moved devices.tar.bz2 to a temp folder in Home, Viewed it, selected everything but console and null and said delete. It did it, then complained that delete failed, but it didn't. Saved the file. Rechecked and only those two devices are there. Then you can replace the old devices.tar.bz2 with this one. Just make sure you don't edit the scripts to not use the tarball if doing it this way. If your using the Tarball this way, you would want to leave RC_DEVICE_TARBALL="yes"
Nvidia Drivers: Sysfs can now only be used by code using the GPL. Udev won't create the nvidiadevice nodes now. Nvidia will have to take care of creating the device nodes. Nvidia-glx will create the device nodes when X starts.Unfortunetly Nvidia has not fixed this issue with legacy cards. So if you have an older card like: RivaTNT, then you willhave to create the device nodes yourself.
See /usr/share/doc/nvidia-kernel-<version>/README.gz in Appendix A to find if your card is Unsupported (legacy) now. The latest version for legacy cards is nvidia-kernel-1.0.7174 and nvidia-glx-1.0.7174-r5
By the way, it is standard procedure to include nvidia modules in /etc/modules.autoload.d/your_kernel. So make sure you have added it to autoload with the other modules at boot.Until Nvidia corrects this you will have to manually create the nvidia# and nvidiactl devices in /dev. One way of doing this that I use is just add it to your /etc/conf.d/local.start file like so:
mknod -m 660 /dev/nvidia0 c 195 0
mknod -m 660 /dev/nvidia1 c 195 1
mknod -m 660 /dev/nvidiactl c 195 255
- Debian users do not have a local.start file, but can add devices not created with /etc/udev/links.conf . So if using Debian, add to links.conf:
M nvidia0 c 195 0
M nvidia1 c 195 1
M nvidiactl c 195 255
The M creates device nodes using /sbin/MAKEDEV
Not sure how many devices you need. I just create two and haven't had a problem, just change the minor number to match. If using a legacy card and Nvidia starts creating the nvidia device nodes in /dev, you will see an error at boot, that the devices already exist. Then you can just remove the lines.
Nvidia/Alsa Devices: As of udev-021 there is a new binary /sbin/udevstart. Have not used versions with this new binary until emerged udev-023-r1, then ran into the problem with NO nvidia devices and only one alsa device (/dev/snd/controlC0) being created. So if you have installed version 021 and up and find your self rebooting and sitting their looking at a command-line login and no X. Run as root: /sbin/udevstart . It will create the devices and you can then exit back to user and run: startx . Have been informed this is a nvidia and alsa package problem and not a problem with udev.
Mixer/Midi/Dsp Devices: Some people, including me, report that the /dev/mixer isn't being created or /dev/midi or /dev/dsp. The problem is not udev. If you compiled your kernel with them as modules you have to load them in /etc/modules.autoload.d/kernel-2.6. So if those devices aren't being created add: snd_pcm_oss & snd_seq_oss to kernel-2.6 file. The snd_pcm_oss will load snd_mixer_oss itself.
snd_mixer_oss alias is /dev/mixer
snd_pcm_oss alias is /dev/dsp
snd_seq_oss alias is /dev/midi
PPP Device: This appears to be one of the devices still needing the be ported to sysfs, so cannot make a udev rule to create it either. If you need a /dev/ppp you will have to manually create it. You could add it to your local.start like the nvidia device. Others have changed the tarball to just contain devices they need that aren't being created. If want to add it to your /etc/conf.d/local.start just add this line:
mknod -m 660 /dev/ppp c 108 0
- Debian users do not have a local.start file, but can add devices not created with /etc/udev/links.conf . So if using Debian, add to links.conf:
M ppp c 108 0
The M creates device nodes using /sbin/MAKEDEV
Mice, Meese and Mouses: For those of you that find your mouse doesn't work in udev. It really is not a udev problem, it is how you have configured it in the past. Udev (at this time) has 4 device locations you can use for mice.
/dev/input/mice
/dev/input/mouse0 (there will be mouse1, mouse2,.. if you have more, but mouse0 is for 1st mouse)
/dev/misc/psaux (which has symlink /dev/psaux)
So whichever you are using (ie. mouse#, mice or psaux), just make sure your /etc/X11/XF86Config-4 or XF86Config or xorg.conf has the correct location for the device. You could make your own symlink in /etc/udev/rules.d/10-local.rules, but better off editing the XF86Config-4 or XF86Config file.
- Debian users do not have a local.start file, but can add devices not created with /etc/udev/links.conf . So if using Debian, add to links.conf:
- You should be able to reboot now and test your udev system out. You should now see this at boot or something similar. First one is older script, below that is current boot. Your system response my vary depending on options you've chosen. Look in /sbin/rc script if you want more info.
mounting sysfs at /sys
mounting ramfs at /dev
configuring system to use udev
populating /dev with device nodes
using /sbin/hotplug for udev management
OR
Mounting /dev for udev ...
Configuring system to use udev ...
Populating /dev with device nodes ... <--- will see only if using tarball.
Setting /sbin/udevsend as hotplug agent ... <--- will vary depending on udev version
There are a few other issues adding at the bottom here for things have seen on the forums.
- Setfont: If you see a Setfont error at boot time, emerge the latest kbd: emerge -U kbd
- Udev-009: Version 009 will not compile with sysfsutils-0.4.0. You will need to downgrade to sysfsutils-0.3.0, then emerge udev-009, then you can emerge sysfsutils-0.4.0 again. There is a bug report on it. This shouldn't be a problem anymore, because you should be using a newer udev version.
- Dynamic Device Creation: Some of you are wonder about the dynamic device creation that udev is suppose to be performing. It pretty much is populating /dev with most devices now. You won't see this either with the way Gentoo has UDEV setup right now (This only applies to those using the devices.tar.bz2).
LINKS:
Italian Udev Primer translation (Thanks to: Enrico Morelli) Udev Primer: Italian
Japanese Udev Primer translation (Thanks to: Masanao Igarashi) Udev Primer: Japanese
Japanese Udev Primer Misc translation (Thanks to: Masanao Igarashi) Udev Primer Misc: Japanese
German Udev Primer translation (Thanks to: Alexander Minges) Udev Primer: German
DSD's Guide on how to Write Udev Rules: Writing udev rules.
Main UDEV post going at Gentoo Forums:Gentoo Forum Thread.
Snippet of How to Write UDev Rules: Using DSD's Guide on how to Write UDEV Rules. Wanted to see how easy it was. So I picked the device most recently working with udev, my Microtek Scanner. Turned out to be very easy.
Update: udevread.py broken, not worth fixing, referenced here only for example/legacy purposes
New: To find out what a device is being called and other sysfs information on it now I use the command: udevmonitor --env as root. You can use just the udevmonitor command, but with the --env you get a lot more info. I recently used it on a Verizon Razr V3m to see what it was being called and found out it wasn't being claimed by any driver, so had to recompile my kernel with correct driver in. There is a lot of info printed, so just type the command in as root and plug your device in. That should give you plenty of information to write a rule. Below is the original way did it, so just disregard the udevread.py script and you can see how to use the info to develop a rule.
Wrote python script to show sysfs information for all the devices in /dev. New version: Added ability to search /sys for one device. Download it here: udevread-0.3.tar . To run it just extract it, run: python udevread.py --all for all devices in /dev OR python udevread.py --dev device_path. Example: python udevread.py --dev input/mice . Probably better open your terminal fullscreen. To see what the output looks like go here: udevread.py output
Note: You can now get udevinfo by entering the device path now instead of having to search for the class in /sys. Real time saver. Kinda makes udevread.py less useful now. But still has some advantages. Check out DSD's udev rules link to see the updated udevinfo information.
Without udevread.py: First I know that my scanner device in /dev is /dev/sg0. Can also use tail -f /var/log/syslog if have debug on hotplug turned on and see something like this:
Feb 25 09:16:17 decibels default.hotplug[18643]: arguments (scsi_generic) env (OLDPWD=/ DEVPATH=/class/scsi_generic/sg0 ...
So using his information I picked out the best non changing identifiers.
bash-2.05b# find | grep sg0./class/scsi_generic/sg0
./class/scsi_generic/sg0/device
./class/scsi_generic/sg0/dev
./cdev/major/sg0
Based on that response:
bash-2.05b# udevinfo -a -p /sys/class/scsi_generic/sg0device '/sys/class/scsi_generic/sg0' has major:minor 21:0
looking at class device '/sys/class/scsi_generic/sg0':
SYSFS{dev}="21:0"
follow the class device's "device"
looking at the device chain at '/sys/devices/platform/host0/0:0:0:0':
BUS="scsi" <------ Picked this.
ID="0:0:0:0"
SYSFS{detach_state}="0"
SYSFS{type}="6"
SYSFS{device_blocked}="0"
SYSFS{queue_depth}="1"
SYSFS{scsi_level}="3"
SYSFS{vendor}=" "
SYSFS{model}="Scanner V6UPL " <----- Picked this. Yes, the spaces where there in the name.
SYSFS{rev}="1.00"
SYSFS{online}="1"
looking at the device chain at '/sys/devices/platform/host0':
BUS=""
ID="host0"
SYSFS{detach_state}="0"
looking at the device chain at '/sys/devices/platform':
BUS=""
ID="platform"
SYSFS{detach_state}="0"
With udevread.py: First I know that my scanner device in /dev is /dev/sg0. Can also use tail -f /var/log/syslog if have debug on hotplug turned on and see something like this:
Feb 25 09:16:17 decibels default.hotplug[18643]: arguments (scsi_generic) env (OLDPWD=/ DEVPATH=/class/scsi_generic/sg0 ...
************ DEVICE NODE *************
-----------------------------
/dev/sg0
P: /class/scsi_generic/sg0
N: sg0
T: c
M: 020660
S: will show symlinks here.
O: root
G: disk
F: will show rules file used here.
L: 0
U: 9650
Examining /sys for information on Device
looking at class device '/sys/class/scsi_generic/sg0':
SYSFS{dev}="21:0"
follow the class device's "device"
looking at the device chain at '/sys/devices/platform/host0/0:0:0:0':
BUS="scsi" <------ Picked this.
ID="0:0:0:0"
SYSFS{detach_state}="0"
SYSFS{device_blocked}="0"
SYSFS{model}="Scanner V6UPL " <----- Picked this. Yes, the spaces where there in the name.
SYSFS{online}="1"
SYSFS{queue_depth}="1"
SYSFS{rev}="1.00"
SYSFS{scsi_level}="3"
SYSFS{type}="6"
SYSFS{vendor}=" "
looking at the device chain at '/sys/devices/platform/host0':
BUS=""
ID="host0"
SYSFS{detach_state}="0"
looking at the device chain at '/sys/devices/platform':
BUS=""
ID="platform"
SYSFS{detach_state}="0"
-----------------------------
*********** END DEVICE NODE ***********
The results are similar, but you don't have to search for the path in /sys. Plus give a little more info, where you would have to use udevinfo twice to get the same. Plus you can use the --all option to print the same results for all device nodes in /dev.
Making the Rule: Okay, let's see if can use that to make a rule to also call my scanner /dev/sg0 as /dev/scanner .
Where to add the rules? There is /etc/udev/udev-rules , /etc/udev/rules.d/50-udev.rules. Well 50-udev.rules is Default and DSD doesn't recommend editing that file. /etc/udev/udev.rules is defunct now and is not used, you can safely delete it now if up-to-date on your udev version. DSD says to make a new file in /etc/udev/rules.d called 10-local.rules for local rules. So create a new file in /etc/udev/rules.d called 10-local.rules and add below: (Tested, don't need to add the spaces at end of model name).
# Microtek ScannerBUS=="scsi", SYSFS{model}=="Scanner V6UPL", NAME="%k", SYMLINK="scanner"
or the one I use now, if you want or need some extra rules:
BUS=="scsi", SYSFS{model}=="Scanner V6UPL", KERNEL=="sg?", NAME="%k", SYMLINK+="scanner", GROUP="scanner", MODE="0660"I know that my XSane backend is microtek2.conf in /etc/sane.d folder. It looks for a scsi device, so added /dev/scanner to it. And started two scanner programs. Both of them now give me the choice of using /dev/sg0 or /dev/scanner. So works perfect.
What good is this? Well in this instance not much. Mainly an exercise. I mean one is just a symlink to /dev/sg0. But in other cases you might have multiple devices and want to tell which one is which. In some cases though symlinks can be very helpful. See below for example. You can read DSD's Guide for more details.
DVD: Next problem I had was playing dvd's and vcd's,... Using a cdwriter/dvd reader combo drive. DSD has good information on this particular on his howto. Udev creates the symlink /dev/cdroms/cdrom0 fine by default, but may not create the /dev/dvd (which was my case). So couldn't play a dvd or vcd,... Also I am not using scsi emulation, instead using hdc=ide-cd . So, using the udev rules howto, added this to my /etc/udev/rules.d/10-local.rules :
# cdrom/dvd devicesKERNEL="hdc", SYMLINK="dvd"
That created the extra /dev/dvd symlink to my /dev/hdc (remember, you do not have to reboot, just run udevstart from the command line as root). So now have two symlinks to /dev/hdc.
Camera: Some Digital Camera's need a device and some don't. If you camera uses one of the scsi devices (ie. /dev/sd# or /dev/sg#) then see DSD's rules. The ones that do not require a device just require some setup. My camera Kodak DX3215 just requires gphoto2 and can use gtkam or digikam gui's. It does show up in /sys folder, but not in /sys/class as a device I can make a rule on. At least any attempts to do so have failed miserably, at no time during testing was a new device created in /dev and found no reference to any device in /sys except it was on the usb bus. The only problem had was permissions, both gtkam and digikam require a little work to be done in /etc/hotplug/usb.usermap and choose which script wanted to use as /etc/hotplug/usbcam and make usbcam executable. Gtkam works fine, but get error about Could not list folders in '/'. even as root. Digikam doesn't get that error.
Thanks for visiting Decibels Help.
Tip Jar
Free Web Counter