Kernel compilen; hoe doen we dat?

[Spider.007]

Enkele dagen heb ik wederom besloten om linux op mijn laptop te installeren; en nadat ik mijn 1400x1050 LCD aan de praat kreeg werd ik weer helemaal enthousiast over de mogelijkheden. Na wat rondgeknoeit te hebben met de bij Slackware 9.1 bijgeleverde 2.4.22 kernel heb ik besloten om 2.6.0-test11 te gaan compileren. Dit ging allemaal hardstikke goed; nadat ik op GoT een aantal manier had gevonden om goed een kernel te compilen.

• Wat is (volgens mij) het voordeel van zelf compilen:
Het voordeel is dat je zelf kunt selecteren welke hardware je wilt ondersteunen of niet. Als je bijvoorbeeld voor je server een standaard RedHat kernel pakt zit hier bijvoorbeeld ondersteuning voor je geluidskaart in die je nooit zal gebruikern op die bak. Door zelf je kernel te compilen kun je hardware die je niet gaat gebruiken simpelweg niet meenemen in de kernel; met als gevolg dat de computer sneller opstart en stabieler draait. Ook geef je bij het compileren van je kernel aan voor welk type processor je deze maakt. Een standaard kernel zal vaak meerdere processortypen ondersteunen (AMD & Pentium & 486 processoren) Aangezien er in je computer vaak slechts 1 type zit kun je deze ene processor ondersteunen; en andere niet. Specifieke optimalisatie kunnen zo ook toegevoegd worden.

• Welke commandos gebruik ik om een 2.6 kernel te compileren:

code:

make clean
make xconfig
make bzImage
make modules
make modules_install
cp arch/i386/boot/bzImage /boot
cp System.map /boot
cp .config /boot/config
lilo -v

Klopt bovenstaande allemaal?

Vragen die ik momenteel nog heb openstaan; hoe kan ik met de informatie uit modprobe --showconfig en lsmod erachter komen welke modules ik wel en niet nodig heb? Ik kan de 2.4.22 kernel pakken (hierin werkt alles goed) en dan met lsmod erachter komen welke modules er in gebruik zijn; hoe kan ik echter zien welke zaken in de kernel zelf gecompiled zijn; en ook daadwerkelijk gebruikt worden? Uit de config file kan ik wel halen wat erin zit; maar niet wat ik eruit kan slopen.... in dmesg kan ik ook niet alle informatie vinden. Wat is de juiste manier om de kernel te optimaliseren voor mijn machine?

offtopic:
Dit topic was begonnen als een centrale kerneldraad; ik werd echter zo ontmoedigd door deze post dat ik dat idee maar heb laten vallen

[Verwijderd]

Vergeet je niet een aantal dingen, je hebt ZEKER weten een nieuwe versie van Modutils nodig hebt, modutils voor de 2.6 kernel....

Verder kun je met de 2.6 kernel ook make help doen dan krijg je een overzicht van commando's. Dit draadje is verder overbodig.

Bekijk de MAN of FAQ's dan kom je wel verder!

[smokalot]

Je kunt in /var/log/syslog voor het belangrijkste deel wel zien welke drivers aangesproken worden. welke IDE-driver bijvoorbeeld. dmesg laat net iets minder zien.

Overigens Is het niet helemaal waar dat een redhat kernel langzamer loopt omdat er geluidskaarten bij zitten die je toch niet gebruikt, ze zijn namelijk bijna allemaal gecompileerd als modules, en nemen dus alleen schijfruimte in beslag. Meestal zijn ze om die reden ook nog eens ge-gzipd.

trial en error is overigens ook een handige methode om te kijken wat je nodig hebt gewoon eruit slopen en kijken of het nog werkt...

[Arnout]

smokalot schreef op 10 december 2003 @ 14:51:
trial en error is overigens ook een handige methode om te kijken wat je nodig hebt gewoon eruit slopen en kijken of het nog werkt...

Inderdaad, zo werk ik ook. Kost wel wat tijd, maar je leert er een hoop van.
Gisteren test11 gecompileerd op een debian woody console p166. Na rebooten werkte dhcp niet meer, blijkt dat de oude dhcp (versie 2) niet meer samenwerkt met de nieuwe kernel. dhcp3-client lostte dit probleem op. Je moet het even weten.

Toen packet mmapped I/O aangezet. Na 45mins compileren kwam ik erachter dat de 3com 905b dit niet zo leuk vond... netwerkkaart werd brak oid en ik moest echt de computer stroomloos maken.

Nahja, dat soort dingen, is leuk

[Spider.007]

Ik merk inderdaad ook dat trial en error het beste is om achter zaken te komen; ik heb echter de vervelende eigenschap dat ik de standaard .config pak en alles eruitsloop wat ik niet nodig denk te hebben. Dit heeft meestal tot gevolg dat het helemaal niet meer werkt; en dat ik maar gewoon weer terug ga naar de standaard situatie. Ik zal mezelf met behulp van jullie tips toch eens ertoe gaan zetten netjes zaken 1-voor-1 uit te schakelen

[Verwijderd]

Ik zal proberen subtiele hints te geven over waarom dit niet altijd handig is.

Spider.007 schreef op 10 december 2003 @ 14:40:
• Wat is (volgens mij) het voordeel van zelf compilen:
Het voordeel is dat je zelf kunt selecteren welke hardware je wilt ondersteunen of niet. Als je bijvoorbeeld voor je server een standaard RedHat kernel pakt zit hier bijvoorbeeld ondersteuning voor je geluidskaart in die je nooit zal gebruikern op die bak.

RedHat (Suse, Mandrake) maakt alles een module, je geheugengebruik is dus absoluut niet hoger. Er zit ook geen beveiligingsrisico aan (zie SuckIt en dergelijke rootkits), alleen enkele kBtjes op je harde schijf.

Door zelf je kernel te compilen kun je hardware die je niet gaat gebruiken simpelweg niet meenemen in de kernel; met als gevolg dat de computer sneller opstart en stabieler draait.

Sneller: nee. Stabieler? Ik zie geen enkele reden waarom.

Ook geef je bij het compileren van je kernel aan voor welk type processor je deze maakt. Een standaard kernel zal vaak meerdere processortypen ondersteunen (AMD & Pentium & 486 processoren) Aangezien er in je computer vaak slechts 1 type zit kun je deze ene processor ondersteunen; en andere niet. Specifieke optimalisatie kunnen zo ook toegevoegd worden.

