Jump to content

Arch boot process (Magyar)

From ArchWiki
Fordítás állapota: Ez az oldal az angol Arch boot process című oldal magyar nyelvre lefordított változata. Utolsó fordítás dátuma: 2026.02.14. Amennyiben a lefordítás időpontja óta az angol nyelvű oldalon történtek újabb módosítások, akkor Ön segíthet hozzászinkronizálni az angolhoz ezt a magyar nyelvű fordítást.

Adott témakörhöz kapcsolódó oldalak

Az Arch Linux operációs rendszer bootolásához szükség van egy Linux-kompatibilis boot loader (rendszerbetöltő) beállítására. A boot loader program azért felel, hogy még mielőtt megkezdődik a bootolási folyamat, a kernel és az initramfs fájlrendszer be legyen töltve a számítógép memóriájába. Az eljárás jelentősen más a BIOS és jelentősen más az UEFI számítógépes rendszerek esetében.

Firmware típusok

A firmware az első program amely a számítógép bekapcsolásakor végrehajtásra kerül.

Tipp
  • A felhasználók a BIOS és az UEFI kifejezést gyakran használják a firmware kifejezés helyett.
  • Ne keverje össze a firmware kifejezést a Linux firmware kifejezéssel. A kettő kifejezés nem ugyanazt a fogalmat jelenti.

UEFI

Az Unified Extensible Firmware Interface támogatja mind a partíciós táblázat olvasását, mind a fájlrendszerek olvasását. Függetlenül attól, hogy a boot programkód létezik-e az adathordozó területén vagy sem, az UEFI nem indít el semmilyen boot programkódot az adathordozó Master Boot Record (MBR) területéről. Ehelyett a bootolás az NVRAM memóriában található boot bejegyzésekre támaszkodik. (Fordítói megjegyzés: Az UEFI firmware programkód az alaplapi flash chipben van beleírva. Az NVRAM memória az UEFI firmware programkódhoz tartozó beállításokat tárolja. Tehát a kettő nem ugyanaz. Az alaplapi flash chipet és az NVRAM memóriát lehet egy elektronikai alkatrészbe belerakni (összeépíteni), gyártótól függően.).

Az UEFI specifikáció előírja a FAT12, FAT16 és FAT32 fájlrendszerek támogatását (tekintse meg az UEFI 2.11 specifikáció 13.3.1.1 szakaszát), de bármely szabványnak megfelelő gyártó opcionálisan további fájlrendszerek támogatását is hozzáadhatja. Például HFS+ fájlrendszer vagy APFS fájlrendszer néhány Apple firmware esetében. Az UEFI implementációk támogatják az ISO 9660 fájlrendszert is az optikai adathordozó lemezek számára.

Az UEFI úgynevezett EFI alkalmazásokat indít el. Például boot loader alkalmazásokat, boot manager alkalmazásokat, UEFI shell alkalmazást stb. Ezek az alkalmazások általában fájlok formájában vannak eltárolva az EFI rendszerpartíción. Minden gyártó a saját fájljait az EFI rendszerpartíción a /EFI/gyártó_neve könyvtárban tárolhatja. Az EFI alkalmazások elindíthatók azáltal, hogy Ön egy boot bejegyzést ad hozzá az NVRAM memóriához, illetve az EFI alkalmazások elindíthatók az UEFI shell alkalmazásból (az UEFI parancssorából) is. (Fordítói megjegyzés: Az UEFI parancssora is önmagában egy EFI alkalmazás. Azt elindítva (tehát abba a parancssori alkalmazásba belelépve) indítható el a többi EFI alkalmazás).

Az UEFI specifikáció támogatja a Compatibility Support Module (CSM) segítségével a hagyományos BIOS bootolást. Ha a CSM engedélyezve van az UEFI-ben, akkor az UEFI CSM boot bejegyzéseket generál minden adathordozó számára. Ha a felhasználó egy CSM boot bejegyzést választ ki bootolásra, akkor az UEFI CSM megpróbálja bootolni az adathordozó MBR bootstrap programkódját.

