Jądro, łatki, drzewa i kompilacja

1.1 Jądro

Aktualną wersję jądra systemu możemy pobrać z „The Linux Kernel Archives” w postaci dużego archiwum tar skompresowanego za pomocą programu gzip lub bzip2 (warto pamiętać o tym, że pliki bz2 są mniejsze niż gz). Archiwum należy rozpakować do jakiegoś katalogu (standardowo /usr/src/), można to zrobić na kilka sposobów (urok systemów uniksowych).

Dla plików skompresowanych programem bzip2:

$ tar xjvf linux-2.6.x.y.tar.bz2

Dla plików skompresowanych programem gzip:

$ tar xzvf linux-2.6.x.y.tar.gz

Równie dobrze możemy postąpić zgodnie z instrukcją zawartą w pliku README

$ bzip2 -dc linux-2.6.x.y.tar.bz2 | tar xvf -
$ gzip -cd linux-2.6.x.y.tar.gz | tar xvf -

Po rozpakowaniu kodu źródłowego jądra otrzymujemy katalog o nazwie odpowiadającej jego wersji (np. linux-2.6.18), którego zawartość często jest nazywana „drzewem jądra” (ang. kernel tree). Z tego powodu słowo „drzewo” bywa wykorzystywane do nazywania różnych wersji kodu źródłowego jądra. Na przykład zamiast mówić „wersja źródeł jądra przygotowywana przez Andrew Mortona” wygodniej jest powiedzieć „drzewo -mm”.

1.2 Łatki

Aby zaktualizować źródła nie powinniśmy pobierać całego archiwum, szybciej jest pobrać łatkę (ang. patch). Aplikujemy ją będąc wewnątrz katalogu z źródłami systemu:

$ bzip2 -cd /ścieżka/do/patch-2.6.x.bz2 | patch -p1
$ gzip -cd /ścieżka/do/patch-2.6.x.gz | patch -p1

lub
$ patch -p1 < /ścieżka/do/patch-x.y.z
$ cat /ścieżka/do/patch-x.y.z | patch -p1

w przypadku łatek rozpakowanych. (To oczywiście są tylko najprostsze sposoby, bez problemu można wymyślić ciekawsze.)

Bardzo użyteczną funkcją jest odwracanie łatek gdy ich już nie potrzebujemy (lub źle działają), możemy to wykonać dodając do flag patch parametr -R.

$ bzip2 -cd /ścieżka/do/patch-2.6.x.bz2 | patch -p1 -R

Możemy też sprawdzić czy łatka aplikuje się czysto (nie ma żadnych odrzuconych fragmentów kodu) przy użyciu flagi —dry-run

$ bzip2 -cd /ścieżka/do/patch-2.6.x.bz2 | patch -p1 --dry-run

Jeżeli nie zauważyliśmy żadnych komunikatów
„1 out of 1 hunk FAILED — saving rejects to file *”,
możemy spokojnie nałożyć łatkę.

Rzecz jasna po nałożeniu łatek otrzymujemy drzewo jądra różne od tego, które mieliśmy na początku. W związku z tym drzewo, od którego zaczynamy nakładanie łatek, często nazywa się drzewem surowym (ang. raw), lub zwyczajnym (ang. vanilla). Większość różnych wersji kodu źródłowego jądra, czyli drzew jądra, jest dostępna w postaci zbiorów łatek, lub nawet w postaci pojedynczych łatek, które należy nałożyć na odpowiednią „surową” wersję jądra dostępną na ftp://ftp.kernel.org. Stabilne wersje jądra mają oznaczenie 2.6.x lub 2.6.x.y, wersje rozwojowe są oznaczane jako 2.6.x-git*, 2.6.x-rc* oraz 2.6.x-rc*-git*. Ten sposób oznaczania pozwala na łatwe zorientowanie się, jakie łatki należy nałożyć na aktualnie posiadaną wersję, aby uzyskać tą która nas interesuje.
Poniższy przykład rozjaśni całą sytuację. Mamy do dyspozycji stabilną wersję 2.6.16.25 i chcemy przejść do wersji rozwojowej 2.6.20-rc1-git1. Rozpakowujemy naszą kopię źródeł:

