PROBLEMA Problemi di avvio, kernel e Btrfs con Fedora

[DonTech]

Ciao a tutti! Descrivo subito la problematica.
Su un PC c'è installata Fedora 39 e di recente ho installato l'ultimo kernel, il 6.8.11. A installazione completata ho riavviato e il kernel non si carica, in pratica dopo la schermata di Grub il monitor mostra soltanto la dicitura di caricamento e anche il led di attività del disco non da segni. Reinstallo il kernel ma il problema persiste. Facendo qualche ricerca non trovo molto.
Allora eseguo il comando sudo dmesg | grep -i failed ed ottengo questo output:

[    7.035696] nvidia: module verification failed: signature and/or required key missing - tainting kernel
[   12.617748] BTRFS warning (device nvme0n1p2): csum failed root 256 ino 6391800 off 36618240 csum 0xe8ad850d expected csum 0x75be784b mirror 1
[   12.617772] BTRFS warning (device nvme0n1p2): csum failed root 256 ino 6391800 off 36622336 csum 0x703efc6e expected csum 0xa68f5e81 mirror 1
[   12.617781] BTRFS warning (device nvme0n1p2): csum failed root 256 ino 6391800 off 36626432 csum 0xb202d783 expected csum 0x9d56c38b mirror 1
[   12.617789] BTRFS warning (device nvme0n1p2): csum failed root 256 ino 6391800 off 36630528 csum 0xe5548687 expected csum 0x3aaa0e25 mirror 1
[   46.505396] BTRFS warning (device nvme0n1p2): csum failed root 256 ino 6391800 off 36700160 csum 0xe8ad850d expected csum 0x75be784b mirror 1
[   46.505409] BTRFS warning (device nvme0n1p2): csum failed root 256 ino 6391800 off 36704256 csum 0x703efc6e expected csum 0xa68f5e81 mirror 1
[   46.505416] BTRFS warning (device nvme0n1p2): csum failed root 256 ino 6391800 off 36708352 csum 0xb202d783 expected csum 0x9d56c38b mirror 1
[   46.505421] BTRFS warning (device nvme0n1p2): csum failed root 256 ino 6391800 off 36712448 csum 0xe5548687 expected csum 0x3aaa0e25 mirror 1
[   46.505673] BTRFS warning (device nvme0n1p2): csum failed root 256 ino 6391800 off 36700160 csum 0xe8ad850d expected csum 0x75be784b mirror 1
[   46.505684] BTRFS warning (device nvme0n1p2): csum failed root 256 ino 6391800 off 36704256 csum 0x703efc6e expected csum 0xa68f5e81 mirror 1
[   46.505691] BTRFS warning (device nvme0n1p2): csum failed root 256 ino 6391800 off 36708352 csum 0xb202d783 expected csum 0x9d56c38b mirror 1
[   46.505697] BTRFS warning (device nvme0n1p2): csum failed root 256 ino 6391800 off 36712448 csum 0xe5548687 expected csum 0x3aaa0e25 mirror 1
[   46.505936] BTRFS warning (device nvme0n1p2): csum failed root 256 ino 6391800 off 36700160 csum 0xe8ad850d expected csum 0x75be784b mirror 1
[   46.505943] BTRFS warning (device nvme0n1p2): csum failed root 256 ino 6391800 off 36704256 csum 0x703efc6e expected csum 0xa68f5e81 mirror 1

Da ciò deduco di avere problemi con il disco o con il filesystem Btrfs. Faccio qualche altra ricerca ed eseguo altri comandi da terminale:

• sudo btrfs device stats /

[/dev/nvme0n1p2].write_io_errs    0
[/dev/nvme0n1p2].read_io_errs     0
[/dev/nvme0n1p2].flush_io_errs    0
[/dev/nvme0n1p2].corruption_errs  20593
[/dev/nvme0n1p2].generation_errs  0

​

• sudo btrfs scrub start -B /

Starting scrub on devid 1
scrub done for fa7f4375-9aca-4c2c-a122-8a0abaa53c18
Scrub started:    Sun Jun  2 11:50:42 2024
Status:           finished
Duration:         0:02:01
Total to scrub:   39.30GiB
Rate:             332.61MiB/s
Error summary:    csum=253252
    Corrected:      253232
    Uncorrectable:  20
    Unverified:     0
