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!
[+] [-] Eyas|3 years ago|reply
- 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...
[+] [-] rustypotato|3 years ago|reply
[^1]: https://pdos.csail.mit.edu/6.S081/2020/schedule.html
[+] [-] ddoolin|3 years ago|reply
E: Sibling comment posted updated course with videos: https://pdos.csail.mit.edu/6.S081/2020/schedule.html
[+] [-] kersplody|3 years ago|reply
[+] [-] zekica|3 years ago|reply
- 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).
[+] [-] microtonal|3 years ago|reply
https://github.com/AsahiLinux/docs/wiki/Introduction-to-Appl...
https://github.com/AsahiLinux/docs/wiki/SW%3ABoot
https://support.apple.com/guide/security/boot-process-secac7...
[+] [-] monocasa|3 years ago|reply
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
[+] [-] junon|3 years ago|reply
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
[+] [-] jiveturkey|3 years ago|reply
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
[+] [-] saidinesh5|3 years ago|reply
https://wiki.archlinux.org/title/Arch_boot_process
P.S I use Arch btw. ;)
[+] [-] iillexial|3 years ago|reply
[+] [-] kfajdsl|3 years ago|reply
[+] [-] lom|3 years ago|reply
[+] [-] cpach|3 years ago|reply
https://docs.freebsd.org/en/books/handbook/boot/
https://man.openbsd.org/boot.8
https://man.netbsd.org/boot.8
[+] [-] vsupalov|3 years ago|reply
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
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?
[+] [-] freakcage|3 years ago|reply
[+] [-] squegles|3 years ago|reply
[+] [-] bpfrh|3 years ago|reply
It explains the boot process from the cpu initialization to a the end of the linux kernel initialization.
[+] [-] vishnugupta|3 years ago|reply
And since no one's mentioned let me say that TLDP is a comprehensive, understandable, and the authoritative source on all things Linux.
That said, here's two documents from TLDP.
1. [Boot process, Init and shutdown] https://tldp.org/LDP/intro-linux/html/sect_04_02.html
2. [The boot process in closer look] https://tldp.org/LDP/sag/html/boot-process.html
[+] [-] photochemsyn|3 years ago|reply
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
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
[+] [-] easterncalculus|3 years ago|reply
[+] [-] soheil|3 years ago|reply
[+] [-] gjsman-1000|3 years ago|reply
[+] [-] hayst4ck|3 years ago|reply
https://github.com/nu11secur1ty/All-Stages-of-Linux-Booting-...
https://github.com/0xAX/linux-insides/blob/master/Booting/li...
[+] [-] mardiyah|3 years ago|reply
Dig in on each of their home/official site e.g: https://www.gnu.org/software/grub/manual/grub/grub.pdf
most say Gentoo or Funtoo (its improvement) excel in docs. among them
[+] [-] mackid|3 years ago|reply
https://depletionmode.com/uefi-boot.html
[+] [-] viraptor|3 years ago|reply
You'll learn everything you wanted about booting and much more.
[+] [-] westurner|3 years ago|reply
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:
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
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.
[+] [-] joebergeron|3 years ago|reply
[0]: https://www.joe-bergeron.com/posts/Writing%20a%20Tiny%20x86%...
[1]: https://github.com/Jophish/tiny-bootstrap
[+] [-] hoherd|3 years ago|reply
> 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