Compilare e installare il kernel Linux da sorgente su Ubuntu, Fedora e openSUSE

Questa guida spiega come compilare e installare un kernel Linux da sorgente scaricato da kernel.org su Ubuntu, Fedora e openSUSE: scelta della versione, verifica della firma, configurazione, creazione di pacchetti deb e rpm, initramfs, avvio e rimozione. Una release stable non è pensata per introdurre nuove funzionalità: consolida un ramo con correzioni, backport selezionati e miglioramenti di stabilità.

Le fonti ufficiali di riferimento sono il sito kernel.org, la pagina dei rami supportati e il changelog di ogni release pubblicato su cdn.kernel.org:

https://www.kernel.org
https://www.kernel.org/category/releases.html
https://cdn.kernel.org/pub/linux/kernel/v7.x/ChangeLog-7.3.1

Mainline, stable, longterm: quale versione scegliere

Sulla home di kernel.org ogni versione ha un’etichetta. mainline è lo sviluppo di Linus Torvalds (release candidate comprese) e non va usata fuori dai test. stable è l’ultimo ramo rilasciato e riceve correzioni per pochi mesi, finché non esce il ramo successivo. longterm (LTS) indica i rami mantenuti per anni, adatti a server e sistemi che non si aggiornano spesso. Quando un ramo termina la manutenzione, kernel.org lo segna come [EOL]: da quel momento non arrivano più correzioni, comprese quelle di sicurezza.

Prima di iniziare controlla la versione in uso e confrontala con la tabella di kernel.org:

uname -r
# versione che vuoi compilare (esempio: ultima stable al 3/11/2026)
VER=7.3.1

La variabile vale solo nel terminale in cui la definisci: se ne apri uno nuovo per i passaggi successivi (initramfs, verifica, rimozione), ridefiniscila con lo stesso valore.

Principali ambiti di utilizzo

Un kernel upstream recente può essere utilizzato in diversi contesti. Su workstation e notebook può servire per migliorare il supporto a hardware recente, GPU, controller Wi-Fi, NVMe, USB4 o piattaforme laptop di nuova generazione. In ambito server può essere interessante per testare fix relativi a networking, storage, filesystem, virtualizzazione, container e sicurezza.

In ambienti di sviluppo, un kernel upstream consente di verificare se un bug presente nel kernel della distribuzione è già stato corretto nella serie stable. In ambienti embedded o appliance, invece, la compilazione personalizzata permette di ridurre il numero di moduli, limitare la superficie d’attacco, ridurre tempi di boot e includere solo i driver necessari.

È importante distinguere l’utilizzo di un kernel upstream da quello di un kernel fornito dalla distribuzione. Ubuntu, Fedora e openSUSE applicano patch, configurazioni, firme, integrazioni Secure Boot, policy di packaging e test specifici. Installare un kernel vanilla da kernel.org è utile per test, debug e ambienti controllati, ma non sempre è la scelta migliore per sistemi di produzione.

Leggere il changelog: l’esempio di Linux 7.0.11

Il changelog di una release stable va letto prima di ogni aggiornamento. Come esempio prendiamo quello di Linux 7.0.11 (ramo oggi a fine vita): una release di manutenzione ampia, con interventi distribuiti su sicurezza, storage, networking, driver e architetture. Tra i punti più interessanti emergevano correzioni nella gestione RCU del sottosistema keyring, fix per use-after-free nel block layer, interventi su ksmbd, correzioni nello stack di rete GRO con pacchetti zerocopy e aggiustamenti su driver e piattaforme specifiche.

Alcune correzioni sono particolarmente rilevanti perché riguardano condizioni di race, lifetime errato di oggetti kernel, gestione della memoria e percorsi di errore. Questi aspetti sono fondamentali nel kernel: un errore di sincronizzazione o un riferimento a memoria già liberata può tradursi in crash, blocchi del sistema, perdita di dati o potenziali implicazioni di sicurezza.

Per chi compila il kernel manualmente, il changelog va sempre letto prima dell’aggiornamento, soprattutto su macchine che usano driver particolari, filesystem avanzati, SMB server kernel-space, storage zoned, io_uring, dispositivi di rete ad alte prestazioni o piattaforme non x86. Il changelog della versione scelta si trova all’indirizzo https://cdn.kernel.org/pub/linux/kernel/v7.x/ChangeLog- seguito dal numero di versione (per un ramo 6.x la cartella è v6.x).

Prerequisiti generali per la compilazione

