kernel compilen - make modules => systeem kapot?

[Alarmnummer]

Ik zit nu al een tijdje te bladeren en kan er geen duidelijke informatie over vinden. Ik heb net mijn kernel gecompiled, en ik sta nu op het punt om make modules uit te voeren. Maar de vorige keer dat ik dit heb gedaan wou linux niet meer opstarten. Ik heb de vorige keer een nieuwe kernel gemaakt, daarna make modules en de image later in de boot dir gezet. Het was al laat, dus ik heb lilo niet meer aangepast en ben op bed gegaan. Maar toen ik de volgende morgen mijn pc opstartte, kon hij niet meer mijn root filesysteem mounten terwijl ik wel met een oude en goedwerkende kernel ben opgestart.

Ik neem aan dat die 'make modules' modules verwijderd/aangepast heeft en zodoende mijn systeem verneukt. Klopt dit, of had ik gewoon pech en is er iets anders fout gegaan? En als er wel veranderingen optreden, hoe kan je dan gaan experimenteren met een kernell? Voor hetzelfde geld moet je je hele systeem opnieuw installen.

[deadinspace]

make modules zou dat helemaal niet moeten kunnen verneuken, maar als je daar bang voor bent, dan compile je je kernel toch als user? Dan *kan* het niks verneuken.

[Alarmnummer]

Ik zie dat ik een foutje heb gemaakt. Het moest zijn bij 'make modules install'. Op dat moment ga je toch aanpassingen doen aan het systeem? En als je per ongeluk een module vergeet *is ook nog maar een amateur*, dan is je systeem naar zijn grootje?

[odysseus]

Het commando 'make modules' doet nog niets engs. Het wordt pas eventueel lastiger met 'make modules_install'. Ook dat kan echter niet voor een 'can't mount root filesystem'-probleem zorgen: je root-filesystem wordt immers nooit via een module aangesproken. Ik gok dat je de vorige keer vergeten bent om ext2-support (of welk filesystem je ook gebruikt) in te schakelen (of het als module hebt gecompileerd), waardoor er geen driver was om je root-partitie mee te mounten. Dat is meestal de oorzaak van de melding die je kreeg.

[odysseus]

Alarmnummer schreef op 24 oktober 2002 @ 21:30:
Ik zie dat ik een foutje heb gemaakt. Het moest zijn bij 'make modules install'. Op dat moment ga je toch aanpassingen doen aan het systeem? En als je per ongeluk een module vergeet *is ook nog maar een amateur*, dan is je systeem naar zijn grootje?

Daar zie ik een fout...tikfout of niet? Als je 'make modules install' draait, dan doet hij eerst 'make modules' en daarna 'make install'...dat is niet wat je waarschijnlijk bedoelde . Daarvoor moet je 'make modules_install' gebruiken...

[Solarsparc]

make modules build alleen maar, hooguit make modules_install zou je modules aanpassen en dat zou een foutmelding kunnen veroorzaken. Wat ik vermoed is dat je een onderdeel zoals ramdisk support of initrd support bent vergeten mee te compileren, of wellicht een filesystem support (ext3?)

[blaat blaat weer te laat]

[Valium]

Als je een make modules_install doet, dan worden de modules in /lib/modules gezet in de submap van de kernelversie (2.4.19 bijvoorbeeld). Als je dus 2.4.19 gaat compileren terwijl je al een 2.4.19 hebt, dan zullen de modules overschreven worden.
Oplossingen:
* Houd altijd een iets oudere kernel bij de hand (2.4.18 bijvoorbeeld).
* Zet de modules van tevoren even weg (/lib/modules/2.4.19.old bijvoorbeeld)
* Zorg ervoor dat je het in een keer goed doet.

Je moet natuurlijk ook nooit vergeten lilo te draaien na het installeren van een nieuwe kernel. Maar dat hoef ik jou niet meer te vertellen gok ik zo.

