Fórum Root.cz

Hlavní témata => Software => Téma založeno: asdfg 22. 11. 2018, 10:46:00

Název: Vysvětlení pojmu InitramFS
Přispěvatel: asdfg 22. 11. 2018, 10:46:00
Ahoj,

v provom rade bz som chcel podakovat autorovi za pekny clanok (https://www.root.cz/clanky/kompletne-sifrovany-disk-se-systemem-i-daty-debian/). V druhom rade by som sa chcel opytat na 2 pojmi, ktore boli spomenute, 'RAMDISK' a 'INITRAMFS'.
Samozrejme ze som sa pytal aj stricka googla ale stale mi to nie je uplne jasne.

Ramdisk - Odkazuje do RAM, ktora bola nakonfigurovana tak, aby simulovala hdd. Da sa pristupovat k datam na RAM ako keby boli na realnom hdd. To, ze ked su data ulozene v ram, tak je praca s nimi neporovnatelne rychlejsia ao keby boli ulozene na HDD je mi jasne. Co mi nie je jasne, ako tie data tam 'nakopirujem' resp. skopirejm z ramdisku na real hdd pred vypnutim PC a vseobecne o co ide... Pointa mi uteka... Ako lajk som bol v tom, ze kazda spustena apka, sa ulozi do ram.

INITRAMFS - ma mat nejaky "Kompletny set priecinkov, ktore su na normalnom filesysteme"..."At boot time, the boot loader loads the kernel and the initramfs image into memory and starts the kernel. The kernel checks for the presence of the initramfs and, if found, mounts it as / and runs /init. The init program is typically a shell script. Note that the boot process takes longer, possibly significantly longer, if an initramfs is used." - Mam to chapat tak, ze pri vypinani PC, sa data nejako skompresuju a "ulozia" do toho INITRAMFS? Ktore pri naslednom starte PC kernel hlada, ked najde tento initramfs, tak spusta uz samotny init?

Predom dakujem za vysvetlenie... :)
Název: Re:Vysvětlení pojmu InitramFS
Přispěvatel: Petr Krčmář 22. 11. 2018, 10:57:03
Initramfs (nebo někdy initramdisk) je předem připravený obraz zaváděcího systému na disku. Zavaděč (v Linuux typicky Grub) ho načítá při bootu do paměti společně s jádrem. Je to cesta, jak se společně s jádrem z disku načtou různé utility, skripty a hlavně moduly, které doplňují jádro o ovladače.

Ve zmíněném článku je například kořenový souborový systém uložený na souborovém systému ext4 v LVM v LUKS. Tohle všechno musí umět jádro zpracovat, aby se dostalo k systémovým souborům. Ovladače a skripty k tomu dostane právě v tom ramdisku. Ten se negeneruje při vypínání počítače, nemá nic moc společného s běžícím systémem (není tam uložený jeho stav nebo něco podobného). Je to jen dočasný kořenový systém, který je skripty (mkinitramfs) vytvořen na míru daného systému – právě podle různého hardware, souborových systémů a podobně.

Stačí?
Název: Re:Vysvětlení pojmu InitramFS
Přispěvatel: Pavouk106 22. 11. 2018, 12:27:49
Ramdisk laicky řečeno:

Část RAM se ukrojí (není dostupná běžícím programům) a připojí se (mount) někam jako kdyby to byla například USB flashka. Stejným způsobem jako USB flashku pak ten ramdsik obsluhuješ, tedy přes oblíbený program do něj můžeš kopírovat soubory, pouštět z něj hudbu (když ji tam předtím nahraješ) apod. Tváří se prostě a jednoduše jako další z připojených úložných zařízení.

Má ale od ostatních opravdových (SSD/flash/hard) disků jednu podstanou nevýhodu - při přerušení napájení (výpadek elektřiny nebo vypnutí počítače) se obsah ramdisku vymaže (je to pořád RAM).

Nejde tedy o zpřístupnění obsahu RAM (jakožto věcí, který si tam strkají jednotlivý programy).

Já osobně používám ramdisk (resp. tmpfs) na Raspberry Pi pro ukládání logů. Sice se mi neukládají pro offline analýzu, ale zase mi pak RPi nezapisuje na karty zbytečně = neopotřebovávají se (tolik). Mohl bych si třeba napsat skript, aby se při běžnym vypnutí nebo restartu (tedy ne při výpadku elektřiny, to se pak nic udělat nedá) ty logy přesunuly z RAM na kartu, ale zatím jsem neměl potřebu to řešit.
Název: Re:Vysvětlení pojmu InitramFS
Přispěvatel: ByCzech 22. 11. 2018, 13:13:20
INITRAMFS - ... - Mam to chapat tak, ze pri vypinani PC, sa data nejako skompresuju a "ulozia" do toho INITRAMFS? Ktore pri naslednom starte PC kernel hlada, ked najde tento initramfs, tak spusta uz samotny init?

Kromě výše uvedeného od kolegů, dodám k tomuto:

Při vypínání PC se nic nekomprimuje a neukládá do initrd. Obraz initrd se vytváří typicky při aktualizaci/instalaci jádra, či při instalaci/odinstalaci něčeho, co se do initrd přidává, třeba plymouth, firmware, dkms ovladače ap. nebo při ruční aktualizaci, když k tomu je důvod (např. změněná konfigurace něčeho co sídlí (i) v initrd). Tento zkomprimovaný initrd/initramfs je soubor v /boot, pro každé konkrétní jádro jeden (pokud jádro pro start OS initrd potřebuje). Při vypínání se initrd nevytváří/nepřepisuje, protože už na disku je připravený jeho obraz pro další start. Soubor s jádrem se také nepřepisuje při vypínání. Prostě se při každém bootu PC pomocí zavaděče (např. Grub, Loadlin, Syslinux, LILO, ap.) načte jádro a obraz initrd, rozbalí se do paměti a spustí se jádro, kterému se předá informace o initramfs v paměti, ze kterého pak jádro pouští init a ten pak další věci, které vedou k úspěšnému startu OS (zavedení potřebných kernelových modulů, vyhledání root device, připojení a přepnutí startu na něj...).
Název: Re:Vysvětlení pojmu InitramFS
Přispěvatel: Ondrej Nemecek 22. 11. 2018, 18:04:37
Předřečníci mají samozřejmě pravdu, ale je to poměrně složitě popsáno. Já bych to napsal takto:

INITRAMFS - virtuální disk, kde je uložené vše, co jádro operačního systému potřebuje před načtením normálního disku. Typicky tam jsou ovladače a skripty potřebné právě pro načtení toho normálního disku (ovladač řadiče, souborového systému, síťový ovladač - pokud je disk přístupný po síti apod.). Pokud by jádro mělo všechny ovladače už v sobě, mohlo by fázi s INITRAMFS přeskočit a nastartovat rovnou z běžného pevného disku.

RAMDISK - způsob, jak ten virtuální disk v RAM vytvořit (ramdisk má uplatnění nejen při startu systému).

Start systému pak probíhá přibližně takto:


Zbývá vysvětlit, jak jádro systému nastartuje, když ještě nemá ovladač souborového systému? Je to jednoduché, načte se bit po bitu z předem známého místa na disku, které to je místo ví zavaděč jádra (v linuxu nejčastěji grub). Stejným způsobem se načte i initramfs.

Většina distrubucí INITRAMFS používá, ale přiznám se, že nevím  přesně proč (asi aby mohla být většina ovladačů kompilována jako zaveditelné moduly a aby byl jednotný způsob bootu i pro bezdiskové stanice).
Název: Re:Vysvětlení pojmu InitramFS
Přispěvatel: RDa 22. 11. 2018, 18:35:34
Start systému pak probíhá přibližně takto:
  • naběhne jádro
  • načte initramfs
  • zpracuje skripty v initramfs
  • připojí běžný disk
  • pokračuje ve startu systému už z běžného disku (spustí služby, zapne grafické rozhraní apod.).

Takhle fakt ne. Start linuxu probiha tim, ze se z disku nacte jadro (kernel) a volitelne initramfs/intird, pripadne na embedded platformach device tree (dtb), pak zavadec (lilo/grub) preda rizeni do kernelu, ktery se v prvni fazi rozbali a pak spusti. Po te co kernel provede svou inicializaci a vsech periferii ci driveru ktere ma zakompilovane, se pristoupi k predani rizeni do init procesu z rootfs (existuje nekolik variant jak se init musi jmenovat), ktery v pripade existence initramfs/initrd se nachazi jiz v pameti - resp. v pripade initramfs se jedna o cpio archiv, ktery se rozbaluje do ramfs, v pripade initrd se jedna o image particie zformatovane filesystemem ktery podporuje kernel (napr. ext2/3/4). V analogii s instrukcema procesoru se jedna o takovy "immediate operand", rootfs je proste predem dan.

A co provedou skripty v initramfs/initrd je jiz zcela na nich. Muze to byt primo nejaka instalace jez se provozuje bez disku (nejcasteji embedded, s flash do ktere se nikdy nezapisuje = po kazdem zapnuti mate stejny bezici system, treba kamery, fotaky, televize a jine jednoucelove krabicky zalozene na linuxu), nebo to muzou byt jen pomocne skripty, ktera zajistit pristup na jiny filesystem (sitovy, sifrovany, kombo z RO cdrom + rw RAM, atd) a po splneni sveho ukolu rizeni deleguji pak do dalsiho programu.

Ad RAMDISK - primo jako blokove zarizeni se snad uz ani nepouziva v modernim linuxu, nahrazuje to ramfs, resp. tmpfs. Je to temer to same, jen tmpfs ma limit na kapacitu. Typicky je tmpfs pouzito pro /dev/shm
Název: Re:Vysvětlení pojmu InitramFS
Přispěvatel: František Ryšánek 22. 11. 2018, 18:40:44
...taky si přisadím, do téhle přátelské debaty nad draním peří:

Boot linuxu začíná zhruba tím, že bootloader loadne do RAMky jádro a spustí ho (skočí na nějakou startovní adresu). Tohle natažení jádra do RAMky se děje sice z disku, ale ještě pomocí služeb BIOSu - tzn. "ovladačem diskového řadiče" je vlastně podpora tohoto hardwaru zabudovaná v BIOSu. Proto to funguje jednak z onboard IDE/SATA řadičů, jednak z USB flashek (i pro boot z těchto zařízení musí být podpora v BIOSu), jednak z přídavných karet, třeba SCSI/SAS apod., které si nesou ssebou svůj vlastní modul do BIOSu (tzv. "option ROM"). Podpora disků v BIOSu je primitivní, není příliš výkonná = není vhodná pro trvalý běh OS, ale pro natažení kernelu postačí.

