V dávných dobách bylo jádro pevně naprogramováno tak, aby znalo hlavní/vedlejší číslo zařízení root fs a připojilo toto zařízení po inicializaci všech ovladačů zařízení, které byly zabudovány do jádra. rdev nástroj lze použít k úpravě čísla kořenového zařízení v obrazu jádra, aniž by bylo nutné jej znovu kompilovat.
Nakonec přišly zavaděče a mohly předat jádru příkazový řádek. Pokud root= argument byl předán, který řekl jádru, kde je root fs místo vestavěné hodnoty. Ovladače potřebovaly přístup, které ještě musely být zabudovány do jádra. Zatímco argument vypadá jako normální uzel zařízení v /dev adresář, evidentně tam není /dev adresář před připojením root fs, takže jádro tam nemůže vyhledat dev uzel. Místo toho jsou některá dobře známá jména zařízení pevně zakódována do jádra, takže řetězec lze přeložit na číslo zařízení. Z tohoto důvodu může jádro rozpoznat věci jako /dev/sda1 , ale ne exotičtější věci jako /dev/mapper/vg0-root nebo UUID svazku.
Později initrd vstoupil do obrazu. Spolu s jádrem by zavaděč nahrál soubor initrd image, což byl nějaký druh komprimovaného obrazu souborového systému (gzipovaný ext2 obraz, gzipovaný romfs obraz, squashfs se nakonec stal dominantním). Jádro by dekomprimovalo tento obraz na ramdisk a připojilo ramdisk jako kořenový fs. Tento obraz obsahoval některé další ovladače a spouštěcí skripty namísto skutečného init . Tyto spouštěcí skripty prováděly různé úkoly, aby rozpoznávaly hardware, aktivovaly věci jako raid pole a LVM, detekovaly UUID a analyzovaly příkazový řádek jádra, aby nalezly skutečný kořenový adresář, který lze nyní specifikovat pomocí UUID, jmenovky svazku a dalších pokročilých věcí. Potom připojil skutečný root fs do /initrd a poté provedl pivot_root systémové volání pro výměnu jádra / a /initrd a poté exec /sbin/init na skutečném rootu, který by pak odpojil /initrd a uvolněte ramdisk.
Konečně dnes máme initramfs . Je to podobné jako initrd , ale místo toho, aby to byl komprimovaný obraz souborového systému, který se nahraje na ramdisk, je to komprimovaný archiv cpio. Jako kořenový adresář je připojen tmpfs a tam je archiv extrahován. Místo použití pivot_root , který byl považován za špinavý hack, initramfs spouštěcí skripty připojí skutečný kořenový adresář do /root , smažte všechny soubory v kořenovém adresáři tmpfs a poté chroot do /root a exec /sbin/init .
Linux se zpočátku zavádí z ramdisku (nazývaného initrd , pro "INITial RamDisk") jako / . Tento disk má na sobě právě tolik, aby bylo možné najít skutečný kořenový oddíl (včetně všech potřebných ovladačů a modulů souborového systému). Připojí kořenový oddíl na dočasný bod připojení na initrd , pak vyvolá pivot_root(8) pro výměnu kořenového a dočasného přípojného bodu a ponechání initrd na pozici umount ed a skutečný kořenový souborový systém na / .
Zdá se, že se ptáte, jak jádro "ví", který oddíl je kořenový, bez přístupu ke konfiguračním souborům v /etc.
Jádro může přijímat argumenty příkazového řádku jako každý jiný program. GRUB nebo většina ostatních zavaděčů může přijímat argumenty příkazového řádku jako vstup uživatele nebo je ukládat a zpřístupňovat různé kombinace argumentů příkazového řádku prostřednictvím nabídky. Zavaděč předává argumenty příkazového řádku jádru, když jej načítá (neznám název ani mechanismus této konvence, ale je to pravděpodobně podobné tomu, jak aplikace přijímá argumenty příkazového řádku z volajícího procesu v běžícím jádře).
Jedna z těchto možností příkazového řádku je root , kde můžete zadat kořenový souborový systém, tj. root=/dev/sda1 .
Pokud jádro používá initrd, zavaděč je zodpovědný za to, že jádru sdělí, kde se nachází, nebo vloží initrd do standardního paměťového umístění (myslím) - alespoň tak to funguje na mém Guruplugu.
Je zcela možné, že jeden nespecifikujete a pak vaše jádro zpanikaří okamžitě poté, co si začne stěžovat, že nemůže najít kořenový souborový systém.
Mohou existovat jiné způsoby předání této možnosti jádru.