Quando SysLinuxOS non arriva più al menu di avvio, non sempre è necessario reinstallare il sistema. Se il problema riguarda GRUB e l’installazione sul disco è ancora integra, SysLinuxOS Boot Repair permette di esaminare il sistema dalla Live, rigenerare la configurazione del menu oppure reinstallare il bootloader attraverso un’interfaccia grafica.
Questa guida descrive SysLinuxOS Boot Repair 0.3.1 per amd64, disponibile nel repository APT SysLinuxOS Tools. Il funzionamento della versione 0.3.0 è stato verificato da SysLinuxOS Live; la 0.3.1 aggiunge l’integrazione nel menu SysLinuxOS Tools, mantenendo invariati helper di riparazione e interfaccia grafica.
Quando usare SysLinuxOS Boot Repair
Lo strumento può essere utile quando GRUB non compare, il computer entra nella console di GRUB, il menu non riflette più la configurazione del sistema oppure il bootloader deve essere reinstallato dopo un intervento sui dischi. Questi sintomi possono però avere cause diverse: prima di scrivere sul disco conviene verificare quale installazione è presente e quale operazione serve.
Boot Repair si occupa del recupero di GRUB su un’installazione SysLinuxOS esistente. Non ripara guasti hardware o filesystem danneggiati, non reinstalla il sistema operativo e non recupera partizioni cancellate. Se il disco mostra errori di lettura o dati mancanti, la priorità è mettere al sicuro i dati e diagnosticare lo storage.
Configurazioni supportate
| Componente | Supporto nella versione 0.3.1 |
|---|---|
| Sistema da riparare | Installazione SysLinuxOS riconoscibile e con configurazione di montaggio coerente |
| Architettura | amd64; reinstallazione GRUB per BIOS oppure UEFI a 64 bit |
| Filesystem root | Btrfs con subvolume root @, ext4 oppure XFS |
| Cifratura | Root direttamente dentro una partizione LUKS, con filesystem supportato |
| Partizioni di avvio separate | /boot e partizione EFI individuate dal file /etc/fstab del sistema installato |
| Mount già esistenti | Riutilizzati tramite mount privati, senza smontare quelli aperti dall’utente |
| Layout fuori ambito | LVM dentro LUKS, RAID, UEFI a 32 bit, layout di mount non standard e altre distribuzioni richiedono recupero manuale |
La presenza di una partizione nell’elenco non garantisce che sia riparabile. L’analisi deve confermare che il dispositivo contenga SysLinuxOS, che la root corrisponda a fstab e che il layout sia supportato.
1. Avviare la Live nella modalità corretta
Preparare una USB SysLinuxOS Live e avviare il computer da quel supporto. La riparazione va eseguita dalla Live, non dal sistema installato da riparare. Prima di procedere è opportuno avere un backup aggiornato dei dati importanti e riconoscere chiaramente i dischi collegati.
La modalità firmware della Live deve corrispondere a quella dell’installazione. Per reinstallare GRUB UEFI occorre una Live avviata in UEFI a 64 bit, con le variabili EFI accessibili. Una Live avviata in modalità Legacy non permette di registrare correttamente la relativa voce UEFI.
Dal terminale della Live, questo controllo indica se la sessione corrente è UEFI oppure BIOS/Legacy:
if [ -d /sys/firmware/efi ]; then
echo "Live avviata in UEFI"
cat /sys/firmware/efi/fw_platform_size
else
echo "Live avviata in BIOS/Legacy"
fi
In UEFI il valore atteso per questa utility è 64. Il controllo descrive la Live in esecuzione, non determina da solo la modalità dell’installazione sul disco. Se occorre, riavviare e scegliere nel menu del firmware la voce corretta della USB.
2. Installare Boot Repair dalla Live
Con il repository SysLinuxOS Tools già configurato e una connessione di rete disponibile:
sudo apt update sudo apt install syslinuxos-boot-repair
Se il repository non è presente nella Live utilizzata, seguire le istruzioni del repository ufficiale SysLinuxOS Tools. Per configurarlo con lo script ufficiale e poi installare il pacchetto:
curl -fsSL https://fconidi.github.io/SysLinuxOS-Tools/client/install-repo.sh -o /tmp/syslinuxos-install-repo.sh less /tmp/syslinuxos-install-repo.sh sudo bash /tmp/syslinuxos-install-repo.sh sudo apt update sudo apt install syslinuxos-boot-repair
Il repository usa la suite tirreno, componente main, architettura amd64 e indici firmati GPG. Per controllare la versione installata e quella candidata:
apt policy syslinuxos-boot-repair
La versione descritta qui è la 0.3.1; se il repository propone una versione successiva, consultare anche il relativo changelog. Sulle Live senza persistenza, l’installazione del pacchetto nella sessione corrente normalmente non resta disponibile dopo il riavvio.
Installazione da un pacchetto locale
È possibile copiare sulla Live il pacchetto e installarlo dalla directory in cui è stato salvato:
sudo apt install ./syslinuxos-boot-repair_0.3.1_amd64.deb
Il file .deb da solo non include tutte le dipendenze. Se mancano nella Live e non è disponibile una rete, occorre procurarle prima. L’installazione di Boot Repair avviene nell’ambiente Live; la successiva riparazione opera sul sistema selezionato sul disco.
3. Aprire l’interfaccia e identificare la root
Aprire il menu SysLinuxOS Tools e scegliere Boot Repair. Con la lingua italiana il collegamento può apparire come Ripara avvio SysLinuxOS. In alternativa:
syslinuxos-boot-repair-launcher
La GUI viene eseguita come utente del desktop. Le operazioni che richiedono privilegi passano attraverso l’helper amministrativo; la Live normalmente dispone di sudo senza password, altrimenti può comparire una richiesta di autenticazione.
L’elenco mostra dispositivo, dimensione, filesystem, etichetta, disco, stato e punti di montaggio. Per confrontare i dispositivi dal terminale:
lsblk -o NAME,SIZE,FSTYPE,LABEL,UUID,MOUNTPOINTS
Selezionare la partizione root del SysLinuxOS installato: non la USB Live, non @home e non la partizione EFI. Con Btrfs l’utility cerca la root nel subvolume @. In presenza di più installazioni, verificare con particolare attenzione il sistema e i dispositivi mostrati nel piano.
4. Scegliere l’operazione
| Operazione | Effetto | Quando valutarla |
|---|---|---|
| Solo analisi / Inspect only | Esamina la root e i dispositivi di avvio in sola lettura; non esegue riparazioni | Primo controllo per identificare correttamente l’installazione |
| Rigenera menu di avvio / Regenerate the boot menu | Esegue update-grub nel sistema installato |
GRUB è presente, ma occorre ricreare la configurazione del menu |
| Reinstalla GRUB e rigenera il menu / Reinstall GRUB and regenerate the boot menu | Esegue grub-install e poi update-grub nel sistema installato |
Occorre reinstallare il bootloader oltre a ricreare il menu |
La scelta iniziale è Solo analisi. È un buon punto di partenza anche quando si pensa già di dover reinstallare GRUB: permette di controllare il sistema prima di scegliere un’operazione che scrive sul disco.
5. Controllare il piano e confermare
Premere Controlla il piano (Review plan). L’helper ispeziona in sola lettura l’installazione selezionata e riporta root, eventuale /boot separata, modalità di avvio e partizione EFI. Con una root cifrata, mostra anche il mapper decifrato e il contenitore LUKS corrispondente.
In BIOS, la destinazione della reinstallazione è il disco intero che contiene la root selezionata: per esempio /dev/sda, non /dev/sda2. Il dispositivo effettivo deve essere controllato nel piano, soprattutto quando sono collegati più dischi.
In UEFI, la partizione EFI viene ricavata da /etc/fstab del sistema installato. Non occorre scegliere a caso una partizione FAT: verificare quella individuata e la disponibilità della modalità UEFI nella Live.
Per le operazioni di riparazione, solo dopo questa verifica premere Conferma riparazione (Confirm repair). Annulla è il pulsante predefinito. L’analisi semplice non propone la conferma di una riparazione. L’helper ricontrolla i dispositivi prima dell’esecuzione.
Attendere il risultato e leggere la sezione Dettagli. Prima delle operazioni di riparazione, l’eventuale grub.cfg esistente viene copiato in un file grub.cfg.syslinuxos-backup.* nella stessa directory. Questo backup riguarda la configurazione GRUB: non è un’immagine del disco o un backup completo del sistema.
Root cifrate LUKS e partizioni già montate
Le partizioni LUKS rimangono visibili sia quando sono bloccate sia quando sono già sbloccate. Selezionando un contenitore bloccato, la GUI consente di inserire la passphrase nella finestra di sblocco. Lo sblocco usa UDisks2 e può richiedere anche l’autenticazione amministrativa. La passphrase non viene passata negli argomenti dei comandi né salvata su disco.
Se la root è già sbloccata o montata, può essere selezionata direttamente quando il layout è supportato. Boot Repair usa mount privati e, alla fine, rimuove quelli creati dall’helper: i mount dell’utente e il mapper già aperto restano disponibili.
La verifica del contenitore usa il crypttab del sistema installato. Questo consente di gestire nomi mapper differenti fra Live e installazione, ma non di ignorare una configurazione incoerente. Header LUKS, keyslot, crypttab e initramfs non vengono modificati.
Il caso di /boot dentro la root cifrata
Se /boot si trova dentro la root cifrata, GRUB deve poter leggere il contenitore prima di caricare il kernel. Dopo la conferma, Boot Repair abilita GRUB_ENABLE_CRYPTODISK=y tramite un file dedicato di impostazioni GRUB.
Con GRUB standard, un contenitore LUKS2 che contiene /boot deve avere un keyslot PBKDF2 compatibile. Un layout con soli slot Argon2 viene rifiutato prima della riparazione. L’utility non converte gli slot e non modifica l’header per aggirare questo limite. Una /boot separata e non cifrata evita questa specifica restrizione. LVM dentro LUKS resta fuori dal supporto della versione descritta.
Btrfs, snapshot e rollback
Boot Repair opera sulla root attiva @ e conserva @home, @/.snapshots, la configurazione Snapper e i backup di rollback. Non ripristina snapshot e non riesegue la configurazione del sistema di snapshot.
La rigenerazione richiama gli script GRUB già presenti nell’installazione. Se l’integrazione degli snapshot è installata e funzionante, viene coinvolta attraverso quegli script. Riparare il bootloader e ripristinare uno snapshot sono interventi distinti: scegliere Boot Repair quando il problema è nell’avvio, valutare il rollback separatamente quando il problema riguarda lo stato del sistema.
Uso da terminale
Per aprire il flusso interattivo nel terminale corrente:
syslinuxos-boot-repair-launcher --cli
I comandi seguenti sono esempi: sostituire ogni dispositivo con quello realmente verificato sulla propria macchina. Per esaminare una root e poi, se necessario, rigenerare la configurazione:
sudo syslinuxos-boot-repair --plan --root /dev/nvme0n1p2 sudo syslinuxos-boot-repair --config --root /dev/nvme0n1p2
Per una reinstallazione UEFI, con la Live avviata in UEFI a 64 bit e la partizione EFI correttamente indicata in fstab:
sudo syslinuxos-boot-repair --reinstall --root /dev/nvme0n1p2
Per una reinstallazione BIOS, indicare anche il disco intero contenente la root:
sudo syslinuxos-boot-repair --reinstall --root /dev/sda2 --disk /dev/sda
Da CLI una root LUKS deve essere già sbloccata. --root accetta il mapper aperto, oppure la partizione LUKS quando la sua mappatura diretta è disponibile. Se il mapper già aperto si chiama effettivamente /dev/mapper/cryptroot, un esempio di analisi è:
sudo syslinuxos-boot-repair --plan --root /dev/mapper/cryptroot
Le riparazioni da terminale richiedono di digitare l’intera riga di conferma mostrata, inclusa la parola letterale REPAIR, anche in italiano. Non copiare una conferma di un’altra macchina: contiene i dispositivi dell’operazione corrente. In GUI è il pulsante esplicito di conferma a fornire questa stessa conferma all’helper.
Lingua dell’interfaccia
Interfaccia e helper seguono la lingua della sessione Live, con supporto per italiano, inglese, tedesco, francese e spagnolo. L’inglese è la lingua predefinita quando la lingua della sessione non è supportata. Per avviare esplicitamente la GUI in italiano:
syslinuxos-boot-repair-launcher --language it
I messaggi dei comandi di sistema, compresi quelli di GRUB, possono mantenere la lingua propria di quei programmi.
Problemi comuni e controlli utili
Il programma richiede SysLinuxOS Live
Riavviare dalla USB Live. Avviare il programma nel sistema installato non equivale a eseguire un recupero dalla Live.
La root non viene riconosciuta o non corrisponde a fstab
Controllare che sia stata selezionata la root di SysLinuxOS, non la home, un altro sistema o la Live stessa. In Btrfs verificare che il layout utilizzi @. Non modificare UUID o file di configurazione soltanto per superare il controllo: prima occorre chiarire l’effettiva disposizione delle partizioni.
Errore UEFI o variabili EFI non disponibili
Controllare come è stata avviata la Live. Per la reinstallazione UEFI sono richiesti firmware UEFI a 64 bit e variabili EFI accessibili. Boot Repair non gestisce una procedura dedicata di configurazione o firma Secure Boot: eventuali problemi relativi a Secure Boot richiedono un’analisi specifica.
Manca update-grub o grub-install nel sistema installato
L’utility usa gli strumenti dell’installazione selezionata e non installa pacchetti al suo interno. Un’installazione con pacchetti GRUB mancanti o danneggiati richiede quindi un intervento manuale appropriato; reinstallare Boot Repair nella Live non ricrea quei file nel sistema sul disco.
La riparazione termina con un errore
Leggere e conservare i Dettagli prima di riprovare. Una riparazione può essere riuscita solo in parte: per esempio, l’installazione di GRUB può essere terminata mentre la rigenerazione del menu ha fallito. Non assumere che un errore annulli automaticamente le scritture precedenti. Il backup di grub.cfg non costituisce un rollback completo.
Verifiche dopo la riparazione
Dopo un esito positivo, chiudere l’applicazione e riavviare rimuovendo la USB quando richiesto. Verificare che il firmware avvii il disco corretto, che GRUB mostri le voci previste e che SysLinuxOS completi l’avvio. Se il menu degli snapshot era configurato, verificarne la presenza.
In dual boot controllare anche le altre voci, senza presumere che la reinstallazione garantisca il rilevamento di ogni sistema. Se SysLinuxOS arriva a GRUB ma il kernel o la root non si avviano, l’errore potrebbe riguardare componenti che Boot Repair non ricostruisce, come initramfs o configurazione del sistema installato.
La conferma finale è l’avvio reale della macchina: un messaggio di completamento dell’utility indica l’esito dei comandi eseguiti, non sostituisce questa verifica.
Riferimenti
Per approfondire il recupero manuale sullo stesso sistema, consultare anche Ripristinare GRUB su SysLinuxOS con Btrfs e subvolumi e Ripristinare GRUB su SysLinuxOS con partizioni cifrate LUKS. Le procedure manuali richiedono la verifica del layout effettivo e non vanno eseguite contemporaneamente a Boot Repair.
Repository ufficiale SysLinuxOS Tools e configurazione APT
SysLinuxOS: distribuzione, Live e documentazione del progetto
Debian Wiki: recupero di GRUB EFI
Debian Wiki: uso di chroot
Per la documentazione inclusa nel pacchetto:
man syslinuxos-boot-repair man syslinuxos-boot-repair-launcher less /usr/share/doc/syslinuxos-boot-repair/README.md
SysLinuxOS Boot Repair guida completa al ripristino di GRUB dalla Live
Informazioni sull'autore