Megjegyzés Az Intel fokozatosan megszünteti a CSM támogatását, így a CSM funkcióra való támaszkodás a jövőben nem biztos, hogy megvalósítható lesz.[1]

BIOS

A BIOS (Basic Input-Output System) a legtöbb esetben az alaplap saját flash memóriájában van eltárolva, és független a számítógépen lévő másik adathordozóktól. Eredetileg az IBM PC számára hozták létre a hardver inicializálásának és az bootolási folyamatnak a kezelésére, de 2010 óta fokozatosan felváltotta az UEFI, amely nem szenved ugyanazoktól a technikai korlátoktól mint amely technikai korlátoktól a BIOS szenved.

Számítógépes rendszer inicializálása

A számítógépes rendszer bekapcsolásakor lefut a power-on self-test (POST). Ezzel kapcsolatban tekintse meg Hugo Landau Modern CPUs have a backstage cast című írását.

UEFI

  1. A POST végrehajtódása után az UEFI inicializálja a bootoláshoz szükséges hardvereket (lemez, billentyűzetvezérlők stb.).
  2. A firmware beolvassa az NVRAM-ban lévő boot bejegyzéseket annak érdekében, hogy meghatározza, melyik EFI alkalmazást indítsa el és honnan (például melyik lemezről és partícióról).
    • Egy boot bejegyzés lehet egyszerűen egy lemez. Ebben az esetben a firmware megkeresi az adott lemezen az EFI rendszerpartíciót, és megpróbálja megtalálni az EFI alkalmazást az alapértelmezett "fallback" \EFI\BOOT\BOOTx64.EFI boot útvonalon (IA32, tehát 32 bites UEFI rendszereken BOOTIA32.EFI). Így működnek a UEFI-vel bootolható cserélhető adathordozók.
  3. A firmware elindítja az EFI alkalmazást.

Ha a Secure Boot engedélyezve van, akkor a boot folyamat aláírás alapján ellenőrzi az EFI binárisan futtatható fájl hitelességét.

Megjegyzés Néhány UEFI-vel rendelkező számítógépes rendszer csak a tartalék (fallback) bootolási útvonalról képes bootolni.

Multibooting

Mivel minden operációs rendszer vagy gyártó saját fájlokat tárolhat az EFI rendszerpartíción anélkül, hogy az egyik operációs rendszer befolyásolná a másikat, az UEFI használatával történő multiboot alatt csupán annyit kell érteni, hogy egy másik EFI alkalmazás van elindítva, amely az adott operációs rendszer boot loader programjának felel meg. Ez megszünteti annak szükségességét, hogy az egyik boot loader láncbetöltési mechanizmusaira támaszkodjon a másik operációs rendszer betöltése.

Tekintse meg a Dual boot a Windows rendszerrel című leírást is.

BIOS

  1. A POST végrehajtódása után a BIOS inicializálja a bootoláshoz szükséges hardvereket (lemez, billentyűzetvezérlők stb.).
  2. A BIOS elindítja az első lemez első 440 byte-ját (a Master Boot Record bootstrap kódterületet) a BIOS lemezsorrendje alapján.
  3. A boot loader első szakasza az MBR boot kódban ezután az alábbi helyekről elindítja a második szakasz kódját (ha létezik):
    • Az MBR utáni következő lemezszektorokból, az úgynevezett post-MBR résből (csak MBR partíciós táblázaton),
    • egy partícióból vagy partíció nélküli lemez kötet boot rekordjából (VBR),
    • GRUB esetén GPT partíciós lemezen—a GRUB-specifikus BIOS boot partícióból (ez helyettesíti a GPT-ben nem létező post-MBR rést).
  4. Elindul az aktuális boot loader.
  5. Ezutnán a boot loader a memóriába betölti az operációs rendszert láncbetöltéssel vagy közvetlenül az operációs rendszer kernelének betöltésével.

Rendszerbetöltő

A boot loader (rendszerbetöltő) egy olyan szoftver, amelyet a firmware (UEFI vagy BIOS) indít el. Feladata a kernel betöltése a számítógép memóriájába a kívánt kernelparaméterekkel együtt, és minden külső initramfs képfájl betöltése a számítógép memóriájába.