Voor de Debianners onder ons: Een kernel-debje maken om netjes te kunnen installeren doe je zo: "make menuconfig" (of xconfig, etc...), "make-kpkg kernel-image". Dan wordt er een make dep make bzImage, make modules en een virtuele make modules_install gedaan en alles wordt netjes in een debje geklust. Als je dan met dpkg -i kernel-image-blabla.deb de kernel installeert wordt automatisch lilo gedraait en de vorige kernel gebackupt naar LinuxOLD (in lilo). Gewoon een tip van Valium.

[ Voor 0% gewijzigd door Valium op 24-10-2002 21:37 . Reden: Valium kan niet typen vandaag ]

[Alarmnummer]

Zo`n vermoeden had ik ook al. Ik moet dus goed oppassen met een nieuwe kernel bouwen. Ik heb dit keer er niet al te veel uitgehaald. Maar zijn er nog dingen waar je op moet letten? *is niet een volledige noob*

[Valium]

Alarmnummer schreef op 24 oktober 2002 @ 21:36:
Zo`n vermoeden had ik ook al. Ik moet dus goed oppassen met een nieuwe kernel bouwen. Ik heb dit keer er niet al te veel uitgehaald. Maar zijn er nog dingen waar je op moet letten? *is niet een volledige noob*

Controleer 4x de dingen die je ECHT nodig hebt. IDE-driver, Root-Filesystem en eventueel een netwerkdriver heb je echt wel nodig voor een basissysteem om weer een kernel te kunnen bouwen of om hulp te kunnen vragen. Let er ook op dat je geen athlopn-kernel bouwt voor een Pentium ofzo. Dan wil het ook zo rot starten

[Alarmnummer]

Dat soort simpele dingen lukt me ook nog wel Ik zit eerder met grafische zaken ed.

*past zijn config snel even aan van amd -> p3"

[Alarmnummer]

Ik zie trouwens dat bij mij in /lib/modules 2 directories staan ipv modules, namelijk 2.4.19-13mdk en 2.4.19-13mdkenterprise Je kan dus wel per kernel aparte module directories aanmaken.

[edit]
Ik ben die makefile even aan het doorploegen en daar kan je inderdaad een path meegeven waar hij zijn libraties gaat plaatsen.

Maar wat is de syntax voor deze aanroep?
make modules install /lib/modules/2.4.19-13clean?

[Verwijderd]

IMHO gewoon even je oude modules dir mv'n naar een andere dir.
en als alles haywire gaat. (kleine kans)
dan kun je alltijd een een rescue starten en die dir terug zetten.

[Expander]

Je vertelt dat het laat was en je lilo nog niet had uitgevoerd.

Hij liep dus niet vast na 'make modules' (kan niet lijkt me), maar na het kopiëren van de kernel (naar zelfde bestand of zelfde symlinknaam).

[Alarmnummer]

Waarom dat geklungel? Je kan je modules installen in een subdir, dus nu kan ik keurig per kernel een eigen subdir maken. Ik hou dus altijd mijn oude goed werkende kernels/modules en ik kan makkelijk experimenteren met nieuwe kernels/modules.

Ik vraag me dus alleen af hoe de kernel zijn modules kan vinden. Ik ben wat aan het rondbladeren maar nog geen antwoord gevonden. Volgens mij zal er in het begin van de build al duidelijk moeten zijn waar de kernel zijn modules kan vinden.

[Alarmnummer]

Expander schreef op 24 oktober 2002 @ 22:09:
Je vertelt dat het laat was en je lilo nog niet had uitgevoerd.

Hij liep dus niet vast na 'make modules' (kan niet lijkt me), maar na het kopiëren van de kernel (naar zelfde bestand of zelfde symlinknaam).

De nieuwe kernel die heb ik er gewoon in gecopieerd (bzImage) en aangezien daar nog geen andere file van bestaat kan dit geen conflicten veroorzaken in de boot dir. Maar het probleem zat hem dus in die modules. Ik had een oude kernel opgestart, met niet bijbehorende modules denk ik.

