Login lub e-mail Hasło   

Kompilacja jądra Linux

Odnośnik do oryginalnej publikacji: http://jarekm3.ovh.org/
Prawdopodobnie każdy użytkownik systemu operacyjnego Linux, prędzej czy później stanie przed koniecznością kompilacji jądra systemu.
Wyświetlenia: 51.778 Zamieszczono 18/12/2006

1. Wprowadzenie

        Prawdopodobnie każdy użytkownik systemu operacyjnego Linux, prędzej czy później stanie przed koniecznością kompilacji jądra systemu. Wprawdzie dystrybucje dostajemy już z przygotowanym jądrem, które będzie działać poprawnie na większości komputerów i systemu takiego możemy bez problemu używać, lecz jądro z dystrybucji posiada zbyt wiele niepotrzebnych elementów nie przydatnych dla naszego systemu, zwalniających jego pracę i pochłaniających niepotrzebnie zasoby. Mimo że kompilacja jądra wymaga od nas podstawowej wiedzy o systemie Linux oraz dokładnej znajomości sprzętu, na którym pracujemy nie należy to do wielce trudnych zadań.
        Jądro systemu jest programem napisanym w języku C. Dostępne jest ono w postaci kodu źródłowego lub skompilowanych pakietów binarnych. Pakiety możemy wykorzystać od razu, lecz ze źródeł sami musimy zbudować własne jądro systemu. Do zbudowania jądra niezbędny jest kompilator, który tłumaczy program napisany w języku programowania na język zrozumiały dla komputera. Przekompilowanie jądra dostarczonego z dystrybucją pozwala na zwiększenie szybkości działania całego systemu. Natomiast jądra nowszej wersji posiadają poprawione błędy znalezione w wersji wcześniejszej i często zwiększoną ilość sterowników i funkcji.

        Celem pracy jest ułatwienie i opisanie jak najprostszym i zrozumiałym sposobem przeprowadzenie kompilacji jądra, przez osoby robiące to po raz pierwszy lub nieznające dostatecznie dobrze języka angielskiego do wyboru zestawu niezbędnych im sterowników. Drugim celem jaki sobie postawiłem jest stworzenie spolszczenia opcji konfiguracyjnych jądra, z których każdy mógłby korzystać bezpośrednio w czasie konfiguracji.

1.1. Czym jest jądro systemu

        Jądro systemu operacyjnego Linux stanowi jego podstawę. Znajdują się tam główne sterowniki i programy odpowiadające za działanie systemu. Każdy system komputerowy posiada zbiór programów, który nazywany jest systemem operacyjnym. Najważniejszym z tych programów jest jądro (kernel). Jądro jest ładowane do pamięci RAM w czasie uruchamiania systemu, zawiera ono wiele niezbędnych dla systemu procedur. Kształt i możliwości komputera opierają się na jego jądrze. Często słowa "system operacyjny" używa się w odniesieniu do jądra systemu. Jądro współdziała ze sprzętem poprzez programy niskiego poziomu. Dostarcza też środowisko dla aplikacji działających w systemie. Kiedy program chce wykorzystać zasoby sprzętowe, musi wystosować odpowiednie zapytanie. Jądro rozważa to zapytanie i wybiera czy, jak i kiedy użyczyć programowi potrzebnych mu zasobów.

        Jądro w systemach typu Unix odgrywa rolę pośrednika między programami, a sprzętem. Najpierw zajmuje się przydziałem pamięci dla wszystkich uruchomionych programów (procesów), i dba o to, aby wszystkie one dostały równą ilość czasu procesora. [1]

1.2. Rodzaje wersji jądra

        Istnieją dwa rodzaje dostępnych wersji jądra - stabilna (stable) i rozwojowa (development). Stabilna przeznaczone jest dla ludzi ceniących sobie niezawodność i stabilność systemu jak również jego bezproblemową obsługę. Natomiast wersje rozwojowe (developerskie) przeznaczone są dla ludzi zajmujących się rozwojem jądra, zawierają one często wiele nowych sterowników dla najnowszych urządzeń i wiele funkcji eksperymentalnych, które mogą zniknąć w następnym jądrze. Jądra te mogą także być niestabilne i powodować liczne problemy.

        Pierwsza liczba oznaczenia jądra przedstawia numer wersji, następna czy jądro jest stabilne (liczba parzysta) czy rozwojowe (liczba nieparzysta), ostatnia liczba określa natomiast numer wydania (rys. 1.2.1 i 1.2.2).
Opis numeracji wersji stabilnej jądra systemu operacyjnego Linux   Opis numeracji wersji rozwojowej jądra systemu operacyjnego Linux
Wynika z tego, że wersje stabilne to np. 2.2.40, 2.4.27, 2.6.9. Jądrami deweloperskimi będą np. 2.3.24, 2.5.75 i w przyszłości 2.7.1. [1]

FunkcjaJądro 2.4.XJądro 2.6.X
Maksymalna liczba obsługiwanych procesorów16255, NUMA (Non-Uniform Memory Access)
Maksymalny rozmiar RAM-u16 GB64 GB
Maksymalny rozmiar systemu plików2 TB16 TB
Obsługiwane systemy plików (odczyt i zapis)Ext2, Ext3, ReiserFS, JFS, HPFS, FFS, HFS+, MS DOS, FAT, VFAT, ISO9660Ext2, Ext3, ReiserFS, Reiser4, JFS, HPFS, FFS, HFS, HFS+, MS DOS, FAT, VFAT, ISO9660, NTFS, XFS
Sieciowe systemy plikówNFSv3, SMB, NCP, InterMezzo, CodaNFSv4, SMB, NCP, Intermezzo, Coda, AFS, CIFS
Rodzaje wątkówLinuxThreadsNPTL (wątki POSIX)
Obsługiwany format dźwiękuOSSALSA
Obsługa Hyper-threadingNieTak
Liczba możliwych urządzeń2554095
Tabelka 1.2.3 Różnice pomiędzy jądrami systemu operacyjnego Linux w wersji 2.4 a 2.6 [2]
        W tabeli 1.2.3 możemy zobaczyć główne różnice pomiędzy jądrami dwóch wersji. W jądrach z serii 2.6 zwiększono liczbę obsługiwanych jednocześnie procesorów do 255 w systemie NUMA. Zwiększyła się także ilość obsługiwanej pamięci RAM i rozmiaru systemu plików.

        W nowym jądrze dodano też obsługę większej ilości systemów plików obsługiwanych bezpośrednio przez jądro jak i obsługę większej liczby urządzeń. Znajduje się też nowy system obsługi dźwięku ALSA.