Start jádra podle mého cca končí tím, že se jádro pokusí "mountnout kořenový svazek" (root) - což činí už prostřednicvím svých vlastních ovladačů pro diskové řadiče, které se budou za běhu naostro používat.
Tzn. ovladač diskového řadiče, potřebný pro kořenový svazek, musel nastartovat někde mezi odskokem z bootloaderu a mountem rootu - v době, kdy ještě nejsou přimountované žádné svazky a neběží žádné user-space procesy.
Jinými slovy, ovladač pro diskový řadič, skrz který se má jádro dostat ke kořenovému svazku, musí být v kernelu zakompilovaný monoliticky. Jako modul uložený na kořenovém svazku v /lib/modules by byl jádru platný jak žábě gumovky, protože brejle se bez brejlí těžko hledají, jak praví Mach a Šebestová.

Problém obecně je, že různých modelů čipů diskových řadičů je spousta. Na domácím počítači Vám to tak třeba nepřipadá, protože přece bootujete vždycky z nějakého SATA zařízení na onboard SATA řadiči, který je v dnešní době nejspíš od Intelu (ano rejpu naschvál do tábora AMD). Ten jeden-dva ovladače by snad kernel monoliticky pobral? Představte si, že byly doby, kdy PC čipsety vyrábělo třeba 5 a více firem. A základní legacy IDE sice bylo nějak kompatibilní, ale s příchodem SATA vzala kompatibilita do značné míry zasvé (čest výjimkám, kde se SATA řadič uměl tvářit jako prastaré generické IDE). Kromě toho Linux je dodnes doména spíš serverů, a v tomhle prostředí je kupodivu spousta nepochopitelných fajnšmekrů, kteří chtějí bootovat ze SCSI, různých RAIDů, FibreChannel SANů apod. Takže prostě těch ovladačů jsou ve zdrojákách jádra k dispozici obecně desítky. Binární bootovatelný image jádra bez diskových ovladačů může mít třeba nízké jednotky MB, s dvaceti základními ovladači jste snadno na dvoj- až trojnásobku. (V dnešní době pořád legrace, ale prosím abstrahujme od toho.)

Chci říct, že je docela velká a rozumná motivace, nemít monoliticky v kernelu všecky diskové ovladače, kolik jich jenom pánbůh stvořil.

A přesně proto vznikl "initial RAMdisk". Kernel nemountuje přímo finální kořenový svazek. Přibyl mezikrok, kdy kernel napřed mountne dočasný root FS právě z RAMdisku. Potřebuje tedy ovladač pouze pro RAMdisk - jistě triviální. A potřebný ovladač pro skutečný diskový řadič už si dotáhne z RAMdisku. Následně může skript běžící z initial RAMdisku remountnout root na finální fyzický oddíl a spustit plnohodnotný $INIT (dosaďte si každý svou pohanskou modlu). A pokračuje plnohodnotný user-space boot.

Aby byl initial RAMdisk k dispozici a zabydlený dřív, než se mountnou fyzické disky, musí se o jeho vytvoření postarat bootloader (Grub, LILO, Syslinux, PXElinux, ISOlinux, RedBoot, Uboot...). Proto v konfiguraci bootloaderu vidíte tradičně dva řádky těsně za sebou: kernel, a initrd.

Kdysi dávno, snad v minulém století, neměl jsem rád initrd. Připadal mi neprůhledný a nepřehledný. Byl jsem radši, když kernel mountoval rovnou konečný root device. Takhle "přímo" totiž kdysi první distra startovala zcela normálně. Abych toho dosáhl, kompiloval jsem si svůj vlastní kernel, ve kterém jsem potřebný ovladač pro můj konkrétní diskový řadič zakompiloval monoliticky.

Už mnoho let je tomu, co jsem si zvykl na "neprůhlednost" initial RAMdisku, naučil jsem se těch pár zaklínadel, pochopil jsem základní principy fungování a odhadl mantinely... a nakonec mi vyhovuje boot skrz initrd. Distro mi tu vypolstrovanou samotku hezky nastele a navoní, takže když nedělám vylomeniny, je ta nevědomost nakonec docela pohodlná. Znám zhruba obrysy, jak to funguje, a pod kapotu už koukat nepotřebuju.

Prvotní podobu initrd připraví instalátor (ať už standardní CDčkový apod., nebo třeba debootstrap) a jednou z jeho základních povinností je, aby už v této počáteční podobě initrd byl přítomen driver pro diskový řadič, ze kterého tento konkrétní stroj bude bootovat. Tzn. ani v initial RAMdisku nejsou *všechny* ovladače, ale jenom ten, který je pro daný počítač potřeba. Případně pokud jste hraví, máte svobodu přidat si do initrd všechny ovladače (nejen diskové), které tam chcete mít - třeba protože chcete, aby Linux z tohoto disku byl ochoten nastartovat v mnoha různých počítačích. Jsou na to skripty, třeba v Debianu update-initramfs a jeho konfigurace v /etc/initramfs-tools . Přídavné moduly vyjmenujete v souboru "modules" v tomto adresáři. Existuje také standardní možnost (už v instalátoru), nacpat do do initrd *všechny* ovladače - asi pro lidi, kteří nešetří každým gigabajtem RAMky (a nevadí jim, čekat při startu pár desítek sekund navíc na bootloader).

Pro jistotu podotýkám, že do initrd nemusíte cpát ani všechny moduly, které opravdu potřebujete na daném HW. Třeba modul pro zvukovou kartu nebo síťovky si jádro může natáhnout už z fyzického disku v normální fázi user-space bootu. Schválně se na standardně nainstalovaném linuxu podívejte přes lsmod, co všecko je nataženo jako modul, a pak porovnejte s obsahem /lib/modules v initial RAMdisku (viz níže).

