Linux kerneld mini-HOWTO | ||
---|---|---|
Prev |
X
meldingen wanneer ik
/sbin/ifconfig uitvoer?xxx
maar
ik heb mijn kernel net opnieuw geconfigureerd zonder
xxx
ondersteuning! Zo om en nabij kernelversie 1.3.80 werd de netwerkcode
gewijzigd dat het 't laden van protocol families
als modules mogelijk maakte (b.v. IPX, AX.25 en AppleTalk).
Dit zorgde voor de aanvulling van een nieuw kerneld verzoek:
net-pf-X
, waarbij
X
een nummer is die het protocol aanduidt
(zie /usr/src/linux/include/linux/socket.h
voor de betekenis van de diverse nummers). Helaas vangt
ifconfig deze meldingen per ongeluk af,
zodat bij een heleboel mensen een paar meldingen worden gelogd
wanneer het systeem boot en het draait
ifconfig om het loopback device in te stellen.
De meldingen zijn onschuldig, en je kunt ze deactiveren door
het toevoegen van de regels:
alias net-pf-3 off # Vergeet AX.25 alias net-pf-4 off # Vergeet IPX alias net-pf-5 off # Vergeet AppleTalk |
aan /etc/conf.modules. Je voegt natuurlijk geen regel toe om IPX te deactiveren als je IPX wel als een module gebruikt.
2. Na het starten van kerneld, wordt mijn systeem zo langzaam als een slak wanneer ik mijn ppp-verbinding activeer
Er zijn hier diverse meldingen van. Het lijkt op een
ongelukkige interactie tussen kerneld en het
tkPPP script dat op een aantal
systemen wordt gebruikt om de PPP verbinding op te zetten
en te monitoren. Het script voert blijkbaar loops uit
terwijl het ifconfig draait.
Dit activeert kerneld, te zoeken naar de
net-pf-X
modules
(zie hiervoor), de systeembelasting hoog houdend en mogelijk
veel Cannot locat module for
net-pf-X
meldingen
in de systeemlog veroorzakend. Er is geen bekende oplossing voor,
anders dan geen gebruik te maken van
tkPPP, of het zodanig te wijzigen
dat het een andere manier om de verbinding te monitoren gebruikt.
Voeg een regel toe voor de SCSI-hostadapter aan het bestand /etc/conf.modules. Zie de beschrijving van de scsi_hostadapter hiervoor.
Dit is een bug in de module utility's, die alleen in binutils 2.6.0.9 en later aan het licht komt en het is ook gedocumenteerd in de release note van de binutils. Dus lees dat of haal een upgrade op voor de module-utilities die deze bug corrigeert.
De instellingen voor een module worden opgeslagen in de module zelf wanneer het wordt geladen. Dus wanneer kerneld automatisch een module uit het geheugen verwijdert, zijn alle instellingen die je hebt ingesteld vergeten en de volgende keer dat de module weer wordt geladen keert het terug naar de standaardinstellingen.
Je kunt kerneld aangeven een module te configureren door een programma uit te voeren nadat de module automatisch is geladen. Zie Pre/Post Install on the post-install entry.
Dat kan niet. Geen van de dosemu versies, officiële of ontwikkelaarsversies ondersteunt het laden van de dosemu modules via kerneld. Met kernel 2.0.26 echter, heb je de speciale dosemumodules niet meer nodig; upgrade gewoon naar dosemu 0.66.1 of een nieuwere versie.
Wanneer de kernel een verzoek aan kerneld verstuurt, verwacht het hiervan binnen een seconde een bevestiging terug te ontvangen. Als kerneld deze bevestiging niet zendt, wordt deze melding gelogt. Het verzoek wordt opnieuw gestuurd en zou tenslotte door moeten komen.
Dit gebeurt gewoonlijk op systemen met een zeer hoge belasting. Aangezien kerneld een gebruikersproces is, wordt het net als elk ander proces op het systeem gepland. Ten tijden van hoge belasting, wordt het wellicht niet op tijd uitgevoerd om de bevestiging terug te sturen voordat de kernel onderbreekt.
Probeer het opnieuw opstarten van kerneld als
dit bij een lage belasting gebeurt. Kill het kerneld proces,
en start het weer op met de opdracht
/usr/sbin/kerneld. Als het probleem blijft
aanhouden dan zou je een bug report moeten mailen naar
<linux-kernel@vger.rutgers.edu>
, maar
verzeker je er alsjeblieft van dat
de door je in gebruik zijnde versies van de kernel, kerneld
en module utility's up-to-date zijn voor je het als probleem
post. Controleer de benodigdheden in
linux/Documentation/Changes
Er zijn een aantal meldingen waardoor de opdracht mount(8) niet wacht op kerneld totdat het de module voor het bestandssysteem heeft geladen. lsmod toont wel dat kerneld de module laadt, en als je de opdracht mount onmiddellijk herhaalt, lukt het wel. Dit schijnt een bug te zijn in de module-utilities versie 1.3.69f waardoor een aantal Debian gebruikers wordt getroffen. Het kan worden gecorrigeerd door een latere versie van de module utility's op te halen.
Je moet de ncpfs utility's compileren met -DHAVE_KERNELD. Zie de ncpfs Makefile.
Je hebt een oudere versie van de smbmount utility's in gebruik. Haal de laatste versie op (0.10 of later) vanaf het SMBFS archief op TSX-11
11. Ik heb alles als modules gecompileerd, en nu boot mijn system niet of kerneld kan de module voor het root bestandssysteem niet laden!
Je kunt niet alles modularizeren: In de kernel moeten zich voldoende drivers bevinden om je root bestandssysteem te kunnen mounten, en de nodige programma's om kerneld te starten.[1]. Wat je niet kunt modularizeren:
de driver voor de harddisk waar je root bestandssysteem op voorkomt
de driver voor het root bestandssysteem zelf
de binary format loader voor init, kerneld en andere programma's
Nieuwere versies van kerneld hebben de GNU dmb library, libgdbm.so nodig om te kunnen draaien. De meeste installaties hebben dit bestand in /usr/lib, maar waarschijnlijk start je kerneld voordat het /usr bestandssysteem is gemount. Een symptoom hiervan is dat kerneld tijdens het starten van het systeem niet (vanuit je rc-scripts) zal starten, maar prima draait als je het met de hand start nadat het systeem is geboot. De oplossing is de kerneld opstart te verplaatsen nadat /usr is gemount of door de gdbm library naar je root bestandssysteem te verplaatsen, b.v. naar /lib.
13. Ik krijg Cannot load module xxx
maar
ik heb mijn kernel net opnieuw geconfigureerd zonder
xxx
ondersteuning!
De Slackware installatie (mogelijk anderen) bouwt een standaard /etc/rc.d/rc.modules die een expliciete modprobe uitvoert op een variëteit aan modules. Exact welke modules worden geladen met modprobe is afhankelijk van de oorspronkelijke configuratie van de kernel. Je hebt je kernel waarschijnlijk opnieuw geconfigureerd om er één of meer modules uit te laten die in rc.modules met modprobe worden getracht te laden, vandaar de foutmelding(en). Werk het rc.modules bestand bij door voor modules die je niet langer gebruikt een commentaarteken te plaatsen of verwijder rc.modules in zijn geheel en laat kerneld de modules laden wanneer ze nodig zijn.
14. Ik heb mijn kernel en modules opnieuw gecompileerd en krijg bij het booten steeds meldingen over unresolved symbols
Je hebt waarschijnlijk je kernel opnieuw
geconfigureerd en gecompileerd en daar wat modules uitgelaten.
Je hebt een aantal modules die je niet langer gebruikt
in de /lib/modules directory. De
eenvoudigste manier om dit te corrigeren is het verwijderen
van de /lib/modules/x.y.z
directory en de opdracht make modules_install
vanuit de kernel broncode directory nogmaals op te starten.
Dit probleem komt alleen voor wanneer je de kernel opnieuw
configureert zonder van versie te wijzigen. Wanneer je deze
foutmelding te zien krijgt wanneer je een nieuwe kernelversie
hebt geïnstalleerd, dan gaat het om een ander probleem.
Oneven genummerde Linux versies zijn ontwikkelaarskernels. Als zodanig kan ervan worden verwacht dat er van tijd tot tijd iets breekt. Een van de dingen die veelbetekenend is gewijzigd is de wijze waarop modules worden afgehandeld, en waar de kernel en modules in het geheugen worden geladen.
Samengevat: als je modules wilt gebruiken in combinatie met een ontwikkelaarskernel, dan moet je
het bestand Documentation/Changes lezen en hierin opzoeken welke packages moeten worden bijgewerkt op je systeem
het laatste modutils package gebruiken, beschikbaar vanaf AlphaBits op Red Hat of de mirror site op TSX-11
Ik raad op z'n minst het gebruik van kernel 2.1.29 aan, als je modules wilt gebruiken met een 2.1. kernel.
kerneld bood oorspronkelijk enige ondersteuning voor het tot stand brengen van dialup netwerkverbindingen op verzoek; pakketjes naar een netwerk proberen te versturen zonder dat er een verbinding was zorgde ervoor dat kerneld het /sbin/request_route script opstartte om een PPP of SLIP-verbinding op te zetten.
Achteraf leek dit niet zo'n goed idee. Alan Cox van Linux networking fame schreef naar de linux-kernel mailinglist
De request-route materie is verouderd, gebrekkig en onnodig [...] Het is bovendien verwijderd uit de 2.1.x structuren.
In plaats van het gebruik van het request-route script in combinatie met kerneld, kan ik je van harte het diald package van Eric Schenk aanbevelen om je demand dialing beheren.
[1] | In werkelijkheid is dit niet waar. Late 1.3.x en alle 2.x kernels ondersteunen het gebruik van een initiële ramdisk die door LILO of LOADLIN wordt geladen; het is mogelijk in een zeer vroeg stadium van het bootproces modules vanaf deze disk te laden. Hoe je dit doet is beschreven in het bestand linux/Documentation/initrd.txt dat wordt meegeleverd met de kernel bronbestanden. |