De Gentoo optimalisatietest laat zien dat dit niet het geval is (self-compiled Gentoo inclusief "recommended" optimalisaties was trager dan default pre-compiled distro's). Zelfs al merk je het wel, dan nog is dit verschil ten hoogste enkele procentjes, en meestal merk je het helemaal niet. Het is echt niet merkbaar.

Vragen die ik momenteel nog heb openstaan; hoe kan ik met de informatie uit modprobe --showconfig en lsmod erachter komen welke modules ik wel en niet nodig heb? Ik kan de 2.4.22 kernel pakken (hierin werkt alles goed) en dan met lsmod erachter komen welke modules er in gebruik zijn; hoe kan ik echter zien welke zaken in de kernel zelf gecompiled zijn; en ook daadwerkelijk gebruikt worden? Uit de config file kan ik wel halen wat erin zit; maar niet wat ik eruit kan slopen.... in dmesg kan ik ook niet alle informatie vinden. Wat is de juiste manier om de kernel te optimaliseren voor mijn machine?

Dit is een beetje de centrale reden om het niet te doen. Hoe lief het Aunt Tilly verhaal van onze grote vriend Eric Raymond ook is, de over- over- overgrote meerderheid van de mensen is niet in staat een eigen kernel te compilen, en er is ab-so-luut geen reden om daar verandering in te brengen. De voordelen zijn summier, de nadelen zijn gigantisch. Mensen moeten een gigantische kennis hebben om een eigen kernel te compileren. Voor ons tweakers is dat niet voor te stellen, maar je moet weten wat voor hardware je hebt inclusief (soms) chipnummers en subtypes, soms moet je module opties opgeven, je moet weten welke workarounds en bugfixes je nodig hebt en je moet weten hoe een systeem boot.
Die kennis hebben de distro-makers in overgrote mate. Zij weten alles over kernels en dergelijke. Hun updates zijn vaak goed getest, hun kernels ook, waarom wil je proberen hun werk overnieuw te doen als je er nauwelijks iets mee opschiet?

Maargoed, omdat jij het vraagt: dat kun je uit lspci en consorten halen, en dan gewoon voor elke hardware device de juiste module aanzetten (of in-kernel, maar dat heeft nog grotere nadelen). Hoe je dat uitvindt? Tsja, zie boven... Kennis, daar gaat het om... .

[Spider.007]

Verwijderd schreef op 10 december 2003 @ 16:23:
RedHat (Suse, Mandrake) maakt alles een module, je geheugengebruik is dus absoluut niet hoger. Er zit ook geen beveiligingsrisico aan (zie SuckIt en dergelijke rootkits), alleen enkele kBtjes op je harde schijf.

Is het niet zo dat bij het opstarten elke module wordt geladen; en eventueel weer wordt ontladen zodra blijkt dat hij niet nodig is? Ook zijn er componenten die niet als module geinstalleerd kunnen worden; deze moeten dus ook in de kernel aanwezig zijn

De Gentoo optimalisatietest laat zien dat dit niet het geval is (self-compiled Gentoo inclusief "recommended" optimalisaties was trager dan default pre-compiled distro's). Zelfs al merk je het wel, dan nog is dit verschil ten hoogste enkele procentjes, en meestal merk je het helemaal niet. Het is echt niet merkbaar.

Ik heb inderdaad gelezen dat dat niet sneller is. De voordelen zijn natuurlijk wel dat je je systeem beter leert kennen; en het gaat er bij mij ook moeilijk in dat een full-loaded kernel sneller zou zijn dan een zelfgebakken kernel. Zijn er naast een goede .config file nog meer manieren om de snelheid van de kernel te bevorderen?

Dit is een beetje de centrale reden om het niet te doen. Hoe lief het Aunt Tilly verhaal van onze grote vriend Eric Raymond ook is,

Leuk verhaal; ik denk echter dat aunt Tilly beter kan wachten tot haar neefje remote de kernel kan upgraden Het is voor de n00b gebruiker beter om te wachten tot er een nieuwe kernel van de distro maker uitkomt; in plaats van dat ze zelf hun spullen moeten compilen...

de over- over- overgrote meerderheid van de mensen is niet in staat een eigen kernel te compilen, en er is ab-so-luut geen reden om daar verandering in te brengen. De voordelen zijn summier, de nadelen zijn gigantisch. Mensen moeten een gigantische kennis hebben om een eigen kernel te compileren. Voor ons tweakers is dat niet voor te stellen, maar je moet weten wat voor hardware je hebt inclusief (soms) chipnummers en subtypes, soms moet je module opties opgeven, je moet weten welke workarounds en bugfixes je nodig hebt en je moet weten hoe een systeem boot.
Die kennis hebben de distro-makers in overgrote mate. Zij weten alles over kernels en dergelijke. Hun updates zijn vaak goed getest, hun kernels ook, waarom wil je proberen hun werk overnieuw te doen als je er nauwelijks iets mee opschiet?

Ik wil die kennis ook graag opdoen; dat is voor mij reden genoeg om hiermee te beginnen. Ook vindt ik het leuk het nieuwe spul te draaien en het zal ongetwijfeld nog even duren voor de grote distromakers met 2.6 kernels uitkomen.

Maargoed, omdat jij het vraagt: dat kun je uit lspci en consorten halen, en dan gewoon voor elke hardware device de juiste module aanzetten (of in-kernel, maar dat heeft nog grotere nadelen). Hoe je dat uitvindt? Tsja, zie boven... Kennis, daar gaat het om... .

En die doe ik inderdaad op deze manier op

[Arnout]

Je gaat voorbij aan het fun element, het kan soms ook gewoon leuk zijn
Ik vind het gaaf dat ik een module-loze kernel draai met minimale opties.
Ik ben begonnen met kernel's bakken vanwege iptables/netfilter, en daarna ook nog traffishaping, dan moet je wel je eigen kernel bakken.

[FCA]

Verwijderd schreef op 10 december 2003 @ 16:23:
Ik zal proberen subtiele hints te geven over waarom dit niet altijd handig is.

[...]


RedHat (Suse, Mandrake) maakt alles een module, je geheugengebruik is dus absoluut niet hoger. Er zit ook geen beveiligingsrisico aan (zie SuckIt en dergelijke rootkits), alleen enkele kBtjes op je harde schijf.

[...]

Opstarten gaat (ietsjes) sneller, aangezien er niet geprobed wordt voor niet-bestaande hardware

Sneller: nee. Stabieler? Ik zie geen enkele reden waarom.

Heb jij benchmarks gedraaid? Ik ook niet, dus wie weet of het sneller of langzamer is.

[...]


De Gentoo optimalisatietest laat zien dat dit niet het geval is (self-compiled Gentoo inclusief "recommended" optimalisaties was trager dan default pre-compiled distro's). Zelfs al merk je het wel, dan nog is dit verschil ten hoogste enkele procentjes, en meestal merk je het helemaal niet. Het is echt niet merkbaar.

Je bedoelt dit artikel? Kijk dan ook eens bij dit artikel waar blijkt dat iemand met verstand, Gentoo zo'n 10% sneller dan Debian en Mandrake weet te krijgen, en blijkbaar de mensen van linmagau geen 2.6 kernel aan de praat krijgen bij Mandrake en Debian

[...]


Dit is een beetje de centrale reden om het niet te doen. Hoe lief het Aunt Tilly verhaal van onze grote vriend Eric Raymond ook is, de over- over- overgrote meerderheid van de mensen is niet in staat een eigen kernel te compilen, en er is ab-so-luut geen reden om daar verandering in te brengen. De voordelen zijn summier, de nadelen zijn gigantisch. Mensen moeten een gigantische kennis hebben om een eigen kernel te compileren. Voor ons tweakers is dat niet voor te stellen, maar je moet weten wat voor hardware je hebt inclusief (soms) chipnummers en subtypes, soms moet je module opties opgeven, je moet weten welke workarounds en bugfixes je nodig hebt en je moet weten hoe een systeem boot.

Na een maandje met Mandrake spelen kon ik aardig een kernel compilen. Gigantische kennis? Gezond verstand, algemen computerkennis en de help lezen, dan kom je een aardig eind. Goed, iemand die moeite heeft met Windows kan het niet, maar elke tweaker kan het volgens mij binnen een week doorhebben.
Ik heb nooit chipnummer en sbntypes nodig gehad. Als je hele rare hardware hebt ja, maar dan weet je echt wel wat je hebt. Systeem booten?
Kopiëer kernel naar /boot, ze hem in /etc/lilo.conf en run lilo...

Die kennis hebben de distro-makers in overgrote mate. Zij weten alles over kernels en dergelijke. Hun updates zijn vaak goed getest, hun kernels ook, waarom wil je proberen hun werk overnieuw te doen als je er nauwelijks iets mee opschiet?

Hardware die alleen in testkernels ondersteund wordt?

Maargoed, omdat jij het vraagt: dat kun je uit lspci en consorten halen, en dan gewoon voor elke hardware device de juiste module aanzetten (of in-kernel, maar dat heeft nog grotere nadelen). Hoe je dat uitvindt? Tsja, zie boven... Kennis, daar gaat het om... .

[ Voor 3% gewijzigd door FCA op 10-12-2003 16:54 ]

[usr-local-dick]

Ik dacht vroeger ook altijd dat een minimale statische kernel het beste was.
Tot ik een extra netwerkkaart erbij prikte. Die deed het dus niet. Kernel opnieuw compilen. Prima.
Een tijdje laten besloot ik om ADSL te nemen. Hmmm geen pptp support? Tsja daar had ik niet aan gedacht. Nou ja nog maar een keer opnieuw compilen dan met pptp support.
Toen moest er een geluidskaart in, het leek me namelijk leuk om live audio te streamen met die server. Hee geen sound? Nog maar weer eens compilen, nu met geluid.
Daarna kwam ik tot de ontdekking dat XS4ALL ook ipv6 had. GAAF
Alleen mijn kernel begreep het niet echt. Nog maar een keer compilen, met ipv6 erin.
Later kreeg ik een oude tapedrive, een mooie DDS2 DAT drive.
Hup aansluiten en backuppen maar. Niet dus, mijn kernel was nog IDE only.
Weer opnieuw gebakken, nu met SCSI/tape support.

Begrijp je een beetje waar ik naartoe wil

Je kan niet altijd voorspellen op wat voor hardware je machine gaat draaien. Stel dat je je machine moet gaan vervangen en er is haast bij. Bijvoorbeeld hij is gejat en je moet de backup terugzetten op een compleet andere machine (zowieso weinig kans dat je precies dezelfde hardware nog kan kopen als een jaar terug),
Ik hoef je niet te vertellen wat voor ellende je dan allemaal krijgt met een statische kernel
Als je daarentegen kernels gebruikt die helemaal gemodulized zijn, hoef je alleen de goede modules in /etc/modules te zetten en hoppa je systeem kan weer fijn de lucht in

[Verwijderd]

Sommige systemen zijn tegenwoordig dermate snel dat het me meer tijd kost om /etc/modules te editten dan die kernel opnieuw te compilen. Ik bouw alles statisch dus het is make dep; make bzImage en klaar.

[smokalot]

usr-local-dick schreef op 10 december 2003 @ 19:32:
Ik dacht vroeger ook altijd dat een minimale statische kernel het beste was.
Tot ik een extra netwerkkaart erbij prikte. Die deed het dus niet. Kernel opnieuw compilen. Prima.
Een tijdje laten besloot ik om ADSL te nemen. Hmmm geen pptp support? Tsja daar had ik niet aan gedacht. Nou ja nog maar een keer opnieuw compilen dan met pptp support.
Toen moest er een geluidskaart in, het leek me namelijk leuk om live audio te streamen met die server. Hee geen sound? Nog maar weer eens compilen, nu met geluid.
Daarna kwam ik tot de ontdekking dat XS4ALL ook ipv6 had. GAAF
Alleen mijn kernel begreep het niet echt. Nog maar een keer compilen, met ipv6 erin.
Later kreeg ik een oude tapedrive, een mooie DDS2 DAT drive.
Hup aansluiten en backuppen maar. Niet dus, mijn kernel was nog IDE only.
Weer opnieuw gebakken, nu met SCSI/tape support.

Begrijp je een beetje waar ik naartoe wil

Je kan niet altijd voorspellen op wat voor hardware je machine gaat draaien. Stel dat je je machine moet gaan vervangen en er is haast bij. Bijvoorbeeld hij is gejat en je moet de backup terugzetten op een compleet andere machine (zowieso weinig kans dat je precies dezelfde hardware nog kan kopen als een jaar terug),
Ik hoef je niet te vertellen wat voor ellende je dan allemaal krijgt met een statische kernel
Als je daarentegen kernels gebruikt die helemaal gemodulized zijn, hoef je alleen de goede modules in /etc/modules te zetten en hoppa je systeem kan weer fijn de lucht in

Voor de meeste nieuwe hardware (geluidskaarten, netwerkkaarten, enz), en software-aanpassingen (IPv6, sommige SCSI-meuk, enz) zijn dus modules beschikbaar, en is t een beetje overkill om je complete kernel opnieuw te compileren. Je doet gewoon alleen maar make modules, en laat make bzImage achterwege. Of je kunt ALLES als module compileren (is zelfs een optie bij make config), en alleen dingen als IDE-controllers aanzetten. Dan weet je zeker dat je meteen aan de gang kunt als je nieuwe hardware installeert.

Om op een andere machine aan de gang te kunnen is het inderdaad verstandig om een generic kernel achter de hand te houden. Waarom zou je je originele {red hat, mandrake, slackware} kernel verwijderen? voor die paar megabyte ruimte?

[No13]

Verwijderd schreef op 10 december 2003 @ 19:42:
Sommige systemen zijn tegenwoordig dermate snel dat het me meer tijd kost om /etc/modules te editten dan die kernel opnieuw te compilen. Ik bouw alles statisch dus het is make dep; make bzImage en klaar.

en jij hoeft je .config dan niet aan te passen ofzow?
met alleen make dep en make bzImage krijg je excact dezelfde kernel en lijkt me niet dat je nieuwe hardware ineens wel werkt

/etc/modules.conf aanpassen lijkt me toch echt de snelste oplossing maarja wie ben ik

[Verwijderd]

Spider.007 schreef op 10 december 2003 @ 16:42:
Is het niet zo dat bij het opstarten elke module wordt geladen; en eventueel weer wordt ontladen zodra blijkt dat hij niet nodig is?

Nope. .

Ik heb inderdaad gelezen dat dat niet sneller is. De voordelen zijn natuurlijk wel dat je je systeem beter leert kennen; en het gaat er bij mij ook moeilijk in dat een full-loaded kernel sneller zou zijn dan een zelfgebakken kernel. Zijn er naast een goede .config file nog meer manieren om de snelheid van de kernel te bevorderen?

Ja, met de internals rotzooien. Dit kan via sysctl, via timers veranderen (da's source trouwens), zelf experimenteren met optimalisatie opties, etc. Ik denk dat je op kernelnewbies.org een heleboel informatie hierover kan vinden. Don't b confused by the name, kernelnewbies.org is echt een hele handige site.

Ik wil die kennis ook graag opdoen; dat is voor mij reden genoeg om hiermee te beginnen. Ook vindt ik het leuk het nieuwe spul te draaien en het zal ongetwijfeld nog even duren voor de grote distromakers met 2.6 kernels uitkomen.

Kijk, da's nou een goede reden. .

[pierre-oord]

Moh, ik ben een dikke linux noob, maar heb toch nu zo'n 30 keer kernel gecompileerd in enkele weken, zo niet meer. Op een P75 duurt dat lang overigens, 90 min, maar op m'n eigen bak precies 4 minuten . Waarom zo veel keer: hardware wisselen, zien dat netwerkkaarten als module handiger is om volgorde aan te passen, sata drivers, etc.

[Miki]

Verwijderd schreef op 10 december 2003 @ 14:45:
Vergeet je niet een aantal dingen, je hebt ZEKER weten een nieuwe versie van Modutils nodig hebt, modutils voor de 2.6 kernel....

Verder kun je met de 2.6 kernel ook make help doen dan krijg je een overzicht van commando's. Dit draadje is verder overbodig.

Bekijk de MAN of FAQ's dan kom je wel verder!

Dit is dus een typische linux gebruiker die wel open source minded is maar niet open minded handelt . Wat hebben de andere GoT'ers nu eraan dat er naar de man of faq verwezen word Straks kan bijvoorbeeld iedereen aan de hand van dit topic zijn eigen 2.6 kernel compileren met nuttige info van mede GoT'ers. Op deze mannier krijg je ook mensen warm voor linux!

[smokalot]

Miki schreef op 11 december 2003 @ 14:22:
[...]


Dit is dus een typische linux gebruiker die wel open source minded is maar niet open minded handelt . Wat hebben de andere GoT'ers nu eraan dat er naar de man of faq verwezen word Straks kan bijvoorbeeld iedereen aan de hand van dit topic zijn eigen 2.6 kernel compileren met nuttige info van mede GoT'ers. Op deze mannier krijg je ook mensen warm voor linux!

offtopic:
Het mooie van linux is dat er overal documentatie over is, en ook over dit onderwerp bestaat een howto. Het is maar de vraag waar de TS het meest aan heeft, dat je z'n vraag beantwoord, of dat je m uitlegt hoe ie zelf zijn vraag kan beantwoorden. Overigens vind ik wel dat als je zo'n opmerking maakt dat je dan een linkje geeft naar die HOWTO (http://www.tldp.org/HOWTO/Kernel-HOWTO/index.html).

Op het moment dat alle simpele vragen hier gevraagd en beantwoord worden wordt het moeilijk voor gevorderden om er nog tussendoor te komen.

Dit topic is overigens een beetje een uitzondering (daarom staat ie nog open denk ik), omdat TS niet zomaar wat simpele vragen had, maar meer een discussie wilde starten over het hoe en waarom.

[Miki]

smokalot schreef op 11 december 2003 @ 14:36:
[...]

offtopic:
Het mooie van linux is dat er overal documentatie over is, en ook over dit onderwerp bestaat een howto. Het is maar de vraag waar de TS het meest aan heeft, dat je z'n vraag beantwoord, of dat je m uitlegt hoe ie zelf zijn vraag kan beantwoorden. Overigens vind ik wel dat als je zo'n opmerking maakt dat je dan een linkje geeft naar die HOWTO (http://www.tldp.org/HOWTO/Kernel-HOWTO/index.html).

Op het moment dat alle simpele vragen hier gevraagd en beantwoord worden wordt het moeilijk voor gevorderden om er nog tussendoor te komen.

Dit topic is overigens een beetje een uitzondering (daarom staat ie nog open denk ik), omdat TS niet zomaar wat simpele vragen had, maar meer een discussie wilde starten over het hoe en waarom.

Er zijn dus bepaalde apparaten die niet goed werken (lees je systeem niet bootable maken) met een bepaalde instelling of juist een extra optie nodig hebben om goed te functioneren in kernel 2.6. Deze kom je helaas niet tegen op een howto maar wel op een topic zoals deze. Ben het wel met je eens dat de persoon in kwestie die een kernel gaat compileren wel de basiskennis moet bezitten en dus ook heel goed de kernelHOWTO moet gelezen hebben. Want anders krijg je inderdaad overal nutteloze topics die goed gedocumenteerd terug te vinden zijn.

Het gaat dus om dit principe samen met de kernelhowto als leidraad: "Straks kan bijvoorbeeld iedereen aan de hand van dit topic zijn eigen 2.6 kernel compileren met nuttige info van mede GoT'ers".

[ Voor 10% gewijzigd door Miki op 11-12-2003 14:45 ]

[Mark]

Tsja, de enige reden die ikzelf heb om een kernel recompile te doen is omdat ik bepaalde patches (grsecurity bijvoorbeeld) graag wil gebruiken. Wat ik dus doe is:
1: de laatste kernelversie downloaden
2: de config file van mijn huidige kernel overmeppen (bij een schone install kopieer ik hem uit de juiste kernel directory op de slackware cd)
3: make oldconfig en dan overal een enter opgeven
4: make menuconfig en dan grsecurity aan en eventueel support voor nieuwere hardware zoals sata
5: kernel + modules bakken.
Zie zelf dus ook helemaal niet het nut van alles statisch inbakken (hooguit wil ik low-level SCSI en ata drivers nog wel eens statisch erin gooien), dit kost me gewoon teveel gezeik bij het installeren van nieuwe hardware. En de uiteindelijke snelheidwinst is dus echt minimaal.

[Verwijderd]

Miki schreef op 11 december 2003 @ 14:41:
Er zijn dus bepaalde apparaten die niet goed werken (lees je systeem niet bootable maken) met een bepaalde instelling of juist een extra optie nodig hebben om goed te functioneren in kernel 2.6. Deze kom je helaas niet tegen op een howto maar wel op een topic zoals deze.

Waar denk je dat wij de antwoorden op die vragen vandaan halen?

Juist, van Google. .

[diehard889]

www.linuxdocs.nl staat er ook een how to op over kernel compilen en nog vele anderen

[cavey]

je vergeet nog wat.... een backup voor het geval je kernel fuxxored.... zoals het er nu naar uit ziet heb je maar 1 kernel draaien. Als die niet wil booten....... einde oefening..

ik heb zelf altijd een /vmlinuz en /vmlinuz-old staan.... dat zijn symbolic links naar /boot/vmlinuz-2.x.yy en /boot/vmlinuz-2.x.yy-vorigeversie

zo hoef ik iedere keer alleen m'n symlinks maar aan te passen, lilo te draaien... en ik heb altijd een systeem om op terug te vallen mocht de nieuwe kernel niet stabiel zijn.
(ik roteer de kernel's door.... en heb er meestal 2 a 3 revisies op staan just in case).

[pierre-oord]

smokalot schreef op 11 december 2003 @ 14:36:
[...]

offtopic:
Het mooie van linux is dat er overal documentatie over is, en ook over dit onderwerp bestaat een howto. Het is maar de vraag waar de TS het meest aan heeft, dat je z'n vraag beantwoord, of dat je m uitlegt hoe ie zelf zijn vraag kan beantwoorden. Overigens vind ik wel dat als je zo'n opmerking maakt dat je dan een linkje geeft naar die HOWTO (http://www.tldp.org/HOWTO/Kernel-HOWTO/index.html).

Op het moment dat alle simpele vragen hier gevraagd en beantwoord worden wordt het moeilijk voor gevorderden om er nog tussendoor te komen.

Dit topic is overigens een beetje een uitzondering (daarom staat ie nog open denk ik), omdat TS niet zomaar wat simpele vragen had, maar meer een discussie wilde starten over het hoe en waarom.

The Kernel-HOWTO has been removed for review.

[Verwijderd]

Ik heb een probleempie;

Als 1ste, ik heb echt geen zak verstand van Linux, ja wat command-line sleuren en pleuren enzo!

Ik wil Debian woody installeren op mijn hpt374 controller in sw-raid. Het leuke is dat de hpt374 niet herkend wordt met rescue bf2.4 flop. Ik dus zoeken ennuh. Er is een manier om de hpt374-opensource-v2.10.tgz in de kernel te bakken.

De howto begint met:

Unpack the Highpoint drivers:
# cd /usr/src
# mkdir hpt374-opensource-v2.10
# cd hpt374-opensource-v2.10
# tar xzf ../hpt374-opensource-v2.10.tgz
#

WHAAHHHHHH , hoe kan ik nu iets naar in directory extracten als de hd's niet herkend worden?! Alle compile howto's, die ik gelezen heb, hebben het daarover.
Of is de vorige denkwijze te Windows?

Ik wil;

/root en /boot/ en de hele zooi op raid1 en bv /common op raid5 laten draaien (voor Samba). Mijn mp3's en progsles zijn dan veilig .
Wie oh wie heeft hier een oplossing voor?

[Freee!!]

Verwijderd schreef op 16 december 2003 @ 16:39:
Ik heb een probleempie;

Als 1ste, ik heb echt geen zak verstand van Linux, ja wat command-line sleuren en pleuren enzo!

Ik wil Debian woody installeren op mijn hpt374 controller in sw-raid. Het leuke is dat de hpt374 niet herkend wordt met rescue bf2.4 flop. Ik dus zoeken ennuh. Er is een manier om de hpt374-opensource-v2.10.tgz in de kernel te bakken.

De howto begint met:

Unpack the Highpoint drivers:
# cd /usr/src
# mkdir hpt374-opensource-v2.10
# cd hpt374-opensource-v2.10
# tar xzf ../hpt374-opensource-v2.10.tgz
#

WHAAHHHHHH , hoe kan ik nu iets naar in directory extracten als de hd's niet herkend worden?! Alle compile howto's, die ik gelezen heb, hebben het daarover.
Of is de vorige denkwijze te Windows?

Ik wil;

/root en /boot/ en de hele zooi op raid1 en bv /common op raid5 laten draaien (voor Samba). Mijn mp3's en progsles zijn dan veilig .
Wie oh wie heeft hier een oplossing voor?

Kernel eerst op een bootflop

[Spider.007]

Mr. Liu schreef op 16 december 2003 @ 16:43:
[...]

Kernel eerst op een bootflop

Langere uitleg; start mbv Knoppix oid een Linux systeem op; download de kernel source; apply de patch en compile de kernel. Zet hem op flop; en start vanaf flop de installatie...

[Verwijderd]

Spider.007 schreef op 16 december 2003 @ 16:52:
[...]


Langere uitleg; start mbv Knoppix oid een Linux systeem op; download de kernel source; apply de patch en compile de kernel. Zet hem op flop; en start vanaf flop de installatie...

1) OK, dan heb je eigen smaakje gemaakt, klinkt makkelijk. Leuk, ik prop Knoppix V3.3 in mijn bak, herkend de ps/2 muis, alleen onder KDE doet deze geen zak.

2) Kan Linux Fat file system aan lezen met hpt374-opensource-v2.10.tgz en bv. Linux-2.4.23.tar.gz erop? Scheelt me weer een CDtje verprutsen. Ik heb namelijk geen Linuxbak draaien, oh toch niet Xbox met Gentoox erop, hier zal ik wel niets aan hebben. Zal ik 2.6 kernel nemen? Stabiliteit gaat voorop!

[ Voor 4% gewijzigd door Verwijderd op 16-12-2003 17:14 ]

[Verwijderd]

Verwijderd schreef op 16 december 2003 @ 17:05:
[...]


1) OK, dan heb je eigen smaakje gemaakt, klinkt makkelijk. Leuk, ik prop Knoppix V3.3 in mijn bak, herkend de ps/2 muis, alleen onder KDE doet deze geen zak.

2) Kan Linux Fat file system aan lezen met hpt374-opensource-v2.10.tgz en bv. Linux-2.4.23.tar.gz erop? Scheelt me weer een CDtje verprutsen. Ik heb namelijk geen Linuxbak draaien, oh toch niet Xbox met Gentoox erop, hier zal ik wel niets aan hebben. Zal ik 2.6 kernel nemen? Stabiliteit gaat voorop!

Kan je niet knoppix in de command line opstarten en dan patchen? (via bootoptie: "knoppix 2")

[Spider.007]

Verwijderd schreef op 16 december 2003 @ 18:02:
[...]

Kan je niet knoppix in de command line opstarten en dan patchen? (via bootoptie: "knoppix 2")

offtopic:
He asked me: "What is God to you?" "GoT is the place where I meet my friends," I said.

[Verwijderd]

Ben wat verder. Ik ben nu via ssh ingelogd op een andere bak met Fedora core1 erop.

Ik vond de volgende oplossing.

<url> http://www.gulu.net/krd/h...traid404_linux.html</url>

1) volgens de README in 2.4.23 moet je niet de kernel naar usr/src uitpakken, dus
heb ik de linux-2.4.23.tar.gz uitgepakt naar /common/Raymond.
2) De hpt374-opensource.tgz heb ik uitgepakt in /common/Raymond. De driver gaat ervan uit dat /usr/src/linux de kernel directory is, niet dus!
3) ik heb een symbol link gemaakt: ln -s /usr/src/linux /common/Raymond/linux-2.4.23
4) make RR154X=0 NON_RAID=1 BOOT=1 SMP=0 ATHLON=1