V initrd jsou nějaké další věci... třeba zmíněný Plymouth, který se snaží o bezešvý high-res graphics vzhled od bootloaderu až do Xwindows, nebo hlouběji pod kapotou "udev", protože už velmi základní systémové programy v user space, startující z initial ramdisku, potřebují nějaký minimální obsah adresáře /dev/ (přístup na systémová zařízení). V initrd míval konkrétně udev jenom jakýsi "preloader", plný udevd startoval až po mountnutí finálního rootu.

Popravdě, Linux, po remountnutí rootu z ramdisku na ostrý diskový oddíl, initial RAMdisk dealokuje a uvolní paměť. Dokonce je to ještě trochu složitější (https://mchehab.fedorapeople.org/kernel_docs/admin-guide/initrd.html) (kdo chce, ať si počte). Prostě initial RAMdisk se za normálních okolností zřejmě nedožije ani konce kompletního user-space bootu :-) Je potřeba jenom pro rané fáze user-space bootu a když splní svou úlohu, tak po něm už pes neštěkne.

Jak už psali ostatní, jednou vytvořený obraz initrd leží v souboru pod /boot/ a při běžném rebootu do něj distro nijak nezasahuje, neukládá se do něj žádný "stav". Mění se pouze při změně konfigurace věcí v initrd.

Co je to vlastně za formát / souborový systém? Osobně jsem v nějaké své volné tvorbě kdysi používal obrazy RAMdisku ve formátu ext2 nebo minix, kernel si s nimi dodnes automaticky poradí (pokud má pro tyto fs ovladače). Takový obraz se dá klasicky mountnout ze souboru s argumentem "-o loop". Ovšem moderní distra tuším dodnes (už dlouhá desetiletí) používají initrd ve formátu .cpio.gz. V podstatě soubory poskládané za sebou a sbalené gzipem (nebo čím vlastně), při bootu z toho kernel tuším udělá nastojato tmpfs. Chcete-li si prohlédnout adresářovou strukturu initial RAMdisku, zkopírujte si ho někam bokem (nebo na něj udělejte symlink) a přidejte mu příponu ".cpio.gz". V této podobě do něj ochotně vleze "mc" a můžete se v něm brouzdat v read-only režimu.

To že každá verze image kernelu v /boot/ má k sobě svou vlastní verzi image initrd je dáno tím, že v daném imagi initrd jsou obsažené pouze moduly=drivery pro kýženou verzi kernelu. Opět kvůli tomu, aby nebylo třeba loadovat při bootu spoustu balastu (/lib/modules s verzemi modulů pro všechny kernely instalované na fyzickém disku v daném systému).

Závěrem nostalgická vzpomínka: v dobách, kdy se hra pro DOS vešla na disketu, ale počítače už měly třeba 4 MB RAM, kterou hry běžně celou neupotřebily, zato hra občas padla zpátky do DOSu, nebo bylo třeba kvůli loadnutí uložené pozice hru restartovat (civilizace?), dávalo velmi dobrý smysl, mít nakonfigurovanou buď velikou cache v RAMce, nebo právě RAMdisk (a hru do něj nakopírovat). Restart her v RAMdisku byl okamžitý :-) Tuším jsem to párkrát použil i v dobách, kdy 100MB HDD měl přenosovou rychlost asi 600 kBps...
Název: Re:Vysvětlení pojmu InitramFS
Přispěvatel: Ondrej Nemecek 22. 11. 2018, 20:15:59
Start systému pak probíhá přibližně takto:
  • naběhne jádro
  • načte initramfs
  • zpracuje skripty v initramfs
  • připojí běžný disk
  • pokračuje ve startu systému už z běžného disku (spustí služby, zapne grafické rozhraní apod.).
Takhle fakt ne. (...)

Co „fakt ne“? Snažil jsem se zjednodušeně popsat to, co vy popisujete detailně. Princip jsem tím myslím nezamlžil (a jak to funguje vím detailně - naučil jsem se to díky dlouhodobému používání Linux from scratch, akorát je to už nějaký pátek zpět, takže modernější technologie tolik neznám).
Název: Re:Vysvětlení pojmu InitramFS
Přispěvatel: RDa 22. 11. 2018, 22:29:10
Co „fakt ne“? Snažil jsem se zjednodušeně popsat to, co vy popisujete detailně. Princip jsem tím myslím nezamlžil (a jak to funguje vím detailně - naučil jsem se to díky dlouhodobému používání Linux from scratch, akorát je to už nějaký pátek zpět, takže modernější technologie tolik neznám).

(cislovani dle vasich bodu zachovano)

1. jadro nenabehne pred nactenim initramfs
2. initramfs nenacita z disku jadro ale jiz bootloader pred startem jadra
3. jadro nezpracuje skripty v initramfs - skripty jsou vlastni procesy a bezi sami, naopak vyuzivajic sluzby jadra
4. jadro nepripoji disk, o to se postaraji skripty v initramfs
5. i initramfs muze poustet sluzby, zejmena ty sitove pokud se jedna o sitovou instalaci daneho OS

