Arch boot process (Bosanski)

From ArchWiki
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.

Da bi se mogao bootati Arch Linux, potrebno je podesiti boot loader koji zna raditi sa Linuxom. Boot loader je odgovoran za učitavanje kernela i inicijalnog ramdiska prije započinjanja boot procesa. Procedura se razlikuje za BIOS i UEFI sisteme, detaljne instrukcije su date na ovoj ili na linkovanim stranicama.

Firmware tipovi

BIOS

BIOS ili Basic Input-Output System (Osnovni ulazno-izlazni sistem) je prvi program(firmware) koji se pokreće kada se sistem uključi. U većini slučajeva, smješten je u flash memorije na matičnoj ploči i nezavisan od sistemskog skladišta.

UEFI

Unified Extensible Firmware Interface ima podršku za čitanje tabele particija kao i fajl sistema. UEFI ne pokreće nikakav boot kode iz Master Boot Recorda-a (MBR) bilo da on postoji ili ne, umjesto toga bootanje se oslanja na boot entry-e unutar NVRAM-a.

UEFI specifikacije obavezuju podršku za FAT12, FAT16 i FAT32 fajl sisteme (vidi UEFI specifikacija verzija 2.8, sekcija 13.3.1.1)), ali drugi vendori mogu dodati podršku za dodatne fajl sisteme; npr, Apple Mac podržava (i po defaultu koriste) svoje HFS+ fajl sistem drivere. UEFI implementacija također podržava ISO-9660 za optičke diskove.

UEFI pokreće EFI aplikacija, npr boot loadere, boot menadžere, UEFI shell-ove itd. Ove aplikacije su obično spašene kao fajlovi u EFI sistemskoj particiji. Svaki vendor može spasiti svoje fajlove u EFI sistemsku particiju pod /EFI/vendor_naziv folderom. Aplikacija može biti pokrenuta dodavanjem boot entry-a u NVRAM ili iz UEFI shella.

