[ottimizzazione kernel] su ubuntu

[neorob]

Secondo voi, quali sono le "voci" essenziali da spuntare per la ricompilazione del kernel tenendo conto che:
- il kernel sia il più piccolo e leggero possibile (magari con un boot fulminante!)
- l'unica espansione dell'hardware è rappresentata da chiavette usb e dischi fissi esterni usb autoalimentati
- abbia il necessario per collegarsi ad internet solo per navigare e al più usare programmi p2p e di messaggistica istantanea
- si possa riprodurre dvd, divx e musica (raramente però)
- legga le partizioni fat, fat32, ntfs (le principali insomma!)

Chiedo questo perchè ho un secondo computer che vorrei fosse il più performante possibile, e prima di fare un kernel panic chiedo a voi!

La configurazione è:

MB: asus cusl2-c
CPU: P3 1 Ghz
RAM: 256+64+64 MB (totale 384)
GPU: nvidia fx5200 128MB
SCSI: adaptec AHA-2940U/2940UW (a cui attaccata ci sono due HDD!)
SPU: CMI8738 PCI
LAN: RTL 8139B

è da intendere che non sono molto esperto in materia... per la prima volta (ehm... seconda, ma la prima non è andata a buon fine... ) tento di ricompilare un kernel...

[valeriocd]

se vai sul sito di ubuntu nella sezione wiki ci sono tutti i passi d compiere per ricompilareil kernel
poi nel seguente link ti posto un esempio di configurazione , giusto per farti un'idea
http://guide.debianizzati.org/index....razione_kernel

[Gimli[2BV!2B]]

Ti consiglio anche di tenere d'occhio quest'altra buona guida di Debianizzati: fornisce una buona panoramica dell'intero processo di compilazione.

In particolare questo punto, e i due successivi, illustrano un punto cruciale per ottenere un kernel funzionante.

[neorob]

grazie dell'aiuto!
seguendo i link ho compilato il kernel senza quello che non interessava il mio hw, però al momento magico.... KERNEL PANIC!! (ehhh va bè, sbagliando si impara!)

in pratica quando lo avvio viene fuori:

kernel panic - not syncing: vfs: unable to mount root fs on unknown-block(0,0)

che da quanto capito è un problema di initrd.img (giusto??)
se cosi fosse ho sbagliato a selezionare qualche voce nel kernel? eppure da quanto capito per evitare l'uso del initrd devo compilare staticamente il supporto al file system e dei miei dischi scsi, cosa che mi sembra di avere fatto...

la versione su cui sto lavorando è la 2.6.22 con patch di Con Kolivas.

suggerimenti?

[Gimli[2BV!2B]]

Mi sembra di capire che hai optato per l'eliminazione dell'initrd (scelta che condivido).
Questo è il classico errore a cui ci si trova davanti se non si integra il modulo del filesystem della radice (/), oppure il driver del controller IDE/SATA che deve essere integrato per permettere di montare la / senza initrd.
In alcuni casi si tratta anche di opzioni accessorie, come il supporto per partizioni MS-DOS segnalato nel link che ho postato.
Mi raccomando devi INTEGRARE i moduli indispensabili, non solo selezionarli: io sono abituato alla sola configurazione ncurses (testuale pseudografica in console a sfondo blu, per intenderci) in cui una cosa è integrata quando indicata con *, mentre è compilata come semplice modulo se indicata con una M.

Una considerazione finale: perché il 2.6.22 Con Kolivas-ato?
Considero la 2.6.24 una versione davvero ben riuscita, ha il suo bel scheduler maturo derivato dal Con Kolivas, una buona quantità di novità, un'ottima retrocompatibilità, e, nelle ultime patch, c'è anche quella abbastanza importante per un problemino che ha fatto scalpore (solo in assenza di SElinux).

[neorob]

Originariamente inviato da Gimli[2BV!2B]

