Če po rutinski nadgradnji jedro počne zares čudne reči, ste
pred prevajanjem novega jedra morda pozabili napisati
make clean
. Simptomi so lahko karkoli, od zmrznjenega
sistema, čudnih V/I problemov do slabega (počasnega) delovanja.
Preverite tudi, ali ste ukazali make dep
.
Če vaše jedro požira velike količine pomnilnika, je preveliko in/ali le traja neskončno dolgo, da se prevede, čeprav imate nov procesor Quadbazillium-III/440, ste najverjetneje vključili podporo veliko nepotrebnih zadevščin (gonilnikov naprav, datotečnih sistemov itd.). Če naprave ne uporabljate, je ne podprite v jedru, saj to zasede pomnilnik. Najočitnejši simptom prenapihnjenega jedra je ekstremno izmenjavanje pomnilnika z diskom sem ter tja; če se vaš disk nenehno oglaša in ni eden tistih starih Fujitsujevih Eagles, katerih zvok lahko primerjamo s pristajanjem reaktivnih letal, preglejte nastavitve jedra.
Koliko pomnilnika zaseda jedro, izveste z odštevanjem vrednosti
,,total mem`` v izpisu /proc/meminfo
ali z izhodom ukaza
,,free
`` od količine vsega pomnilnika.
Nastavitvene izbire za računalnike PC so: najprej v kategoriji splošnih nastavitev (angl. General Setup) vključite podporo zaporednih vrat (angl. Parallel port support) in strojno opremo osebnih računalnikov (angl. PC-style hardware). Nato v Znakovnih napravah (angl. Character devices) podprite tiskalnik na vzporednih vratih (angl. Parallel printer support).
Potem so tu še imena. Linux 2.2 poimenuje tiskalniške naprave drugače
od prejšnjih izdaj. Posledica tega je, da napravi lp1
v
vašem starem jedru v novem jedru verjetno ustreza naprava
lp0
. Uporabite dmesg
ali poglejte v dnevnik v
imeniku /var/log
ter ugotovite novo ime.
Če se ne prevede, je verjetno krivo to, da je popravek spodletel ali pa
je vaša izvirna koda nekako pokvarjena. Morda nimate prave različice
prevajalnika gcc
ali pa je tudi z njim kaj narobe (na primer,
vključne datoteke so lahko napačne). Preverite, ali so simbolične
povezave, ki jih Linus priporoča v datoteki README
, pravilno
izvedene. V splošnem, če se standardna jedra ne prevajajo, je nekaj
resno narobe s sistemom in vnovična namestitev nekaterih orodij je
neizogibna.
V nekaterih primerih lahko gcc
odpove zaradi strojnih
težav. Sporočila o takih napakah so nekaj kot ,,xxx exited with
signal 15`` in so navadno videti zelo skrivnostno. Tega sploh ne bi
omenil, a se mi je nekoč zgodilo, da sem imel nekaj slabega
predpomnilnika in prevajalnik se je pritoževal povsem naključno. Če
imate težave, poskusite najprej znova namestiti gcc. Sumničavi
postanite samo, če se vaše jedro lepo prevede z izključenim zunanjim
predpomnilnikom, zmanjšano količino RAM ipd.
Ljudje so navadno vznemirjeni, ko izvejo, da bi lahko imeli tudi
težave s strojno opremo. Hja, tega si ne izmišljujem. Cel kup
pogostih vprašanj je tudi na to temo -- najdete jih na
http://www.bitwizard.nl/sig11/
.
Niste pognali programa lilo ali pa ga niste pravilno nastavili.
Nekoč me je zafrkavala vrstica v konfiguracijski datoteki lila, ki
je bila ,,boot = /dev/hda1
`` namesto ,,boot =
/dev/hda
``. (To je lahko sprva zelo moteče, a ko imate enkrat
delujočo nastavitveno datoteko, vam je ni treba spreminjati.)
Ojoj! Najboljše, kar lahko storite ta hip, je, da zaženete operacijski
sistem z diskete ali s plošče CD-ROM in potem pripravite še eno
zaganjalno disketo (kot bi jo naredil ukaz ,,make zdisk
``).
Vedeti morate, kje je vaš korenski (/
) datotečni sistem in
katere vrste je (npr. second extended, minix). V spodnjem primeru
morate vedeti tudi, v kakšnem datotečnem sistemu leži vaše drevo
izvirne kode /usr/src/linux
, kakšne vrste je in kje je
navadno nameščen (z mount
).
V naslednjem primeru je /
enak /dev/hda1
in
datotečni sistem, ki vsebuje /usr/src/linux
na
/dev/hda3
, navadno nameščen na /usr
. Oba sta
datotečna sistema vrste ext2 (second extended). Delujoča slika jedra v
imeniku /usr/src/linux/arch/i386/boot
se imenuje
bzImage
.
Zamisel je taka, da uporabimo delujoče jedro zImage
na novi
disketi. Še ena možnost, ki lahko deluje bolje ali pa tudi ne
(odvisno od konkretne metode, s katero ste zavozili svoj sistem), je
opisana za tem zgledom.
Najprej zaženite sistem s kombinacije disket boot in root ali z reševalne diskete in namestite delujočo sliko jedra:
# mkdir /mnt # mount -t ext2 /dev/hda3 /mnt
Če vam mkdir
pravi, da imenik že obstaja, se ne
zmenite zanj. Zdaj pojdite z ukazom cd
na imenik, v katerem je
delujoče jedro. Pozorni bodite na to, da je
/mnt + /usr/src/linux/arch/i386/boot - /usr = /mnt/src/linux/arch/i386/boot
V disketni pogon ,,A:`` vložite formatirano disketo (ne diskov boot ali root!), prepišite sliko jedra na disketo in jo nastavite za svoj korenski datotečni sistem.
# cd /mnt/src/linux/arch/i386/boot # dd if=bzImage of=/dev/fd0 # rdev /dev/fd0 /dev/hda1
Naredite cd
na /
in odmestite običajni datotečni
sistem /usr
:
# cd / # umount /mnt
Zdaj lahko še enkrat zaženete sistem z nove diskete. Ne pozabite
tokrat po zagonu pognati lilo
(ali karkoli je že bilo
narobe)!
Kot smo omenili zgoraj, je možna še ena običajna pot. Če imate delujočo
sliko jedra v /
(/vmlinuz
, na primer), jo lahko
uporabite za zagonsko disketo. Če veljajo vsi zgoraj našteti pogoji
in je slika jedra /vmlinuz
, izvedite te spremembe v zgoraj
opisanem zgledu: spremenite /dev/hda3
v /dev/hda1
(datotečni sistem /
), /mnt/src/linux
v
/mnt
, in if=bzImage
v if=vmlinuz
. Opombo o
tem, kako dobimo /mnt/src/linux
, lahko spregledate.
Uporaba programa lilo na velikih diskih (večjih od 1024 cilindrov) lahko povzroča težave. Preberite lilo mini-HOWTO ali dokumentacijo lila, če potrebujete pomoč pri tem.
warning: bdflush not running
``
To je lahko resen problem. Od jedra izdaje po 1.0 (okoli 20. aprila
1994) se je program ,,update
``, ki periodično izplakne vmesni
pomnilnik datotečnega sistema, posodabljal in nadomestil. Dobite
izvirno kodo ,,bdflush
`` (najdete jo tam, kjer ste našli
jedro) in namestite ta program (verjetno boste medtem pognati vaš
sistem pod starim jedrom). Program se sam namesti kot
,,update
`` in po vnovičnem zagonu se novo jedro ne bo več
pritoževalo.
Čudno, a marsikdo ne more pripraviti pogona ATAPI do tega, da bi deloval, verjetno zato, ker gre lahko marsikaj narobe.
Če je vaš CD-ROM edina naprava na konkretnem vmesniku IDE, morate nastaviti skakače kot ,,master`` ali ,,single``. To je menda najpogostejša napaka.
Creative Labs (na primer) je postavil vmesnik IDE na zvočne kartice. A posledica tega je, da imajo nekateri ljudje en sam vmesnik, veliko jih ima dva vmesnika IDE na matičnih ploščah (navadno na IRQ15), torej je splošna praksa označiti vmesnik SoundBlasterja kot tretji vhod IDE (IRQ11, pravijo).
To pri Linuxu povzroča težave, saj različice 1.2.x ne podpirajo tretjega vmesnika IDE (ta podpora je v serijah 1.3.x, a to je razvojna različica, saj se spomnite, in ne izvaja avtomatskega iskanja). Temu se lahko izognemo na več načinov.
Če že imate druga vrata IDE, jih morda ne uporabljate ali še nimajo na sebi dveh naprav. Vzemite pogon ATAPI z zvočne kartice in ga povežite na drugi vmesnik. Potem lahko onemogočite vmesnik zvočne kartice, kar tako ali tako privarčuje IRQ.
Če nimate drugega vmesnika, nastavite skakač na vmesniku zvočne kartice (ne na zvočnem delu zvočne kartice) kot IRQ15, drugi vmesnik. Moralo bi delovati.
Poiščite novo različico programa route
in vseh drugih
usmerjevalnih programov. Datoteka /usr/include/linux/route.h
(ki je pravzaprav v imeniku /usr/src/linux
) se je spremenila.
Nadgradite vsaj na različico 1.2.1.
Not a compressed kernel Image file
`` (datoteka s sliko jedra ni stisnjena)
Ne uporabljajte datoteke vmlinux
, ki je narejena v imeniku
/usr/src/linux
, kot zaganjalno sliko;
[..]/arch/i386/boot/bzImage
je prava datoteka.
Spremenite besedo dumb
v linux
v opisu zaslonskega
terminala v datoteki /etc/termcap
. Morda boste morali tudi
narediti nov zapis.
Izvirno kodo jedra Linuxa sestavljajo številne datoteke
(datoteke, ki se končujejo na .h
), na katere se sklicujejo
standardne datoteke v imeniku /usr/include
. Nanje se
navadno sklicujemo takole (tu je xyzzy.h
nekaj v imeniku
/usr/include/linux
):
#include <linux/xyzzy.h>
Navadno je v imeniku /usr/include
povezava, imenovana
linux
, z imenikom include/linux
vaše izvirne kode
jedra (/usr/src/linux/include/linux
v tipičnem sistemu). Če
te povezave ni tam ali če kaže na napačen kraj, se večina stvari sploh
ne bo prevedla. Če ste se odločili, da zaseda izvirna koda jedra
preveč prostora na disku in ste jo zbrisali, je očitno v tem težava.
Lahko pa je tudi kaj narobe z dovoljenji datotek; če ima vaš
root
nastavitev umask, ki ne dovoljuje drugim uporabnikom, da
bi kot privzeto lahko gledali njegove datoteke, in ste izluščili
izvirno kodo jedra brez izbire p
(ohrani datotečne načine),
ti uporabniki ne bodo mogli uporabljati prevajalnika za C. Čeprav
lahko uporabite ukaz chmod
in to popravite, je verjetno laže
še enkrat izvleči vključene datoteke. To lahko storite enako, kot ste
storili na začetku z vso izvirno kodo, le z dodatnim argumentom:
# tar zxvpf linux.x.y.z.tar.gz linux/include
Opomba: ,,make config
`` bo naredil povezavo
/usr/src/linux
, če je še nimate.
Naslednji zgled ukazov utegne koristiti tistim, ki se sprašujete, kako povečati nekatere mehke omejitve, ki jih privzame jedro:
# echo 4096 > /proc/sys/kernel/file-max # echo 12288 > /proc/sys/kernel/inode-max # echo 300 400 500 > /proc/sys/vm/freepages