ERROR: there are 1 uncorrectable errors

• sudo btrfs check /dev/nvme0n1p2

Opening filesystem to check...
Checking filesystem on /dev/nvme0n1p2
UUID: fa7f4375-9aca-4c2c-a122-8a0abaa53c18
[1/7] checking root items
[2/7] checking extents
[3/7] checking free space tree
[4/7] checking fs roots
[5/7] checking only csums items (without verifying data)
[6/7] checking root refs
[7/7] checking quota groups skipped (not enabled on this FS)
found 39998722048 bytes used, no error found
total csum bytes: 36739452
total tree bytes: 2296004608
total fs tree bytes: 2134851584
total extent tree bytes: 104857600
btree space waste bytes: 483752904
file data blocks allocated: 234120581120
  referenced 88654282752

Da questi output credo che ci sia qualche problema con il filesystem Btrfs sull'NVMe.
Sono problemi gravi? Possono compromettere i dati? Indicano che l'NVMe è danneggiato? Possono essere la causa del mancato avvio del kernel?

Inoltre ho creato sullo stesso disco una nuova partizione Btrfs della stessa dimensione ed eseguito gli stessi comandi per confrontare gli output e ritrovare gli stessi errori. A quanto pare nessuno errore viene segnalato, quindi forse posso escludere eventuali problemi hardware dell'NVMe.
Potrebbe essere solo relativo alla singola partizione su cui è installata Fedora?

Infine mi sono reso conto che occasionalmente riscontro problemi di avvio anche con il kernel 6.8.10 funzionante: in pratica una volta avviato il sistema si blocca prima della comparsa di GDM e posso solo interagire con la shell tty. Devo riavviare per poter accedere al sistema con la shell di Gnome funzionante.

Qualcuno sa come potrei risolvere?

 

[EmanueleC]

Da questi output credo che ci sia qualche problema con il filesystem Btrfs sull'NVMe.
Sono problemi gravi? Possono compromettere i dati? Indicano che l'NVMe è danneggiato? Possono essere la causa del mancato avvio del kernel?

Il problema non è il filesystem Btrfs, ma hardware:

Gli errori corruption_errs specificamente indicano che durante il processo di verifica, Btrfs ha trovato dei blocchi che risultano corrotti. Questo significa che i dati in quei blocchi non corrispondono ai dati previsti, il che potrebbe essere dovuto a vari motivi, tra cui:

1. Guasti hardware: Problemi con il disco fisico o i dispositivi di archiviazione sottostanti
2. Bug nel file system: Errori nel codice del file system Btrfs stesso.
3. Problemi di alimentazione: Interruzioni improvvise dell'alimentazione che causano la corruzione dei dati in scrittura.
4. Errori nella memoria: Malfunzionamenti nella RAM che causano dati errati essere scritti sul disco.

Controllerei l'hardware.

 

[DonTech]

Il problema non è il filesystem Btrfs, ma hardware:

Nonostante le altre partizioni Btrfs sullo stesso disco siano esenti da errori il problema può essere comunque hardware?
E se provassi ad eliminare questa partizione, eseguire di nuovo i comandi dati in precedenza e poi ripristinare la partizione?
Ho letto che il filesystem Btrfs ha dei comandi per poter effettuare delle riparazioni, li potrei provare senza rischi?

Controllerei l'hardware.

I blocchi corrotti possono essere riparati?

1. Il disco è praticamente nuovo, ha giusto qualche ora di accensione. Possibile che sia difettoso o danneggiato?
2. Come posso trovare e risolvere gli eventuali errori nel codice del file system Btrfs?
3. Nessuna interruzione di alimentazione, il PC è stato quasi sempre acceso e quando è stato spento è stato fatto correttamente. L'alimentatore non presenta problematiche di alimentazione;
4. Ho controllato la RAM con MemTest (con più cicli di test) ed è sana, senza errori.

Posso controllare in qualche altro modo il disco o la partizione? Perchè se davvero danneggiato ho giusto ancora qualche giorno per poter fare il reso.

