Corruption de disque Razer Blade Stealth (fsck nécessaire, probablement un bogue de samsung SSD) après les mises à jour
J'ai une Razer Blade Stealth 2016. Le premier Ubuntu que j'ai installé était Ubuntu 17.04, ce qui a provoqué cette erreur après deux semaines d'utilisation. Après cela, j'ai installé 16.04 et je l’utilise pendant mois sans aucun problème , jusqu’à ce qu’il produise la même erreur aujourd’hui. Je pense que cela a à voir avec les mises à jour d'ubuntu, car j'en ai fait une récemment et une aujourd'hui, juste avant ce problème. Pourrait être une coïncidence si.
(j'ai même fait quelques tests de résistance, en téléchargeant des centaines de gb de données et en ayant mon disque presque plein, et je n'ai eu aucune de ces erreurs alors que dans 16.04 sans mises à jour)
Après avoir exécuté fsck manuellement, le problème est résolu, mais il se reproduit après un certain temps.
Il y a des choses qui se passent dans l'installation (les 16.04, 17.04 et 17.10.1) qui méritent d'être mentionnées:
Si j'essaie de choisir l'option de chiffrement de mon disque, l'installation échoue toujours dans les 1 ou 2 prochains écrans en disant quelque chose à propos de l'erreur d'ubiquité (que j'ai déjà souvent signalée). Je dois l'installer sans aucune personnalisation. Cela se produit pour toutes les versions que j'ai essayées: 16.04, 17.04, 17.10.1.
J'ai installé à nouveau 17.0.1 et immédiatement appliqué les mises à jour et redémarré l'ordinateur. Cela m'a donné l'erreur: mon disque est entré en mode lecture seule.
J'ai ensuite réinstallé 17.10.1 mais je ne vais pas appliquer les mises à jour pour l'instant. Pour l'instant je n'ai pas le problème dans ma machine, mais quand j'essaye d'installer une nouvelle machine virtuelle, une erreur d'entrée/sortie de disque se produit dans la machine virtuelle. Dans la machine hôte, il n'y a pas de tel problème.
Comment puis-je aller à la racine de ce problème? C'est très énervant, je dois tout recommencer quand cela se produit.
J'ai trouvé ceci: Problèmes de corruption de disque après la mise à niveau vers Ubuntu 17.04 qui relie cette question: erreur EXT4-fs après la mise à niveau vers Ubuntu 17.04 qui renvoie à ce bogue: https: //bugs.launchpad.net/ubuntu/+source/linux/+bug/1678184 qui s'applique aux SSD de Samsung, ce qui est mon cas . Et c'est aussi lié aux mises à jour d'ubuntu.
Mon hypothèse est que ce qui a fait que mon ordinateur portable ne fonctionne pas correctement était dans 17.04, c'est pourquoi il a bien fonctionné jusqu'à ce jour lorsque j'ai appliqué une mise à jour pour mon 16.04 qui comportait probablement cette nouvelle fonctionnalité.
J'ai peut-être trouvé le problème, mais je poste ceci pour écouter les choses à essayer, pour aider d'autres personnes avec le même cahier (j'ai bien étiqueté le titre pour qu'elles puissent le trouver), et pour attirer l'attention, car cela pourrait être passe pour de nombreux ordinateurs portables avec ce SSD.
update : Je suis confus, car le rapport de bogue indique que le bogue a été corrigé. Je ne devrais donc pas rencontrer ce problème avec 17.10.1, devrais-je?
UPDATE:
C'est arrivé à nouveau (avec la nouvelle installation 17.10.1 sans mises à jour que j'utilisais depuis le jour où j'ai commencé ce post. J'ai remarqué le problème parce que j'ai essayé de sauvegarder l'un de mes ordinateurs virtuels sur un disque et que mon disque était en lecture seule. Puis j'ai couru:
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"
J'ai ensuite redémarré et fait fsck /dev/nvm.... Il m'a posé des questions sur de nombreux inodes, j'ai répondu "oui" à tous et à un moment, cela s'est arrêté.
https://imgur.com/a/cfbPD (cette photo montre l'intégralité de la sortie, mais elle n'est pas très visible) https://imgur.com/a/VFoPB ( celui-ci est meilleur mais il coupe un peu de la sortie)
Voici une vidéo de l'ensemble du processus: https://photos.app.goo.gl/8ZHF3Un1BOsRwjaz1
(désolé pour la qualité, j'ai dû filmer sur mon ancien téléphone portable car le nouveau attend un nouvel écran)
Je vais appliquer le correctif du microcode comme le suggère la réponse ci-dessous, mais je ne pense pas que cela ait à voir avec le problème, car cela se produit des mois avant la fusion et le spectre. Et je n’avais même jamais installé de mise à jour de microcode.
Je pense toujours que cela a à voir avec le problème que j'ai décrit dans mon post. Est-ce que quelqu'un peut me donner des détails sur si cela a été corrigé, dans quels noyaux il est fixé? Que devrais-je faire?
Quoi qu'il en soit, je viens d'appliquer la correction suggérée d'ajouter
nvme_core.default_ps_max_latency_us=5500
aux paramètres de démarrage. Va voir comment le système se comporte avec.
UPDATE: chaque fois que j'installe un nouveau système, il se comporte bien jusqu'à ce que je décide d'utiliser le programme de mise à jour du logiciel! Ensuite, il entre en mode lecture seule :(
J'ai essayé avec nvme_core.default_ps_max_latency_us=250 et cela n'a pas fonctionné
UPDATE: tout semble bien fonctionner lorsque j'installe Windows. Même les tests d'évaluation indiquent que tout va bien
Intel Microcode 2018-01-08 casse certains systèmes
Lorsque les failles de sécurité mondialement connues de Meltdown et Specter ont été annoncées au début de 2018, les fournisseurs se sont précipités avec des correctifs. Selon Ubuntu, Intel leur a demandé de revenir à un microcode ancien alors que le Mise à jour du microcode du 8 janvier 2018 a cassé certains systèmes.
Lister votre version actuelle du microcode
Pour trouver votre version actuelle du microcode, utilisez:
$ apt list --installed | grep intel-microcode
WARNING: apt does not have a stable CLI interface. Use with caution in scripts.
intel-microcode/now 3.20170707.1~ubuntu16.04.0 AMD64 [installed,upgradable to: 3.20180108.0+really20170707ubuntu16.04.1]
Dans mon cas, la mise à jour d'Intel Microcode pour 2018-01-08 n'est pas utilisée et et la version d'origine de 2017-07-07 est utilisée. Lorsque des correctifs pour Meltdown ont été annoncés, des bogues ont commencé à apparaître sur des mises à jour régulières le 2018-01-04. Depuis lors, j'ai refusé toutes les mises à jour automatiques au profit de l'installation manuelle de nouveaux noyaux principaux. C'est pourquoi j'ai l'ancien microcode original.
Déclassement du microcode pour Ubuntu 14.04, 16.04 et 17.10
Si vous exécutez 2018-01-08 Intel Microcode, vous DEVEZ le mettre à niveau vers la version publiée le 2018-01-22.
Le problème peut être corrigé en mettant à jour votre système avec la version de package suivante:
Ubuntu 17.10:
Ubuntu 16.04 LTS:
Ubuntu 14.04 LTS:
Pour mettre à jour votre système, suivez ces instructions: https://wiki.ubuntu.com/Security/Upgrades .
Après une mise à jour système standard, vous devez redémarrer votre ordinateur pour effectuer toutes les modifications nécessaires.
Répétez les étapes de la section précédente pour vérifier la version de votre microcode Intel
Installer le microcode à partir du terminal
Pour installer Microcode à partir d'un terminal sans passer par les panneaux de configuration de l'interface graphique Ubuntu, utilisez:
Sudo apt update
Sudo apt install intel-microcode