Questa guida copre un’installazione avanzata e production-ready di Fedora 44, ottimizzata per workstation enterprise (Dell Precision con Intel Core Ultra) con supporto team per GPU NVIDIA e AMD. L’obiettivo è un sistema con rollback atomici, crittografia completa del disco, snapshot automatici e accelerazione hardware configurata correttamente.
Fedora supporta nativamente il Secure Boot — tienilo disabilitato durante l’installazione e dopo averla installata tienilo sempre abilitato. Per i driver proprietari (NVIDIA), l’enrollment dei MOK keys avviene automaticamente al primo riavvio dopo l’installazione del driver.
Consenti i certificati di terze parti (Fondamentale):
Nel BIOS del tuo Dell o Thinkpad, cerca un’opzione chiamata “Microsoft UEFI CA” o “3rd Party UEFI CA” (di solito si trova sotto le impostazioni del Secure Boot o della sezione sicurezza). Assicurati che sia abilitata.
Questa opzione dice al BIOS di accettare le firme Linux approvate (MOK), non solo quelle di Windows. Senza di essa, i driver firmati come akmod-nvidia o fedora non verranno caricati anche se il MOK enrollment va a buon fine.
Partizionamento (Anaconda Web UI → Cockpit Storage)#
Usa il Cockpit Storage editor (menu a tre punti nella pagina storage) per il partizionamento custom.
Partizioni standard:
Partizione
Dimensione
Filesystem
Azione
/boot/efi
600MB
FAT32
Solo assegnare mount point
/boot
2.15GB
Ext4
Creare partizione e assegnare mount point
vuoto (mounts nei subvolumes)
Rimanente
LUKS2 → Btrfs
Creare senza nome e senza mount point
LUKS2: seleziona lo spazio libero, crea una partizione cifrata (LUKS2) e imposta la passphrase.
Subvolumi Btrfs (dentro LUKS) — da creare durante l’install:
Clicca sulla partizione btrfs e clicca sul top level volume e poi sui 3 puntini crea sottovolume.
Soluzione base:
root montato su / — il sistema operativo
home montato su /home — i dati utente
Soluzione avanzata (ogni subvolume non viene snapshottato con root):
Subvolume
Mount Point
Scopo
root
/
Il sistema operativo
home
/home
I dati utente
log
/var/log
Persistenza log durante i rollback
cache
/var/cache
Cache rigenerabile — tiene gli snapshot leggeri
tmp
/var/tmp
File temporanei persistenti
libvirt
/var/lib/libvirt
Immagini VM
podman
/var/lib/containers
Container Podman rootful (servizi di sistema)
docker
/var/lib/docker
Container Docker
containers_user
~/.local/share/containers
Container Podman rootless (nested sotto home, esclusi dagli snapshot di /home)
# sudo chattr +C /var/lib/containers # Optional if podman is rootfull
4
# sudo chattr +C /var/lib/docker # Optional if docker is present
WARNING
Database voluminosi in container: se esegui PostgreSQL, MySQL, MongoDB o simili con volumi di dati significativi, applica NOCOW sulla directory del volume prima di avviare il container per la prima volta — le scritture random continue causano frammentazione severa su Btrfs senza di esso:
Terminal window
1
sudochattr+C/percorso/del/volume/db
Auto-Unlock con TPM2 (nessuna passphrase al boot)#
Dopo l’installazione puoi enrollare la chiave LUKS2 nel chip TPM2 della macchina: il disco si sblocca automaticamente finché il sistema è integro (stessa CPU, stesso firmware, nessuna manomissione). La passphrase manuale rimane come fallback.
Prerequisiti: Secure Boot abilitato e TPM2 presente (verificabile con ls /dev/tpm*).
PCR 0 — misura il firmware UEFI (rileva modifiche al BIOS)
PCR 7 — misura lo stato del Secure Boot (rileva se viene disabilitato)
Ti verrà chiesta la passphrase LUKS esistente per autorizzare l’enrollment.
4. Rigenera l’initramfs:
Terminal window
1
sudodracut--force
Riavvia: il sistema si sbloccherà automaticamente senza chiedere la passphrase. Se il TPM rileva una modifica al firmware o al Secure Boot, tornerà a chiedere la passphrase manuale.
WARNING
Dopo ogni aggiornamento BIOS: le misurazioni PCR cambiano. Esegui di nuovo systemd-cryptenroll con --wipe-slot=tpm2 prima di aggiornare, oppure il sistema si bloccherà al riavvio successivo.
Nel tab Snapper Settings, imposta i limiti di retention per evitare che il disco si riempia (es. 5, 7, 2, 0, 0, 10). Verifica che i timer snapper-timeline e snapper-cleanup siano Attivi.
3. Primo Avvio: Firmware, Repository & Aggiornamenti#
Usa un nome che identifichi la macchina fisica, non l’OS (es. precision-7680, tower-5090) — l’hostname dovrebbe restare valido anche dopo un reinstall o cambio distro.
Driver xe per Intel Core Ultra e successivi: il nuovo driver KMS Intel xe sostituisce i915 per le GPU integrate/discrete recenti (Meteor Lake, Lunar Lake, Arrow Lake, Panther Lake, Arc, Battlemage). Su Lunar Lake/Battlemage è già il default. Su Meteor Lake (Core Ultra Serie 1)i915 è ancora il driver di fabbrica ma puoi forzare xe per avere stack grafico più moderno, Vulkan migliore e compute Xe più maturo.
Verifica il driver attivo:
Terminal window
1
lspci-k|grep-EA3'VGA|3D'# cerca "Kernel driver in use: i915" o "xe"
Forzare xe via kernel parameter (trova il PCI-ID con lspci -nn | grep -i vga, es. [8086:7d55]):
Secure Boot rimane abilitato — i MOK keys vengono enrolled automaticamente al primo riavvio. Attendi 5 minuti prima di riavviare per la compilazione del modulo akmods.
RAM Optimization: il comando seguente impedisce a GNOME Software di consumare memoria in background, ma disabilita il controllo automatico degli aggiornamenti.
Setup di Podman compatibile con docker CLI e docker compose.
WARNING
Se in futuro installi Docker CE (moby-engine o docker-ce): si scontra con podman-docker su /usr/bin/docker — disinstalla uno dei due. Ricorda anche di fare unset DOCKER_HOST (o gestirlo per-progetto con direnv) quando vuoi parlare col daemon Docker invece che col socket Podman.
Installazione pacchetti.podman è preinstallato; podman-docker fornisce /usr/bin/docker come wrapper; docker-compose è la v2 upstream che parla con il socket Podman.
Terminal window
1
sudodnfinstallpodmanpodman-dockerdocker-compose
Abilita il socket Podman e configura DOCKER_HOST — rootless, user-level. È ciò che permette a docker compose di parlare con Podman.
Terminal window
1
# Abilita e avvia il socket
2
systemctl--userenable--nowpodman.socket
3
systemctl--userstatuspodman.socket# verifica
4
5
# Esporta DOCKER_HOST in shell config (~/.zshrc, o ~/.bashrc se usi bash)
Avvio automatico al boot (lingering). In modalità rootless, i servizi utente vengono terminati al logout e non vengono avviati al boot se nessuno ha effettuato login. Per permettere a podman.socket e ai container con --restart=always (o restart: always in Compose) di partire automaticamente all’accensione del PC, abilita il lingering sul tuo utente:
Senza enable-linger il socket Podman non è raggiungibile finché non fai login, e i container con restart policy non ripartono al boot.
NOTE
Quadlet (opzionale): per servizi di sistema con dipendenze complesse, considera Quadlet (~/.config/containers/systemd/*.container) — definisce i container come unit systemd native, più pulito di podman generate systemd (deprecato).
Test multi-container con Compose. Crea un file di prova con due servizi (nginx + redis):
A questo punto hai un sistema Fedora 44 stabile, sicuro e pronto per lo sviluppo. I passi successivi dipendono dal tuo ruolo/uso, ma tipicamente coprono:
Abilita poi l’impronta da Impostazioni → Utenti → Impronta digitale.
NOTE
Il COPR supporta sia gli ID 5842-5845 (installa libfprint-2-tod1-broadcom) sia i più nuovi 5864-5867 con -cv3plus (sperimentale). Verifica il tuo chip con lsusb | grep -i broadcom.