Aggiungo che la partizione che presenta problemi è stata creata e poi ci è stata clonata una partizione che era presente in un altro disco. Possibile che la clonazione abbia corrotto il filesystem Btrfs?

 

[EmanueleC]

Nonostante le altre partizioni Btrfs sullo stesso disco siano esenti da errori il problema può essere comunque hardware?

Si, potrebbe esserci una differenza sulla quantità di scritture che effettui su una particolare partizione, ed è in questi casi che potrebbe verificarsi un problema hardware

1. Il disco è praticamente nuovo, ha giusto qualche ora di accensione. Possibile che sia difettoso o danneggiato?

Non importa se è nuovo: potrebbe essere un difetto di fabbrica o un problema del firmware. Ma sono solo ipotesi non è detto che il problema sia il disco.

2. Come posso trovare e risolvere gli eventuali errori nel codice del file system Btrfs?

Facendo "debug" del codice, se sei uno sviluppatore del kernel Linux ed hai esperienza con i filesystem. Da utente puoi segnalare i bug. Ma dubito che in questo caso sia un problema del FS, altrimenti ci sarebbero state molte segnalazioni visto che è il FS predefinito di Fedora, openSUSE/SUSE... Lo scluderei.

3. Nessuna interruzione di alimentazione, il PC è stato quasi sempre acceso e quando è stato spento è stato fatto correttamente. L'alimentatore non presenta problematiche di alimentazione;

Il problema può verificarsi anche con una tensione instabile dell'alimentatore quando l'hardware richiede più energia. Che alimentatore hai?

4. Ho controllato la RAM con MemTest (con più cicli di test) ed è sana, senza errori.

Per quanto tempo? Quel controllo non è sempre affidabile, come minimo dovresti lasciarlo tutta la notte.

Aggiungo che la partizione che presenta problemi è stata creata e poi ci è stata clonata una partizione che era presente in un altro disco. Possibile che la clonazione abbia corrotto il filesystem Btrfs?

Direi che questa è la causa più probabile. Come l’hai clonata? Con quale comando? Btrfs ha dei comandi specifici per sostituire i dischi o copiare su un altro disco in modo più affidabile.

 

[DonTech]

Si, potrebbe esserci una differenza sulla quantità di scritture che effettui su una particolare partizione, ed è in questi casi che potrebbe verificarsi un problema hardware

Considerato che è nuovo la differenza di quantità di scritture è data solo dal fatto che in quella incriminata c'è stata clonata una partizione mentre nelle altre sono "vergini" con dati trasferiti in modalità "copia-incolla" (perchè pochi).
Posso fare qualcosa per individuare eventuali altri errori?

Non importa se è nuovo: potrebbe essere un difetto di fabbrica o un problema del firmware. Ma sono solo ipotesi non è detto che il problema sia il disco.

C'è qualcos altro che posso fare per controllare eventuali difetti hardware? Perchè poi altrimenti non posso fare neanche il reso.
L'ho anche montato come disco esterno ad un PC con Windows per visionare con tool come CristalDyskInfo se rilevasse qualcosa, oltre al comando smartctl. Ma nulla di anomalo.

Facendo "debug" del codice, se sei uno sviluppatore del kernel Linux ed hai esperienza con i filesystem. Da utente puoi segnalare i bug. Ma dubito che in questo caso sia un problema del FS, altrimenti ci sarebbero state molte segnalazioni visto che è il FS predefinito di Fedora, openSUSE/SUSE... Lo scluderei.

Allora direi che non è il mio caso.

Il problema può verificarsi anche con una tensione instabile dell'alimentatore quando l'hardware richiede più energia. Che alimentatore hai?

Dov'è montato il disco c'è un alimentatore Thermaltake da 700W installato di recente. Se necessiti del modello esatto devo controllare.

Per quanto tempo? Quel controllo non è sempre affidabile, come minimo dovresti lasciarlo tutta la notte.

Il test è durato quasi 5 ore. Quali altri tool consigli per testare la RAM?

Direi che questa è la causa più probabile. Come l’hai clonata? Con quale comando? Btrfs ha dei comandi specifici per sostituire i dischi o copiare su un altro disco in modo più affidabile.