1.3. Co to są moduły

        Moduły - "Są to części jądra, które nie są zawarte bezpośrednio w nim. Kompiluje się je osobno i można je umieścić a następnie usunąć z uruchomionego jądra prawie zawsze. Z powodu tej elastyczności jest to teraz preferowana metoda pisania niektórych fragmentów jądra. Wiele popularnych sterowników urządzeń to ładowalne moduły." [3]
        Są to sterowniki różnych urządzeń, które nie są wkompilowane bezpośrednio w jądro. Jednak gdy zajdzie potrzeba użycia takiego sterownika zostaje on wtedy załadowany dynamicznie przez specjalny program ładujący bez przerywania pracy naszego systemu. Wszystkie moduły dostępne w naszym systemie znajdują się w katalogu /lib/modules/numer_wersji_naszego_jądra.
        Korzyść z użycia modułów jest taka, że przez ich zastosowanie otrzymujemy mniejsze i szybsze jądro, dzięki czemu nie trwonimy bez potrzeby zasobów naszego komputera, w razie gdy potrzebujemy raz na jakiś czas skorzystać z sterownika a mamy go jako moduł, możemy załadować go na czas pracy, a gdy już nie będzie nam potrzebny spokojnie możemy skasować go z pamięci. Jednak nie wszystkie sterowniki możemy użyć jako moduły, Linux potrzebuje część z nich jeszcze zanim zostaną one załadowane przez system, tak jest np. z obsługą dysku twardego czy systemu plików, aby system mógł się poprawnie uruchomić i obsłużyć posiadany przez nas sprzęt.

1.3.1. Zarządzanie modułami

        Modułami możemy zarządzać za pomocą poleceń:
insmod [nazwa modułu] - "instaluje ładowalny moduł w pracującym jądrze." [4]
depmod - "tworzy plik podobny do "Makefile" z zależnościami, bazujący na symbolach, które znalazł w zbiorze modułów podanych w linii komend (lub w standardowym miejscu). Plik zależności może być potem użyty przez modprobe, aby automatycznie załadować odpowiednie moduły." [5]
modprobe [nazwa modułu] - ładuje podany, szukając modułów w katalogu /lib/modules/"uname -r", oraz wszystkie inne moduły, od których jest zależny. [6]
rmmod [nazwa modułu] - "usuwa załadowany moduł z działającego jądra systemu." [7]
lsmod - "wyświetla informację o wszystkich załadowanych modułach." [8]
Istnieje też możliwość wykorzystanie do tego programu KMOD, który możemy skompilować zaznaczając specjalną opcję w czasie jego konfigurowania. Program ten będzie automatycznie ładował niezbędne moduły, lecz nie zawsze działa poprawnie i wtedy musimy załadować moduł ręcznie.

1.4. Co to są łaty (patche)

        Łaty (patche) - Są sposobem na dodawanie do jądra lub uaktualnianie sterowników lub funkcji. Nieraz po załataniu jądra, szczególnie nieoficjalnymi łatami może nie działać ono poprawnie, lub nawet może nie powieść się jego kompilacja. Łatać jądro powinniśmy jedynie wtedy, gdy jesteśmy pewni jego działania i do tego najlepiej na osobnej kopii źródeł jądra.

Istnieją łaty oficjalne i nieoficjalne:
- Łaty oficjalne możemy znaleźć na stronie www.kernel.org. Łaty te zostały zaakceptowane przez twórców jądra i pozwalają one aktualizować starszą wersję jądra na nowszą. Np. jądro 2.6.7 za pomocą łaty patch-2.6.8.bz2 zaktualizować jądro 2.6.7 do wersji 2.6.8. Łaty te, jeśli nie użyjemy wersji testowej z dopiskiem -rc i nakładamy na niezałatane wcześniej jądro działają poprawnie. Oprócz tego możemy także znaleźć codzienne zrzuty z czasu rozwoju jądra. Posiadają one dopisek -bk.
Ostatnio pojawiły się także łaty poprawiające błędy w stabilnej już wersji jądra. Posiadają one na końcu jeszcze jedna cyfrę, np. 2.6.8.1.

- Łaty nieoficjalne możemy znaleźć w różnych miejscach, zazwyczaj poprawiają one działanie jądra, aczkolwiek nie muszą zawsze działać poprawnie.

Linki do różnych łat do jądra w wersji 2.6:
http://programista.org/~snaj/.
http://kem.p.lodz.pl/~peter/cko/.
http://members.optusnet.com.au/ckolivas/kernel/.
http://omfg.linux.dk/pub/configurable-hid-mouse-polling/.
http://shfs.sourceforge.net/.
http://linux.bytesex.org/v4l2/.
http://www.bluez.org/.
http://fallow.fm.interia.pl/index.html.
http://kem.p.lodz.pl/~peter/qnet/.
http://relaks.info/linux/mq/testing/.
http://www.reactivated.net/patches/linux-kernel/.
http://www.bootsplash.org/.
http://www.kernel.org/pub/linux/kernel/people/.
http://people.redhat.com/mingo/.

