Il ramdisk iniziale (initrd) è in genere una versione ridotta del filesystem di root contenente solo ciò che è necessario per montare il filesystem di root effettivo e passare l'avvio su di esso.
Il initrd esiste perché nei sistemi moderni, il boot loader non può essere reso abbastanza intelligente da trovare il filesystem di root in modo affidabile. Ci sono troppe possibilità per coprire un programma così piccolo come il boot loader. Si consideri root NFS, schede RAID non standard, ecc. Il boot loader deve fare il proprio lavoro usando solo il BIOS più qualsiasi codice che può essere inserito nel settore di avvio.
Initrd viene memorizzato in un punto che può essere trovato dal boot loader , ed è abbastanza piccolo che lo spazio extra che occupa di solito non disturba nessuno. (Nei piccoli sistemi embedded, di solito non esiste una radice "reale", ma solo l'inizrd.)
Initrd è prezioso: il suo contenuto deve essere preservato in tutte le condizioni, perché se initrd si rompe, il sistema non può avviarsi. Una scelta progettuale che i suoi progettisti hanno fatto per assicurarsi che ciò consistesse nel fare in modo che il boot loader caricasse initrd in sola lettura. Ci sono altri principi che il lavoro verso questo, anche, come che nel caso di piccoli sistemi dove non c'è radice "reale", si monta ancora separati /tmp
, /var/cache
e tale per memorizzare le cose. La modifica di initrd viene eseguita solo raramente e quindi deve essere eseguita con molta attenzione.
Tornando al caso normale in cui v'è un vero e proprio filesystem di root, si è inizialmente montato in sola lettura perché initrd era. Viene quindi mantenuto di sola lettura il più a lungo possibile per gli stessi motivi. Qualsiasi scrittura sulla radice reale che deve essere eseguita viene rimandata fino all'avvio del sistema, per preferenza, o almeno fino a tardi nel processo di avvio quando tale preferenza non può essere soddisfatta.
La cosa più importante che accade durante questa fase di sola lettura è che il filesystem di root viene controllato per vedere se è stato smontato in modo pulito. Questo è qualcosa che il boot loader potrebbe certamente fare invece di lasciarlo a initrd, ma cosa succederebbe se il filesystem di root non fosse smontato in modo pulito? Quindi deve chiamare fsck
per verificare e possibilmente risolverlo. Quindi, dove sarebbe initrd
ottenere fsck
, se è stato responsabile di questa fase invece di aspettare fino a quando l'handoff alla radice "reale"? Si potrebbe dire che è necessario copiare fsck
nella initrd
quando si costruisce, ma ora è più grande. E per di più, quale fsck
copierai? I sistemi Linux usano regolarmente una dozzina di filesystem diversi. Copi solo quello necessario per la radice reale al momento delinitrd
è creato? Metti in valigia le dimensioni initrd
copiando tutti i fsck.foo
programmi disponibili in esso, nel caso in cui il filesystem di root venga successivamente migrato verso un altro tipo di filesystem e qualcuno dimentica di ricostruire initrd?
Gli architetti del sistema di avvio Linux hanno saggiamente scelto di non gravare su initrd con questi problemi. Hanno delegato il controllo del vero filesystem di root al vero filesystem di root, poiché è in una posizione migliore rispetto a initrd.
Una volta che il processo di avvio è proceduto abbastanza lontano da renderlo sicuro, initrd viene sostituito da sotto la radice reale pivot_root(8)
e il filesystem viene rimontato in modalità lettura-scrittura.