Nu krijg ik dus een foutmelding:


gcc -DDRIVER_VERSION=\"2.1\" -DLIST_H_INCLUDED -DMODVERSIONS -DMODULE -DLINUX -D_LINUX_ -D__KERNEL__=1 -DCONF
IG_PCI -DNO_CROSS_CTRL=1 -D__BOOT_KERNEL_BOOT=1 -D__BOOT_KERNEL_SMP=0 -D__BOOT_KERNEL_UP=0 -D__MODULE_KERNEL_
athlon=1 -Wall -O2 -Wstrict-prototypes -fomit-frame-pointer -I. -I/usr/src/linux/include -I/usr/src/linux/i
nclude/asm-i386 -I/usr/src/linux/drivers/scsi -c hpt.c -o hpt.o
make: gcc: Command not found
make: *** [hpt.o] Error 127

Wat moet ik hier mee?

Ben trouwens nu de kernel met "make config" aan het bewerken.

[ Voor 3% gewijzigd door Verwijderd op 16-12-2003 23:30 ]

[Spider.007]

je moet gcc op die bak zetten

[voodooless]

Als ik andere CFLAGS mee wil geven aan make, kan ik dat dan via make CFLAGS=... bzImage doen? Overschijft dat dan de waardes die in de Makefile staan, of moet ik steeds de makefile aanpassen.