Jo.. vsude se neco najde a LFS neni zarukou toho, ze tomu rozumite. Treba Gentoo ma v initrd kompletni shell / ultra osekane distro na bazi busyboxu, coz me osobne prislo nekolikrat vhod, kdyz se neco rozbilo a nechtel stroj radne nabootovat. Je to omnoho rychlejsi nez hledat alternativni medium a doufat ze bude kompatibilni s tim co se snazite rozchodit. A taky jestli zvladnete opravu provest prikazy z tohoto mista, tak vam to rovnou odhali i reseni/puvod problemu proc to vlastne nestartovalo.
Název: Re:Vysvětlení pojmu InitramFS
Přispěvatel: Ondrej Nemecek 23. 11. 2018, 02:54:25
Co „fakt ne“? Snažil jsem se zjednodušeně popsat to, co vy popisujete detailně. Princip jsem tím myslím nezamlžil (a jak to funguje vím detailně - naučil jsem se to díky dlouhodobému používání Linux from scratch, akorát je to už nějaký pátek zpět, takže modernější technologie tolik neznám).

(cislovani dle vasich bodu zachovano)

1. jadro nenabehne pred nactenim initramfs
2. initramfs nenacita z disku jadro ale jiz bootloader pred startem jadra
3. jadro nezpracuje skripty v initramfs - skripty jsou vlastni procesy a bezi sami, naopak vyuzivajic sluzby jadra
4. jadro nepripoji disk, o to se postaraji skripty v initramfs
5. i initramfs muze poustet sluzby, zejmena ty sitove pokud se jedna o sitovou instalaci daneho OS
(...)

Až na to že ten podnět „jádro“ jste si tam domyslel sám. Jako laické vysvětlení to je myslím dostačující a pro seriózní debatu bychom stejně museli přesně definovat pojmy (co je „načtení“ a jaké má fáze, co je „zpracování“ a kterak se provádí, jak probíhá „připojení“ souborového systému atd.), jinak by ta debata postrádala zcela smysl (vždyť bez dalšího vysvětlení nejsou ani Vaše připomínky přesné). Mě šlo o pořadí těch fází a na víc jsem si ani nečinil nárok. Proto jsem psal „zjednodušeně“. Máte samozřejmě plnou svobodu to upřesnit, pokud myslíte že je můj příspěvek zavádějící.
Název: Re:Vysvětlení pojmu InitramFS
Přispěvatel: asdfg 23. 11. 2018, 10:31:37
Tak pokial som vas aspon trosku pochopil, tak pri boote, boot loader nacita kernel spolu s initramfs obrazom(ktory je obohateny o zavadzace, jadrove moduly) do pamate ram a nasledne spusti kernel. Kernel skontroluje pritomnost initramfs a ak ho najde, moutne ako / (uz priamo na disk alebo este len do ramdsiku(myslim tym ten ramfs/tmpfs)?) a nasledne spusti /sbin/init, ktory pusta init scripty?

Len bohuzial, stale nerozumiem pojmu 'predom priraveny obraz zavadzacieho systemu na disk'. Stale som nejako v tom, ze ovladace, moduli su priamo v jadre... Preto odpadava nutnosti instalovat ovladace oproti win... A aj ked nahravam nejake moduli do jadra, napr. conntrack modul, nenahravam ho do initramfs...

Vsuvka, ked som si skusil tmpfs/ramfs mount -t tmpfs -o size=4096m tmpfs /tmp/ramdisk, tak som z utiliyky free ani z htop nevidel, ze by som bol lahsi o 4gb ram pamate... Az pri vystupe z udelatka df som videl, ze /tmp/ramdisk ma 4gb...
Název: Re:Vysvětlení pojmu InitramFS
Přispěvatel: Ravise 23. 11. 2018, 11:46:24
Zavaděč načte z disku jádro a initramfs. Ten initramfs jsou vpodstatě prvotní data, která začne jádro zpracovávat - každý program nejdřív přečte vlastní konfigurák. Initramfs se nachází kdesi v RAM, jádro se tam podívá a tu oblast namountuje do /. Všechno tohle se děje v RAM, jádro zatím nemá ovladače k tomu, aby se dostalo na disk [1]. Ty získá právě z initramfs. Od téhle chvíle jádro vidí na disk, dokáže z něj číst. Initramfs se ukončí, jako / se namountuje disk a nastartuje se sytém z disku - zavedou se další ovladače, spustí se init a tak.

Len bohuzial, stale nerozumiem pojmu 'predom priraveny obraz zavadzacieho systemu na disk'. Stale som nejako v tom, ze ovladace, moduli su priamo v jadre... Preto odpadava nutnosti instalovat ovladace oproti win... A aj ked nahravam nejake moduli do jadra, napr. conntrack modul, nenahravam ho do initramfs...

Instalátor nebo běžící systém ví přesně, na jakém stroji běží a podle toho dokáže initramfs připravit. Do initramfs zahrne ty nutné ovladače, napíše návod jak se dostat na disk. Conntrack se může načíst až z disku. Nic ti samozřejmě nebrání říct si o jeho zahrnutí do initramfs - postup bude popsaný v manuálu tvé distribuce.

[1] Můžeš si zkompilovat jádro na míru a všechny tyhle nezbytný ovladače dát přímo do jádra, potom bys initramfs nepotřeboval. Ale distribuční jádro to udělat nemůže, kdyby mělo jádro pokrýt úplně všechny případy (různé souborové systémy, rozhraní disků, RAID, bootování po síti atd atd), bylo by moc velké.
Název: Re:Vysvětlení pojmu InitramFS
Přispěvatel: . 23. 11. 2018, 11:51:22
Pokud by někdo chtěl jít do větších podrobností a detailů, doporučuji jít rovnou na tuhle knihu: https://0xax.gitbooks.io/linux-insides/Booting/linux-bootstrap-1.html (https://0xax.gitbooks.io/linux-insides/Booting/linux-bootstrap-1.html)
Název: Re:Vysvětlení pojmu InitramFS
Přispěvatel: Diskobolos 23. 11. 2018, 11:55:55
Start systému pak probíhá přibližně takto....
Takhle fakt ne...

