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 Quadbazillium-III/4400, 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.
Opcje które musisz włączyć na PC-cie to: Najpierw w sekcji "General Setup" włącz "Parallel port support" oraz "PC-style hardware". Następnie w sekcji "Character devices" włącz "Parallel printer support".
No i potem zostają nazwy. W wersji 2.2 zastosowano inne nazwy niż w
starszych wersjach. Powodem tego jest, to że w starym jądrze miałeś
lp1 a teraz jest to lp0. Spójrz do dmesg albo w
katalogu /var/log/.
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.
W niektórych 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/.
Albo nie uruchomiłeś lilo po skopiowaniu jądra na miejsce
starego, albo źle skonfigurowałeś. Najczęściej spotykanym
problemem jest nie wkompilowanie obsługi twoejgo dysku lub systemu
ext2. Kiedyś miałem problem z plikiem konfiguracyjnym LILO; było
tam boot = /dev/hda1 a powinno być boot =
/dev/hda. Na początku to może byc naprawdę denerwujące, ale
potem jak już masz dobry plik konfiguracyjny nie powinieneś go
zmieniać.
Oooj! Najlepszą rzeczą jaką można zrobić to załadować system z
dyskietki lub CDROMu (no trzeba je oczywiście mieć :) ) i przygotować nową
dyskietkę startującą (np. make zdisk). Musisz wiedzieć,
gdzie jest twój główny system plików i jakiego jest typu. (ext2,
minix). W przykładzie poniżej musisz także wiedzieć gdzie i na
jakim systemie jest /usr/src/linux i gdzie jest zwykle
zamontowany.
W następującym przykładzie "/" to /dev/hda1, a partycja, na której
znajduje się katalog linux to /dev/hda3 normalnie montowana na
/usr. Działające jądro jest w katalogu
/usr/src/linux/arch/i386/boot i nazywa się bzImage.
Pomysł polega na tym, że jeśli masz działające bzImage, można tego użyć dla nowej dyskietki. Inna alternatywa, która może, ale nie musi działać (to zależy jak bardzo namieszałeś) opisana jest za tym przykładem.
Najpierw, załaduj system z dyskietki, którą akurat masz i zamontuj system plików, na którym znajduje się działające jądro:
mkdir /mnt mount -t ext2 /dev/hda3 /mnt
Jeśli pojawi się komunikat, że katalog /mnt już jest - zignoruj go. Przy mount na pewno pojawi się komunikat ostrzegający, że montujesz niesprawdzony system plików - zignoruj go. Zmień katalog na ten, w którym znajduje się działające jądro (pamiętaj, że teraz masz dysk w katalogu /mnt). Umieść sformatowaną dyskietkę w stacji A: (nie dyskietkę, z której startowałeś !!!), przerzuć jądro na dyskietkę i skonfiguruj je dla twojego głównego systemu plików:
cd /mnt/src/linux/arch/i386/boot dd if=bzImage of=/dev/fd0 rdev /dev/fd0 /dev/hda1
Zmień katalog na / (cd /) i odmontuj katalog /mnt (umount /mnt). Powinieneś być teraz w stanie załadować system tak jak normalnie z tej dyskietki. Nie zapomnij uruchomić lilo po restarcie (czy co tam źle zrobiłeś).
Jak już wspomniałem jest jeszcze inna metoda. Jeśli masz kopię działającego jądra, możesz jej użyć dla zrobienia dyskietki startowej. Weźmy znów powyższe warunki i załóżmy, że działająca kopia to /vmlinuz. Zrób to samo co powyżej z tymi zmianami: /dev/hda3 zmień na /dev/hda1/ (gł. system plików) /mnt/src/linux na /mnt if=bzImage na if=vmlinuz
------------------------------------------------------------------
Od tłumacza:
Szczerze powiem/napiszę, że nie wiem po co ten człowiek tak komplikuje sprawę. Podam tu sposób, ktorego ja używam:
Najpierw sprawdź czy masz takie linijki na początku
pliku /etc/lilo.conf:
prompt timeout=50
Jeśli nie to je dopisz.
W swoim pliku /etc/lilo.conf mam zawsze dwie sekcje:
image=/boot/vmlinuz
label=linux
root=/dev/hda1
read-only
image=/boot/vmlinuz-old
label=linux-old
root=/dev/hda1
read-only
Ja nazywam jądra z wersją na końcu (/vmlinuz-2.0.18) i robię
symboliczne dołączenie ln -s /vmlinuz-2.0.18 /vmlinuz.
Jeśli kompiluję tę samą wersję jądra, to przed kompilacją/instalacją
ZAWSZE robię kopię jądra, które mi działa (powiedzmy
cp /vmlinuz-2.0.18 /vmlinuz.2.0.18.old);
Jak już skompiluję jądro to kopiuje je na /vmlinuz-wersja, przedtem
KOPIA !!! - tylko jeśli kompilujemy tę samą wersję jądra, którą
już używamy, bo nowsza wersja będzie miała inny numer na końcu. Po
skopiowaniu zmieniamy dołączenie symboliczne (jeśli instalujemy
nową wersję) - rm /vmlinuz; ln -s /vmlinuz-nowa_wersja /vmlinuz;
oraz ln -s /vmlinuz-2.0.18.old /vmlinuz-old;
potem uruchamiamy lilo i restartujemy komputer. Jeśli
nowe jądro nie działa, to startujemy stare jądro (wpisujemy po
pojawieniu się boot: lub LILO: na ekranie linux-old) i
po wciśnięciu ENETERa mamy znowu działający system.
Jeśli nie działające jądro było w tej samej wersji co poprzednie
(po prostu potrzebowałeś coś dodać), to trzeba uruchomić system w
trybie "single" (linux-old init single), odzyskać stare
moduły ze zrobionej poprzednio kopii katalogu
/lib/modules/x.y.z i zrestartować jeszcze raz system
pamiętając, żeby startować stare jądro. Albo po prostu zmień
odpowiednie dowiązanie /vmlinuz, żeby wskazywało też na starą
wersję jądra (ln -s /vmlinuz-x.y.z.old /vmlinuz) i NIE
ZAPOMNIJ po każdej takiej operacji uruchomić /sbin/lilo.
------------------------------------------------------------------
Używanie LILO z dużymi dyskami (z wiekszą ilością cylindrów niż 1023) może powodować problemy. Przeczytaj mini-HOWTO LILO i Large-Drives, jeśli chcesz znać więcej szczegółów.
No i dobrze, że pisze, bo to może być poważny problem. Poczynając
od wersji jądra 1.0.0 (około 20 kwietnia 1994) program update,
który okresowo zapisuje zawartość bufora na dysk, został zmieniony.
Zdobądź źródła programu "bdflush" (powinieneś je znaleźć tam gdzie
jądro) i skompiluj. Dopóki nie uruchomisz tego programu radzę
używać wersji jądra starszej od 1.0.0 (Czy ta wersja jest jeszcze
do zdobycia !!!?). Instaluje się samo jako update, a po
restarcie nowe jądro nie powinno juz narzekać.
Naprawdę dziwne. Bardzo dużo ludzi ma ten problem. Pewnie dlatego, że jest dużo przypadków, w których to się może dziać.
Jeśli twój CD-ROM to jedyne urządzenie na konkretnym interfejsie IDE, musi być skonfigurowany zworkami jako master lub single. To jest najczęstszy problem.
Creative Labs umieszcza teraz interfejs IDE na swoich kartach dźwiękowych. To prowadzi do ciekawego problemu, bo niektórzy mają tylko jeden interfejs IDE, wielu ma dwa interfejsy IDE na swoich płytach głównych (zwykle na IRQ15), więc najpopularniejszym rozwiązaniem jest uczynić interfejs na karcie dźwiękowej trzecim (IRQ11, a przynajmniej tak mi mówili).
To powoduje w Linux-ie problemy, ponieważ wersja 1.2.x nie obsługuje trzeciego interfejsu IDE (obsługa jest w którejś z wersji 1.3.x, ale pamiętaj - to jest wersja testowa, i nie wykrywa sama tego interfejsu). Aby to obejść masz trzy możliwości:
Jeśli masz już drugi interfejs, to przełóż CD-ROM na ten drugi interfejs jeśli jest wolny. Możesz wtedy wyłączyć interfejs z karty dźwiękowej, co zachowa jedno IRQ.
Jeśli nie masz drugiego interfejsu, ustaw interfejs na karcie dźwiękowej (ale nie ten od dźwięku, tylko IDE) na przerwanie IRQ15 za pomocą zworek. Powinno działać.
Weź nową wersję programu route i wszelkie inne programy,
które się zajmuja rutingiem.
/usr/include/linux/route.h (który właściwie jest plikiem
w /usr/src/linux) sie zmienił.
Weź wersję co najmniej 1.2.1.
Nie używaj jako jądra pliku vmlinux w katalogu
/usr/src/linux stworzonego podczas kompilacji. Plik,
który powinieneś użyć to:
/usr/src/linux/arch/i386/boot/bzImage.
Zmień słowo dumb na linux w pliku /etc/termcap
w sekcji dotyczącej konsoli. Mozliwe też, że będziesz musiał
zrobić terminfo.
Źródła jądra zawierają pewną liczbę plików nagłówkowych (te co się
kończą na .h), do których odwołują się standardowe pliki
nagłówkowe w /usr/include. Przeważnie wygląda to tak:
#include <linux/xxyy.h>
Zwykle w katalogu /usr/include jest symboliczne
dołączenie linux wskazujące na /usr/src/linux/include/linux.
Jeśli dołączenia tego nie ma, albo wskazuje na złe miejsce, to
rzeczywiście większość programów się nie skompiluje. Jeśli
zdecydowałeś, że źródła zajmują za dużo miejsca na dysku i
skasowałeś je, to to jest właśnie twój problem. Razem z tymi
źródłami skasowałeś pliki nagłówkowe. Inny problem to problem z
dostępem do plików: Jeśli twój root ma umask ustawiony tak, że
użytkownicy nie mogą widzieć plików przez niego stworzonych, i
rozpakowałeś źródła bez opcji p (zachowaj oryginalne flagi
dostępu), użytkownicy nie będą mogli użyć kompilatora. Najprościej
naprawić to w ten sposób:
zaloguj się jako root cd /usr/src/linux/ chmod -R go+r include/
Kilka następujących przykładowych poleceń może pomóc tym, którzy zastanawiają się jak zwiększyć pewne programowe ograniczenia wprowadzone przez jądro:
echo 4096 > /proc/sys/kernel/file-max echo 12288 > /proc/sys/kernel/inode-max echo 300 400 500 > /proc/sys/vm/freepages