Ik wil AUB geen verhalen horen dat je dat niet moet doen omdat blabla... ik wil gewoon een antwoord, de verhalen ken ik ook wel

[Verwijderd]

Ik heb volgende probleem. ik heb de README van linux-2.6.0 opgevolgd;

BUILD directory for the kernel:

When compiling the kernel all output files will per default be
stored together with the kernel source code.
Using the option "make O=output/dir" allow you to specify an alternate
place for the output files (including .config).
Example:
kernel source code: /usr/src/linux-2.6.N
build directory: /home/name/build/kernel

To configure and build the kernel use:
cd /usr/src/linux-2.6.N

make O=/home/name/build/kernel menuconfig
make O=/home/name/build/kernel
sudo make O=/home/name/build/kernel install_modules install

Ik heb mijn linux-2.6.0 uitgepakt in /home/raymond/ , als ik de 1ste 'make' regel invoer( hierboven), wordt gelijk al make menuconfig opgestart. Ik heb dus de 3 regels achter elkaar ingetokkeld. Na het configureren van de kernel, deze heb ik ook gesaved, krijg ik de volgende foutmeldingen:

makefile:391: .config: no such file or directory
make[1]: nothing to be done for 'make file'
make[2]: 'scrip/fixdep' is up to date
#
#
using default found in /boot/config-2.4.21-0.26mdk
#
en dan TIG regels met;