Mi sembra di capire che hai optato per l'eliminazione dell'initrd (scelta che condivido).
Questo è il classico errore a cui ci si trova davanti se non si integra il modulo del filesystem della radice (/), oppure il driver del controller IDE/SATA che deve essere integrato per permettere di montare la / senza initrd.
In alcuni casi si tratta anche di opzioni accessorie, come il supporto per partizioni MS-DOS segnalato nel link che ho postato.
Mi raccomando devi INTEGRARE i moduli indispensabili, non solo selezionarli: io sono abituato alla sola configurazione ncurses (testuale pseudografica in console a sfondo blu, per intenderci) in cui una cosa è integrata quando indicata con *, mentre è compilata come semplice modulo se indicata con una M.

Una considerazione finale: perché il 2.6.22 Con Kolivas-ato?
Considero la 2.6.24 una versione davvero ben riuscita, ha il suo bel scheduler maturo derivato dal Con Kolivas, una buona quantità di novità, un'ottima retrocompatibilità, e, nelle ultime patch, c'è anche quella abbastanza importante per un problemino che ha fatto scalpore (solo in assenza di SElinux).

ma devo attivare per forza l'opzione driver del controller IDE/SATA anche se ho due dischi scsi e nessuno ide/sata?

per quanto riguarda il kernel la versione 2.6.24 ha praticamente integrato la patch Con Kolivan ed esente dal bug che ha fatto scalpore?

[Gimli[2BV!2B]]

Ah, beh, mi hai spiazzato!

Francamente non ho mai avuto molto a che fare con lo SCSI, ma dovrebbe trattarsi sempre e solo di integrare il driver del controller SCSI corretto.

Dando un'occhiata veloce mi è saltato all'occhio questo:

"SCSI disk support" che è fuori dal menù dei driver specifici "SCSI low-level drivers" (tutto in "Device Drivers"->"SCSI device support", naturalmente).

Occorre integrare anche questo componente per ottenere un kernel funzionante con root su SCSI (Do not compile this driver as a module if your root file system (the one containing the directory /) is located on a SCSI disk).
Se hai correttamente integrato questo modulo allora prova a leggiucchiare anche le altre voci o cerca informazioni specifiche (io non ho avuto fortuna, prova magari con il modello del controller).

Passando al kernel 2.6.24 c'è lo scheduler di derivazione Kolivas di Ingo Molnar, in quanto a fairness è nettamente migliore del vecchio scheduler, non so dirti con certezza se garantisce lo stesso grado di real-time del Kolivas, ma ti posso assicurare che, ad esempio, i programmi audio emulati con Wine che un tempo erano inusabili senza strumenti appositi (jackd) ora funzionano molto bene.