Prima di compilare il nuovo kernel è necessario installare toolchain, librerie di sviluppo, utility per la configurazione, strumenti per la generazione dei pacchetti e dipendenze opzionali. È inoltre consigliabile avere spazio libero sufficiente: una build completa può richiedere diversi gigabyte, soprattutto se si generano pacchetti, debug symbols o molte varianti di moduli.

Requisiti consigliati:
- CPU multi-core
- almeno 8 GB di RAM, meglio 16 GB o più
- 20-30 GB liberi per build e pacchetti
- GCC o Clang compatibile
- make, bc, flex, bison, perl, pahole
- librerie ncurses per menuconfig
- openssl e libelf per moduli, firme e BPF
- configurazione di partenza presa dal kernel attualmente in uso

Il sorgente ufficiale può essere scaricato da kernel.org:

VER=7.3.1   # versione scelta su kernel.org
wget https://cdn.kernel.org/pub/linux/kernel/v${VER%%.*}.x/linux-${VER}.tar.xz
wget https://cdn.kernel.org/pub/linux/kernel/v${VER%%.*}.x/linux-${VER}.tar.sign
tar -xf linux-${VER}.tar.xz
cd linux-${VER}

Il file .sign serve a verificare che il sorgente scaricato sia autentico e integro, ma va effettivamente controllato. La firma si riferisce all’archivio .tar non compresso, quindi si decomprime al volo l’archivio .xz e si passa il risultato a GPG, dopo aver importato le chiavi degli sviluppatori che firmano le release (Linus Torvalds e Greg Kroah-Hartman). I comandi vanno eseguiti nella directory in cui sono stati scaricati i file (quindi prima del cd linux-${VER}, oppure dopo un cd ..):

gpg --locate-keys torvalds@kernel.org gregkh@kernel.org
xz -cd linux-${VER}.tar.xz | gpg --verify linux-${VER}.tar.sign -

(su alcune distribuzioni lo stesso programma è disponibile anche con il nome gpg2)

Il risultato deve riportare Good signature; in caso di firma non valida l’archivio non va utilizzato. La procedura è descritta nella pagina ufficiale kernel.org: Linux kernel releases PGP signatures.

Configurazione del kernel

La configurazione è il passaggio più delicato. Il file .config stabilisce quali funzionalità verranno compilate nel kernel, quali saranno moduli e quali saranno escluse. Una scelta errata può produrre un kernel non avviabile, privo del supporto al filesystem root, senza driver storage o incompatibile con Secure Boot.

Una pratica comune consiste nel partire dalla configurazione del kernel attualmente in uso:

cp /boot/config-$(uname -r) .config
make olddefconfig

Il target olddefconfig mantiene le opzioni già presenti e assegna valori predefiniti alle nuove opzioni introdotte dalla versione del kernel. Per una configurazione interattiva si può usare menuconfig:

make menuconfig

Per generare una configurazione più aderente ai moduli effettivamente caricati sul sistema corrente, si può usare localmodconfig. Questo approccio riduce il numero di driver compilati, ma va usato con attenzione: se una periferica non è collegata o un modulo non è caricato al momento della generazione, il relativo supporto potrebbe essere escluso.

make localmodconfig

Parametri da monitorare in fase di compilazione

Durante la compilazione non bisogna limitarsi a verificare che il comando make termini senza errori. È opportuno monitorare risorse, warning, dimensione dei binari, moduli generati, compatibilità della configurazione e impatto sul sistema.

I parametri principali da controllare sono:

CPU:
- utilizzo percentuale durante la build
- temperatura dei core
- eventuale throttling termico
- carico medio del sistema

Memoria:
- RAM disponibile
- uso della swap
- eventuali OOM killer
- consumo nei passaggi di linking

Disco:
- spazio libero nella directory di build
- I/O wait
- velocità di scrittura durante generazione moduli e pacchetti
- spazio in /boot dopo l'installazione

Build:
- numero di job paralleli usati con make -j
- warning del compilatore
- errori trattati come fatali
- moduli non compilati
- dimensione di vmlinux, bzImage e initramfs

Configurazione:
- supporto al filesystem root
- driver storage necessari al boot
- supporto initramfs
- supporto EFI, ACPI e microcode
- opzioni di sicurezza
- compatibilità Secure Boot
- moduli DKMS esterni, ad esempio NVIDIA, VirtualBox, ZFS o driver vendor

Per monitorare il sistema durante la build si possono usare strumenti standard:

htop
watch -n 2 free -h
watch -n 2 df -h
iostat -xz 2
sensors
dmesg -w

Un comando di compilazione tipico utilizza tutti i core disponibili:

make -j$(nproc)

Su sistemi con poca RAM è preferibile ridurre il parallelismo:

make -j4

Per aumentare la verbosità della build o individuare warning aggiuntivi:

make V=1 -j$(nproc)
make W=1 -j$(nproc)

Opzioni di configurazione da valutare con attenzione

Alcune aree del file .config meritano particolare attenzione. Le opzioni relative a CPU, scheduler, filesystem, storage, networking e sicurezza possono modificare sensibilmente comportamento, prestazioni e compatibilità del sistema.

CONFIG_MODULES=y
CONFIG_BLK_DEV_INITRD=y
CONFIG_DEVTMPFS=y
CONFIG_DEVTMPFS_MOUNT=y
CONFIG_EFI=y
CONFIG_EFI_STUB=y
CONFIG_EXT4_FS=y
CONFIG_BTRFS_FS=m
CONFIG_XFS_FS=m
CONFIG_OVERLAY_FS=m
CONFIG_NAMESPACES=y
CONFIG_CGROUPS=y
CONFIG_SECCOMP=y
CONFIG_SECURITY=y
CONFIG_BPF=y
CONFIG_DEBUG_INFO_NONE=y

Per workstation e server moderni è opportuno mantenere il supporto a cgroup, namespace, overlayfs, BPF e seccomp, poiché container, orchestratori, sandbox e strumenti di osservabilità dipendono spesso da queste funzionalità.

Attenzione però al compromesso con CONFIG_DEBUG_INFO_NONE: eliminare le informazioni di debug riduce tempi di compilazione e spazio occupato, ma rende impossibile abilitare CONFIG_DEBUG_INFO_BTF, richiesto da molti strumenti BPF moderni (programmi CO-RE, bpftrace, alcune funzioni di systemd). Se si vuole usare BPF per l’osservabilità conviene quindi impostare le informazioni di debug, ad esempio con CONFIG_DEBUG_INFO_DWARF5=y e CONFIG_DEBUG_INFO_BTF=y (quest’ultima richiede pahole, incluso nel pacchetto dwarves).

Compilazione generica da sorgente

La procedura generica, valida come base per tutte le distribuzioni, consiste nello scaricare il sorgente, importare la configurazione corrente, aggiornare le opzioni e compilare kernel e moduli.

VER=7.3.1   # versione scelta su kernel.org
wget https://cdn.kernel.org/pub/linux/kernel/v${VER%%.*}.x/linux-${VER}.tar.xz
tar -xf linux-${VER}.tar.xz
cd linux-${VER}

cp /boot/config-$(uname -r) .config
make olddefconfig

make -j$(nproc)
sudo make modules_install
sudo make install

Dopo l’installazione è necessario rigenerare la configurazione del bootloader, se la distribuzione non lo fa automaticamente:

sudo update-grub

Oppure, su sistemi che usano grub2-mkconfig:

sudo grub2-mkconfig -o /boot/grub2/grub.cfg

Al riavvio, la versione attiva può essere verificata con:

uname -r

Installazione su Ubuntu

Su Ubuntu è preferibile generare pacchetti .deb invece di usare direttamente make install. In questo modo il kernel risulta gestibile tramite dpkg e può essere rimosso più facilmente.

Installazione delle dipendenze:

sudo apt update
sudo apt install -y build-essential bc bison flex libssl-dev libelf-dev \
  libncurses-dev dwarves pahole wget xz-utils fakeroot rsync

Download e preparazione:

VER=7.3.1   # versione scelta su kernel.org
wget https://cdn.kernel.org/pub/linux/kernel/v${VER%%.*}.x/linux-${VER}.tar.xz
tar -xf linux-${VER}.tar.xz
cd linux-${VER}

cp /boot/config-$(uname -r) .config
scripts/config --disable SYSTEM_TRUSTED_KEYS --disable SYSTEM_REVOCATION_KEYS
make olddefconfig

Il comando scripts/config è necessario con la configurazione di Ubuntu: le opzioni SYSTEM_TRUSTED_KEYS e SYSTEM_REVOCATION_KEYS puntano ai certificati Canonical (debian/canonical-certs.pem), assenti nel sorgente vanilla, e senza questa modifica la compilazione si interrompe.

Creazione dei pacchetti Debian:

make -j$(nproc) bindeb-pkg LOCALVERSION=-mst

I pacchetti verranno creati nella directory superiore:

cd ..
ls -lh *.deb

Installazione:

sudo dpkg -i linux-image-*.deb linux-headers-*.deb