Ho usato Rescuezilla per clonare la partizione. Di solito l'ho trovato sempre affidabile.
Non credevo ci fossero dei comandi specifici di Btrfs. Posso fare qualcosa adesso? Posso usare i comandi specifici di Btrfs per ripristinare la partizione e o ripararla? Mi sembra ci siano dei comandi Btrfs di tipo repair. Posso usare quelli?

Mi viene in mente che potrei eliminare la partizione incriminata, ricrearla e ripristinarci il backup della partizione fatto in precedenza. Potrebbe essere una soluzione?


Inoltre mi sono accorto che i corruption_errors aumentano un pò alla volta:
sudo btrfs device stats /:

[/dev/nvme0n1p2].write_io_errs    0
[/dev/nvme0n1p2].read_io_errs     0
[/dev/nvme0n1p2].flush_io_errs    0
[/dev/nvme0n1p2].corruption_errs  20875
[/dev/nvme0n1p2].generation_errs  0

 

[r3dl4nce]

BTRFS supporta i comandi send / receive come ZFS.
Non so come Clonezilli effettua la clonazione, ma andrebbero usati appunto i comandi send / receive su file system che lo supportano, copiare i settori porterebbe a problemi nel file system

Send/receive — BTRFS documentation

 

[EmanueleC]

Ho usato Rescuezilla per clonare la partizione. Di solito l'ho trovato sempre affidabile.

Mai usato, ma potrebbe non implementare bene Btrfs e fare qualcosa che a Btrfs non piace. Anche con clonezilla ad alcuni utenti ha dato problemi.
Hai il comando "send|receive" e "replace" per sostituire un disco.
Tempo fa ho creato una demo su come sostituire un disco a sistema avviato:

Sulla demo per ovvi motivi ho utilizzato il comando "add|remove" per sostituire un disco a sistema avviato. Ho prima aggiunto il nuovo disco e poi rimosso quello da sostituire. Tuttavia, se stai lavorando con un disco dati che può essere scollegato offline, puoi utilizzare il comando "replace".

Inoltre mi sono accorto che i corruption_errors aumentano un pò alla volta:

Se non hai dati da perdere e hai un backup di quella partizione, puoi provare il comando "repair", in caso ti consiglio di formattare.

 

[DonTech]

BTRFS supporta i comandi send / receive come ZFS.
Non so come Clonezilli effettua la clonazione, ma andrebbero usati appunto i comandi send / receive su file system che lo supportano, copiare i settori porterebbe a problemi nel file system

Send/receive — BTRFS documentation

Avevo letto qualcosa su questo comando ma credevo servisse solo a spostare gli snasphot.
Dal link che mi hai inviato, leggendo, deduco che debba usare l'opzione clone.
Seguirò anche la guida che mi è stata suggerita qui di seguito.
Non ero a conoscenza che Rescuezilla potesse creare problemi.

Ora mi preme capire se il disco ha problemi hardware o meno, perchè mi restano un paio di giorni per fare il reso (che vorrei evitare).
--- i due messaggi sono stati uniti ---

Mai usato, ma potrebbe non implementare bene Btrfs e fare qualcosa che a Btrfs non piace. Anche con clonezilla ad alcuni utenti ha dato problemi.
Hai il comando "send|receive" e "replace" per sostituire un disco.
Tempo fa ho creato una demo su come sostituire un disco a sistema avviato:

Sulla demo per ovvi motivi ho utilizzato il comando "add|remove" per sostituire un disco a sistema avviato. Ho prima aggiunto il nuovo disco e poi rimosso quello da sostituire. Tuttavia, se stai lavorando con un disco dati che può essere scollegato offline, puoi utilizzare il comando "replace".

Grazie mille per la guida! Quindi sono operazioni che si possono svolgere "a caldo" sul sistema in esecuzione.
Se fossi in un sistema live dovrei usare dei comandi diversi?
No, non lavorerei con un disco dati da poter essere scollegato.

Però ora la mia situazione è questa: ho un backup della partizione del disco originale/iniziale, ho un backup della partizione attuale del nuovo disco e la partizione di origine è stata eliminata.
Quindi come posso usare questi comandi ora? Dovrei ripristinare il backup originale sul disco di origine e poi eseguire la guida?