$ tar xjvf linux-2.6.16.25.tar.bz2

Pobieramy łatkę patch-2.6.16.25.bz2 i odwracamy ją.
$ bzip2 -cd /ścieżka/do/patch-2.6.16.25.bz2 | patch -p1 -R

Teraz w katalogu roboczym mamy wersję 2.6.16 - o to nam chodziło, łatki stabilne i rozwojowe aplikują się czysto tylko na wersję 2.6.x, ponieważ już zawierają poprawki wchodzące w skład 2.6.x.y. Teraz pobieramy łatki w wersjach 2.6.17, 2.6.18 oraz 2.6.19 i aplikujemy
je po kolei.

$ bzip2 -cd /ścieżka/do/patch-2.6.17.bz2 | patch -p1
$ bzip2 -cd /ścieżka/do/patch-2.6.18.bz2 | patch -p1
$ bzip2 -cd /ścieżka/do/patch-2.6.19.bz2 | patch -p1

Otrzymaliśmy wersję systemu 2.6.19. Następnie trzeba pobrać dwie łatki rozwojowe 2.6.20-rc1 i 2.6.20-rc1-git1, aplikujemy je w podanej kolejności. Prawda że proste? Ale żmudne - dlatego ludzie, którzy nie lubią marnować czasu, stosują narzędzie nazywające się ketchup http://www.selenic.com/ketchup/.
Więcej o aplikowaniu i ściąganiu łatek można przeczytać w plikach:
Documentation/applying-patches.txt oraz README znajdujących się w źródłach jądra.

Jeśli podczas nakładania łatki zobaczymy komunikat „patch: **** malformed patch at line” np.

$ cat ../sched-2.patch | patch -p1 -R --dry-run
patching file kernel/sched.c
patch: **** malformed patch at line 33:                  if (next == rq->idle)

oznacza to, że łatka najprawdopodobniej została przeformatowana przez naszego klienta poczty - lub też kopiowaliśmy łatkę bezpośrednio ze strony archiwum LKML - wtedy najczęściej wszystkie wcięcia używane w kodzie źródłowym znikają. Na stronie http://marc.theaimsgroup.com/?l=linux-kernel wszystkie wiadomości są dostępne w postaci tekstowej (bez formatowania HTML) - wystarczy kliknąć na link „Download message RAW”.

1.3 Ketchup

Ketchup jest narzędziem, dzięki któremu możemy w prosty i szybki sposób pobrać najnowszą wersję interesującego nas jądra systemu. Robi to w całkiem inteligentny sposób, sprawdza aktualną wersję i pobiera tylko wymagane łatki. Jeżeli używamy Debiana testing/unstable, to po prostu instalujemy pakiet ketchup przy pomocy naszego ulubionego narzędzia np.

# apt-get install ketchup

dostępny, to najłatwiej będzie wykonać:

$ mkdir ~/bin (jeżeli nie mamy bin w katalogu domowym)
$ cd ~/bin
$ wget http://www.selenic.com/ketchup/ketchup-0.9.8.tar.bz2
$ tar xjvf ketchup-0.9.8.tar.bz2

Musimy także mieć zainstalowany pakiet python.
Należy pamiętać o tym, że ketchup potrafi sprawdzać sygnatury łatek, a więc odwiedzamy stronę http://www.kernel.org/signature.html zapisujemy aktualny klucz do jakiegoś pliku tekstowego ($ gpg —keyserver wwwkeys.pgp.net —recv-keys 0x517D0F0E jakoś nigdy u mnie nie działało) i robimy:

$ gpg --import plik_z_kluczem_kernel.org

Teraz możemy sprawdzić jak to wszystko działa:

$ mkdir ~/tree
$ cd ~/tree
$ ketchup -m

Powinien pojawić się taki błąd:

Traceback (most recent call last):
  File "/usr/bin/ketchup", line 695, in ?
     lprint(get_ver("Makefile"))
   File "/usr/bin/ketchup", line 160, in get_ver
      m = open(makefile)
 IOError: [Errno 2] No such file or directory: ’Makefile’