Aggiornamento di GRUB e riavvio:

sudo update-grub
sudo reboot

Verifica:

uname -r

In caso di problemi, dal menu di GRUB è possibile scegliere un kernel precedente. È consigliabile non rimuovere il kernel funzionante della distribuzione finché il nuovo kernel non è stato testato con storage, rete, grafica, sospensione, container e moduli DKMS.

Installazione su openSUSE

Su openSUSE è possibile compilare un kernel vanilla e generare pacchetti RPM. Anche in questo caso è preferibile produrre pacchetti gestibili dal package manager invece di installare manualmente file sparsi nel sistema.

Installazione delle dipendenze:

sudo zypper refresh
sudo zypper install -y gcc make bc bison flex libopenssl-devel libelf-devel \
  ncurses-devel dwarves rpm-build wget xz rsync cpio

Download e configurazione:

VER=7.3.1   # versione scelta su kernel.org
wget https://cdn.kernel.org/pub/linux/kernel/v${VER%%.*}.x/linux-${VER}.tar.xz
tar -xf linux-${VER}.tar.xz
cd linux-${VER}

cp /boot/config-$(uname -r) .config
make olddefconfig

Creazione di pacchetti RPM generici:

make -j$(nproc) binrpm-pkg LOCALVERSION=-mst

I pacchetti generati si trovano normalmente sotto ~/rpmbuild/RPMS/:

find ~/rpmbuild/RPMS -name "*.rpm" -type f

Installazione con zypper:

sudo zypper install $(ls ~/rpmbuild/RPMS/x86_64/kernel-*.rpm | grep -v headers)

Il pacchetto kernel-headers generato da binrpm-pkg viene escluso perché sostituirebbe quello della distribuzione, usato dalla libreria C per compilare i programmi.

Aggiornamento del bootloader:

sudo grub2-mkconfig -o /boot/grub2/grub.cfg
sudo reboot

Verifica:

uname -r

Su openSUSE con Secure Boot attivo, un kernel compilato manualmente potrebbe non essere avviabile senza firma corretta. In ambienti di test si può disabilitare temporaneamente Secure Boot dal firmware, mentre in ambienti controllati è preferibile firmare kernel e moduli secondo la policy aziendale.

Attenzione: disabilitare Secure Boot riduce la protezione del sistema contro bootloader e moduli kernel non autorizzati, e su sistemi in produzione o con disco cifrato legato al TPM può avere conseguenze sulla sicurezza e sullo sblocco del disco. L’alternativa che mantiene attivo Secure Boot è usare una propria chiave MOK (Machine Owner Key): si genera una coppia di chiavi, la si registra con mokutil (la registrazione va confermata al riavvio successivo nella schermata blu di MokManager) e con quella chiave si firmano l’immagine del kernel (ad esempio con sbsign) e i moduli (con lo script scripts/sign-file presente nei sorgenti del kernel).

sudo mokutil --import MOK.der
sudo mokutil --list-new

Lo stesso vale per Fedora e Ubuntu con Secure Boot attivo.

Installazione su Fedora

Fedora aggiorna frequentemente il kernel e dispone di un’integrazione molto curata con RPM, dracut, grubby, Secure Boot e moduli. Per testare un kernel upstream si può comunque compilare il sorgente vanilla e generare pacchetti RPM.

Installazione delle dipendenze:

sudo dnf install -y gcc make bc bison flex openssl-devel elfutils-libelf-devel \
  ncurses-devel dwarves rpm-build wget xz perl rsync cpio

Download e configurazione:

VER=7.3.1   # versione scelta su kernel.org
wget https://cdn.kernel.org/pub/linux/kernel/v${VER%%.*}.x/linux-${VER}.tar.xz
tar -xf linux-${VER}.tar.xz
cd linux-${VER}

cp /boot/config-$(uname -r) .config
make olddefconfig

Compilazione in pacchetti RPM:

make -j$(nproc) binrpm-pkg LOCALVERSION=-mst

Installazione:

sudo dnf install $(ls ~/rpmbuild/RPMS/x86_64/kernel-*.rpm | grep -v headers)

Come su openSUSE, il pacchetto kernel-headers generato viene escluso per non sostituire quello della distribuzione.

Rigenerazione initramfs, se necessario:

sudo dracut --force --kver ${VER}-mst

Verifica delle voci di boot:

sudo grubby --info=ALL | less

Riavvio e controllo della versione:

sudo reboot
uname -r