Per quanto riguarda il baco è stato patchato, se non ricordo male, dalla revisione 2 (ma se provi il 24 prendi l'ultima 2.6.24.4 e non ci sono problemi).

[neorob]

Originariamente inviato da Gimli[2BV!2B]

Ah, beh, mi hai spiazzato!

Francamente non ho mai avuto molto a che fare con lo SCSI, ma dovrebbe trattarsi sempre e solo di integrare il driver del controller SCSI corretto.

Dando un'occhiata veloce mi è saltato all'occhio questo:

"SCSI disk support" che è fuori dal menù dei driver specifici "SCSI low-level drivers" (tutto in "Device Drivers"->"SCSI device support", naturalmente).

Occorre integrare anche questo componente per ottenere un kernel funzionante con root su SCSI (Do not compile this driver as a module if your root file system (the one containing the directory /) is located on a SCSI disk).
Se hai correttamente integrato questo modulo allora prova a leggiucchiare anche le altre voci o cerca informazioni specifiche (io non ho avuto fortuna, prova magari con il modello del controller).

Passando al kernel 2.6.24 c'è lo scheduler di derivazione Kolivas di Ingo Molnar, in quanto a fairness è nettamente migliore del vecchio scheduler, non so dirti con certezza se garantisce lo stesso grado di real-time del Kolivas, ma ti posso assicurare che, ad esempio, i programmi audio emulati con Wine che un tempo erano inusabili senza strumenti appositi (jackd) ora funzionano molto bene.

Per quanto riguarda il baco è stato patchato, se non ricordo male, dalla revisione 2 (ma se provi il 24 prendi l'ultima 2.6.24.4 e non ci sono problemi).

ihih! in effetti mi diverto a sbattere la testa su cose poco standard..!!

comunque oggi ho provato a ricompilare il kernel mettendo supporto nativo anche ai fs della ms (ho letto in giro che qualcuno aveva risolto cosi) e dando un'occhiata alle voci che mi hai consigliato (che avevo già selezionato in modo nativo).... solito errore.
Appena ho un altro po' di tempo provo a riconfigurare il tutto usando il nuovo kernel (cosi magari mi saltano all'occhio voci che avevo trascurato).

un'altra cosa.. come faccio ad eliminare completamente traccia del kernel che non funziona?? devo modificare sicuramente qualche file di config di grub e poi? che file elimino? chiedo questo perchè se devo continuamente compilare kernel che poi non fungono, mi ritrovo la lista di avvio di grub stra piena!!

[Gimli[2BV!2B]]

Purtroppo non ho altre idee per moduli/opzioni mancanti...

Per quanto riguarda la disinstallazione:

• se hai creato i pacchetti con il metodo Debian è sufficiente "purgarli" via (dpkg -P linux-image-VERSIONE, ma puoi anche usare Synaptic o Adept);
  
• se invece hai installato il tutto in modo classico, cioè con:
  make install
  make install-modules
  dovrai cancellare manualmente i file relativi al kernel che vuoi rimuovere dalle cartelle:
  /boot/
  /lib/modules/
  Dopodiché un update-grub dovrebbe aggiornare il /boot/grub/menu.lst con le sole voci rimaste valide.
  Occhio a rimuovere solo i file relativi ai kernel che non sono stati installati da dei deb (o a quello attivo!).

[neorob]

ancora non sono riuscito a capire cosa non funziona... ho provato quindi a compilare il kernel con attivato l'initrd e parte. Ha qualche problema con il riconoscimento della rete, ma per il resto sembra funzionare. Però non mi è sembrato di guadagnare questa velocità al caricamento... mah... continuerò a smanettarci e vedere se riesco ad ottimizzare tutto per bene!

[Gimli[2BV!2B]]

L'ho scritto, non molto tempo fa, a qualcun altro: in distribuzioni nate per il desktop non si ottengono rivoluzioni, mentre, ad esempio, in Debian (che ha politiche molto più conservatrici/standard) si ottengono miglioramenti tangibili.

Le opzioni potenzialmente più utili per questo obiettivo sono:
se selezionate, disattivare

• General setup->Optimize for size (Look out for broken compilers!) (questa opzione è controproducente se il processore non ha una cache dell'ordine di grandezza di 1MB)
• Processor type and features->Generic x86 support (solo se il processore è presente nell'elenco Processor family)

assicurarsi invece di aver selezionato/correttamente impostato

• Processor type and features->Single-depth WCHAN output
• Processor type and features->Processor family
• Processor type and features->Preemption Model [se si cerca un sistema molto scattante scegliere "Low-Latency Desktop"]
• Processor type and features->Preempt The Big Kernel Lock
• Processor type and features->Timer frequency [1000 HZ dovrebbe essere la scelta migliore]

Queste credo siano le impostazioni più importanti, che dovrebbero garantire l'ottenimento di un sistema il più scattante possibile.

[Gimli[2BV!2B]]

Ah, poi al momento non l'ho pensato: se hai ottenuto un kernel funzionante (ed hai già ristretto un po' l'insieme dei driver integrando qualcosina) controlla lsmod con maggiore attenzione.
Integra i driver sufficientemente stabili che trovi nell'elenco, soprattutto quelli eventualmente contraddistinti con [permanent] (tra quelli dovrebbe trovarsi il responsabile del panic).

[neorob]

grazie 1000 dei consigli! alla fine nn sono ancora riuscito a capire cosa ho dimenticato di farli compilare per farlo funzionare senza initrd :-(
cmq visto che la velocità di caricamento non varia molto, penso di tenermi il kernel "standard" poichè dovrei ricompilare alcuni moduli tipo ndiswrapper, e quindi pernso sia più il tempo perso che i reali vantaggi. mi conviene aspettare qualche giorno e aggiornare ad ubuntu 8.04!
però prima o poi riuscirò a capire cosa non va! così poi posso provare gentoo!