[odysseus]

De kernel kiest die directory aan de hand van de naam van de kernel, iets als '2.4.19' of '2.4.18mdk'. Deze kun je bovenin de Makefile van de kernel aanpassen (of voor Debian met de optie voor het revisienummer laten aanmaken). Daarnaast kun je naderhand in /etc/modules.conf (of in /etc/modutils/paths) nog directories toevoegen.

[Alarmnummer]

Dan zou dit moeten werken:
MODLIB:=$(INSTALL_MOD_PATH)/lib/modules/$(KERNELRELEASE)clean
?

En wat is de hoogste optimalisatie die ik veilig kan toepassen, 2 of 3? (zie hem namelijk net staan )

[Verwijderd]

3 is geloof ik nog veilig, dan garandeert gcc nog dat de code werkt. .

[odysseus]

Nee, voor de kernel dien je geen 3 te gebruiken als ik het me goed herinner...je hebt wel kans dat het lukt, maar het is het risico niet waard. Compileer liever KDE of XFree86 met dergelijke opties, dat levert veel meer op.

[Alarmnummer]

Ik ben al met uitzonder veel plezier overgestapt op fluxbox. KDE vind ik persoonlijk vrij bloat. Ik gebruik maar een beperkt aantal tools, en dat is niet aan mijn kde install te zien. Verder is KDE veel meer dan alleen een windows manager en heeft oa ook veel tools die ik niet gebruik omdat ik een variant ervan gebruik. Voor mij dus even geen kde meer

[deadinspace]

En bescherming tegen zulke tikfouten kun je natuurlijk krijgen door je kernel als user te compilen

En van de optimalisatie flags voor de kernel moet je afblijven, die regelen de Makefiles zelf. En geloof me, de kerneldevelopers kunnen heel wat beter dan jij beslissen wat optimaal en betrouwbaar is.
En afaik is alleen gcc 2.95 "veilig" verklaard, maar als je het zeker wil weten moet je eens googlen.

[Alarmnummer]

Ik heb op mijn systeem geen typefouten gemaakt hoor Alleen bij het posten heb ik de verkeerde make target opgegeven.

