W jaki sposób jądro montuje partycję root?

Moje pytanie dotyczy uruchomienia systemu Linux z osobnej partycji / boot. Jeśli większość plików konfiguracyjnych znajduje się na osobnej / partycji, w jaki sposób jądro poprawnie montuje go podczas uruchamiania?

Wszelkie rozwinięcie tego byłoby świetne. Mam wrażenie, że brakuje mi czegoś podstawowego. Najbardziej interesuje mnie proces i kolejność operacji.

Dzięki!

EDYCJA: Myślę, że to, o co musiałem zapytać, było bardziej zgodne z plikiem dev, który jest używany w parametrze jądra root. Powiedzmy na przykład, że podaję parametr root jako root = / dev / sda2. W jaki sposób jądro ma mapowanie pliku / dev / sda2?

Linux początkowo uruchamia się z ramdyskiem (zwanym initrd„INITial RamDisk”) jako /. Ten dysk ma wystarczającą ilość miejsca, aby znaleźć prawdziwą partycję główną (w tym wszelkie wymagane sterowniki i moduły systemu plików). Montuje partycję root na tymczasowym punkcie montowania na initrd, a następnie wywołuje pivot_root(8)zamianę root i tymczasowych punktów montowania, pozostawiając initrdpozycję do umountedycji i włączony system plików root /.

W czasach starożytnych jądro było mocno zakodowane, aby znać główną / mniejszą liczbę root fs i montowało to urządzenie po zainicjowaniu wszystkich sterowników urządzeń wbudowanych w jądro. rdevNarzędzie może być wykorzystywane do zmiany numeru urządzenia głównego w jądrze bez konieczności ponownej kompilacji.

W końcu pojawiły się programy ładujące i mogły przekazać wiersz poleceń do jądra. Jeśli root=argument został przekazany, informowało to jądro, gdzie znajduje się root fs zamiast wbudowanej wartości. Sterowniki wymagały dostępu, które wciąż musiały być wbudowane w jądro. Podczas gdy argument wygląda jak normalny węzeł urządzenia w /devkatalogu, oczywiście nie ma /devkatalogu przed zamontowaniem root fs, więc jądro nie może tam znaleźć węzła dev. Zamiast tego niektóre dobrze znane nazwy urządzeń są zakodowane na stałe w jądrze, aby ciąg mógł zostać przetłumaczony na numer urządzenia. Z tego powodu jądro może rozpoznać takie rzeczy jak /dev/sda1, ale nie bardziej egzotyczne rzeczy takie jak /dev/mapper/vg0-rootUUID woluminu.

Później initrdpojawił się na zdjęciu. Wraz z jądrem moduł ładujący initrdładowałby obraz, który był pewnego rodzaju skompresowanym obrazem systemu plików (obraz gzipped ext2, obraz romfów gzip, wreszcie squashfs stał się dominujący). Jądro rozpakuje ten obraz na ramdysk i zamontuje go jako root fs. Ten obraz zawierał kilka dodatkowych sterowników i skryptów rozruchowych zamiast prawdziwego init. Te skrypty rozruchowe wykonały różne zadania w celu rozpoznania sprzętu, aktywacji takich rzeczy, jak tablice RAID i LVM, wykrycia UUID i parsowania wiersza poleceń jądra w celu znalezienia prawdziwego katalogu głównego, który może być teraz określony przez UUID, etykietę woluminu i inne zaawansowane rzeczy. Następnie zamontował prawdziwy root fs /initrd, a następnie wykonał pivot_rootwywołanie systemowe w celu wymiany jądra /i/initrd, a następnie uruchom /sbin/initna prawdziwym katalogu głównym, który następnie odmontuje /initrdi uwolni ramdysk.

Wreszcie, dzisiaj mamy initramfs. Jest to podobne do tego initrd, ale zamiast być skompresowanym obrazem systemu plików ładowanym do ramdysku, jest to skompresowane archiwum CPIO. Tmpfs jest montowany jako root, a archiwum jest tam rozpakowywane. Zamiast używać pivot_root, co uważano za brudny hack, initramfsskrypty rozruchowe montują prawdziwy root /root, usuwają wszystkie pliki z root tmpfs, a następnie chrootdo /rooti wykonują /sbin/init.

Wygląda na to, że pytasz, w jaki sposób jądro „wie”, która partycja jest partycją główną, bez dostępu do plików konfiguracyjnych na / etc.

Jądro może akceptować argumenty wiersza poleceń, jak każdy inny program. GRUB lub większość innych programów ładujących może akceptować argumenty wiersza poleceń jako dane wprowadzane przez użytkownika lub przechowywać je i udostępniać różne kombinacje argumentów wiersza poleceń za pośrednictwem menu. Program ładujący przekazuje argumenty wiersza poleceń do jądra, gdy je ładuje (nie znam nazwy ani mechaniki tej konwencji, ale prawdopodobnie jest to podobne do sposobu, w jaki aplikacja odbiera argumenty wiersza poleceń z procesu wywołującego w uruchomionym jądrze).

Jedną z tych opcji wiersza poleceń jest rootokreślenie głównego systemu plików, tj root=/dev/sda1.

Jeśli jądro używa initrd, bootloader jest odpowiedzialny za poinformowanie jądra, gdzie się znajduje, lub umieszczenie initrd w standardowej lokalizacji pamięci (tak myślę) - przynajmniej tak działa na moim Guruplug.

Jest całkowicie możliwe, aby nie podać jednego, a następnie wywołać panikę jądra natychmiast po rozpoczęciu narzekań, że nie może znaleźć głównego systemu plików.

Mogą istnieć inne sposoby przekazania tej opcji do jądra.

Grub montuje /bootpartycję, a następnie wykonuje jądro. W konfiguracji Gruba informuje jądro, które ma być używane jako urządzenie root.

Na przykład w Grub's menu.lst:

kernel /boot/linux root=/dev/sda2

No dalej, GRUB nie „montuje” / bootuje, po prostu czyta „menu.lst” i niektóre moduły, nie jest też częścią jądra LINUX. Kiedy wywołujesz jądro, przekazujesz argument „root” z partycją root. W najgorszym przypadku jądro wie, że właśnie zamontowano / boot (LOL).

Dalej: geekozaur ma rację, Linux używa początkowego ramdysku w formacie skompresowanego obrazu, a następnie montuje prawdziwy główny system plików, wywołując pivot_root. Linux zaczyna więc działać z obrazu, a następnie z lokalnego dysku.

Program ładujący, bez względu na to, czy jest grub, czy lilo, czy cokolwiek innego, informuje jądro, gdzie ma szukać root=, i opcjonalnie ładuje początkowy ramdysk do pamięci initrdprzed uruchomieniem jądra.

Jądro następnie ładuje się, testuje sterowniki sprzętu i urządzeń i rozgląda się po systemie pod kątem tego, co widzi (możesz przejrzeć te informacje diagnostyczne, pisząc dmesg; obecnie prawdopodobnie przewija się zbyt szybko, aby je zobaczyć), a następnie próbuje zamontować partycję wymienioną w root=parametr.

Jeśli initrd jest obecny, najpierw jest montowany, a wszystkie moduły / sterowniki urządzeń są ładowane i sprawdzane przed zamontowaniem głównego systemu plików. W ten sposób możesz skompilować sterowniki dysków twardych jako moduły i nadal mieć możliwość rozruchu.