1) Autor původní odpovědi použil opravdu slovo přibližně
2) Tazatel se ptal v laickém duchu a takovou dostal i odpověď

Irituje mě, když si někdo neodpustí takovéto zbytěčné rýpání... Jinak za mě +1 František Ryšánek.
Název: Re:Vysvětlení pojmu InitramFS
Přispěvatel: RDa 23. 11. 2018, 12:05:50
Vsuvka, ked som si skusil tmpfs/ramfs mount -t tmpfs -o size=4096m tmpfs /tmp/ramdisk, tak som z utiliyky free ani z htop nevidel, ze by som bol lahsi o 4gb ram pamate... Az pri vystupe z udelatka df som videl, ze /tmp/ramdisk ma 4gb...

ramfs i tmpfs maji "on demand" allocation. Tu pamet si alokuji az v momente ze tam zacnes vytvaret adresare/soubory a hlavne az zacnes do tech souboru nahravat nejaka data. ramfs bude alokovat do aleluja, tmpfs po tech tvych 4096m rekne "no space left"
Název: Re:Vysvětlení pojmu InitramFS
Přispěvatel: RDa 23. 11. 2018, 12:21:13
Tak pokial som vas aspon trosku pochopil, tak pri boote, boot loader nacita kernel spolu s initramfs obrazom(ktory je obohateny o zavadzace, jadrove moduly) do pamate ram a nasledne spusti kernel. Kernel skontroluje pritomnost initramfs a ak ho najde, moutne ako / (uz priamo na disk alebo este len do ramdsiku(myslim tym ten ramfs/tmpfs)?) a nasledne spusti /sbin/init, ktory pusta init scripty?

Len bohuzial, stale nerozumiem pojmu 'predom priraveny obraz zavadzacieho systemu na disk'. Stale som nejako v tom, ze ovladace, moduli su priamo v jadre... Preto odpadava nutnosti instalovat ovladace oproti win... A aj ked nahravam nejake moduli do jadra, napr. conntrack modul, nenahravam ho do initramfs...

Chapes to spravne. Ovladace muzou byt:
1. bud v jadre (soucasti linuxu)
2. nebo out of tree (ovladace tretich stran, typicky priklad: nvidia)
3. pripadne prasacke reseni "nas ovladac je patchem pro jadro verze x.y.z", ktere se uz dnes vidi vyjimecne

Pro body 1 a 3 plati, ze to lze kompilovat jako soucast jadra (compiled-in) nebo jako modul, ktery je v extra souboru. U bodu 2 je to vzdy modul.

Situace pro moduly a initramfs vznikla historicky v dobe, kdy pocitace nemeli moc pameti (rozumej - v dobe 8 az 64 MB). Protoze kod kernelu je v pameti udrzovan vzdy (neni odswapovatelny), tak treba nekolik MB ovladacu, ktere tvuj stroj nevyzaduje znamenalo znacne plytvani tou uz tak malou pameti. Byt initramfs obsahuje tech 10MB, jsou to jen "moznosti" - ze kterych se nakonec pouzivala pro konkretni stroj jen jedna. Pokud mel skript v initramfs detekci hw tak dokazal natahnout konkretni modul, ale casteji se tupe natahlo vsechno a doufalo ze neco zpristupni disk s rootfs. Existence modulu ale umoznovala pozdeji udelat rmmod na ovladace, ktere pouzity nebyly a tak uvolnit pamet. Dnes, v dobe NVMe a AHCI mate tyto dva ovladace rovnou v jadre, tenkrat to byly desitky ruznych ovladacu.

Initramfs tedy resi problem slepice a vejce - na uvolneni pameti skrze rmmod jste ovladace diskovych radicu potreboval mit jako moduly, ale kdyz byly jako moduly, tak uz nebyly soucasti kernelu a nedostal by jste se na rootfs.
Název: Re:Vysvětlení pojmu InitramFS
Přispěvatel: František Ryšánek 24. 11. 2018, 00:12:57
Ravise a RDa už se toho ujali, takže teď budu trochu nosit dříví do lesa...

a nasledne spusti /sbin/init, ktory pusta init scripty?

/sbin/init býval původně kdysi dávno jenom jeden - ten co se spouštěl z přímo mountnutého definitivního kořenového svazku. A máte pravdu, že spuštění initu (procesu s PID=1) skutečně následuje vzápětí po mountnutí rootu.

/sbin/init je především spustitelný program. Díky kernelové autodetekci, o jaký typ spustitelného programu se jedná, nemusí jít nutně o ELFový binár, může to být stejně tak nějaký skript, třeba shellový. Pokud se jedná o skript, správný interpreter se natáhne podle konvence #!/cesta/k/interpreteru na prvním řádku skriptu. Ten "hash a vykřičník" jsou skutečně vypečená finta, a právě na ně se jádro chytá. Pokud se nepletu, tak initial ramdisky takový skript pojmenovaný /sbin/init dříve obsahovaly. Jinak když si zkusíte poskládat bootovatelné "distro" skutečně od nuly, tak první školní příklad je ten, že na budoucí kořenový svazek nakopírujete všechny potřebné knihovny, především libc, a minimální sadu systémových prográmků, především shell, a jméno /sbin/init dáte symlinku na /bin/sh nebo tak něco. (Jasně - nebo na Váš skript.)

