Re: initrd - czy jest niezbędny?
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 <porridge@debian.org> http://marcin.owsiany.pl/
GnuPG: 1024D/60F41216 FE67 DA2D 0ACA FC5E 3F75 D6F6 3A0D 8AA0 60F4 1216
Reply to: