Re: Re[6]: Zależności kernel-2.2.19?

[Tomasz Kłoczko]

On Wed, 27 Jun 2001, Mariusz Mazur wrote:

> >> Nie. Nie lubie wpisywac do lilo komend ktore nie wiem co robia, a
> >> jestem zbyt leniwy by czytac o mechanizmach initrd.
> 
> TK> Moemnt. Pzrecież geninitrd nie ma zwiazku z lilo. Owszem generuje to
> TK> dodatkowy plik który rejestruje się np. w lilo.conf ale na tym zwiazek się
> TK> kończy.
> 
> Jak juz mowilem: nie wiem jak to dziala i nie chce mi sie dowiadywac
> (nie tyle nie chce ile nie mam takiej potrzeby... i tak bede
> rekompilowal jadro). Wiem, ze musze dodac do lilo.conf jakis wpis i
> nie wiem co on robi. EOT (w sumie stracilem watek i nie wiem o czym
> dyskutujemy :)

Opis bęzdie krótszy niż długość skryptu.
Tak w punktach:
- w kernel nie wkompilowujesz obsługi ani urządzeń na których jest root fs
  (ide czy scsi czy nieco wyżej mata devy do RAID) - wszystko leci do
  modułów, a w kernel dodatkowo wlatuje obsługa autoraid (szkoda że
  jeszcze tego niezmodularyzowano bo zdaje mi się że dałoby się),
- w kernelu pozostawiasz obsługe systemu plikowego którego kod zajmuje
  najmneij (obsługa romfs zajmuje niecałe 4KB kodu), a reszta do modułów,
- skrypt służy do skompmpletowania zestawu modułów jakei będzie trzeba
  załadować do kernela żeby móc podmonotwać root fs *i tylko do tego*, bo
  reszta czynności może być juz wykonana po podmontowaniu własciwego root
  fs.

Teraz zastanów się .. co jest Ci potrzebne do tego żeby wykonać
stuprocentowo pewna detekcje tego które moduły trzeba załadować żeby móc
już podmontować root fs ? Do wyboru możesz mieć:
1) załadowanie modułów do ide,
2) załadowanie sterownika scsi host adaptera i modułu do scsi do obsługi
  dysków,
3) załadowanie modułu do obsługi konkretnego typ RAID,

Musisz załadować konkretny (jeden) modułu do obsługi systemu
plikowego jaki jest na root fs.

W przypadku kernela 2.4 między 2 i 3 może się jeszcze wcisnąć coś do
obsługi LVM (to jest w modułąch tak bajdełejem ?)

Zastanowiłęś sie ? .. .. .. 

To teraz patrz:

Zaglądasz do /etc/fstab i wyciagsz linikę która w drugiej
kolumnie ma "/" i dalej wyciagsz pierwsą kolumnę z tej linijki i już
masz nazwę urządznia z którego odbywa się start. jeżeli to jest /dev/hd*
to ładujesz moduły ide, jeżeli /dev/sd* to scsi i tu żeby dowiedziec sie
dodatkowo jaki potzrebny jest scsi host adapter to zaggloądasz do
aliasów modutils wyciągajac z tego nazłe odpwiedniego modułu. Jeżeli to
jest /dev/md* to zaglądając sodatkowo do /proc/mdstat wyciągsz z tego
informację jaki typ RAID na root fs i zależnie od tego wyciągasz typ
modułu który powinien być załadowany. Na podstawie tej wyciagnietej z
fstab linuijki z trzeciej kolumny dowiadujesz sie jaki moduł
potrzebujesz do obsługi root fs.

Czyli w tym momencie masz juz ustalona kolejność ładowanai modułów jak i
ich lisę. Teraz to już czysta formalność:
1) założenie katalogu w którym będzisz komplował zawartość initrd,
2) założenie kilku plikół w /dev
3) zapakowanie do tego katalogu /linuxrc w którym mopzesz uruchomić
  normalnie shella w którego skrypcie wywoąłsz odpowiednia sekwencje
  insmodów,
4) załadowanie do odpwoeidniego katalogu potrebnych modułół (kopiujesz je
   z /lib/modules/<ver>),
5) wywołąnie genromfs któryu z tego katalogu utworzy obraz wolumenu
   którego rozmiar bezie dokąłdnie taki jak potzreba na powyyższe pliki, i
   mna koniec mozesz całosć spakować (initrd możesz byc spakowane).

