Thanks for taking the time to post this. I had no idea the grub code was this accessible. Some things to note: switching to Real Mode uses real addressing, and is a backwards compatibility feature where all x86 systems start in real mode. Real mode has 20 bit addressing and is limited to 1MB of RAM. So one of the functions of grub is to switch from Real Mode to Protected Mode (introduced in 286). You also came across some A20 code (21st addressing line) which relates to this as well when switching to protected mode. There was a point where you were wondering where the menu is displayed. It is in the same file as the code that gets the menu item and executes the script, but a bit hidden because Grub has a simplistic display plugin architecture, so it can handle displaying the menu in text mode and graphical modes, and can handle multiple layers of submenus. Searching for "viewers" in that file will give you a better idea. One thing I'm curious about, and you didn't have time to look at in the 1 hour, was how initrd is executed. I remember that it is compressed, so there must be some zlib decompression code in grub, but then how does it look in initrd, find a kernel, and then execute it? Presumably initrd is a filesystem that gets mounted, I'd be curious to know what fstype it is, and somewhere there must be a file that is a kernel that gets loaded into memory and executed. Does grub just jump to the first byte in the kernel to get it all started? I came here from a Hacker News post, and thanks again, and your style of not looking at it beforehand and thinking out loud is enjoyable to watch.
Thanks, this is so helpful! And thanks for the kind words :) That's a good question about initrd. I looked it up, and according to this post [0], the missing part is vmlinuz. Vmlinuz is the compressed kernel and as you guessed, we just start executing at the head of the kernel (which contains the decompression routine). Vmlinuz then mounts the initrd. Vmlinuz is of course passed as an argument to grub, which is why it doesn't need to search initrd for a kernel. Although whether the decompression routine is literally the first byte I'm not sure. re: the fstype of initrd, what I'm seeing is that initrd is just a compressed file system image, often something like ext2 [1]. The drive rs for that file system have to be compiled into the kernel. For initramfs, the file system is a cpio archive that gets unpacked onto tmpfs. [0] dev.to/er_dward/understanding-the-initrd-and-vmlinuz-in-linux-boot-process-534f [1] en.wikipedia.org/wiki/Initial_ramdisk
@@ants_are_everywhere Ah! I remember seeing vmlinuz but I never understood what it was there for. I think it's really cool that it contains its own decompression routine. Thank you for the helpful links!
Thanks for taking the time to post this. I had no idea the grub code was this accessible. Some things to note: switching to Real Mode uses real addressing, and is a backwards compatibility feature where all x86 systems start in real mode. Real mode has 20 bit addressing and is limited to 1MB of RAM. So one of the functions of grub is to switch from Real Mode to Protected Mode (introduced in 286). You also came across some A20 code (21st addressing line) which relates to this as well when switching to protected mode.
There was a point where you were wondering where the menu is displayed. It is in the same file as the code that gets the menu item and executes the script, but a bit hidden because Grub has a simplistic display plugin architecture, so it can handle displaying the menu in text mode and graphical modes, and can handle multiple layers of submenus. Searching for "viewers" in that file will give you a better idea.
One thing I'm curious about, and you didn't have time to look at in the 1 hour, was how initrd is executed. I remember that it is compressed, so there must be some zlib decompression code in grub, but then how does it look in initrd, find a kernel, and then execute it? Presumably initrd is a filesystem that gets mounted, I'd be curious to know what fstype it is, and somewhere there must be a file that is a kernel that gets loaded into memory and executed. Does grub just jump to the first byte in the kernel to get it all started?
I came here from a Hacker News post, and thanks again, and your style of not looking at it beforehand and thinking out loud is enjoyable to watch.
Thanks, this is so helpful!
And thanks for the kind words :)
That's a good question about initrd. I looked it up, and according to this post [0], the missing part is vmlinuz. Vmlinuz is the compressed kernel and as you guessed, we just start executing at the head of the kernel (which contains the decompression routine). Vmlinuz then mounts the initrd. Vmlinuz is of course passed as an argument to grub, which is why it doesn't need to search initrd for a kernel. Although whether the decompression routine is literally the first byte I'm not sure.
re: the fstype of initrd, what I'm seeing is that initrd is just a compressed file system image, often something like ext2 [1]. The drive rs for that file system have to be compiled into the kernel. For initramfs, the file system is a cpio archive that gets unpacked onto tmpfs.
[0] dev.to/er_dward/understanding-the-initrd-and-vmlinuz-in-linux-boot-process-534f
[1] en.wikipedia.org/wiki/Initial_ramdisk
@@ants_are_everywhere Ah! I remember seeing vmlinuz but I never understood what it was there for. I think it's really cool that it contains its own decompression routine. Thank you for the helpful links!