Se non hai dati da perdere e hai un backup di quella partizione, puoi provare il comando "repair", in caso ti consiglio di formattare.

C'è solo il sistema con l'intera configurazione, vorrei evitare di reinstallare tutto. Le configurazioni posso salvare dalla /home giusto?
Si ho un backup di questa partizione. Gli errori potrebbero replicarsi nel bakup?
Il comando repair sarebbe il primo di questo link? https://btrfs.readthedocs.io/en/latest/btrfs-check.html#dangerous-options
Il comando da dare sarebbe: sudo btrfs check --repair /dev/nvme0n1 ? O devo precisare la partizione e quindi /dev/nvme0n1p2? Va dato da sessione live giusto? Perchè deve essere smontata la partizione.
Se formatto ripristino il backup giusto?

Ci sono altri test che posso fare per controllare eventuali problemi hardware del disco?

 

[r3dl4nce]

Test SMART del disco
smartctl -t long /dev/sdX


Risultati con
smartctl -l selftest /dev/sdX


Puoi anche fare un test settore per settore, non così indicativo su ssd, ma se riscontrasse problemi saresti certo del guasto

badblocks -vsw /dev/sdX
Attenzione che questo è distruttivo, perdi tutto il contenuto del disco


Temo però che il problema più che il disco sia il backup che non ha gestito bene btrfs e quindi ho paura che non sia recuperabile, non hai più il disco sorgente?

 

[DonTech]

Test SMART del disco
smartctl -t long /dev/sdX


Risultati con
smartctl -l selftest /dev/sdX


Puoi anche fare un test settore per settore, non così indicativo su ssd, ma se riscontrasse problemi saresti certo del guasto

badblocks -vsw /dev/sdX
Attenzione che questo è distruttivo, perdi tutto il contenuto del disco


Temo però che il problema più che il disco sia il backup che non ha gestito bene btrfs e quindi ho paura che non sia recuperabile, non hai più il disco sorgente?

Il comando smartctl purtroppo mi daà questo output, probabilmente dovuto al fatto che il disco è collegato tramite uno slot PCIe invece che su slot M.2 (almeno da ciò che ho letto da alcuni articoli):

Read Self-test Log failed: Invalid Field in Command (0x002)

Ho dato il comando sudo smartctl -a /dev/nvme0n1 e ottengo questo output:

=== START OF SMART DATA SECTION ===
SMART overall-health self-assessment test result: PASSED

SMART/Health Information (NVMe Log 0x02)
Critical Warning:                   0x00
Temperature:                        23 Celsius
Available Spare:                    100%
Available Spare Threshold:          1%
Percentage Used:                    0%
Data Units Read:                    2.122.731 [1,08 TB]
Data Units Written:                 618.241 [316 GB]
Host Read Commands:                 16.347.254
Host Write Commands:                12.331.067
Controller Busy Time:               67
Power Cycles:                       19
Power On Hours:                     37
Unsafe Shutdowns:                   4
Media and Data Integrity Errors:    0
Error Information Log Entries:      0
Warning  Comp. Temperature Time:    0
Critical Comp. Temperature Time:    0
Temperature Sensor 1:               23 Celsius
Temperature Sensor 2:               30 Celsius

Error Information (NVMe Log 0x01, 16 of 64 entries)
No Errors Logged

Read Self-test Log failed: Invalid Field in Command (0x002)

Ho dato eseguito anche il comando sudo nvme smart-log /dev/nvme0n1:

Smart Log for NVME device:nvme0n1 namespace-id:ffffffff
critical_warning            : 0
temperature                : 24 °C (297 K)
available_spare                : 100%
available_spare_threshold        : 1%
percentage_used                : 0%
endurance group critical warning summary: 0
Data Units Read                : 2122731 (1.09 TB)
Data Units Written            : 618069 (316.45 GB)
host_read_commands            : 16347252
host_write_commands            : 12326822
controller_busy_time            : 67
power_cycles                : 19
power_on_hours                : 37
unsafe_shutdowns            : 4
media_errors                : 0
num_err_log_entries            : 0
Warning Temperature Time        : 0
Critical Composite Temperature Time    : 0
Temperature Sensor 1           : 24 °C (297 K)
Temperature Sensor 2           : 30 °C (303 K)
Thermal Management T1 Trans Count    : 0
Thermal Management T2 Trans Count    : 0
Thermal Management T1 Total Time    : 0
Thermal Management T2 Total Time    : 0