Oznacza to tylko i wyłącznie tyle, że nie mamy w tym katalogu żadnego drzewa Linuksa. Poleceniem „ketchup 2.6-tip” pobieramy najnowszą wersję drzewa „stable”:

$ ketchup 2.6-tip
None -> 2.6.16.1
Unpacking linux-2.6.15.tar.bz2
Applying patch-2.6.16.bz2
Downloading patch-2.6.16.1.bz2
--21:11:47-- http://www.kernel.org/pub/linux/kernel/v2.6/patch-2.6.16.1.bz2
            => ‘/home/michal/.ketchup/patch-2.6.16.1.bz2.partial’
Translacja www.kernel.org... 204.152.191.5, 204.152.191.37
Connecting to www.kernel.org|204.152.191.5|:80... połączono.
Żądanie HTTP wysłano, oczekiwanie na odpowiedź... 200 OK
Długość: 5,284 (5.2K) [application/x-bzip2]
100%[====================================>] 5,284           6.19K/s
21:11:49 (6.18 KB/s) - ‘/home/michal/.ketchup/patch-2.6.16.1.bz2.partial’
saved [5284/5284]
Downloading patch-2.6.16.1.bz2.sign
--21:11:49-- http://www.kernel.org/pub/linux/kernel/v2.6/
patch-2.6.16.1.bz2.sign
           => ‘/home/michal/.ketchup/patch-2.6.16.1.bz2.sign.partial’
Translacja www.kernel.org... 204.152.191.37, 204.152.191.5
Connecting to www.kernel.org|204.152.191.37|:80... połączono.
Żądanie HTTP wysłano, oczekiwanie na odpowiedź... 200 OK
Długość: 250 [application/pgp-signature]
100%[====================================>] 250            --.--K/s
21:11:49 (18.34 MB/s) - ‘/home/michal/.ketchup/
patch-2.6.16.1.bz2.sign.partial’ saved [250/250]
Verifying signature...
gpg: Signature made wto 28 mar 2006 09:37:31 CEST using DSA key ID 517D0F0E
gpg: Good signature from "Linux Kernel Archives Verification Key
 <ftpadmin@kernel.org>"
gpg: OSTRZEŻENIE: Ten klucz nie jest poświadczony zaufanym podpisem!
gpg:           Nie ma pewności co do tożsamości osoby która złożyła podpis.
Odcisk klucza głównego: C75D C40A 11D7 AF88 9981 ED5B C86B A06A 517D 0F0E
Applying patch-2.6.16.1.bz2

Teraz wydajemy polecenie „ketchup -m” aby sprawdzić, czy rzeczywiście mamy najnowsze stable:

$ ketchup -m
2.6.16.1

Jak widać, ketchup w razie potrzeby pobiera potrzebne łatki, inne bierze z folderu ~/.ketchup, znajdującego się w naszym katalogu domowym - więc dobrym pomysłem będzie wrzucenie tam łatek, które aktualnie już posiadamy. Przejście do konkretnej wersji drzewa nie stanowi dla ketchup’a żadnego problemu. Po prostu wpisujemy „ketchup wersja_drzewa” np.

$ ketchup 2.6.16-rc4-mm1
2.6.16.1 -> 2.6.16-rc4-mm1
Applying patch-2.6.16.1.bz2 -R
Applying patch-2.6.16.bz2 -R
Applying patch-2.6.16-rc4.bz2
Applying 2.6.16-rc4-mm1.bz2

lub, gdy chcemy najnowsze drzewo -rt

$ ketchup 2.6-rt
ketchup 2.6-rt
2.6.16-rc4-mm1 -> 2.6.16-rt12
Applying 2.6.16-rc4-mm1.bz2 -R
Applying patch-2.6.16-rc4.bz2 -R
Applying patch-2.6.16.bz2
Applying patch-2.6.16-rt12

Narzędzie automatycznie nakłada/wyrzuca łatki.

Aby pobrać archiwum z łatkami wchodzącymi w skład ostatniego -mm, powinniśmy wykonać

$ wget -c ‘ketchup -u 2.6-mm | sed "s/.bz2/-broken-out.tar.bz2/"‘