UEFI specifikacija također ima podršku za legacy BIOS bootanje sa svojim [[Compatibility Support Module (CSM) (Modul za podršku kompatibilnosti). Ako je CSM uključen po defaultu, UEFI će generisati CSM boot entry za sve drive-ove. Ako je CSM boot entry odabran da se sistem boota sa njega, UEFI-ov CSM će pokušati da boota sa drive-ovogo MBR bootstrap koda.

Inicijalizacija sistema

Pod BIOS-om

  1. Sistem uključen, power-on self-test (POST) se izvršava.
  2. Nakon POST-a, BIOS inicijalizira potrebni sistemski hardware za bootanje (disk, kontrolere tastature, itd.).
  3. BIOS pokreće prvih 440 bajtova (Master Boot Record-a bootstrap koda) prvog diska u BIOS disk poretku bootanja.
  4. Boot loaderova prva faza je u MBR boot kodu i zatim pokreće drugu fazu (ako je ima) sa:
  5. Aktuelni boot loader je pokrenut.
  6. Boot loader zatim učitava operativni sistem za lančanim učitavanjem ili direktni učivanjem kernela operativnog sistema.

Pod UEFI-om

  1. Sistem uključen, power-on self-test (POST) se izvršava.
  2. UEFI inicijalizira hardware potreban za bootanje.
  3. Firmware čita boot entry-e iz NVRAM-a da zaključi koju EFI aplikaciju da pokrene i odakle (npr. sa kojeg diska i koje particije).
  4. Boot entry može jednostavno biti disk. U ovom slučaju, firmware traži EFI sistemsku particiju na tom disku i pokušava da nađe EFI aplikaciju u fallback boot putanji \EFI\BOOT\BOOTX64.EFI (BOOTIA32.EFI) na sistemima sa IA32 (32-bit) UEFI). Ovako radi bootabilni UEFI removable media.
  5. Firmware pokreće zatim EFI aplikaciju.

Ako je Secure Boot uključen, boot process će verifikovati autentičnost EFI binary-a gledajući potpis.

Note: Neki UEFI sistemi se samo mogu bootati sa fallback boot putanje.

Višestruko bootanje u UEFI-u

Pošto svaki OS ili vendor može održavati svoje fajlove unutar EFI sistemske particija bez da utiče na druge, višestruko bootanje koristeći UEFI postaje stvar pokretanje druge EFI aplikacije koja odgovara boot loaderu toga operativnog sistema. Ovo uklanja potrebu za oslanjanjem na mehanizam lančanog učitavanja jednog boot loadera da se učita drugi OS.

Vidite i Dual boot sa Windowsom.

Boot loader

Boot loader je dio software pokrenut od strane BIOS-a ili UEFI-a. Odgovoran je za učitavanje kernela sa željenim kernel parametrima i inicijalnim RAM diskom bazirano na konfiguracijskim fajlovima. U slučaju UEFI-a, kernel može se direktno pokrenuti od strane UEFI-a koristeći EFI boot stub. Odvojeni boot loader ili boot menadžer može i dalje biti korišten za editovanje kernel parametara prije bootanja.

Note: Učitavanje update-a mikro koda zahtjeva podešavanja konfiguracije boot loadera. [1]

Uporedba feature-a

Tango-view-fullscreen.pngThis article or section needs expansion.Tango-view-fullscreen.png

Reason: Ako je /boot unutar nečega kompleksnijeg nego što je fajl sistem na particiji (npr. LUKS, RAID, LVM), boot loader treba driver i za te slojeve također. (Discuss in Talk:EFI system partition#Preffered mount point for LVM users)
Note:
  • Boot loaderi trebaju samo da podržavaju fajl sistem na kojem se nalaze kernel i initramfs (fajl sistem na kojem je /boot).
  • Pošto je GPT dio UEFI specifikacije, svi UEFI boot loaderi podržavaju GTP diskove. GPT na BIOS sistemima je moguć korištenjem ili "hibridnog bootanja" sa Hybrid MBR ili novijim GPT-only protokolom. Ovaj protokol zna praviti probleme sa određenim BIOS implementacijama; vidite rodsbooks za detalje.
  • Metoda enkripcije spomenuta u podršci za fajl sistem je filesystem-level encryption (Enkripcija na nivou fajl sistema), ne utiče na block-level encryption.
Name Firmware Partition table Multi-boot File systems Notes
BIOS UEFI MBR GPT Btrfs ext4 ReiserFS VFAT XFS
EFISTUB Yes Yes Yes ESP only Kernel preveden u EFI executable da se učita direktno iz UEFI firmware ili iz drugog boot loadera.
Clover emulates UEFI Yes Yes Yes Yes1 No bez enkripcije No Yes No Fork od rEFIt-a modifikovan da pokreće macOS na non-Apple hardware-u.
GRUB Yes Yes Yes Yes Yes bez zstd kompresije Yes Yes Yes Yes Na BIOS/GTP konfiguraciji zahtjeva BIOS boot particiju.
Podržava RAID, LUKS1 i LVM
rEFInd No Yes Yes Yes Yes1 bez: enkripcije, zstd kompresije bez enkripcije bez tail-packing feature-a Yes No Podržava automatsko detektovanje kernela i parametara bez eksplicitne konfiguracije.
Syslinux Yes Parcijalno Yes Yes Parcijalno bez: multi-device volume-a, kompresije, enkripcije bez enkripcije No Yes MBR samo; bez prorijeđenih inode-ova Bez podrške za određene fajl sistem feature. [2]
Boot loader može samo pristupiti fajl sistemu na koji je instaliran.[3]
systemd-boot No Yes Manuelna instalacija samo Yes Yes1 No No No ESP only No Ne može pokrenuti binary-e iz particija mimo ESP.
GRUB Legacy Yes No Yes No Yes No No Yes Yes v4 only Zamijenjen sa GRUB-om.
LILO Yes No Yes No Yes No bez enkripcije Yes Yes Yes Zamijenjen zbog nekih limita (npr. sa Btrfs, GPT, RAID).
  1. A boot menadžer. Može samo pokretati druge EFI aplikacije, npr, Linux kernel image buildan sa CONFIG_EFI_STUB=y i Windows bootmgfw.efi.

Vidite i Uporedba boot loadera.

Kernel

Kernel je jezgro operativnog sistema. Radi na niskom nivou (kernelspace) gdje vrši interakciju između hardware-a na mašini i programa koji koriste hardware da se pokreću. Da se iskoristi CPU efikasno, kernel koristi scheduler da određuje koji task ima prioritet izvršavanja u datom trenutku, te tako kreira iluziju da se više taskova izvršava simultano.

initramfs

Nakon što boot loader učita kernel (Bosanski) i moguće initramfs fajlovu te izvrši kernel, kernel zatim raspakuje initramfs (inicijalni RAM fajl sistem) arhivu u (tada prazan) rootfs (inicijalni root fajl sistem, specifično ramfs ili tmpfs). Prvi ekstraktovani initramfs je onaj koji je ugrađen u kernel binary tokom buildanja kernela, zatim se eventualni drugi initramfs fajlovi ekstraktuju. Što znači da eksterni fajlovi sa istim imenom prepisuju one u ugrađenom initramfs-u. Kernel zatim izvršava /init (u rootfs-u) kao prvi proces. Rani userspace time je započeo.

Arch Linux koristi praznu arhivu kao ugrađeni initramfs (defaultno tokom buildanja Linuxa). Vidite mkinitcpio za više Arch specifičnih informacija o eksternom initramfs-u.

Svrha initramfs-a je da bootstrapa sistem do tačke gdje može da pristupi root fajl sistemu (vidite FHS za detalje). To znači da bilo koji moduli koji su potrebni za uređaje, poput IDE, SCSI, SATA, USB/FW (ako se boota sa eksternog uređaja) moraju se moći učitati iz initramfs-a ako nisu buildani u kernel; nakon što su odgovarajući kernel moduli učitani (eksplicitno koristeći program ili skriptu ili implicitno sa udev-om), boot proces se nastavlja. Iz ovog razloga, initramfs treba samo da sadržava module potrebne za pristup root fajl sistemu; ne treba da ima sve module koji će se koristiti. Većina modula će se kasnije učitati od strane udev-a, tokom init procesa.later on by udev, during the init process.

init proces

Na zadnjoj fazi ranog userspace-a, stvarni root je mountan i zamjenjuje inicijalni root fajl sistem. /sbin/init se izvršava, zamjenjujući /init proces. Arch koristi systemd kao defaultni init.

getty

init poziva getty jednom za svaki virtualni termina (obično 6 ih ima), koji inicijalizira svaki tty i pita za username i lozinku. Nakon što su username i lozinka ukucani, getty ih provjerava gledajući u /etc/passwd i /etc/shadow te zatim poziva login. Alternativno, getty može pokrenuti display menadžera ukoliko postoji na sistemu.

Display menadžer

Display menadžer može biti konfigurisan da zamijenit getty login prompt na tty-u.

Da bi se automatski inicijalizirao display menadžer nakon bootanja, potrebno je manuelno uključiti service unit-e sa systemd-om. Za više informacija vezanih za enablanje i startanje service unit-a, vidite systemd#Using units.

Login

login program započinje sesiju za korisnika tako što podešava environment varijable i pokreće korisnički shell, bazirano na /etc/passwd.

login program prikaziju sadržaj /etc/motd (message of the day) (poruka dana) nakon uspješnog logovanja, prije nego što izvrši shell. To je dobro mjesto za prikazati Uslove korištenja da se podsjete korisnici lokalnih polica ili bilo čega drugog što želite da im kažete.

Shell

Nakon što je korisnički shell pokrenut, obično se pokreće runtime konfiguracijski fajl, poput bashrc prije prikazivanja prompta korisniku. Ako je korisnički account podešen za pokretanje X na loginu, runtime konfiguracijski fajl će pozvati startx ili xinit.

GUI, xinit or wayland

xinit pokreće korisnički xinitrc runtime konfiguracijski fajl, koji obično pokreće window menadžera. Nakon što korisnik završi i izađe iz window menadžera, xinit, startx, shell i login će se izgasiti u ovom redu, vraćajući se na getty.

Vidite i