Linux – Does the kernel delete entries in /dev on an initramfs

devicesinitramfslinuxlinux-kernel

I have a fully custom, minimal, embedded Linux (vanilla, 3.3.8, i486, Vortex86dx) system that boots from an initramfs image. No standard distribution scripts are used, just a single rcS file that does the initialisation.

I have an IDE Flash disk with two partitions at /dev/hda1 and /dev/hda2.

As this is a minimal embedded distribution for a fixed system, it has a static /dev directory that contains /dev/hda1 and /dev/hda2, and there is no UDEV.

At the point that init calls rcS, the /dev/hda1 entry is no longer present. No other scripts, user applications or daemons have been run at this point. /dev/hda1 appears to have been deleted by the kernel(?)

I do not have this same problem if I boot my target via an NFS root filing system during my development process.

I use Buildroot to create the /dev directory via the device_table_dev.txt file. e.g. 

# IDE Devices
/dev/hda    b   640 0   0   3   0   0   0   -
/dev/hda    b   640 0   0   3   1   1   1   4

I inspected the rootfs.tar.gz from Buildroot output/images. The /dev directory contains /dev/hda1:

brw-r-----  1 root root  3,   0 Jul  2 13:44 hda
brw-r-----  1 root root  3,   1 Jul  2 13:44 hda1
brw-r-----  1 root root  3,   2 Jul  2 13:44 hda2
brw-r-----  1 root root  3,   3 Jul  2 13:44 hda3
brw-r-----  1 root root  3,   4 Jul  2 13:44 hda4

My post-boot directory listing (done from within rcS, at the top of the script) on the target looks like this:

brw-r-----   1 root   root    3,   0 Jul  2 12:44 hda
brw-r-----   1 root   root    3,   2 Jul  2 12:44 hda2
brw-r-----   1 root   root    3,   3 Jul  2 12:44 hda3
brw-r-----   1 root   root    3,   4 Jul  2 12:44 hda4

/dev/hda1 is missing. /dev/hda2 is a partition on the same disk yet it is still there. Strange.

If I run the Busybox utility "mdev -s", it restores/dev/hda1 on the target and it works normally. e.g. I can mount it

Has anyone ever seen this behaviour before?

Does the kernel delete entries from /dev?

Best Answer

The udev subsystem creates and mounts a tmpfs filesystem on /dev at boot time. The contents are populated by the kernel as devices are detected. Since tmpfs resides in virtual memory, it's not persistent so your changes don't survive across reboots. Even if you have a /dev already, mounting the new filesystem hides the directory and it looks like all your device specials have been deleted. They haven't, but the end result is the same: the specials aren't where you expect.

I suspect you'll find that your hda and hdaX entries have been replaced by sda and sdaX entries. Alternatively, check out /proc/devices and /proc/partitions to get the name udev assigns to the drive.

Sometimes, a quick & dirty solution like fdisk -l /dev/[sh]d[a-z] can help (works better if you have fewer than 26 disks of each type).

By the way, the naming scheme used by udev is standardised, and your static /dev could do worse than to follow the conventions. If udev thinks it's /dev/sda, go with that. You could escape potential weirdness and misunderstandings down the road.

Related Question