Linki do łat do starszych wersji:
http://www.plumlocosoft.com/kernel/.
http://www.holtmann.org/linux/kernel/.
http://www.openwall.com/linux/.
http://www.kernel.org/pub/linux/kernel/people/bcrl/v2.4/.
http://www.kernel.org/pub/linux/kernel/people/benh/.
http://www.kernel.org/pub/linux/kernel/people/cw/Altix/.
http://www.kernel.org/pub/linux/kernel/people/hedrick/.
http://www.kernel.org/pub/linux/kernel/people/jgarzik/patches/.
http://surriel.com/patches/.

 

2. Czynności wstępne

        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łuPodzespół
 Procesor
Typ procesoraAMD Athlon XP, 1666 MHz (10 x 167) 2000+
Zbiór instrukcjix86, MMX, 3DNow!, SSE
 Płyta główna
Nazwa płyty głównejAsus A7N8X-E Deluxe
Mikroukład płyty głównejnForce2-U400
Urządzenia zintegrowaneAudio, Gigabit LAN
Kontroler IDENVIDIA nForce2 ATA Controller (v2.6)
 Karta graficzna
Karta wideonVIDIA GeForce4 Ti 4200
 Karta muzyczna
TypnVIDIA MCP2 - Audio Codec Interface
TypnVIDIA MCP2 - Audio Processing Unit
 Karty sieciowe
Karta sieciowa 1Marvell Yukon 88E8001 Gigabit Ethernet Adapter
Karta sieciowa 2Realtek RTL8139 Fast Ethernet Adapter
 Monitor
Największa rozdzielczość1280 x 1024
Odświeżanie poziome31 - 64 kHz
Odświeżanie pionowe59 - 61 Hz
 Pamięć fizyczna
W sumie1023 MB
 Dodatkowy kontroler IDE
Chipset kontroleraSilicon 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 ISASubsystem: 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 controllernVidia Corporation nForce MultiMedia audio
Multimedia audio controllernVidia 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:
Pakietminimalna wersjametoda sprawdzenia
Gnu C2.95.3# gcc --version
Gnu make3.79.1# make --version
binutils2.12# ld -v
util-linux2.10# fdformat --version
module-init-tool0.9.10# depmod -V
e2fsprogs1.29# tune2fs
jfsutils1.1.3# fsck.jfs -V
reiserfsprogs3.6.3# reiserfsck -V 2>&1|grep reiserfsprogs
xfsprogs2.6.0# xfs_db -V
pcmcia-cs3.1.21# cardmgr -V
quota-tools3.09# quota -V
PPP2.4.0# pppd --version
isdn4k-utils3.1pre1# isdnctrl 2>&1|grep version
nfs-utils1.0.5# showmount --version
proces3.2.0# ps --version
profile0.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 C3.2.2
Gnu make3.79.1
binutils2.13.90.0.18
util-linux2.11y
mount2.11y
module-init-tools3.0
e2fsprogs1.32
jfsutils1.0.17
reiserfsprogs3.6.8
pcmcia-cs3.1.31
quota-tools3.06.
isdn4k-utils3.1pre4
Linux C Library2.3.2
Dynamic linker2.3.2
Proces2.0.11
Net-tools1.60
Kbd1.08
Sh-utils4.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]

3. Konfiguracja jądra

        Gdy już wykonaliśmy wszystkie wcześniejsze czynności przy chodzi czas na najdłuższą część, czyli na konfiguracje jądra. Większość problemów z źle działającym lub nieuruchamiającym się jądrem wynikają z nieodpowiedniej konfiguracji. Powinniśmy zaznaczać tylko opcję nam niezbędne zwiększy to szybkość działania jądra i zmniejszy jego rozmiar, a także czas kompilacji.

3.1. Narzędzia konfiguracyjne jądra

        Jądro możemy kompilować w trybie tekstowym jak i graficznym wpisując odpowiednią komendę z konsoli bezpośrednio w katalogu głównym jądra. Konfiguracja jądra znajduje się w pliku .config w katalogu źródeł jądra. Nie należy konfigurować jądra bezpośrednio w tym pliku, ale za pomocą jednego z poniższych konfiguratorów do tego przeznaczonych.

- oldconfig: Jest to konsolowa konfiguracja starego typu gdzie odpowiadamy na pytania.
        Y - oznacza wkompilowanie opcji na stałe.
        N - Oznacza nie wkompilowywanie opcji.
        M - Oznacza wkompilowanie opcji jako moduł.
        ? - Oznacza wyświetlenie pomocy do opcji.

Sposób ten jest bardzo niewygodny i długotrwały.

- menuconfig (rys 3.1.1): Jest to konsolowy tryb konfiguracji, najbardziej przejrzysty i nie wymaga bibliotek graficznych ani serwera X. Opcje zaznaczyć możemy jako:
        [*] - oznacza wkompilowanie opcji na stałe.
        [ ] - Oznacza nie wkompilowywanie opcji.
        [M] - Oznacza wkompilowanie opcji jako moduł.

Menu programu menuconfig Rysunek 3.1.1. Menu programu menuconfig
Opcją select lub poprzez naciśnięcie spacji zmieniamy zaznaczenie opcji.Po wybraniu z menu Help lub po naciśnięciu przycisku ? poprzez jednoczesne naciśnięcie przycisków Shift + /, pojawia nam się opis funkcji. Przy wyjściu jesteśmy pytani czy chcemy zapisać konfigurację. Możemy ja zapisać lub odczytać pod inną nazwą, dzięki czemu możemy posiadać kilka konfiguracji jądra.

- xconfig (rys 3.1.2): Konfiguracja jądra w trybie graficznym za pomocą edytora napisanego w QT. Musimy mieć do tego sposobu konfiguracji uruchomiony serwer X Window. Opcje zaznaczyć możemy jako:
        Ptaszek - oznacza wkompilowanie opcji na stałe.
        [ ] - Oznacza nie wkompilowywanie opcji.
        Czarne kółko - Oznacza wkompilowanie opcji jako moduł.

