Errore EXT4-fs dopo l'aggiornamento di Ubuntu 17.04

Ho un Dell XPS 15 9550 . Ho eseguito Ubuntu 16.10 su di esso per quattro mesi senza drammi.

Due giorni fa, sono passato a Ubuntu 17.04 . Circa un'ora dopo l'aggiornamento, il mio disco rigido è tornato in modalità di sola lettura. Quando sono saltato su uno schermo tty, questo è apparso:

[ 746.341551] EXT4-fs error (device nvme0n1p7): ext4_find_entry:1463: inode #525023: comm NetworkManager: reading directory iblock 0
[ 746.343318] EXT4-fs error (device nvme0n1p7): ext4_find_entry:1463: inode #524289: comm pool: reading directory iblock 0
[ 746.356125] EXT4-fs error (device nvme0n1p7): ext4_find_entry:1463: inode #11272213: comm systemd-udevd: reading directory iblock 0
[ 746.356139] EXT4-fs error (device nvme0n1p7): ext4_find_entry:1463: inode #11272210: comm systemd-udevd: reading directory iblock 0
[ 746.356332] EXT4-fs error (device nvme0n1p7): ext4_find_entry:1463: inode #11272193: comm systemd-udevd: reading directory iblock 0
[ 746.356338] EXT4-fs error (device nvme0n1p7): ext4_find_entry:1463: inode #11272825: comm systemd-udevd: reading directory iblock 0
[ 746.356400] EXT4-fs error (device nvme0n1p7): ext4_find_entry:1463: inode #11272210: comm systemd-udevd: reading directory iblock 0
[ 746.474632] EXT4-fs error (device nvme0n1p7): ext4_find_entry:1463: inode #524539: comm unity-settings-: reading directory iblock 0
[ 746.992814] EXT4-fs error (device nvme0n1p7): ext4_find_entry:1463: inode #5506108: comm BrowserBlocking: reading directory iblock 0
[ 746.304451] EXT4-fs error (device nvme0n1p7): ext4_find_entry:1463: inode #5506117: comm BrowserBlocking: reading directory iblock 0

Ecco cosa fdisk -lmostra:

Disk /dev/nvme0n1: 477 GiB, 512110190592 bytes, 1000215216 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 3CD27380-DAC8-48DC-910A-D084CE857DA3

Device             Start        End   Sectors   Size Type
/dev/nvme0n1p1      2048    1026047   1024000   500M EFI System
/dev/nvme0n1p2   1026048    1288191    262144   128M Microsoft reserved
/dev/nvme0n1p3   1288192  487948287 486660096 232.1G Microsoft basic data
/dev/nvme0n1p4 972302336  973223935    921600   450M Windows recovery environmen
/dev/nvme0n1p5 973223936  998094847  24870912  11.9G Windows recovery environmen
/dev/nvme0n1p6 998094848 1000204287   2109440     1G Windows recovery environmen
/dev/nvme0n1p7 487948288  939046911 451098624 215.1G Linux filesystem
/dev/nvme0n1p8 939046912  972302335  33255424  15.9G Linux swap

Partition table entries are not in disk order.

Ho riavviato e ho continuato a ricevere l'errore una volta ogni ora. Quindi ho reinstallato Ubuntu 17.04 da zero . Tuttavia sto ancora riscontrando lo stesso problema.

Ho provato a eseguire fsck creando un file / forcefsck (ho creato uno script shell wrapper che aggiunge il -vflag e genera stdout in un file). Ecco il risultato:

fsck.fat 4.0 (2016-05-06)                               
Checking we can access the last sector of the filesystem
Boot sector contents:                                   
System ID "MSDOS5.0"                                    
Media byte 0xf8 (hard disk)                             
       512 bytes per logical sector                     
      4096 bytes per cluster                            
      6206 reserved sectors                             
First FAT starts at byte 3177472 (sector 6206)          
         2 FATs, 32 bit entries                         
    508416 bytes per FAT (= 993 sectors)                
Root directory start at cluster 2 (arbitrary size)      
Data area starts at byte 4194304 (sector 8192)          
    126976 data clusters (520093696 bytes)              
63 sectors/track, 255 heads                             
      2048 hidden sectors                               
   1024000 sectors total                                
Reclaiming unconnected clusters.                        
Checking free cluster summary.                          
/dev/nvme0n1p1: 212 files, 15526/126976 clusters

