Vysvětlení pojmu InitramFS

asdfg

Vysvětlení pojmu InitramFS
« kdy: 22. 11. 2018, 10:46:00 »
Ahoj,

v provom rade bz som chcel podakovat autorovi za pekny clanok. 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... :)
« Poslední změna: 22. 11. 2018, 10:53:34 od Petr Krčmář »


Re:Vysvětlení pojmu InitramFS
« Odpověď #1 kdy: 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čí?

Pavouk106

  • *****
  • 2 362
    • Zobrazit profil
    • Můj blog
    • E-mail
Re:Vysvětlení pojmu InitramFS
« Odpověď #2 kdy: 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.
« Poslední změna: 22. 11. 2018, 12:30:08 od Pavouk106 »

ByCzech

  • *****
  • 1 830
    • Zobrazit profil
    • E-mail
Re:Vysvětlení pojmu InitramFS
« Odpověď #3 kdy: 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...).

Re:Vysvětlení pojmu InitramFS
« Odpověď #4 kdy: 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:

  • 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.).

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).


RDa

  • *****
  • 2 039
    • Zobrazit profil
    • E-mail
Re:Vysvětlení pojmu InitramFS
« Odpověď #5 kdy: 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

Re:Vysvětlení pojmu InitramFS
« Odpověď #6 kdy: 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ší (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...

Re:Vysvětlení pojmu InitramFS
« Odpověď #7 kdy: 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).

RDa

  • *****
  • 2 039
    • Zobrazit profil
    • E-mail
Re:Vysvětlení pojmu InitramFS
« Odpověď #8 kdy: 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.

Re:Vysvětlení pojmu InitramFS
« Odpověď #9 kdy: 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í.

asdfg

Re:Vysvětlení pojmu InitramFS
« Odpověď #10 kdy: 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...

Ravise

  • ***
  • 113
    • Zobrazit profil
    • E-mail
Re:Vysvětlení pojmu InitramFS
« Odpověď #11 kdy: 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é.

.

Re:Vysvětlení pojmu InitramFS
« Odpověď #12 kdy: 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

Diskobolos

Re:Vysvětlení pojmu InitramFS
« Odpověď #13 kdy: 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.

RDa

  • *****
  • 2 039
    • Zobrazit profil
    • E-mail
Re:Vysvětlení pojmu InitramFS
« Odpověď #14 kdy: 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"