HN Explorer

Ask HN: Where can I find a primer on how computers boot?

457 points by mog_dev ↗ HN
As a developer, I recently encountered challenges with GRUB and discovered I lacked knowledge about my computer's boot process. I realized terms like EFI partition, MBR, GRUB, and Bootloader were unfamiliar to me and many of my colleagues. I'm seeking introductory and easy-to-understand resources to learn about these concepts. Any recommendations would be appreciated!

95 comments

[ 3.1 ms ] story [ 164 ms ] thread
anenefan
I would say start at wikipedia looking up terms and consider a couple of weeks to grasp the simple notions of what's involved. Start with MBR, limits on old drives, dig into various tricks to get around limitations ... not really relevant present day but it's good insight.

Problems with bootlaoders are generally specific to the system it's on and how the drive(s) is / are set up.

https://www.linux.org/threads/linux-bootloaders.8943/

https://www.tecmint.com/best-linux-boot-loaders/

I think even old versions of Scott Mueller's "Upgrading and Repairing Pcs" might be of use to you. Digital versions could be found at archive.org.

fuzzfactor
Nothing beats experimentation when you really need to find out for yourself and documentation is not ideal to begin with.
saidinesh5
Arch wiki is a really good place i learned this stuff from:

https://wiki.archlinux.org/title/Arch_boot_process

P.S I use Arch btw. ;)

iillexial
I use Arch too.
themaninthedark
How do you know if a person uses Linux? >They will tell you.

I use Mint :p

IE6
I use ChromeOS >:)
kfajdsl
2nd this, this is where I learned how computers boot up.
lom
+1, this is also where I learned most of my knowledge
ignoramous
The gist is (which doesn't hold universally true), when the CPU is powered up, it initializes its internal RAM, loads in a pre-boot ROM, executes it. pre-boot ROM's job is to initialize whatever it has to, to bring in the initial bootloader which initializes RAM, finds a suitable bootloader program and loads it in. This program, also called second-stage bootloader, is an Operating System in its own right. It can understand filesystems, explore attached hardware, speak multiple network protocols, initialize devices as needed. The second-stage bootloader (there may also be a third-stage) usually then boots into a Kernel. The Linux Kernel invokes the init process and things proceed into the userspace from there.

At each of those stages, the bootloader images, the kernel image, the device trees, and the disk / filesystem are verified ("measured") for integrity eventually anchored on a "hardware root-of-trust".

If you're a visual learner:

How TI Beagleboard boots (33m): https://www.youtube.com/watch?v=DV5S_ZSdK0s / https://ghostarchive.org/varchive/DV5S_ZSdK0s

How ARM Cortex M boots (9m): https://www.youtube.com/watch?v=3brOzLJmeek / https://ghostarchive.org/varchive/3brOzLJmeek

Bootloader 101 (embedded devices; 38m): https://www.youtube.com/watch?v=UvFG76qM6co / https://ghostarchive.org/varchive/UvFG76qM6co

Measured Boot (39m): https://www.youtube.com/watch?v=EzSkU3Oecuw / https://ghostarchive.org/varchive/EzSkU3Oecuw

Coreboot (38m): https://www.youtube.com/watch?v=iffTJ1vPCSo / https://ghostarchive.org/varchive/iffTJ1vPCSo

U-Boot (1h 25m): https://www.youtube.com/watch?v=INWghYZH3hI

UEFI for U-Boot (38m): https://www.youtube.com/watch?v=VnsF3uRZzNk / https://ghostarchive.org/varchive/VnsF3uRZzNk

Device Trees (43m): https://www.youtube.com/watch?v=Nz6aBffv-Ek / https://ghostarchive.org/varchive/Nz6aBffv-Ek

ARM Trust Zone (46m): https://www.youtube.com/watch?v=q32BEMMxmfw

rramadass
Very Nice; Thank You for all the links !

PS: Your profile which seems to be a cheat-sheet of various HN handles categorized into their areas of expertise is very useful too :-)

tyingq
It might be easier to study something other than an x86 PC, at least to start with. There's so much legacy in x86 that's distracting.