/boot/config-2.4.21-0.26mdk:xyz: trying to assign noncoexsistent symbol

make[1] *** no rule to make target 'make' . stop

Ik snap niet wat er fout gaat, wie wel?

Zou dit misschie nkunnen komen omdat ik er net achterkom dat ik dit alles vanuit /home/raymond/linux-2.6.0 heb gedaan en niet vanuit //usr/src/linux-2.6.N (deze bestaat bij mij ook niet).

[ Voor 9% gewijzigd door Verwijderd op 18-12-2003 20:54 ]

[Stoney3K]

Verwijderd schreef op 18 december 2003 @ 20:49:
Ik heb volgende probleem. ik heb de README van linux-2.6.0 opgevolgd;

BUILD directory for the kernel:

When compiling the kernel all output files will per default be
stored together with the kernel source code.
Using the option "make O=output/dir" allow you to specify an alternate
place for the output files (including .config).
Example:
kernel source code: /usr/src/linux-2.6.N
build directory: /home/name/build/kernel

To configure and build the kernel use:
cd /usr/src/linux-2.6.N

make O=/home/name/build/kernel menuconfig
make O=/home/name/build/kernel
sudo make O=/home/name/build/kernel install_modules install

Ik heb mijn linux-2.6.0 uitgepakt in /home/raymond/ , als ik de 1ste 'make' regel invoer( hierboven), wordt gelijk al make menuconfig opgestart. Ik heb dus de 3 regels achter elkaar ingetokkeld. Na het configureren van de kernel, deze heb ik ook gesaved, krijg ik de volgende foutmeldingen:

makefile:391: .config: no such file or directory
make[1]: nothing to be done for 'make file'
make[2]: 'scrip/fixdep' is up to date
#
#
using default found in /boot/config-2.4.21-0.26mdk
#
en dan TIG regels met;

/boot/config-2.4.21-0.26mdk:xyz: trying to assign noncoexsistent symbol

make[1] *** no rule to make target 'make' . stop

Ik snap niet wat er fout gaat, wie wel?

Zou dit misschie nkunnen komen omdat ik er net achterkom dat ik dit alles vanuit /home/raymond/linux-2.6.0 heb gedaan en niet vanuit //usr/src/linux-2.6.N (deze bestaat bij mij ook niet).

verkas die kernel inderdaad eens naar /usr/src/linux-2.6.xx en probeer nog eens te bouwen.

[Verwijderd]

Ok voor een gedeelte weet ik al wat er fout ging. Ik had alle regels achter elkaar ingevoerd, ja weet ik veel als n00b, staat toch zo letterlijk de README.

Tijdens het compilen crashte de pc, beetje te geoc'ed. 2de keer lukte compieluh wel, had config.-files gesaved Echter bij de commando regel;

sudo make O=/home/raymond/2.6.0/kernel install_modules install (in mijn geval) krijg ik deze foutmelding;

make[1]: *** No rule to make target 'install_modules'. stop

Ook ff geg00gled, maar nog niets bijzonders over kunnen vinden.

[ Voor 12% gewijzigd door Verwijderd op 19-12-2003 01:15 ]

[Eärendil]

Je moet waarschijnlijk modules_install doen i.p.v. install_modules.
Zie ook 'make help', daar staan de mogelijke targets voor make

[Wolfboy]

komakeef schreef op 11 december 2003 @ 15:20:
je vergeet nog wat.... een backup voor het geval je kernel fuxxored.... zoals het er nu naar uit ziet heb je maar 1 kernel draaien. Als die niet wil booten....... einde oefening..

ik heb zelf altijd een /vmlinuz en /vmlinuz-old staan.... dat zijn symbolic links naar /boot/vmlinuz-2.x.yy en /boot/vmlinuz-2.x.yy-vorigeversie

