top | item 35229045

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

457 points| mog_dev | 3 years ago

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!

94 comments

order
[+] Eyas|3 years ago|reply
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|3 years ago|reply
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

[+] zekica|3 years ago|reply
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).

[+] monocasa|3 years ago|reply
> 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.

[+] Dalewyn|3 years ago|reply
As an aside, GRUB here for general purposes is synonymous with other bootloaders such as NTLDR, Windows Boot Manager, lilo, and so on.
[+] junon|3 years ago|reply
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|3 years ago|reply
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.
[+] jiveturkey|3 years ago|reply
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|3 years ago|reply
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.
[+] vsupalov|3 years ago|reply
I wondered about an adjacent topic recently ("what IS the kernel actually") and found out that a great way to understand it, would be to start with the boot process. Once I felt less lost, I tried to capture my learnings [1]

The text is not edited yet, but as I had the benefit of learning about it with fresh eyes, it should be very approachable (and hopefully accurate enough)

[1] https://vsupalov.com/demystifying-kernel/

[+] MuffinFlavored|3 years ago|reply
> It’s firmware time. Your machine has a motherboard, there is a chip on it which has had BIOS (Basic Input/Output System) flashed on it.

I wonder if it's worth it to call out the "processor microcode" firmware? Any cool startup things happen at that low level as well?

[+] photochemsyn|3 years ago|reply
This one looks pretty good, for all the terms you list. It's refreshingly free of opinionating and just covers the technicalities and the history in a straightforward manner, and has links to good wiki overviews of EFI etc, compares the BIOS vs UEFI boot processes, and so on:

https://en.wikipedia.org/wiki/GNU_GRUB

Incidentally I discovered you can learn a fair amount about the boot process by making bad edits to your /etc/fstab file on a Linux system :) e.g.

https://unix.stackexchange.com/questions/107828/how-is-etc-f...

Also this central page for different bootloaders for a variety of systems, is kind of interesting, there's many different approaches.

https://en.wikipedia.org/wiki/Comparison_of_bootloaders

[+] bewuethr|3 years ago|reply
Didn't see these two mentioned yet:

UNIX and Linux System Administration Handbook, 5th Edition, Chapter 2: Booting and System Management Daemons

"Code" by Charles Petzold, 2nd Edition, Chapter Twenty-Six: The Operating System

The first one is totally fine to read stand-alone. "Code" makes more sense to read cover to cover, though the chapter on its own isn't totally useless.

[+] joemi|3 years ago|reply
"Code" was such a great read even though I already knew a lot of what's in it. I highly recommend it.
[+] easterncalculus|3 years ago|reply
I honestly had a very good exchange about this exact topic with ChatGPT not too long ago. It was able to draw connections between the different stages that blog posts/wikis about each often do not. Specifically I was asking about the Linux boot process and it was able to go into enough detail for me to Google for the rest. Hope that helps.
[+] soheil|3 years ago|reply
I'd be very interested to know what Ask HN posts will actually be answered by HN better than by ChatGPT. Maybe those will be things that we excel at.
[+] gjsman-1000|3 years ago|reply
Also, heads up: GPT-4 is night and day smarter than regular ChatGPT and totally worth the subscription price if using it for general research.
[+] westurner|3 years ago|reply
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|3 years ago|reply
>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.

[+] hoherd|3 years ago|reply
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