V situaci, kdy se mountne na / napřed dočasný initramfs, a až pak finální root, je samozřejmě otázkou, jestli bude /sbin/init jeden, nebo dva... V jednom odkazu co jsem vložil do té předchozí tapety je bootování skrz initrd popsáno včetně toho, že k remountu na finální kořenový svazek se používá syscall pivot_root()... čili někde kolem se zřejmě taky přepřáhne dočasný "init z initial ramdisku" na finální init. Pokud to máte takto zařízeno standardním způsobem. Alternativně by asi šlo, aby ten lehký init nebo init skript, co nastartoval z initrd, spustil "finální velký init" nějak explicitně. Vlastně by na to stačil jediný exec() a finální init by převzal i charakteristický PID=1. Nebo by ten velký init mohl nakonec startovat už přímo z initial RAMdiku? Teoreticky ano, ale tušímže to žádná mainstreamová distribuce takto nedělá... Chcete-li vědět, jak je to doopravdy, klidně se ponořte do zdrojáků své distribuce :-)

Koukám tady v Debianu 9 na /sbin/init jednak na finálním rootu (diskový oddíl),
jednak v initial RAMdisku. V obou "svazcích" skutečně takový soubor existuje.
Na disku se jedná o symlink na systemd, uvnitř initrd se jedná zřejmě o hardlink
(jeden z mnoha) na multifukční ELFový binár busyboxu. Takže nejen Gentoo má v initrd zapečený poloplnohodnotný busybox ;-)

Jo a pokud jde o to, co "init" vlastně dělá: ten skript nebo minimální "přípravátor" v initial RAMdisku skutečně hlavně provede pár skriptů (nějaké ty přípravné práce). Pokud jde o "finální velký init", tak tradiční sysv init volal napřed rc.sysinit, pak snad rc.local, a pak všechny startovací skripty různých služeb/démonů, kteří v systému běží. Systemd má konfiguraci trochu jinou a taky o jeho celkové koncepci by se dalo dlouze debatovat, ale v podstatě se opět jedná především o "service manager".

Len bohuzial, stale nerozumiem pojmu 'predom priraveny obraz zavadzacieho systemu na disk'. Stale som nejako v tom, ze ovladace, moduli su priamo v jadre... Preto odpadava nutnosti instalovat ovladace oproti win... A aj ked nahravam nejake moduli do jadra, napr. conntrack modul, nenahravam ho do initramfs...

Smíchal jste několik rovin :-)

Linux má skutečně pro spoustu hardwaru "ovladače" v tom smyslu, že jsou přítomny v upstream vanilkovém stromě zdrojových kódů (textů, programů v jazyce C) a Linus a jeho pobočníci tyto ovladače dlouhodobě oprašují/udržují kompatibilní s "kernel core" tzn. se základem jádra.

Prvním krokem při kompilaci jádra ze zdrojáků je to, že vlezete např. do "make menuconfig", kde u jednotlivých ovladačů zvolíte, zda se mají přilinkovat k hlavnímu bináru jádra (tzv. "monoliticky") nebo zda se mají slinkovat do podoby externích souborů s příponou .ko, těm se říká "jaderné moduly". Je to obdoba dynamických knihoven v user space. Třetí možnost v menuconfigu je, ovladač z buildu zcela vynechat.

Bývaly kdysi dávno doby, kdy hotové binární jádro (výsledek kompilace) tvořil jediný monolit. Ovladače ke kompilaci se daly jenom povolit/zakázat. Pokud povolit, tak to automaticky znamenalo přilinkování do zmíněného monolitu. V zájmu modularity binárních distribucí (bez potřeby kompilovat jádro pro každý stroj zvlášť) byly poměrně záhy zavedeny "moduly": malé úlomky, které se k monolitu daly za jízdy podle potřeby připojovat (a odpojovat).

Základní binární "monolit" jádra je na disku uložen v /boot/vmlinuz-blablabla-verze. Odtud ho při startu sosá bootloader. Moduly .ko na disku spinkají uložené v /lib/modules/verze/... . Do obrazu initial RAMdisku se nakopírují pouze moduly, které jsou před mountnutím finálního rootu potřeba - což nejsou zdaleka všechny. V dnešních univerzálních desktopových distribucích bývá "distribuční" kernel zkompilovaný prakticky se všemi dostupnými ovladači v modulární podobě (.ko) takže příslušný podadresář v /lib/modules/verze je pěkně košatý a nafouklý. Natáhnout modul z disku do jádra (tzn. vlastně ho "spustit") je možno rukama z příkazového řádku příkazem insmod nebo modprobe. Modprobe je schopen automaticky dotahat všechny moduly, na kterých požadovaný modul závisí (systém má k dispozici mapu vzájemných závislostí). Dalšími příkazy z téhle rodiny jsou lsmod a rmmod.

Pod linuxem soubor .ko je něco jako pod Windows soubor .sys. V obou případech se jedná o kus binárního kódu, který lze zavést do běžícího kernelu, a modul/ovladač se definovaným způsobem uvnitř kernelu přihlásí / zapojí do práce. Že se pod Windows soubory .SYS distribuují pohromadě s popisným souborem .INF a podpisem .CAT, a na rozdíl od Linuxu nejsou příliš jemně verzované, to je v zásadě malá nuance, která souvisí s modelem vývoje softwaru (každý operační systém ho má postavený trochu jinak, zcela jistě Linux vs. Windows).

