Do kompilacji i instalacji nowego jądra należy się dokładnie przygotować. Musimy wiedzieć, jaki sprzęt znajduje się w naszym komputerze, pobrać źródła jądra z Internetu lub z płyty CD. Następnie jądro rozpakować i ewentualnie załatać. Równie ważne jest sprawdzenie zależności, czyli czy posiadamy wszystkie niezbędne programy do skompilowania i poprawnego działania nowego jądra. Jeśli posiadamy dość nową dystrybucję działającą już na jądrze 2.6.X nie będzie to konieczne, jednak na jednej z starszych dystrybucji prawdopodobnie konieczne będzie doinstalowanie części programów.

        Opiszę tutaj pokrótce czynności, jakie musimy wykonać i co będzie nam niezbędne jeszcze przed konfiguracją i kompilacją jądra.
2.1. Poznanie własnego sprzętu
        Przede wszystkim musimy poznać nasz własny komputer. Jest to nam niezbędne do utworzenie jądra pod nasz sprzęt. Możemy dokonać tego na kilka sposobów. Przede wszystkim możemy skorzystać z instrukcji, jeśli ją posiadamy. Innym sposobem jest komenda lspci wydana w konsoli. Pokazuje ona, jaki sprzęt jest podłączony do komputera. Jeszcze innym sposobem jest skorzystanie z jakiegoś narzędzia diagnostycznego pod systemem Windows jak np. AIDA, Sandra, Everest.

        Najważniejsze rzeczy, jakie musimy znać to typ naszego procesora, układ (chipset) płyty głównej, ewentualne dodatkowe kontrolery IDE, jakie posiadamy kartę graficzną, karty sieciowe i kartę muzyczną. Przydatna może być też znajomość naszego monitora, chociaż monitora nie wybieramy w konfiguracji jądra jego parametry podajemy w czasie konfiguracji serwera X Windows. Ilość pamięci RAM i typ procesora możemy odnaleźć w BIOSie płyty głównej w czasie uruchamiania się systemu.

        Podam tutaj dla przykładu własną konfigurację komputera, jaką można odnaleźć w zależności od wykorzystanego systemu operacyjnego. Dla porównania zamieszczę tutaj wyniki sprawdzania sprzętu w systemie operacyjnym Windows i Linux.

- Windows: Do sprawdzenie, jaki sprzęt posiadamy zalecam zastosowanie jednego z wymienionych wcześniej programów, wszystkie one są darmowe i bez problemu możemy je znaleźć w Internecie. Wprawdzie można skorzystać z menadżera urządzeń, lecz jego informacje są nie szczegółowe i niedokładne. Wykorzystałem tutaj program EVEREST Home Edition v1.51.195.
Typ podzespołu    Podzespół
    Procesor
Typ procesora    AMD Athlon XP, 1666 MHz (10 x 167) 2000+
Zbiór instrukcji    x86, MMX, 3DNow!, SSE
    Płyta główna
Nazwa płyty głównej    Asus A7N8X-E Deluxe
Mikroukład płyty głównej    nForce2-U400
Urządzenia zintegrowane    Audio, Gigabit LAN
Kontroler IDE    NVIDIA nForce2 ATA Controller (v2.6)
    Karta graficzna
Karta wideo    nVIDIA GeForce4 Ti 4200
    Karta muzyczna
Typ    nVIDIA MCP2 - Audio Codec Interface
Typ    nVIDIA MCP2 - Audio Processing Unit
    Karty sieciowe
Karta sieciowa 1    Marvell Yukon 88E8001 Gigabit Ethernet Adapter
Karta sieciowa 2    Realtek RTL8139 Fast Ethernet Adapter
    Monitor
Największa rozdzielczość    1280 x 1024
Odświeżanie poziome    31 - 64 kHz
Odświeżanie pionowe    59 - 61 Hz
    Pamięć fizyczna
W sumie    1023 MB
    Dodatkowy kontroler IDE
Chipset kontrolera    Silicon Image Sil 0680, zgodny z CMD 680
Tabelka 2.1.1 Przykładowe wyszukiwanie sprzętu w programie EVEREST na systemie Windows
        W tabelce pokazałem, jakich ważnych dla nas danych musimy szukać. W drugiej części tabelki przedstawiłem posiadany przeze mnie dodatkowy kontroler IDE, dane spisałem z instrukcji, gdyż sterowniki jego nie są zainstalowane pod system Windows.

