Zależności kernel-2.2.19?

[Tomasz Kłoczko]

On Wed, 27 Jun 2001, Jacek Osiecki wrote:
[..]
> > Jacek co by nie mówić to jednak nie masz racji. To nie jest kilka KB
> > Porównaj sobie rozmiar kernela własnego z dystrybucyjnym. Porównaj sobie
> 
> Nie jest tak źle - powywalałem wiele rzeczy, których nie potrzebowałem ;-)
> No i od czego jest bzImage...

O włąsnie .. a nie lepiej trzymać te "dodatki" w modułach ? :)

> Moja niechęć do geninitrd wynika pewnie z tego, że jest to jeszcze jedno
> narzędzie, dodatkowa komplikacja przy użyciu której można coś jeszcze
> popsuć. No i poza tym nie wiem, jak to stosować...

$ ls -l /sbin/geninitrd 
-rwxr-xr-x    1 root     root        11275 kwi  4 22:12 /sbin/geninitrd

Primo: Jacek to jest skrypt :)

W sumie jakby przepisać nieco jeszcze zapewne dałoby się go zmniejszyć
(pierwsza wersja była przeróbką z mkinitrd z RH i w zasadzie także
wszystko to od czego jest zależny geninitrd co ejst w
/etc/sysconfig/geninitrd ejst do usunięcia). Zaleta tego narzędzia polega
właśnie na tym, że nie jest to binarka, że wykonuje stosunkowo elemetarne
czynności (łatwość lokalizowania potencjalnych błedów) i w założeniach
dodatkowo jest to coś może być dość deterministyczne narzędziem
(teoretycznie nie powinno napotykać na sytuacje w których nie wiadomo by
było co zrobić).

Tak czy inaczej jeszcze za kawałek kernel za kawałek będzie zależny
jeszcze od drugiego narzędzia/skryptu o nazwie rc-boot służącego do
automatycznego osadzania keenela w konfiguracji (dowolnego) boo managera
na zasadzie nieco podobnej do rc-inetd. Po czymś takim za pomocą rc-boot
bezie można zarejestrować choćby memtest86 i mieć to do wyboru przy
starcie, a upgrade kernela bezie mógł być wrecz dopuszczony do wykonywanai
automatycznie IMHO nalezy do tego dążyć żeby było to mozliwe i dizałało
niezawodnie bo znacznie zmniejsza stopień komplikacji tego typu operacji.
W końcu przy podejściu do tego zagadnienia tak jak to włąsnie robimy przy
maksymalnej modularyzacji kernela operacja ta ma szansę stać sie
trywaialną .. tak samo jak w choćby Solarisie gdzie stopień modularyzacji
kernela jest daleko mocniejszy i przez to wszelkie zmiany na tym poziomie
mogą być właśnie wykonywane bez konieczności rekompilacji czy relinkowania
kernela.

Mówiąc inaczej jest to coś co jest w kompletnej zgodzie z KISS .. coś co
uiprasza operacje przy kernelu do możliwych rozsądnych granic.

W tym wypadku ważne jest tylko to żeby dopracować sam skrypt generatora do
poziomu w którym będzie można będzie się nimi posługiiwać rzeczywiście bez
drżenai rąk i obaw czy z wygenerowanego initrd całość po restarcie
podniesie się (jak na razie sprawuje sie dość dobrze). Żeby było to
możliwe naprawdę prosiłbym o zgłaszanie wszelkich przypadków w ktrórych z
wygenerowanego initrd system się nie podniósł. W razie czego przydatne
będzie zawartość tych trzech plików które wymieniłem, a których zawartość
jest wykorzystywana przy generowaniu initrd.

Tak wogóle to wczoraj leżąc na plaży uświadomiłem sobie, że geninitrd nie
jet przygotowany do root fs na RAID (trzebaby sprawdzać, czy root fs w
/etc/fstab jest na /dev/md* i jeżeli tak to dodatkowio zagladać do
/proc/mdstat wyczuwając który moduł do RAID trzeba załadować na initrd).

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*