Co je to ovladač: je to malé bago spustitelného kódu, s nějakou standardizovanou "hlavičkou" / datovou strukturou s předepsanými údaji a odkazy na výkonné funkce modulu. Je to vlastně kolekce volatelných funkcí. Některé ty funkce jsou "zveřejněné", tvoří rozhraní modulu vůči zbytku jádra - jiné jsou "privátní", modul je používá pouze interně. Pokud někdy uslyšíte o "tabulce symbolů", tak se jedná o jména funkcí a proměnných uvnitř modulu (především těch veřejných). Velikou tabulku symbolů obsahuje také hlavní monolit jádra. Vzájemné vypořádání symbolů poskytovaných a požadovaných mezi monolitem a moduly navzájem je náplní práce kernelového dynamického linkeru... (Velmi podobně to funguje u user space programů a dynamických knihoven. Ovšem zatímco user-space program při nevyřešených zavislostech zhavaruje, kernelový linker jenom odmítne natáhnout modul, pro který nemohl vyřešit všechny závislosti.)

Na úrovni zdrojových kódů je "ovladač" opět kolekce funkcí - ve zdrojákách. K vytvoření jednoho binárního kernelového modulu může být potřeba jeden nebo více zdrojáků = textových souborů s příponou .c. Předpis pro sestavení modulu z jednoho či více zdrojáků je obsažen v tzv. Makefile. Přesněji zrovna v kernelu se jedná o celý rozsáhlý strom dílčích souborů Makefile a Kconfig (oba jsou to textové soubory) - granularitu skladby (linkování modulů) lze detailně ovlivnit konfigurací kernelu.
Obvykle je granularita kernelových modulů volená tak, že jeden modul = jeden ovladač, pro specifický hardware. Ale klidně může jeden modul obsahovat ovladačů několik. Kromě toho ne všechny moduly obsahují drivery pro hardware, často modul opouzdřuje nějakou čistě softwarovou fičuru v systému. Třeba nějaké dílčí "porovnávací pravidlo" pro netfilter.
Přesto pojmy "modul" a "ovladač" v obecné mluvě často dost splývají.

Ovladače od třetích stran mají v Linuxu těžký život, hlavně kvůli jemnému verzování kernelů. To souvisí s průběžným inkrementárním vývojem a releasováním linuxového kernelu jakožto softwaru. Pod Windows obvykle stačí, aby byl driver kompatibilní s poměrně hrubým základním číslem verze kernelu (cca na úrovni verzí Windows). Pod Windows dokonce existují mechanismy (styl programování), jak zařídit, že může být binárka ovladače kompatibilní s více verzemi Windows.
Zato pod Linuxem je prakticky vynuceno, že zavést do jádra lze pouze modul zkompilovaný proti téže třímístné verzi kernelu (resp. včetně "patchlevel ocásku verze", který si můžete sami definovat při kompilaci), ba dokonce lze zapnout verzování až na úrovni "sériového čísla buildu". Dnešní distribuce toto mají běžně v distibučním kernelu zapnuto, já to ve svých custom kernelech vypínám, abych při ladění modulů nemusel po rekompilaci hlavního kernelu rekompilovat bez pardonu taky všechny externí (out of tree) ovladače.

Ovladač, od kterého máte k dispozici kompletní zdrojáky, můžete poměrně snadno přikopírovat a zaháčkovat do vanilkového stromu, který jste si stáhl na lokální disk - a zkompilovat "in tree". Existuje ale také oficiálně podporovaný postup, jak svůj custom ovladač zkompilovat "out of tree", pouze s odkazem na hlavní strom někde jinde na disku (a jeho verzování). Rozdíl je nakonec vlastně jenom v cestě k adresáři, kde se zdrojáky "vašeho" modulu nacházejí. Čili toto platí pro "ovladače třetích stran", pokud jsou k dispozici kompletní zdrojáky.

Jiná je situace u ovladačů třetích stran, které obsahují "binární blob". Překlad mnoha tradičních programovacích jazyků do binárního executable kódu se děje ve dvou krocích: kompilace a linkování. První krok vyrobí z jednotlivého zdrojového souboru (např. .c) "polotovar" zvaný "objektový soubor" (.o nebo třeba .obj). Ve druhém kroku se několik objektových souborů slinkuje do potřebného finálního formátu: to může být user-space executable binárka, nebo statická či dynamická knihovna, nebo třeba kernelový modul. Výrobci hardwaru mají i pod Linuxem sklon, nedávat volně k dispozici zdrojové kódy ovladačů. Nechtějí podporovat konkurenci apod. Takže dodávají nějakou interní knihovnu ovladače v podobě "objektového polotovaru". A to je právě ten ohavný binární blob. On obsahuje tabulku symbolů, takže jeho funkce lze volat - ale zároveň je to černá skříňka, do jejíž vnitřní logiky nikdo nevidí. A může se stát, že ten blob byl zkompilovaný proti starší verzi kernelu (jde o deklarace structů a prototypy funkcí, ale taky o věci hlouběji pod kapotou), takže když ho jenom obalíte do open-source "košilky" a tu zkompilujete proti kýženému novějšímu kernelu, tak to vypadá navenek OK, ale ten blob může za provozu způsobovat chyby. Což je vedle ideologického imperativu dost dobrý praktický důvod, proč se binárním blobům v ovladačích bránit. A že se Linux (Linus) brání zuby nehty.

Končím - chtěl jsem něco vysvětlit a spíš do toho jenom dál a dál zabředávám...