Sto pistolando su un kernel per l’e3pc (così, per provare il nuovo 2.6.30).
Fra me è Sua Maestà il K non c’è ancora quello che definirei un ottimo rapporto, ma suppongo che alla lunga impareremo a conoscerci (o meglio, IO, umile padawan, troverò un modo per farmi capire a S.M.).

Ci sono un sacco di guide sul web, e come sempre tirare le somme in maniera organica non è banale.
Una lista di comandi come segue SENZA spiegato che significa non ha senso (imho).

make clean
$ make dep
$ make bzImage
$ make modules
# make modules_install

Una scaletta un po’ più seria (ma sicuramente da perfezionare):
* prendete il kernel nuovo (kernel.org)

* mettete sotto /usr/src/ e scompattate

* il kernel viene “partorito” da una compilazione con # make. Make si appoggia ad un Makefile che si appoggia a sua volta ad un file testuale di configurazione (.config nella dir dove ci stanno i sorgenti).

* Si può cambiare qualche aspetto importante andando a modificare le variabili dentro il Makefile (quelle in stampatello all’inizio). Per esempio:

VERSION = 2
PATCHLEVEL = 6
SUBLEVEL = 29
EXTRAVERSION = .1
NAME = Temporary Tasmanian Devil

Modificare EXTRAVERSION può risultare molto utile, poichè in /lib/modules/ vengono caricati i moduli necessari al kernel all’avvio, e la stringa che forma la dir concatena anche quel parametro (insomma, si possono tenere separati i vari moduli di versione in versione).

* L’operazione di configurazione del kernel è fondamentale, e io la realizzo con un comando: $ make menuconfig
NOTA: Io uso menu config perchè mi è comodo e usa le solite interfacce coloratine da terminale figlie di ncurses. Ovviamente esistono altre opzioni: dal più testuale config, ai grafici xconfig e gconfig (mai usati, ma sono certo siano esteticamente validi e ugualmente efficaci). Se si vuole caricare una configurazione vecchia (ie: esiste già un .config precedentemente redatto) si puo’ usare il comando $ make oldconfig.
NOTA2: Ci sono anche alcune opzioni per creare file .config con caratteristiche standard: $ make allnoconfig, $make allyesconfig, ecc. Per ulteriori info, leggere il README.