A boot manager a bootolási lehetőségekről egy menüt jelenít meg, vagy más módot biztosít a bootolási folyamat irányítására. (Azaz egyszerűen más EFI végrehajtható fájlokat futtat.).

UEFI esetében az EFI boot stub segítségével a kernel közvetlenül elindítható az UEFI által. A bootolás előtt továbbra is használható külön boot loader vagy boot manager a kernelparaméterek szerkesztésére.

Számítógépes rendszerek, amelyek 32 bites IA32 UEFI megoldást használnak, olyan boot loadert igényelnek, amely támogatja a vegyes módú bootolást.

Figyelmeztetés Az Arch operációs rendszer sikeres bootolásához a boot loadernek hozzá kell férnie a kernelhez és az initramfs képfájl(ok)hoz, amelyek általában a /boot könyvtárban találhatók. Ez azt jelenti, hogy a boot loadernek támogatnia kell mindent, kezdve a blokk eszközöktől, a rétegzett blokk eszközökön (LVM, RAID, dm-crypt, LUKS, stb.) át egészen a fájlrendszerig, amelyen a kernel(ek) és az initramfs képfájl(ok) találhatók.

Mivel szinte egyetlen boot loader sem támogatja az ilyen rétegzett blokk eszközöket, és mivel a fájlrendszerek új funkciókat vezethetnek be, amelyeket még egyetlen boot loader sem támogat (például archlinux/packaging/packages/grub#7, FS#79857, FS#59047, FS#58137, FS#51879, FS#46856, FS#38750, FS#21733 és a fscrypt által titkosított könyvtárak), ezért gyakran célszerűbb egy külön /boot partíció használata univerzálisan támogatott fájlrendszerrel, mint például a FAT32.

Jellemzők összehasonlítása

Megjegyzés
  • Mivel a GPT partíciós táblázat az UEFI specifikáció része, ezért minden UEFI boot loader támogatja a GPT partíciós táblázattal megformázott adathordozókat. A GPT partíciós táblázat használata BIOS rendszereken is lehetséges, akár "hibrid bootolással" a Hybrid MBR segítségével, akár az új kizárólag GPT protokollal. Ez a protokoll azonban problémákat okozhat bizonyos BIOS megvalósításoknál. Részletekért tekintse meg a rodsbooks című leírást.
  • Mivel a Secure Boot funkció az UEFI specifikáció része, ezért minden UEFI boot loader támogatja a Secure Boot funkciót, bár némelyik korlátozásokkal teszi ezt.
Név Firmware Partíciós táblázat Multi-boot Fájlrendszer Megjegyzések
BIOS UEFI MBR GPT
Clover Igen Igen Nem Igen Igen Bővíthető2,5 Képes UEFI emulációra a hagyományos BIOS számítógépes rendszereken.
EFI boot stub – Igen1 Igen Igen – Firmware-től örökölt2 A kernel egy érvényes EFI végrehajtható állomány, amely közvetlenül indítható UEFI-ből vagy egy másik UEFI boot loaderből.
GRUB Igen Igen3 Igen Igen Igen Beépített Támogatja a RAID-et, a LUKS-ot (de nem az Argon2 PBKDF-eket) és az LVM-et (de nem a vékonyan kiosztott köteteket). Tekintse meg a GRUB című cikket a beállítás-specifikus korlátozás megismerése érdekében.
Limine Igen Igen3 Igen Igen Igen Korlátozott
rEFInd Nem Igen Igen Igen Igen4 Bővíthető2,5 Támogatja a kernelek és paraméterek automatikus felismerését explicit beállítás nélkül, valamint támogatja a gyors indítást [2].
Syslinux Igen Részleges1 Igen Igen Részleges Korlátozott Nincs támogatás bizonyos fájlrendszer-funkciókhoz.
Egyedül ahhoz a fájlrendszerhez tud hozzáférni, amelyre telepítve lett.
systemd-boot Nem Igen3 Manuális Igen Igen4 Bővíthető2,5 Egyedül arról az ESP partícióról tud bináris futtatható fájlokat elindítani, amelyre telepítve lett, vagy ugyanazon a lemezen található Extended Boot Loader Partition (XBOOTLDR) partícióról.
Automatikusan felismeri az egységes kernelképfájlokat, amelyek az esp/EFI/Linux/ könyvtárba vannak elhelyezve.
Unified kernel image – Igen3 Igen Igen – Firmware-től örökölt2 A systemd-stub(7), a kernel, az initramfs és a kernelparancssor egy EFI végrehajtható állományba van becsomagolva, amely közvetlenül betölthető a számítógép memóriájába az UEFI firmware-ből vagy egy másik boot loaderből.
GRUB Legacy Igen Nem Igen Nem Igen Korlátozott Megszüntetve a GRUB javára.
LILO Igen Nem Igen Részleges Igen Korlátozott Megszüntetve a korlátozások miatt. (Például: Btrfs, GPT, RAID, titkosítás esetén.)
  1. Bár a bináris futtatható fájl aláírható a Secure Boot számára, nem végez további ellenőrzést, így megszakítja a bizalmi láncot.
  2. A fájlrendszer-támogatás az alapfirmware-ből öröklődik. A UEFI specifikáció előírja a FAT12, FAT16 és FAT32 fájlrendszerek támogatását [3], de a gyártók opcionálisan további fájlrendszerek támogatását is hozzáadhatják. Például az Apple Mac számítógépeinek firmware-je támogatja a HFS+ fájlrendszert. Ha a firmware biztosít interfészt bootoláskor UEFI-illesztőprogramok betöltésére, akkor további fájlrendszerek támogatása hozzáadható (önállóan beszerzett) fájlrendszer-illesztőprogramok betöltésével.
  3. Támogatja a vegyes módú bootolást. Azaz képes egy 64 bites x86_64 Linux kernelt elindítani 32 bites IA32 UEFI környezetben.
  4. Egy boot manager. Kizárólag másik EFI alkalmazásokat képes elindítani, például Linux kernelképfájlokat, amelyek CONFIG_EFI_STUB=y beállítással készültek, valamint a Windows Boot Managert (bootmgfw.efi).
  5. Támogatja az UEFI fájlrendszer-illesztőprogramok betöltését.

Tekintse meg a Wikipedia:Boot loader programok összehasonlítása című leírást is.

Kernel

A boot loader betölti a számítógép RAM memóriájába a binárisan futtatható vmlinux képfájlt, amely képfájl tartalmazza a binárisan futtatható kernelt.

A kernel (szokták még rendszermagnak is nevezni) alacsony szinten (kernelspace) működik, a számítógép hardvere és a programok között közvetítve. A kernel kezdetben hardverfelismerést és inicializálást végez, mielőtt folytatná a felhasználói térbe történő belépést. Részletes magyarázatért olvassa el a Rendszermag és Linux (rendszermag) című Wikipédia cikkeket.

initramfs

Egy initramfs (initial RAM file system) bináris képfájl tulajdonképpen egy cpio archívumfájl, amely biztosítja a szükséges fájlokat a korai felhasználói tér számára (részletek lentebb) annak érdekében, hogy a biztosított fájlok által maga az initramfs sikeresen elindítsa a késői felhasználói teret. A bináris initramfs képfájl elsősorban az összes bináris kernelmodulfájlt, felhasználói térben működő programot, kapcsolódó függvénykönyvtárakat, támogató fájlokat, például udev szabályokat stb. jelenti, amely fájlok szükségesek a gyökérfájlrendszer megtalálásához, eléréséhez és felcsatolásához. Az initramfs koncepciójával lehetőség nyílik még összetettebb beállítások kezelésére is. Például lehetőség van külső adathordozóról történő bootolásra, lehetőség van egymásra épülő eszközök (logikai kötetek, szoftveres RAID-ek, tömörítés, titkosítás) használatára, vagy lehetőség van egy apró SSH szerver futtatására a korai felhasználói térben a gyökérfájlrendszer távoli feloldásához vagy a karbantartási feladatokhoz.

A bináris kernelmodulfájlok többsége az init folyamat későbbi szakaszaiban kerül betöltésre a számítógép RAM memóriájába az udev által, miután a gyökérkönyvtár a memóriából át lett állítva a gyökérfájlrendszer könyvtárára.

A folyamat a következő:

  1. A gyökérfájlrendszer a / alatt egy üres rootfs formájában indul el, amely a tmpfs vagy ramfs egy speciális példánya. Ez az ideiglenes gyökérfájlrendszer, ahová az initramfs bináris képfájlok kicsomagolásra kerülnek.
  2. A kernel kicsomagolja a beépített initramfs fájlt az ideiglenes gyökérkönyvtárba. Az Arch Linux hivatalosan támogatott kerneljei üres archívumot használnak a beépített initramfs fájlhoz, ami az alapértelmezett beállítás a Linux forráskódból történő lefordításakor.
  3. A kernel a külső initramfs bináris képfájlokat a boot loader által átadott parancssorban megadott sorrendben csomagolja ki, felülírva a beágyazott initramfs fájljait vagy a korábban kicsomagolt fájlokat. Megjegyzendő, hogy több initramfs képfájlt esetén egyetlen fájlban is kombinálható, és a kernel a fájlban szereplő sorrendben dolgozza fel őket.
    • Ha az első initramfs képfájl tömörítetlen, akkor a kicsomagolás után a kernel CPU mikrokód frissítéseket és ACPI táblázatfrissítéseket keres a /kernel/x86/microcode/ illetve a /kernel/firmware/acpi/ könyvtárakban.
    • Amennyiben még vannak fennmaradó initramfs képfájlok, akkor a CPU mikrokód és ACPI táblázatfrissítések feldolgozása után a kernel folytatja a fennmaradó initramfs képfájlok kicsomagolását.

Az initramfs bináris képfájlok az Arch Linux által preferált módszert jelentik a korai felhasználói tér beállítására, és legenerálhatóak az mkinitcpio, dracut vagy booster segédalkalmazásokkal.

Futtatás az initramfs nélkül

A 6.13.8 kernelverzió óta a hivatalosan támogatott kernelek beépített Btrfs és Ext4 illesztőprogramokkal rendelkeznek. [4].

Ez az illesztőprogramok beépítettsége lehetővé teszi a kernel számára, hogy maga a kernel közvetlenül ezekkel a fájlrendszerekkel használja a gyökérpartíciót, és magáról a gyökérpartícióról töltse be a szükséges külső kernelmodulfájlok többi részét. Ugyanakkor van néhány furcsaság, amelyet érdemes szem előtt tartani:

Megjegyzés Jelenleg egyedül a virtio és a hagyományos SCSI/SATA/AHCI adathordozók rendelkeznek beépített kernelmodulokkal. Más adathordozók (NVMe, USB, device mapper stb.) nem működnek. Az LVM vagy a titkosítás sem használható initramfs nélkül, mivel működésükhöz felhasználói térben futó segédprogramokra van szükség.

Egy másik dolog, amihez valóban szükség van initramfs képfájlra, az mikrokód korai betöltése. Ehhez azonban nem szükséges teljes képfájlt készíteni, mivel az Arch biztosít mikrokódot külön initramfs képfájlokban, amelyek önállóan is használhatók.

Ha nem áll rendelkezésre initramfs képfájl, akkor a kernel mindig tartalmaz egy üres képfájlt, amelyből el lehet indulni [8]. Így nem lehet probléma a gyökérpartíció meghatározása.

Early userspace

Az early userspace (korai felhasználói tér) szakasz, más néven az initramfs szakasz, az #initramfs által biztosított fájlokból álló rootfs fájlrendszerben zajlik. Az early userspace akkor indul, amikor a kernel elindítja PID 1 folyamatként a /init bináris fájlt.

Az early userspace funkciója beállítható, de fő célja a rendszer bootstrap-elése addig a pontig, amíg hozzá nem tud férni a gyökérfájlrendszerhez. Ez magában foglalja:

  • A systemd-modules-load(8) betölti a kernel modulfájlokat a memóriába. Például azokat a blokk eszköz modulfájlokat tölti be, amelyek szükségesek a valódi gyökérfájlrendszer felcsatolásához.
  • Beállítja az adathordozó réteget, amelyen a gyökérfájlrendszer található, például dm-crypt, dm-verity, mdadm, LVM, systemd-repart stb. segítségével.
    • Ha alkalmazható a művelet, akkor kezeli a valódi gyökérfájlrendszer titkosításának feloldását.
  • Az állandó (persistent) blokk adathordozók neveinek feloldása valódi adathordozókra udev segítségével.
  • Betölti a DRM kernelmodulfájlt a memóriába, mivel a korai KMS alapértelmezetten engedélyezve van.

Vegye figyelembe, hogy az early userspace nem csupán a gyökérfájlrendszer beállítását szolgálja. Vannak olyan feladatok, amelyeket csak a gyökérfájlrendszer felcsatolása előtt lehet elvégezni, például a fsck futtatása és a hibernáció állapotából való visszatérés.

Az early userspace végső szakaszában a valódi gyökér a /sysroot/ alá kerül felcsatolásra (ha systemd-alapú initramfs-ről van szó), vagy a /new_root/ alá (ha busybox-alapú initramfs képfájlt használunk). Ezután a váltás a systemctl switch-root paranccsal történik systemd-alapú initramfs esetén, illetve a switch_root(8) paranccsal busybox-alapú initramfs esetén. A late userspace (kései userspace) az init program futtatásával indul a valódi gyökérfájlrendszerből.

Late userspace

A late userspace (késői felhasználói tér) elindítását az init folyamat hajtja végre. Az Arch hivatalosan a systemd init rendszert használja, amely az unit-fájlok és szolgáltatásfájlok koncepciójára épül, de az itt leírt funkcionalitás nagyrészt átfedésben van más init rendszerekkel.

getty

Az init folyamat minden egyes virtuális terminál (általában hat darab) számára meghívja a getty programot. A getty inicializálja az egyes terminálokat, és megvédi azokat az illetéktelen hozzáféréstől. Amikor megadják a felhasználónevet és jelszót, a getty ezeket összeveti a /etc/passwd és /etc/shadow fájlokkal, majd meghívja a login(1) parancsot.

Login

A login program elindítja a felhasználói munkamenetet azáltal, hogy beállítja a környezeti változókat és elindítja a felhasználó parancsértelmezőjét a /etc/passwd alapján. A login program a sikeres bejelentkezés után, közvetlenül a bejelentkezési parancsértelmező futtatása előtt megjeleníti a /etc/motd (message of the day) tartalmát. Ez jó hely arra, hogy Ön megjelenítse a Szolgáltatási feltételeket, emlékeztetve a felhasználókat a helyi szabályokra vagy bármilyen más információra, amelyet közölni kíván velük.

Shell

Amint a felhasználó shell programja elindul, az általában futtat egy futásidejű beállításfájlt, például a bashrc fájlt, mielőtt megjeleníti a parancssort a felhasználónak. Ha a felhasználó fiókja úgy van beállítva, hogy X-szervert indítson el bejelentkezéskor, akkor a futásidejű beállításfájl meghívja a startx vagy xinit parancsot. Ugrás a #Grafikus munkamenet (Xorg) részhez a végéhez.

Display manager

This article or section needs expansion.

Reason: Ez a szakasz egyedül az Xorg folyamatát írja le, de nem magyarázza el, hogy mi történik a Wayland esetében. (Discuss in Talk:Arch boot process (Magyar))

Az init beállítható úgy, hogy egy adott virtuális terminálon a getty helyett egy display manager programot indítson el. Ehhez manuális úton, kézzel kell engedélyezni annak systemd szolgáltatásfájlját. A display manager ezután elindít egy grafikus munkamenetet.

Grafikus munkamenet (Xorg)

Az xinit futtatja a felhasználó xinitrc futásidejű beállításfájlját, amely általában egy window manager programot vagy egy asztali környezet programot indít. Amikor a felhasználó befejezi a munkát és kilép, akkor az xinit, startx, a shell és a login leállnak ebben a sorrendben, visszatérve a getty programhoz vagy a display manager programhoz.

További olvasnivaló a témában