Menu programu xconfig Rysunek 3.1.2 Menu programu xconfig
W menu file możemy wybrać opcję:
        Load - dzięki której możemy załadować konfigurację z dowolnego pliku.
        Save - która zapisuje konfigurację w katalogu z źródłem jądra.
        Save as - która zapisuje konfigurację w dowolnym miejscu i pod dowolna nazwą.
W poniższym menu ikonowym znajdują się:
        1 - jest to cofnięcie ostatniego wykonanego działania.
        2 - pozwala załadować konfigurację z dowolnego pliku.
        3 - zapisuje konfigurację w katalogu z źródłem jądra.

- gconfig (rys 3.1.3): Konfiguracja jądra w trybie graficznym za pomocą edytora napisanego w GTK. Musimy mieć do tego sposobu konfiguracji uruchomiony serwer X. W przypadku gconfig układ jest identyczny jak w przypadku xconfig.

Menu programu gconfig Rysunek 3.1.3 Menu programu gconfig 
  

4. Konfiguracja jądra

Opis konfiguracji jądra znajdziesz tutaj: http://jarekm3.ovh.org/index.php?strona=opis_konfiguracji.php&odw=1 .

 

4. Kompilacja jądra

        Po zakończeniu konfiguracji jądra przyszedł czas na końcowy proces, czyli na kompilację. Proces ten trwa w zależności od posiadanego przez nasz procesora, oraz ilości zaznaczonych opcji od paru minut nawet do kilku godzin. W moim przypadku proces kompilacji trwa zazwyczaj ok. 10 - 15 minut. Istnieje możliwość skompilowania jądra na innym komputerze, jeśli nasz jest do tego za słaby i proces kompilacji trwa długo. W takim wypadku po skompilowaniu jądra na innym komputerze, należy przegrać z powrotem na nasz komputer w miarę możliwości cały katalog z źródłami jądra, lub tylko pliki bzImage, System.map i moduły jądra z katalogu /lib/nazwa_jądra. Istnieje także możliwość utworzenie uruchamialnej (bootowalnej) dyskietki bądź też płyty CD z obrazem jądra, z której będziemy uruchamiać nasz system.

4.1. Opcje kompilacyjne

        Poniżej podaje komendy, które możemy wydawać w konsoli dla kompilacji jądra. Polecenia wydajemy wpisując w konsoli make i jedno z poleceń poniżej. Sam proces kompilacji i instalacji sprowadza się do wpisania komend make all, make module_install, make install.

make + :
        clean - usuwa większość wygenerowanych plików pozostawiając plik konfiguracyjny.
        mrproper - usuwa wszystkie wygenerowane pliki razem z pikiem konfiguracyjnym. Zalecane jest zastosowanie tego po łataniu jądra.
        oldconfig - konfiguracja jądra w trybie tekstowym odpowiadając na pytania.
        menuconfig - konfiguracja jądra w trybie tekstowym.
        xconfig - konfiguracja jądra w trybie graficznym za pomocą edytora napisanego QT.
        gconfig - konfiguracja jądra w trybie graficznym za pomocą edytora napisanego w GTK.
        defconfig - konfiguruje jądro z domyślnymi ustawieniami.
        allmodconfig - konfiguruje jądro wybierając moduły gdzie tylko to możliwe.
        allyesconfig - konfiguruje jądro z wkompilowanymi wszystkimi pakietami.
        allnoconfig - konfiguruje jak najmniejsze jądro.
        all - Robi na raz wszystkie polecenia z * na początku z listy poniżej.
        * vmlinux - Buduje jądro.
        * modules - Buduje wszystkie moduły.
        * bzImage - Tworzy skompresowane jądro.
        modules_install - Instaluje wszystkie moduły.
        install - Przenosi pliki jądra na odpowiednie miejsce i tworzy wpisy w bootloaderze.
        dir/ - Buduje wszystkie pliki w podanym katalogu.
        dir/file.[ois] - Buduje tylko podany obiekt.
        rpm - Buduje jądro jako RPM.
        tags/TAGS - Generuje tagi dla edytorów.
        cscope - Generuje tylko listę cscope.
        rpm-pkg - Buduje jądro jako RPM.
        binrpm-pkg - Buduje jądro jako RPM zawierający skompilowane jądro i moduły.
        deb-pkg - Buduje jądro jako paczkę dla Debiana.
        bzdisk - Tworzy bootowalną dyskietkę w /dev/fd0.
        fdimage - Tworzy bootowalną dyskietkę. [12]

4.2. Opis kompilacji jądra

        Do kompilacji jądra przystępujemy komendą make all, proces ten może zająć trochę czasu szczególnie na słabszych komputerach. W tym czasie kompilowane są pliki, które zaznaczyliśmy z konfiguracji jądra. Proces ten możemy przerwać przyciskami CTRL + C, kiedy ponownie wydamy komendę kompilacji make all, proces kompilacji zostanie dokończony.

        Po zakończeniu, jeśli nie wystąpią jakieś błędy i zamierzamy używać modułów wydajemy komendę make modules_install. Na sam koniec możemy wydać komendę make install, która przeniesie nam wszystkie pliki nowo utworzonego jądra i dokona odpowiednich wpisów w menadżerze uruchamiania (bootloaderze).

 

5. Instalacja jądra

        Jeśli mamy więcej niż jeden system Linux nie musimy dla każdego z nich tworzyć nowego jądra, możliwe jest uruchomienie go z jądrem innego systemu Linux, o ile posiada ono wszystkie opcje niezbędne do uruchomienia się na naszym komputerze. Jak uruchomić system z jądrem innego Linuxa wyjaśnię w rozdziale poświęconej Konfiguracji menadżera uruchamiania (bootloadera). Jedynym mankamentem tego jest to, iż nie będziemy mogli wykorzystywać modułów, gdyż zostały one umieszczone w katalogu /lib systemu, w którym jądro tworzyliśmy, chyba, że skopiujemy katalog z modułami.

