/pub/Linux/sunsite/docs/HOWTO.
Nowsza wersja zawiera uaktualnione wskazania na katalog zawierający jądra na
ftp.icm.edu.pl
Czy powinieneś to czytać? Hmm... zobaczmy czy masz następujące problemy:
Niektóre z przykładów zawartych tutaj zakładają, że masz
zainstalowane takie programy jak: GNU tar, find i xargs.
Są one właściwie standardowe; nie powinno być z tym problemów.
Zakłada się także, że znasz strukturę twojego systemu plików.
Jeśli nie znasz to koniecznie trzymaj w ręku wydruk tego co
pojawia się na ekranie po poleceniu mount, albo wydruk
zawartości pliku /etc/fstab jeśli umiesz go przeczytać.
Informacja ta jest ważna, i nie zmieni się dopóki nie zmienisz
układu partycji na twoim dysku.
Najnowszą wersją jądra, dostępną podczas pisania tego dokumentu, była wersja 2.0.30. To znaczy, że wszystko w tym dokumencie odnosi się do tej właśnie wersji. Chociaż staram się napisać ten dokument tak niezależnym jak się tylko da, jądro jest ciągle rozwijane, więc jeśli dostaniesz nowszą wersję, nieuniknionym jest, że będą jakieś różnice. Ale to wciąż nie powinno stanowić dużego problemu, co najwyżej mogą wystąpić jakieś drobne różnice.
Są dwie ogólne wersje źródeł jądra Linux-a, stabilne i testowe. Stabilne wersje zaczynają się od wersji 1.0.x i są numerowane liczbami parzystymi (chodzi o liczbę drugą); 1.0.x, 1.2.x, 2.0.x Wersje te są uważane za najbardziej stabilne, wolne od dziur i błędów podczas ich dystrybucji. Jądra testowe (1.1.x, 1.3.x, 2.1.x) są jądrami przeznaczonymi dla tych, którzy chcą je testować, wprowadzać jakieś zmiany, może nawet współpracować przy tworzeniu go. W wersjach tych może byc pełno błędów, mogą się zawieszać chociaż to wcale nie jest regułą i niekoniecznie musi się dziać. Jakby co, to zostałeś ostrzeżony.
Tekst, który tak wygląda jest albo czymś co pojawi się na
ekranie, nazwą pliku, albo czymś co może być bezpośrednio wpisane
z klawiatury (np. polecenie, czy jego opcje). Jeśli czytasz ten
dokument jako zwykły plik tekstowy to tekst ten niczym się nie
różni.
Jądro w systemach typu Unix odgrywa rolę pośrednika między twoimi programami, a twoim sprzętem. Najpierw zajmuje się zarządzaniem pamięci dla wszystkich uruchomionych programów (procesów), i dba o to, aby wszystkie one dostały równą ilość czasu procesora. (albo nierówną jeśli tak zażądasz). Dodatkowo, posiada miły interfejs dla programów chcących "rozmawiać" z twoim sprzętem.
Jądro spełnia oczywiście o wiele więcej funkcji, ale to są najważniejsze, które należy znać.
Nowsze jądra z reguły mają wiekszą ilość sterowników, czyli mogą obsłużyć większą ilość urządzeń, mogą mieć ulepszone algorytmy zarządzania procesami, mogą działać szybciej niż starsze wersje, mogą być bardziej stabilne, mają także wiele poprawek błędów, które zdarzyły się w wersjach wcześniejszych. Większość ludzi odnawia swoje jądra ponieważ chcą większej ilości sterowników i naprawionych błędów.
Przeczytaj Hardware-HOWTO. Możesz także zajrzeć do pliku
config.in w źródłach jądra. Albo po prostu dowiedzieć się
samemu jak napiszesz make config. W poleceniu tym znajdą
się wszystkie obsługiwane przez dane jądro urządzenie. Ale nie będą
to wszystkie urządzenia, które obsługuje Linux. Wiele popularnych
sterowników (jak np. sterownik do PCMCIA i niektóre sterowniki do
taśm) są rozprowadzane osobno jako ładowalne moduły.
Aby zobaczyć jaką masz wersję napisz gcc -v.
Linus zaleca zawsze w pliku README wersję gcc, która
powinna być użyta do kompilacji danego jądra. Jeśli nie masz tej
wersji, dokumentacja w zalecanej wersji gcc powinna powiedzieć ci
czy musisz odnowić libc. Nie jest to trudne, ale ważne jest, aby
postępować zgodnie ze wskazówkami.
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.
To zależy od twojej konkretnej konfiguracji. Skompresowane źródła zajmują mniej więcej 6 MB. No ale żeby skompilować to wypadałoby je rozpakować, a te zajmują już 24 MB (+6 MB archiwum). Ale to jeszcze nie koniec -- musisz przecież skompilować to jądro, a wyniki kompilacji (pliki objektowe itp.) też trzeba gdzieś trzymać. Wielkość wyniku kompilacji zależy od tego co władujesz do jądra. Np. ja mam sieć, sterownik do 3Com 3C509, i trzy systemy plików, co w sumie daje 30 MB (razem z rozpakownymi źródłami oczywiście) Dodając do tego, skompresowane archiwum wychodzi na to, że potrzebujesz około 36 MB. Jeśli dołożysz coś jeszcze, np. dźwięk, będziesz musiał przeznaczyć jeszcze więcej miejsca. (Od tłumacza: u mnie dźwięk zajmuje około 500 kB - SoundBlaster 16 Pro). Oczywiście nowsze wersje źródeł będą zajmować coraz więcej miejsca. Dla porównania: wersja 1.2.29 zajmowała rozpakowana około 9 MB. Pomiedzy tą wersją a 2.0.10 były jeszcze 1.2.30-40, 1.3.0-99 a potem 2.0.x. Tak więc lepiej najpierw się upewnić czy mamy wystarczająco miejsca.
Dla większości ludzi odpowiedź to "naprawdę długo". Szybkość procesora i ilość pamięci RAM są czynnikami decydującymi. Na komputerze 486DX4/100 z RAM-em 16 MB, jądro w wersji 1.2.x z pięcioma systemami plików, obsługą sieci i sterownikiem do karty dźwiekowej kompiluje się około 20 minut. Na 386DX/40 z 8 MB RAM-u i podobną konfiguracją kompilacja trwa 1,5 - 2 godzin. Generalnie najlepiej zrobić sobie kawę, pooglądać telewizję czy coś w tym guście podczas gdy twój komputer będzie kompilował jądro. No jeśli masz Pentium 166 czy PPro ;) i 32 MB RAM-u to możesz w czasie kompilacji nawet pisać swoje programiki czy robić coś innego na komputerze. Jeśli natomiast masz naprawdę wolny komputer, to idź do kolegi i poproś, żeby ci skompilował.
Źródła możesz sciągnąć np. z
ftp.kernel.org:/pub/linux/kernel - jest to główny
serwer dla jądra Linux-a, albo z jakiejś bliższej ci kopii
tego serwera. W Polsce najlepszym miejscem jest
ftp.icm.edu.pl/pub/Linux/kernel. Z reguły nazwa
jądra to linux-x.y.z.tar.gz, gdzie x.y.z jest numerem
wersji. Nowsze (lepsze?) wersje i łaty (patches) są zwykle w
podkatalogu v1.1 czy v1.2. Najwyższy numer oznacza
najnowszą wersję, zwykle jest to wersja testowa. To znaczy, że
jeśli nie masz chęci na wersje beta czy alfa, powinieneś zostać
przy wersji podstawowej.
Bardzo zalecam, aby używać lokalnego mirrora zamiast ftp.funet.fi. ftp.icm.edu.pl jest polskim mirrorem dla sunsite.unc.edu. Jednak adres ten posiada także w Polsce wiele kopii, więc sprawdź najpierw czy gdzieś w pobliżu nie ma takiej kopii.
Ogólnie kopia serwera sunsite.unc.edu to dobre miejsce, żeby
zacząć. Plik /pub/Linux/MIRRORS zawiera listę znanych
mirror-ów.
Jeśli nie masz dostępu do ftp, lista BBS-ów jest co jakiś czas
ogłaszana na grupie dyskusyjnej (USENET) comp.os.linux.announce;
postaraj się ją zdobyć.
Jeśli szukasz jakichś ogólnych informacji o Linux-ie, to zajrzyj pod adres www.linux.org. W Polsce także jest Polska Grupa Użytkowników Linux-a.
Zaloguj się jako root albo użyj polecenia su i
zmień katalog na /usr/src cd /usr/src.
Jeśli zainstalowałeś źródła do jądra podczas instalacji Linux-a w
katalogu tym znajdziesz dołączenie symboliczne linux,
które będzie wskazywało na katalog linux-x.y.z ze
źródłami, które wtedy zainstalowałeś. Jeśli chcesz zachować stare
źródła to usuń dołączenie linux poleceniem rm linux.
Jeśli takiego dołączenia nie ma, a jest katalog linux, to (jeśli
chcesz zachować źródła starej wersji jądra) zmień nazwę linux na
linux-x.y.z, gdzie x.y.z jest wersją tych źródeł. (zajrzyj do
pliku linux/Makefile - w pierwszych trzech linijkach
znajdziesz wersję źródeł znajdujących się w tym katalogu).
Jeśli chcesz możesz skasować cały katalog linux i pozbyć się
starych źródeł.
W każdym razie upewnij się, że nie ma katlogu linux przed
rozpakowanie źródeł.
Teraz w katalogu /usr/src rozpakuj źródła poleceniem
tar zxpvf linux-x.y.z.tar.gz, jeśli na końcu nazwy pliku
ze źródłami nie ma .gz to użyj polecenia tar xpvf
linux-x.y.z. Zawartość archiwum wyświetli się na ekranie.
Kiedy rozpakowywanie się skończy pojawi się nowy katalog linux.
Dobrym pomysłem byłoby w tym momencie zmienić jego nazwę na
linux-x.y.z i zrobić symboliczne dołączenie do tego
katalogu o nazwie linux. Aby to zrobić użyj polecenia
mv linux linux-x.y.z; ln -s linux-x.y.z linux. Teraz
zmień bieżący katalog na linux i przejrzyj plik
README. Znajdziesz tam sekcję o nazwie INSTALLING the
kernel. Przeczytaj ją uważnie i wypełnij wszystkie polecenia,
o których tam mowa.
UWAGA: Niektóre z uwag zawartych tutaj są podobne do tych z pliku
Linusa README.
Polecenie make config wydane w katalogu
/usr/src/linux uruchamia skrypt konfiguracyjny, który
zadaje ci wiele pytań. Wymaga on zainstalowanego shella, więc
sprawdź czy go masz. (/bin/bash, /bin/sh lub $BASH)
Od tłumacza:
W wersjach 2.0.x i nowszych istnieją jeszcze dwa sposoby na
konfigurację: make menuconfgi jak sama nazwa wskazuje
jest to konfiguracja za pomocą menu tekstowego. Można też wydać
polecenie make xconfig co spowoduje uruchomienie miłej
konfiguracji pod Xwindows. Pierwszy sposób wymaga zainstalowanej
biblioteki (n)curses. Ta druga wymaga zainstalowanej biblioteki
Tcl/Tk. Obie są dostarczane wraz ze standardowymi dystrybucjami.
Można teraz odpowiadać na kolejne pytania ukazujące się na ekranie. Odpowiada się zwykle literami "y" - tak i "n" - nie. Przy sterownikach jest jeszcze dodatkowa opcja "m" - oznacza skonfigurowanie go jako ładowalny moduł. Bardziej komicznym sposobem wyjaśnienia tej litery jest "może". Niektóre z bardziej oczywistych czy nie-krytycznych opcji nie zostały tutaj opisane; zobacz w sekcji "Inne opcje konfiguracji."
W wersjach 2.0.x i nowszych jest opcja "?". Wciskając "?" otrzymasz, krótki (czasem dłuższy) opis dotyczący danego pytania. Informacje te powinny być najbardziej aktualne.
Pytanie to dotyczy emulacji koprocesora przez jądro. Jeśli nie masz koprocesora matematycznego (masz czysty 386 albo 486SX), musisz tu odpowiedzieć "y". Jeśli masz koprocesor a odpowiesz "y", nie martw się -- koprocesor będzie użyty, a emulacja ignorowana. Jedyną konsekwencją (ważną w niektórych sytuacjach) jest większe i, co za tym idzie, wolniejsze jądro. Powiedziano mi, że emulacja koprocesora jest wolna; chociaż to nie ma nic wspólnego z tą sekcją, można jednak pamiętać o tym, np. przy pracy z Xwindows.
Przypuszczalnie potrzebujesz tej obsługi. Opcja ta oznacza, że jądro będzie obsługiwać standardowe dyski do komputerów PC, które są w posiadaniu większości ludzi. Sterownik ten nie zawiera obsługi dla dysków SCSI, pytanie o to będzie później w konfiguracji.
Zostaniesz zapytany następnie o sterowniki "old disk-only" i "new IDE". Wybierz jeden z nich; główna różnica pomiędzy nimi to taka, że stary sterownik obsługuje tylko dwa dyski na pojedynczym interfejsie, a nowy obsługuje drugi interfejs i napędy IDE/ATAPI CD-ROM. Nowy sterownik jest o około 4 kB większy od starego i ma być lepszy. To znaczy, że pomijając mniejszą ilość błędów może działać bardziej wydajnie, szczególnie jeśli masz dysk typu EIDE.
Ogólnie powinieneś odpowiedzieć "y" jeśli twój komputer jest w sieci takiej jak Internet, albo jeśli chcesz używać protokołów SLIP czy PPP, aby mieć dostęp do Internetu. Aczkolwiek wiele pakietów (np. Xwindows) wymaga obsługi sieci nawet jeśli twój komputer nie jest podłączony do żadnej sieci; powinieneś tu odpowiedzieć "y". Później, zostaniesz zapytany czy chcesz obsługę protokołu TCP/IP; znowu, odpowiedz "y" jeśli nie jesteś absolutnie pewien.
Są kontrolery 386 DMA, które posiadają pewne błędy i mają problemy z adresowaniem powyżej 16 MB RAM-u; powinieneś odpowiedzieć "y" jeśli posiadasz takowy.
Jedną z najlepszych definicji IPC (InterProcess Communication - Komunikacja Pomiędzy Procesami) znajduje się w glosariuszu w książce o Perlu. Nic więc dziwnego, że niektórzy programiści piszący w Perlu wykorzystują go do komunikacji między procesami, tak samo jak wiele innych pakietów (DOOM - z tych najbardziej znanych ;) ), więc odpowiedź "n" nie jest mądrym wyborem, o ile wiesz dokładnie co robisz.
Tradycyjnie, to wkompilowywało pewne optymalizacje dla konkretnego procesora; jądra działały dobrze także na inncyh procesoarch, ale były one troche większe. W nowszych wersjach się już tego nie stosuje i powinieneś odpowiedzieć na jaki procesor rzeczywiście kompilujesz jądro. Jądro skompilowane na 386 będzie działać na wszystkich procesorach.
Jeśli masz urządzenia SCSI odpowiedz "y". Zostaniesz następnie zapytany o dalsze informacje, jak np.: obsługa CD-ROM-u, dysków i twojego adaptera. Zajrzyj do SCSI-HOWTO po więcej szczegółów.
Jeśli masz kartę sieciową, albo chciałbyś używać protokołów SLIP, PPP, albo kontrolera portu równoległego aby połączyć się z Internetem odpowiedz "y". Konfigurator spyta cię następnie o typ karty i rodzaj protokołu.
Skrypt konfiguracyjny pyta cię następnie o to, jakie systemy plików chcesz obsługiwać:
Standard (minix) - Nowsze dystrybucje nie tworzą tego systemu
plików, a wielu ludzi go nie używa, ale jednak użycie go mogłoby
być dobrym pomysłem, ponieważ przydaje się on do odczytu dyskietek,
dla których system ten jest mniej bolesny niż ext2.
Extended fs - To jest pierwsza wersja systemu plików extended, która już nie jest w użyciu. Szanse, że będziesz potrzebował obsługi są prawie żadne, więc możesz go nie używać.
Second extended - Ten system plików jest bardzo szeroko rozpowszechniony i najprawdopodobniej ty także go używasz, więc lepiej go skonfiguruj.
xiafs filesystem - Swego czasu system ten był w użyciu, jednak podczas pisania tego dokumentu nie znałem nikogo, kto by go używał.
msdos - Jeśli chcesz używać swej partycji dos-owej, albo montować dyskietki sformatowane pod ten system, odpowiedz "y".
umsdos - Ten system plików rozszerza system plików MS-DOS o cechy systemów plików typu Unix, jak np. długie nazwy. Nie jest on przydatny dla ludzi, którzy (tak jak ja) nie używają DOS-a.
/proc - Następny genialny wynalazek po mleku w proszku (pomysł,
jak mniemam, skradziony bezwstydnie z laboratorium Bella). Na
dysku nie tworzy się systemu plików proc. To jest system
plików, który służy do porozumiewania się z jądrem i procesami.
Wiele programów wyświetlających procesy, jak np. ps używa
tego systemu plików. Spróbuj czasami wykonać polecenie cat
/proc/meminfo albo cat /proc/devices.
Niektóre powłoki (w szczególności rc) używają /proc/self/fd
(znane jako /dev/fd na innych systemach) do funkcji I/O.
Powinieneś prawie na pewno odpowiedzieć tutaj "y". Wiele ważnych
narzędzi do Linux-a zależy od tego systemu plików.
NFS - Jeśli twój komputer jest w sieci i chcesz używać systemów plików, które znajdują się na innych systemach z NFS, odpowiedz "y".
ISO9660 - Ten system plików jest na przeważającej ilości CD-ROM-ów. Jeśli więc chcesz używać CD-ROM-u odpowiedz "y".
OS/2 HPFS - Podczas pisania tego dokumentu, system plików tylko-do-odczytu dla OS/2 HPFS.
System V and Coherent - dla partycji Systemu V and Coherent. (Są to inne warianty Unixa na PC)
No dobra, napisz mount. Powinno się wyświetlić coś jak:
blah# mount
/dev/hda1 on / type ext2 (defaults)
/dev/hda3 on /usr type ext2 (defaults)
none on /proc type proc (defaults)
/dev/fd0 on /mnt type msdos (defaults)
Spójrz na każdą linijkę; słowo obok type jest typem
systemu plików. W tym przypadku / i /usr są typu second extended,
używany jest także proc i jest także zamontowana dyskietka
z systemem plików msdos (tfu!).
Możesz spróbować też cat /proc/filesystems jeśli masz
system proc. Wyświetli ci to systemy plików wkompilowane
w aktulanie używane jądro.
Konfiguracja rzadko używanych i nie krytycznych systemów plików może powodować niepotrzebne powiększanie się jądra; poczytaj sekcję o modułach jak tego uniknąć i sekcję "Pułapki", aby dowiedzieć się dlaczego powiększające się jądro nie jest pożądane.
Tutaj dołączasz sterowniki dla drukarki (równoległej, znaczy się), myszy szeregowej, myszy PS/2 (wiele Notebooków używa protokołu PS/2 dla swoich wbudowanych myszy), niektóre sterowniki do taśm, i inne tego typu "znakowe" urządzenia. Odpowiedz "y" kiedy znajdziesz urządzenie, którego używasz.
UWAGA: Selection to program, który pozwala na użycie myszy poza Xwindows i na kopiowanie tekstu pomiędzy wirtualnymi konsolami. Jest to całkiem przyjemne jeśli masz zwykłą myszkę szeregową, ponieważ koegzystuje ona z Xwindows, ale musisz uciekać się do specjalnych sztuczek dla innych. Wsparcie dla selection było kiedyś opcją podczas konfiguracji. Teraz jest standardem.
UWAGA 2: Selection jest teraz programem przestarzałaym. Nowym programem jest gpm. Ma on o wiele więcej możliwości, jak np.: tłumaczenie protokołów myszek, obsługa wielu myszek, ...
Jeśli czujesz wielką potrzebę usłyszenia dźwięków wydobywających się z tej maszynerii to odpowiedz "y", a później następny program konfiguracyjny wypyta cię o szczegóły na temat twojej karty dźwiękowej i skompiluje sterownik. (Uwaga o konfiguracji kart dźwiękowych: jeśli zapyta cię czy chcesz zainstalować pełną wersję sterownika, możesz odpowiedzieć "n" i zaoszczędzić trochę pamięci wybierając tylko to co jest ci potrzebne.) Szczerze radzę zajrzeć do Sound-HOWTO na temat szczegółów o obsłudze kart dźwiękowych.
Nie wszystkie opcje konfiguracyjne są tu wymienione ponieważ zmieniają się zbyt często lub są oczywiste (na przykład: obsługa 3Com 3C509). Pod adresem
<htmlurl url="http://math-www.uni-paderborn.de/~axel/config_help.html" name="http://math-www.uni-paderborn.de/~axel/config_help.html">
znajduje się dość obszerna lista opcji zrobiona przez Axela Boldta
axel@uni-paderborn.de,
jak również sposób umieszczenia jej w skrypcie Configure.
Od tłumacza: Zobaczę, może z czasem przetłumaczę tę listę z opisem... Sprawdzaj moją stronę WWW.
Wzięte z pliku README napisanego przez Linusa: opcja "kernel hacking" daje w rezultacie większe i wolniejsze jądro, może nawet uczynić je mniej stabilnym, przez konfigurowanie niektórych procedur, tak aby aktywnie próbowały łamać złe algorytmy i żeby można było znaleźć problemy jądra. (kmalloc()). Tak więc powinieneś odpowiedzieć tutaj "n" jeśli chcesz mieć normalnie działające i stabilne jądro.
Po poleceniu make config (albo jemu równoważnemu), pojawi
się na ekranie wiadomość, że jądro zostało skonfigurowane i że
należy sprawdzić top-level Makefile dla dodatkowej
konfiguracji.
Ten top-level Makefile to plik o nazwie Makefile w katalogu
/usr/src/linux. Zajrzyj tam. Przypuszczalnie nie będziesz
tam nic zmieniał, ale spojrzeć nie boli :). Jak już zainstalujesz
nowe jądro możesz zmienić jego opcje przy pomocy narzędzia rdev.
Kiedy skrypt konfiguracyjny się skończy każe ci napisać make
dep i (przypuszczalnie) make clean. Tak więc
zaczynamy od make dep. Jest to pewne zabezpieczenie się,
które sprawdza różne zależności, jak na przykład: czy pliki
nagłówkowe są na swoich miejscach. Nie zajmuje to wiele czasu, no
chyba, że twój komputer jest naprawdę wolny.
W starszych wersjach powinieneś jeszcze wydać polecenie make
clean. To usuwa pozostałości po starej kompilacji jądra
(pliki objektowe itp). Nie zapomnij tego kroku !!!
Po czyszczeniu i sprawdzeniu zależności możesz wpisać make zImage
lub make zdisk (to jest ta część, która zabiera tyle
czasu). make zImage skompiluje jądro i zostawi je w pliku
/usr/src/linux/arch/i386/boot/zImage wśród innych rzeczy.
To jest nowe skompresowane jądro. make zdisk robi to samo,
z tą różnicą, że umieszcza plik zImage na dyskietce w
stacji A:, którą mam nadzieję włożysz na czas do stacji :). (ten
czas to sam koniec kompilacji, ale na wszelki wypadek radzę włożyć
od razu, bo potem można zapomnieć)
make zdisk to dobry sposób na testowanie nowego jądra;
jeśli coś pójdzie nie tak, po prostu wyjmujesz dyskietkę ze stacji,
resetujesz i po krzyku. Może to być także pomocne jeśli
przypadkowo usuniesz jądro z dysku. (radzę uważać na to co się robi
w katalogu głównym a szczególnie w katalogu /boot). Możesz
jej także użyć do instalacji innych systemów, ponieważ wystarczy
przegrać zawartość tej dyskietki na inną.
Wszystkie, nawet te w połowie sensowne, jądra są skompresowane, z powodu literki "z" na początku. Skompresowane jądro odkompresowuje się automatycznie w czasie wykonywania.
make mrproper spowoduje dokładniejsze wyczyszczenie.
Czasem jest to potrzebne; możesz to robić przy instalacji
każdej łaty (patch). make mrproper skasuje także twój
plik z bieżącą konfiguracją, więc możesz sobie zrobić kopię
tego pliku (.config).
make oldconfig spróbuje skonfigurować jądro na podstawie
starego pliku konfiguracyjnego; przejdzie za ciebie przez proces
konfiguracji (make config). Jeśli jeszcze nigdy przedtem nie
kompilowałeś jądra lub nie masz starego pliku konfiguracyjnego
wtedy przypuszczalnie nie powinieneś tego robić, bo będziesz
chciał zmienić konfigurację domyślną.
Przeczytaj sekcję o modułach na temat szczegółów dotyczących
make modules.
Jeśli masz już nowe jądra i wydaje ci się, że ono działa tak jak
chciałeś, czas aby je zainstalować. Większość ludzi używa do tego
celu LILO (Linux Loader). make zlilo zainstaluje jądro,
uruchomi lilo, aby odświeżyć informacje i przygotuje wszystko, aby
zresetować i załadować nowe jądro. ALE TYLKO w przypadku,
gdy LILO jest skonfigurowane następująco:
jądro to /vmlinuz, lilo jest w /sbin, a twój
plik konfiguracyjny od lilo to /etc/lilo.conf i zgadza
się z tym co jest powyżej.
W innym przypadku musisz użyć bezpośrednio polecenia lilo.
Jest to pakiet całkiem prosty do zainstalowania i używania, ale ma
tendencję do załamywania ludzi swoim plikiem konfiguracyjnym.
Zajrzyj do pliku /etc/lilo/config - w starszych wersjach;
lub /etc/lilo.conf - w nowszych wersjach, i sprawdź
bieżące ustawienia. Plik ten wygląda tak:
image = /vmlinuz
label = Linux
root = /dev/hda1
...
image = odnosi się do aktualnej wersji zainstalowanego
jądra. Większość używa nazwy /vmlinuz. Ale równie dobrze
może to być nazwa xxx, jądro, czy pliczek (nie jestem pewien co
do polskich liter, ale zawsze można poeksperymentować :) )
label = używane jest przez LILO, aby dowiedzieć się jaki
system lub jądro załadować, a root = jest katalogiem
głównym danego systemu. Zrób kopię jądra, którego teraz używasz i
skopiuj nowo zrobione jądro na miejsce starego (czyli napisz
cp zImage /vmlinuz jeśli używasz nazwy vmlinuz i jesteś w
katalogu /usr/src/linux/arch/i386/boot. Potem uruchom
LILO - w nowszych wersjach po prostu uruchamiasz lilo; w
starszych może będziesz musiał uruchomić /etc/lilo/install
albo nawet /etc/lilo/lilo -C /etc/lilo/config.
Jeśli chcesz wiedzieć więcej na temat konfiguracji LILO, albo nie masz LILO, zdobądź najnowszą wersję i poczytaj dokumentację.
Aby załadować jedną ze starszych wersji jądra, które mam nadzieję
zachowałeś :) skopiuj linie od image = xxx w pliku
konfiguracyjnym LILO na dół pliku, zmień xxx na nazwę twojego
zachowanego pliku (wraz z pełną ścieżką). Zmień label = zzz
na np. label = old-kernel i uruchom ponownie lilo.
Możesz też wstawić linię delay = x, gdzie x jest ilością
dziesiętnych części sekundy, do pliku konfiguracyjnego LILO, aby
zatrzymać ładowanie na określoną ilość sekund i przerwać je np.
klawiszem SHIFT, a potem wpisać nazwę którą nadałeś starszej
wersji jądra (tę label = z pliku konfiguracyjnego LILO, a
nie nazwę pliku jądra) w razie gdyby stało się coś nieprzyjemnego.
Pakiety, które pozwalają na odnowienie jądra to łaty. Na przykład:
jeśli masz wersję 1.1.45 i znajdziesz plik o nazwie patch46.gz
to znaczy, że możesz odnowić swoje jądro do wersji 1.1.46. Możesz
zrobić kopię źródeł, które masz (make clean a potem
cd /usr/src; tar zcvf old-kernel.tar.gz linux)
Tak więc kontynuując powyższy przykład załóżmy, że masz plik
patch46.gz w katalogu /usr/src. Bedąc w katalogu
/usr/src wydaj polecenie zcat pacth46.gz | patch -p0
albo patch -p0 < patch46 jeśli łata nie jest
skompresowana. Zobaczysz teraz trochę ścieżek i nazw plików
oraz komunikatów przelatujących przez ekran, o tym co się udało a co
nie. Wszystko to przelatuje zbyt szybko, żeby nadążyć z
czytaniem, także właściwie nie wiesz czy się udało czy nie. Możesz
użyć parametru -s do polecenia patch, aby
poinformować je, żeby wyświetlało tylko komunikaty o błędach. Aby
zobaczyć czy coś poszło nie tak, poszukaj plików z rozszerzeniem
.rej w katalogu /usr/src/linux. Niektóre wersje
patch (starsze wersje, które mogły być skompilowane na gorszym
systemie plików) zostawiają błędy w plikach z rozszerzeniem
#. Możesz użyć polecenia find, aby znaleźć
te pliki:
cd /usr/src/linux; find ./ -name '*.rej' -print
Polecenie to wyświetli wszystkie pliki z rozszerzeniem rej znajdujące się w bieżącym katalogu i jego podkatalogach.
Jeśli wszystko poszło dobrze, wydaj teraz po kolei polecenia
make clean, make config i make dep tak jak opisano w
sekcjach 3 i 4.
Do polecenia patch jest trochę opcji. Jak już wspomniałem,
patch -s spowoduje wyświetlenie na ekran tylko wiadomości
o błędach. Jeśli trzymasz źródła w innym katalogu niż
/usr/src/linux, polecenie patch -p1 wydane w tym
katalogu, gdzie trzymasz źródła zrobi wszystko bez błędów. Inne
opcje polcenia patch są dobrze opisane w podręczniku "man".
(Uwaga: ta sekcja odnosi się w głównej mierze do starszych wersji jądra.)
Najczęstszym problemem było to, że kiedy polecenie patch
modyfikowało plik config.in nie wyglądał on tak jak
powinien, bo zmodyfikowałeś go, aby pasował do twojego komputera.
Zostało to już poprawione, ale w starszych wersjach błąd ten
pozostał. Aby to naprawić, przeczytaj plik config.in.rej
i zobacz co pozostało z oryginalnej łaty. Zmiany są zwykle
zaznaczane znakami + i - na początku linii. Spójrz na linie
otaczające tę zaznaczoną i przypomnij sobie, czy były one
ustawione na tak, czy na nie. Teraz w pliku config.in
zmień "y" na "n" i "n" na "y" tam gdzie trzeba. Wydaj polecenie
patch -p0 < config.in.rej a jeśli poinformuje cię, że
się powiodło, wtedy możesz kontynuować konfigurację i kompilację.
Plik config.in.rej pozostanie, ale możesz go skasować.
Jeśli odkryjesz dalsze problemy, mogłeś zainstalować jakąś łatę
nie w kolejności. Jeśli na ekranie pojawi się taka wiadomość:
previously applied patch detected: Assume -R? oznacza to,
że przypuszczalnie próbujesz nałożyć łatę o wersji mniejszej niż
źródła twojego jądra. Jeśli odpowiesz "y", polecenie patch
spróbuje zdegradować twoją wersję, i najprzypuszcalnie się to nie
powiedzie, przez co będziesz musiał zdobyć całkiem nowe źródła.
(co w sumie wcale nie jest takim złym pomysłem).
Aby odinstalować jakąś łatę użyj patch -R na oryginalnej.
Jak już się wszystko tak pomiesza, że nie będziesz mógł dojść do ładu, to najlepszym sposobem jest zdobyć nowe źródła jądra i zacząć od nowa.
Po zaledwie kilku łatach pliki .orig zaczynają niebezpiecznie
rosnąć. Na przykład: usunięcie plików .orig z wersji 1.1.51, która
była ostatnio czyszczona w wersji 1.1.48 spowodowało zwolnienie
ponad 500 kB dysku.
find . -name '*.orig' -exec rm -f {} ';'
Polecenie to spowoduje usunięcie wszystkich plików .orig z bieżącego katalogu i jego podkatalogów.
Wersje patch, które używają plików .# zamiast plików .rej, używają tyldy (~) zamiast plików .orig.
Są lepsze sposoby pozbycia się plików .orig, które zależą od
polecenia GNU xargs:
find . -name '*.orig' | xargs rm
lub metoda całkiem bezpieczna ale trochę "głośna" (dużo komunikatówna ekranie):
find . -name '*.orig' -print0 | xargs --null rm --
Są jeszcze inne łaty (tzw. niestandardowe), niż te które dystrybuuje Linus. Jeśli ich użyjesz łaty Linusa mogą nie działać i będziesz musiał je albo odinstalować, dopasować źródła albo łatę, zainstalować nowe źródła, albo jakaś kombinacja tego. Może to być trochę frustrujące, więc jeśli nie chcesz grzebać w źródłach (z możliwością narobienia niezłego bajzlu), odinstaluj niestandardowe wersje łat zanim zainstalujesz łatę Linusa, albo po prostu zainstaluj nowe źródła. Wtedy możesz zobaczyć czy łaty niestandardowe wciąż działają. Jeśli nie to albo utknąłeś ze starym jądrem i będziesz próbował zmusić jakoś źródło albo łatę, żeby zaczęła działać, albo będziesz czekał (pewnie błagał) o nową łatę.
Jak pospolite są te niestandardowe łaty?
Przypuszczalnie o nich usłyszysz. Ja używałem łaty "noblink" na
moich wirtualnych konsolach, bo nienawidzę mrugającego kursora. Ta
łata jest (a przynajmniej była) często odnawiana dla nowszych
wersji jądra. Z większością nowych sterowników jako ładowalne
moduły, chociaż częstotliwość niestandardowych łat znacznie spada.
Jądro Linux-a ma wiele zalet, które nie znajdują się w źródłach. Są one rozprowadzane jako osobne pakiety. Niektóre z tych najbardziej popularnych są tu wymienione.
Konsola Linux-owa ma chyba więcej zalet niż na to zasługuje. Pomiędzy nimi znajdują się takie jak: zmiana czcionek, zmiana układu klawiszy, zmiana trybów wyświetlania (w nowszych wersjach). Pakiet kbd to programy, które pozwalają użytkownikowi na robienie tego wszystkiego plus wiele czcionek i układów klawiatur dla prawie wszystkich klawiatur i jest on dostępny z tego samego miejsca, gdzie znajdują się źródła jądra.
Rik Faith (
faith@cs.unc.edu ) złożył razem obszerną
kolekcję narzędzi do Linux-a, które dziwnym trafem nazywają się
util-linux. Obecnie zajmuje się nimi Nicolai Langfeldt
(
util-linux@math.uio.no ). Dostępne są one poprzez
anonimowe ftp z
ftp.icm.edu.pl w katalogu /pub/Linux/sunsite/system/misc.
Zawiera ona takie narzędzia jak: setterm, rdev, czy
ctrlaltdel, które są związane z jądrem. Jak Rik twierdzi,
Nie instaluj tego zestawu bez zastanowienia. Nie trzeba
instalować całej zawartości pakietu, mogłoby to nawet spowodować
poważne problemy.
Jak więszkość pakietów, ten był łatą i dodatkiem dla jądra. Łaty zostały z czasem związane na stałe z jądrem, a ten program stał się osobnym pakietem. W rękach niedoświadczonego użytkownika jest on bardzo niebezpieczny. Więc nie używaj go jeśli nie wiesz co robisz.
gpm - general purpose mouse czyli, w dość wolnym tłumaczeniu :), mysz o ogólnym zastosowaniu. Program ten pozwala na przenoszenie zawartośći pomiędzy wirtualnymi konsolami i inne pożyteczne rzeczy jak np. tłumaczenie protokołów pomiędzy różnymi typami myszek, używanie wielu myszek...
Jeśli twoje nowe jądro zaczyna robić dziwne rzeczy po rutynowym
odnowieniu, przypuszczalnie zapomniałeś wydać polecenie make clean
przed kompilacją nowego jądra. Oznaki takie to może być cokolwiek
od zawieszania się systemu bez powodu, przez dziwne problemy z
funkcajmi I/O, do ślimaczej szybkości. Nie zapomnij także wydać
polecenia make dep.
Jeśli twoje jadro zżera ogromną ilość pamięci, jest zbyt duże, albo po prostu kompiluje się w nieskończoność nawet jeśli masz swoje nowiutkie 786DX6/440, najprawdopodobniej skonfigurowałeś niepotrzebnie pełno sterowników. Jeśli czegoś nie używasz, to nie konfiguruj, bo to naprawdę zabiera niepotrzebnie pamięć. Najbardziej oczywistym symptomem przy zbyt dużym jądrze jest bardzo częste swapowanie (jeśli twój dysk ciągle rzęzi, a nie jest jednym z tych starych orłów Fujitsu, które brzmią jak lądujący odrzutowiec, przejrzyj konfigurację swojego jądra).
Możesz dowiedzieć się ile pamięci zabiera twoje jądro odejmując
wartość total mem z pliku /proc/meminfo albo z
polecenia free od całkowitej ilości pamięci w twoim
komputerze. Jednak nie jest to najlepsza metoda ponieważ w danym
momencie mogą być uruchomione jeszcze jakieś programy, które też
zabierają pamięć. Najlepiej sprawdzić to poleceniem dmesg.
Znajdź linijkę, która wygląda mniej więcej tak:
Memory: 15124k/16384k available (552k kernel code, 384k reserved, 324k data)
Jeśli twoje wartości sa zbliżone do tych (a właściwie kernel code powinna być trochę mniejsza - 450-500k) to jądro jest OK!
Jeśli "po prostu musisz" mieć duże jądro, ale system ci nie
pozwala, to możesz spróbować polecenia make bzimage.
Całkiem możliwe, że jeśli to zrobisz, to będziesz musiał
zainstalować nowszą wersję LILO.
Jeśli się rzeczywiście nie kompiluje, to pewnie jakaś łata się nie
zainstalowała poprawnie. Twoja wersja "gcc" może także być
nie w porządku. Albo pliki nagłówkowe są skopane. Upewnij się
także czy symboliczne dołączenie, o których Linus pisze w README,
są poprawnie zrobione. W ogólności jeśli standardowe jądro się nie
kompiluje, to coś poważnego jest z systemem i niezbędna jest
ponowna instalacja niektórych narzędzi.
Albo kompilujesz jądro w wersji 1.2.x kompilatorem ELF (gcc 2.6.3
i nowsze). Jeśli dostajesz pełno komunikatów, że to i to
undefined to przypuszczalnie tak właśnie jest. Naprawa w
takich przypadkach jest z reguły bardzo prosta. Dodaj następujące
linie na początku pliku /usr/src/linux/arch/i386/Makefile:
AS=/usr/i486-linuxaout/bin/as LD=/usr/i486-linuxaout/bin/ld -m i386linux CC=gcc -b i486-linuxaout -D__KERNEL__ -I$(TOPDIR)/include
Jeśli któraś z tych linii się póżniej powtarza, skasuj tę
powtarzającą się.
Potem make dep i make zImage.
W rzadkich przypadkach "gcc" może się wysypać z powodu
problemów sprzętowych. Komunikaty w tym przypadku to: xxx
exited with signal 15 i w ogólności są one bardzo tajemnicze.
Pewnie bym o tym nie wspominał, gdyby nie to, że mi się to
zdażyło - miałem kiedyś wadliwą pamięć cache a kompilator wtedy
hulał sobie po pamięci gdzie chciał. Najpierw spróbuj
przeinstalwać gcc. Podejrzenia na sprzęt rzucaj dopiero jeśli
jądro się kompiluje przy wyłączonym zewnętrznym cache'u, albo przy
zmniejszonej ilości pamięci RAM itp.
Z reguły ludzi to trochę denerwuje jak im powiesz, że mają popsuty sprzęt. Cóż, ja tego nie zmyślam. Jest FAQ na ten temat - www.bitwizard.nl/sig11/.
/usr/src/linux/arch/i386/boot/zImage wśród innych rzeczy.
To jest nowe skompresowane jądro. make zdisk robi to samo,
z tą różnicą, że umieszcza plik zImage na dyskietce w
stacji A:, którą mam nadzieję włożysz na czas do stacji :). (ten
czas to sam koniec kompilacji, ale na wszelki wypadek radzę włożyć
od razu, bo potem można zapomnieć)
make zdisk to dobry sposób na testowanie nowego jądra;
jeśli coś pójdzie nie tak, po prostu wyjmujesz dyskietkę ze stacji,
resetujesz i po krzyku. Może to być także pomocne jeśli
przypadkowo usuniesz jądro z dysku. (radzę uważać na to co się robi
w katalogu głównym a szczególnie w katalogu /boot). Możesz
jej także użyć do instalacji innych systemów, ponieważ wystarczy
przegrać zawartość tej dyskietki na inną.
Wszystkie, nawet te w połowie sensowne, jądra są skompresowane, z powodu literki "z" na początku. Skompresowane jądro odkompresowuje się automatycznie w czasie wykonywania.
make mrproper spowoduje dokładniejsze wyczyszczenie.
Czasem jest to potrzebne; możesz to robić przy instalacji
każdej łaty (patch). make mrproper skasuje także twój
plik z bieżącą konfiguracją, więc możesz sobie zrobić kopię
tego pliku (.config).
make oldconfig spróbuje skonfigurować jądro na podstawie
starego pliku konfiguracyjnego; przejdzie za ciebie przez proces
konfiguracji (make config). Jeśli jeszcze nigdy przedtem nie
kompilowałeś jądra lub nie masz starego pliku konfiguracyjnego
wtedy przypuszczalnie nie powinieneś tego robić, bo będziesz
chciał zmienić konfigurację domyślną.
Przeczytaj sekcję o modułach na temat szczegółów dotyczących
make modules.
Jeśli masz już nowe jądra i wydaje ci się, że ono działa tak jak
chciałeś, czas aby je zainstalować. Większość ludzi używa do tego
celu LILO (Linux Loader). make zlilo zainstaluje jądro,
uruchomi lilo, aby odświeżyć informacje i przygotuje wszystko, aby
zresetować i załadować nowe jądro. ALE TYLKO w przypadku,
gdy LILO jest skonfigurowane następująco:
jądro to /vmlinuz, lilo jest w /sbin, a twój
plik konfiguracyjny od lilo to /etc/lilo.conf i zgadza
się z tym co jest powyżej.
W innym przypadku musisz użyć bezpośrednio polecenia lilo.
Jest to pakiet całkiem prosty do zainstalowania i używania, ale ma
tendencję do załamywania ludzi swoim plikiem konfiguracyjnym.
Zajrzyj do pliku /etc/lilo/config - w starszych wersjach;
lub /etc/lilo.conf - w nowszych wersjach, i sprawdź
bieżące ustawienia. Plik ten wygląda tak:
image = /vmlinuz
label = Linux
root = /dev/hda1
...
image = odnosi się do aktualnej wersji zainstalowanego
jądra. Większość używa nazwy /vmlinuz. Ale równie dobrze
może to być nazwa xxx, jądro, czy pliczek (nie jestem pewien co
do polskich liter, ale zawsze można poeksperymentować :) )
label = używane jest przez LILO, aby dowiedzieć się jaki
system lub jądro załadować, a root = jest katalogiem
głównym danego systemu. Zrób kopię jądra, którego teraz używasz i
skopiuj nowo zrobione jądro na miejsce starego (czyli napisz
cp zImage /vmlinuz jeśli używasz nazwy vmlinuz i jesteś w
katalogu /usr/src/linux/arch/i386/boot. Potem uruchom
LILO - w nowszych wersjach po prostu uruchamiasz lilo; w
starszych może będziesz musiał uruchomić /etc/lilo/install
albo nawet /etc/lilo/lilo -C /etc/lilo/config.
Jeśli chcesz wiedzieć więcej na temat konfiguracji LILO, albo nie masz LILO, zdobądź najnowszą wersję i poczytaj dokumentację.
Aby załadować jedną ze starszych wersji jądra, które mam nadzieję
zachowałeś :) skopiuj linie od image = xxx w pliku
konfiguracyjnym LILO na dół pliku, zmień xxx na nazwę twojego
zachowanego pliku (wraz z pełną ścieżką). Zmień label = zzz
na np. label = old-kernel i uruchom ponownie lilo.
Możesz też wstawić linię delay = x, gdzie x jest ilością
dziesiętnych części sekundy, do pliku konfiguracyjnego LILO, aby
zatrzymać ładowanie na określoną ilość sekund i przerwać je np.
klawiszem SHIFT, a potem wpisać nazwę którą nadałeś starszej
wersji jądra (tę label = z pliku konfiguracyjnego LILO, a
nie nazwę pliku jądra) w razie gdyby stało się coś nieprzyjemnego.
Pakiety, które pozwalają na odnowienie jądra to łaty. Na przykład:
jeśli masz wersję 1.1.45 i znajdziesz plik o nazwie patch46.gz
to znaczy, że możesz odnowić swoje jądro do wersji 1.1.46. Możesz
zrobić kopię źródeł, które masz (make clean a potem
cd /usr/src; tar zcvf old-kernel.tar.gz linux)
Tak więc kontynuując powyższy przykład załóżmy, że masz plik
patch46.gz w katalogu /usr/src. Bedąc w katalogu
/usr/src wydaj polecenie zcat pacth46.gz | patch -p0
albo patch -p0 < patch46 jeśli łata nie jest
skompresowana. Zobaczysz teraz trochę ścieżek i nazw plików
oraz komunikatów przelatujących przez ekran, o tym co się udało a co
nie. Wszystko to przelatuje zbyt szybko, żeby nadążyć z
czytaniem, także właściwie nie wiesz czy się udało czy nie. Możesz
użyć parametru -s do polecenia patch, aby
poinformować je, żeby wyświetlało tylko komunikaty o błędach. Aby
zobaczyć czy coś poszło nie tak, poszukaj plików z rozszerzeniem
.rej w katalogu /usr/src/linux. Niektóre wersje
patch (starsze wersje, które mogły być skompilowane na gorszym
systemie plików) zostawiają błędy w plikach z rozszerzeniem
#. Możesz użyć polecenia find, aby znaleźć
te pliki:
cd /usr/src/linux; find ./ -name '*.rej' -print
Polecenie to wyświetli wszystkie pliki z rozszerzeniem rej znajdujące się w bieżącym katalogu i jego podkatalogach.
Jeśli wszystko poszło dobrze, wydaj teraz po kolei polecenia
make clean, make config i make dep tak jak opisano w
sekcjach 3 i 4.
Do polecenia patch jest trochę opcji. Jak już wspomniałem,
patch -s spowoduje wyświetlenie na ekran tylko wiadomości
o błędach. Jeśli trzymasz źródła w innym katalogu niż
/usr/src/linux, polecenie patch -p1 wydane w tym
katalogu, gdzie trzymasz źródła zrobi wszystko bez błędów. Inne
opcje polcenia patch są dobrze opisane w podręczniku "man".
(Uwaga: ta sekcja odnosi się w głównej mierze do starszych wersji jądra.)
Najczęstszym problemem było to, że kiedy polecenie patch
modyfikowało plik config.in nie wyglądał on tak jak
powinien, bo zmodyfikowałeś go, aby pasował do twojego komputera.
Zostało to już poprawione, ale w starszych wersjach błąd ten
pozostał. Aby to naprawić, przeczytaj plik config.in.rej
i zobacz co pozostało z oryginalnej łaty. Zmiany są zwykle
zaznaczane znakami + i - na początku linii. Spójrz na linie
otaczające tę zaznaczoną i przypomnij sobie, czy były one
ustawione na tak, czy na nie. Teraz w pliku config.in
zmień "y" na "n" i "n" na "y" tam gdzie trzeba. Wydaj polecenie
patch -p0 < config.in.rej a jeśli poinformuje cię, że
się powiodło, wtedy możesz kontynuować konfigurację i kompilację.
Plik config.in.rej pozostanie, ale możesz go skasować.
Jeśli odkryjesz dalsze problemy, mogłeś zainstalować jakąś łatę
nie w kolejności. Jeśli na ekranie pojawi się taka wiadomość:
previously applied patch detected: Assume -R? oznacza to,
że przypuszczalnie próbujesz nałożyć łatę o wersji mniejszej niż
źródła twojego jądra. Jeśli odpowiesz "y", polecenie patch
spróbuje zdegradować twoją wersję, i najprzypuszcalnie się to nie
powiedzie, przez co będziesz musiał zdobyć całkiem nowe źródła.
(co w sumie wcale nie jest takim złym pomysłem).
Aby odinstalować jakąś łatę użyj patch -R na oryginalnej.
Jak już się wszystko tak pomiesza, że nie będziesz mógł dojść do ładu, to najlepszym sposobem jest zdobyć nowe źródła jądra i zacząć od nowa.
Po zaledwie kilku łatach pliki .orig zaczynają niebezpiecznie
rosnąć. Na przykład: usunięcie plików .orig z wersji 1.1.51, która
była ostatnio czyszczona w wersji 1.1.48 spowodowało zwolnienie
ponad 500 kB dysku.
find . -name '*.orig' -exec rm -f {} ';'
Polecenie to spowoduje usunięcie wszystkich plików .orig z bieżącego katalogu i jego podkatalogów.
Wersje patch, które używają plików .# zamiast plików .rej, używają tyldy (~) zamiast plików .orig.
Są lepsze sposoby pozbycia się plików .orig, które zależą od
polecenia GNU xargs:
find . -name '*.orig' | xargs rm
lub metoda całkiem bezpieczna ale trochę "głośna" (dużo komunikatówna ekranie):
find . -name '*.orig' -print0 | xargs --null rm --
Są jeszcze inne łaty (tzw. niestandardowe), niż te które dystrybuuje Linus. Jeśli ich użyjesz łaty Linusa mogą nie działać i będziesz musiał je albo odinstalować, dopasować źródła albo łatę, zainstalować nowe źródła, albo jakaś kombinacja tego. Może to być trochę frustrujące, więc jeśli nie chcesz grzebać w źródłach (z możliwością narobienia niezłego bajzlu), odinstaluj niestandardowe wersje łat zanim zainstalujesz łatę Linusa, albo po prostu zainstaluj nowe źródła. Wtedy możesz zobaczyć czy łaty niestandardowe wciąż działają. Jeśli nie to albo utknąłeś ze starym jądrem i będziesz próbował zmusić jakoś źródło albo łatę, żeby zaczęła działać, albo będziesz czekał (pewnie błagał) o nową łatę.
Jak pospolite są te niestandardowe łaty?
Przypuszczalnie o nich usłyszysz. Ja używałem łaty "noblink" na
moich wirtualnych konsolach, bo nienawidzę mrugającego kursora. Ta
łata jest (a przynajmniej była) często odnawiana dla nowszych
wersji jądra. Z większością nowych sterowników jako ładowalne
moduły, chociaż częstotliwość niestandardowych łat znacznie spada.
Jądro Linux-a ma wiele zalet, które nie znajdują się w źródłach. Są one rozprowadzane jako osobne pakiety. Niektóre z tych najbardziej popularnych są tu wymienione.
Konsola Linux-owa ma chyba więcej zalet niż na to zasługuje. Pomiędzy nimi znajdują się takie jak: zmiana czcionek, zmiana układu klawiszy, zmiana trybów wyświetlania (w nowszych wersjach). Pakiet kbd to programy, które pozwalają użytkownikowi na robienie tego wszystkiego plus wiele czcionek i układów klawiatur dla prawie wszystkich klawiatur i jest on dostępny z tego samego miejsca, gdzie znajdują się źródła jądra.
Rik Faith (
faith@cs.unc.edu ) złożył razem obszerną
kolekcję narzędzi do Linux-a, które dziwnym trafem nazywają się
util-linux. Obecnie zajmuje się nimi Nicolai Langfeldt
(
util-linux@math.uio.no ). Dostępne są one poprzez
anonimowe ftp z
ftp.icm.edu.pl w katalogu /pub/Linux/sunsite/system/misc.
Zawiera ona takie narzędzia jak: setterm, rdev, czy
ctrlaltdel, które są związane z jądrem. Jak Rik twierdzi,
Nie instaluj tego zestawu bez zastanowienia. Nie trzeba
instalować całej zawartości pakietu, mogłoby to nawet spowodować
poważne problemy.
Jak więszkość pakietów, ten był łatą i dodatkiem dla jądra. Łaty zostały z czasem związane na stałe z jądrem, a ten program stał się osobnym pakietem. W rękach niedoświadczonego użytkownika jest on bardzo niebezpieczny. Więc nie używaj go jeśli nie wiesz co robisz.
gpm - general purpose mouse czyli, w dość wolnym tłumaczeniu :), mysz o ogólnym zastosowaniu. Program ten pozwala na przenoszenie zawartośći pomiędzy wirtualnymi konsolami i inne pożyteczne rzeczy jak np. tłumaczenie protokołów pomiędzy różnymi typami myszek, używanie wielu myszek...
Jeśli twoje nowe jądro zaczyna robić dziwne rzeczy po rutynowym
odnowieniu, przypuszczalnie zapomniałeś wydać polecenie make clean
przed kompilacją nowego jądra. Oznaki takie to może być cokolwiek
od zawieszania się systemu bez powodu, przez dziwne problemy z
funkcajmi I/O, do ślimaczej szybkości. Nie zapomnij także wydać
polecenia make dep.
Jeśli twoje jadro zżera ogromną ilość pamięci, jest zbyt duże, albo po prostu kompiluje się w nieskończoność nawet jeśli masz swoje nowiutkie 786DX6/440, najprawdopodobniej skonfigurowałeś niepotrzebnie pełno sterowników. Jeśli czegoś nie używasz, to nie konfiguruj, bo to naprawdę zabiera niepotrzebnie pamięć. Najbardziej oczywistym symptomem przy zbyt dużym jądrze jest bardzo częste swapowanie (jeśli twój dysk ciągle rzęzi, a nie jest jednym z tych starych orłów Fujitsu, które brzmią jak lądujący odrzutowiec, przejrzyj konfigurację swojego jądra).
Możesz dowiedzieć się ile pamięci zabiera twoje jądro odejmując
wartość total mem z pliku /proc/meminfo albo z
polecenia free od całkowitej ilości pamięci w twoim
komputerze. Jednak nie jest to najlepsza metoda ponieważ w danym
momencie mogą być uruchomione jeszcze jakieś programy, które też
zabierają pamięć. Najlepiej sprawdzić to poleceniem dmesg.
Znajdź linijkę, która wygląda mniej więcej tak:
Memory: 15124k/16384k available (552k kernel code, 384k reserved, 324k data)
Jeśli twoje wartości sa zbliżone do tych (a właściwie kernel code powinna być trochę mniejsza - 450-500k) to jądro jest OK!
Jeśli "po prostu musisz" mieć duże jądro, ale system ci nie
pozwala, to możesz spróbować polecenia make bzimage.
Całkiem możliwe, że jeśli to zrobisz, to będziesz musiał
zainstalować nowszą wersję LILO.
Jeśli się rzeczywiście nie kompiluje, to pewnie jakaś łata się nie
zainstalowała poprawnie. Twoja wersja "gcc" może także być
nie w porządku. Albo pliki nagłówkowe są skopane. Upewnij się
także czy symboliczne dołączenie, o których Linus pisze w README,
są poprawnie zrobione. W ogólności jeśli standardowe jądro się nie
kompiluje, to coś poważnego jest z systemem i niezbędna jest
ponowna instalacja niektórych narzędzi.
Albo kompilujesz jądro w wersji 1.2.x kompilatorem ELF (gcc 2.6.3
i nowsze). Jeśli dostajesz pełno komunikatów, że to i to
undefined to przypuszczalnie tak właśnie jest. Naprawa w
takich przypadkach jest z reguły bardzo prosta. Dodaj następujące
linie na początku pliku /usr/src/linux/arch/i386/Makefile:
AS=/usr/i486-linuxaout/bin/as LD=/usr/i486-linuxaout/bin/ld -m i386linux CC=gcc -b i486-linuxaout -D__KERNEL__ -I$(TOPDIR)/include
Jeśli któraś z tych linii się póżniej powtarza, skasuj tę
powtarzającą się.
Potem make dep i make zImage.
W rzadkich przypadkach "gcc" może się wysypać z powodu
problemów sprzętowych. Komunikaty w tym przypadku to: xxx
exited with signal 15 i w ogólności są one bardzo tajemnicze.
Pewnie bym o tym nie wspominał, gdyby nie to, że mi się to
zdażyło - miałem kiedyś wadliwą pamięć cache a kompilator wtedy
hulał sobie po pamięci gdzie chciał. Najpierw spróbuj
przeinstalwać gcc. Podejrzenia na sprzęt rzucaj dopiero jeśli
jądro się kompiluje przy wyłączonym zewnętrznym cache'u, albo przy
zmniejszonej ilości pamięci RAM itp.
Z reguły ludzi to trochę denerwuje jak im powiesz, że mają popsuty sprzęt. Cóż, ja tego nie zmyślam. Jest FAQ na ten temat - www.bitwizard.nl/sig11/.
/usr/src/linux/arch/i386/boot/zImage wśród innych rzeczy.
To jest nowe skompresowane jądro. make zdisk robi to samo,
z tą różnicą, że umieszcza plik zImage na dyskietce w
stacji A:, którą mam nadzieję włożysz na czas do stacji :). (ten
czas to sam koniec kompilacji, ale na wszelki wypadek radzę włożyć
od razu, bo potem można zapomnieć)
make zdisk to dobry sposób na testowanie nowego jądra;
jeśli coś pójdzie nie tak, po prostu wyjmujesz dyskietkę ze stacji,
resetujesz i po krzyku. Może to być także pomocne jeśli
przypadkowo usuniesz jądro z dysku. (radzę uważać na to co się robi
w katalogu głównym a szczególnie w katalogu /boot). Możesz
jej także użyć do instalacji innych systemów, ponieważ wystarczy
przegrać zawartość tej dyskietki na inną.
Wszystkie, nawet te w połowie sensowne, jądra są skompresowane, z powodu literki "z" na początku. Skompresowane jądro odkompresowuje się automatycznie w czasie wykonywania.
make mrproper spowoduje dokładniejsze wyczyszczenie.
Czasem jest to potrzebne; możesz to robić przy instalacji
każdej łaty (patch). make mrproper skasuje także twój
plik z bieżącą konfiguracją, więc możesz sobie zrobić kopię
tego pliku (.config).
make oldconfig spróbuje skonfigurować jądro na podstawie
starego pliku konfiguracyjnego; przejdzie za ciebie przez proces
konfiguracji (make config). Jeśli jeszcze nigdy przedtem nie
kompilowałeś jądra lub nie masz starego pliku konfiguracyjnego
wtedy przypuszczalnie nie powinieneś tego robić, bo będziesz
chciał zmienić konfigurację domyślną.
Przeczytaj sekcję o modułach na temat szczegółów dotyczących
make modules.
Jeśli masz już nowe jądra i wydaje ci się, że ono działa tak jak
chciałeś, czas aby je zainstalować. Większość ludzi używa do tego
celu LILO (Linux Loader). make zlilo zainstaluje jądro,
uruchomi lilo, aby odświeżyć informacje i przygotuje wszystko, aby
zresetować i załadować nowe jądro. ALE TYLKO w przypadku,
gdy LILO jest skonfigurowane następująco:
jądro to /vmlinuz, lilo jest w /sbin, a twój
plik konfiguracyjny od lilo to /etc/lilo.conf i zgadza
się z tym co jest powyżej.
W innym przypadku musisz użyć bezpośrednio polecenia lilo.
Jest to pakiet całkiem prosty do zainstalowania i używania, ale ma
tendencję do załamywania ludzi swoim plikiem konfiguracyjnym.
Zajrzyj do pliku /etc/lilo/config - w starszych wersjach;
lub /etc/lilo.conf - w nowszych wersjach, i sprawdź
bieżące ustawienia. Plik ten wygląda tak:
image = /vmlinuz
label = Linux
root = /dev/hda1
...
image = odnosi się do aktualnej wersji zainstalowanego
jądra. Większość używa nazwy /vmlinuz. Ale równie dobrze
może to być nazwa xxx, jądro, czy pliczek (nie jestem pewien co
do polskich liter, ale zawsze można poeksperymentować :) )
label = używane jest przez LILO, aby dowiedzieć się jaki
system lub jądro załadować, a root = jest katalogiem
głównym danego systemu. Zrób kopię jądra, którego teraz używasz i
skopiuj nowo zrobione jądro na miejsce starego (czyli napisz
cp zImage /vmlinuz jeśli używasz nazwy vmlinuz i jesteś w
katalogu /usr/src/linux/arch/i386/boot. Potem uruchom
LILO - w nowszych wersjach po prostu uruchamiasz lilo; w
starszych może będziesz musiał uruchomić /etc/lilo/install
albo nawet /etc/lilo/lilo -C /etc/lilo/config.
Jeśli chcesz wiedzieć więcej na temat konfiguracji LILO, albo nie masz LILO, zdobądź najnowszą wersję i poczytaj dokumentację.
Aby załadować jedną ze starszych wersji jądra, które mam nadzieję
zachowałeś :) skopiuj linie od image = xxx w pliku
konfiguracyjnym LILO na dół pliku, zmień xxx na nazwę twojego
zachowanego pliku (wraz z pełną ścieżką). Zmień label = zzz
na np. label = old-kernel i uruchom ponownie lilo.
Możesz też wstawić linię delay = x, gdzie x jest ilością
dziesiętnych części sekundy, do pliku konfiguracyjnego LILO, aby
zatrzymać ładowanie na określoną ilość sekund i przerwać je np.
klawiszem SHIFT, a potem wpisać nazwę którą nadałeś starszej
wersji jądra (tę label = z pliku konfiguracyjnego LILO, a
nie nazwę pliku jądra) w razie gdyby stało się coś nieprzyjemnego.
Pakiety, które pozwalają na odnowienie jądra to łaty. Na przykład:
jeśli masz wersję 1.1.45 i znajdziesz plik o nazwie patch46.gz
to znaczy, że możesz odnowić swoje jądro do wersji 1.1.46. Możesz
zrobić kopię źródeł, które masz (make clean a potem
cd /usr/src; tar zcvf old-kernel.tar.gz linux)
Tak więc kontynuując powyższy przykład załóżmy, że masz plik
patch46.gz w katalogu /usr/src. Bedąc w katalogu
/usr/src wydaj polecenie zcat pacth46.gz | patch -p0
albo patch -p0 < patch46 jeśli łata nie jest
skompresowana. Zobaczysz teraz trochę ścieżek i nazw plików
oraz komunikatów przelatujących przez ekran, o tym co się udało a co
nie. Wszystko to przelatuje zbyt szybko, żeby nadążyć z
czytaniem, także właściwie nie wiesz czy się udało czy nie. Możesz
użyć parametru -s do polecenia patch, aby
poinformować je, żeby wyświetlało tylko komunikaty o błędach. Aby
zobaczyć czy coś poszło nie tak, poszukaj plików z rozszerzeniem
.rej w katalogu /usr/src/linux. Niektóre wersje
patch (starsze wersje, które mogły być skompilowane na gorszym
systemie plików) zostawiają błędy w plikach z rozszerzeniem
#. Możesz użyć polecenia find, aby znaleźć
te pliki:
cd /usr/src/linux; find ./ -name '*.rej' -print
Polecenie to wyświetli wszystkie pliki z rozszerzeniem rej znajdujące się w bieżącym katalogu i jego podkatalogach.
Jeśli wszystko poszło dobrze, wydaj teraz po kolei polecenia
make clean, make config i make dep tak jak opisano w
sekcjach 3 i 4.
Do polecenia patch jest trochę opcji. Jak już wspomniałem,
patch -s spowoduje wyświetlenie na ekran tylko wiadomości
o błędach. Jeśli trzymasz źródła w innym katalogu niż
/usr/src/linux, polecenie patch -p1 wydane w tym
katalogu, gdzie trzymasz źródła zrobi wszystko bez błędów. Inne
opcje polcenia patch są dobrze opisane w podręczniku "man".
(Uwaga: ta sekcja odnosi się w głównej mierze do starszych wersji jądra.)
Najczęstszym problemem było to, że kiedy polecenie patch
modyfikowało plik config.in nie wyglądał on tak jak
powinien, bo zmodyfikowałeś go, aby pasował do twojego komputera.
Zostało to już poprawione, ale w starszych wersjach błąd ten
pozostał. Aby to naprawić, przeczytaj plik config.in.rej
i zobacz co pozostało z oryginalnej łaty. Zmiany są zwykle
zaznaczane znakami + i - na początku linii. Spójrz na linie
otaczające tę zaznaczoną i przypomnij sobie, czy były one
ustawione na tak, czy na nie. Teraz w pliku config.in
zmień "y" na "n" i "n" na "y" tam gdzie trzeba. Wydaj polecenie
patch -p0 < config.in.rej a jeśli poinformuje cię, że
się powiodło, wtedy możesz kontynuować konfigurację i kompilację.
Plik config.in.rej pozostanie, ale możesz go skasować.
Jeśli odkryjesz dalsze problemy, mogłeś zainstalować jakąś łatę
nie w kolejności. Jeśli na ekranie pojawi się taka wiadomość:
previously applied patch detected: Assume -R? oznacza to,
że przypuszczalnie próbujesz nałożyć łatę o wersji mniejszej niż
źródła twojego jądra. Jeśli odpowiesz "y", polecenie patch
spróbuje zdegradować twoją wersję, i najprzypuszcalnie się to nie
powiedzie, przez co będziesz musiał zdobyć całkiem nowe źródła.
(co w sumie wcale nie jest takim złym pomysłem).
Aby odinstalować jakąś łatę użyj patch -R na oryginalnej.
Jak już się wszystko tak pomiesza, że nie będziesz mógł dojść do ładu, to najlepszym sposobem jest zdobyć nowe źródła jądra i zacząć od nowa.
Po zaledwie kilku łatach pliki .orig zaczynają niebezpiecznie
rosnąć. Na przykład: usunięcie plików .orig z wersji 1.1.51, która
była ostatnio czyszczona w wersji 1.1.48 spowodowało zwolnienie
ponad 500 kB dysku.
find . -name '*.orig' -exec rm -f {} ';'
Polecenie to spowoduje usunięcie wszystkich plików .orig z bieżącego katalogu i jego podkatalogów.
Wersje patch, które używają plików .# zamiast plików .rej, używają tyldy (~) zamiast plików .orig.
Są lepsze sposoby pozbycia się plików .orig, które zależą od
polecenia GNU xargs:
find . -name '*.orig' | xargs rm
lub metoda całkiem bezpieczna ale trochę "głośna" (dużo komunikatówna ekranie):
find . -name '*.orig' -print0 | xargs --null rm --
Są jeszcze inne łaty (tzw. niestandardowe), niż te które dystrybuuje Linus. Jeśli ich użyjesz łaty Linusa mogą nie działać i będziesz musiał je albo odinstalować, dopasować źródła albo łatę, zainstalować nowe źródła, albo jakaś kombinacja tego. Może to być trochę frustrujące, więc jeśli nie chcesz grzebać w źródłach (z możliwością narobienia niezłego bajzlu), odinstaluj niestandardowe wersje łat zanim zainstalujesz łatę Linusa, albo po prostu zainstaluj nowe źródła. Wtedy możesz zobaczyć czy łaty niestandardowe wciąż działają. Jeśli nie to albo utknąłeś ze starym jądrem i będziesz próbował zmusić jakoś źródło albo łatę, żeby zaczęła działać, albo będziesz czekał (pewnie błagał) o nową łatę.
Jak pospolite są te niestandardowe łaty?
Przypuszczalnie o nich usłyszysz. Ja używałem łaty "noblink" na
moich wirtualnych konsolach, bo nienawidzę mrugającego kursora. Ta
łata jest (a przynajmniej była) często odnawiana dla nowszych
wersji jądra. Z większością nowych sterowników jako ładowalne
moduły, chociaż częstotliwość niestandardowych łat znacznie spada.
Jądro Linux-a ma wiele zalet, które nie znajdują się w źródłach. Są one rozprowadzane jako osobne pakiety. Niektóre z tych najbardziej popularnych są tu wymienione.
Konsola Linux-owa ma chyba więcej zalet niż na to zasługuje. Pomiędzy nimi znajdują się takie jak: zmiana czcionek, zmiana układu klawiszy, zmiana trybów wyświetlania (w nowszych wersjach). Pakiet kbd to programy, które pozwalają użytkownikowi na robienie tego wszystkiego plus wiele czcionek i układów klawiatur dla prawie wszystkich klawiatur i jest on dostępny z tego samego miejsca, gdzie znajdują się źródła jądra.
Rik Faith (
faith@cs.unc.edu ) złożył razem obszerną
kolekcję narzędzi do Linux-a, które dziwnym trafem nazywają się
util-linux. Obecnie zajmuje się nimi Nicolai Langfeldt
(
util-linux@math.uio.no ). Dostępne są one poprzez
anonimowe ftp z
ftp.icm.edu.pl w katalogu /pub/Linux/sunsite/system/misc.
Zawiera ona takie narzędzia jak: setterm, rdev, czy
ctrlaltdel, które są związane z jądrem. Jak Rik twierdzi,
Nie instaluj tego zestawu bez zastanowienia. Nie