Ho provato a fare il boot da una USB live ed eseguire e2fsck -p /dev/nvme0n1p7come suggerito qui ( /ubuntu//a/768813/679041 ). Non ha dato errori.

Ho anche provato a eseguire, smartctl -t long /dev/nvme0n1p7tuttavia i risultati sembrano indicare che lo strumento non funziona con il mio SSD particolare:

smartctl 6.6 2016-05-31 r4324 [x86_64-linux-4.10.0-19-generic] (local build)
Copyright (C) 2002-16, Bruce Allen, Christian Franke, www.smartmontools.org

=== START OF INFORMATION SECTION ===
Model Number:                       PM951 NVMe SAMSUNG 512GB
Serial Number:                      S29PNX0H611013
Firmware Version:                   BXV77D0Q
PCI Vendor/Subsystem ID:            0x144d
IEEE OUI Identifier:                0x002538
Controller ID:                      1
Number of Namespaces:               1
Namespace 1 Size/Capacity:          512,110,190,592 [512 GB]
Namespace 1 Utilization:            254,982,533,120 [254 GB]
Namespace 1 Formatted LBA Size:     512
Local Time is:                      Mon Apr 17 17:45:48 2017 AEST
Firmware Updates (0x06):            3 Slots
Optional Admin Commands (0x0017):   Security Format Frmw_DL *Other*
Optional NVM Commands (0x001f):     Comp Wr_Unc DS_Mngmt Wr_Zero Sav/Sel_Feat
Maximum Data Transfer Size:         32 Pages

Supported Power States
St Op     Max   Active     Idle   RL RT WL WT  Ent_Lat  Ex_Lat
 0 +     6.00W       -        -    0  0  0  0        5       5
 1 +     4.20W       -        -    1  1  1  1       30      30
 2 +     3.10W       -        -    2  2  2  2      100     100
 3 -   0.0700W       -        -    3  3  3  3      500    5000
 4 -   0.0050W       -        -    4  4  4  4     2000   22000

Supported LBA Sizes (NSID 0x1)
Id Fmt  Data  Metadt  Rel_Perf
 0 +     512       0         0

=== START OF SMART DATA SECTION ===
Read NVMe SMART/Health Information failed: NVMe Status 0x2002

Qualche idea del perché questo problema potrebbe verificarsi e di come potrei risolverlo? Grazie! :)

filesystem ext4 17.04

— Ben B.
fonte

Benvenuto in AskUbuntu! Sembra che tu possa essere interessato da questo errore. Ti consiglio di far sapere agli sviluppatori che questo errore ha effetto anche su di te e di iscriverti all'errore in modo da poter essere informato dell'avanzamento / risoluzione.

— Elder Geek,

Sto riscontrando lo stesso identico problema su un Lenovo Thinkpad X270 con un SSD Toshiba "THNSF5256GPUK TOSHIBA". Immagino sia bello sapere che non sono l'unico.

— Maeher,

@ElderGeek, leggendo la segnalazione di bug collegata, sembra che fino a quando il problema non sarà risolto, una soluzione temporanea sarebbe quella di disabilitare APST, tuttavia dalla discussione lì non mi è chiaro come farlo. Sembra che un modo per farlo sarebbe una risposta valida a questa domanda.

— Maeher,

Grazie per i vostri commenti ragazzi :) Impazientemente, ho reinstallato la scorsa notte, tuttavia questa volta ho formattato esplicitamente / dev / nvme0n1p7 e cancellato in anticipo / dev / nvme0n1p8 (ho pensato che forse una reinstallazione con tutte le opzioni predefinite potrebbe non formattare, e invece cancellare solo i vecchi file prima di installarne di nuovi). Devo ancora sperimentare il problema dopo 4 ore di uso ininterrotto, ma solo il tempo lo dirà. Sentirai i miei singhiozzi attraverso il Pacifico se lo faccio :)

— Ben B

OK, posso confermare - Ho appena ripreso il problema nonostante la formattazione completa della partizione. Aggiungerà un commento al bug collegato sopra

— Ben B

Risposte:

Come sottolineato in un commento dell'anziano Geek , ciò è dovuto a un bug noto .

Dalla segnalazione bug:

Il supporto APST è appena arrivato nell'ultimo kernel Zesty (4.10.0-14.16) come parte di https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1664602 . Quella patch ha una stranezza per alcune unità Samsung da 256 GB trovate nei laptop Dell che non si comportano bene quando è abilitato APST. Sto riscontrando gli stessi sintomi con lo stesso modello di laptop, tranne con un Samsung da 512 GB. Prima di disabilitare manualmente APST l'unità sarebbe morta e il sistema sarebbe andato in fiamme con errori I / O entro 20-40 minuti dall'avvio.

Fino a quando non viene implementata una correzione corretta, viene suggerita una soluzione alternativa, che prevede l' aggiunta di un parametro del kernel :

Prova nvme_core.default_ps_max_latency_us=5500, se il problema persiste, prova nvme_core.default_ps_max_latency_us=200.

Per aggiungere un parametro di avvio del kernel, modificare il file di configurazione per GRUB:

sudo nano /etc/default/grub