Ponieważ statycznie zlikowany shell zajmuje sporo miejsca został wymysłony
specjalny programik (bsp) który w sobie ma kod ładowania modułów, a lisę
tycze modułów czyta z pliku (też to laduje e obrazie initrd). bsp ma tylko
paręnaście KB, a statycznie zlinkowany incmod i shell (tak jak to się
klasycznie robi) maja po paręset KB. W sumie zajmuą ponad połowę objętości
initrd np. w tym co jest w RH.

Bootloader startuje z initrd w ten sposób, że ładuje pod określona lokację
obraz kernela i pod inną obraz initrd po czym przekazuje sterowanei do
kernel pzrekazujać mu informację że start powinien obyć się z initrd
pzrekazując jednoczłnie adres obrazu w pamieci initrd.
Po podmontowaniu initrd (ramdysk którego obsługa też musi być wkompilowana
w kernel) startuje z niego /linuxrc. W /linuxrc startowany jest bsp kóry
ładuje wszystkei moduły. Po skojczeniu działania /linuxrc kernel
odmontowuje initrd i zwalnai pamieć zajmowaną pzrez ten obraz po czym
pzrechodzi do podmontowanai włąsciwego root fs. Możan juz to w tym moemcie
zrobić poniewać w przestrzeni kernla znajduja się juz załadowane wszystkie
moduły dzieki którym obłużenie rootfs jest juz mozliwe.

Jedyne kryczyczne moenty to poprawne napisanie kawałków zajmujacych się
analizą stanu systemu dzięki którym jestes w stanie skompletrować lisę
potzrebnych modułół. Co Ci to daje ? ano dokąłdnie tyle że masz kernel
kóry jest kompletnie niezależny od włąsciwści otocznia w jakich przyjdzie
mu podmontować root fs. Jeszcze raz cała ta zabawa dotyczy wyłącznie root
fs i niczego wiecej bo reszta mozę być juz wykonana po podmontowaniu
własciwego root fs.

Jak się powyższemu przyjrzysz to zapewne zauważysz, że:
- initrd wąłsnie został wymyslony po to żeby powyśze było możeliwe i tylko
  brak implemetacji powyższego w pełnej postaci powoduje, że initrd nie
  jest w szasadzie powszechnym standardem (ale takim się stanie bo nie ma
  wyjscia jeżeli ktoś chce uprościć osadzanie Linuxa na dowolnym sprzęcie
  bez koneiczniości rekompilacji kernela,
- kernel modularny zajmuje potrencjalnie tylko kilka do kilkudziesiąt
  więcej KB pamieci niż ściśle dopasowany kernel pod konkretna masznke,
- powyższe dane służące do skompletowanai initrd to 100% tego co
  potrzebujesz .. ergo: o ile powyższe jest poprawnie zaimplementowane to
  *musi* działać kompletnie deterministycznie i *bezobsługowo*. ta
  bezobsługowość w połączeniu z pewnością tego co powinno być ładowane
  daje kompletne wyrugowanie błedów wynikajacych z niewłąsciwego
  skonfigurowanai źródeł,
- powszechne używanie kernela z binarnego pakeitu wpłyywa na jego znacznie
  lepsze wytesowanie co jest koejnym czyynnikiem dooprowadzajacym rdo
  tego, że do całości masz większe zauwfanie,
- kernel + initrd zajmuje dokałdnie tyle ile jest potzrebne, a dzieki bsp
  całosć jest dodatkowo na tyle mała, że kernel + initrd zmieści sie na
  dyskietce. Ttutaj tzreba jeszcze przerobić skrypt mkbootdisk który jest
  w np. RH ale tak żeby generowany obraz dyskietki był wykonywany z
  kernela i initrd. Po zrobieniu tego mamy niema komplet .. komplet bo do
  kompletu mozan dołożyć jeszcze automatyczne reejstrowanie i generowanie
  np. lilo.conf (narzędzie do tego jest robione pod nazwa rc-boot).

Jeszcze jakieś wątpliwości ? pytania ?

kloczek
-- 
-----------------------------------------------------------
*Ludzie nie mają problemów, tylko sobie sami je stwarzają*
-----------------------------------------------------------
Tomasz Kłoczko, sys adm @zie.pg.gda.pl|*e-mail: kloczek w rudy.mif.pg.gda.pl*