Wybrane drzewa:
• 2.6-tip - aktualne stabilne wydanie Linuksa
• 2.6-rc - najnowsza wersja rozwojowa -rc
• 2.6-git - najnowsza wersja rozwojowa -git
• 2.6-rt - drzewo Ingo Molnara
• 2.6-mm - drzewo Andrew Mortona
• 2.6-ck - drzewo Cona Kolivasa (desktop)
• 2.6-cks - drzewo Cona Kolivasa (serwer)

Po co w takim razie wypisywałem te wszystkie polecenia służące do nakładania/odwracania łatek? Powód jest bardzo prosty - jak znajdziemy i zgłosimy błąd, to dostaniemy do przetestowania poprawkę, którą powinniśmy umieć poprawnie nałożyć.

1.4 Drzewa

Często spotkamy się z pojęciem „drzewo jądra” (ang. kernel tree). Co to takiego? Drzewo, jest to zbiór łatek posiadający swoją własną nazwę np. drzewo -mm, -rt dający się nałożyć na konkretną wersję systemu. Do popularniejszych drzew można zaliczyć:
• Drzewo -mm (prowadzone przez Andrew Mortona) jest zbiorem innych mniejszych drzew i eksperymentalnych łatek.
• Drzewo -rt (prowadzone przez Ingo Molnara) - znajdują się w nim łatki zamieniające Linuksa w system ograniczony czasowo (Real Time).
• Drzewo -ck (prowadzone przez Cona Kolivasa) - skupia się na poprawianiu wydajności systemu.

Praktycznie każdy deweloper, oraz podsystem jądra posiada swoje drzewo nad którym prowadzone są prace. Po pewnym czasie różne części drzew wchodzą do drzewa „surowego”, prowadzonego przez Linusa Torvaldsa.

1.5 Drzewo -mm

Jak już wcześniej wspomniałem, drzewo -mm „ jest zbiorem innych mniejszych drzew i eksperymentalnych łatek”, to właśnie w nim przebiega główna linia frontu walki z błędami w Linuksie. Zrozumienie znaczenia tego drzewa ułatwi schemat przepływu łatek, a jest on następujący (przynajmniej tak to wygląda w teorii) drzewo -mm - drzewa podsystemów - drzewo Linusa.

Nowe łatki wysyłane przez deweloperów, albo są włączane od razu do drzewa danego podsystemu, albo najpierw trafiają do -mm (jeżeli trafią od razu do drzewa podsystemu, to i tak zostaną przetestowane w -mm, ponieważ właśnie z tych drzew się ono składa). Andrew Morton łączy wszystkie drzewa w jedną spójną całość, którą następnie wypuszcza do przetestowania.

Drzewo -mm jest zawsze dostępne w postaci pojedynczej łatki i zbioru wszystkich, z których zostało złożone (razem z poprawkami, które wprowadził Andrew). Ułatwia to odnajdywanie łatek wprowadzających błędy (więcej informacji o quilt i przeszukiwaniu binarnym można znaleźć w rozdziale czwartym). W katalogu, w którym umieszczone są łatki (na kernel.org) znajdziemy podkatalog hot-fixes - przed przystąpieniem do kompilacji warto zawsze do niego zajrzeć i pobrać poprawki, które się w nim znajdują.

Łatki włączane i wyrzucane z drzewa -mm są wysyłane na listę mm-commits. Jej śledzenie pozwoli nam na zorientowanie się w aktualnej jego zawartości, oraz ułatwi odnajdywanie łatek, które wprowadziły nowe błędy.

Od czasu do czasu Andrew wysyła na mm-commits list zatytułowany „mm snapshot broken-out-data-godzina.tar.gz uploaded” jest to najnowsza migawka drzewa -mm przeznaczona głównie dla ludzi, którzy chcą pomóc w jego „poskładaniu”.

1.6 Kompilacja, przygotowanie systemu testowego