Trova l'inizio della riga GRUB_CMDLINE_LINUX_DEFAULTe aggiungi il parametro di avvio agli altri già tra le virgolette. Ad esempio, in questo caso probabilmente finirai con

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash nvme_core.default_ps_max_latency_us=5500"

Salvare il file ed uscire, quindi per rendere effettiva la modifica, eseguire

sudo update-grub

— Ben B.
fonte

Questa correzione funziona per te? A proposito, un link su come impostare i parametri del kernel per chi potrebbe inciampare nella tua risposta wiki.ubuntu.com/Kernel/KernelBootParameters

— justmyfault

Sto eseguendo Ubuntu 16.04 e sto aggiornando i pacchetti in maniera frammentaria, qualcosa che non consiglierei a nessuno ma che faccio per necessità. L'ultimo pacchetto era libc, qualcosa di così integrato nel sistema che se qualcosa andava storto sarebbe durante l'aggiornamento di libc. Al riavvio, ho visto tutti gli errori EXT4 menzionati nella domanda precedente, ma l'aggiunta del parametro kernel mi ha finalmente permesso di riavviare in pace e continuare. Grazie.

— lukecampbell

eventuali aggiornamenti su questo? Sto soffrendo questo problema sul mio razer blade stealth con un ssd Samsung da 512 GB

— Lucas Zanella,

La soluzione precedente ha funzionato per me, ma il bug è stato corretto nel pacchetto linux - 4.10.0-22.24. Se i problemi persistono, è necessario aprire una nuova segnalazione di bug su launchpad.

— Ben B

Ho provato entrambi i valori, ma si è comunque bloccato. nvme_core.default_ps_max_latency_us = 0 ha funzionato per me. Kernel 4.15.0-36-generic Ubuntu 16.04

— Mike Schroll

Innanzitutto, visiterei il sito Web dell'assistenza Samsung e assicurerei che hai installato l'ultimo firmware per il tuo SSD modello.

Quindi, il tuo fsck non aveva molto senso, quindi fallo in questo modo ...

Per controllare il file system sulla tua partizione Ubuntu ...

avvia il menu di GRUB
scegli Opzioni avanzate
scegli la modalità di recupero
scegli Accesso root
al prompt #, digitare sudo fsck -f /
ripetere il comando fsck in caso di errori
genere reboot

— heynnema
fonte

Grazie per la risposta! Ho reinstallato, ma questa volta ho formattato in modo esplicito prima la partizione del problema (nel caso in cui il processo di reinstallazione predefinito in realtà non sia stato formattato). Spero che sia OK ora, tuttavia se il problema persiste eseguirò un fsck e pubblicherò i risultati (anche se direi che se il problema persiste su una partizione appena formattata, potrebbe essere al di là delle capacità di fsck)

— Ben B

Il problema si è verificato di nuovo, tuttavia, come sottolineato dall'anziano Geek nei commenti sotto la mia domanda, sembra essere dovuto a un bug noto ( bugs.launchpad.net/ubuntu/+source/linux/+bug/1678184 ).

— Ben B,

@BenB hai mai controllato il firmware nel tuo SSD Samsung, come avevo suggerito in precedenza? A seconda del modello, avevano alcuni aggiornamenti molto obbligatori per far funzionare correttamente l'unità.

— heynnema,

In realtà non sono sicuro al 100% su come farlo. Ho trovato un po 'di firmware qui, tuttavia non sono sicuro al 100% che nessuno di questi si applichi al mio SSD specifico. La segnalazione di bug non indica comunque alcun problema relativo al firmware, quindi a questo punto preferirei attendere maggiori informazioni dagli sviluppatori che affrontano il bug prima di provare ad aggiornare il firmware (conoscendomi, lo farei male e perdere tutte le mie cose: P).

— Ben B

fsck non mostra errori. Il problema non è alcun tipo di problema firmware o corruzione SSD. È dovuto ad APST, che è stato abilitato in 17.04. L'impostazione del parametro del kernel 'nvme_core.default_ps_max_latency_us = 5500' ha risolto il problema per me e altri hanno riferito che la disabilitazione di APST lo risolve del tutto per loro.

— Ben B

Una possibile soluzione al bug noto che ho citato e che non sono in grado di testare perché non ho l'hardware NVMe in questione sarebbe quella di provare ad avviare l'attuale pacchetto di build del kernel mainline per la tua archetecture disponibile qui.

Aspettare! prima di partire per provare questo, devo sottolineare che, a meno che non si sia certi di sapere esattamente cosa si sta facendo e come recuperare da conseguenze indesiderate, si consiglia vivamente di eseguire il backup.

Se non sai cosa stai facendo e disponi di un backup corrente, puoi trovare ulteriori informazioni sulla creazione del kernel qui.

Nota: se hai scremato la prima frase, questa risposta si basa sulla ricerca, non sui test. Se si interrompe, ripristinare il backup.

— Anziano Geek
fonte