Słowem przedwstępu…. Po przeczytaniu prawie gotowej części drugiej „zabaw z Ubuntu” doszedłem do wniosku, że zupełnie mi się nie podoba - mało praktyki „praktycznej”, dużo teorii, czyli dokładnie przeciwieństwo tego, czym miał być cykl. Jednakże, z drugiej strony część z tych zagadnień może okazać się pomocna w dalszych zabawach z Ubuntu, jak również w pracy z Linuksem. Idąc tym tropem postanowiłem, iż zagadnienia praktyczne związane z initrd, a w każdym razie te zgodne z założeniami cyklu, znajdą się w części trzeciej, tak aby osoby nie zainteresowane poniższą teorią mogły część drugą pominąć i bez większego trudu przebrnąć przez część trzecią, o ile okaże się lepsza ;)
boot loader initialized RAM disk - initrd
Wielokrotnie w „świecie Linuksa” słyszymy i czytamy o initrd. Można wywnioskować nawet, że jeden mały plik jest wspaniałym „wynalazkiem”, cudownym narzędziem, a czasem największą zmorą. Gdy działa, wszystko jest wspaniale, ale w tych nielicznych przypadkach, gdy zawiedzie, użytkownik rozpoczyna falę przekleństw związanych zazwyczaj z ostatnią aktualizacją jądra lub innego ważnego pakietu „systemowego” ;) Poniższy artykuł co prawda nie wyjaśnia jak naprawić initrd - nie ma uniwersalnego lekarstwa, jednak bez znajomości pliku możemy co najwyżej kopiować znalezione komendy w nadziei, „że to pomoże”. Poznajmy choć trochę tego diabła, a może uda się go złapać za rogi!
Czym jest initrd - z angielskiego „initialized RAM disk”, lub pełniej „boot loader initialized RAM disk”, to w znacznym uproszczeniu tak spreparowany obraz „ramdysku”, który po załadowaniu przeprowadzi dalszy rozruch systemu. Można by to rozwijać, jednak w miejsce „czczego gadania” przeprowadźmy mały eksperyment.
Na początek zaopatrzmy się w dwa narzędzia: pakiet mkisofs, którym przygotujemy obraz płyty CD oraz emulator zdolny do tego, by udawał maszynę klasy x86 (np. qemu, VirtualBox). Masochiści mogą oczywiście „zresetować” swoją maszynę i tym samym obyć się bez żadnego z wymienionych programów.
sudo apt-get install mkisofs qemu
Typowy obraz initrd zawiera między innymi program busybox. Jest to zaledwie jedna „binarka”, jednak jej funkcjonalność może zapierać dech u niejednego wielbiciela konsoli - dostarcza on wielu poleceń - zaczynając od typowych ls, cp, mkdir, przez ifconfig, mount czy nawet vi. Może dostarczać znacznie więcej niż binarka dostępna w repozytorium Ubuntu, która nie zawiera nawet połowy z wszystkich dostępnych „apletów”. Wystarczy wykonać polecenie:
/usr/lib/initramfs-tools/bin/busybox
aby zobaczyć ile apletów zostało wkompilowanych w posiadaną przez nas wersję programu. Daną funkcję wywołujemy podając jej nazwę jako pierwszy parametr busybox, na przykład:
/usr/lib/initramfs-tools/bin/busybox ls
spowoduje wyświetlenie listy plików w bieżącym katalogu. Ten konkretny plik w naszym przypadku ma dodatkową zaletę - został skompilowany statycznie, a więc nie będziemy potrzebowali do jego działania żadnych dodatkowych bibliotek. Możemy sobie również zapamiętać, że busybox wywołany np. poprzez link symboliczny o nazwie ls uruchomi aplet ls.
Przygotujmy strukturę katalogów, gdzie będziemy tworzyli własną wersję initrd, skopiujemy busybox oraz utworzymy linki symboliczne:
mkdir -p kat_roboczy/initrd/bin
cp /usr/lib/initramfs-tools/bin/busybox kat_roboczy/initrd/bin
cd kat_roboczy/initrd/bin
ln -s busybox ash
ln -s busybox sh
cd ..
Potrzebujemy jeszcze pliku init, który uruchomi dla nas powłokę. Program, czy też proces init, ma decydujące znaczenie dla systemu - bez niego, w większości przypadków, zobaczymy ulubiony przez wszystkich użytkowników Linuksa komunikat: „Kernel Panic”, ponieważ to właśnie init jest uruchamiany przez jądro tuż po starcie.
W ulubionym edytorze tworzymy plik o następującej treści:
#!/bin/sh
exec /bin/ash
A następnie zapisujemy go pod nazwą init w katalogu initrd. Jesteśmy gotowi. Teraz musimy tylko spreparować archiwum, z którym poradzi sobie kernel. W tym celu będąc w katalogu initrd wykonujemy polecenie:
find . | cpio --quiet --dereference -o -H newc | gzip -9 > initrd-test.img
cd ..
Nasz obraz jest już gotowy. Za chwilę dowiemy się, co zrobiło to magiczne polecenie, a teraz zajmijmy się preparowaniem obrazu płyty, który stanie się pożywką dla emulatora.
W tym celu utworzymy jej strukturę katalogów, a następnie skopiujemy tam nasz obraz initrd, kernel, plik stage2_eltorito, oraz utworzymy plik menu.lst
mkdir -p livecd/boot/grub
cp /boot/vmlinuz-`uname -r` livecd/boot
cp initrd/initrd-test.img livecd/boot
cp /usr/lib/grub/i386-pc/stage2_eltorito livecd/boot/grub
Plik livecd/boot/grub/menu.lst w dowolnym edytorze wypełniamy treścią:
title Testowy
kernel /boot/vmlinuz
initrd /boot/initrd-test.img
oraz przygotowujemy obraz płyty:
mkisofs -o livecd.iso -b boot/grub/stage2_eltorito -no-emul-boot -boot-load-size 4 -boot-info-table -V "Moje wlasne LiveCD" -cache-inodes -r -J -l livecd
po czym testujemy nasze dzieło:
qemu -cdrom livecd.iso -boot d
Przywitała nas powłoka ash „wbudowana” w busybox.
Wiemy już, czym jest tajemniczy plik initrd.img? Tak! „Małym GNU/Linuksem”, systemem stworzonym w celu uruchomienia „właściwego” systemu operacyjnego, choć może spełniać także inne funkcje. Nietrudno wyobrazić sobie, że taki „system” może pełnić funkcje Linuksowego routera, odtwarzacza plików wideo, itd.
Wróćmy jednak na chwilę do zagadnienia samego tworzenia obrazu initrd. Dla przypomnienia, obraz generowaliśmy następująco:
find . | cpio --quiet --dereference -o -H newc | gzip -9 > initrd-test.img
w pierwszym etapie polecenie
find .
odszukuje wszystkie pliki w katalogu bieżącym oraz podkatalogach, natomiast jego wynik zostaje przekazany do programu cpio, który służy do obsługi archiwów. Narzędzie cpio tworzy archiwum, które następnie zostanie skompresowane przez program gzip i zapisane do pliku initrd-test.img. Należy zauważyć, iż kompresja jest opcjonalna - jądro poradzi sobie również z nieskompresowanym plikiem. Znaczenie wymienionych parametrów możemy odszukać w dokumentacji poszczególnych programów i nie będziemy się nad nimi rozwodzić.
Na szczęście dla nas nie będziemy musieli tworzyć od podstaw initrd, a ten nudny fragment ma wyłącznie pokazać czym jest obraz initrd i jak to draństwo działa. W Ubuntu istnieją gotowe skrypty „pakowane” do initrd, jak też same „generatory” obrazów initrd. W następnej części zajmiemy się właśnie nimi i wreszcie wykorzystamy zdobytą wiedzę w praktyce, bez kolejnych zagadnień będących „sztuką dla sztuki”.