Erro EXT4-fs após a atualização do Ubuntu 17.04

Eu tenho um Dell XPS 15 9550 . Estou executando o Ubuntu 16.10 nele há quatro meses, sem dramas.

Dois dias atrás, atualizei para o Ubuntu 17.04 . Cerca de uma hora após a atualização, meu disco rígido voltou ao modo somente leitura. Quando pulei para uma tela tty, isso apareceu:

[ 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

Aqui está o que 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.

Reiniciei e continuei a obter o erro uma vez por hora. Então eu reinstalei o Ubuntu 17.04 a partir do zero . No entanto, ainda estou recebendo o mesmo problema.

Tentei executar o fsck criando um arquivo / forcefsck (criei um script shell do wrapper que adiciona o -vsinalizador e gera stdout a um arquivo). Aqui está o resultado:

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

Tentei inicializar a partir de um USB ativo e executando e2fsck -p /dev/nvme0n1p7como sugerido aqui ( /ubuntu//a/768813/679041 ). Não deu nenhum erro.

Também tentei executar, smartctl -t long /dev/nvme0n1p7no entanto, os resultados parecem indicar que a ferramenta não funciona com meu SSD específico:

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

Alguma idéia de por que esse problema pode estar ocorrendo e como posso resolvê-lo? Obrigado! :)

filesystem ext4 17.04

— Ben B
fonte

Bem-vindo ao AskUbuntu! Parece que você pode ser afetado por esse bug . Recomendo que você informe aos desenvolvedores que esse bug também afeta você e assine o bug para que você possa ser notificado sobre o andamento / resolução.

— Elder Geek

Estou tendo exatamente o mesmo problema em um Lenovo Thinkpad X270 com um SSD Toshiba "THNSF5256GPUK TOSHIBA". Eu acho que é bom saber que eu não sou o único.

— Maeher 18/04

O @ElderGeek, lendo o relatório de bug vinculado, parece que até que o problema seja corrigido, uma correção temporária seria desativar o APST, no entanto, a partir da discussão lá, não está claro para mim como fazer isso. Parece que uma maneira de fazer isso seria uma resposta válida para essa pergunta.

— Maeher 18/04

Obrigado por seus comentários pessoal :) Impacientemente, eu reinstalei novamente ontem à noite, mas desta vez eu formatei explicitamente / dev / nvme0n1p7 e excluí / dev / nvme0n1p8 de antemão (eu pensei que talvez uma reinstalação com todas as opções padrão possa não ser realmente formatada e, em vez disso, exclua apenas arquivos antigos antes de instalar novos). Ainda estou enfrentando o problema após 4 horas de uso ininterrupto, mas apenas o tempo dirá. Você vai ouvir meus soluços através do Pacífico, se eu faço :)

— Ben B

OK, posso confirmar - acabei de receber o problema novamente, apesar de formatar completamente a partição. Adicionará comentário ao bug vinculado acima

— Ben B

Respostas:

Como apontado em um comentário do Elder Geek , isso ocorre devido a um bug conhecido .

No relatório de erros:

O suporte ao APST acabou de chegar ao kernel mais recente do Zesty (4.10.0-14.16) como parte do https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1664602 . Esse patch tem uma peculiaridade em certas unidades Samsung de 256 GB encontradas em laptops da Dell que não se comportam bem quando o APST está ativado. Estou enfrentando os mesmos sintomas com o mesmo modelo de laptop, exceto com um Samsung de 512 GB. Antes de desativar manualmente o APST, a unidade morria e o sistema entrava em chamas com erros de E / S dentro de 20 a 40 minutos após a inicialização.

Até que uma correção adequada seja implementada, é sugerida uma solução alternativa, que envolve a adição de um parâmetro do kernel :

Tente nvme_core.default_ps_max_latency_us=5500, se o problema persistir, tente nvme_core.default_ps_max_latency_us=200.

Para adicionar um parâmetro de inicialização do kernel, edite o arquivo de configuração do GRUB:

sudo nano /etc/default/grub

Encontre a linha de início GRUB_CMDLINE_LINUX_DEFAULTe adicione o parâmetro de inicialização aos outros já entre aspas. Por exemplo, nesse caso, você provavelmente terminará com

GRUB_CMDLINE_LINUX_DEFAULT="quiet splash nvme_core.default_ps_max_latency_us=5500"