5.1. Opis instalacji jądra

        Komenda make install dokonuje tego wszystkiego za nas, przenosi pliki System.map nadając mu nazwę System.map-(extension z makefile), BzImge nadając mu nazwę vmlinuz-(tak jak przy System.map). Tworzy także i przenosi do katalogu /boot plik initrd nadając mu nazwę intrd-(tak jak przy System.map).img. Komenda ta, także dokonuje niezbędnych modyfikacji w konfiguracji menadżera uruchamiania (bootloadera).
        Po kompilacji, jeśli nie wydamy komendy make install musimy ręcznie przenieść pliki jądra. Należy uważać, aby zmieniać nazwy tych plików i nie zapisać plików starego jądra. Z katalogu gdzie znajdują się nasze źródła jądra przenosimy plik System.map do katalogu /boot. Najlepiej zmienić nazwę pliku na kojarzącą nam się z jądrem np. System.map-2.6.8.1-kompilacja1. Następie tworzymy skrót do nowego pliku. W konsoli w katalogu /boot wydajemy komendę ln -s System.map-nasza_nazwa System.map, należy wcześniej usunąć stary skrót, jeśli taki istnieje.
        Następnie z podkatalogów arch/i386/boot w katalogu z źródłami jądra przenosimy plik BzImage i zmieniamy jego nazwę na np. vmlinuz-2.6.8.1-kompilacja1. Tworzymy także skrót ln -s vmlinuz-nazwa vmlinuz.
        Także, jeśli nie wydaliśmy komendy make install, lub wpis nie został automatycznie utworzony musimy skonfigurować naszemu menadżerowi uruchamiania (bootloaderowi) obsługę nowego jądra. [13]

5.2. Konfiguracja menadżera uruchamiania (bootloadera)

        Po kompilacji, jeśli nie wydamy komendy make install musimy ręcznie ustalić konfiguracje menadżerowi uruchamiania (bootloaderowi), aby uruchomił nam nowe jądro. W każdym razie warto sprawdzić te konfiguracje przed ponownym uruchomieniem systemu. Szczególnie uwagę zwracać należy czy podane jest odpowiednie jądro i ścieżka root=/dev/partycja_główna.

5.2.1. Konfiguracja GRUBa

        Aby zmienić opcje menadżera uruchamiania GRUB, musimy zajrzeć do jego pliku konfiguracyjnego. Opcje pliku konfiguracyjnego przedstawiają się następująco, wszelkie zmiany dokonujemy w pliku /boot/grub/grub.conf:
        title - wpisujemy tutaj dowolną nazwę (np. linux-2.6.8.1).
        root (hd0,0) - oznacza dysk i partycję z systemem, numeracja zaczyna się od 0 i oznacza partycję pierwszą (np. hda1) dysku pierwszego. (hd0,1) oznacza drugą partycję (np. hdg1) itd.
        kernel - tutaj wpisujemy ścieżkę do katalogu z jądrem i nazwę jądra (np. /boot/vmlinuz-2.6.8.1-kompilacja1).
        initrd - nie jest to konieczne (chyba, że ustawiliśmy obsługę naszego głównego systemu plików jako moduł), ale jeśli chcemy wykorzystać initrd to tutaj także podajemy ścieżkę i nazwę. [14]

        Przykładowy wpis dla jądra 2.6.8.1 wpis będzie wyglądał następująco:
title Linux (2.6.8.1)
root (hd0,0)
kernel /boot/vmlinuz-2.6.8.1 ro root=/dev/hdg1
initrd /boot/initrd-2.6.8.1.img [15]

        Jeśli w root= wpiszemy katalog główny innego systemu Linux niż, tego dla którego kompilowaliśmy i instalowaliśmy jądro, to uruchomi się on z tym jądrem, aczkolwiek nie będziemy mogli korzystać z modułów, gdyż nie zostały one umieszczone w katalogu tego systemu. Jeśli chcemy korzystać z modułów musimy przekopiować katalog /lib/modules/nazwa_jadra.

5.2.2. Konfiguracja LILO

        W sytuacji, gdy posiadamy menadżer uruchamiania LILO sytuacja przedstawia się podobnie. Zmiany konfiguracji LILO dokonujemy w pliku /etc/lilo.conf:
        image - wpisujemy tutaj pełną ścieżkę do jądra (np. /boot/vmlinuz-2.6.8.1-kompilacja1).
        root - określa urządzenie, które powinno zostać zamontowane jako katalog nadrzędny (/). Jeśli użyta zostanie specjalna nazwa current, nadrzędnym urządzeniem zostanie urządzenie, którego główny system plików jest aktualnie zamontowany. Jeśli katalog nadrzędny zostanie zmieniony za pomocą -r, odpowiednie urządzenie zostanie użyte. Jeśli pominięto opcję root, użyte zostanie główne urządzenie ustalone przez jądro (i które zostało określone przy kompilacji za pomocą zmiennej ROOT_DEV w pliku Makefile źródeł jądra, lub zmienione przez program rdev(8)). Oznacza to, że podajemy tutaj nazwę naszego katalogu nadrzędnego dla Linuxa (np. hdg1).
        label - menadżer uruchamiania (bootloader) aby zidentyfikować obraz używa nazwy pliku (bez ścieżki) tego obrazu. Odmienna nazwa może zostać podana za pomocą opcji label. W graficznym menu LILO jest to nazwa na liście systemów do uruchomienia (np. Linux-2.6.8.1). [16]
        initrd - nie jest to konieczne (chyba, że ustawiliśmy obsługę naszego głównego systemu plików jako moduł), ale jeśli chcemy wykorzystać initrd to tutaj także podajemy ścieżkę i nazwę.

        Przykładowy wpis dla jądra 2.6.8.1 wpis będzie wyglądał następująco:
image=/boot/vmlinuz-2.6.8.1
root=/dev/hdg1
label=linux-2.6.8.1
initrd=/boot/initrd-2.6.8.1.img
read-only

        Po wprowadzeniu zmian w pliku konfiguracyjnym koniecznie musimy wydać polecenie /sbin/lilo. [17]
        Jeśli w root= wpiszemy katalog główny innego systemu Linux niż tego, dla którego kompilowaliśmy i instalowaliśmy jądro, to uruchomi się on z tym jądrem, aczkolwiek nie będziemy mogli korzystać z modułów, gdyż nie zostały one umieszczone w katalogu tego systemu. Jeśli chcemy korzystać z modułów musimy przekopiować katalog /lib/modules/nazwa_jadra.

5.3. Tworzenie dyskietki startowej

        Tworzenie dyskietki startowej sprowadza się Do wydanie komendy make bzdisk, po kompilacji jądra. Tworzy to dyskietkę startową na dyskietce w stacji dysków. Należy pamiętać o włożeniu dyskietki przed wydaniem tej komendy.
        Możemy wykorzystać naszą dyskietkę do uruchamiania innych systemów z nowym jądrem, należy jednak pamiętać, że musimy zaznaczyć w konfiguracji odpowiedni procesor i niezbędne do poprawnego działania sprzętu sterowniki nie mogą być w formie modułów, moduły bowiem zostały zainstalowane na twardym dysku komputera, na którym jądro kompilowaliśmy. Jeśli chcemy korzystać z modułów należy je najpierw przegrać na dysk twardy drugiego komputera.
        Po wykonaniu dyskietki startowej restartujemy komputer pozostawiając dyskietkę w stacji dysków.

5.4. Tworzenie uruchamialnego (bootowalnego) obrazu iso z jądrem

        Jako iż jądro z serii 2.6 zajmuje już dość dużo miejsca i może się na dyskietkę po prostu nie zmieścić. W takim wypadku możemy wykonać obraz uruchamialny (bootowalny) iso, w konsoli wydajemy komendę: mkbootdisk --iso --device /jakiś/katalog/zasza_nazwa.iso nazwa_jądra-(wersja-nazwa_z_makefile_EXTRAVERSION).

Przykładowo komenda u mnie wygląda tak:
        mkbootdisk --iso --device /home/jarek/2681.iso 2.6.8.1-STABILNA.

        Obraz ten musimy teraz nagrać na płytę, najlepiej CD-RW i uruchomić z niej system. Jeśli chcemy uruchamiać inny system niż ten, na którym kompilowaliśmy jądro z płyty, należy stosować się do uwag podanych przy dyskietce startowej.
        Teraz należy zrestartować system i uruchomić go z nowym jądrem, jeśli wszystko pójdzie dobrze to system powinien uruchomić się już na nowym jądrze. Jeśli nie, poniżej podaje listę problemów jakie mogą wystąpić.

6. Możliwe błędy

        Zebrałem tutaj w listę błędy, które mogą wystąpić w czasie kompilacji i uruchamiania nowego jądra. Z pewnością jest więcej i mogą różnić się w zależności od dystrybucji, lecz komunikaty powinny być podobne.
Podzieliłem błędy na trzy rodzaje w zależności, w której fazie kompilacji mogą one wystąpić.

6.1. Błędy w czasie kompilacji

        Są to błędy, które wystąpić mogą na początku jeszcze w czasie kompilowania jądra lub jego konfiguracji.

QM_MODULES: Function not implemented:
Dzieje się tak, gdy nie posiadamy odpowiedniej wersji module-init-tools. Komunikat ten występuje po wydaniu komendy make modules_install. Jądro skompiluje się, ale nie będziemy mogli korzystać z modułów. Musimy ściągnąć najnowszą wersję module-init-tools, najnowszą wersję możemy ściągnąć ze strony: ftp://ftp.kernel.org/pub/linux/kernel/people/rusty/modules/.

Następnie instalujemy w sposób podany w pliku README:
./configure --prefix=/
make moveold
make
make install
./generate-modprobe.conf /etc/modprobe.conf

Komunikat: 3.3.4/../../../libncurses.a:
Związany jest on z brakiem pakietu ncurses i ncurses-dev lub ncurses-devel. [18]

Komunikat: SYSMAP .tmp_System.map /bin/sh: line 1: cmp: command not found Inconsistent kallsyms data, try setting CONFIG_KALLSYMS_EXTRA_PASS: Brak w systemie pakietu diffutils, konkretnie programu cmp [19].

Komunikat: /usr/include/bits/socket.h:305:24: asm/socket.h: Nie ma takiego pliku ani katalogu, w czasie wykonywania xconfig, menuconfig:
Brakuje pakietu kernel-headers. Można go zainstalować albo podlinkować odpowiednie katalogi ze źródeł jądra do /usr/include [20].

Komunikat: /usr/src/linux-2.6.10/scripts/gcc-version.sh: line 1: gcc: command not found , w czasie wykonywania make menuconfig: W wypadku tego komunikatu należy zainstalować pakiet gcc [21].

6.2. Błędy "Kernel Panic"

        Błędy "Kernel Panic", występują w czasie ładowania się systemu, są one wynikiem błędnej kompilacji lub konfiguracji jądra.

VFS: Cannot open root device (0:0):
Numer może być przypadkowy, jest to nazwa urządzenia. Błąd ten występuje, jeśli zapomnimy podać w jądrze sterowników do IDE. Może też to się zdarzyć, jeśli w menadżerze uruchamiania podaliśmy nieprawidłowy parametr root=.

Kernel panic: VFS: Unable to mount root fs on (0:0):
Jeśli wystąpił poprzedni komunikat ten też się pojawi. Jeśli jednak wystąpi sam oznacza to, że system nie mógł sobie poradzić z systemem plików, czyli nie wkompilowaliśmy w jądro obsługi systemu plików, jakich używamy, np. Ext2/3, ewentualnie wkompilowaliśmy go jako moduł i stąd problemy.

