The Linux Boot Process: From Power Button to Kernel • Hacker News Board

Re: The Linux Boot Process: From Power Button to Kernel

#71

Post by tremon » Sun, Oct 26, 2025, 1:53 PM UTC

zaxioms wrote: post #41

Does anyone have a similar article with more detail? I don't quite want to read the datasheet of your favorite microprocessor, but I would like a decent amount more detail than what's provided. Especially before UEFI/BIOS.

At a very high level, the processor initialization procedure is similar to most microcontrollers:

- processor is powered up with RESET pin asserted, making sure that all circuits are in a known-safe state.

- when RESET is deasserted, all autonomous circuits (e.g. core control units, cache controllers, ALUs) go through a hardware setup phase.

- the processor accesses the boot firmware according to the platform design. There's many options here, but the three most common are 1) the boot ROM is permanently mapped to a dedicated hardware address, and the processor uses its memory controller to access that memory; 2) the boot ROM is directly connected to the processor via dedicated I/O pins; 3) the initial boot code is located on the processor itself (factory-programmed EEPROM).

- if the boot ROM is not mapped to a memory address, the data is loaded into CPU cache (external RAM needs to be initialized first, and that task is usually performed by the firmware).

- the primary cpu core starts executing boot code (UEFI/BIOS/etc) from said predefined hardware address. Other cores (and processors) are usually left uninitialized throughout the startup process, and it is left to the operating system to bring up the remaining parts of the system.

Specifically for Intel, see https://binarydebt.wordpress.com/2018/10/06/how-does-an-x86-... . Or see https://electronics.stackexchange.com/a/726918 and its comments to get an idea of the differences between platforms.

Re: The Linux Boot Process: From Power Button to Kernel

#72

Post by Imustaskforhelp » Sun, Oct 26, 2025, 2:14 PM UTC

deivid wrote: post #54