Powinniśmy zacząć od przygotowania środowiska do pracy, potrzebne nam będą: gcc, make, binutils, util-linux, pakiet z plikami nagłówkowymi ncurses (libncurses5-dev w Debianie lub ncurses-devel w Fedorze). Plik Documentation/Changes w katalogu ze źródłami systemu zawiera spis wszystkich niekoniecznie wymaganych programów. Poniższe polecenia należy wykonać z uprawnieniami administratora.

# groupadd kernel
# mkdir /usr/src/kernel
# chgrp kernel /usr/src/kernel
# chmod 775 /usr/src/kernel/
# usermod -G kernel <login>

Pierwsze polecenie tworzy nową grupę nazywająca się „kernel”, następnie tworzymy katalog roboczy, zmieniamy uprawnienia dostępu do katalogu tak, aby użytkownicy należący do grupy „kernel” mieli w nim prawo do zapisu. Ostatnie polecenie dodaje nasze konto do świeżo utworzonej grupy. Jeżeli używamy systemu opartego na Debianie, to polecenie „usermod -G src <login>” doda nasze konto do grupy src, która ma już prawo do zapisu w /usr/src.

Warto zwrócić uwagę na to, że po pewnym czasie nasz katalog /usr/src/kernel może zajmować kilka gigabajtów, więc może powinniśmy go umieścić w jakimś innym miejscu.
Aby skompilować jądro musimy wykonać sekwencję poleceń:

make oldconfig - przetwarza nasz stary plik konfiguracyjny (nazywający się po prostu .config (na początku nazwy jest kropka - plik jest plikiem ukrytym)) i wyświetla zapytania czy chcemy użyć nowych opcji, sterowników etc.

make menuconfig - pozwala zmienić konfigurację - instrukcja krok po kroku jak przeprowadzić konfigurację jądra znajduje się pod adresem: http://kompilacja_jadra_linuxa_26.xt.pl/

make - kompilujemy jądro systemu

make modules_install - instalujemy wybrane moduły w /lib/modules/wersja

cp arch/i386/boot/bzImage /boot/vmlinuz-2.6.x.y - kopiujemy jądro do katalogu /boot

cp System.map /boot/System.map-2.6.x.y - kopiujemy mapę symboli do katalogu /boot

Na początku, gdy nie wiemy jeszcze co włączyć a co wyłączyć w pliku konfiguracyjnym naszego jądra, można skorzystać z konfiguracji jądra dystrybucyjnego (przeważnie zawiera mnóstwo nie potrzebnych nam rzeczy, dlatego też warto się nauczyć konfigurować jądro ;)).

$ zcat /proc/config.gz > .config
$ make oldconfig

Kilka przydatnych opcji:
make O=/katalog/ - zapisuje wynik kompilacji w innym katalogu. Opcja bardzo przydatna, szczególnie, gdy nie chcemy sobie zaśmiecać katalogu z jądrem plikami *.o. (Trzeba wtedy też używać zmodyfikowanych wersji „make O=/katalog menuconfig”, „make O=/katalog oldconfig”, „make O=/katalog modules_install” itd.).

make CC= - możemy podać nazwę naszego kompilatora gcc, np. w debianie mamy do dyspozycji kilka wersji gcc, gdy chcemy kompilować jądro wersją 3.4 wystarczy wpisać „make CC=gcc-3.4”.

make C=1 - przed kompilacją źródła są sprawdzane przez sparse.

make -j<liczba> - możemy podać, ile jednocześnie procesów gcc chcemy uruchomić. Na maszynach SMP przyśpiesza to proces kompilacji.

make xconfig - konfiguracja w trybie graficznym (qt).

make gconfig - konfiguracja w trybie graficznym (gtk).

Po wybraniu opcji:

Loadable module support --->
[*] Enable loadable module support
[*]     Automatic kernel module loading}}

będziemy mogli korzystać z tak zwanych modułów. Są to fragmenty kodu, które nie są wbudowywane w jądro na stałe. Dzięki modularyzacji jądro może być znacznie mniejsze, przez co może działać szybciej. Aby skompilować wybrany fragment kodu jako moduł musimy oznaczyć go literą „M” podczas konfiguracji np.

<M>     Check for non-fatal errors on AMD Athlon/Duron / Intel Pentium 4

