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'm trying to understand the boot process of a machine as a whole from the time you hit the power button. There's this one piece from bootloader to initramfs stage I don't quite understand among some other smaller bits.

Given this Grub configuration for an entry, taken from a recent Ubuntu default installation:

insmod gzio
insmod part_msdos
insmod ext2
set root='(hd0,msdos1)'
search --no-floppy --fs-uuid --set=root 96fb7310-5adb-4f66-bf59-04acd08d76a3
echo    'Loading Linux x.y.z ...'
linux   /vmlinuz-x.y.z root=/dev/mapper/some-device-name ro nomodeset 
echo    'Loading initial ramdisk ...'
initrd  /initrd.img-x.y.z

What does this actually do in terms of the system state and memory? I understand that Grub's task is to "load and run the kernel" and it has its own set of modules to access files on devices (or network) to get to them. In the example here insmods, set root and search - but this is just from the perspective of Grub, and not shared with the kernel, right?

I'm also guessing that Grub is loading (a copy?) of the kernel into memory (linux command) and kicking it to start execution. (two different steps apparently - so, how?) The parameters given can be read in the kernel and interpreted (is this a big string mapped into memory somewhere?) and provide the options to arrange things requested.

I also see this initrd option. This points to my gzip-compressed initramfs, needed to boot the actual root device specified by root=. But how is this initramfs provided to the kernel? It is not passed any memory addresses to where it can load it, nor is it able to access it itself, as it is loaded already before the kernel is started. Some kernel documentation says this initramfs file system 'device' is accessible through /dev/ram0, but I don't see how it becomes an accessible device file to start with. There's something happening under water I don't see, I guess.

I also don't see how this relates to other boot loaders, including embedded platforms, for example using U-boot/Coreboot. Is this doing the same thing as Grub (same standard memory addresses?) and to what extent does these compare to Grub regarding loading kernel/initrd?

Just to be clear on my questions, I think I do understand why the different boot stages exist and what transitions take place, yet I don't see how they take place and what the exact responsibilities are to each of the stages. I have the feeling I'm missing out on some "standard" to which this all comes down to.

I would appreciate some explanation on this.

share|improve this question
    
Note the implicit boot command at the end of the sequence. I'm not sure exactly what it does in Grub, but if you use the Grub command line to enter these commands manually, you need to boot or it will just sit forever at grub> (or at least, until you get bored and turn the computer off). The preceding commands "merely" set up an environment. –  Michael Kjörling Dec 19 '12 at 9:09
    
@MichaelKjörling From my understanding now, boot will make the CPU jump to the address of the kernel loaded (start execution). For a menu entry this is implicitly defined. see this. –  gertvdijk Dec 19 '12 at 11:19

2 Answers 2

up vote 4 down vote accepted

In general there has to be some kind of protocol because typically it is not enough to just load a file into memory and jump at a specific location but you have to either pass additional arguments like kernel parameters, i.e. accessing memdisk arguments from DOS.

As this is hardware dependent (arm is different than x86 for instance) you have to find the correct information, see this article about booting arm or the Linux/x86 boot protocol for some examples.

share|improve this answer

The bootloader stores the initrd into a location in memory, and tells the kernel the memory address of the initrd image. Most modern linux systems use the initramfs scheme using dracut, which is actually a cpio archive (rather than a disk image) that is unpacked into a tmpfs filesystem created by the kernel shortly after execution.

share|improve this answer
    
I got that far; but how does the bootloader tell the kernel about the location in memory? Where does the kernel retrieve that memory address? –  gertvdijk Dec 18 '12 at 21:44
2  
@gertvdijk have a look at kernel.org/doc/Documentation/x86/boot.txt it describes how the bootloader communicates with the kernel, i.e. the bootloader has to provide the kernel parameters etc. as well. –  Ulrich Dangel Dec 18 '12 at 22:23
    
@UlrichDangel Nice! Exactly what I was looking for. Apparently, it's an hardware-specific (x86 in this case) protocol describing it all. Write it as an answer with a short description and I'll accept it. –  gertvdijk Dec 18 '12 at 22:52

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.