On Sat, Dec 30, 2006 at 12:13:42AM +0100, Jarek Buczyński wrote: > Mam pytanie dotyczące initrd. Czy mógłby ktoś krótko i prosto napisać jak > działa initrd i czy jest niezbędny?
initrd to skrót od "initialial ram disk" czyli (wolne tłumaczenie) ramdysk na czas inicjalizacji. Powoli jest zastępowany przez initramfs, którego działanie jest bardzo podobne (nawet plik nazywa się initrd.img), ale implementacja nieco inna (archiwum cpio zamiast obrazu systemu plików, może być doczepiany do obrazu jądra itd) Działanie initrd (może nie krótko, ale mam nadzieję, że prosto): -1) jeśli podano argument --initrd do make-kpkg (skrypt budujący deb-y z jądrem) - a tak jest w przypadku standardowych jąder Debiana - to pakiet zostanie wyposażony w skrypt postinst zdolny do automatycznego wygenerowania initrd 0) przy instalacji pakietu kernel-image/linux-image skrypt postinst generuje automatycznie obraz initrd jako /boot/initrd.img-$(uname -r) Do jego wygenerowania są używane: - initrd-tools/initramfs-tools - moduły jądra (właśnie zainstalowane razem z jądrem) - podstawowe narzędzia (bash, modprobe, mount...) - informacje na temat lokalizacji głównego systemu plików (nazwa urządzenia, sterownika tego urządzenia, ew. dodatkowe informacje o tym jak się do niego dostać - czy np. potrzebny jest LVM albo EVMS, może MD itp) - mkinitrd zawiera logikę potrzebną do automatycznego uzyskania tych informacji - opcjonalnie dodatkowe nadzędzia (do inicjalizacji MD, LVM itp) - wymagane biblioteki Generowanie initrd polega na utworzeniu archiwum albo obrazu systemu plików z wyżej wymienionymi rzeczami. 0.5) jeśli przechodzisz z jądra bez initrd na takie z initrd, to trzeba ręcznie zmodyfikować config boot loadera (dodać linijkę "initrd"). Jeśli nie, to postinst wykonuje update-grub lub update-lilo i to wystarcza 1) boot loader ładuje obraz jądra i initrd do pamięci, a następnie uruchamia jądro, przekazując mu informację, że ma do dyspozycji initrd 2) jądro montuje ramdysk jako główny system plików (co się nie uda, jeśli nie ma wkompilowanej obsługi systemu plików cramfs) i odpala skrypt (o ile się nie mylę) linuxrc 3) tenże skrypt odwala całą czarną robotę wymaganą do tego, żeby zamontować (o ile się nie mylę w /mnt) docelowy główny system plików (ten na którym jest system), czyli załadowanie odpowiednich modułów jądra w odpowiedniej kolejności, odpalenie coldpluga (to zdaje się taki mały hotplug) ew. inicjalizację macierzy, LVM, EVMS itp i samo montowanie systemu plików 4) odpalany jest pivot_root, który "zamienia miejscami" dotychczasowy i docelowy główny system plików: /mnt -> / / -> /initrd 5) odpalany jest init w docelowym głównym systemie plików i od tego momentu ładowanie systemu postępuje tak jak w przypadku bez initrd > Pytam ponieważ czasami znajomi którzy używają innych dystrybucji dziwią się > co to jest initrd? Po co to jest w Debianie? W Debianie cel jest następujący: uzyskać minimalne jądro (z obsługą tylko rzeczy potrzebnych do initrd) a wszystko inne (łącznie z modułami potrzebnymi do zamontowania głównego systemu plików) zapakować do modułów. Dzięki temu można uzyskać uniwersalny pakiet z jądrem, który "działa u wszystkich" a jednocześnie samo jądro nie zawiera niepotrzebnych sterowników marnujących pamięć. Niektórzy pewnie pamiętają czasy instalatora boot-floppies i kilku jąder do wyboru (vanilla, idepci, cośtam jeszcze) z których każde zawierało nieco inny zestaw sterowników. Podstawowa wada tego rozwiązania to jego komplikacja - skoro pakiet jest uniwersalny, to musi umieć obsłużyć setki kombinacji sterowników, z których pewne, przy "anarchistycznym" modelu rozwoju Linuksa są naprawdę nietrywialne. Do tego dochodzi czasem problem zmiany zachowania sterowników, albo zmiana ich nazwy - initrd jest konstruowany jeszcze gdy działa jądro w wersji "X", a następnie używany z jądrem w wersji "Y" - gdzie na przykład nazwa modułu ze sterownikiem do obsługi macierzy megaraid radośnie zmieniła się na megaraid_2. Na dodatek, częściowo dlatego, że initrd jest dość mały, a cześciowo dlatego, że komunikaty Linuksa dość ciężko się czyta (por. komunikaty jądra FreeBSD, które mają schludny, jednolity format) jakikolwiek problem w działaniu linuxrc dość ciężko rozwikłać - ewidentnie widać to gdy zgłaszając problem ludzie cytują trzy ostatnie linijki, które akurat są dość bezużyteczne, a właściwa przyczyna błędu jest gdzieś pół ekranu wcześniej, albo i jeszcze wyżej. > I dlaczego u nich tego nie ma :) "U nich nie ma" prawdopodobnie dlatego, że posiadają monolityczne jądra z najpopularniejszymi sterownikami "do wszystkiego" co może być potrzebne do zamontowania głównego systemu plików. Zaś na pytanie "które z rozwiązań jest lepsze" odpowiedź brzmi pewnie "zależy dla kogo" :) Wiem, że istnieją/będą istnieć rozwiązania, których bez pomocy initrd się nie da załadować (po prostu jądro nie jest w stanie automatycznie wykonać wszystkich czynności koniecznych, żeby dostać się do głównego systemu plików - są potrzebne do tego dodatkowe narzędzia działające w trybie użytkownika). I wydaje mi się, że w tym kierunku pójdzie rozwój - widać to choćby na przykładzie hotpluga, który został "wydzielony" do procesu w trybie użytkownika. Osobiście używam initrd, i raczej problemów nie mam, choć przyznaję, że kiedyś toczyłem z nim zażarte boje, pewnie dlatego że sam nie wiedziałem jak to dokładnie działa, i dlatego że kiedyś mkinitrd/linuxrc był bardziej prymitywny i "mało inteligentny". Marcin -- Marcin Owsiany <[EMAIL PROTECTED]> http://marcin.owsiany.pl/ GnuPG: 1024D/60F41216 FE67 DA2D 0ACA FC5E 3F75 D6F6 3A0D 8AA0 60F4 1216 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
