Eu tenho um Razer Blade Stealth 2016. O primeiro Ubuntu que eu instalei foi o Ubuntu 17.04, que deu esse erro após 2 semanas de uso. Depois disso, eu instalei o 16.04 e o usei por meses sem problemas , até que ele produzisse o mesmo erro hoje. Eu acho que tem a ver com as atualizações do ubuntu, porque eu fiz um recentemente e um hoje, pouco antes deste problema. Poderia ser uma coincidência embora.
(Eu até fiz alguns testes de estresse, baixando centenas de GB de dados várias vezes, e tendo meu disco quase cheio, e não tive nenhum desses erros enquanto estava em 16.04 sem atualizações)
Depois de executar o fsck manualmente, ele resolve o problema, mas isso acontece novamente depois de algum tempo.
Existem algumas coisas que acontecem na instalação (16.04, 17.04 e 17.10.1) que valem a pena mencionar:
Se eu tentar escolher a opção para criptografar meu disco, a instalação sempre falhará nas próximas 1 ou 2 telas dizendo algo sobre erro de ubiquidade (que já relatei várias vezes). Eu tenho que instalá-lo sem nenhuma personalização. Isso acontece para todas as versões que eu tentei: 16.04, 17.04, 17.10.1.
Instalei o 17.0.1 novamente e imediatamente apliquei atualizações e reiniciei o computador. Isso me deu o erro: meu disco entrou no modo somente leitura.
Eu então reinstalei o 17.10.1, mas não vou aplicar as atualizações por enquanto. Por enquanto não tenho o problema em minha máquina, mas quando tento instalar uma nova máquina virtual, ocorre um erro de entrada / saída do disco na máquina virtual. Na máquina host, não há tal problema.
Como posso chegar à raiz deste problema? É muito chato, eu tenho que começar tudo de novo quando isso acontecer.
Eu encontrei isto: Problemas de Corrupção de Disco após o upgrade do Ubuntu 17.04 que liga esta questão: erro EXT4-fs após Atualização do Ubuntu 17.04 que leva a esse bug: link que se aplica a < SSDs strongs> samsung, que é o meu caso . E também está relacionado a upgrades do Ubuntu.
Meu palpite é que a coisa que fez meu disco de laptop dar errado foi em 17.04, então é por isso que funcionou bem para mim até hoje quando eu apliquei uma atualização para o meu 16.04 que provavelmente tinha esse novo recurso que causa esse bug.
Eu posso ter encontrado o problema, mas estou postando isso para ouvir possíveis coisas para tentar ajudar outras pessoas com o mesmo caderno (eu marquei o título para eles acharem isso), e para chamar atenção, porque Isso pode estar acontecendo para muitos notebooks com este SSD.
update : Eu me sinto confuso porque no relatório de bug ele diz que o bug foi corrigido, então eu não deveria estar passando por esse problema com 17.10.1, devo?
ATUALIZAÇÃO:
Aconteceu de novo (com a nova instalação do 17.10.1 sem atualizações que estava usando desde o dia em que iniciei este post. Percebi o problema porque tentei salvar uma das minhas VMs no disco e ele disse que meu disco foi somente para leitura. Então eu corri:
lz@lz:/var/log$ touch something
touch: cannot touch 'something': Read-only file system
lz@lz:/var/log$ cat syslog
Jan 29 01:07:39 lz kernel: [62984.375393] EXT4-fs error (device nvme0n1p2): ext4_find_entry:1442: inode #26607929: comm updatedb.mlocat: checksumming directory block 0
lz@lz:/var/log$ dmesg
[62984.375393] EXT4-fs error (device nvme0n1p2): ext4_find_entry:1442: inode #26607929: comm updatedb.mlocat: checksumming directory block 0
[62984.377374] Aborting journal on device nvme0n1p2-8.
[62984.379343] EXT4-fs (nvme0n1p2): Remounting filesystem read-only
[62984.379516] EXT4-fs error (device nvme0n1p2): ext4_find_entry:1442: inode #26607929: comm updatedb.mlocat: checksumming directory block 0
[62984.381486] EXT4-fs error (device nvme0n1p2): ext4_find_entry:1442: inode #26607929: comm updatedb.mlocat: checksumming directory block 0
[62984.383484] EXT4-fs error (device nvme0n1p2): ext4_find_entry:1442: inode #26607929: comm updatedb.mlocat: checksumming directory block 0
[62984.385469] EXT4-fs error (device nvme0n1p2): ext4_find_entry:1442: inode #26607929: comm updatedb.mlocat: checksumming directory block 0
[62984.387278] EXT4-fs error (device nvme0n1p2): ext4_find_entry:1442: inode #26607929: comm updatedb.mlocat: checksumming directory block 0
[62984.389262] EXT4-fs error (device nvme0n1p2): ext4_find_entry:1442: inode #26607929: comm updatedb.mlocat: checksumming directory block 0
[62984.391252] EXT4-fs error (device nvme0n1p2): ext4_find_entry:1442: inode #26607929: comm updatedb.mlocat: checksumming directory block 0
[62984.393341] EXT4-fs error (device nvme0n1p2): ext4_find_entry:1442: inode #26607929: comm updatedb.mlocat: checksumming directory block 0
[63285.618078] audit: type=1400 audit(1517195560.393:63): apparmor="DENIED" operation="capable" profile="/usr/sbin/cupsd" pid=22495 comm="cupsd" capability=12 capname="net_admin"
Eu reiniciei e fiz fsck /dev/nvm... . Ele me perguntou sobre muitos inodes, eu fiz 'sim' para todos, e no momento parou.
link (esta foto mostra toda a saída, mas não é muito visível)
link (este é melhor, mas corta um pouco a saída)
Aqui está um vídeo de todo o processo:
link
(desculpe pela qualidade, eu tive que filmar no meu celular mais antigo, já que o novo está esperando que uma nova tela chegue)
Vou aplicar o patch de microcódigo como a resposta abaixo sugere, mas não acho que tenha a ver com o problema, já que isso está acontecendo meses antes do colapso e do espectro. E eu nunca havia instalado uma atualização de microcódigo.
Eu ainda acho que tem a ver com o problema que descrevi no meu post. Alguém pode me dar detalhes sobre se foi corrigido, em quais núcleos ele é consertado? O que devo fazer?
De qualquer forma, acabei de aplicar a correção sugerida para adicionar
nvme_core.default_ps_max_latency_us=5500
para os parâmetros de inicialização. Indo ver como o sistema se comporta com ele.
UPDATE: toda vez que eu instalo um novo sistema, ele se comporta bem até eu decidir usar o atualizador de software! Em seguida, ele entra no modo somente leitura: (
Eu tentei com nvme_core.default_ps_max_latency_us=250 e não funcionou
UPDATE : tudo parece funcionar corretamente quando instalo o Windows. Até os testes de benchmark dizem que tudo está bem