Su Fedora, Secure Boot e moduli esterni meritano attenzione. Driver proprietari o moduli DKMS potrebbero dover essere ricompilati per la nuova versione. Se il sistema usa NVIDIA, VirtualBox, VMware, ZFS o altri moduli fuori albero, è necessario verificare la compatibilità prima di usare il nuovo kernel come predefinito.

Gestione di initramfs e bootloader

L’initramfs contiene driver e strumenti necessari nelle prime fasi del boot. Se il driver del controller storage, del filesystem root o della cifratura disco non è integrato direttamente nel kernel, deve essere disponibile nell’initramfs. Un errore in questa fase può impedire il montaggio del filesystem root.

Su Ubuntu l’initramfs viene normalmente gestito da update-initramfs; i pacchetti .deb lo creano già durante l’installazione, quindi è sufficiente aggiornarlo solo se necessario:

sudo update-initramfs -u -k ${VER}-mst
sudo update-grub

Su Fedora e openSUSE è comune l’uso di dracut:

sudo dracut --force --kver ${VER}-mst

Prima di riavviare è utile controllare che i file siano presenti in /boot:

ls -lh /boot | grep "$VER"

Verifiche post-installazione

Dopo il primo avvio con il nuovo kernel, è consigliabile eseguire una serie di controlli. L’obiettivo è verificare che il kernel sia effettivamente attivo, che i moduli siano caricati correttamente e che non emergano errori critici nei log.

uname -a
lsmod | head
dmesg -T | less
journalctl -k -b
systemctl --failed
df -h
ip a
lsblk
findmnt /

Per un sistema desktop vanno testati grafica, audio, Wi-Fi, Bluetooth, sospensione, ripresa dalla sospensione e periferiche USB. Per un server vanno verificati storage, rete, firewall, container, virtualizzazione, monitoraggio, backup e servizi critici.

Problemi comuni

Un kernel compilato manualmente può non avviarsi per assenza di driver storage, initramfs incompleto, configurazione EFI errata, moduli non installati, Secure Boot non compatibile o problemi con driver esterni. Per questo motivo è fondamentale mantenere installato almeno un kernel precedente funzionante.

Problema: kernel non compare in GRUB
Controllare:
- presenza di vmlinuz in /boot
- presenza di initramfs
- aggiornamento grub
- configurazione Boot Loader Specification su Fedora

Problema: kernel panic al boot
Controllare:
- driver del controller storage
- supporto filesystem root
- initramfs
- UUID del filesystem root
- command line del kernel

Problema: rete non funzionante
Controllare:
- modulo della scheda di rete
- firmware installato
- dmesg
- NetworkManager o systemd-networkd

Problema: driver NVIDIA o moduli DKMS non caricati
Controllare:
- headers installati
- compatibilità del driver
- ricompilazione DKMS
- firma dei moduli con Secure Boot

Rimozione del kernel compilato

Se il kernel è stato installato tramite pacchetti, la rimozione è più semplice e pulita.

Su Ubuntu:

dpkg -l | grep linux | grep "$VER"
sudo apt remove "linux-image-*${VER}*" "linux-headers-*${VER}*"
sudo update-grub

Su Fedora:

rpm -qa | grep kernel | grep "$VER"
sudo dnf remove "kernel*${VER}*"

Su openSUSE:

rpm -qa | grep kernel | grep "$VER"
sudo zypper remove "kernel*${VER}*"
sudo grub2-mkconfig -o /boot/grub2/grub.cfg

Quando conviene compilare un kernel upstream

Un kernel upstream è indicato quando si desidera testare l’ultimo ramo stable, verificare bug corretti rispetto alla versione della distribuzione, validare hardware recente o preparare ambienti di sviluppo kernel. È anche utile per amministratori e sviluppatori che vogliono confrontare il comportamento di un sistema con il kernel vanilla rispetto al kernel patchato dal vendor.

Un ramo stable smette di ricevere correzioni, comprese quelle di sicurezza, quando termina la sua manutenzione: prima di usarlo verifica su kernel.org che il ramo non sia segnato [EOL] e, per sistemi di produzione, preferisci il kernel della distribuzione o un ramo LTS. Ricorda che un kernel compilato a mano non si aggiorna da solo: quando esce una nuova release del ramo devi ripetere la procedura con il nuovo valore di VER. Non è invece consigliabile sostituire il kernel della distribuzione in produzione senza una fase di test. I kernel distribuiti da Ubuntu, Fedora e openSUSE includono integrazioni, patch e processi QA specifici. Un kernel upstream può risolvere un problema, ma può anche introdurre differenze operative rispetto al kernel ufficiale della distribuzione.