how does mounting a root filesystem actually work?

How exactly does linux mount the root filesystem? Please explain the mechanics of what actually happens in simple terms.

It all sounds like a chicken and egg conundrum to me:

If the device file '/dev/xxxx' has to be mounted on '/' then doesnt that mean that everything below '/' is now invisible meaning that the original '/dev/xxxx' device file is now hidden?

Also, how does the kernel access '/dev/xxxx' before it even has a root file system, i.e. how does it navigate a path to the /dev directory?

The short answer.

Anything in /dev isnt a file as such, it is not actually stored in the file system, but generate by the kernel at boot time (and dynamically as hardware changes (mknode for example, or when you plug in a USB flash drive).

Stage 1 Boot loader is read from the MBR on the disk, this contains the location of the Stage 2 Boot Loader, on a Linux system, this is generally the small boot partition.

The boot partition contains Grub (lilo) and the kernel images to boot. Once you make a selection through the boot menu, the selected kernel is decompressed and then booted. The kernel uses a small temporary root filesystem in ram, to load modules that tell the kernel how to access disks and other hardware, (this is where the root filesystem is mounted, and device nodes are created)

The net step is init, which is where all the services happen (/etc/init.d/*) networking, httpd, ssh, etc etc...

(I am sure there are holes in that answer somebody smarter than I can correct :P)

Thanks alot @fukawi1 for a good answer that every text I have read on this subject appears to completely ignore. Could I ask a further few questions of you or anybody else that feels up to explaining a few more linux mysteries?

(1) Am I correct in saying that the '/dev' device directory does not actually exist 'on the same plane' as the virtual filesystem as a whole and is actually just an exposed property of the kernel, accessed using similar syntax as filesystem navigation? (Is it more akin to the 'buried' \Device folder in the WindowsNT kernel?)

(2) Is the '/dev' device directory *immune* to being hidden by whatever is mounted on '/' root directory?

(3) what exactly are the entities such as 'proc' 'udev' 'sysfs' that are mounted on my ubuntu system? Are they distinct filesystems in their own right? Where are they located if they are not in the /dev directory? Do *they* exist on the filesystem?

(4) On my ubuntu system 'udev' is mounted on /dev, but doesnt that hide everything that was originaly on /dev at boot time?

(5) Could you explain the important filesystem and /dev entities in a time line of what is/isnt available at critical points on the boot sequence.

Most of your questions might have been answered via linux kernel map check here or here

1. Sorry I don' t understand the question. /dev, which contains char, block and pipe devices (which sometimes did not exist), is created according to info from /sys (sysfs). Both are virtual fs. It is a 'product' of kernel.

2. Yes, /dev is created by kernel. However you can hide/change file-like device nodes within it. Hence, the need of udev rules.

3. They are virtual fs and temporary.

4. The same answer as no. 1 & 2.

5. I don't understand this question. (Sorry, English is not my tongue). You might need to check this and this.

CMIIW

I can't give you an exact answer, but I think your confusion starts from seeing the /dev/... tree as a filesystem, which it principally is not. It is a structure of devices known to the kernel through their respective driver interfaces. When the root filesystem is 'created', the /dev/... tree is mapped into the filesystem, so userspace applications can access them.

I think that the real answer to your question is that the kernel is given, at boot time, a filesystem that it is told to use as the root filesystem. This will be already formatted with enough files to bootstrap the rest of the system to a state where userspace applications can be launched. On desktop and server class PCs, this is very often a RAM disk, called an initrd. The bootloader tells the kernel how to find the root filesystem, which is one of the things that the kernel does some time after the bootloader passes control to the kernel. The kernel commandline can be built into the kernel, or can be supplied by a bootloader. You can view the running kernel's commandline arguments in the /proc/cmdline pseudo-file. This can be a useful way to convey information to userpsace applications from a bootloader.

On a system that boots with grub or lilo, you can usually see an initrd associated with each kernel image in the /boot directory. This will start out as the root filesystem, and provide just enough functionality to proceed with a more complete boot. Usually the initrd is a compressed cpio archive, similar to a tar file. You can use a few standard tools (cpio & compress/gzip, primarily) to unroll them to plain disk files, modify the content, and re-roll into an initrd.

There also exists a bit of a magical tool, probably found in most or many initrd's, called pivot_root. This little gem of a tool is used to swap the existing root filesystem for another, specified, filesystem. This way, a generic kernel can leverage enough smarts from driver modules embedded in an initrd to load more complex filesystems from the likes of spinning media, or network shares (as in NFS_Root). It can gain access to the disk filesystem(s), and then pivot_root to make the disk filesystem the new root. From there, other filesystems are mounted at various mountpoints within the root filesytem. At what point the /dev, /proc, and other pseudo filesystems become exposed, I cannot say; early on after mounting the first root filesystem is a sure bet.

Don't know if this answers your question, but I hope there is something useful for you.

--- rod.