Arch boot process (Magyar)

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.
További oldalak az adott témakörben
Autostarting (Magyar)
GUID Partition Table (Magyar)
Master Boot Record (Magyar)
Unified Extensible Firmware Interface (Magyar)
fstab (Magyar)
init (Magyar)
mkinitcpio (Magyar)
systemd (Magyar)
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
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.).
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.
A firmware elindítja az EFI alkalmazást.
Az alkalmazás lehet egy
boot loader
vagy maga az Arch
kernel
, amely
EFI boot stub
segítségével indul.
Lehet más EFI alkalmazás is, például az
UEFI shell
vagy egy
boot manager
, mint a
systemd-boot
vagy a
rEFInd
.
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
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.).
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.
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).
Elindul az aktuális
boot loader
.
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
–
Igen
1
Igen
Igen
–
Firmware-től örökölt
2
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
Igen
3
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
Igen
3
Igen
Igen
Igen
Korlátozott
rEFInd
Nem
Igen
Igen
Igen
Igen
4
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észleges
1
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
Igen
3
Manuális
Igen
Igen
4
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
–
Igen
3
Igen
Igen
–
Firmware-től örökölt
2
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.)
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.
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.
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.
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
).
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
(
init
ial
RAM
f
ile
s
ystem) 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ő:
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.
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.
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:
GPT partíció automatikus úton történő felcsatolása
nem használható, ezért a
root
kernelparaméter
mindig szükséges.
A
root
tartós blokkeszköz elnevezés
csak
PARTUUID
és
PARTLABEL
használatára korlátozódik
[5]
.
A
rootflags
mount
opciói korlátozottak, például a
noatime
nem működik
[6]
. Az esetleges mellékhatások mérséklésére az első felcsatolást olvasásra Ön korlátozva végezheti a
rootflags=ro
használatával. A kívánt opciók később újbóli felcsatolással alkalmazhatók az
fstab
segítségével.
A
systemd-gpt-auto-generator(8)
initramfs nélkül értelmetlen és problémás
[7]
, tiltsa le a
systemd.gpt_auto=no
beállításával.
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
(
m
essage
o
f
t
he
d
ay) 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
Wikipedia:Booting process of Linux
Inside the Linux boot process
Rod Smith - Managing EFI Boot Loaders for Linux
NeoSmart: The BIOS/MBR Boot Process
Lennart Poettering - Linux Boot Partitions and How to Set Them Up
Wikipedia:initramfs
Early Userspace in Arch Linux
Kernel Newbie Corner: initrd and initramfs
bootup(7)
(mostly about the systemd initramfs userspace portion)