Salve o arquivo e saia e, para efetivar a alteração, execute

sudo update-grub

— Ben B
fonte

Essa correção está funcionando para você? BTW um link sobre como configurar parâmetros do kernel para quem pode tropeçar em sua resposta wiki.ubuntu.com/Kernel/KernelBootParameters

— justmyfault

Estou executando o Ubuntu 16.04 e atualizo pacotes para o zesty, algo que eu não recomendaria a ninguém, a não ser por necessidade. O último pacote foi o libc, algo tão essencial ao sistema que, se algo desse errado, seria ao atualizar o libc. Na reinicialização, vi todos os erros do EXT4 mencionados na pergunta acima, mas adicionar o parâmetro kernel finalmente me permitiu reiniciar em paz e continuar. Obrigado.

— Lukecampbell 4/17

alguma atualização sobre isso? Estou sofrendo este problema na minha discrição lâmina razer com um SSD Samsung 512gb

— Lucas Zanella

A solução acima funcionou para mim, mas o bug foi corrigido no pacote linux - 4.10.0-22.24. Se você ainda estiver com problemas, abra um novo relatório de bug na barra de ativação.

— Ben B

Eu tentei os dois valores, mas ele ainda falhou. nvme_core.default_ps_max_latency_us = 0 funcionou para mim. Kernel 4.15.0-36-generic Ubuntu 16.04

— Mike Schroll

Primeiro, eu visitaria o site de suporte da Samsung e asseguraria que você tenha o firmware mais recente instalado para o seu SSD modelo.

Então, seu fsck não fazia muito sentido, faça assim ...

Para verificar o sistema de arquivos na sua partição Ubuntu ...

inicialize no menu GRUB
escolha Opções avançadas
escolha o modo de recuperação
escolha acesso root
no prompt #, digite sudo fsck -f /
repita o comando fsck se houver erros
tipo reboot

— heynnema
fonte

Obrigado pela sua resposta! Eu reinstalei, mas desta vez formatei explicitamente a partição do problema primeiro (caso o processo de reinstalação padrão não tenha sido formatado). Esperemos que isso é OK agora, no entanto, se os persiste problema que vai executar um fsck e postar os resultados (embora gostaria de dizer se os persiste problema em uma partição recém-formatado, pode ser além das capacidades do fsck)

— Ben B

O problema ocorreu novamente, no entanto, como apontado pelo Elder Geek nos comentários abaixo da minha pergunta, parece ser devido a um bug conhecido ( bugs.launchpad.net/ubuntu/+source/linux/+bug/1678184 ).

— Ben B

@BenB você já verificou o firmware no seu SSD Samsung, como sugeri anteriormente? Dependendo do modelo, eles tinham algumas atualizações muito obrigatórias para fazer a unidade funcionar corretamente.

— heynnema

Na verdade, não tenho 100% de certeza de como fazer isso. Encontrei algum firmware aqui, no entanto, não tenho 100% de certeza de que algum deles se aplique ao meu SSD específico. O relatório de bug não aponta para nenhum problema relacionado ao firmware, então, neste momento, prefiro esperar mais informações dos desenvolvedores que o corrigem antes de tentar atualizar o firmware (conhecendo-me, eu faria isso errado e perder todas as minhas coisas: P).

— Ben B

O fsck não mostra erros. O problema não é nenhum tipo de problema de firmware ou corrupção de SSD. É devido ao APST, que foi ativado em 17.04. Definir o parâmetro do kernel 'nvme_core.default_ps_max_latency_us = 5500' corrigiu o problema para mim, e outros relataram que a desativação do APST o corrige completamente para eles.

— Ben B

Uma possível solução alternativa para o bug conhecido que mencionei e que não consigo testar porque não tenho o hardware NVMe em questão seria tentar inicializar o atual pacote de compilação diária principal do kernel para sua arquitetura disponível aqui.

Esperar! Antes de você tentar fazer isso, devo enfatizar que, a menos que você tenha certeza de que sabe exatamente o que está fazendo e como se recuperar de consequências indesejadas, é altamente recomendável fazer backup.

Se você não sabe o que está fazendo e possui um backup atual, pode encontrar mais informações sobre como construir seu kernel aqui.

Nota: Caso você tenha percorrido a primeira frase, esta resposta é baseada em pesquisa, não em teste. Se quebrar, restaure seu backup.

— Elder Geek
fonte