Jeśli wcześniej wybraliśmy opcję „Automatic kernel module loading”, to moduły powinny być ładowane przez jądro automatycznie wtedy, gdy będą potrzebne - czyli, jeżeli chcemy zamontować płytę cd-rom, to zostanie załadowany moduł isofs.ko. Do ręcznego ładowania i wyładowywania modułów można użyć polecenia modprobe (lub insmod, rmmod)
modprobe isofs - załaduje moduł isofs.ko

modprobe -r isofs - usunie moduł isofs.ko

Wszystkie moduły jakie są aktualnie dostępne dla naszego systemu możemy znaleźć w podkatalogach /lib/modules/<wersja_jądra>/kernel.
Podczas konfiguracji jądra warto zwrócić uwagę na opcje znajdujące się w menu Kernel hacking Powinniśmy włączyć przynajmniej:

[*] Kernel debugging
[*]    Compile the kernel with debug info

Poniższe opcje służą do debugowania konkretnej funkcjonalności jądra, w miarę możliwości powinniśmy włączyć je wszystkie (niektóre mogą znacznie obniżyć szybkość działania systemu)

[*]    Debug shared IRQ handlers
[*]    Detect Soft Lockups
[*]    Debug slab memory allocations
[*]      Slab memory leak debugging
[*]    RT Mutex debugging, deadlock detection
[*]    Built-in scriptable tester for rt-mutexes
[*]    Lock debugging: prove locking correctness
[*]    Lock dependency engine debugging
[*]    Locking API boot-time self-tests
[*]    Highmem debugging
[*]    Debug VM

Bardzo użyteczną funkcją jest

[*] Magic SysRq key

Często pozwala ograniczyć skutki błędu jądra, oraz może służyć do uzyskania dodatkowych informacji o stanie systemu. Oferuje nam skróty klawiaturowe, które pozwalają wykonać ściśle określone instrukcje:
Alt + SysRq + h - wyświetla pomoc
Alt + SysRq + b - natychmiastowy restart systemu, bez odmontowania dysków i zapisania buforów. NIEBEZPIECZNE!
Alt + SysRq + c - crashdump
Alt + SysRq + e - wysyła sygnał TERM do wszystkich procesów z wyjątkiem procesu INIT
Alt + SysRq + i - wysyła sygnał KILL do wszystkich procesów z wyjątkiem procesu INIT
Alt + SysRq + k - sekwencja SAK (Secure Access Key), zabicie wszystkich procesów na danej konsoli, np. awaryjne wyłączenie XWindow, gdy Ctrl+Alt+Backspace zawiedzie
Alt + SysRq + l - wysyła sygnał KILL do wszystkich procesów, z procesem INIT włącznie, skutkuje zatrzymaniem systemu
Alt + SysRq + m - informacja o pamięci
Alt + SysRq + o - wyłączenie systemu
Alt + SysRq + p - wyświetla zawartość rejestrów i flag procesora
Alt + SysRq + r - przełącza klawiaturę w tryb RAW - gdy np. Ctr+Alt+Del nie działa
Alt + SysRq + s - synchronizacja dysków i zapisania zawartości buforów dysków
Alt + SysRq + t - lista wszystkich zadań
Alt + SysRq + u - przemontowanie wszystkich systemów plików w trybie „tylko do odczytu”

SysRq, który to klawisz?
• x86 - Print Screen
• SPARC - STOP
• szeregowa konsola - Break
• PowerPC - PrintScreen (lub F13)
• Wszystkie - echo t > /proc/sysrq-trigger

Jak najbezpieczniej restartować komputer?
Najpierw powinniśmy spróbować Ctrl + Alt + Backspace (XWindow) lub Ctrl + Alt + Del
(konsola). Gdy to zawiedzie, to:
• aby zabić wszystkie procesy na danej konsoli: Alt+SysRq+k
• aby bezpiecznie zrestartować komputer: Alt+SysRq+s Alt+SysRq+u Alt+SysRq+b
Więcej informacji na temat „Magic SysRq key” można znaleźć w pliku Documentation/sysrq.txt.

