Take the 2-minute tour ×
Unix & Linux Stack Exchange is a question and answer site for users of Linux, FreeBSD and other Un*x-like operating systems.. It's 100% free, no registration required.

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?

share|improve this question
    
It may be helpful (for the benefit of others searching for solutions) to indicate that this is a completely custom-built system. –  Alexios Jul 4 '12 at 11:25
add comment

1 Answer 1

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.

share|improve this answer
    
This is a custom distribution for a fixed embedded target so it only needs a static /dev and there is no udev. I only run mdev as the hotplug agent because I handle USB Flash drives. The directory listing from the target was performed right after init was executed by the kernel. No other applications or daemons are running at this time. –  Mr Stinky Jul 3 '12 at 13:31
    
Interesting! Well, the kernel has no reason to delete anything in /dev, so if you're not running udev, you should look at userspace code that might. And check if something's mounted on /dev anyway. Possibly remnants of an earlier udev startup? How pristine are the boot scripts? –  Alexios Jul 3 '12 at 15:56
    
The thing is 100% custom. There is no remnants of anything. The boot scripts are all my own doing. My /etc/init.d/rcS simply does this: #!/bin/sh ls /dev ... and I can see that /dev/hda1 is missing. There is nothing else running before I list the /dev directory. –  Mr Stinky Jul 3 '12 at 18:22
    
The only thing I can think of checking might be the /etc/inittab file which is the only user customisable script that gets called before /etc/init.d/rcS AFAIK it only calls /etc/init.d/rcS but I did have some other mount scripts in there earlier, I may have left some cruft that I have forgotten about. I will have to check when I get back in to work tomorrow. –  Mr Stinky Jul 3 '12 at 18:28
    
If the problem isn't in the full userspace, it must be somewhere in the initramfs. But it's definitely not the kernel's fault. –  Alexios Jul 4 '12 at 11:22
show 1 more comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.