101.2 Lecke 1
Tanúsítvány: |
LPIC-1 |
---|---|
Verzió: |
5.0 |
Témakör: |
101 Rendszerarchitektúra |
Fejezet: |
101.2 A rendszer indítása |
Lecke: |
1/1 |
Bevezetés
A gép vezérléséhez az operációs rendszer fő összetevőjét — a kernelt --, egy bootloader nevű programnak kell betöltenie, amit egy előre telepített firmware, például a BIOS vagy az UEFI tölt be. Testreszabható, hogy a bootloader paramétereket adjon át a kernelnek, például azt, hogy melyik partíció tartalmazza a gyökérfájlrendszert, vagy azt, hogy az operációs rendszer milyen üzemmódban fusson. A betöltés után a kernel folytatja a rendszerindítási folyamatot, azonosítva és konfigurálva a hardvert. Végül a kernel meghívja a rendszer szolgáltatásainak indításáért és kezeléséért felelős segédprogramot.
Note
|
Egyes Linux disztribúciókban az ebben a leckében végrehajtott parancsok root jogosultságokat igényelhetnek. |
BIOS vagy UEFI
Az x86-os gépek által a bootloader futtatásához végrehajtott eljárások különböznek attól, hogy BIOS-t vagy UEFI-t használnak. A BIOS, a Basic Input/Output System rövidítése, az alaplaphoz csatlakoztatott, non-volatile (megmaradó) memóriachipen tárolt program, amely a számítógép minden egyes bekapcsolásakor végrehajtódik. Az ilyen típusú programot firmware-nek nevezik, és a tárolási helye elkülönül a rendszer esetleges egyéb tárolóeszközeitől. A BIOS feltételezi, hogy az első tárolóeszköz első 440 bájtja — a BIOS konfigurációs segédprogramjában meghatározott sorrend szerint — a bootloader (más néven bootstrap) első szakasza. A tárolóeszköz első 512 bájtját a DOS szabványos partíciós sémáját használó tárolóeszközök MBR-jének (Master Boot Record) nevezik, és a bootloader első szakaszán kívül a partíciós táblát is tartalmazza. Ha az MBR nem tartalmazza a megfelelő adatokat, a rendszer nem tud elindulni, hacsak nem alkalmazunk alternatív módszert.
Általánosságban elmondható, hogy a BIOS-szal ellátott rendszer indítása előtti lépések a következők:
-
A POST (power-on self-test) folyamat az egyszerű hardverhibák azonosítása érdekében a gép bekapcsolásakor azonnal végrehajtódik.
-
A BIOS aktiválja az alapvető komponenseket a rendszer betöltéséhez, mint például a videokimenetet, a billentyűzetet és a tárolóeszközöket.
-
A BIOS betölti a bootloader első szakaszát az MBR-ből (az első eszköz első 440 bájtja a BIOS konfigurációs segédprogramjában meghatározottak szerint).
-
A bootloader első szakasza hívja a bootloader második szakaszát, amely a bootolási opciók megjelenítéséért és a kernel betöltéséért felelős.
Az UEFI, amely az Unified Extensible Firmware Interface rövidítése, néhány kulcsfontosságú ponton különbözik a BIOS-tól. A BIOS-hoz hasonlóan az UEFI is egy firmware, de képes azonosítani a partíciókat és olvasni számos, azokban található fájlrendszert. Az UEFI nem támaszkodik az MBR-re, csak az alaplaphoz csatlakoztatott non-volatile memóriájában (NVRAM) tárolt beállításokat veszi figyelembe. Ezek a definíciók jelzik az UEFI-kompatibilis programok, az úgynevezett EFI-alkalmazások helyét, amelyek automatikusan végrehajtódnak vagy a rendszerindítási menüből hívhatók. Az EFI-alkalmazások lehetnek bootloaderek, operációs rendszer kiválasztók, a rendszer diagnosztikájához és javításához szükséges eszközök stb. Ezeknek egy hagyományos tárolóeszköz partíciójában és egy kompatibilis fájlrendszerben kell lenniük. A szabványos kompatibilis fájlrendszerek a FAT12, FAT16 és FAT32 a blokkos eszközök esetén és az ISO-9660 az optikai adathordozók esetén. Ez a megközelítés sokkal kifinomultabb eszközök megvalósítását teszi lehetővé, mint amire a BIOS lehetőséget nyújt.
Az EFI-alkalmazásokat tartalmazó partíciót EFI rendszerpartíciónak vagy egyszerűen ESP-nek nevezik. Ezt a partíciót nem szabad megosztani más rendszer-fájlrendszerekkel, például a gyökérfájlrendszerrel vagy a felhasználói adatfájlrendszerekkel. Az ESP partícióban található EFI mappa tartalmazza azokat az alkalmazásokat, amelyekre az NVRAM-ba mentett bejegyzések mutatnak.
Általánosságban elmondható, hogy az UEFI-vel rendelkező rendszerek esetében a rendszerindítás előtti lépések a következők:
-
A POST (power-on self-test) folyamat az egyszerű hardverhibák azonosítása érdekében a gép bekapcsolásakor azonnal végrehajtódik.
-
Az UEFI aktiválja az alapvető komponenseket a rendszer betöltéséhez, például a videokimenetet, a billentyűzetet és a tárolóeszközöket.
-
Az UEFI firmware beolvassa az NVRAM-ban tárolt definíciókat az ESP partíció fájlrendszerében tárolt, előredefiniált EFI-alkalmazás futtatásához. Általában az előredefiniált EFI-alkalmazás egy bootloader.
-
Ha az előre definiált EFI-alkalmazás egy bootloader, akkor az operációs rendszer indításához betölti a kernelt.
Az UEFI-szabvány támogatja a Secure Boot nevű funkciót is, amely csak a hardver gyártója által engedélyezett, azaz aláírt EFI-alkalmazások futtatását teszi lehetővé. Ez a funkció növeli a rosszindulatú szoftverekkel szembeni védelmet, de megnehezítheti a gyártó garanciáján kívüli operációs rendszerek telepítését.
A bootloader
Az x86-os architektúrájú Linux legnépszerűbb bootloadere a GRUB (Grand Unified Bootloader). Amint a BIOS vagy az UEFI meghívja, a GRUB megjeleníti a bootolásra rendelkezésre álló operációs rendszerek listáját. Néha a lista nem jelenik meg automatikusan, de előhívható a Shift lenyomásával, miközben a GRUB-ot a BIOS hívja. UEFI rendszerekben az Esc billentyűt kell használni.
A GRUB menüből kiválasztható, hogy a telepített kernelek közül melyik legyen betöltve, és új paramétereket adhatunk át neki. A legtöbb kernelparaméter az opció=érték
mintát követi. Néhány a leghasznosabb paraméterek közül:
acpi
-
ACPI-támogatás engedélyezése/letiltása. Az
acpi=off
letiltja az ACPI támogatását. init
-
Alternatív rendszerinicializálót állít be. Például az
init=/bin/bash
a Bash shell-t állítja be. Ez azt jelenti, hogy egy shell munkamenet közvetlenül a kernel indítási folyamata után fog elindulni. systemd.unit
-
Beállítja az aktiválandó systemd célpontot. Például
systemd.unit=graphical.target
. A systemd elfogadja a SysV számára meghatározott numerikus futási szinteket is. Az 1-es futási szint aktiválásához például csak az1
számot vagy azS
betűt (a “single” rövidítése) kell kernelparaméterként megadni. mem
-
Beállítja a rendszer számára rendelkezésre álló RAM mennyiségét. Ez a paraméter a virtuális gépeknél hasznos, hogy korlátozza, mennyi RAM álljon az egyes vendégek rendelkezésére. A
mem=512M
használata 512 megabájtra korlátozza az adott vendégrendszer számára rendelkezésre álló RAM mennyiségét. maxcpus
-
Korlátozza a rendszer számára látható processzorok (vagy processzormagok) számát szimmetrikus többprocesszoros gépeken. Ez a virtuális gépeknél is hasznos. A
0
érték kikapcsolja a többprocesszoros gépek támogatását, és ugyanolyan hatású, mint a kernelnosmp
paramétere. Amaxcpus=2
paraméter az operációs rendszer számára elérhető processzorok számát kettőre korlátozza. quiet
-
Elrejti a legtöbb indítási üzenetet.
vga
-
Kiválasztja a videomódot. A
vga=ask
paraméter megjeleníti a rendelkezésre álló módok listáját, amelyek közül választani lehet. root
-
Beállítja a rootpartíciót, amely különbözik a bootloaderben előre beállított partíciótól. Például
root=/dev/sda3
. rootflags
-
A root-fájlrendszer csatolási beállításai.
ro
-
A root-fájlrendszer kezdeti csatolását csak olvashatóvá teszi.
rw
-
Lehetővé teszi az írást a gyökér fájlrendszerbe a kezdeti csatolás során.
A kernel paramétereinek módosítása általában nem szükséges, de hasznos lehet az operációs rendszerrel kapcsolatos problémák észleléséhez és megoldásához. A kernelparamétereket hozzá kell adni az /etc/default/grub
fájlhoz a GRUB_CMDLINE_LINUX
sorban, hogy azok az újraindítások során is megmaradjanak. A bootloaderhez új konfigurációs fájlt kell generálni minden egyes /etc/default/grub
változáskor, ami a grub-mkconfig -o /boot/grub/grub/grub.cfg
paranccsal érhető el. Ha az operációs rendszer fut, az aktuális munkamenet betöltéséhez használt kernelparaméterek a /proc/cmdline
fájlban olvashatók.
Note
|
A GRUB konfigurálásáról egy későbbi leckében lesz szó. |
Rendszerinicializálás
Az operációs rendszer a kernelen kívül más komponensektől is függ, amelyek az elvárt funkciókat biztosítják. Ezen összetevők közül sokan a rendszer inicializálási folyamata során töltődnek be, az egyszerű shellszkriptektől kezdve az összetettebb szolgáltatási programokig. A szkripteket gyakran rövid életű feladatok elvégzésére használják, amelyek a rendszer inicializálási folyamata során futnak le és fejeződnek be. A szolgáltatások, más néven daemonok, állandóan aktívak lehetnek, mivel az operációs rendszer belső aspektusaiért lehetnek felelősek.
A legkülönbözőbb tulajdonságokkal rendelkező indítószkriptek és daemonok Linux-disztribúcióba való beépítésének sokfélesége hatalmas, ez történelmileg akadályozta egy olyan egységes megoldás kifejlesztését, amely megfelel az összes Linux-disztribúció karbantartói és felhasználói elvárásainak. Azonban bármilyen eszközt is választanak a disztribúciók karbantartói ezen funkció ellátására, az legalább a rendszerszolgáltatások indítására, leállítására és újraindítására képes. Ezeket a műveleteket gyakran maga a rendszer végzi el például egy szoftverfrissítés után, de a rendszergazdának szinte mindig manuálisan kell újraindítania a szolgáltatást, miután módosította annak konfigurációs fájlját.
A rendszergazda számára is kényelmes, ha a körülményektől függően aktiválhatja a daemonok egy adott csoportját. Lehetővé kell tenni például, hogy a rendszerkarbantartási feladatok elvégzéséhez csak egy minimális szolgáltatáskészletet futtasson.
Note
|
Szigorúan véve az operációs rendszer nem más, mint a kernel és annak összetevői, amelyek a hardvert vezérlik és az összes folyamatot irányítják. Az “operációs rendszer” kifejezést azonban szokás lazábban használni, hogy a különböző programok egész csoportját jelölje, amelyek azt a szoftverkörnyezetet alkotják, ahol a felhasználó az alapvető számítási feladatokat elvégezheti. |
Az operációs rendszer inicializálása akkor kezdődik, amikor a bootloader betölti a kernelt a RAM-ba. Ezután a kernel átveszi a CPU-t, és elkezdi felismerni és beállítani az operációs rendszer alapvető beállításait, például az alapvető hardverkonfigurációt és a memóriacímzést.
A kernel ezután megnyitja az initramfs-t (inicial RAM filesystem). Az initramfs egy olyan archívum, amely egy olyan fájlrendszert tartalmaz, amelyet a rendszerindítás során ideiglenes gyökérfájlrendszerként használ. Az initramfs fájl fő célja a szükséges modulok biztosítása, hogy a kernel hozzáférhessen az operációs rendszer “valódi” gyökérfájlrendszeréhez.
Amint a root fájlrendszer elérhetővé válik, a kernel csatlakoztatja az összes, az /etc/fstab'-ban konfigurált fájlrendszert, majd végrehajtja az első programot, az `init
nevű segédprogramot. Az init
program felelős az összes inicializáló szkript és rendszerdaemon futtatásáért. Az ilyen rendszerindítóknak a hagyományos init mellett külön implementációi vannak, mint például a systemd és az Upstart. Az init program betöltése után az initramfs eltávolításra kerül a RAM-ból.
- SysV standard
-
A SysVinit szabványon alapuló szolgáltatáskezelő a runlevels (futtatási szintek) fogalmával szabályozza, hogy mely daemonok és erőforrások lesznek elérhetőek. A futási szintek számozása 0-tól 6-ig terjed és a disztribúció karbantartói tervezték meg őket, úgy, hogy meghatározott célokat szolgáljanak. Az egyetlen, minden disztribúcióban közös runlevel definíciók a 0, 1 és 6-os futtatási szintek.
- systemd
-
A systemd egy modern rendszer- és szolgáltatáskezelő, amely kompatibilitási réteggel rendelkezik a SysV parancsokhoz és futtatási szintekhez. A systemd egyidejű struktúrával rendelkezik, socketeket és D-Bus-t használ a szolgáltatások aktiválásához, igény szerinti daemonfuttatást, folyamatfelügyeletet cgroups segítségével, snapshot-támogatást, rendszermunkamenet-helyreállítást, csatolási pont ellenőrzést és függőségi alapú szolgáltatás-ellenőrzést. Az elmúlt években a legtöbb nagyobb Linux-disztribúció fokozatosan átvette a systemd-t alapértelmezett rendszerkezelőként.
- Upstart
-
A systemd-hez hasonlóan az Upstart is az init helyettesítője. Az Upstart középpontjában a rendszerindítási folyamat felgyorsítása áll a rendszerszolgáltatások betöltési folyamatának párhuzamosításával. Az Upstartot az Ubuntu alapú disztribúciók használták a korábbi kiadásokban, de mára átadta helyét a systemd-nek.
Az inicializálás ellenőrzése
A rendszerindítás során előfordulhatnak hibák, de ezek nem feltétlenül olyan kritikusak, hogy teljesen leállítsák az operációs rendszert. Ettől függetlenül ezek a hibák veszélyeztethetik a rendszer elvárt viselkedését. Minden hiba olyan üzeneteket eredményez, amelyek felhasználhatók a későbbi vizsgálatokhoz, mivel értékes információkat tartalmaznak arról, hogy mikor és hogyan következett be a hiba. Még ha nem is keletkeznek hibaüzenetek, a rendszerindítási folyamat során gyűjtött információk hasznosak lehetnek finomhangolási és konfigurációs célokra.
A memóriaterületet, ahol a kernel az üzeneteit tárolja, beleértve a boot-üzeneteket is, kernel ring buffer-nek nevezik. Az üzenetek akkor is a kernel gyűrűpufferben maradnak, ha az inicializálási folyamat során nem jelennek meg, például ha helyette egy animáció jelenik meg. A kernel gyűrűpuffer azonban elveszíti az összes üzenetet, amikor a rendszert kikapcsoljuk, vagy a dmesg --clear
parancs végrehajtásákor. Kapcsolók nélkül a dmesg
parancs megjeleníti a kernel gyűrűpufferben lévő aktuális üzeneteket:
$ dmesg [ 5.262389] EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null) [ 5.449712] ip_tables: (C) 2000-2006 Netfilter Core Team [ 5.460286] systemd[1]: systemd 237 running in system mode. [ 5.480138] systemd[1]: Detected architecture x86-64. [ 5.481767] systemd[1]: Set hostname to <torre>. [ 5.636607] systemd[1]: Reached target User and Group Name Lookups. [ 5.636866] systemd[1]: Created slice System Slice. [ 5.637000] systemd[1]: Listening on Journal Audit Socket. [ 5.637085] systemd[1]: Listening on Journal Socket. [ 5.637827] systemd[1]: Mounting POSIX Message Queue File System... [ 5.638639] systemd[1]: Started Read required files in advance. [ 5.641661] systemd[1]: Starting Load Kernel Modules... [ 5.661672] EXT4-fs (sda1): re-mounted. Opts: errors=remount-ro [ 5.694322] lp: driver loaded but no devices found [ 5.702609] ppdev: user-space parallel port driver [ 5.705384] parport_pc 00:02: reported by Plug and Play ACPI [ 5.705468] parport0: PC-style at 0x378 (0x778), irq 7, dma 3 [PCSPP,TRISTATE,COMPAT,EPP,ECP,DMA] [ 5.800146] lp0: using parport0 (interrupt-driven). [ 5.897421] systemd-journald[352]: Received request to flush runtime journal from PID 1
A dmesg
kimenete több száz sor hosszú is lehet, ezért az előző felsorolás csak azt a kivonatot tartalmazza, amely a kernel systemd szolgáltatáskezelő hívását jeleníti meg. A sorok elején lévő értékek a kernel betöltésének kezdetéhez viszonyított másodpercek számát jelentik.
A systemd alapú rendszerekben a journalctl
parancs megjeleníti az inicializálási üzeneteket a -b
, --boot
, -k
vagy --dmesg
opciókkal. A journalctl --list-boots
parancs megjeleníti az aktuális boothoz viszonyított boot-számok listáját, az azonosító hash-üket és az első és utolsó üzenet időbélyegét:
$ journalctl --list-boots -4 9e5b3eb4952845208b841ad4dbefa1a6 Thu 2019-10-03 13:39:23 -03—Thu 2019-10-03 13:40:30 -03 -3 9e3d79955535430aa43baa17758f40fa Thu 2019-10-03 13:41:15 -03—Thu 2019-10-03 14:56:19 -03 -2 17672d8851694e6c9bb102df7355452c Thu 2019-10-03 14:56:57 -03—Thu 2019-10-03 19:27:16 -03 -1 55c0d9439bfb4e85a20a62776d0dbb4d Thu 2019-10-03 19:27:53 -03—Fri 2019-10-04 00:28:47 -03 0 08fbbebd9f964a74b8a02bb27b200622 Fri 2019-10-04 00:31:01 -03—Fri 2019-10-04 10:17:01 -03
A régebbi inicializálási logok a systemd-alapú rendszerekben is megmaradnak, így a korábbi operációs rendszer munkamenet-üzenetei továbbra is ellenőrizhetők. Ha a -b 0
vagy --boot=0
opciókat adjuk meg, akkor az aktuális rendszerindításhoz tartozó üzenetek jelennek meg. A -b -1
vagy --boot=-1
opciók az előző inicializálás üzeneteit mutatják. A -b -2
vagy --boot=-2
opciók az azt megelőző inicializálás üzeneteit mutatják, és így tovább. A következő részlet azt jeleníti meg, hogy a kernel az utolsó inicializálási folyamathoz hívja a systemd szolgáltatáskezelőt:
$ journalctl -b 0 oct 04 00:31:01 ubuntu-host kernel: EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null) oct 04 00:31:01 ubuntu-host kernel: ip_tables: (C) 2000-2006 Netfilter Core Team oct 04 00:31:01 ubuntu-host systemd[1]: systemd 237 running in system mode. oct 04 00:31:01 ubuntu-host systemd[1]: Detected architecture x86-64. oct 04 00:31:01 ubuntu-host systemd[1]: Set hostname to <torre>. oct 04 00:31:01 ubuntu-host systemd[1]: Reached target User and Group Name Lookups. oct 04 00:31:01 ubuntu-host systemd[1]: Created slice System Slice. oct 04 00:31:01 ubuntu-host systemd[1]: Listening on Journal Audit Socket. oct 04 00:31:01 ubuntu-host systemd[1]: Listening on Journal Socket. oct 04 00:31:01 ubuntu-host systemd[1]: Mounting POSIX Message Queue File System... oct 04 00:31:01 ubuntu-host systemd[1]: Started Read required files in advance. oct 04 00:31:01 ubuntu-host systemd[1]: Starting Load Kernel Modules... oct 04 00:31:01 ubuntu-host kernel: EXT4-fs (sda1): re-mounted. Opts: commit=300,barrier=0,errors=remount-ro oct 04 00:31:01 ubuntu-host kernel: lp: driver loaded but no devices found oct 04 00:31:01 ubuntu-host kernel: ppdev: user-space parallel port driver oct 04 00:31:01 ubuntu-host kernel: parport_pc 00:02: reported by Plug and Play ACPI oct 04 00:31:01 ubuntu-host kernel: parport0: PC-style at 0x378 (0x778), irq 7, dma 3 [PCSPP,TRISTATE,COMPAT,EPP,ECP,DMA] oct 04 00:31:01 ubuntu-host kernel: lp0: using parport0 (interrupt-driven). oct 04 00:31:01 ubuntu-host systemd-journald[352]: Journal started oct 04 00:31:01 ubuntu-host systemd-journald[352]: Runtime journal (/run/log/journal/abb765408f3741ae9519ab3b96063a15) is 4.9M, max 39.4M, 34.5M free. oct 04 00:31:01 ubuntu-host systemd-modules-load[335]: Inserted module 'lp' oct 04 00:31:01 ubuntu-host systemd-modules-load[335]: Inserted module 'ppdev' oct 04 00:31:01 ubuntu-host systemd-modules-load[335]: Inserted module 'parport_pc' oct 04 00:31:01 ubuntu-host systemd[1]: Starting Flush Journal to Persistent Storage...
Az operációs rendszer által kiadott inicializálási és egyéb üzeneteket a /var/log/
mappában található fájlokban tárolja. Ha kritikus hiba történik, és az operációs rendszer a kernel és az initramfs betöltése után nem tudja folytatni az inicializálási folyamatot, akkor egy alternatív boot mediumot lehet használni a rendszer indítására és a megfelelő fájlrendszer elérésére. Ezután a /var/log/
alatt található fájlokat át lehet kutatni a rendszerindítási folyamat megszakadását okozó lehetséges okok után. A journalctl
parancs -D
vagy --directory
opcióival a /var/log/journal/
mappán kívüli mappákban lévő logüzenetek olvashatók, ami a systemd naplóüzenetek alapértelmezett helye. Mivel a systemd logüzenetei nem nyers szövegben vannak tárolva, a journalctl
parancsra van szükség a beolvasásukhoz.
Gyakorló feladatok
-
Egy BIOS firmware-rel ellátott gépen hol található a bootstrap bináris állomány?
-
Az UEFI firmware támogatja a külső programok, az úgynevezett EFI-alkalmazások által biztosított kibővített funkciókat. Ezeknek az alkalmazásoknak azonban saját speciális helyük van. Hol helyezkednek el a rendszerben az EFI-alkalmazások?
-
A bootloaderek lehetővé teszik az egyéni kernel paraméterek átadását a betöltés előtt. Tegyük fel, hogy a rendszer nem tud elindulni a gyökérfájlrendszer helyének téves tájékoztatása miatt. Hogyan lehetne a helyes root fájlrendszert, amely a
/dev/sda3
címen található, paraméterként megadni a kernelnek? -
A Linux boot folyamata a következő üzenettel végződik:
ALERT! /dev/sda3 does not exist. Dropping to a shell!
Mi a probléma legvalószínűbb oka?
Gondolkodtató feladatok
-
A bootloader megjeleníti az operációs rendszerek listáját, amelyek közül választhatunk, ha egynél több operációs rendszer van telepítve a gépre. Egy újonnan telepített operációs rendszer azonban felülírhatja a merevlemez MBR-jét, ami törli a bootloader első szakaszát, és a másik operációs rendszert elérhetetlenné teszi. Miért nem történhet ez meg egy UEFI firmware-es gépen?
-
Mi a gyakori következménye annak, ha egy egyéni kernelt úgy telepítünk, hogy nem adunk meg megfelelő initramfs imaget?
-
Az inicializálási log több száz sor hosszú, ezért a
dmesg
parancs kimenete gyakran átkerül egy pager parancsba — ilyen például aless
parancs --, az olvasás megkönnyítése érdekében. Melyikdmesg
opció fogja automatikusan oldalszámozni a kimenetet, így nem lesz szükség a pager parancs explicit használatára? -
Egy offline gép teljes fájlrendszerét tartalmazó merevlemezt eltávolítottak és másodlagos meghajtóként egy működő géphez csatlakoztattak. Feltételezve, hogy a csatolási pont a
/mnt/hd
, hogyan lehetne ajournalctl
segítségével megvizsgálni a/mnt/hd/var/log/journal/
címen található logfájlok tartalmát?
Összefoglalás
Ez a lecke egy szabványos Linux rendszer indítási sorrendjét tárgyalja. A Linux-rendszer indítási folyamatának megfelelő ismerete segít megelőzni a hibákat, amelyek miatt a rendszer elérhetetlenné válhat. A lecke a következő témaköröket járja körül:
-
Miben különböznek a BIOS és az UEFI rendszerindítási módszerek.
-
A rendszer tipikus inicializálási fázisai.
-
A rendszerindítási üzenetek helyreállítása.
A tárgyalt parancsok és eljárások a következők voltak:
-
Közös kernel paraméterek.
-
Boot üzenetek olvasására szolgáló parancsok:
dmesg
és ajournalctl
.
Válaszok a gondolkodtató feladatokra
-
Egy BIOS firmware-rel ellátott gépen hol található a bootstrap bináris állomány?
Az első tárolóeszköz MBR-ében, a BIOS konfigurációs segédprogramjában meghatározottak szerint.
-
Az UEFI firmware támogatja a külső programok, az úgynevezett EFI-alkalmazások által biztosított kibővített funkciókat. Ezeknek az alkalmazásoknak azonban saját speciális helyük van. Hol helyezkednek el a rendszerben az EFI-alkalmazások?
Az EFI-alkalmazások az EFI rendszerpartícióban (ESP) tárolódnak, amely bármely kompatibilis fájlrendszerrel (általában FAT32 fájlrendszerrel) rendelkező szabad tárolóblokkban található.
-
A bootloaderek lehetővé teszik az egyéni kernel paraméterek átadását a betöltés előtt. Tegyük fel, hogy a rendszer nem tud elindulni a gyökérfájlrendszer helyének téves tájékoztatása miatt. Hogyan lehetne a helyes root fájlrendszert, amely a
/dev/sda3
címen található, paraméterként megadni a kernelnek?A
root
paramétert kell használni, mint példáulroot=/dev/sda3
. -
A Linux boot folyamata a következő üzenettel végződik:
ALERT! /dev/sda3 does not exist. Dropping to a shell!
Mi a probléma legvalószínűbb oka?
A kernel nem találta a root fájlrendszerként feltüntetett
/dev/sda3
eszközt.
Válaszok a gondolkodtató feladatokra
-
A bootloader megjeleníti az operációs rendszerek listáját, amelyek közül választhatunk, ha egynél több operációs rendszer van telepítve a gépre. Egy újonnan telepített operációs rendszer azonban felülírhatja a merevlemez MBR-jét, ami törli a bootloader első szakaszát, és a másik operációs rendszert elérhetetlenné teszi. Miért nem történhet ez meg egy UEFI firmware-es gépen?
Az UEFI-s számítógépek nem használják a merevlemez MBR-jét a bootloader első szakaszának tárolására.
-
Mi a gyakori következménye annak, ha egy egyéni kernelt úgy telepítünk, hogy nem adunk meg megfelelő initramfs imaget?
A root fájlrendszer elérhetetlenné válhat, ha a típusát külső kernelmodulként fordították le.
-
Az inicializálási log több száz sor hosszú, ezért a
dmesg
parancs kimenete gyakran átkerül egy pager parancsba — ilyen például aless
parancs --, az olvasás megkönnyítése érdekében. Melyikdmesg
opció fogja automatikusan oldalszámozni a kimenetet, így nem lesz szükség a lapozó parancs explicit használatára?A
dmesg -H
vagy admesg --human
parancsok alapértelmezetté teszik a lapozást. -
Egy offline gép teljes fájlrendszerét tartalmazó merevlemezt eltávolítottak és másodlagos meghajtóként egy működő géphez csatlakoztattak. Feltételezve, hogy a csatolási pont a
/mnt/hd
, hogyan lehetne ajournalctl
segítségével megvizsgálni a/mnt/hd/var/log/journal/
címen található logfájlok tartalmát?A
journalctl -D /mnt/hd/var/log/journal
vagy ajournalctl --directory=/mnt/hd/var/log/journal
parancsokkal.