Commenti a "Tecniche avanzate con Ubuntu: compilare un kernel "vanilla""

[The Doctor]

Tecniche avanzate con Ubuntu: compilare un kernel "vanilla" - Commenti

Compilare un kernel "vanilla" ci consente di adattarlo all'hardware del nostro PC, rendendo il sistema più veloce e stabile, nonché risolvere eventuali bug e problemi di compatibilità con alcune periferiche. Vediamo come. [continua...]

[Al3x]

Complimenti per l'articolo mi hai invogliato provare

[The Doctor]

Complimenti per l'articolo mi hai invogliato provare

se incontri difficoltà fammi sapere.

[farbix89]

Che dire

Personalmente già compilavo,ma questo articolo è così ben fatto da invogliare chiunque a compilare

[vraptus]

Personalmente penso che compilare il kernel non abbia più l'utilità di qualche anno fa, specie se si lavora su macchine recenti, ma è una cosa che prima o poi chiunque dovrebbe fare.
Grande Doctor!!!

[GiovanniT]

Mi ricordo le compilazioni su opensuse... che nostalgia.
Comunque, io ho sempre rimosso molti più moduli di questi.
Tu hai notato maggiore reattività del sistema?

PS: bell'articolo

[ninjabionico]

Bell'articolo, il metodo funziona sulle derivate di Debian fra cui Ubuntu fruttando il gestore dei pacchetti per installare e rimuovere facilmente il kernel.

Mi viene un dubbio però leggendo la tua guida...
... gli ultimi passaggi...
... l'uso dell'opzione --initrd dovrebbe già creare il file initrd.img-{versione} e in fase d'installazione l'aggiornamento della configurazione di Grub dovrebbe tenerne conto...


Ho compilato e installato diverse volte il kernel, anche col metodo manuale che funziona su qualsiasi distro ma non sfrutta il gestore dei pacchetti e ti tocca ritoccare la configurazione del boot-manager, il mio consiglio è di rimuovere molto di più dopo aver preso confidenza con la compilazione.

Come?

Per ottenere informazioni utili per la configurazione del kernel io utilizzo i comandi:

Codice: Seleziona tutto

lsusb
lspci
lspcmcia

{L'ultimo è utile solo per i portatili}

Questi comandi forniscono un output minimale rispetto a lshw ma contiene ugualmente le sigle dei chip utilizzati nelle schede, fondamentali per sapere con precisione quali sono i driver da abilitare o meno, perché difficilmente troverete come riferimento il nome del costruttore e il modello della scheda fra le voci del kernel (infatti molti produttori di hardware utilizzano i medesimi chip che vengono così supportati da un unico driver).


Cosa abilitare e cosa no (oltre a quanto correttamente specificato nella guida):

- tutti i supporti ai chipset inutilizzati, se abbiamo una scheda madre con chipset Intel potremmo rimuovere i moduli per i chipset Amd, Via, Nvidia, Sis e Uli per esempio, rimuovendo anche eventuali moduli per le famiglie di chipset Intel di cui non fa parte la nostra scheda madre (perché obsoleti, usati nei server o troppo recenti) e selezionando come statico il modulo del nostro specifico chipset e lasciando come moduli quelli generici

- rimuovere i supporti ai controller Scsi/Sata che non possediamo, lasciando invece abilitati (meglio se statici) quelli generici che vengono utilizzati per supporti usb e unità sata/pata visto che per semplificare la gestione sono stati portati tutti nella catena Scsi

- abilitare in modo statico il supporto ai controller dei dischi del chipset e integrati extra nella scheda madre

- rimuovere il supporto a schede di rete PCI/ISA/PCMCIA non installate, inutile avere i driver per le schede per fibra ottica o delle obsolete 10 Mbit quando oggi sono tutte 100/1000 Mbit quelle integrate nelle schede madri, consiglio invece di lasciare come moduli quelli per le schede USB (soprattutto le WiFi)

- disabilitare il supporto all'ISDN se non ce l'avete (come probabile)

- come sopra è valido lo stesso discorso per le schede audio, abilitare ALSA e disabilitare OSS, abilitare in ALSA l'emulazione OSS se abbiamo alcuni vecchi programmi ne fanno uso (per retro-compatibilità, il 99% dei programmi recenti ormai utilizzano ALSA e non più OSS), disabilitare i moduli di tutte le schede audio PCI (è il bus più frequentemente usato per integrarle nelle schede madri, anche se di recente si è cominciato a utilizzare anche quello USB) eccetto quello della nostra scheda e lasciando abilitati come moduli quelli delle schede USB (che non si sà mai)

- disabilitare il supporto alle schede d'acquisizione video PCI che non possedete, lasciando invece quello delle schede USB (potrebbe sempre capitarvene una fra le mani)

- abilitare in modo statico il supporto ai filesystem che utilizzate per le vostre partizioni di sistema (es Ext3/4, ReiserFs, ecc...), questo permetterà insieme al supporto statico dei controller pata/sata l'avvio del sistema anche in assenza del file initrd.img-{versione kernel} (se l'uso del suddetto file non è utilizzato in fase di avvio si guadagna qualche secondo), lasciate come moduli quelli presenti sul disco ma non utilizzati direttamente da GNU/Linux come Iso9660 (cd-rom) , VFAT e NTFS, disabilitando gli altri inutilizzati (es. ReiserFs, JFs, XFs, ecc...)