Il comando sui blocchi magari lo farei una volta eliminato tutto e dopo esser certo di poter ripristnare correttamente il sistema.

Intendi dire che non sia più recuperabile la partizione dal punto di vista software?
Il disco di origine cè l'ho ancora, però senza partizione originale. Ho il backup della partizione originale. Potrei ripristinare il backup della partizione sul disco originale, controllarla e poi eseguire il trasferimento della partizione tramite i comandi Btrfs?

 

[r3dl4nce]

Secondo me il disco è a posto e hai possibilmente due problemi:
- il controller a cui l'hai collegato, io lo collegherei su scheda madre, non su controller aggiuntivi che aggiungono rischi di guasto
- il software usato per far eil backup, che potrebbe non aver gestito bene btrs e quindi ora ti ritrovi con un backup non funzionante.

Prova a ripristinare il backup su un disco SATA e non su nvme, connesso direttamente al sata della scheda madre, e vedi se così funziona

 

[DonTech]

Secondo me il disco è a posto e hai possibilmente due problemi:
- il controller a cui l'hai collegato, io lo collegherei su scheda madre, non su controller aggiuntivi che aggiungono rischi di guasto
- il software usato per far eil backup, che potrebbe non aver gestito bene btrs e quindi ora ti ritrovi con un backup non funzionante.

Prova a ripristinare il backup su un disco SATA e non su nvme, connesso direttamente al sata della scheda madre, e vedi se così funziona

Quindi dici che posso escludere l'opzione di restituirlo?
- Nell'immediato non riesco a testarlo direttamente sulla scheda madre, perchè c'è solo uno slot M.2 SATA. Proverò appena rientro su un'altra scheda madre.
- A questo punto è probabile che Rescuezilla non abbia gestito bene il backup. Ma nel backup è possibile che ci siano anche questi errori o sono solo relativi al filesystem?

Quindi:

1. Riprisitno il backup originale sul SSD SATA originale, collegato direttamente alla scheda madre;
2. Da sessione live eseguo i comandi btrfs che ho eseguito in precedenza per controllare errori nel filesystem;
3. Se è tutto ok, senza errori, posso tentare il comando repair sull'NVMe.
4. Ricontrollo la partizione sull'NVMe, se presenta ancora errori formatto e seguo la guida con in comandi send|receive da sessione live.

Ma i comandi send|receive copiano anche la configurazione di grub e il UUID della partizione?

 

[r3dl4nce]

Quindi dici che posso escludere l'opzione di restituirlo?

Che NVME è? Forse l'hai scritto, ma dai dati smart postati sopra non lo vedo.

- Nell'immediato non riesco a testarlo direttamente sulla scheda madre, perchè c'è solo uno slot M.2 SATA. Proverò appena rientro su un'altra scheda madre.

Non hai capito, prendi un SSD SATA e fai il ripristino sul SSD SATA, che se ci si mette pure di mezzo l'adattatore NVME/PCI è un bel bordello. Tra l'altro io ti sconsiglio vivamente di usare questo adattatore, se non hai slot M2 pci-ex, prendi un SSD SATA tipo il crucial mx500 e fai il reso del NVME

- A questo punto è probabile che Rescuezilla non abbia gestito bene il backup. Ma nel backup è possibile che ci siano anche questi errori o sono solo relativi al filesystem?

Il mio sospetto va sempre più all'adattatore nvme/pci-ex ma potrebbe anche essere che il backup è danneggiato e quindi non avrai mai un ripristino "sano", per questo consigliavo di effettuare un ripristino quanto più "lineare" possibile, ovvero su SSD SATA su slot SATA della scheda madre, per avere certezza dell'integrità del backup

 

[EmanueleC]

Se fossi in un sistema live dovrei usare dei comandi diversi?