- Linux:         Do sprawdzania podłączonego sprzętu pod Linuxem służy komenda lspci. Dla porównania z odnajdywaniem sprzętu w programie EVEREST pod systemem Windows podałem tutaj wynik komendy lspci pod systemem Linux. Komenda ta nie pokazuje ilości pamięci i typu procesora. Dane te jednak podawane są przez BIOS płyty głównej w czasie uruchamiania komputera. Dane dotyczące monitora, których ta komenda także nie wyświetla musimy poszukać w instrukcji.

        Dla łatwiejszego przedstawienie skróciłem część opisów i skróciłem listę do odpowiednich wyników z tabelki 2.1.1.

Lspci:
    Płyta główna
Mostek AGP (Host bridge)    nVidia Corporation nForce2 AGP
Mostek ISA (ISA bridge)    nVidia Corporation nForce2 ISA Bridge
Nazwa płyty głównej podana przy mostku ISA    Subsystem: Asustek Computer, Inc. A7N8X Mainboard
Mostek PCI (PCI bridge)    nVidia Corporation nForce2 External PCI Bridge
Interfejs IDE (IDE interface)    nVidia Corporation nForce2 IDE
    Karta graficzna
Karta wideo (VGA compatible controller)    nVidia Corporation NV25 [GeForce4 Ti 4200]
    Karta muzyczna
Multimedia audio controller    nVidia Corporation nForce MultiMedia audio
Multimedia audio controller    nVidia Corporation nForce2 AC97 Audio Controler (MCP)
    Karty sieciowe
Karta1 (Ethernet controller)    Marvell Yukon Gigabit Ethernet
Karta 2 (Ethernet controller)    Realtek Semiconductor RTL-8139/8139C/8139C+
    Dodatkowy kontroler IDE
Chipset kontrolera (RAID bus controller)    CMD Technology Inc PCI0680
Tabelka 2.1.1 Przykładowe wyszukiwanie sprzętu używając komendy lspci na systemie Linux
        Aby sprawdzić, jaki system plików obecnie używamy i musimy go wkompilować wydać możemy komendę mount.

Powinno się wyświetlić coś jak:
        /dev/hda1 on / type ext2
        /dev/hda3 on /usr type ext2
        none on /proc type proc
        /dev/fd0 on /mnt type msdos [3]

        Widzimy tutaj (pogrubiłem i podkreśliłem ważne dla nas dane), że mamy zamontowane obecnie systemy plików ext2 na partycji hda1 i hda3. System plików msdos na stacji dysków. System plików katalogu root (/) powinniśmy wkompilować w jądro na stałe. Co prawda można wykorzystać do tego dysk RAM initrd, lecz nie ma sensu marnować pamięci na dysk RAM tylko dla tego celu, gdyż i tak za każdym razem moduł ten będzie ładowany przy starcie systemu. Dysk RAM initrd zastosować możemy, jeśli jądro będzie wykorzystywać większa ilość komputerów a sterowniki mamy w formie modułów. Wszystkie moduły ładowane są bezpośrednio z dysku RAM, który przed uruchomieniem systemu montowany jest jako główny system plików.
2.2. Pobieranie źródeł jądra
        Aby przystąpić do kompilacji jądra musimy najpierw pobrać źródła jądra znaleźć je możemy na stronie www.kernel.org. Znaleźć tam możemy również łaty, które dodadzą do naszego jądra funkcje z nowszych wersji. Jądro możemy, także znaleźć na płytach naszej dystrybucji Linuxa, powinno tam być standardowe jądro dystrybucji jak i źródła jądra. Ze stron internetowych naszej dystrybucji możemy nieraz pobrać pakiety z źródłami jądra lub też z skompilowanym już jądrem. W niektórych czasopismach na dołączanych płytach CD znaleźć nieraz, także można źródła jądra. Skupie się tutaj na pobieraniu źródeł z strony www.kernel.org.

Źródło jądra na stronie www.kernel.org
Rysunek 2.2.1. Źródło jądra na stronie www.kernel.org

Na rysunku 2.2.1 widzimy przykładowy wpis, oznaczone na nim miejsca oznaczają:
        1 - Numer jądra oznacza najnowszą stabilną łatę do pobrania.
        2 - F oznacza pełne stabilne źródła jądra do pobrania.
        3 - V to krótki opis zmian dokonywanych przez łatę z pod.
        4 - VI to krótki opis zmian pomiędzy obecną łatą a poprzednią.
        5 - C to dokładny opis zmian w łatach publikowanych na stronie.
        6 - Changelog to szczegółowy opis zmian w obecnej łacie w stosunku do poprzedniej.
