Debian GNU/Linux kernel device FAQ

The linux kernel has seen a few different ideas on how users interact with the kernel to gain access to devices such as your fixed disks, terminals, and mice.

The methods have ranged from the dev file system to the latest ideas of udev. Along the way there were other complimentary and conflicting methods.

This FAQ is not a forum for debate over which method is better or worse. There are better forums for that and much bandwidth and time has already been spent. This FAQ is about what support levels exist for the different device interfaces and when you might need to use one or the other.

A brief discussion of the goals and concepts behind each system and a short list of their strengths with as many or less brief points about their shortcommings is also appropriate in this FAQ to help people new to the concepts quickly get up to speed.

What is it?

The dev directory on a system running *nix is the expected location to gain access via file system entries to hardware resources managed by the kernel. It is populated with special files generally of two types; block and character. You can make new files in the dev directory using the mknod command.

If you were using a rescue disk that didn't populate this directory for you, you might need to use mknod to specify that hda is a block device at major number 3 and minor number 0. Then you would need to create the device files for each partition, eg hda1 at major 3 minor 1 and hda2 at major 3 minor 2.

You could have called your special file 'mydisk' if you wanted. The mount command would still work because you specify the device name. Calling it 'mydisk' and then asking for help on #debian or searching the web will return less results than if you had named it 'hda'.

What if you also need access to hdb? That would require a block device file with a major number of 3 and a minor number of 64 of course.

The method of determining the major minor numbers is pretty straight forward if you have the rules at hand, but it's not something that the average user is going to remember. That's why it's nice when the dev directory is prepopulated, or autopopulated.

Pre-populating the dev directory has some downsides. One is that the directory gets pretty large. Debian i386 has over 1000 entries in dev. Most users do not have 1000 devices attached to their system. The dev directory can be intimidating to look through.

Auto-populating the dev directory is more appealing, especially if it works right. In most cases a user doesn't care what file name or major/minor number the kernel and software are using to talk to their printer. They want the printer to print today like it did yesterday without reconfiguring even though they may have plugged it into a different port.

One more concern/issue with the dev directory entries is that the major and minor numbers need to be unique for each device, and we need unique file names. You wouldn't want to have the same entry refer to your first partition on your primary ide disk and to your mouse because they had the same major and minor numbers or the same file name. Coordination of the names and numbers for Linux are done by The Linux Assigned Names and Numbers Authority.


Device access systems




dev is highly supported in Debian Woody. It is the way things are done and things seem to work just fine.




/I don't know what the support for udev is in Debian. Will it be used by default in Sarge if it doesn't release until kernel 2.6 is defacto? I tried udev and didn't get any virtual terminals. Anyone write a 'How to use udev on Debian/Sid'? If not, please include it here./

Here's a brief stab at it:

The udev.rules (/etc/dev/udev.rules) file that the current (0.024-6) udev package installs will cause a boot time failure. (The "no virtual terminals" problem from above).

You need (well, it worked for me ...) to move compat-full.rules to udev.rules (after taking the backup, of course).

Then alter /etc/inittab so that your min/a/mgettys that provide your ?VTs point towards "vc/1" instead of "tty1" (no quotes).

That's all I did, and it works for me. YMMV. Maybe someone else can write about how I should have done it while keeping the vanilla udev rules that the package shipped with.

- Jonathan Matthews (jaycee (at) jaycee ?dot uklinux {dot} net)


Edit your /etc/inittab to use tty1 though tty6 and not have to use the compatability rules. As an example the it should look something like this:

1:2345:respawn:/sbin/getty 38400 /dev/tty1 2:23:respawn:/sbin/getty 38400 /dev/tty2 3:23:respawn:/sbin/getty 38400 /dev/tty3 4:23:respawn:/sbin/getty 38400 /dev/tty4 5:23:respawn:/sbin/getty 38400 /dev/tty5 6:23:respawn:/sbin/getty 38400 /dev/tty6

- Charles Puffer (cpuffer red-belt org)


/!\ devfs is obsolete. Debian/Etch uses udev (except for DebianInstaller)

The devfs system designed by Richard Gooch was included in the kernel around 2.3.46 and will likely be there until at least 2.7. It is currently not activly maintained but seems to work well enough for many people.



The devfs option is compiled into the kernel-image-2.4 packages distributed with Debian. This means that some programs that try to use the proc file system to determine what hardware you have, like noflushd, will expect you to have devfs mounted somewhere.

A quick check to see if devfs is compiled into your system is to cat the partitions file in proc. If the device names are hda1, hda2, etc it is not compiled in. If they are ide/host0/bus0/target0/lun0/part1 than it is.

I've not used devfs on top of dev, anyone who's used it successfully please contribute here.


The remainder of this page after the next divider is for open discussion of how these device systems work in Debian. Preferably the discussions can be refactored from time to time and organized under the proper section above, or new on-topic subsections can be created.

Sharing experiances of configuring these device interface systems on various Debian versions and what software worked or was broken is appreciated.