This post[1] has an animated image that's pretty helpful: https://embeddedinn.xyz/images/posts/rvLinuxQemuBoot/bootAni...

It's of course specific to one platform, but the visualization of building up a structures in memory with the right offsets/order and jumping in is pretty typical.

[1] https://embeddedinn.xyz/articles/tutorial/RISCV-Uncovering-t...

zekica
Here are a couple of resources I think can help you:

- old x86 PCs boot in BIOS mode: https://opensource.com/article/17/2/linux-boot-and-startup

With BIOS, your PC initializes hardware and contains firmware drivers for reading disk drives. BIOS loads the first sector (MBR) from the selected boot drive to a fixed memory location and jumps to it. Everything else is up to the bootloader (BIOS still provides methods for reading disk, interacting with the keyboard/moues and text or (S)VGA video output). GRUB2 is saved to the disk in two stages: Stage 1 is <512bytes and is only used to load stage 2. Stage 2 is commonly saved in the empty space before the first partition. Grub stage 2 then loads it's own drivers for filesystems, searches partitions and kernels+ramdisks... Once you select or manually type the path to a kernel and init ram disk, GRUB loads it into memory and jumps to it (still in 16bit real mode).

- new x86 PCs and some ARM use UEFI: https://hackaday.com/2021/11/30/whats-the-deal-with-uefi/

UEFI works similarly, but is cross-platform (can work on x86, x86_64, itanium, 32bit and 64bit ARM, possibly on RISC-V). UEFI doesn't look for boot drives but for EFI applications (bootloaders) on a special EFI System Partition (uses FAT32 filesystem per spec, but can be any filesystem your UEFI firmware has a driver for). The firmware then loads the configured UEFI application and runs it (it also provides services for input devices, disks, networking, display). GRUB does the same as above.

