View Full Version : Il primo kernel non si scorda mai...
...e vai!!! Ho compilato il mio primo kernel da quando sono passato a Debian (circa un anno) :winner:
Il sistema è partito al primo colpo senza colpo ferire e adesso il mio PC è attrezzato con la 3.5.2 Vanilla con solo 2 dubbi:
- Come faccio ad installare gli headers della 3.5.2 dal momento che non è possibile installarli con apt-get?
- Il risultato della compilazione ha comportato un initrd di oltre 100 Mb :mc: , dove ho toppato?
Per la cronaca queste sono i passi che ho seguito:
1) Download dei sorgenti da kernel.org
2) scompattazione dei sorgenti in una directory di lavoro (~/work) e copia del precedente .config nella directory.
3) make oldconfig
4) make bzImage
5) make modules
6) make modules_install
7) make install.
Thanks!
kernelex
23-08-2012, 19:36
edit
pabloski
23-08-2012, 22:00
ma in quel precedente .config include tutti i moduli possibili ed immaginabili? :D
seriamente non riesco a trovare altra spiegazione ai 100 mb dell'initramfs
ovviamente è possibilissimo che l'initramfs sia stata creata male, aggiungendo una marea di driver che non servono, ficcando dentro libc invece di klibc e magari tirandosi dietro mezzo userland gnu
questo però indica che il file di configurazione dell'initramfs non è mica fatto tanto bene :D
Ho preso in prestito per la compilazione il config dell'attuale wheezy, dici che se prima faccio un make mrproper e subito dopo un make defconfig dovrei riuscire a eliminare la maggior parte dei drivers inutili?
pabloski
23-08-2012, 22:11
Ho preso in prestito per la compilazione il config dell'attuale wheezy, dici che se prima faccio un make mrproper e subito dopo un make defconfig dovrei riuscire a eliminare la maggior parte dei drivers inutili?
Il config di debian dovrebbe essere meglio di quello della configurazione standard. Il problema dell'initramfs si trova nella fase successiva, cioè quando viene costruita l'initramfs.
Decomprimi l'initramfs e vedi che c'è dentro. Probabilmente si sarà tirato dietro un mucchio di eseguibili e librerie inutili.
letto?
http://guide.debianizzati.org/index.php/Debian_Kernel_Howto
letto?
http://guide.debianizzati.org/index.php/Debian_Kernel_Howto
Corro! Anche se si riferisce ad una versione arcaica del kernel....
Gimli[2BV!2B]
24-08-2012, 13:32
versione arcaica del kernel....:eek: non dire così che mi sento vecchio!
Comunque vedo che la guida è tenuta aggiornata, citando anche le novità post 3.0.
L'initrd credo potrebbe risultare più longilineo se creato a là Debian (non so bene cosa si inventino i sorgenti del kernel quando hanno le mani libere).
Comunque valuta se ti serve davvero l'initrd, come spiegato nella guida che ti hanno già riportato.
Gimli[2BV!2B]
24-08-2012, 14:28
Le opzioni basilari che consiglierei per provare a spremere qualche goccia di efficienza (sono miste x86+amd64 e dipendenti da altre voci, quindi non tutte potrebbero essere visibili):
General setup --->
[ ] Optimize for size
Optimize very unlikely/likely branches
Processor type and features --->
[ ] Support for extended (non-PC) x86 platforms
Single-depth WCHAN output
Processor family (SCEGLIERE LA FAMIGLIA CORRETTA) --->
[ ] Generic x86 support
[ ] Numa Memory Allocation and Scheduler Support
Kernel hacking --->
[ ] Compile the kernel with frame pointers
Allow gcc to uninline functions marked 'inline'Se, come il sottoscritto, si hanno ancora macchine con un solo core, ricordarsi di togliere di mezzo il SMP:
Processor type and features --->
[ ] Symmetric multi-processing supportA questo aggiungerei di controllare tutto ciò che ha debug nel nome o nella descrizione: nel 99% dei casi si può disattivare, attivando poi singole voci se necessario debuggare specifici problemi (personalmente mi capita molto raramente).
Il traguardo che si persegue solitamente è di lasciare attivo solo ed esclusivamente ciò che si utilizza o si ha intenzione di provare, cioè praticamente una frazione minima di ciò che è attivo in un kernel Debian generico.
Per finire cito nuovamente lo scheduler BFS (http://en.wikipedia.org/wiki/Brain_Fuck_Scheduler) di Con Kolivas (http://ck-hack.blogspot.it/), di cui sono un appassionato utilizzatore.
Grazie per gli ottimi e preziosi consigli; cercando un pò in giro ho trovato questo (http://how-to.wikia.com/wiki/How_to_configure_the_Linux_kernel) eccellente tutorial che, al prezzo di un'annetto di studi, copre quasi ogni aspetto della consigurazione del kernel. Se non altro adesso c'è un minimo di spiegazione su cosa vogliano dire le singole voci.
Per quanto riguarda l'initrd, stò seriamente pensando di abolirlo. Compilo come builtin il supporto ai vari filesystem e ai controller SATA/ICH e ciò mi dovrebbe permettere di montare in fase di boot la root e avviare il tutto..
Gimli[2BV!2B]
24-08-2012, 15:12
Per vedere i driver delle periferiche PCI in uso usa lspci -k, l'lspci liscio è scomodo.
La prima parte della guida che riporti mi sembra dia informazioni utili, però i dettagli successivi mi sembra siano semplicemente le voci di help di una vecchia versione del kernel riportate in HTML.
Immagino tu sappia che ogni voce ha una descrizione che è spesso sufficiente per capire a cosa serva.
Altra cosa molto utile è la funzione di ricerca, che con menuconfig si apre premendo il tasto / (non ti so dire come funzioni nelle altre modalità).
In particolare nella ricerca sono esplicitate posizione e dipendenze di ogni voce, vale a dire ciò che occorre avere abilitato/disabilitato per averla a disposizione (o per disattivarla).
Per far fuori l'initrd non scordare:
Device Drivers --->
SCSI device support --->
<*> SCSI disk support
Asynchronous SCSI scanning
Azz, dopo 2 giorni sono ancora alla voce "General Setup" :muro: mi confermate che ci vuole un mese per poter configurare un kernel per la compilazione? :mc:
Gimli[2BV!2B]
25-08-2012, 10:15
Dipende quanto ti vuoi concentrare sulle singole voci.
Alla prima configurazione di una nuova macchina il tempo più lungo lo passo in "Device Drivers".
Quando si tratta di aggiornare o controllare una cosa faccio una revisione delle impostazioni.
In ogni caso il kernel è compilabile e solitamente funzionante in tutte le iterazioni, quindi ogni volta che raggiungo l'obiettivo che mi sono preposto mi fermo fino a che non nasce una nuova necessità.
Per coloro che sono preda della disperazione suggerisco che a questo link (http://massimo.solira.org/pcikl/) è disponibile il language pack, completo delle istruzioni di installazione che traduce la quasi totalità delle opzioni di configurazioni di makeconfig e delle sue controparti grafiche.
Post Scriptum: ma qualcuno è mai riuscito a compilarsi un kernel partendo da un .config pulito e non già preparato? A me sembra che una roba del genere sia un impresa titanica...
battery_charge
02-10-2012, 15:18
infatti non devi compilarlo cosi'.... la compilazione del kernel si fa, perche' ti servono nuovi driver, o patch, oppure per snellirlo, per esempio che te ne fai dei moduli di 100 schede eternet ? scegli solo il driver per la tua scheda, e via dicendo, puoi potresti togliere il console buffer, scegliere se vuoi moduli o driver statici (i moduli li carichi solo alla bisogna per esempio quando colleghi una usb)
conta che un kernel ricompilato puo' anche arrivare a stare in un floppy
se non ricordo male ai tempi di slackware i mie i kernel erano 3 mega
battery_charge
02-10-2012, 15:24
Per coloro che sono preda della disperazione suggerisco che a questo link (http://massimo.solira.org/pcikl/) è disponibile il language pack, completo delle istruzioni di installazione che traduce la quasi totalità delle opzioni di configurazioni di makeconfig e delle sue controparti grafiche.
Post Scriptum: ma qualcuno è mai riuscito a compilarsi un kernel partendo da un .config pulito e non già preparato? A me sembra che una roba del genere sia un impresa titanica...
cosa intendi preparato? senza flag ecc? penso che di default sia cosi', pero' e' generico, io ho dicimao fatto tutto da 0, nel senso che disabilitavo tutto quello che non mi serviva minuziosamente voce per voce
scusate se mi intruflo in questo post ma essendo niubbo e visto che San Google non mi ha aiutato... volevo chiedervi una cosa velocissima: perché compilare un kernel? a che serve?
compili un kernel su misura per il tuo computer in modo tale che possa dare il massimo in termini di prestazione? se avessi un pentium 2 e ricompilassi il kernel potrei farlo girare "decentemente"?
scusate ancora per l'intrusione :stordita:
Gimli[2BV!2B]
03-10-2012, 00:02
Si può fare su misura alla macchina: questo permette solitamente di risparmiare un po' di memoria, magari ridurre il tempo di boot di una frazione di tempo apprezzabile senza misurazioni.
Applicando qualche patch ed esasperando qualche configurazione si può rendere il sistema un po' più reattivo.
Certamente non si possono fare miracoli.
Fino a qualche mese fa utilizzavo un Athlon XP ed un Pentium IV dotati di un kernel ritagliato sulle macchine e patchato Con Kolivas (http://ck-hack.blogspot.it/): a sensazione le svecchiava di un paio di anni almeno.
Un Pentium II con RAM di dimensioni dell'ordine delle centinaia di mega può funzionare bene solo con software suo contemporaneo o con distribuzioni moderne leggere. I principali vantaggi si avrebbero scegliendo con cura tutto il software tra le alternative più leggere: un kernel sarebbe giusto la ciliegina sulla torta.
Il problema principale è la poca RAM, il secondo le capacità della CPU, che finisce in ginocchio non appena si prova ad usare un sito con del Flash... (colpa della CPU o di Flash? Anche Javascript se complesso...)
battery_charge
03-10-2012, 08:17
;38226317']Si può fare su misura alla macchina: questo permette solitamente di risparmiare un po' di memoria, magari ridurre il tempo di boot di una frazione di tempo apprezzabile senza misurazioni.
Applicando qualche patch ed esasperando qualche configurazione si può rendere il sistema un po' più reattivo.
Certamente non si possono fare miracoli.
Fino a qualche mese fa utilizzavo un Athlon XP ed un Pentium IV dotati di un kernel ritagliato sulle macchine e patchato Con Kolivas (http://ck-hack.blogspot.it/): a sensazione le svecchiava di un paio di anni almeno.
Un Pentium II con RAM di dimensioni dell'ordine delle centinaia di mega può funzionare bene solo con software suo contemporaneo o con distribuzioni moderne leggere. I principali vantaggi si avrebbero scegliendo con cura tutto il software tra le alternative più leggere: un kernel sarebbe giusto la ciliegina sulla torta.
Il problema principale è la poca RAM, il secondo le capacità della CPU, che finisce in ginocchio non appena si prova ad usare un sito con del Flash... (colpa della CPU o di Flash? Anche Javascript se complesso...)
tutto corretto
già flash questo maledetto, infatti se fai questa scelta devi scordarti flash e grafica ultra 3d ecc, vai di openbox, come browser opterei per links o dillo eccc devi fare molte rinunce, in ambito desktop userei almeno un p4
slackware e' adatta per macchine vecchie
Non sò se è in tema, ma eventualmente utilizzare i kernel del ramo trunk-experimental di Debian, è molto rischioso?
Io ho provato a compilare un kernel ma sono comparsi diversi errori dopo aver macinato 6,8GB di dati, ed ho proceduto all'installazione di uno già precompilato (sebbene di un ramo alternativo).
Tutto sembra andare bene da circa una settimana... ho dovuto solo installare l'AMD64-microcode.
Vostre esperienze in merito?
bye
tutto corretto
già flash questo maledetto, infatti se fai questa scelta devi scordarti flash e grafica ultra 3d ecc, vai di openbox, come browser opterei per links o dillo eccc devi fare molte rinunce, in ambito desktop userei almeno un p4
slackware e' adatta per macchine vecchie
diciamo che la mia era più curiosità che altro :)
quindi per sistemare una macchina, se pur vecchia, la prima cosa da fare è la scelta del software e solo in seguito la compilazione del kernel?
Grazie mille per le risposte :)
vBulletin® v3.6.4, Copyright ©2000-2025, Jelsoft Enterprises Ltd.