zo hoef ik iedere keer alleen m'n symlinks maar aan te passen, lilo te draaien... en ik heb altijd een systeem om op terug te vallen mocht de nieuwe kernel niet stabiel zijn.
(ik roteer de kernel's door.... en heb er meestal 2 a 3 revisies op staan just in case).

Om dit wat uit te breiden, ik gebruik altijd de versie van de kernel als naam
dit werkt best goed vind ik zelf
dan krijg je dus dit
• mm-2.6.0r10
• vanilla-2.6.0
en meer
gaat prima hoor

[bolke]

Waarom duurt een compile bij mij zo lang. Ik lees soms dat ze met een half uur klaar zijn. Maar op mijn Pentium III-450 kost het uren.

Zijn er tips waar ik naar kan kijken hoe dit process kan versnellen.

[Verwijderd]

meschin nog even een handige tip voor somige.

er is binnen linux een heel simpele manier op te checken wat voor hardware je hebt.
bestanden die je even in wilt zien als je niet meer precies weet welke hardware er in zit.

/proc/pci (mobo spul en pci slot kaarten)
lsmod (modules die je huidige kernel geladen heeft (en dus schijnbaar nuttig zijn) )
of /proc/modules (zelvde als lsmod)
/proc/driver/ (in deze subdirectory kan nog info over drivers staan. (b.v. nvidia)
ook dmesg is handig om te zien wat er allemaal gebeurt rond boot.

zegt hij b.v. dat je huidige partitie op reiserFS draait. dan is het handig om even te controleren of jouw nieuwe kernel dit ook al aan heeft staan

FB console
2.6 Device Drivers -> Graphic support -> Support for frame buffer devices
nu kun je uit de lijst een driver kiezen (1 driver wel te verstaan, voor zover ik weet)
ik raad hier aan om VESA te kiezen,
VESA
(nou is dit discutabel, maar je kunt er van uit gaan dat VESA werkt.)
-> Console display driver support -> Video mode selecten
-> Console display driver support -> Frame buffer console support

2.4.*
Console drivers -> VGA text console
Console drivers -> Video mode selection support
Console drivers -> Frame buffer support -> support for frame buffer devices
en je kunt nu weer een driver kiezen.
en ik raad weer aan VESA te nemen.
(hier VESA VGA genoemd)


hoop dat het helpt, als je het eenmaal weet is het relatief simpel.
maar ik heb er vroeger vaak genoeg mijn hoofd aan gestoten.

[Confusion]

Om trouwens nog eens antwoord te geven op het subject van dit topic: in Debian is er de volgende manier om gemakkelijk een kernel package te maken van je eigen kernel

• de packages kernel-package, fakeroot en kernel-source.x.y.z installeren,
• tar xjvf /usr/src/kernel-source.x.y.z.tar.bz2 /usr/local/src/ (niet als root)
• cd /usr/local/src/kernel-source.x.y.z
• make menuconfig
• make-kpkg clean
• fakeroot make-kpkg --revision=custom.a.b kernel_image

en dan vervolgens dpkg -i kernel-image.x.y.z_custom.a.b_i386.deb.

[ Voor 7% gewijzigd door Confusion op 19-12-2003 09:53 ]

[riotrick]

bolke schreef op 19 december 2003 @ 08:29:
Waarom duurt een compile bij mij zo lang. Ik lees soms dat ze met een half uur klaar zijn. Maar op mijn Pentium III-450 kost het uren.

Zijn er tips waar ik naar kan kijken hoe dit process kan versnellen.

Het scheelt nogal hoeveel drivers je compileert en op wat voor bak. Om even te vergelijken Mijn Athlon XP 1500+ 512MB doet een kleine 10 minuten over het compilen van een 2.6 kernel. M'n PIII 600MHz 256MB doet over dezelfde kernel een uur of 2. Tja het snelheidsverschil is nou eenmaal erg groot.

[Verwijderd]

Eärendil schreef op 19 december 2003 @ 02:26:
Je moet waarschijnlijk modules_install doen i.p.v. install_modules.
Zie ook 'make help', daar staan de mogelijke targets voor make

Ik heb 'install_modules' veranderd naar 'modules_install' enuhh begint te reutelen, dus. Raar zo staat het in howto van de kernel!

depmod: snd_card_register
depmod: snd_ctl_new1
depmod: snd_ac97_update_bits
depmod: snd_pcm_sgbuf_ops_page
depmod: snd_pcm_hw_constraint_list
depmod: snd_card_free
depmod: snd_free_pci_pages
depmod: snd_card_new
depmod: snd_mpu401_uart_new
Using /usr/src/linux-2.6.0 as source for kernel
make[2]: `arch/i386/kernel/asm-offsets.s' is up to date.
CHK include/linux/compile.h
Kernel: arch/i386/boot/bzImage is ready
sh /usr/src/linux-2.6.0/arch/i386/boot/install.sh 2.6.0 arch/i386/boot/bzImage S ystem.map ""
mke2fs 1.32 (09-Nov-2002)
mke2fs 1.32 (09-Nov-2002)
[root@Neptune linux-2.6.0]#

Ik heb alleen heel veel van de volgende meldingen:

depmod: ip6t_unregister_match
depmod: ip6t_register_match
depmod: *** Unresolved symbols in /lib/modules/2.6.0/kernel/net/ipv6/netfilter/i
p6t_length.ko
depmod: ip6t_unregister_match
depmod: ip6t_register_match
depmod: *** Unresolved symbols in /lib/modules/2.6.0/kernel/net/ipv6/netfilter/i

[frim]

ik geloof dat ipv6 nog steeds als experimental is aangeduid n de kernel? Als je het niet gebruikt, kun je het misschien gewoon uitzetten?

[mOrPhie]

Confusion schreef op 19 december 2003 @ 09:51:
Om trouwens nog eens antwoord te geven op het subject van dit topic: in Debian is er de volgende manier om gemakkelijk een kernel package te maken van je eigen kernel

• de packages kernel-package, fakeroot en kernel-source.x.y.z installeren,
• tar xjvf /usr/src/kernel-source.x.y.z.tar.bz2 /usr/local/src/ (niet als root)
• cd /usr/local/src/kernel-source.x.y.z
• make menuconfig
• make-kpkg clean
• fakeroot make-kpkg --revision=custom.a.b kernel_image

en dan vervolgens dpkg -i kernel-image.x.y.z_custom.a.b_i386.deb.

Alleen heb ik zelf nooit ingezien wat hier makkelijker aan is. Ik compile ook in debian gewoon op de "reguliere" manier en voeg 'm toe aan lilo (of wijzig iets). Wat kun je daar nog makkelijker aan maken. Of anders gezegd: wat is het voordeel van een package gebruiken ten opzichte van "handmatig"?

[frim]

mOrPhie schreef op 19 december 2003 @ 11:17:
[...]


Alleen heb ik zelf nooit ingezien wat hier makkelijker aan is. Ik compile ook in debian gewoon op de "reguliere" manier en voeg 'm toe aan lilo (of wijzig iets). Wat kun je daar nog makkelijker aan maken. Of anders gezegd: wat is het voordeel van een package gebruiken ten opzichte van "handmatig"?

Nu kun je hem ergens op diskette zetten en als je je pc dan een keer disfunctionel ( ) maakt dan kun je debian opnieuw installeren en daarna gelijk je eigen kernel eroverheen gooien.

Verder kan ik ook niks verzinnen

[Verwijderd]

Nu krijg ik dit weer;

[root@Neptune linux-2.6.0]# make bzImage
Makefile:391: .config: No such file or directory
CHK include/linux/version.h
UPD include/linux/version.h
SYMLINK include/asm -> include/asm-i386
HOSTCC scripts/fixdep
"
"
HOSTCC scripts/bin2c
make[2]: `scripts/fixdep' is up to date.
SHIPPED scripts/kconfig/zconf.tab.h
HOSTCC scripts/kconfig/conf.o
HOSTCC scripts/kconfig/mconf.o
SHIPPED scripts/kconfig/zconf.tab.c
SHIPPED scripts/kconfig/lex.zconf.c
HOSTCC -fPIC scripts/kconfig/zconf.tab.o
HOSTLLD -shared scripts/kconfig/libkconfig.so
HOSTLD scripts/kconfig/conf
scripts/kconfig/conf -s arch/i386/Kconfig
***
*** You have not yet configured your kernel!
***
*** Please run some configurator (e.g. "make oldconfig" or
*** "make menuconfig" or "make xconfig").
***
make[2]: *** [silentoldconfig] Error 1
make[1]: *** [silentoldconfig] Error 2
make: *** [include/linux/autoconf.h] Error 2
[root@Neptune linux-2.6.0]#

Ik heb dus al menuconfig gebruikt en heb kernel al gecompiled, ook heb ik .config opgeslagen. Ik heb alleen de output niet in de source laten zetten:
Source is /usr/src/linux-2.6.0
output is /home/raymond/2.6.0/kernel

Ik heb ook al in /home/raymond/2.6.0/kernel 'make bzImage' gegeven krijg zelfde foutmelding! De file .config.linux2.6.0 bestaat wel, deze heb ik in output gegooid (zie boven). Ik heb ook dit geprobeerd; make O=/home/raymond/2.6.0/kernel bzImage, zelfde foutmelding.

[ Voor 9% gewijzigd door Verwijderd op 19-12-2003 12:03 ]

[bolke]

riotrick schreef op 19 december 2003 @ 10:12:
[...]


Het scheelt nogal hoeveel drivers je compileert en op wat voor bak. Om even te vergelijken Mijn Athlon XP 1500+ 512MB doet een kleine 10 minuten over het compilen van een 2.6 kernel. M'n PIII 600MHz 256MB doet over dezelfde kernel een uur of 2. Tja het snelheidsverschil is nou eenmaal erg groot.

Ik dacht dat ik wat fout deed. Maar dat is dus niet zo.
Bedankt voor de info.

[Eärendil]

Verwijderd schreef op 19 december 2003 @ 11:32:
Nu krijg ik dit weer;

[root@Neptune linux-2.6.0]# make bzImage
Makefile:391: .config: No such file or directory
[...]
*** You have not yet configured your kernel!
***
*** Please run some configurator (e.g. "make oldconfig" or
*** "make menuconfig" or "make xconfig").
***
make[2]: *** [silentoldconfig] Error 1
make[1]: *** [silentoldconfig] Error 2
make: *** [include/linux/autoconf.h] Error 2
[root@Neptune linux-2.6.0]#

Ik heb dus al menuconfig gebruikt en heb kernel al gecompiled, ook heb ik .config opgeslagen. Ik heb alleen de output niet in de source laten zetten:
Source is /usr/src/linux-2.6.0
output is /home/raymond/2.6.0/kernel

Ik heb ook al in /home/raymond/2.6.0/kernel 'make bzImage' gegeven krijg zelfde foutmelding! De file .config.linux2.6.0 bestaat wel, deze heb ik in output gegooid (zie boven). Ik heb ook dit geprobeerd; make O=/home/raymond/2.6.0/kernel bzImage, zelfde foutmelding.

Die config file moet .config heten, niets meer en niets minder, die moet je dus even kopieren/renamen.


Even een vraagje: heb je de hele tijd de commando's als root gedaan, of was je bij je vorige pogingen een gewone user.
De 'make O=/home/raymond/2.6.0/kernel' procedure is bedoeld om als gewone user, die geen schrijfrechten heeft in /usr/src/linux/, een kernel te compilen.
Een ander manier om als gewone user een kernel te compilen is de hele source naar je HOME-dir kopieren, en daar dan een 'make *config' en 'make' te doen, daarna moet je als root nog even de module instaleren en de kernel naar /boot kopieren, omdat daar weer schrijfrechten voor nodig zijn

Als je als root een kernel compilet, kan dat direct in /usr/src/linux.

[ Voor 4% gewijzigd door Eärendil op 19-12-2003 13:25 ]

[frim]

ik snap niet waarom je een kernelsource eerst naar /usr/src/ zou verplaatsen voordat je gaat compileren?

[Verwijderd]

mOrPhie schreef op 19 december 2003 @ 11:17:
Alleen heb ik zelf nooit ingezien wat hier makkelijker aan is. Ik compile ook in debian gewoon op de "reguliere" manier en voeg 'm toe aan lilo (of wijzig iets). Wat kun je daar nog makkelijker aan maken. Of anders gezegd: wat is het voordeel van een package gebruiken ten opzichte van "handmatig"?

Package management! Ik heb een keer een stukje geschreven voor de FAQ waarin staat uitgelegd waarom dit zo belangrijk is.

[Eärendil]

frim schreef op 19 december 2003 @ 13:28:
ik snap niet waarom je een kernelsource eerst naar /usr/src/ zou verplaatsen voordat je gaat compileren?

Misschien omdat je distro ze daart neerzet? Als je ze handmatig download kan je ze natuurlijk meteen uitpakken in je home-dir

[ Voor 15% gewijzigd door Eärendil op 19-12-2003 13:59 ]

[Verwijderd]

Eärendil schreef op 19 december 2003 @ 13:57:
[...]
Misschien omdat je distro ze daart neerzet? Als je ze handmatig download kan je ze natuurlijk meteen uitpakken in je home-dir

Nee, zo stond het in voorbeeld in README. ik dacht " Doe ik het ook zo".
Ik zal de file weer ff veranderen naar .config

[ Voor 5% gewijzigd door Verwijderd op 19-12-2003 14:13 ]

[mOrPhie]

Verwijderd schreef op 19 december 2003 @ 13:29:
[...]


Package management! Ik heb een keer een stukje geschreven voor de FAQ waarin staat uitgelegd waarom dit zo belangrijk is.

Ook voor een kernel?

Voor software an sich kan ik daar helemaal in komen. Ook ik ben apt/dpkg-freak. Echter de kernel vind ik dermate exclusief dat ik dit graag handmatig doe. Ach, er valt waarschijnlijk voor beide wat te zeggen.

[usr-local-dick]

Ook voor een kernel?
Voor software an sich kan ik daar helemaal in komen. Ook ik ben apt/dpkg-freak. Echter de kernel vind ik dermate exclusief dat ik dit graag handmatig doe. Ach, er valt waarschijnlijk voor beide wat te zeggen.

Ik vindt het juist wel cool dat de kernel ook helemaal opgezogen is in het package management Soort assimilatie a la Borg
Alleen de laatste paar maanden hebben we een aantal nieuwe servers gekocht waar nogal wat funky hardware in zit die de stock debian kernel niet ondersteunt.
Wat ik nu ga doen is een machine bestempelen als compiler (een van de dual Xeon machines ), daar compile ik 2.4.23 op, helemaal op de debian manier. Dus met de debian patches voor initrd enzo, plus nog een paar patches die we hier nodig hebben. De kernel-deb wordt op alle machines geinstalleerd.
Als er iets aan de hand is wordt 1 keer de kernel opnieuw gecompiled en vervolgens op alle machines geinstalleerd.
Zo heb je redelijk snel alles weer up-to-date en overal hetzelfde.
Het allermooiste is om die compilemachine in te richten als apt-repository en alle andere server die te laten gebruiken. Maar tot die tijd kopieer ik wel een debje.

[Arnout]

Confusion schreef op 19 december 2003 @ 09:51:
[...]

• fakeroot make-kpkg --revision=custom.a.b kernel_image

[...]

Waarom fakeroot? Ik zag dat ook al staan in stappenplan wat ik altijd gebruik, dat je als niet-root moet inloggen en vervolgens fakeroot gebruikt?
Of is het niet netjes om als root te gaan compileren?

[Verwijderd]

Een mijlpaal voor een linux n00b

Ik heb toch maar linux-2.4.23 gecompield (wil op server Debian draaien, this is a test) Ik heb grub.conf aangepast dmv WinSCP. Eerst had ik bij Fedrora 2.4.23 geen initrd geplaatst , daardoor ontstonden de volgende foutmeldingen bij booten:

VFS: cannot open root device "label/" or 00:00
please append a correct "root="boot option
kernel panic : VFS: Unable to mount root fs on 00:00

Later aangepast;

# grub.conf generated by anaconda

default=0
timeout=10
splashimage=(hd0,0)/grub/splash.xpm.gz
title Fedora Core (2.4.22-1.2115.nptl)
root (hd0,0)
kernel /vmlinuz-2.4.22-1.2115.nptl ro root=LABEL=/ hdc=ide-scsi rhgb
initrd /initrd-2.4.22-1.2115.nptl.img

title Fedora Core (2.4.23)
root (hd0,0)
kernel /bzImage ro root=LABEL=/ hdc=ide-scsi rhgb
initrd /initrd-2.4.22-1.2115.nptl.img

Alles wordt dus naar een ramdisk gepleurd , of niet? Ik heb nu namelijk regel van de 2.4.22 kernel letterlijk naar de 2.4.23 gepleurd.

Trouwens ander probleempie;
Ik wil deze 2.4.23 kernel draaien op Debian, kan ik de hpt374-controller bij booten gebruiken ((wil sw-raid) werkt trouwens met Fedora core 1 out of the box). Maar nu is de kernel te groot om een bzdisk te maken, und jetzt?

[Verwijderd]

initrd /initrd-2.4.22-1.2115.nptl.img

Deze regel moet je ook wel aanpassen voor je nieuwe kernel Anders pakt ie nog steeds vrolijk je 2.4.22 kernel

[Spider.007]

Verwijderd schreef op 20 december 2003 @ 12:50:
[...]Maar nu is de kernel te groot om een bzdisk te maken, und jetzt?

Waarom zou deze te groot zijn? Je kunt na het compilen van de kernel het bestand uit

code:

arch/i386/boot/bzImage

kopieren naar /boot en dan in je grub configuratie zetten

offtopic:
CowMike; waarom heb je je icon zo lelijk geresized

[ Voor 9% gewijzigd door Spider.007 op 20-12-2003 13:28 ]

[Verwijderd]

Zoals ik al eerder heb aangegeven, ga ik Debian gebruiken. debian ondersteunt geen hpt374, dus geen hd's, dus geen install.

volgens commando: uname -r draait de 2.4.23. Ik dacht eerst ook dat de "oude" 2.4.22-bla bla zou draaien, maar niet dus, ook geen foutmeldingen ofzo.

[Confusion]

MetHod schreef op 19 december 2003 @ 20:32:
Waarom fakeroot? Ik zag dat ook al staan in stappenplan wat ik altijd gebruik, dat je als niet-root moet inloggen en vervolgens fakeroot gebruikt?
Of is het niet netjes om als root te gaan compileren?

Er zijn, of waren, redenen om een kernel niet als root te compileren. Ik weet niet waarom (ik heb wel een uitleg gezien maar die begreep ik op dat moment nog niet), maar ik vertrouwde de bron voldoende om zijn aanwijzingen op te volgen. Waarschijnlijk maakt het voor het gros van de systemen niet uit.

[ Voor 19% gewijzigd door Confusion op 20-12-2003 14:30 ]

[frim]

Confusion schreef op 19 december 2003 @ 09:51:
Om trouwens nog eens antwoord te geven op het subject van dit topic: in Debian is er de volgende manier om gemakkelijk een kernel package te maken van je eigen kernel

• de packages kernel-package, fakeroot en kernel-source.x.y.z installeren,
• tar xjvf /usr/src/kernel-source.x.y.z.tar.bz2 /usr/local/src/ (niet als root)
• cd /usr/local/src/kernel-source.x.y.z
• make menuconfig
• make-kpkg clean
• fakeroot make-kpkg --revision=custom.a.b kernel_image

en dan vervolgens dpkg -i kernel-image.x.y.z_custom.a.b_i386.deb.

als je dat niet in de src dir doet, maar in vanaf je home dir, krijg je dan een niet werkende package, of maakt het verder weinig uit, ook al is het niet helemaal netjes? anders ga ik nu mijn pc namelijk niet rebooten

[Spider.007]

Confusion schreef op 20 december 2003 @ 14:29:
[...]

Er zijn, of waren, redenen om een kernel niet als root te compileren. Ik weet niet waarom (ik heb wel een uitleg gezien maar die begreep ik op dat moment nog niet), maar ik vertrouwde de bron voldoende om zijn aanwijzingen op te volgen. Waarschijnlijk maakt het voor het gros van de systemen niet uit.

Er zitten gewoon altijd gevaren aan het werken onder de root account. (zoals 'rm -Rf /usr/src/linux /' ipv 'rm -Rf /usr/src/linux/' ) dpkg-buildpackage heeft geen rootrechten nodig; maar controleert wel of je root bent. fakeroot doet voorkomen dat je root bent zonder dat je de eigenlijke rechten hebt. Je kunt dus niets stukmaken; maar wel deps compileren

[lvh]

Als ik probeer iets te doen met make, met uitzondering van make clean, krijg ik erg vaak:

error: '[variable]' undeclared (first use in this function)

Magda?

[Spider.007]

racoontje schreef op 24 december 2003 @ 13:46:
Als ik probeer iets te doen met make, met uitzondering van make clean, krijg ik erg vaak:

error: '[variable]' undeclared (first use in this function)

Magda?

Volgens mij betekent dat niet meer dan dat er een programmeur wat slordig is bezig geweest Dit heeft verder geen negatieve gevolgen voor de make zelf

[lvh]

Spider.007 schreef op 24 december 2003 @ 14:38:
[...]


Volgens mij betekent dat niet meer dan dat er een programmeur wat slordig is bezig geweest Dit heeft verder geen negatieve gevolgen voor de make zelf

Dat dacht ik al. Mijn gezond verstand en beperkte programmeurskennis vertelden me al dat iemand hier nietbestaande variables was aan het gebruiken. Ik wist dat dat alles behalve kosjer was, maar niet of het echt kwaad kon

[lvh]

make modules geeft dit:
The present kernel configuration has modules disabled.
Type 'make config' and enable loadable module support.
Then build a kernel with module support enabled.


Wat ik al allemaal geprobeerd heb voor dit te doen (zelfde resultaat)
make menuconfig
make xconfig
make oldconfig

Geen enkele helpt.

EDIT v2: Note to self. Found use for ball-shape objects in eye sockets. Must remember to use them more.


Ik had module-init-tools niet. Maar, zelfs met die tools, krijg ik bij het proberen van "make menuconfig" het volgende:

code:

scripts/fixdep.c:97:23: sys/types.h: No such file or directory
scripts/fixdep.c:98:22: sys/stat.h: No such file or directory
scripts/fixdep.c:99:22: sys/mman.h: No such file or directory
scripts/fixdep.c:100:20: unistd.h: No such file or directory
scripts/fixdep.c:101:19: fcntl.h: No such file or directory
scripts/fixdep.c:102:20: string.h: No such file or directory
scripts/fixdep.c:103:20: stdlib.h: No such file or directory
scripts/fixdep.c:104:19: stdio.h: No such file or directory
In file included from /usr/lib/gcc-lib/i486-linux/3.3.3/include/syslimits.h:7,
                 from /usr/lib/gcc-lib/i486-linux/3.3.3/include/limits.h:11,
                 from scripts/fixdep.c:105:

[ Voor 162% gewijzigd door lvh op 24-12-2003 17:35 ]

[Verwijderd]

Verwijderd schreef op 10 december 2003 @ 16:23:
Dit is een beetje de centrale reden om het niet te doen. Hoe lief het Aunt Tilly verhaal van onze grote vriend Eric Raymond ook is, de over- over- overgrote meerderheid van de mensen is niet in staat een eigen kernel te compilen, en er is ab-so-luut geen reden om daar verandering in te brengen. De voordelen zijn summier, de nadelen zijn gigantisch. Mensen moeten een gigantische kennis hebben om een eigen kernel te compileren. Voor ons tweakers is dat niet voor te stellen, maar je moet weten wat voor hardware je hebt inclusief (soms) chipnummers en subtypes, soms moet je module opties opgeven, je moet weten welke workarounds en bugfixes je nodig hebt en je moet weten hoe een systeem boot.
Die kennis hebben de distro-makers in overgrote mate. Zij weten alles over kernels en dergelijke. Hun updates zijn vaak goed getest, hun kernels ook, waarom wil je proberen hun werk overnieuw te doen als je er nauwelijks iets mee opschiet?

Ik ben het voor een groot gedeelte met je verhaal eens. Vrijwel niemand kan zo flexibel en zo professioneel een kernel bakken als de makers van gebruikersvriendelijke distro's.
Het feit dat de kernels zo modulair zijn, maakt het vrijwel compleet overbodig ooit aan deze stof te beginnen als normale gebruiker (interesse overwegingen daar gelaten).

Ik zelf draai eigenlijk altijd een kernel die ik zelf gebakken heb. De reden hiervoor: mijn hardware wil dat. (ik boot vanaf ataraid en nu in mijn nieuwe pc vanaf sataraid).
Zoals jij al zegt: dit heeft nadelen. Je komt voor een hele berg keuzes te staan waar je eigelijk geen zak vanaf weet. De werkwijze die ik eigenlijk zou willen volgen maakt echter het verschil tussen zelfbakken en out-of-the-box kernels zeer klein:
* Je installeert de sources naar wens (bijvoorbeeld die van redhat)
* Je gebruikt de .config die de hackers van redhat zelf ook bij hun distro gebruiken.
* Je zet nét dat ene dingetje wat jij in de kernel wil hebben aan wat anders een module is.

Deze wijze volg ik in gentoo. De Gentoo-sources leveren vaak (waarom in godsnaam de laatste releases niet) een kant en klare .config. Met zo'n kernel kom ik eigenlijk nooit situaties tegen waarbij ik moet recompilen vanwege slechte keuzes eerder (ik heb hem immers bijna helemaal laten configureren door experts ).

offtopic:
* De stock kernel heeft geen drivers voor mijn sata raid controller. Ik gebruik een patch hiervoor. Ik moet dus écht zelf aan het bakken bij mijn pc.
* Mijn in gentoo voor de Athlon xp gemaakte kernel draaide op een duron 700 (waarom breiden de kernel hackers van gentoo de Processor type and features hiermee uit? )

Jambek2003 schreef op 16 december 2003 @ 16: 9:
Ik heb een probleempie;
[...]

* Brand een livecdtje van gentoo
* Boot deze cd
* modprobe ataraid htpraid
* mount je partities (/dev/ataraid/discx/party)
* pak stage3 uit op een bruikbare partitie (deze bevat een compiler linker etc. aan het einde van de rit gooi je dit weg en ga je met debian verder)
* chroot naar deze tijdelijke gentoo install (nadat je /boot /dev /proc enzo go d gemount hebt).
* compile een kernel met

code:

[*] HPT36X/37X chipset support
[*] Support for IDE Raid controllers
[*] Highpoint 370 software RAID

* installeer en draai lilo en kijk of je systeem naar wens boot

Tipjes: mount /boot gewoon op een kleine partitie ergens vooraan (ter grootte v n 1 cylinder is vaak genoeg). Altijd handig wanneer je van distro verandert of en upgrade wilt doen. Overschrijf nooit een werkende kernel.

[Verwijderd]

Ik wil ff zeggen dat ik een totale Linux n00b ben, maar ik kan wel NU wel een kernel compileren, het kost wat tijd en hulp. Naar mijn mening is het zeker nuttig om zelf je kernel te compileren, je leert zo veel sneller Linux onder de knie te krijgen.

Ik zal eens kijken wat de beste olossing voor mij is. Ik denk eerst dat ik de hpt374 in de 2.4.23 kernel ga bakken en alle hardware die ik niet in mijn server heb zitten uit de kernel knikker.

[lvh]

racoontje schreef op 24 december 2003 @ 17:21:
make modules geeft dit:
The present kernel configuration has modules disabled.
Type 'make config' and enable loadable module support.
Then build a kernel with module support enabled.


Wat ik al allemaal geprobeerd heb voor dit te doen (zelfde resultaat)
make menuconfig
make xconfig
make oldconfig

Geen enkele helpt.

Ik had module-init-tools niet. Maar, zelfs met die tools, krijg ik bij het proberen van "make menuconfig" het volgende:

code:

scripts/fixdep.c:97:23: sys/types.h: No such file or directory
scripts/fixdep.c:98:22: sys/stat.h: No such file or directory
scripts/fixdep.c:99:22: sys/mman.h: No such file or directory
scripts/fixdep.c:100:20: unistd.h: No such file or directory
scripts/fixdep.c:101:19: fcntl.h: No such file or directory
scripts/fixdep.c:102:20: string.h: No such file or directory
scripts/fixdep.c:103:20: stdlib.h: No such file or directory
scripts/fixdep.c:104:19: stdio.h: No such file or directory
In file included from /usr/lib/gcc-lib/i486-linux/3.3.3/include/syslimits.h:7,
                 from /usr/lib/gcc-lib/i486-linux/3.3.3/include/limits.h:11,
                 from scripts/fixdep.c:105:

Doet het nog altijd niet. Ik ga opnieuw de kernel downloaden, misschien is daar wat misgelopen... Ook alle requirements krijgen nog eens een nakijkbeurt.
EDIT: Doet het nog niet. Ik heb het idee dat die fixdep.c niet echt deugt, terwijl ik nochtans opnieuw gedownload heb. Dingen als stdio.h mogen toch niet ontbreken?
EDIT2: Zou het probleem kunnen liggen bij mijn (te) recente gcc? (3.3.3)

[ Voor 12% gewijzigd door lvh op 02-01-2004 23:06 ]

[pierre-oord]

Ik ben een newbie, maar kernel compileren is echt easy. En die opties zijn echt niet moeilijk ofzo; omg, meestal zelfs overduidelijk. En de opties waarvan je niet weet wat het is, daarvan vraag je toch gewoon ff de help op bij "make menuconfig" ?

Ik ga van de week eens opzoek naar een guide over een kernel compileren voor op flop; ik wil namelijk linux op m'n SATA raid0 config aan de gang helpen. 's kijken of je 2.6.0 op flop krijgt...?

[lvh]

EDIT: Gevonden. libncurses-5 was up-to-date volgens apt, alleen vond de kernel compiler dat minder waar

[ Voor 86% gewijzigd door lvh op 03-01-2004 11:57 ]

[Spider.007]

pierre-oord schreef op 02 januari 2004 @ 23:25:
Ik ben een newbie, maar kernel compileren is echt easy. En die opties zijn echt niet moeilijk ofzo; omg, meestal zelfs overduidelijk. En de opties waarvan je niet weet wat het is, daarvan vraag je toch gewoon ff de help op bij "make menuconfig" ?

Ik ga van de week eens opzoek naar een guide over een kernel compileren voor op flop; ik wil namelijk linux op m'n SATA raid0 config aan de gang helpen. 's kijken of je 2.6.0 op flop krijgt...?

Dan kun je direct de nieuwst pakken; deze schijnt wat problemen op te lossen:

2.6.1-rc1
Changelog
patch vanaf 2.6.0