En verder geef ik mijn install 1 week Ik ben op dit moment veel aan het experimenteren met linux en dan is het zo en dan handig(er) om een verse install te doen. Dus een 'te geoptimaliseerde' kernel is nog niet zo`n probleem.

[imdos]

Je wordt er vanzelf behendig in ... dat kernel compileren! maar wat wel degelijk kan helpen is goed de help-files lezen als je iets niet zeker weet.

Ik ga er tegenwoordig vanuit dat ik een zo kaal mogelijke kernel heb .. maar heb toch wel zo'n 1100 KB grote kernel! hier zit wel veel multimedia zut in en nfs & smb etc. Kleiner als 430 KB is me nog niet overkomen en was met 2.2.x

[_Squatt_]

odysseus schreef op 24 oktober 2002 @ 22:17:
De kernel kiest die directory aan de hand van de naam van de kernel, iets als '2.4.19' of '2.4.18mdk'. Deze kun je bovenin de Makefile van de kernel aanpassen (of voor Debian met de optie voor het revisienummer laten aanmaken). Daarnaast kun je naderhand in /etc/modules.conf (of in /etc/modutils/paths) nog directories toevoegen.

Ik verander inderdaad altijd de EXTRAVERSION als ik een nieuwe kernel ga bouwen. Dan komen de modules in een andere directory terecht, en heb ik altijd nog een werkende kernel+modules mocht ik toch iets vergeten zijn.

De vorige kernel kan ik dan natuurlijk ook nog in lilo kiezen.

[Alarmnummer]

Ik heb dus weer problemen gekregen. Hij heeft geen files geplaatst in de /lib/modules/2.4.19-13custom en ik kon niet meer opstarten. Ik heb er dus weer een nieuwe install moeten doen, maar ik snap dus niet waarom het fout gaat. Ik heb die makefile nog even doorgekeken, en daar staat ook in dat hij de modules naar die directory moet schrijven.

[odysseus]

En welke make-commando's heb je precies gegeven?

[Alarmnummer]

make dep
make xconfig
make bzImage
make modules
make modules install

[_Squatt_]

Alarmnummer schreef op 25 oktober 2002 @ 15:56:
make dep
make xconfig
make bzImage
make modules
make modules install

De laatste regel moet zijn:

code:

make modules_install

met een underscore dus.

Nu doe je op het laatst 'make modules' en 'make install'.

edit:

En ik dacht dat 'make dep' altijd na je 'make xconfig' moest. Alhoewel dat geen probleem zou moeten zijn als je je config niet veranderd hebt.

[Alarmnummer]

grrr... in mijn linux boek staat gewoon 'make modules install' (heb het nog even gecontroleerd).

en die make dep die doet toch niets anders dan alle dependencies (dus libraties/tools/sources) controleren?

[_Squatt_]

Alarmnummer schreef op 25 oktober 2002 @ 16:06:
en die make dep die doet toch niets anders dan alle dependencies (dus libraties/tools/sources) controleren?

Euhm, ik dacht dat dat uitzocht welke modules afhankelijk waren van welke andere modules enzo, wat zou verklaren waarom er na een 'make menuconfig' altijd staat "you must run 'make dep' now.".

_{maar het is zeker niet ondenkbaar dat ik het fout heb, want ik kan me niet herinneren dat ik het ergens gelezen heb. Waarschijnlijk zelf iets bedacht wat aannemelijk klinkt en er maar vanuitgegaan dat het klopte}

[Alarmnummer]

ik zie trouwens in mijn boek ook nog een 'depmod -a' staan. Waar is die goed voor?? (Het zal wel iets met die dependencies te maken hebben, maar wat gebeurt er precies?)

:z <-klik mij

[Alarmnummer]

Hmmzz.. gewoonlijk moet ik de bzImage uit de /arch/i386/boot pakken, maar ik zie nu ook dat er een vmlinux bestand in de basis kernel source directory is gekomen. Waar is die goed voor? De size is trouwens ook verschillend.

[odysseus]

Alarmnummer schreef op 25 oktober 2002 @ 16:06:
grrr... in mijn linux boek staat gewoon 'make modules install' (heb het nog even gecontroleerd).

Gheh, ik zei al in de vierde post van deze thread dat dat niet klopte .

Alarmnummer schreef op 25 oktober 2002 @ 17:12:
Hmmzz.. gewoonlijk moet ik de bzImage uit de /arch/i386/boot pakken, maar ik zie nu ook dat er een vmlinux bestand in de basis kernel source directory is gekomen. Waar is die goed voor? De size is trouwens ook verschillend.

Dat zou een uncompressed kernel kunnen zijn...neem gewoon de bzImage in arch/i386/boot om mee te installeren.

[Alarmnummer]

odysseus schreef op 25 oktober 2002 @ 18:41:
[nohtml]
Gheh, ik zei al in de vierde post van deze thread dat dat niet klopte .

hmmmzz.. tijd voor een nieuwe Maarja.. die underscore zie je ook erg makkelijk over het hoofd

Dat zou een uncompressed kernel kunnen zijn...neem gewoon de bzImage in arch/i386/boot om mee te installeren.

De kernel is dit keer wel goed gecompileerd (dus systeem is niet verneukt), maar krijg op dit moment de volgende foutmelding:
kernel panic: vfs unable to mount rootsfs on 03:07

Aan de liloconfig kan het niet liggen, want die heb ik afgezien van de image locatie gecopieerd. Ik gebruik trouwens Reiser-FS, en die is al module in mijn kernel geplaatst, dus ik snap eerlijk gezegd niet wat er fout gaat.

[Boomerang]

Alarmnummer schreef op 25 oktober 2002 @ 18:48:
[...]

hmmmzz.. tijd voor een nieuwe Maarja.. die underscore zie je ook erg makkelijk over het hoofd


[...]

De kernel is dit keer wel goed gecompileerd (dus systeem is niet verneukt), maar krijg op dit moment de volgende foutmelding:
kernel panic: vfs unable to mount rootsfs on 03:07

Aan de liloconfig kan het niet liggen, want die heb ik afgezien van de image locatie gecopieerd. Ik gebruik trouwens Reiser-FS, en die is al module in mijn kernel geplaatst, dus ik snap eerlijk gezegd niet wat er fout gaat.

De driver van een root fs kan nooit als een module functioneren, die moet altijd rechtstreeks in de kernel worden gebakken. Correct me if i'm wrong..

edit:

typo's enzow

[sebas]

Hmm, daar struikelde ik net ook over. Je moet immers een rootfs kunnen benaderen om de modules ueberhaupt te kunnen laden.

Aan de andere kant, als je geen aparte /boot partitie hebt en je boot dus vanaf reiserfs, hoe kan dat dan? De kernel staat immers op de reiserfs partitie en die kun je blijkbaar wel mounten aangezien mijn systeem is opgestart.

* sebas bakt die dingen trouwens allemaal gewoon static, hier zijn al meerdere discussies over geweest, maar mijn uitkomst was dat dit in elk geval problemen met het laden van modules voorkomt.

[odysseus]

Lilo weet de locatie van de kernel, dus kan de kernel wel automatisch gevonden worden. Module-lokaties zijn echter variabel (als in: niet op een bekende sector van de HD) en dus niet hard-coded (in de huidige kernelserie in ieder geval), waardoor ze niet direct kunnen worden aangesproken. Modules kunnen als gewone files gelezen worden, maar dat kan pas als de driver voor het bestandssysteem waar die modules op staan geladen is...vandaar dat die driver altijd statisch in de kernel moet zitten. _{Ik noemde in de derde post van deze thread voornoemde oorzaak al...helderziend?}

[sebas]

odysseus schreef op 25 oktober 2002 @ 21:25:
[...]_{Ik noemde in de derde post van deze thread voornoemde oorzaak al...helderziend?}

Nee, ik heb recentelijk wat met de linux kernel zitten prutsen en dit was een van de dingen die me bij nader inzien nogal opvielen. Ik neem aan dat voor grub en andere bootmanagers ongeveer hetzelfde geldt?

[Alarmnummer]

Ik ben intussen al weer een heel stuk verder, en ben nu bezig om versie 2.4.19 in elkaar te zetten waar alle onnodige dingen uit zijn gehaald. Ik heb hiervoor dus mijn custom modules gehad in /lib/modules/2.4.19-12mdkcustom (zootje van mandrake met veel te veel onzin) en nu gewoon in /lib/modules/2.4.19 Maar als ik nu met de nieuwe kernel opstart, dan krijg ik in mijn bootlog de volgende foutmelding te zien:
gpm: gpm startup succeeded
modprobe: modprobe: Can't open dependencies file /lib/modules/2.4.19-13mdkcustom/modules.dep (No such file or directory)

Waarom blijft hij om die directory zeuren? (Directory bestaat trouwens niet meer). De standaard kernels zitten hier niet om te zeuren, maar mijn nieuwe dus wel. Het kan dus geen gemeenschappelijk bestand zijn, anders hadden ze er allemaal last van gehad. Ik zou alleen niet weten waar deze specifieke informatie dan wel staat. Het staat ook niet in lilo (voor zover dat mogelijk is).

[edit]
aha.. het is dus verplicht lilo ook te gaan draaien als je een nieuwe kernel hebt gemaakt. Het is dus al gefixed.