{"id":21159,"date":"2025-10-27T20:32:50","date_gmt":"2025-10-27T20:32:50","guid":{"rendered":"https:\/\/pokecon.jp\/job\/?p=21159"},"modified":"2025-10-27T20:32:50","modified_gmt":"2025-10-27T20:32:50","slug":"the-linux-boot-process-from-power-button-to-kernel","status":"publish","type":"post","link":"https:\/\/pokecon.jp\/job\/21159\/","title":{"rendered":"The Linux Boot Process: From Power Button to Kernel"},"content":{"rendered":"\n<\/p>\n<div>\n<nav class=\"nav\">\n<\/nav>\n<p><span class=\"date\"><br \/>\n    <time datetime=\"25-10-2025\">Saturday. October 25, 2025<\/time><br \/>\n     &#8211; <span class=\"reading-time\" title=\"Estimated read time\"><\/p>\n<p>        15 mins<\/p>\n<p><\/span><\/p>\n<p><\/span><\/p>\n<h2 id=\"part-1--from-power-button-to-the-kernels-first-breath\">Part 1 \u2014 From power button to the kernel\u2019s first breath<\/h2>\n<p>You press the power button. A second later a wall of text scrolls by, or a logo fades in, and eventually Linux appears. What happens in between is not magic. It is a careful handshake between tiny programs and a very literal CPU. This part follows that handshake until the very first line of C code inside the Linux kernel runs.<\/p>\n<h3 id=\"the-very-first-instruction\">The very first instruction<\/h3>\n<p>When power stabilizes, the CPU resets itself to a tiny, old\u2011fashioned mode called real mode. Real mode dates back to the original 8086 chip. The rules are simple on purpose. Memory addresses are built from two values the CPU keeps in special fast storage called registers. You combine a segment and an offset like this:<\/p>\n<p><code class=\"language-plaintext highlighter-rouge\">physical_address = (segment <\/code><\/p>\n<p>If you see numbers like <code class=\"language-plaintext highlighter-rouge\">0xFFFFFFF0<\/code>, that is hexadecimal. Hex is base 16. We write <code class=\"language-plaintext highlighter-rouge\">0x<\/code> in front to make that clear. <code class=\"language-plaintext highlighter-rouge\">0x10<\/code> is 16 in everyday counting. <code class=\"language-plaintext highlighter-rouge\">0x100000<\/code> is 1 megabyte. Hex lines up nicely with how hardware stores bits, which is why you see it everywhere in low\u2011level code.<\/p>\n<p>Right after reset the CPU jumps to a special address called the reset vector at <code class=\"language-plaintext highlighter-rouge\">0xFFFFFFF0<\/code>. Think of it as a permanent bookmark that says \u201cstart here.\u201d There is room for almost nothing at that address, so manufacturers put a short jump there that passes control to the firmware on your motherboard.<\/p>\n<p><strong>Tiny explainer: register<\/strong><br \/>\nA register is a tiny slot inside the CPU. It holds a number the CPU is using right now. Names like CS and IP are register names. CS means \u201ccode segment,\u201d which marks the current neighborhood for instructions. IP means \u201cinstruction pointer,\u201d which marks which instruction comes next.<\/p>\n<h3 id=\"bios-and-uefi\">BIOS and UEFI<\/h3>\n<p>The firmware is a small starter program baked into your board.<\/p>\n<p>BIOS stands for Basic Input Output System. It is the older style. BIOS does a quick health check called POST, looks at the boot order, and tries each device. If it finds a disk whose very first 512\u2011byte sector ends with the marker bytes <code class=\"language-plaintext highlighter-rouge\">0x55<\/code> and <code class=\"language-plaintext highlighter-rouge\">0xAA<\/code>, it treats that device as bootable. BIOS copies that sector to memory at <code class=\"language-plaintext highlighter-rouge\">0x7C00<\/code> and jumps there. That sector is tiny, so it usually knows only how to load the next, larger piece.<\/p>\n<p>UEFI is the modern replacement. It still starts the machine, but it understands filesystems directly and can load bigger boot programs without the old \u201cfirst sector\u201d dance. UEFI also passes richer information to the operating system. Different path, same goal: hand control to a boot program that can load Linux.<\/p>\n<h3 id=\"meet-the-bootloader\">Meet the bootloader<\/h3>\n<p>The bootloader is the usher that gets the operating system into place. GRUB is a popular choice on PCs. It reads its configuration, shows a menu if you installed one, and loads the Linux kernel into memory. The Linux kernel file actually contains two things:<\/p>\n<ul>\n<li>a small setup program that still runs in real mode<\/li>\n<li>the larger compressed kernel that will be unpacked a little later<\/li>\n<\/ul>\n<p>GRUB also fills out a small structure called the setup header with useful facts: where it placed the kernel, where the command line lives, where the initrd is if you have one. Then it jumps into the setup program.<\/p>\n<h3 id=\"the-setup-program-makes-a-safe-room\">The setup program makes a safe room<\/h3>\n<p>Before Linux can do anything interesting, the setup code creates a predictable workspace.<\/p>\n<p>It lines up the segment registers so memory copies behave the same way every time. Names you\u2019ll see here are CS for code, DS for data, and SS for stack. It also clears a single CPU bit called the \u201cdirection flag\u201d so copy instructions move forward through memory.<\/p>\n<p>It creates a stack. The stack is a last\u2011in, first\u2011out workbench where functions store temporary values. SS says which segment the stack uses. SP is the pointer to the current top of the stack.<\/p>\n<p>It clears a region called BSS. BSS is where global variables that must start as zero live. C code assumes BSS is zero. The setup program writes zeros over that entire span to keep that promise.<\/p>\n<p>If you passed <code class=\"language-plaintext highlighter-rouge\">earlyprintk<\/code> on the kernel command line, the setup code also programs the serial port so it can print very early messages. This is useful when graphics are not ready yet.<\/p>\n<p>Finally the setup program asks the firmware \u201chow much usable RAM do we really have and where are the holes.\u201d On old BIOS this is a call people often nickname e820, which returns a simple list of usable and reserved ranges. The kernel will use that list to avoid stepping on the firmware\u2019s toes.<\/p>\n<p>With that done, the setup code calls its first C function, which is literally named <code class=\"language-plaintext highlighter-rouge\">main<\/code>. We are still in the small old real mode at this point. The next job is to leave it.<\/p>\n<p><strong>Tiny explainer: interrupt<\/strong><br \/>\nAn interrupt is a hardware or software \u201cexcuse me\u201d that pauses what the CPU is doing and runs a small handler for something urgent. A timer tick is an interrupt. A key press is an interrupt. There are two flavors here. Maskable interrupts follow your rules and can be temporarily blocked so they do not fire during delicate moments. Non\u2011maskable interrupts, often called NMI, always cut in because they usually report serious hardware issues. We will control both while switching modes so nothing surprises us halfway through.<\/p>\n<h2 id=\"part-2--leaving-real-mode-stepping-through-32bit-land-and-arriving-in-64bit\">Part 2 \u2014 Leaving real mode, stepping through 32\u2011bit land, and arriving in 64\u2011bit<\/h2>\n<p>Modern Linux on PCs runs in long mode, which is the 64\u2011bit mode of x86_64. You cannot jump there directly from real mode. The path is real mode to protected mode and then protected mode to long mode. This part covers that path and explains the vocabulary on the way.<\/p>\n<h3 id=\"protected-mode-without-the-jargon-haze\">Protected mode, without the jargon haze<\/h3>\n<p>Protected mode is the 32\u2011bit world introduced to get past the limits of the 1980s. It adds two central ideas.<\/p>\n<p>The Global Descriptor Table, or GDT, is a short list of segment descriptions. A description says \u201cthis segment starts here, covers this much, and is allowed to do these things.\u201d Linux keeps this simple. It uses a flat model, which means the base is zero and the size covers the whole 32\u2011bit space. When everything is flat, addresses look like plain numbers again.<\/p>\n<p>The Interrupt Descriptor Table, or IDT, is a directory of \u201cphone numbers\u201d for emergency calls. If an interrupt arrives, the CPU looks up the entry in the IDT and jumps to the handler listed there. During the switch we load a tiny placeholder IDT because we are about to block interrupts anyway. The full\u2011featured IDT arrives later once the real kernel is in charge.<\/p>\n<h3 id=\"the-careful-switch\">The careful switch<\/h3>\n<p>The setup code turns off the noisy parts first. It disables maskable interrupts with a single instruction. It quiets the old PIC chips so hardware interrupts are fully blocked for a moment. It opens the A20 line. This is a historical quirk. Early PCs made addresses wrap at 1 megabyte. Opening A20 removes that wrap so higher addresses work like you expect. It resets the math coprocessor so the floating point state is clean.<\/p>\n<p>Then it loads a tiny GDT with only what we need right now and a tiny IDT. Finally it sets a single bit named PE in a control register named CR0 and performs a far jump. That jump reloads the code segment from the GDT and locks in protected mode. It reloads the data and stack segments and fixes the stack pointer to match the new flat world.<\/p>\n<p>We are now in 32\u2011bit protected mode.<\/p>\n<p><strong>Tiny explainer: control registers<\/strong><br \/>\nThe CPU has a few special registers for on off switches. CR0 turns on protected mode. CR3 holds the address of the top of the page tables, which we will need in a second. CR4 enables a set of extended features such as larger page table entries.<\/p>\n<h3 id=\"why-we-still-are-not-done\">Why we still are not done<\/h3>\n<p>Linux wants 64\u2011bit. That is long mode. Two things are needed.<\/p>\n<p>Paging must be on. Paging is the translator between virtual addresses and physical addresses. Programs use virtual addresses. The hardware reads and writes physical memory. Page tables map one to the other in fixed\u2011size chunks called pages. On PCs a normal page is 4 kilobytes. There are also bigger pages. Early in boot the kernel uses 2 megabyte pages to describe low memory quickly.<\/p>\n<p>A single bit named LME in a special register called EFER must be set to allow long mode. EFER is a model specific register, which is a fancy way of saying \u201ca register used for certain CPU features.\u201d<\/p>\n<h3 id=\"building-just-enough-paging\">Building just enough paging<\/h3>\n<p>The 32\u2011bit prologue builds a small set of page tables that say \u201cfor this region, virtual equals physical.\u201d That is called an identity map. It is enough to flip paging on safely.<\/p>\n<p>To make this work the code enables PAE in CR4 so larger entries are used. It builds a minimal set of tables that cover low memory in 2 megabyte chunks. It writes the address of the top table into CR3. Paging is now ready.<\/p>\n<p>Finally it sets LME in EFER and performs a far return into a label that is written as 64\u2011bit code. Long mode is now active. Segments are still \u201cflat,\u201d but addresses and registers are 64\u2011bit wide.<\/p>\n<p><strong>Why all the extra care<\/strong><br \/>\nSwitching modes while a live system runs is like changing a car tire while rolling. The code blocks interruptions, prepares the minimum needed tables, flips the bit, and only then invites interrupts back. Slow and steady prevents weird half\u2011switched states.<\/p>\n<h2 id=\"part-3--unpacking-the-real-kernel-fixing-addresses-and-why-linux-sometimes-moves-itself\">Part 3 \u2014 Unpacking the real kernel, fixing addresses, and why Linux sometimes moves itself<\/h2>\n<p>We have a 64\u2011bit CPU with paging on and a compressed kernel in memory. Now the small 64\u2011bit stub does the practical work: get out of the way if needed, unpack the kernel, fix addresses if the kernel is not at its default spot, and jump.<\/p>\n<h3 id=\"clearing-a-path-and-setting-safety-nets\">Clearing a path and setting safety nets<\/h3>\n<p>The stub first figures out where it is actually running. Early code is linked as if it lived at address zero and then computes its real base at runtime. If the planned destination for the decompressed kernel would overlap the stub, it copies itself to a safe place.<\/p>\n<p>It clears its own BSS so global state starts clean.<\/p>\n<p>It loads a minimal IDT with two handlers. One for page fault and one for NMI. A page fault happens when the CPU cannot find a mapping for a virtual address it just tried to use. In our early identity\u2011mapped world, the tiny page fault handler can add the missing mapping on the fly and continue. The NMI handler is there so a non\u2011maskable interrupt does not crash the machine while we are still bringing things up.<\/p>\n<p>It also builds identity mappings for the regions it will touch next. That includes the future home of the kernel, the small boot parameters page the bootloader filled in, and the command line buffer.<\/p>\n<h3 id=\"decompressing-linux\">Decompressing Linux\u2026<\/h3>\n<p>A C function commonly named <code class=\"language-plaintext highlighter-rouge\">extract_kernel<\/code> takes over. It sets aside a tiny heap for temporary buffers, prints the classic line, and unpacks the kernel using whatever algorithm the kernel was built with. gzip, xz, zstd, lzo, and others all plug into the same wrapper.<\/p>\n<p>When the bytes are out, the decompressor reads the kernel\u2019s ELF headers. ELF, short for Executable and Linkable Format, is both a file format and a map. It says which chunks are code, which are data, and exactly where each chunk wants to live. The decompressor copies each chunk where it belongs.<\/p>\n<p>If the kernel is being loaded at a different address than it was built for, the decompressor applies relocations. A relocation is a small fix\u2011up that adjusts a pointer or an instruction that contains an address. The decompressor walks a list of these and patches each place so it points to the right spot in the address space we are actually using.<\/p>\n<p>When everything is in place, the decompressor returns the entry point of the real kernel and jumps there, passing a pointer to the boot parameters. From that moment you are in the full kernel. The first function you meet is <code class=\"language-plaintext highlighter-rouge\">start_kernel<\/code>, and the big initialization begins.<\/p>\n<h3 id=\"why-the-kernel-sometimes-moves-itself-on-purpose\">Why the kernel sometimes moves itself on purpose<\/h3>\n<p>You may see kASLR mentioned in kernel logs. That stands for Kernel Address Space Layout Randomization. The idea is simple. If attackers do not know where the kernel lives in memory, certain attacks get a lot harder.<\/p>\n<p>Early in boot, if kASLR is enabled, the decompressor chooses two \u201cbases\u201d at random:<\/p>\n<ul>\n<li>a physical base, which is where the bytes will live in RAM<\/li>\n<li>a virtual base, the starting virtual address the kernel will use once full paging is set up<\/li>\n<\/ul>\n<p>How does it choose without breaking anything<\/p>\n<p>It builds a do not touch list. That includes the decompressor itself, the compressed image, the initial ramdisk, the boot parameters page, and the command line buffer. It can also include ranges you reserve with a <code class=\"language-plaintext highlighter-rouge\">memmap=<\/code> option on the command line.<\/p>\n<p>It scans the memory map from firmware to find large free regions. For each free region it counts how many aligned \u201cslots\u201d of the right size would fit. It draws a random number using the best early entropy source it has. On modern CPUs that might be a hardware random instruction. It reduces the number to the total number of slots and picks the matching slot. That becomes the physical base. The virtual base is chosen the same way, but within the kernel\u2019s virtual address window.<\/p>\n<p>If nothing suitable exists, the code falls back to the default addresses and prints a small warning. If you pass <code class=\"language-plaintext highlighter-rouge\">nokaslr<\/code> on the command line, the randomization step is skipped by design.<\/p>\n<hr\/>\n<h2 id=\"a-quick-glossary-you-can-bookmark\">A quick glossary you can bookmark<\/h2>\n<p><strong>Hexadecimal.<\/strong> Base 16 numbers written with <code class=\"language-plaintext highlighter-rouge\">0x<\/code>. <code class=\"language-plaintext highlighter-rouge\">0x10<\/code> is 16. <code class=\"language-plaintext highlighter-rouge\">0x100000<\/code> is 1 megabyte. Hex maps cleanly to bits, which is why low\u2011level code uses it.<\/p>\n<p><strong>Register.<\/strong> A tiny slot inside the CPU that holds a number right now. Examples: CS, DS, SS, IP, SP.<\/p>\n<p><strong>Segment and offset.<\/strong> The two pieces used to build real\u2011mode addresses. Physical address equals segment times 16 plus offset.<\/p>\n<p><strong>BIOS.<\/strong> Older firmware that starts the machine, checks hardware, and loads the first boot sector into memory.<\/p>\n<p><strong>UEFI.<\/strong> Modern firmware that understands filesystems and loads larger boot programs directly.<\/p>\n<p><strong>Bootloader.<\/strong> The usher that places the kernel in memory and passes facts about the system to it. GRUB is a common one.<\/p>\n<p><strong>Stack.<\/strong> A last\u2011in, first\u2011out workbench for functions. SS selects its segment. SP points at the current top.<\/p>\n<p><strong>BSS.<\/strong> A region where global variables that must start as zero live. The kernel setup code clears it before C runs.<\/p>\n<p><strong>Interrupt.<\/strong> A fast \u201cexcuse me\u201d from hardware or software. The CPU pauses, runs a small handler, then resumes. Maskable interrupts can be blocked for a moment. NMI cannot.<\/p>\n<p><strong>GDT.<\/strong> Global Descriptor Table. Short list of segment descriptors. Linux sets it to a simple flat model.<\/p>\n<p><strong>IDT.<\/strong> Interrupt Descriptor Table. Directory of interrupt handlers. Early boot uses a minimal one. The full kernel installs the real one later.<\/p>\n<p><strong>A20 line.<\/strong> Historical switch that must be opened to address above 1 megabyte correctly on old PCs.<\/p>\n<p><strong>Protected mode.<\/strong> 32\u2011bit mode that introduces the GDT and IDT and allows paging.<\/p>\n<p><strong>Long mode.<\/strong> 64\u2011bit mode on x86_64. Requires paging and a bit named LME set in the EFER register.<\/p>\n<p><strong>Paging.<\/strong> The translator from virtual addresses to physical memory. Implemented with page tables.<\/p>\n<p><strong>Page tables.<\/strong> The data structure that maps virtual pages to physical pages. Early boot uses identity maps. Normal pages are 4 KB. Early boot often uses 2 MB pages to cover ground quickly.<\/p>\n<p><strong>CR0, CR3, CR4.<\/strong> Control registers. CR0 turns on protected mode. CR3 points to the top of the page tables. CR4 enables extended features such as PAE.<\/p>\n<p><strong>EFER.<\/strong> A model\u2011specific register that holds Long Mode Enable among other bits.<\/p>\n<p><strong>ELF.<\/strong> The kernel\u2019s on\u2011disk format with a built\u2011in map of what belongs where.<\/p>\n<p><strong>Relocation.<\/strong> A fix\u2011up that adjusts addresses when code is loaded at a different base than it was built for.<\/p>\n<p><strong>kASLR.<\/strong> Randomizes kernel base addresses at boot to make exploitation harder.<\/p>\n<div class=\"blog-navigation\">\n<p>            <a target=\"_blank\" class=\"prev\" href=\"https:\/\/www.0xkato.xyz\/BFT-Pitfalls\/\">\u00ab Your BFT Protocol Will Break in Production<\/a><\/p><\/div>\n<section class=\"feedback\">\n<p class=\"feedback-text\">\n        Feedback is extremely welcomed! You can reach out to me on X <a target=\"_blank\" href=\"https:\/\/x.com\/0xkato\" target=\"_blank\" rel=\"noopener noreferrer\">@0xkato<\/a>\n    <\/p>\n<\/section>\n<footer class=\"footer-main\">\n    0xkato \u00a9 2025<\/p>\n<p>    <a target=\"_blank\" class=\"link\" href=\"https:\/\/www.0xkato.xyz\/feed.xml\" target=\"_blank\" alt=\"anchor link to rss feed\" aria-label=\"anchor link to rss feed\"><\/p>\n<p>    <\/a><\/p>\n<\/footer><\/div>\n\n<br \/><a href=\"https:\/\/www.0xkato.xyz\/linux-boot\/\">\u5143\u306e\u8a18\u4e8b\u3092\u78ba\u8a8d\u3059\u308b <\/a><\/p>\n","protected":false},"excerpt":{"rendered":"Saturday. October 25, 2025 &#8211; 15 mins Part 1 \u2014 From power button to the kernel\u2019s first breath You press t [&hellip;]","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"_acf_changed":false,"footnotes":""},"categories":[2],"tags":[],"class_list":["post-21159","post","type-post","status-publish","format-standard","hentry","category-hatena-blog"],"acf":[],"yoast_head":"<!-- This site is optimized with the Yoast SEO plugin v27.6 - https:\/\/yoast.com\/product\/yoast-seo-wordpress\/ -->\n<title>The Linux Boot Process: From Power Button to Kernel - \u30dd\u30b1\u30b3\u30f3<\/title>\n<meta name=\"robots\" content=\"index, follow, max-snippet:-1, max-image-preview:large, max-video-preview:-1\" \/>\n<link rel=\"canonical\" href=\"https:\/\/www.0xkato.xyz\/linux-boot\/\" \/>\n<meta property=\"og:locale\" content=\"ja_JP\" \/>\n<meta property=\"og:type\" content=\"article\" \/>\n<meta property=\"og:title\" content=\"The Linux Boot Process: From Power Button to Kernel - \u30dd\u30b1\u30b3\u30f3\" \/>\n<meta property=\"og:description\" content=\"Saturday. October 25, 2025 &#8211; 15 mins Part 1 \u2014 From power button to the kernel\u2019s first breath You press t [&hellip;]\" \/>\n<meta property=\"og:url\" content=\"https:\/\/www.0xkato.xyz\/linux-boot\/\" \/>\n<meta property=\"og:site_name\" content=\"\u30dd\u30b1\u30b3\u30f3\" \/>\n<meta property=\"article:published_time\" content=\"2025-10-27T20:32:50+00:00\" \/>\n<meta name=\"author\" content=\"info@pokecon.jp\" \/>\n<meta name=\"twitter:card\" content=\"summary_large_image\" \/>\n<meta name=\"twitter:label1\" content=\"\u57f7\u7b46\u8005\" \/>\n\t<meta name=\"twitter:data1\" content=\"info@pokecon.jp\" \/>\n\t<meta name=\"twitter:label2\" content=\"\u63a8\u5b9a\u8aad\u307f\u53d6\u308a\u6642\u9593\" \/>\n\t<meta name=\"twitter:data2\" content=\"14\u5206\" \/>\n<script type=\"application\/ld+json\" class=\"yoast-schema-graph\">{\"@context\":\"https:\\\/\\\/schema.org\",\"@graph\":[{\"@type\":\"Article\",\"@id\":\"https:\\\/\\\/www.0xkato.xyz\\\/linux-boot\\\/#article\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/pokecon.jp\\\/job\\\/21159\\\/\"},\"author\":{\"name\":\"info@pokecon.jp\",\"@id\":\"https:\\\/\\\/pokecon.jp\\\/job\\\/#\\\/schema\\\/person\\\/16c9f07b1ba984d165d9aee259bda997\"},\"headline\":\"The Linux Boot Process: From Power Button to Kernel\",\"datePublished\":\"2025-10-27T20:32:50+00:00\",\"mainEntityOfPage\":{\"@id\":\"https:\\\/\\\/pokecon.jp\\\/job\\\/21159\\\/\"},\"wordCount\":2710,\"articleSection\":[\"\u306f\u3066\u306a\u30d6\u30ed\u30b0\"],\"inLanguage\":\"ja\"},{\"@type\":\"WebPage\",\"@id\":\"https:\\\/\\\/pokecon.jp\\\/job\\\/21159\\\/\",\"url\":\"https:\\\/\\\/www.0xkato.xyz\\\/linux-boot\\\/\",\"name\":\"The Linux Boot Process: From Power Button to Kernel - \u30dd\u30b1\u30b3\u30f3\",\"isPartOf\":{\"@id\":\"https:\\\/\\\/pokecon.jp\\\/job\\\/#website\"},\"datePublished\":\"2025-10-27T20:32:50+00:00\",\"author\":{\"@id\":\"https:\\\/\\\/pokecon.jp\\\/job\\\/#\\\/schema\\\/person\\\/16c9f07b1ba984d165d9aee259bda997\"},\"breadcrumb\":{\"@id\":\"https:\\\/\\\/www.0xkato.xyz\\\/linux-boot\\\/#breadcrumb\"},\"inLanguage\":\"ja\",\"potentialAction\":[{\"@type\":\"ReadAction\",\"target\":[\"https:\\\/\\\/www.0xkato.xyz\\\/linux-boot\\\/\"]}]},{\"@type\":\"BreadcrumbList\",\"@id\":\"https:\\\/\\\/www.0xkato.xyz\\\/linux-boot\\\/#breadcrumb\",\"itemListElement\":[{\"@type\":\"ListItem\",\"position\":1,\"name\":\"\u30db\u30fc\u30e0\",\"item\":\"https:\\\/\\\/pokecon.jp\\\/job\\\/\"},{\"@type\":\"ListItem\",\"position\":2,\"name\":\"The Linux Boot Process: From Power Button to Kernel\"}]},{\"@type\":\"WebSite\",\"@id\":\"https:\\\/\\\/pokecon.jp\\\/job\\\/#website\",\"url\":\"https:\\\/\\\/pokecon.jp\\\/job\\\/\",\"name\":\"\u30dd\u30b1\u30b3\u30f3\",\"description\":\"\",\"potentialAction\":[{\"@type\":\"SearchAction\",\"target\":{\"@type\":\"EntryPoint\",\"urlTemplate\":\"https:\\\/\\\/pokecon.jp\\\/job\\\/?s={search_term_string}\"},\"query-input\":{\"@type\":\"PropertyValueSpecification\",\"valueRequired\":true,\"valueName\":\"search_term_string\"}}],\"inLanguage\":\"ja\"},{\"@type\":\"Person\",\"@id\":\"https:\\\/\\\/pokecon.jp\\\/job\\\/#\\\/schema\\\/person\\\/16c9f07b1ba984d165d9aee259bda997\",\"name\":\"info@pokecon.jp\",\"image\":{\"@type\":\"ImageObject\",\"inLanguage\":\"ja\",\"@id\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/2b0549cd9f7907c092ca5fbb283baf72337f235726e4b46fa39ec0b701ac2fe2?s=96&d=wavatar&r=g\",\"url\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/2b0549cd9f7907c092ca5fbb283baf72337f235726e4b46fa39ec0b701ac2fe2?s=96&d=wavatar&r=g\",\"contentUrl\":\"https:\\\/\\\/secure.gravatar.com\\\/avatar\\\/2b0549cd9f7907c092ca5fbb283baf72337f235726e4b46fa39ec0b701ac2fe2?s=96&d=wavatar&r=g\",\"caption\":\"info@pokecon.jp\"},\"url\":\"https:\\\/\\\/pokecon.jp\\\/job\\\/author\\\/infopokecon-jp\\\/\"}]}<\/script>\n<!-- \/ Yoast SEO plugin. -->","yoast_head_json":{"title":"The Linux Boot Process: From Power Button to Kernel - \u30dd\u30b1\u30b3\u30f3","robots":{"index":"index","follow":"follow","max-snippet":"max-snippet:-1","max-image-preview":"max-image-preview:large","max-video-preview":"max-video-preview:-1"},"canonical":"https:\/\/www.0xkato.xyz\/linux-boot\/","og_locale":"ja_JP","og_type":"article","og_title":"The Linux Boot Process: From Power Button to Kernel - \u30dd\u30b1\u30b3\u30f3","og_description":"Saturday. October 25, 2025 &#8211; 15 mins Part 1 \u2014 From power button to the kernel\u2019s first breath You press t [&hellip;]","og_url":"https:\/\/www.0xkato.xyz\/linux-boot\/","og_site_name":"\u30dd\u30b1\u30b3\u30f3","article_published_time":"2025-10-27T20:32:50+00:00","author":"info@pokecon.jp","twitter_card":"summary_large_image","twitter_misc":{"\u57f7\u7b46\u8005":"info@pokecon.jp","\u63a8\u5b9a\u8aad\u307f\u53d6\u308a\u6642\u9593":"14\u5206"},"schema":{"@context":"https:\/\/schema.org","@graph":[{"@type":"Article","@id":"https:\/\/www.0xkato.xyz\/linux-boot\/#article","isPartOf":{"@id":"https:\/\/pokecon.jp\/job\/21159\/"},"author":{"name":"info@pokecon.jp","@id":"https:\/\/pokecon.jp\/job\/#\/schema\/person\/16c9f07b1ba984d165d9aee259bda997"},"headline":"The Linux Boot Process: From Power Button to Kernel","datePublished":"2025-10-27T20:32:50+00:00","mainEntityOfPage":{"@id":"https:\/\/pokecon.jp\/job\/21159\/"},"wordCount":2710,"articleSection":["\u306f\u3066\u306a\u30d6\u30ed\u30b0"],"inLanguage":"ja"},{"@type":"WebPage","@id":"https:\/\/pokecon.jp\/job\/21159\/","url":"https:\/\/www.0xkato.xyz\/linux-boot\/","name":"The Linux Boot Process: From Power Button to Kernel - \u30dd\u30b1\u30b3\u30f3","isPartOf":{"@id":"https:\/\/pokecon.jp\/job\/#website"},"datePublished":"2025-10-27T20:32:50+00:00","author":{"@id":"https:\/\/pokecon.jp\/job\/#\/schema\/person\/16c9f07b1ba984d165d9aee259bda997"},"breadcrumb":{"@id":"https:\/\/www.0xkato.xyz\/linux-boot\/#breadcrumb"},"inLanguage":"ja","potentialAction":[{"@type":"ReadAction","target":["https:\/\/www.0xkato.xyz\/linux-boot\/"]}]},{"@type":"BreadcrumbList","@id":"https:\/\/www.0xkato.xyz\/linux-boot\/#breadcrumb","itemListElement":[{"@type":"ListItem","position":1,"name":"\u30db\u30fc\u30e0","item":"https:\/\/pokecon.jp\/job\/"},{"@type":"ListItem","position":2,"name":"The Linux Boot Process: From Power Button to Kernel"}]},{"@type":"WebSite","@id":"https:\/\/pokecon.jp\/job\/#website","url":"https:\/\/pokecon.jp\/job\/","name":"\u30dd\u30b1\u30b3\u30f3","description":"","potentialAction":[{"@type":"SearchAction","target":{"@type":"EntryPoint","urlTemplate":"https:\/\/pokecon.jp\/job\/?s={search_term_string}"},"query-input":{"@type":"PropertyValueSpecification","valueRequired":true,"valueName":"search_term_string"}}],"inLanguage":"ja"},{"@type":"Person","@id":"https:\/\/pokecon.jp\/job\/#\/schema\/person\/16c9f07b1ba984d165d9aee259bda997","name":"info@pokecon.jp","image":{"@type":"ImageObject","inLanguage":"ja","@id":"https:\/\/secure.gravatar.com\/avatar\/2b0549cd9f7907c092ca5fbb283baf72337f235726e4b46fa39ec0b701ac2fe2?s=96&d=wavatar&r=g","url":"https:\/\/secure.gravatar.com\/avatar\/2b0549cd9f7907c092ca5fbb283baf72337f235726e4b46fa39ec0b701ac2fe2?s=96&d=wavatar&r=g","contentUrl":"https:\/\/secure.gravatar.com\/avatar\/2b0549cd9f7907c092ca5fbb283baf72337f235726e4b46fa39ec0b701ac2fe2?s=96&d=wavatar&r=g","caption":"info@pokecon.jp"},"url":"https:\/\/pokecon.jp\/job\/author\/infopokecon-jp\/"}]}},"_links":{"self":[{"href":"https:\/\/pokecon.jp\/job\/wp-json\/wp\/v2\/posts\/21159","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/pokecon.jp\/job\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/pokecon.jp\/job\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/pokecon.jp\/job\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/pokecon.jp\/job\/wp-json\/wp\/v2\/comments?post=21159"}],"version-history":[{"count":1,"href":"https:\/\/pokecon.jp\/job\/wp-json\/wp\/v2\/posts\/21159\/revisions"}],"predecessor-version":[{"id":21160,"href":"https:\/\/pokecon.jp\/job\/wp-json\/wp\/v2\/posts\/21159\/revisions\/21160"}],"wp:attachment":[{"href":"https:\/\/pokecon.jp\/job\/wp-json\/wp\/v2\/media?parent=21159"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/pokecon.jp\/job\/wp-json\/wp\/v2\/categories?post=21159"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/pokecon.jp\/job\/wp-json\/wp\/v2\/tags?post=21159"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}