UDEV is a service/package that detects new devices connected to the linux server and launches predefined scripts and also makes them accessible through /dev. In the old days people had to use “mknod DEVICENAME [b,c,p] MAJOR# MINOR#(ex: “mknod /dev/random b 12 5” or “mknod /dev/ttyS0 c 4 64” or “mknod /dev/nicedisk b 45 0” or “mknod /dev/sda b 8 0” or “mknod /dev/sda1 b 8 1” or “mknod /dev/sda2 b 8 2” or “mknod /dev/sdb b 8 16” or “mknod /dev/sdb1 b 8 17” – notice the device name can be anything, such /dev/nicedisk. notice the major number stays the same for similar devices as they use the same drives. Also notice that there are b[block], c[character], or p[fifo] type of devices that can be made) to associate a new device to its major number (which represented a unique identifier that tied a certain device to a driver) and minor number (which sub-categorized the device within the driver). For example: The major number 8 is used for “sd” devices and the minor numbers represent the drive letter and partition – you can see that if you run “cat /proc/partitions“. There was a newer system then mknod which udev built from called mdev. mdev was a device discovery tool which had to be manually ran like this “mdev -s“. Well udev is like “mdev -s” except it runs when it detects a new device. udevadm can be used to gather lots of information about a device. udev can also use all of this information when it detects a device to do certain things, such as make a symlink of sda that looks like this “/dev/0:7200 –> /dev/sda” meaning “port 1. rpm 7200” and sdb can be “/dev/5:5600 –> /dev/sdb” meaning meaning “port 6 rpm 5600″ – this is just an example of how useful udev can be, for example a linux admin can reference up a drive based on slot number or rpm.

SIDENOTE: With mknod, how did one know what major and minor number to associate to a device? Well one can use previous similar devices to figure out the pattern such as based on the above info I can predict that since sda is b,8,0 and sda1 is b,8,1 then I can assume sda3 is b,8,3 (TIP: for making the pattern connection use “cat /proc/partitions” for storage block devices). Now if you dont have anything to make a pattern out of, then just use the LANANA LINUX DEVICE LIST (administred by Alan Cox – one of the main linux beards). You can find the latest copy online ( or in the linux kernle source code under the folder Documentation/devices.txt

SIDENOTE: History timeline, first it was mknod, then mdev, then udev




To gather info about a device using udevadm you need to know the path of the device. To get the path of the device find it in /sys/devices or use “udevadm info -q path -n DEV_PATH

Example1: sda & sdb

Imagine a prefix of /sys for each of those devices paths.
sda is really /sys/devices/pci0000:00/0000:00:1f.2/ata1/host0/target0:0:0/0:0:0:0/block/sda
sdb is really /sys/devices/pci0000:00/0000:00:1f.2/ata2/host1/target1:0:0/1:0:0:0/block/sdb


Now to get info about the device (udev info) do this: “udevadm info -a -p DEV_SYS_PATH

Example2: for sda

See output below. sdb will have similar output


You can can combine both results like this: “udevadm info -a -p udevadm info -q path -n DEV_PATH” or instead of back ticks command substitution use dollar-sign-parenthesis substitution, “udevadm info -a -p $(udevadm info -q path -n DEV_PATH)”

Example3: sda

All of the above will provide the same output seen at the bottom


Now what if we wanted to poll every device in /dev, then use this script:

SIDENOTE: the i will equal /dev/sda and /dev/sdb and so on.
SIDENOTE: the | grep . removes those extra new lines you see at the bottom. Then the echo; echo; just adds a good seperator between the devices for easier viewing
SIDENOTE: I didnt include my own system output so that you didnt get too much info. Just run it on your own system to check it out.





Lets dive deeper into udevadm info arguments, and maybe we can unlock more things.

Checkout the –help of “udevadm info”, to make sense of the options

Each of those can also be used by single letters:
-q for query, -n for name, -a for attribute walk (get all attributes), -p for path

So check this out, we can actually get the device path by doing this (as seen above):

Meaning: udevadm-info query(get) the path of device named sda. In other words: Udevadm-info please show us the path of the device sda.

Or you can get all of the query-able information like this:

You can also get all of the query-able information by path:

Or you can get every attribute by path or name* (see CORRECTION TO SECTION 1 below)

Get all Attributes by device sys path:

Get all Attributes by device name:

* CORRECTION TO SECTION 1: I said you cant get all attribute by using the name (such as sda) and that you needed to know the path (such as /devices/pci0000:00/0000:00:01.1/0000:02:00.0/host0/port-0:0/end_device-0:0/target0:0:0/0:0:0:0/block/sda). But that is in correct. PS: I only said that we are limited to get all attributes if we quote the full devices’s sys path because the citation I quoted said that, but I tested it myself and the message of the author was incorrect.

So that means instead of using this to get all the attributes of sda:

We can use this simpler one:

And to get the attributes of every device:

NOTE: getting all of the attributes, udevadm does an “attribute walk” through all of the sys files


You can use udevadm test “sys path of device” to get even more information. The above just shows all of the attributes with udevadm info -a (–attribute). Or it shows all of the queriable information with udevadm info -q (–query). However there is also env variables for each device. Which can be used when device rules are made. For example the ID_CHANNEL env variable of a device tells you the slot number.

TIP: /sys/block/ has symlinks to all of the /sys/devices paths are useful

Like this:

Check out the output of these 3 identical commands:


NOTE: all of these variables seen in “udevadm test” and “udevadm info” can be used while making rules. Checkout these rules.

Here is an example of a rule that looks at the drives and makes a symlink for it in /dev/disk/internal which has the channel (so it has the slot number), model number, serial number, firmware version of the drive, and rpm of the drive

That rule looks for a device that is a “disk” and has an ID_CHANNEL of anything (“?*” means it just cant be empty – usb drives dont have ID_CHANNEL so they dont appear here. ID_CHANNEL is output like this 0:3 where 3 is the slot number, just add 1 and it will 4). If the ID_CHANNEL doesnt exist then this rule is skipped and a symlink is not made. The Symlink that is made if the device is a disk and has the variable ID_CHANNEL will be of the format disk/internal/stuff. meaning that it will go in the /dev/disk/internal folder (udev will auto make the folder /dev/disk/internal). The “stuff” will be ID_CHANNEL:ID_MODEL:ID_SERIAL_SHORT:ID_REVISION:ID_ATA_ROTATION_RATE_RPM. Notice all of these variables are shown with “udevadm test /sys/block/sd*”.

Example of this rules /dev’s results:

SIDENOTE: this rule exists on the new ReadyNAS OS6 units. I dont recommend editing them without risk of hurting your warranty. However now you know how to see which /dev/sd* letter ties to which slot. Simply look at “ls -lisah /dev/disk/internal” and add 1 to the second number to get the slot number.

NOTE: if you edit any rules (dont do so on the ReadyNAS or else might hurt). Reset them like this and check out the /dev folder:


2 thoughts on “udev & mknod & mdev — and — Udevadm to gather info about a device & all devices

Leave a Reply

Your email address will not be published. Required fields are marked *