Kernel panic: No init found. Try passing init= option to kernel:
Przyczyna tego komunikatu zazwyczaj jest taka sama jak poprzednio. System plików nie został zamontowany prawidłowo i system nie mógł odnaleźć komendy init.

...FATAL: Module sd_mod not found...
Komunikat ten nie jest szczególnie groźny, jeśli nie zapomnieliśmy wybrać niezbędnych opcji z jądra. Oznacza on, iż taki moduł nie został znaleziony i nie może zostać uruchomiony. Przyczyną teko może być to, iż wkompilowaliśmy moduł na stałe a jego wpis pozostał w pliku /etc/modprobe.conf lub też nie wkompilowaliśmy w ogóle. W takim wypadku (o ile nie będziemy wykorzystywać już tego modułu), możemy skasować odnoszący się do niego wpis.

6.3. Błędy w działaniu systemu

        Są błędy w samym działaniu systemu powstałe po skompilowaniu nowego jądra. System uruchomił się, ale nie wszystko działa tak jak powinno, tutaj opisze takie właśnie problemy.

Manual systemowy nie włącza się, występuje komunikat "Błąd w trakcie formatowania lub wyświetlania. Komenda (cd /usr/man/pl && (echo ".ll 11.2i"; echo ".pl 1100i"; /bin/gunzip -c '/usr/man/pl/man1/man.1.gz'; echo ".\\\""; echo ".pl \n(nlu+10") | /usr/bin/gtbl | /usr/bin/nroff -S -mandoc | /usr/bin/less -is) zwróciła status 256.": Problem taki przydarzył mi się w systemie Slackware 10 po skompilowaniu jądra 2.6.8.1. Aby go naprawić należy podać odpowiedni system kodowania znaków dla konsoli, z jakiego korzystamy. W moim przypadku musiałem zamienić ISO-8859-1 na ISO-8859-2 w opcji Default NLS Option, niestety wymaga to ponowne skompilowanie jądra. Możemy zmienić to także w działającym już systemie dodając lub zmieniając wpis w pliku /etc/profile.d/lang.sh export LESSCHARSET=latin1.
Na forum dyskusyjnym spotkałem się, także z radą aby uaktualnić pakiet udev do najnowszej wersji.

W czasie uruchamiania się jądra występuje komunikat "System has been configured to work with DEVFS_FS":
Na błąd ten natrafiłem na Gentoo, jądro uruchamiało się, ale pojawiał się ten błąd. Aby to naprawić należy zaznaczyć opcję /dev file system support, która znajduje się w File systems -> Pseudo filesystems.

W konsoli linuxowej bark jest polskiej czcionki:
Jeśli po przekompilowaniu jądra nie mamy wyświetlanych polskich liter najprawdopodobniej wybraliśmy zły system kodowania w opcji (iso-8859-2) Default NLS Option (NLS_DEFAULT). Można także zmienić system kodowania znaków na odpowiedni w systemie dodając lub zmieniając wpis w pliku /etc/profile.d/lang.sh export LESSCHARSET=latin1.

rpmdb: unable to join the environment:
Komunikat ten wystąpił po uruchomieniu jądra z wersji 2.6 na dystrybucji Auroxie 9.1 (Red Hat 9). Pakietów nie można było instalować a po wydaniu komendy instalacji RPMa w konsoli po dość długim oczekiwaniu występował komunikat:
rpmdb: unable to join the environment
error: db4 error(11) from dbenv->open: Resource temporarily unavailable
error: cannot open Packages index using db3 - Resource temporarily unavailable (11)
error: cannot open Packages database in /var/lib/rpm

Po wpisaniu komendy: export LD_ASSUME_KERNEL=2.4.1 w konsoli problem ten znikną, lecz apt nadal nie działał. Problem udało mi się zupełnie rozwiązać instalując najnowszą wersję pakietu rpm (rpm-4.2.1-0.30.i386.rpm, rpm-build-4.2.1-0.30.i386.rpm, rpm-devel-4.2.1-0.30.i386.rpm, rpm-python-4.2.1-0.30.i386.rpm).

7. Przejście z jądra 2.4 na 2.6

        Większość nowszych dystrybucji dostosowana jest już do używania jądra 2.6, w niektórych jest ono nawet jako alternatywny wybór. Jednak starsze dystrybucje mogą mieć problem z jego obsługą.
        Opiszę tutaj, jakie zmiany należy dokonać w systemie, aby po przejściu z jądra 2.4 na jądro 2.6 wszystko działało nam poprawnie. Zmiany te działały poprawnie na dystrybucji Aruox 9.1, który oparty jest na Red Hat 9.

7.1 Tworzenie systemu plików Sysfs

        Jeśli przechodzimy na jądro 2.6 z jądra wcześniejszego będziemy musieli stworzyć system plików sysfs, nie jest to konieczne, jeśli używamy dalej /proc (przez pewien czas nie korzystałem z sysfs i nie doświadczyłem poważniejszych błędów), aczkolwiek brak sysfs może powodować pewne problemy.

Poniżej opisuje jak stworzyć ten system:
- Tworzymy katalog /sys (cd /, mkdir sys).
- W pliku /etc/rc.sysinit po linii "mount -f /proc" dopisujemy "mount -f /sys".
- W pliku /etc/rc.sysinit po linii "action $"Mounting proc filesystem: " mount -n -t proc /proc /proc" dopisujemy "action $"Mounting sysfs filesystem: " mount -n -t sysfs /sys /sys".
- W pliku /etc/fstab dodajemy linie "none /sys sysfs defaults 0 0".
- W pliku /etc/init.d/halt zmieniamy "awk '$2 ~ /^\/$|^\/proc|^\/dev/{next}" na "awk '$2 ~ /^\/$|^\/proc|^\/sys|^\/dev/{next}". [22]

