Erreur EXT4-fs après la mise à niveau de Ubuntu 17.04
J'ai un Dell XPS 15 9550 . J'utilise Ubuntu 16.10 depuis quatre mois sans drames.
Il y a deux jours, je suis passé à Ubuntu 17.04 . Environ une heure après la mise à niveau, mon disque dur a été remonté en mode lecture seule. Lorsque j'ai sauté sur un écran tty, ceci est apparu:
[ 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
Voici ce que fdisk -l montre:
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.
J'ai redémarré et j'ai continué à avoir l'erreur environ une fois par heure. Donc j'ai réinstallé Ubuntu 17.04 à partir de zéro . Cependant, je suis toujours en train de recevoir le même problème.
J'ai essayé d'exécuter fsck en créant un fichier/forcefsck (j'ai créé un script shell wrapper qui ajoute l'indicateur -v et génère la sortie standard dans un fichier). Voici le résultat:
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
J'ai essayé de démarrer à partir d'une clé USB réelle et d'exécuter e2fsck -p /dev/nvme0n1p7 comme suggéré ici ( https://askubuntu.com/a/768813/679041 ). Cela n'a donné aucune erreur.
J'ai également essayé d'exécuter smartctl -t long /dev/nvme0n1p7 mais les résultats semblent indiquer que l'outil ne fonctionne pas avec mon SSD particulier:
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
Avez-vous une idée de la cause de ce problème et de la façon dont je pourrais le résoudre? Merci! :)
Comme indiqué dans n commentaire de frère Geek , cela est dû à un bogue conn .
Depuis le rapport de bug:
Le support APST vient d'arriver dans le dernier noyau Zesty (4.10.0-14.16) dans le cadre de https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1664602 . Ce correctif a une particularité pour certains disques Samsung de 256 Go trouvés dans les ordinateurs portables Dell qui ne se comportent pas bien lorsque APST est activé. J'éprouve les mêmes symptômes avec le même modèle d'ordinateur portable, à l'exception d'un Samsung 512 Go. Avant de désactiver manuellement APST, le lecteur mourrait et le système s'effondrerait avec des erreurs d'E/S dans les 20 à 40 minutes suivant le démarrage.
Jusqu'à ce qu'un correctif correct soit implémenté, une solution de contournement est suggérée, qui implique l'ajout d'un paramètre de noyau :
S'il vous plaît essayez
nvme_core.default_ps_max_latency_us=5500, si le problème persiste, s'il vous plaît essayeznvme_core.default_ps_max_latency_us=200.
Pour ajouter un paramètre de démarrage du noyau, éditez le fichier de configuration pour GRUB:
Sudo nano /etc/default/grub
Recherchez la ligne commençant par GRUB_CMDLINE_LINUX_DEFAULT et ajoutez le paramètre de démarrage aux autres déjà entre guillemets. Par exemple, dans ce cas, vous allez probablement vous retrouver avec
GRUB_CMDLINE_LINUX_DEFAULT="quiet splash nvme_core.default_ps_max_latency_us=5500"
Enregistrez le fichier et quittez-le, puis exécutez
Sudo update-grub
Tout d’abord, consultez le site Web d’assistance Samsung et assurez-vous que vous disposez du dernier micrologiciel installé pour votre modèle de disque SSD.
Ensuite, votre fsck n'avait pas beaucoup de sens, alors faites-le comme ça ...
Pour vérifier le système de fichiers sur votre partition Ubuntu ...
- démarrer dans le menu GRUB
- choisissez Options avancées
- choisissez le mode de récupération
- choisissez l'accès racine
- à l'invite #, tapez
Sudo fsck -f / - répéter la commande fsck s'il y avait des erreurs
- tapez
rebootname__
Une solution de contournement possible pour le bogue connu que j'ai mentionné et que je ne peux pas tester car je n'ai pas le matériel NVMe en question serait d'essayer de démarrer la version actuelle du noyau principal du réseau principal en cours. paquet pour votre architecture disponible ici.
Attendez! avant de vous lancer pour essayer ceci, je dois souligner que, sauf si vous êtes certain vous savez exactement ce que vous faites et comment récupérer des conséquences inattendues, il est fortement recommandé de sauvegarder.
Si vous ne savez pas ce que vous faites et avez une sauvegarde en cours, vous pouvez trouver plus d'informations sur la construction de votre noyau ici.
Remarque: Si vous écrivez la première phrase, cette réponse est basée sur des recherches et non sur des tests. Si cela se produit, restaurez votre sauvegarde.