2.3. Dekompresja źródeł jądra
        Pobrane źródła jądra rozpakowujemy komendą tar -xvjf nazwa_katalogu_jądra i przenosimy do katalogu /usr/src/ komendą mv nazwa_katalogu_jądra /usr/src/. Opcja -x i -f polecenia tar dekompresuje archiwum, -v wyświetla informacje o rozpakowywanych plikach a -j dekompresuje archiwum w formacie bzip2.

        Po zakończeniu wyświetlania komunikatów źródła jądra zostaną rozpakowane. Możemy też zrobić to w Midnight Commander, komendą mc, otwieramy w jednym oknie spakowane źródła, a w drugim przechodzimy do katalogu /usr/src i kopiujemy do niego za pomocą przycisku F5 źródła jądra.
2.4. Sprawdzanie zależności
        Przed rozpoczęciem kompilacji należy sprawdzić czy nasz system posiada niezbędne do kompilacji pakiety. Niezbędne pakiety razem z metodami ich sprawdzenia zostały podane w źródłach jądra w Documentation/Changes. Np. dla jądra 2.6.8.1 wygląda to następująco:
Pakiet    minimalna wersja    metoda sprawdzenia
Gnu C    2.95.3    # gcc --version
Gnu make    3.79.1    # make --version
binutils    2.12    # ld -v
util-linux    2.10    # fdformat --version
module-init-tool    0.9.10    # depmod -V
e2fsprogs    1.29    # tune2fs
jfsutils    1.1.3    # fsck.jfs -V
reiserfsprogs    3.6.3    # reiserfsck -V 2>&1|grep reiserfsprogs
xfsprogs    2.6.0    # xfs_db -V
pcmcia-cs    3.1.21    # cardmgr -V
quota-tools    3.09    # quota -V
PPP    2.4.0    # pppd --version
isdn4k-utils    3.1pre1    # isdnctrl 2>&1|grep version
nfs-utils    1.0.5    # showmount --version
proces    3.2.0    # ps --version
profile    0.5.3    # oprofiled -version

        Nie wszystkie pakiety są potrzebne w każdym systemie, gdy np. nie wykorzystujemy PCMCIA nie musimy się przejmować pcmcia-cs. Do ułatwienia sprawdzania zależności w źródłach jądra w katalogu scripts, znajduje się skrypt ver_linux, który wyświetla nam zależności. [9]

U mnie skrypt dał taki wynik:
Linux JarekM 2.6.8.1-STABILNA #1 Thu Oct 21 20:53:29 CEST 2004 i686 athlon i386 GNU/Linux
Gnu C    3.2.2
Gnu make    3.79.1
binutils    2.13.90.0.18
util-linux    2.11y
mount    2.11y
module-init-tools    3.0
e2fsprogs    1.32
jfsutils    1.0.17
reiserfsprogs    3.6.8
pcmcia-cs    3.1.31
quota-tools    3.06.
isdn4k-utils    3.1pre4
Linux C Library    2.3.2
Dynamic linker    2.3.2
Proces    2.0.11
Net-tools    1.60
Kbd    1.08
Sh-utils    4.5.3
2.5. Łatanie jądra
        Jeśli posiadamy jakieś łaty (patche) dla jądra to należy wykorzystać je teraz. Aby załatać jądro należy wejść do katalogu z jego źródłami i wydać w konsoli komendę patch -p1 < katalog_z_łatą/nazwa_łaty. Opcja -p+liczba komendy patch pomija podaną przez liczbę ilość katalogów w pliku z łatą, np. jeśli łata przygotowana była dla katalogu /usr/src/linux-2.6.8.1 to opcja -p1 pominie katalog linux-2.6.8.1. Jeśli już został nałożony jakąś łatę na jądro może nie udać nam się nałożyć innej, lub mogą wystąpić komplikacje opisane poniżej. [10]

        Może też się zdarzyć, że łata została źle napisana lub nie jest prawidłowa z powodu nałożonej przed nią łaty, mogą wystąpić wtedy poniższe błędy:
Hunk #3 FAILED at 508
        - komunikat ten oznacza, że trzeciej łaty z zestawu nie udało się nałożyć. Wystąpił błąd w linii 508.
Hunk #4 succeeded at 581 (offset 10 lines)
        - ten komunikat oznacza, że łata czwarta została poprawnie nałożona, ale miejsce gdzie ona powinna zostać nałożona różni się o dziesięć linii w pliku docelowym.
1 out of 11 hunks FAILED -- saving rejects to file usr/src/nv/nv-linux.h.rej
        - komunikat ten to podsumowanie nakładania łat oznacza, że nie powidło się nałożenie jednej łaty z zestawu jedenastu łat. Odrzucona łata została zapisana w podanym pliku, w tym przypadku (usr/src/nv/nv-linux.h.rej).
W wypadku wystąpienia błędu możemy usunąć łatę poleceniem patch -p1 -R < katalog_z_łatą/nazwa_łaty. [11]