The only difference is if you are using a distribution that has a signed bootloader (using Microsoft's UEFI CA) probably also check whether the kernel and 3rd party modules are signed using distribution's or your (owner's) signing keys.

- other ARM devices and most MIPS, RISC-V commonly use U-Boot with Device Tree (as without UEFI or ACPI, there has to be a way to inform the kernel of basic non-PNP hardware and how to communicate with it).

Dalewyn
As an aside, GRUB here for general purposes is synonymous with other bootloaders such as NTLDR, Windows Boot Manager, lilo, and so on.
monocasa
> other ARM devices and most MIPS, RISC-V commonly use U-Boot with Device Tree (as without UEFI or ACPI, there has to be a way to inform the kernel of basic non-PNP hardware and how to communicate with it).

Additionally, UEFI on ARM (and probably RISC-V) will commonly give you a device tree too. The two aren't mutually exclusive and modern ARM SoCs more or less require kernel space to have more information than UEFI is capable of conveying.

junon
https://osdev.org has a lot of resources about this.

Your computer and all of its hardware are built on standards. For the most part, they are adhered to by hardware and BIOS manufacturers. GRUB et al are just abstracting those away because they're obtuse and not very ergonomic to work with from day to day.

klodolph
I also recommend the OSDev Wiki. It also includes information you’d need to write your own bootloader, if that’s what you want to do.
rnd0
Isn't a lot of the material there deliberately obscufated and/or wrong but not corrected for the sake of making people figure it out themselves?
junon
No lol, where did you get that idea?
swalsh
Installing Arch is a great way to learn. As you go step by step you'll learn the parts of the OS, and kind kind of grok why they're there (and when you'll inevitably skip a step, you'll learn more). It's also a great system to have total control over your OS. And since you built it yourself you can fix it yourself.
jiveturkey
Plenty of good links here already. I'll just add that booting is enormously complex, and starts well before any of the dozen comments so far. I skimmed many of them (not all) and they all tell pretty much the same story whether on real hardware or virtual.

But modern real hardware first boots a Management Engine (or BMC, or T2, or similar), which prepares things and starts subsystems like hardware controllers, before releasing the CPU where the "OS" finally boots, blissfully unaware that it is running on an abstraction.

Watch https://www.youtube.com/watch?v=36myc8wQhLo from about 10:00 to about 20:00 for a decent super high level overview.

These two are also good for a deeper understanding.

https://i.blackhat.com/USA-19/Thursday/us-19-Davidov-Inside-...

https://i.blackhat.com/USA-19/Thursday/us-19-Krstic-Behind-T...

They both cover UEFI, even though the focus is on T2.

I know that's well beyond what you were asking for, but the boot process goes well beyond GRUB.

jeffbee
So much this. Every part of a modern computer contains unseen, non-architectural processors of various kinds. When the main architectural CPU executes the first instruction, that is the last in a sequence of miracles. The only way to be familiar with the whole process is to build a computer from scratch.
hoherd
Here's a write up I found recently.

> This is a discussion of what happens when a CPU chip starts. It may be thought of as what happens when a whole computer starts, since the CPU is the center of the computer and the place where the action begins.

https://lateblt.tripod.com/bit68.txt

markus_zhang
As a side note, I found the concept of BIOS/UEFI/Firmware virus fascinating. It might be useful to read a few analysis about them. Of course I understand little about the topic as I don't work in low level.
Eyas
Most of the links here help with your immediate questions, but if starting with base concepts and first principles is appealing to you, I have to recommend:

- the MIT Operating Systems Engineering OCW course [^1]

- specifically, Lecture #2 [^2] which describes the bootloader for 'xv6', a reimplementation of Unix v6, which does a great job showing what a solid OS with all the basics look like

[^1]: https://ocw.mit.edu/courses/6-828-operating-system-engineeri...

[^2]: https://ocw.mit.edu/courses/6-828-operating-system-engineeri...

ddoolin
This is cool, although I wish (and maybe I'm missing them) that there were lecture videos or recordings to go along with this. It seems like good material with not a lot of explanation.

E: Sibling comment posted updated course with videos: https://pdos.csail.mit.edu/6.S081/2020/schedule.html

peter_d_sherman
The following is a pretty decent historical page about the pre-(U)EFI MBR (Master Boot Record) boot process:

https://thestarman.pcministry.com/asm/mbr/STDMBR.htm

Note that EFI/UEFI -- occurred much later in time than MBR...

The MBR boot process is also called "Legacy Boot" -- and is emulated on (U)EFI -- although it may not show as an option on some (U)EFI BIOS'es if the option is turned off...

Related: https://en.wikipedia.org/wiki/Master_boot_record

You might also wish to check out some emulators, most notably Bochs (https://bochs.sourceforge.io/) and QEMU (https://www.qemu.org/) because they simulate the boot process, and if you're in their debuggers, you should be able to inspect that process step by step -- but also more generally emulators for other machines/platforms/architectures (https://en.wikipedia.org/wiki/List_of_computer_system_emulat...) because in general, most of those emulators should realistically simulate the given machine/platform/architecture's boot process...

The basic theory of booting is that when a system starts, it contains a little bit of persistent memory (BIOS ROM, EPROM?) that contains a little bit of code, which is just enough code to load the data of the first block/sector of the hard disk (or other persistent storage boot device) to a specific address in memory as code -- and jump to it.

This data on the first block/sector -- is a small bit of machine code -- which although fairly stupid -- knows enough about the system to load the next N blocks/sectors of the hard disk (or other storage device) -- again into memory at a specific address -- and then jump (transfer control) to it.

This pattern may repeat several times, for example, GRUB's first bootsector then loads an intermediate length program (a "chainloader") from the next N contiguous blocks/sectors of the storage device, this chainloader knows more about the hardware and filesystems than the initial boot block did, and then it proceeds to do a yet longer/more complex load of the main Operating System into memory.

During the final load, the main Operating System might be on discontiguous blocks/sectors and those blocks/sectors may be part of a filesystem. But that doesn't have to be the case.

But whatever the case, the final load (or perhaps "bootstrap phase") is usually more complex than reading continuous blocks/sectors into memory and subsequently jumping to its start address in memory -- but not always...

Another way to think about it is that a 512 byte program (the bootsector) is loaded that then loads a 32K (let's say) program (the chainloader on N contiguous blocks/sectors) which then loads the multi-megabyte (or multi-gigabyte!) OS from multiple files from multiple file systems from multiple discontinuous blocks/sectors on the physical device (let's say, for example...)

Simple Program (loads) -> More Complex Program (loads) -> Most Complex Program (OS)...

Anyway, there's your basic theory...

Good luck!

fuzzfactor
I also recommend the Starman for good documentation over the decades.

Basically you're supposed to know BIOS/MBR booting quite well in order to make the best progress on UEFI/GPT.

Originally upon powerup the BIOS would run from ROM and then boot control to a program known as the Master Boot Record which would reside on the first 440 bytes of sector 0 of the HDD. The partition table took up the final bytes of sector 0. The MBR checked which of the 4 possible primary partitions was flagged as active, and then booted control to the Volume Boot Record (Boot Sector) residing at the first sector of that particular partition which would then (usually, but specifically according to BOOT.INI on Windows [BCD today] or GRUB configs for Linux) load the OS contained within that partition. Usually by reading files from the filesystem beyond that point, but capable of being chained directly to other executable sectors.

Starman can be a very good resource on underlying structures:

https://thestarman.pcministry.com/asm/mbr/

He's got lots more pages like this, and references too.

Now, straight to modern UEFI:

The MBR code itself is best not there on sector 0, just an imitation partition table in the final few bytes still exists which is considered "protective" and keeps BIOS PC's from recognizing the HDD since they can not handle partitions layed out by the GPT regime.

Sector 1 designates GPT drive parameters, and sector 2 begins the defining data for each partition, which by default extends to sector 33 so you have room to define many more than 4 partitions, and any of them can be booted to from a single EFI folder on a hidden ESP partition, depending mainly on the config files in the EFI folder. There are backups of these defining sectors (not the EFI folder itself) in the final area of the HDD.

In the ESP partition which is often expected by MB UEFI to carry a specific ESP GUID (but often works just fine after changing to a "regular" GUID so you can unhide it for maintenance), the UEFI expects to find it formatted as FAT32, and there behold a recognizable EFI/BOOT folder containing the elusive BOOTX64.EFI file. That's the only thing normally found in the EFI/BOOT folder except for systems having bootability by the rare remaining 32-bit UEFI firmwares, then you might see BOOTIA32.EFI. Lots of times it will do just fine having an EFI folder on an NTFS partition too.

UEFI 64-bit firmware just runs whatever file is currently named BOOTX64.EFI in the BOOT folder. Or falls back to secondary alternatives if not present.

When you install an OS like Windows it adds an EFI/MICROSOFT folder, but each time you add a different version of Windows to a different partition, you do not add additional Microsoft folders to EFI, instead you add additional boot entries to the default boot menu already present in the Microsoft BCD file there. The OS installation procedure overwrites the existing BOOTX64.EFI file with one directing the boot process to continue from the Microsoft folder after that point, according to the NT6 boot menu you have in place at the time.

Installing Linux creates an EFI/ubuntu folder for example, containing most necessary GRUB elements, while overwriting BOOTX64.EFI to direct the boot process to the ubuntu folder and use the GRUB bootmenu accessible from there. Each distinct distro will add its own folder like EFI/debian/, EFI/fedora, with the most recently added claiming the most coveted BOOTX64.EFI prize.

Ideally, you install all the Windows versions you want into their designated NTFS volumes, which naturally builds up your NT6 bootmenu as you go. You will best do some BCDEDITing as you go just to keep the Descriptions in the bootmenu straight as to which entry goes to which Windows version on which partition.

Ideally again, your final Linux install will be a distro that automatically d...

jaclaz
>The MBR checked which of the 4 possible primary partitions was flagged as active, and then booted control to the Volume Boot Record (Boot Sector) residing at the first sector of that particular partition which would then (usually, but specifically according to BOOT.INI on Windows [BCD today] or GRUB configs for Linux) load the OS contained within that partition. Usually by reading files from the filesystem beyond that point, but capable of being chained directly to other executable sectors.

You forgot the Windows boot manager, on Windows NT the chain is:

Up to XP:

BIOS->MBR->PBR of active partition->NTLDR (+NTDETECT.COM)->BOOT.INI->Choices->OS

Vista and later:

BIOS->MBR->PBR of active partition->BOOTMGR->\boot\BCD->Choices->OS

The MBR only passes control to the PBR and the PBR only loads the Windows boot manager, it is this latter that does all the actual OS loading and that reads BOOT.INI and \boot\BCD settings and user choices.

fuzzfactor
Good to see your message jaclaz.

You're another one like Starman who can fill in details like no-one else, in case people are not aware. Please kindly post a link to the message board where your most valuable information still can be found!

What I'm seeing now is when Windows 8+ is installed to an MBR partition, and boots normally from a plain NT6 BOOT folder using BOOT\BCD in legacy CSM mode no differently than Vista (whether the boot folder is on a separate hidden volume or the same partition as Windows itself), the same Windows files on that partition can also boot using UEFI if available, from an alternative EFI\BOOT folder (plus accompanying EFI\Microsoft\BOOT\BCD) on the same or similar media.

In the first case with BIOS it ends up running winload.exe, but under UEFI the firmware runs winload.efi instead, since both the "DOS" executable and the EFI executable are both present in the Windows\System32 folder, you have your choice here too.

jaclaz
Thanks for the comparison, though of course the Starman's site is a much better source than my scattered posts, mainly on:

https://msfn.org/board/

and:

http://reboot.pro/

(on this latter under the nick of Wonko the Sane)

About your Windows 8+ report, yes, what you describe is perfectly normal, what many people tend to forget is that UEFI does not necessarily means GPT, a UEFI can access "MBR style disks" just fine (the opposite, BIOS acccessing a GPT disk needs special provisions, so-called hybrid MBR's and "special" code in them).

You evidenced however yet another aspect of more recent NT Windows booting, until XP NTLDR was both the boot manager and the OS loader, now BOOTMGR (and bootmgr.efi) is just the boot manager and it chainloads a separate OS loader, the WINLOAD.EXE (or winload.efi).

westurner
Booting process of Linux: https://en.wikipedia.org/wiki/Booting_process_of_Linux

Booting process of Windows NT since Vista: https://en.wikipedia.org/wiki/Booting_process_of_Windows_NT_...

UEFI > Secure Booting, Boot Stages: https://en.wikipedia.org/wiki/UEFI#Boot_stages

The EFI system partition is conventionally /boot/efi on a Linux system; and there's a signed "shim loader" that GRUB launches, which JMP- launches the kernel+initrd after loading the initrd into RAM (a "RAM drive") and mounting it as the initial root filesystem /, which is pivot_root'd away from after the copy of /sbin/init (systemd) mounts the actual root fs and launches all the services according to the Systemd unit files in order according to a topological sort given their dependency edges: https://en.wikipedia.org/wiki/EFI_system_partition

Runlevels: https://en.wikipedia.org/wiki/Runlevel

runlevel 5 is runlevel 3 (multi-user with networking) + GUI. On a gnome system, GDM is the GUI process that is launched. GDM launches the user's Gnome session upon successful login. `systemctl restart gdm` restarts the GDM Gnome Display Manager "greeter" login screen, which runs basically runs ~startx after `bash --login`. Systemd maps the numbered runlevels to groups of unit files to launch:

  telinit 6 # reboot
  telinit 3 # kill -15 GDM and all logged in *GUI* sessions
You can pass a runlevel number as a kernel parameter by editing the GRUB menu item by pressing 'e' if there's not a GRUB password set; just the number '3' will cause the machine to skip starting the login greeter (which may be what's necessary to troubleshoot GPU issues). The word 'rescue' as a kernel parameter launches single-user mode, and may be what is necessary to rescue a system failing to boot. You may be able to `telinit 5` from the rescue runlevel, or it may be best to reboot.
fuzzfactor
>The EFI system partition is conventionally /boot/efi on a Linux system;

Still often mounted as /boot/efi but physically residing on the root of the hidden ESP volume as EFI/boot & EFI/ubuntu, for distros like ubuntu.

So when mounted you have something like /boot/efi/boot/bootx64.efi and boot/efi/ubuntu/grub etc. if visible and accessible.