Se un filesystem Btrfs di SUSE Linux Enterprise segnala "Filesystem di sola lettura", innanzitutto verifica se è stato montato in sola lettura intenzionalmente o se è passato a tale modalità a seguito di un errore. Controlla le opzioni di montaggio, lo spazio libero e il log del kernel prima di tentare un rimontaggio. Utilizza Snapper rollback per creare uno snapshot di sistema avviabile verificato; se Btrfs ha registrato errori di I/O o di metadati, proteggi i dati e diagnostica il percorso di archiviazione prima di scrivere nuovamente sul filesystem.
Sostituire /datacon il punto di montaggio interessato, oppure /per la radice.
findmnt -T /data -o SOURCE,FSTYPE,OPTIONS
sudo btrfs filesystem show /dataNel primo comando, cerca roo rwnelle opzioni. Uno snapshot Snapper di sola lettura dovrebbe rifiutare le scritture. Anche un mount configurato con roin /etc/fstabpotrebbe essere intenzionale. Btrfs può anche passare alla modalità di sola lettura dopo gravi errori di transazione, metadati o dispositivo. In tal caso, l'esecuzione ripetuta mount -o remount,rwnon risolve la causa e potrebbe fallire immediatamente.
Se il filesystem è stato montato intenzionalmente in sola lettura, il dispositivo è integro e il log del kernel non presenta errori Btrfs o di I/O, un normale mount di dati può essere rimontato in modalità lettura/scrittura:
sudo mount -o remount,rw /data
findmnt -T /data -o TARGET,OPTIONSNon utilizzare questo comando per il ripristino di uno snapshot di sola lettura avviato o di un filesystem di sola lettura forzato da un errore. Un rimontaggio riuscito conferma la possibilità di scrittura, non l'integrità del filesystem.
Anche quando una visualizzazione di base del disco mostra anomalie, Btrfs può esaurire lo spazio allocabile, poiché l'allocazione dei dati e dei metadati viene tracciata separatamente. Verifica sia lo spazio libero ordinario che l'utilizzo di Btrfs:
df -hT /data
sudo btrfs filesystem usage -T /dataSe il sistema segnala errori No space left on devicee il log del kernel non mostra guasti del dispositivo o errori strutturali, prima di rimuovere qualsiasi elemento, verificare l'utilizzo di Snapper:
sudo snapper listElimina solo gli snapshot che la tua policy di conservazione ti consente di perdere, uno sudo snapper delete SNAPSHOT_IDper ogni ID selezionato. Conserva uno snapshot precedente all'aggiornamento funzionante se hai bisogno di un'opzione di ripristino; l'eliminazione degli snapshot recupera spazio ma rimuove i punti di ripristino. La pulizia potrebbe non ripristinare immediatamente lo spazio e gli snapshot non correggono gli errori di I/O. Non eseguire un bilanciamento per forzare la scrittura di un filesystem di sola lettura; questa operazione sposta i dati ed è pensata per un problema di allocazione diagnosticato su un filesystem sano e scrivibile.
Cerca il primo errore relativo a Btrfs, dispositivi a blocchi, controller o trasporto, non solo il messaggio finale che indica che il filesystem è diventato di sola lettura:
sudo journalctl -k -b --no-pager | grep -Ei 'btrfs|I/O error|nvme|ata|scsi'I messaggi relativi a letture non riuscite, mancate corrispondenze del checksum, dispositivi mancanti o errori di I/O indicano una strada diversa da una semplice roopzione di montaggio. Verificare le informazioni sullo stato del disco, del controller, del RAID/HBA, della SAN o del livello del disco virtuale e del fornitore. Correggere prima eventuali problemi hardware o di connettività instabili. Se i dati sono importanti, ridurre al minimo le scritture e concordare con un amministratore un backup o un'immagine a livello di blocco prima di tentare la riparazione del filesystem.
| Cosa hai trovato | Azione successiva | Compromesso |
|---|---|---|
roè configurato o il mount è stato intenzionalmente impostato in sola lettura; nessun errore del kernel rilevante | Correggi la configurazione di montaggio se non è quella desiderata, oppure rimonta un normale sottovolume scrivibile dopo aver verificato che il dispositivo sia integro. | Veloce, ma il rimontaggio non può eliminare uno stato di sola lettura forzato da un errore né rendere scrivibile un'istantanea di sola lettura. |
| Uno snapshot di root avviabile funziona e il problema è seguito a una modifica del sistema | Avvia e testa lo snapshot, quindi esegui sudo snapper rollbacke riavvia per tornare alla voce predefinita. | Ripristina il sottovolume root allo stato dello snapshot. I dati nei sottovolumi esclusi o separati non vengono ripristinati. SLES 15 SP7 supporta questo ripristino solo con la configurazione predefinita root-sottovolume e un filesystem root su un singolo dispositivo. |
| Il log del kernel contiene errori di I/O di archiviazione o errori strutturali di Btrfs. | Stabilizzare lo spazio di archiviazione e preservare i dati; utilizzare un ambiente di ripristino e richiedere un intervento di livello superiore per il ripristino specifico del filesystem. | Più lento, ma evita di nascondere un problema hardware irrisolto con un rimontaggio scrivibile. |
| Viene segnalato solo l'esaurimento dello spazio; non sono presenti errori di archiviazione. | Esamina la conservazione di Snapper e libera gli snapshot o i dati consentiti, quindi ricontrolla l'utilizzo di Btrfs. | Libera spazio a scapito di punti di ripristino o file selezionati. |
Su SLES, gli snapshot avviabili utilizzano la configurazione root predefinita di Snapper. La root deve essere Btrfs su un dispositivo, il boot loader deve supportarla e viene ripristinato solo il sottovolume root. Verificare l'immagine candidata prima di confermarla; se non idonea, riavviare il sistema corrente o l'ambiente di ripristino. Consultare la procedura di ripristino di Snapper per SLES 15 SP7 .
Se il filesystem non si monta o i messaggi del kernel suggeriscono un danno strutturale, avviare il sistema di ripristino SLES o un altro ambiente di ripristino appropriato, identificare il dispositivo corretto e assicurarsi che sia smontato prima di eseguire il controllo predefinito in sola lettura:
sudo btrfs check /dev/DEVICEUtilizzare il dispositivo a blocchi Btrfs effettivo, non un segnaposto per il punto di montaggio. Un controllo può richiedere tempo e memoria e segnala anomalie strutturali; non garantisce la riparazione. Non aggiungerlo --repaircome passaggio successivo di routine. La documentazione di Btrfs avverte che la riparazione può peggiorare la situazione e dovrebbe essere eseguita solo con la guida di un esperto, dopo aver accettato il rischio per i dati. Consultare l'assistenza SUSE o uno specialista Btrfs se il controllo segnala errori o se il dispositivo presenta guasti di I/O.
Una volta che l'archiviazione è stabile e il filesystem è montato in modalità lettura/scrittura, sudo btrfs scrub start -B /dataè possibile verificare i checksum. Scrub non è uno strumento di verifica strutturale. Può riparare i danni solo da una copia ridondante funzionante; su una configurazione a copia singola, rileva gli errori ma non può ricostruire i dati persi. Consultare la documentazione di Btrfs scrub . Vedere anche la guida ai filesystem di SLES 15 SP7 di SUSE , l' articolo di SUSE sul ripristino di Btrfs e il manuale di Btrfs check .
Dopo aver scelto il ripristino, verificare che il mount abbia le opzioni desiderate e che sia possibile eseguire una scrittura sicura:
findmnt -T /data -o TARGET,SOURCE,FSTYPE,OPTIONS
sudo touch /data/.rw-check && sudo rm /data/.rw-checkPer ripristinare uno snapshot di root, riavviare prima il sistema e verificare che il sistema predefinito si avvii normalmente. Quindi, esaminare il nuovo log del kernel per individuare eventuali errori ricorrenti di Btrfs o dei dispositivi. Un flag di lettura/scrittura da solo non è sufficiente a garantire il corretto funzionamento: se gli errori si ripresentano, interrompere le scritture e tornare alla diagnostica dello storage.
Verifica se Btrfs è intenzionalmente di sola lettura, se ha poco spazio disponibile o se protegge i dati dopo gli errori, quindi scegli un percorso di ripristino adeguato alla causa.
Preparare canali mirror, creare una chiave di attivazione e avviare un client SLES 15 senza accesso diretto a Internet, preservando al contempo la connessione necessaria per i check-in dei manager.
Risolvi l'errore di avvio di YaST in XIO tramite SSH, verifica l'inoltro X11 e l'autenticazione xauth e passa all'interfaccia ncurses quando una finestra remota non è necessaria.
Trova lo snapshot di Btrfs precedente all'aggiornamento, testalo in sola lettura e rendi il ripristino permanente con Snapper, comprendendo quali dati rimangono al di fuori del rollback della partizione root.
Invio dei log di sistema SLES a un collettore rsyslog remoto tramite TLS autenticato, con verifica dei certificati, buffering in caso di interruzione del servizio e test di consegna.
Utilizza i log di RAM, swap, kernel e Zypper per identificare la reale pressione sulla memoria, proteggere lo stato dei pacchetti e scegliere un tentativo di aggiornamento SLES più sicuro.
Abilita gli aggiornamenti di sicurezza automatici di Debian tramite SSH, mantieni le sorgenti predefinite dei pacchetti e verifica le esecuzioni pianificate tramite i log di systemd e APT.
Confronta le opzioni di consegna della posta, configura smartd su Ubuntu e verifica che gli avvisi sullo stato del disco vengano recapitati nella tua casella di posta.
Ripristina le ricerche DNS su Debian 12 controllando systemd-resolved, riparando resolv.conf quando necessario e verificando la risoluzione DNS upstream e quella dell'applicazione.
Fai in modo che Ubuntu rilevi il monitor o la TV come uscita audio, selezionalo nelle impostazioni audio e controlla la connessione o l'elenco dei dispositivi PipeWire se l'HDMI non è presente.
