All files in /dev are special files... they represent devices of the computer.
They were created with the mknod syscall. My question is: How can I know the minor and
major numbers that were used to create this special file?
The list is called the LANANA Linux Device List, and it is administered by Alan Cox.
You can find the latest copy online (direct link), or in the Linux source. Its filename in the kernel tree is Documentation/devices.txt.
To see the major and minor numbers that created a node in /dev (or any device node for that matter), simply use ls with the -l option:
22:26 jsmith#undertow% ls -l /dev/xvd?
brw-rw---- 1 root disk 202, 0 Nov 1 20:31 /dev/xvda
brw-rw---- 1 root disk 202, 16 Nov 1 20:31 /dev/xvdb
brw-rw---- 1 root disk 202, 32 Nov 1 20:31 /dev/xvdc
In this example, 202 is the three devices' major number, and 0, 16, and 32 are minors. The b at left indicates that the node is a block device. The alternative is c, a character device:
crw-rw-rw- 1 root tty 5, 0 Nov 22 00:29 /dev/tty
$ ls -l /dev/fd0 /dev/null
brw-rw---- 1 root floppy 2, 0 Nov 22 19:48 /dev/fd0
crw-rw-rw- 1 root root 1, 3 Nov 22 19:48 /dev/null
$ stat -c '%n: %F, major %t minor %T' /dev/fd0 /dev/null
/dev/fd0: block special file, major 2 minor 0
/dev/null: character special file, major 1 minor 3
Most device numbers are fixed (i.e. /dev/null will always be character device 1:3) but on Linux, some are dynamically allocated.
$ cat /proc/devices
Character devices:
...
10 misc
...
Block devices:
...
253 mdp
254 device-mapper
$ cat /proc/misc
...
57 device-mapper
...
For example, on this system, it just so happens that /dev/mapper/control will be c:10:57 while the rest of /dev/mapper/* will be b:254:*, and this could differ from one boot cycle to another -- or even as modules are loaded/unloaded and devices are added/removed.
You can explore these device registrations further in /sys.
$ readlink /sys/dev/block/2:0
../../devices/platform/floppy.0/block/fd0
$ cat /sys/devices/platform/floppy.0/block/fd0/dev
2:0
$ readlink /sys/dev/char/1:3
../../devices/virtual/mem/null
$ cat /sys/devices/virtual/mem/null/dev
1:3
You can also use stat.
$ stat -c 'major: %t minor: %T' <file>
Especially for block devices:
$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sda 8:0 0 90G 0 disk
├─sda1 8:1 0 4G 0 part [SWAP]
├─sda2 8:2 0 4G 0 part /
Alternative that doesn't depend on stat:
$ cat /sys/class/*/random/dev
1:8
Related
I'm trying to create a sparse file (for a QEMU HDD image).
Both qemu-img and fallocate are proving confusing.
$ fallocate -l 100M disk.img
$ ls -lsh disk.img
101M -rw-r--r-- 1 i336 users 100M Jul 22 12:03 disk.img
Note the 101M. strace shows a successful syscall:
$ strace fallocate -l 100M disk.img
open("disk.img", O_RDWR|O_CREAT|O_LARGEFILE, 0666) = 3
fallocate(3, 0, 0, 104857600) = 0
$ ls -lsh disk.img
101M -rw-r--r-- 1 i336 users 100M Jul 22 12:03 disk.img
I'm not sure if stat is the right tool, but just in case..
$ stat disk.img
File: 'disk.img'
Size: 104857600 Blocks: 204808 IO Block: 4096 regular file
Device: 802h/2050d Inode: 549166 Links: 1
Access: (0644/-rw-r--r--) Uid: ( 1337/ i336) Gid: ( 100/ users)
A possible (very weird) clue: 104857600/204808 = 511.9800. (File size / block count)
qemu-img has similar output. (I found the preallocation option in the manual.)
$ qemu-img create -f raw -o preallocation=falloc disk.img 100M
Formatting 'disk.img', fmt=raw size=104857600 preallocation=falloc
$ ls -lsh disk.img
101M -rw-r--r-- 1 i336 users 100M Jul 22 12:06 disk.img
Here's the annoying bit: the image appears to be using real space on disk.
$ df -h /; fallocate -l 1G disk.img; df -h /
Filesystem Size Used Avail Use% Mounted on
/dev/root 48G 43G 3.5G 93% /
Filesystem Size Used Avail Use% Mounted on
/dev/root 48G 44G 2.5G 95% /
And yet, just like a sparse file, it takes no time to create!
$ time fallocate -l 3.3G disk.img
0.00user 0.57system 0:00.91elapsed 63%CPU (0avgtext+0avgdata 5424maxresident)k
200inputs+0outputs (0major+68minor)pagefaults 0swaps
0.91 seconds, on a 5400RPM HDD. There is no way I'm not creating a sparse file.
And yet no matter what tool I use, it appears to be using 101MB of space right off the bat.
What could I be doing wrong or have misconfigured?
$ cat /etc/fstab
/dev/sda2 / ext4 rw,user_xattr 0 0
I can create a new urandom device on a some directory (test_urandom in below example), and it works as expected. E.g.
test_urandom$ sudo mknod -m 0444 ./urandom c 1 9
test_urandom$ ls -l
total 0
cr--r--r-- 1 root root 1, 9 Jun 9 09:06 urandom
test_urandom$ head -c 10 ./urandom
�O1�9�^
However, if I create the same device node in another directory, which in my case is an ext4 filesystem on a LVM (Logical Volume Management), it failed and system complained with permission denied.
test_urandom_lvm$ sudo mknod -m 0444 ./urandom c 1 9
test_urandom_lvm$ ls -l
total 0
cr--r--r-- 1 root root 1, 9 Jun 9 09:06 urandom
test_urandom_lvm$ head -c 10 ./urandom
head: cannot open ‘./urandom’ for reading: Permission denied
If I am allowed to create a device in the filesystem, why not allowed to read the device? What caused the permission denied? What changes is needed to make it work?
The filesystem is mounted with the nodev option, which inhibits block and character special device operation. Mounting it dev will allow them to work.
I was compiling a custom kernel, and I wanted to test the size of the image file.
These are the results:
ls -la | grep vmlinux
-rwxr-xr-x 1 root root 8167158 May 21 12:14 vmlinux
du -h vmlinux
3.8M vmlinux
size vmlinux
text data bss dec hex filename
2221248 676148 544768 3442164 3485f4 vmlinux
Since all of them show different sizes, which one is closest to the actual image size?
Why are they different?
They are all correct, they just show different sizes.
ls shows size of the file (when you open and read it, that's how many bytes you will get)
du shows actual disk usage which can be smaller than the file size due to holes
size shows the size of the runtime image of an object/executable which is not directly related to the size of the file (bss uses no bytes in the file no matter how large, the file may contain debugging information that is not part of the runtime image, etc.)
If you want to know how much RAM/ROM an executable will take excluding dynamic memory allocation, size gives you the information you need.
Two definition need to be understood
1 runtime vs storetime (this is why size differs)
2 file depth vs directory (this is why du differs)
Look at the below example:
[root#localhost test]# ls -l
total 36
-rw-r--r-- 1 root root 712 May 12 19:50 a.c
-rw-r--r-- 1 root root 3561 May 12 19:42 a.h
-rwxr-xr-x 1 root root 71624 May 12 19:50 a.out
-rw-r--r-- 1 root root 1403 May 8 00:15 b.c
-rw-r--r-- 1 root root 1403 May 8 00:15 c.c
[root#localhost test]# du -abch --max-depth=1
1.4K ./b.c
1.4K ./c.c
3.5K ./a.h
712 ./a.c
70K ./a.out
81K .
81K total
[root#localhost test]# ls -l
total 36
-rw-r--r-- 1 root root 712 May 12 19:50 a.c
-rw-r--r-- 1 root root 3561 May 12 19:42 a.h
-rwxr-xr-x 1 root root 71624 May 12 19:50 a.out
-rw-r--r-- 1 root root 1403 May 8 00:15 b.c
-rw-r--r-- 1 root root 1403 May 8 00:15 c.c
[root#localhost test]# size a.out
text data bss dec hex filename
3655 640 16 4311 10d7 a.out
If using size not on executable, OS will report an error.
Empirically differences happen most often for sparse files and for compressed files and can go in both directions.
du < ls
Sparse files contain metadata about space needed for an application, which ls reads and applies for its result, while du doesn't. For example:
truncate -s 1m test.dat
creates a sparse file consisting entirely of nulls without disk usage, ie. du shows 0 and ls shows 1M.
du > ls
On the other hand du can indicate, as in your case, files which might occupy a lot of space on disk (ie. they spread among lots of blocks), but not all blocks are filled, i.e. their bytesize (measured by ls) is smaller than du (looking at occupied blocks). I observed this rather prominently e.g. for some python pickle files.
I have created a root filesystem with buildroot that is using squashfs. It works fine, and now I would like to create an overlayfs, which would hold /home and /etc directories.
For this purpose, I wanted to create a simple jffs2 filesystem with couple of files:
jlumme#simppa:~/projects/jffs2_home$ ls -la
total 20
drwxrwxr-x 4 jlumme jlumme 4096 Apr 21 16:21 .
drwxrwxr-x 6 jlumme jlumme 4096 Apr 21 16:21 ..
drwxrwxr-x 2 jlumme jlumme 4096 Apr 21 13:45 default
drwxrwxr-x 2 jlumme jlumme 4096 Apr 21 13:45 ftp
-rw-rw-r-- 1 jlumme jlumme 24 Apr 21 15:34 test.txt
The flash chip I use is SST25VF064C, so I believe it's erase block size is 64 KB, and thus I create a filesystem image from that folder:
mkfs.jffs2 -r jffs2_home/ -e 64 -o home.jffs2
$ ls -la
-rw-r--r-- 1 jlumme jlumme 496 Apr 21 15:42 home.jffs2
(Suprisingly, if I set -e 32, or even -e 4, the resulting binary image doesn't change at all???).
Nevertheless, moving on, I have aligned my mtdblock that contains home, to 64KB, and my flash layout looks like this:
uboot/<0x00000000 0x40000>
kernel/<0x00040000 0x3D9000>
dtb/<0x00419000 0x10000>
rootfs/<0x00429000 0x1F7000>
home/<0x00620000 0x1E0000>
On my board, I can mount the mtdblock4 fine, and I can read the file contents properly. However, if I modify the file, and try saving it, vi complains:
[ 77.030000] jffs2: Node totlen on flash (0xffffffff) != totlen from node ref (0x00000044)
Now, if I unmount the filesystem, and remount it, I start getting complaints immediately:
# mount -t jffs2 /dev/mtdblock4 /home/
[ 99.740000] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x001d4070: 0xff0a instead
[ 99.760000] jffs2: Empty flash at 0x001d4074 ends at 0x001d412c
[ 99.770000] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x001d412c: 0xffff instead
[ 99.790000] jffs2: Empty flash at 0x001d4130 ends at 0x001d4194
[ 99.790000] jffs2: jffs2_scan_eraseblock(): Magic bitmask 0x1985 not found at 0x001d4194: 0xff0a instead
I suppose now my filesystem is already corrupted... and I don't really understand the reason for it..
Any ideas where am I going wrong with this ? Thanks for all suggestions..
This is what I did to solve the issue.
Updated newer MTD drivers from http://www.linux-mtd.infradead.org/
- There was new code for SST25V064C chip
Made sure the area reserved for JFFS2 was initialized to 0xFF
(possibly optional) Specified more accurately the creation of jffs2 file system:
mkfs.jffs2 -e 64 -l -p -s 4096 -r jffs2_home/ -o home.jffs2
With these changes the file system now reads and writes as expected.
I have written a simple UART serial driver in embedded Linux running busybox with mdev rules. I have provided .dev_name as "ttyC2C" in my driver code.
static struct uart_driver serial_omap_reg = {
.owner = THIS_MODULE,
.driver_name = "Omap-C2C-Serial",
.dev_name = "ttyC2C",
.nr = OMAP_MAX_HSUART_PORTS,
.cons = NULL,
};
However the node is getting created in
./sys/devices/platform/omap_c2c_uart.0/tty/ttyC2C0
./sys/class/tty/ttyC2C0
/ # ls -l ./sys/class/tty/ttyC2C0
lrwxrwxrwx 1 root 0 0 Jan 1 00:14 ./sys/class/tty/ttyC2C0 -> ../../devices/platform/omap_c2c_uart.0/tty/ttyC2C0
/ # ls -l ./sys/devices/platform/omap_c2c_uart.0/tty/ttyC2C0
-r--r--r-- 1 root 0 4096 Jan 1 00:14 dev
lrwxrwxrwx 1 root 0 0 Jan 1 00:14 device -> ../../../omap_c2c_uart.0
drwxr-xr-x 2 root 0 0 Jan 1 00:14 power
lrwxrwxrwx 1 root 0 0 Jan 1 00:14 subsystem -> ../../../../../class/tty
-rw-r--r-- 1 root 0 4096 Jan 1 00:14 uevent
/ #
The mdev rules for tty are:
tty 0:5 0666
tty.* 0:0 0620
How to get device node as /dev/ttyC2C ?
You are confusing two things. The sysfs nodes you are seeing are indeed maintained by the kernel based on the kobject hierarchy. However device nodes are entirely a user space problem and can exist anywhere (although by convention are under /dev).
So by hand you would first find the major:minor numbers:
cat /sys/class/tty/ttyC2C0/dev
And then:
mknod /dev/ttyC2C0 c ${MAJOR} ${MINOR}
However as you have already indicated you are using the fork of udev, mdev to handle the user space creation of device nodes. However the matching rules look odd to me. I assume mdev has the equivalent of udevadm which should help you write the matching rules. For example my USB tty driver can be queried like this:
udevadm info -a -p /sys/class/tty/ttyUSB0
And looking at the tree produced I can see a list of udev attributes which I could use to match. So in my case:
KERNEL=="ttyUSB0", DRIVERS=="ftdi_sio", NAME="ttyUSB0"
Would be enough to match (although my distro has a lot more complex matching rules to deal with dynamic setups).
I'm guessing but I suspect the mapping rule you want would look more like:
KERNEL=="ttyC2C", NAME="ttyC2C"
Although you might need a bit more to ensure you get device nodes created for each port (minor number?).
Does adding a specific mdev rule to your /etc/mdev.conf for ttyC2C resolve your problem ?
Something like one of the following ?
ttyC2C[0-9]+ root:tty 620
or
ttyC2C[0-9]+ root:tty 620 #/bin/ln -sf $MDEV ttyC2C