I suggerimenti sopra sono abbastanza generici, le voci di configurazione sono moltissime, alcune vengono visualizzate o nascoste in base a quelle che sono abilitate, ulteriori ottimizzazioni sono ancora possibili (sensori interni, contatori e watchdog, protocolli di rete, moduli di espansione delle funzionalità del firewall NetFilter, ecc...) ma è opportuno procedere per gradi e tentativi finché non si è raggiunto un grado di personalizzazione/ottimizzazione accettabile.

[The Doctor]

Grazie ninja, i tuoi suggerimenti sono preziosi come sempre

[tesivo]

Salve a tutti. Innanzi tutto un complimenti a The Doctor per la guida, è davvero ben fatta. Ci sono però dei problemi dovuti probabilmente al fatto che la guida non era per la versione attuale del kernel: 3.5.2


Vado in ordine:
Nel paragrafo "Alcune impostazioni consigliate":
"Export task/process statistics through netlink" (EXPERIMENTAL) non è del tutto de-selezionabile
lo stesso per un'altra che ora non ricordo più qual'era

poi non vi è più "1GB Low Memory Support" ma sembra che ora anche 1Gb sia in "Off".

Infine vi è il vero problema:
Fallisce la compilazione del kernel con questo output:

Codice: Seleziona tutto

  LD [M]  lib/raid6/raid6_pq.o
  CC [M]  lib/reed_solomon/reed_solomon.o
  CC [M]  lib/xz/xz_dec_test.o
  CC [M]  lib/zlib_deflate/deflate.o
  CC [M]  lib/zlib_deflate/deftree.o
  CC [M]  lib/zlib_deflate/deflate_syms.o
  LD [M]  lib/zlib_deflate/zlib_deflate.o
  Building modules, stage 2.
  MODPOST 3440 modules
ERROR: "__modver_version_show" [drivers/staging/rts5139/rts5139.ko] undefined!
WARNING: modpost: Found 12 section mismatch(es).
To see full details build your kernel with:
'make CONFIG_DEBUG_SECTION_MISMATCH=y'
make[2]: *** [__modpost] Errore 1
make[1]: *** [modules] Errore 2
make[1]: uscita dalla directory "/usr/src/linux-3.5.2"
make: *** [debian/stamp/build/kernel] Errore 2

Come posso risolvere?

[tesivo]

risolto in questo modo: sed -i s/CONFIG_RTS5139=m/CONFIG_RTS5139=n/ .config

poi ho compilato da root dando questa opzione: make CONFIG_DEBUG_SECTION_MISMATCH=y

[tesivo]

aggiungo un'ultima cosa: questa parte era già fatta in automatico:

Infine apriamo il file di configurazione di GRUB con sudo gedit /boot/grub/grub.cfg, scorriamo il file fino a trovare la configurazione che riguarda l'avvio di Ubuntu, ovvero ### BEGIN /etc/grub.d/10_linux ###, ed aggiungiamo al codice del nuovo kernel installato la riga initrd /boot/initrd.img-2.6.34.

Per il resto tutto perfetto, kernel perfettamente aggiornato e mi ha persino sistemato i problemi della mia scheda tv xD

[zenith]

Ottimo, grazie per aver condiviso la tua soluzione con noi