7.2. Zmiany w USB

        Nazwy modułów USB także się zmieniają. Wpływa to na plik /etc/modprobe.conf i /etc/rc.sysinit. Musimy zamienić "keybdev" na "usbkbd" i "mousedev" na "usbmouse". Pozatym należy zamienić "/proc/bus/usb" na "/sys/bus/usb".
Musimy to także zrobić w /etc/init.d/halt.
W pliku /etc/rc.sysinit musimy zmienić funkcję "needusbstorage" jak to opisane jest poniźej:

needusbstorage=
if [ $usb = "1" ]; then
needusbstorage=`LC_ALL=C grep -e "^I.*Cls=08" /sys/bus/usb/devices 2>/dev/null`
action $"Initializing USB HID interface: " modprobe usbhid 2> /dev/null
action $"Initializing USB keyboard: " modprobe usbkbd 2> /dev/null
action $"Initializing USB mouse: " modprobe usbmouse 2> /dev/null
fi
[22]

7.3. Zmiany w Hotplug

        Hotplug jest niezbędny, aby poprawnie działały radiowe karty sieciowe. Należy zaznaczyć opcję CONFIG_HOTPLUG w czasie konfigurowania jądra, a następnie zamienić wszystkie "/proc/ksyms" na "/proc/kallsyms" w pliku /etc/rc.sysinit. [22]

9. Bibliografia

1. D. P. Bovet, M. Cesati, "Understanding the Linux Kernel", O'Reilly, 2000.
2. http://www-106.ibm.com/developerworks/linux/library/l-web26/.
3. B. Ward, "The Linux Kernel HOWTO. V1.0", 1999. http://www.linuxdocs.org/HOWTOs/Kernel-HOWTO.html.
        Wersja polska: B. Maruszewski, "Opis jądra Linux-a, jego instalacji itp. v3.0", 1999. http://www.jtz.org.pl/Html/Kernel-HOWTO.pl.html.
4. B. Laarhoven, J. Tombs, B. Ekwall, E. Youngdale, R. Henderson, "man insmod", 1996.
5. J. Gelinas oraz B. Ekwall, "man depmod", 1996.
6. J. Gelinas oraz B. Ekwall, "man modprobe", 1996.
7. B. Laarhoven, J. Tombs, B. Ekwall i R. Henderson, "man rmmod", 1996.
8. B. Laarhoven, J. Tombs, B. Ekwall i R. Henderson, "man lsmod", 1996.
9. "Documentation/Changes", dokumentacja z źródeł jądra.
10. Gibbdog, "Kernel Patching Guide".http://www.linuxhelp.net/guides/kernelpatch/.
11. "man patch", 1997.
12. "make help", Help opcji konfiguracyjnych jądra.
13. "FAQ - Najczęściej zadawane pytania...",
http://www.linux.com.pl/forum/index.php.
14. info grub.
15. GRUB Manual, http://www.gnu.org/software/grub/manual/grub.html.
16. W. Almesberger oraz J. Coffman, "man lilo.conf", 2002.
17. LILO - The Linux Loader, http://www.acm.uiuc.edu/workshops/linux_install/lilo.html.
18. "problem z uruchomieniem make menuconfig", http://www.linux.com.pl/forum/index.php.
19. "Kernel 2.6.8.1 kompilacja i błąd...", http://www.linux.com.pl/forum/index.php.
20. "jajco 2.6.10", http://www.linux.com.pl/forum/index.php.
21. "Problem z kompilacja jajka 2.6.10", http://www.linux.com.pl/forum/index.php.
22. T. M. Gil, "Migrating to Linux Kernel 2.6", 2004. http://thomer.com/linux/migrate-to-2.6.html.

 

Przedruk za zgodą autora 

Podobne artykuły


10
komentarze: 11 | wyświetlenia: 2303
6
komentarze: 18 | wyświetlenia: 398
108
komentarze: 32 | wyświetlenia: 56180
53
komentarze: 68 | wyświetlenia: 29396
53
komentarze: 55 | wyświetlenia: 30477
49
komentarze: 27 | wyświetlenia: 61000
48
komentarze: 18 | wyświetlenia: 62869
38
komentarze: 51 | wyświetlenia: 21013
37
komentarze: 29 | wyświetlenia: 26400
36
komentarze: 9 | wyświetlenia: 26386
35
komentarze: 36 | wyświetlenia: 19859
33
komentarze: 22 | wyświetlenia: 25138
 
Autor
Artykuł



Zawsze można się dowiedzieć, jak to wygląda. Ale po przeczytaniu przeszła mi na to chyba ochota. Za dużo roboty.

  Kamil O.  (www),  11/03/2010

No strasznie skomplikowane :)

  oldml,  11/02/2008

Fakt, kiedyś przymierzałem się do tego, ale też zrezygnuję :)) Niemniej opracowanie wygląda bardzo solidnie. Czytałem trochę o tym po angielsku.

  rajcio,  31/03/2009

"Prawdopodobnie każdy użytkownik systemu operacyjnego Linux, prędzej czy później stanie przed koniecznością kompilacji jądra systemu."

więcej takich tekstów a użytkowników linuxa na pewno nam przybędzie, szczególnie po przeczytaniu całości ;)

Może nie koniecznością, ale chęcią dopasowania jądra do swojego sprzętu. Mimo tego, że system działa. Ale wydaje się, że może być lepiej ... :)



Dodaj swoją opinię
W trosce o jakość komentarzy wymagamy od użytkowników, aby zalogowali się przed dodaniem komentarza. Jeżeli nie posiadasz jeszcze swojego konta, zarejestruj się. To tylko chwila, a uzyskasz dostęp do dodatkowych możliwości!
 

© 2005-2017 grupa EIOBA. Wrocław, Polska