W niektórych dystrybucjach (lub jeżeli skompilowaliśmy sterowniki naszego kontrolera SCSI / IDE / SATA albo system plików używany na / jako moduł) musimy wygenerować tzw. initrd. Powinno to za nas załatwić wydanie polecenia

$ make install

Jeżeli używamy grub, to plikiem konfiguracyjnym jest /boot/grub/menu.lst. Wpisujemy do niego:

title Linux 2.6.wersja
         root (hd0,0)
         kernel /boot/vmlinuz-2.6.wersja ro root=/dev/<nasza partycja />
#        Jeżeli używamy initrd
#        initrd /boot/initrd-2.6.wersja.img

Użytkownicy lilo powinni w pliku /etc/lilo.conf wpisać

image=/boot/vmlinuz-2.6.wersja
label=linux
initrd=/boot/initrd-2.6.wersja.img
read-only
root=/dev/<nasza partycja />

Następnie trzeba powiadomić lilo o zmianie konfiguracji

$ sudo /sbin/lilo

Powyższe kroki mogą już być wykonane przez skrypt instalacyjny jądra dostępny w naszej dystrybucji. Więcej informacji na temat konfiguracji bootloaderów można znaleźć w „man lilo.conf” i „info grub”.
Poniżej znajduje się skrypt, dzięki któremu można pobrać, skompilować i zainstalować najnowsze jądro -stable. Skrypt jest dość uniwersalny, łatwo też jest dostosować go do własnych potrzeb.

#! /bin/sh
# Ścieżka do katalogu ze źródłami jądra
SRC_PATH="/usr/src/kernel/linux-stable"
OBJ_PATH="$SRC_PATH-obj/"
cd $SRC_PATH
# Pobieramy najnowsze -stable
ketchup 2.6
# Zapamiętujemy wersję
VER=‘ketchup -m‘
# Odświeżamy konfigurację
make O=$OBJ_PATH oldconfig
# Budujemy jądro
make O=$OBJ_PATH
# Instalujemy moduły
sudo make O=$OBJ_PATH modules_install
# Kopiujemy skompresowany obraz jądra do /boot
sudo cp $OBJ_PATH/arch/i386/boot/bzImage /boot/vmlinuz-$VER
# Kopiujemy System.map do /boot
sudo cp $OBJ_PATH/System.map /boot/System.map-$VER
# Jeżeli używamy Fedory, to trzeba wygenerować fedorowe initrd
# sudo /sbin/new-kernel-pkg --make-default --mkinitrd --depmod --install $VER

Poniżej zamieszczam odsyłacze do instrukcji budowania jądra metodą konkretnych dystrybucji
CentOS http://www.howtoforge.com/kernel_compilation_centos (ang.)
Debian http://www.debian.org/doc/manuals/reference/ch-kernel.pl.html
http://www.howtoforge.com/howto_linux_kernel_2.6_compile_debian (ang.)
Fedora http://www.howtoforge.com/kernel_compilation_fedora (ang.)
Gentoo http://www.gentoo.org/doc/pl/kernel-upgrade.xml
Mandriva http://www.howtoforge.com/kernel_compilation_mandriva (ang.)
OpenSUSE http://www.howtoforge.com/kernel_compilation_suse (ang.)
Ubuntu http://www.howtoforge.com/kernel_compilation_ubuntu (ang.)

Więcej informacji o arkanach konfiguracji i kompilacji jądra można znaleźć w książce Grega Kroah-Hartmana „Linux Kernel in a Nutshell ” http://www.kroah.com/lkn/

Linux posiada bardzo specyficzny model rozwoju - niespotykany w innych projektach otwartych czy zamkniętych, dlatego warto zapoznać się z zasadami nim rządzącymi http://www.stardust.webpages.pl/ltg/wiki/index.php/Proces_rozwoju_j%C4%85dra_Linux
Krótkie wskazówki:
• wpisz „make help” i przyjrzyj się dostępnym opcjom
• w menu „Kernel hacking —->” można znaleźć wiele użytecznych opcji
• zapoznaj się z opcjami skryptu ketchup

O ile nie zaznaczono inaczej, treść tej strony objęta jest licencją Creative Commons Attribution-Share Alike 2.5 License.