Raccomandato è di usare "replace" per la sostituzione offline, perché va a creare un raid 1 temporaneo. Però, perdi la comodità installare il boot loader, se lo fai offline|live puoi farlo lo stesso, ma devi usare il chroot ecc.

Però ora la mia situazione è questa: ho un backup della partizione del disco originale/iniziale, ho un backup della partizione attuale del nuovo disco e la partizione di origine è stata eliminata.
Quindi come posso usare questi comandi ora? Dovrei ripristinare il backup originale sul disco di origine e poi eseguire la guida?

In questo caso non hai modo di sfruttare le funzionalità di Btrfs, tranne che il backup è su un subvolume Btrfs.

Il comando repair sarebbe il primo di questo link? https://btrfs.readthedocs.io/en/latest/btrfs-check.html#dangerous-options
Il comando da dare sarebbe: sudo btrfs check --repair /dev/nvme0n1 ? O devo precisare la partizione e quindi /dev/nvme0n1p2? Va dato da sessione live giusto? Perchè deve essere smontata la partizione.
Se formatto ripristino il backup giusto?

Devi indicare la partizione Btrfs:

sudo btrfs check --repair /dev/nvme0n1p2

Si, esegui il comando da una live.
--- i due messaggi sono stati uniti ---

1. Da sessione live eseguo i comandi btrfs che ho eseguito in precedenza per controllare errori nel filesystem;

Per verificare il checksumming dei dati in modo approfondito:
(offline)

sudo btrfs check --check-data-csum /device

Check and reporting options:
--check-data-csum verify checksums of data blocks

Se è tutto ok con il primo comando:
(Online)

sudo btrfs scrub start -Bd /mountpoint

 

[DonTech]

Che NVME è? Forse l'hai scritto, ma dai dati smart postati sopra non lo vedo.

Un Fanxiang.

Non hai capito, prendi un SSD SATA e fai il ripristino sul SSD SATA, che se ci si mette pure di mezzo l'adattatore NVME/PCI è un bel bordello. Tra l'altro io ti sconsiglio vivamente di usare questo adattatore, se non hai slot M2 pci-ex, prendi un SSD SATA tipo il crucial mx500 e fai il reso del NVME

Ho voluto solo specificare che in quel momento avevo solo una scheda madre con slot M.2 SATA, tutto qua.
Mi è chiaro che devo ripristinare il backup originale sul SSD SATA di origine.
L'opzione di aggiungere un ulteriore SSD SATA è esclusa perchè tutte le porte sono occupate.

Il mio sospetto va sempre più all'adattatore nvme/pci-ex ma potrebbe anche essere che il backup è danneggiato e quindi non avrai mai un ripristino "sano", per questo consigliavo di effettuare un ripristino quanto più "lineare" possibile, ovvero su SSD SATA su slot SATA della scheda madre, per avere certezza dell'integrità del backup

L'adattatore fin'ora anche con altri NVMe non ha dato problemi simili, può esserci la possibilità che si sia rovinato proprio ora ma credo che le probabilità siano basse.

Ho effettuato un ripristino "lineare", ovvero su SSD SATA di origine su slot SATA della scheda madre, ma purtroppo facendo i test btrfs sulla partizione sono presenti errori che prima non c'erano. Quindi il backup è danneggiato.

Quali potrebbero essere le altre possibili soluzioni? Solo una nuova installazione da zero?
--- i due messaggi sono stati uniti ---

In questo caso non hai modo di sfruttare le funzionalità di Btrfs, tranne che il backup è su un subvolume Btrfs.

Ho effettuato il ripristino della partizione Btrfs originale sul SSD di origine per poi provare a seguire la tua guida.
Ho dato i comandi di check su questa partizione e purtroppo gli output danno errori simili a quelli mostrati nel mio post iniziale. Quindi credo che il backup sia rovinato.

Si, esegui il comando da una live.

Ho esguito il comando repair da una live e poi i comandi di checksumming. Questi ultimi riportano ugualmente degli errori.

Dato che anche il ripristino del backup originale riporta degli errori cos'altro si può tentare? Seguire la tua guida in questo caso non sarebbe utile immagino?