Really nice post, some months ago I also wrote about linux boot, but a bit more focused on the IO side (what's on disk, how is it loaded), here: https://blog.davidv.dev/posts/booting-x86-64/

Oh wow! Combined with the explaination of iso files which can be a single file which can have things like fat and bzimage and rootfs etc. with the bootloader and combined with software like dd / gnome-disks and your article and the HN thread article, this finally makes me understand how Linux starts and how we can install things from https / internet and use software to fundamentally change the operating system

Its magic.

I was recently trying to build my own linux operating system and I felt so frustrated as to how to build an iso image from bzImage / linux kernel + initramfs but I was able to withstand its pain somehow and it took me a week to actually learn a lot more about the fundamentals of linux which are so fascinating.

Now, I was trying to do some mix and matching (imagine tinycorelinux initramfs and buildroot bzImage and merging them) and doing some other shenanigans.

Sometimes my computer kernel didn't work or the userspace didn't work in the vm and I guess now WHEN I AM WRITING THIS POST, I realized that it was because of the difference in 32 bit and 64 bit, I think I had 64 bit kernel and 32 bit userspace which had some issues

There were some different things as well, which had caused some issues which made me want to scratch my remaining hair but it was so worth it (maybe i used some llm assistance in the end as well), its all just makes sense now, I always wanted to learn how computers work from scratch, now I feel like I have a very basic idea on how things work and they are complex indeed :sob:

I was looking for a post like yours yesterday and so I am still glad I found it when the topic is still fresh.

I faced so many issues trying to build my own iso but I don't know if it was my skill issue which streched it to a week. But the whole process of building your own iso seems less daunting to me now knowing what it really is

I may have skill issues indeed but I fixed those, I feel like that there is a lot to learn from those errors that I missed but maybe that's also because they got too overwhelming. But I now know a path which works and some explainations of why they work. I feel more confident in my ability to make my own custom distro even, but my appreciation for linux grows so much.

Its just such a massive rabbit hole and most of linux is literally just "it just works", linux is amazing.

Re: The Linux Boot Process: From Power Button to Kernel

#73

Post by QuiEgo » Sun, Oct 26, 2025, 2:27 PM UTC

tonetegeatinst wrote: post #69

1oooqooq wrote: post #64

Earlier quoted context omitted.

firmwares are the real IoT nobody talks about that that actually happened. infinite little computers and code churning away from view. and not being updated. next 'snowden leaks' will have that word on every page.

Worse is how little information exists on firmware or how development for firmware works. Its certainly not something regularly taught in higher education.

If you're curious go walk through the bootloaders of an embedded platform, they serve roughly the same role as firmware that implements UEFI on traditional x86 systems.

Example, start with bl1 (first stage boot loader) for a Rasberry Pi here:

https://github.com/raspberrypi/arm-trusted-firmware

The Pi's hardware (register map, etc) is well documented so it's a good way to learn this stuff.

Re: The Linux Boot Process: From Power Button to Kernel

#74

Post by messe » Sun, Oct 26, 2025, 2:29 PM UTC

gldrk wrote: post #45

As should be clear from the reset vector, the 80286 and its successors actually boot in unreal mode . On the 80386, the base address of the code segment is 0xffff0000, which cannot be obtained by shifting the 16-bit CS register by 4. The descriptor cache simply gets loaded with the correct value at reset. Writing to CS in real mode overwrites the cached value with CS * 16.

This isn't quite right either. That's not what unreal mode is. Unreal mode has 32-bit data segments limit, not code segment limits.

In this case the code segment still has a 16 bit limit, it's just that its base address in the descriptor cache is outside the bounds typically associated with real mode.

Re: The Linux Boot Process: From Power Button to Kernel

#75

Post by ra1231963 » Sun, Oct 26, 2025, 2:33 PM UTC

Based on all the negative comments, and being a non-expert, I had an LLM generate an article for that same title. I suspect it was more approachable and more technically accurate than this. In fact I asked it to compare its article with this one and the negative comments.

The author of any technical blog post should be using an LLM to vet things before posting to find gaps or inconsistencies.

Re: The Linux Boot Process: From Power Button to Kernel

#76

Post by 3abiton » Sun, Oct 26, 2025, 3:35 PM UTC

deivid wrote: post #54

Really nice post, some months ago I also wrote about linux boot, but a bit more focused on the IO side (what's on disk, how is it loaded), here: https://blog.davidv.dev/posts/booting-x86-64/

I am curious were the differntiation comes between linux, and other unix systems (bsd, etc ..).

Re: The Linux Boot Process: From Power Button to Kernel

#77

Post by zvmaz » Sun, Oct 26, 2025, 4:34 PM UTC

deivid wrote: post #54

Really nice post, some months ago I also wrote about linux boot, but a bit more focused on the IO side (what's on disk, how is it loaded), here: https://blog.davidv.dev/posts/booting-x86-64/

Thanks! Nice to see it has plenty of diagrams.

Re: The Linux Boot Process: From Power Button to Kernel

#78

Post by Melonai » Sun, Oct 26, 2025, 4:59 PM UTC

0xkato wrote: post #12

zahlman wrote: post #9

In the page source: uwu OwO what's this?

Its a working progress.

Hey us mobile readers want the Femboy Mode Button, too! :(

Re: The Linux Boot Process: From Power Button to Kernel

#79

Post by mmh0000 » Sun, Oct 26, 2025, 5:09 PM UTC

7bit wrote: post #60

nickelpro wrote: post #16

UEFI is an interface implemented by firmware (literally, Unified Extensible Firmware Interface), it's not the firmware itself. Saying "it starts the machine" is a bit of a nomenclature faux pas. The firmware starts the machine, you talk to the firmware via UEFI. This post skips all the interesting things in the modern firmware dance. Not the least of which is when you call ExitBootServices() you're already in long mo…

I'm currently trying to learn more about how the boot process works, specifically with UEFI. Yesterday I watched a video on how to program a UEFI bootloader so I was happy when I saw this article this morning. The article jumps over so many steps and leaves out so many mechanics that I had to stop reading, because it just opened more and more questions without closing any. For example, right at the beginning: > Right…

Would love to see the video you're referencing. Mind providing a link?

Re: The Linux Boot Process: From Power Button to Kernel

#80

Post by jdsnape » Sun, Oct 26, 2025, 5:35 PM UTC

tonetegeatinst wrote: post #69

1oooqooq wrote: post #64

Earlier quoted context omitted.

firmwares are the real IoT nobody talks about that that actually happened. infinite little computers and code churning away from view. and not being updated. next 'snowden leaks' will have that word on every page.

Worse is how little information exists on firmware or how development for firmware works. Its certainly not something regularly taught in higher education.

Maybe not on compsci? but when I did electronic engineering it was covered as part of our embedded systems course.

There’s quite a lot of info out there on UEFI, and tiano core is open source. I taught myself enough to implement a small game you had to solve to be able to boot your machine, for example :)