Boot process
 

In an interiew, I was asked to explain about the boot process. So I did tell 'em from start to finish.

I told 'em that once the Grub is loaded onto memory, it reads the /boot/grub/grub.conf file for kernel and initrd image info. once kernel is loaded on memory, it starts the init process.

But the interviewer said that from the Grub loading onto memory and the init process starting, there are a lot of steps that have been skipped.

Can anyone tell me where did I go wrong?

Also, if the kernel info in /boot/grub/grub.conf file is just a virtual image(VMLinuz), then where is the actual kernel info?

Yeah, you actually skipped some important steps. The grub.conf file contains the filename of the kernel image and optionally the name of an initial ramdisk. First the kernel image is loaded into memory. After that the initrd is also put to memory. Then on x86 architectures the header of the kernel image is analyzed and the 16 bit startup code is executed (arch/x86/boot/header.S). This will prepare the machine for switching to protected mode (arch/x86/boot/main.c): Prepare memory, copy boot parameters, such as command line or initrd addresses, then CPU is switched to protected mode (arch/x86/boot/pm.c) and the internal kernel structures get initialized (arch/x86/kernel/setup.c). After that the external hardware will be initialized: Setting up the PCI bus and other subsystems. When this is done, the root file system is mounted (either from the root= option or from some hardcoded default value). After having done this, the init process is searched for (usually /sbin/init or init= value), loaded into memory and then executed. What follows depends on the init-configuration.

This description was x86-based, but the boot process is similar on other architectures. Maybe you want to look at init/main.c, especially at the start_kernel() function for details and /sbin/init gets loaded in the function init_post() in init/main.c

...or look at the gazillion docs describing the boot process like http://www.ibm.com/developerworks/li...y/l-linuxboot/.

<rant>
And why is all that detail relevant to the majority (say 99%) of the Linux user community - sysadmins included ?.
Even people who want to start writing (simple) kernel modules don't need to know much more than the OP answered.

Sure some people like the detail, sure some (very few) need it.

What about reading a disk file ?. Do you need to know about how the kernel structures map to functions at the VFS layer so that block device drivers can resolve the appropriate inode(s) ?.

Bah humbug.

</rant>