* Dopo aver create il .config, con $ make si compila il kernel vero e proprio (che comparirà magicamente sotto arch/x86/boot/bzImage .
ATTENZIONE: basta scrivere $ make per ottenere ciò che in molte guide e’ indicato come $ make dep, $ make bzImage, $ make modules. Insomma, il tutto si è evoluto, e non c’è più necessità di indicare che è necessario compilare le dipendenze (dep), l’immagine (bzImage, big compressed image) e i moduli; make già sa, e basta e avanza.
NOTA: Se si vuole avere più output con make, si può dare il comando $ make V=1 (o 2).

* Se si è configurato il kernel in maniera monolitica (cioè all-in-one), si deve spostare il tutto sotto /boot e via. Nel caso si siano indicati dei moduli, bisogna compilarli. il comando è # make modules_install e, come si evince facilmente, installa i moduli del kernel nel filesystem (sotto /lib/modules/linux-2.x.x.EXTRAVERSION-XXXX).

* Si potrebbe dare anche $ make install per installare il kernel compilato nel posto giusto, ma io non mi fido e lo copio a mano (ie: # cp /usr/src/linux-2.xx.xx/arch/x86/boot/bzImage /boot/kernel-2.xx.xx).
NOTA: $ make install si basa su /sbin/installkernel che viene lanciato da arch/x86/boot/install.sh coi parametri estrapolati dallo script.

system.map è una mappa di simboli utile al kernel che viene caricata all’avvio, ma non necessaria.

* Nel caso le cose vadano storte (e ci andranno, of course), è necessario ripulire i sorgenti appena compilati e tornare alla situazione iniziale. Soluzione stupida: cancellare tutto e scompattare l’archivio. Soluzione migliore: usare i comandi di make. Come si legge nel Makefile:

# Cleaning is done on three levels.
# make clean     Delete most generated files
#                Leave enough to build external modules
# make mrproper  Delete the current configuration, and all generated files
# make distclean Remove editor backup files, patch leftover files and the like

Di solito sono sufficienti i primi due: se si vuole tenere la configurazione, si lancia $ make clean; se si vuole cancellare tutto $ make mrproper.

In qualunque caso, ci vengono in aiuto il file README, il Makefile (si puo’ leggere, davvero!) e $ make help (le info di cosa puo’ fare il makefile, che forse è meglio che leggere il codice del Makefile. ).
Esiste anche la dir Documentation/ che tiene tante di quelle info da uscirne scoppiati (cominciare dal file HOWTO).

Visto che ultimamente ho smandruppato con slackware m’è toccato guardare un po’ LILO (LInux LOader). Preferisco GRUB, ma vabbè.
Dunque, lilo è l’altro (il primo) bootloader. A differenza di grub che si legge il file di configurazione menu.lst e questo gli basta, lilo necessita di un file di configurazione /etc/lilo.conf (che è molto semplice ed intuitivo da capire) e di una compilazione per essere a posto.
La compilazione la si ottiene dando il comando # lilo. Se si vuole fare un test (imho fondamentale), meglio postporre al comando il flag -t. Il flag -v aumenta la verbosità, ovviamente.

Un link da esplorare: kernel niubbi.

Robba (vecchia) da leggere:
Configurare, compilare e installare un kernel 2.6 per (open)SUSE Linux di Thomas Hertweck (2006)
KernelAnalysis-HOWTO di Roberto Arcomano (2003)
The Linux Installation HOWTO di Eric Steven Raymond (2002)

Ho messo su neon una Slackware (12.2, il 27/8 è uscita la 13).
Ho aggiornato il kernel alla versione 2.6.30, e questa è la mia attuale configurazione (ancora da limare, ma c’è un sacco della roba che conta) – boota in pochi secondi.

Sistemate le rotte (# route add default gw ip_gateway eth0) lynx si è collegato senza problemi a google e al blog, e mi sono ascoltato un mp3 con mpg321 (lol) senza problemi (ho dovuto comunque installarmi la libreria libid3tag.so che m’era sfuggita).

Anche se è tutto molto rude, mi sento assai a mio agio.
Vedremo come procede.

(Intanto mi linko un sito che sull’e3pc si è sbattuto un casino – come distro ha scelto ubuntu)

PS: L’installazione della slack è stata assai liscia: si prepara una chiavetta per il boot e un’altra dove si mette tutta la distro. Quando si arriva all’indicazione del source dei pacchetti, si installa la chiavetta e si fa puntare lì il setup, ed il gioco è fatto.

L’immagine per la chiavetta di boot la si puo’ trovare sul sito slack sotto slackware-current/usb-and-pxe-installers. (Il readme dice una cosa importante: The mini image does not contain any installable Slackware package. In order to install Slackware you will need a local NFS/HTTP/FTP server or another Slackware package source like a prepared local harddisk partition.).

idrogeno:~# dd if=/home/sim/distro/slack/usbboot.img.1 of=/dev/sdc bs=512
54480+0 records in
54480+0 records out
27893760 bytes (28 MB) copied, 9.14268 s, 3.1 MB/s

Dopo aver ricompilato il kernel di H avevo qualche problema a far girare iptables come volevo.

Essenzialmente Sua Maestà il K non mi prendeva la (fondamentale) riga che gestisce le connessioni già attive.

$IPT -A INPUT -i eth0 -m state --state RELATED,ESTABLISHED -j ACCEPT

Poiché il firewall è in effetti gestito a livello di kernel, e l’errore era su uno stato specifico (-m state) era chiaro che m’ero dimenticato di includere un modulo… sic.

La prossima volta, meglio ricordarsi di inserire lo state match support sotto Core Netfilter Configuration (CONFIG_NETFILTER_XT_MATCH_STATE).
More »

Dopo qualche casino col kernel e moduli vari, la scheda eth della mobo di kripton si è incasinata e m’è toccato passare alla Realtek (sempre due schede eth in tasca, sempre!) che non mi delude mai.

Ma è bello avere TUTTO l’hardware funzionante sulla propria box. Quindi solita ricerca a partire da:

kripton:~# lspci -nn | grep Eth
00:07.0 Bridge [0680]: nVidia Corporation MCP61 Ethernet [10de:03ef] (rev a2)
01:09.0 Ethernet controller [0200]: Realtek Semiconductor Co., Ltd. RTL-8139/8139C/8139C+ [10ec:8139] (rev 10)

10de:03ef devices – nForce 430 (MCP61) Ethernet [ASUSTeK Computer Inc]
Ok, i moduli ci sono, dovrebbe fungere tutto. Che cavolo ha sta mobo maledetta? O_o

In /etc/udev/rules.d/70-persistent-net.rules c’e’ l’associazione fra la scheda e il suo mac address che la individua. E qui vedo la stranezza: due identificazioni per la stessa scheda eth (quella della mobo con chipset nVidia)… mmm.
Commento le righe che mi sembrano spaiate e scrivo il mac address giusto nella eth0.
[NdSim: Avevo già parlato di quel file tempo addietro. Maledetto.]

Rendo buone queste modifiche con

# /etc/init.d/udev restart

Abbatto il modulo che gestisce la scheda eth (forcedeth, e c’e’ scritto anche nel file 70-persistent-net.rules) con modprobe -r forcedeth, e poi lo rimetto up (modprobe forcedeth).

Infine con un bell’ifconfig -a. posso constatare che è tutto tornato in ordine: eth0 e 1 sono up. Mittico.
Anche questa impagliacciata è stata risolta.