[Résolu] Rédemarrage après Win10: invalid superblock system

Bonjour à tous,

pour tester mon nouveau clavier, avec lequel j’ai quelques problèmes (cf. https://www.debian-fr.org/t/rates-clavier-sans-fils/73877 ), j’ai redémarré sous Window 10.
Il était installé à l’origine et je l’utilise si peu que j’avais oublié que les dernières fois m’a causé des problèmes.

Avant tout, je m’excuse car je ne sais pas où récupérer les logs concernants le dernier kernel panic.
J’ai cherché dans le dossier /var/log, mais ils affichent un vide entre 17.13 et 17.30 (le temps du redémarrage).
Bref, la situation est la suivante:
je redémarre l’ordi sous Win10. Grub marche à merveille, Win10 aussi.
J’éteigne l’ordi et je redémarre, comme d’habitude, sous Debian.

Je reçois un erreur disque, comme quoi il faut corriger certains secteurs (j’essaye de m’en souvenir, je n’ai pas pris de photo et j’ignore comment trouver les logs relatifs au problème).
Si je tape exit dans la console, je reçoit un kernel panic.
Si je tape e2fsk /dev/sda3 (mon fichier racine), il me propose de corriger (fix) des secteurs le filesystem.
Puis ça redémarre normalement.

J’ai fait un test SMART sur le disque et les valeurs sont normales, selon lui, le disque se porte bien.
En effet, je n’ai jamais remarqué de problèmes.

Mon kernel est :

Je ne sais pas quels autres éléments pourraient être utiles.
N’hésitez pas à me demander des logs (en me disant où est ce qu’ils se cachent !) ou d’autres informations qui pourraient être utiles.

Un gros merci pour le support.

Bonjour,
quelques conseils ?
Ici ( Quels logs pour un kernel panic ? ) on pose la question des logs pour un kernel panic, mais honnêtement la solution m’échappe…
Merci

Un conseil si tu n’as pas une mémoire photographique : débrouille-toi pour fixer les messages d’erreur complets et exacts par quelque moyen à ta disposition : capture d’écran, photo, logs, recopie à la main s’il le faut…

Normal si cette erreur s’est produite dans l’initramfs, alors que la racine n’était pas encore montée puisque les logs se trouvent dans la racine ou dans la partition /var qui est montée encore plus tard, et le service qui enregistre les logs n’est pas encore démarré.

Il faut récupérer les logs du noyau dans le tampon mémoire avec la commande dmesg, et éventuellement les enregistrer dans un fichier sur au autre système de fichiers (clé USB, autre partition non endommagée…) qu’il faudra monter préalablement.

Il existe de nombreuses causes de kernel panic et une recherche avec ces seuls mots a peu de chance de te conduire vers la réponse.
Si l’erreur est
Kernel panic - not syncing : VFS: Unable to mount root fs
alors la cause est que le système de fichiers racine n’a pas pu être monté, par exemple à cause des erreurs qu’il contient.

“Corriger des secteurs”, vraiment ? Ça m’étonnerait. e2fsck ne corrige pas les secteurs (d’ailleurs il ne parle jamais de secteurs), il ne peut que détecter les blocs défectueux et les marquer comme inutilisables, à condition d’utiliser l’option -c.

Merci pour la réponse.
Désolée pour le flou et les imprécisions dans mes explications.
Tu as tout à fait raison, c’est impossible de résoudre les problèmes si on a pas les erreurs exacts.

Comme j’ai un peu de temps, je vais redémarrer sous Win et ensuite recopier exactement ce que l’écran affiche.
J’ai juste peur que e2fsck ne réussisse pas cette fois à fixer les erreurs qui empêchent le démarrage…je vais faire un bon backup avant !
À bientôt avec des informations plus détaillées.
Merci

Bonsoir,

J’ai un Windows 10 natif, en dual boot, que je n’utilise pratiquement jamais (je préfère utiliser ma VM Windows 10 qui ne m’oblige pas à stopper Linux).
Récemment, pour mettre à jour, je démarre sous Windows 10 puis arrête l’ordinateur pour la nuit
Le lendemain, au boot sous Linux (Jessie 64) , plein de problèmes et impossible de redémarrer Linux.
Une recherche Internet me met sur la piste:

. L’arrêt de W10 ne serait pas un vrai arrêt, mais plutôt une sorte d’hibernation (pour redémarrer plus vite).
. Le système de fichier NTFS n’est pas “démonté”.

  • En cas de montage automatique au boot de Linux, celui-ci n’arrive pas à monter le système de fichier NTFS (qui lui semble corrompu).

SOLUTION:

  • Redémarrer sous Windows 10.
  • Demander le redémarrage (et non pas l’arrêt).
  • Au boot, dans le menu de Grub (si pas automatique), choisir Linux.

Sylvain

@spourre : Ce problème avec le “démarrage rapide” de Windows 8+ est bien connu et n’affecte que les partitions de Windows, pas les partition de Linux.
A moins que @guayaki ait monté la partition racine de Linux sous Windows, rien à voir avec son problème.

J’ai bien précisé que le problème vient d’un système de fichier NTFS mal démonté. Je ne connais pas un linuxien assez maso pour mettre son boot ou son / sur un tel FS.
Pour en avoir le coeur net j’ai:

  • relu les posts du PO
  • refait la manip.

Les posts du PO ne permettent pas de se faiore une idée exacte du problème , les messages d’erreur ne sont pas donnés et le vocabulaire imprécis peut être celui d’un débutant (non péjoratif).

La séquence boot Windows 10, arrêt Windows 10 et boot Linux, reproduit le même phénomène chez moi:
passage automatique au mode console rescue et non lancement de Linux :slight_smile:

Je précise que j’ai 2 partitions NTFS montées automatiquement sous Linux, comme partitions d’échange avec Windows 10.

Le reboot par Windows puis Linux, comme décrit dans mon premier message, résoud bien le problème.

Sylvain

Merci à tous pour les réponses.
Le fait de vouloir vous présenter le problème plus clairement, m’a énormément aidé à mieux cerner le dysfonctionnement.
Je vous explique par étape.

  1. J’ai redémarré sous Win, puis redémarré avec Debian : aucun problème ;
  2. j’ai rébooté sous Win, éteint l’ordi et ré-allumé sous Debian : aucun souci.

J’ai donc relu vos messages.
Et bien, non, je n’ai pas monté / (au aucune autre directory linux) sur une partition NTFS.
D’ailleurs, au passage, la table des partitions :

[code] sudo fdisk -l
[sudo] password di tarmac:
Disk /dev/sdb: 465,8 GiB, 500107862016 bytes, 976773168 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: dos
Disk identifier: 0xb5a9455a

Device Boot Start End Sectors Size Id Type
/dev/sdb1 2048 372133887 372131840 177,5G 7 HPFS/NTFS/exFAT
/dev/sdb2 382853118 976771071 593917954 283,2G 5 Extended
/dev/sdb3 372133888 382851071 10717184 5,1G 82 Linux swap / Solaris
/dev/sdb5 382853120 976771071 593917952 283,2G 83 Linux

Partition table entries are not in disk order.

Disk /dev/sda: 58,7 GiB, 63023063040 bytes, 123091920 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: dos
Disk identifier: 0x5d3ae453

Device Boot Start End Sectors Size Id Type
/dev/sda1 2048 1026047 1024000 500M 7 HPFS/NTFS/exFAT
/dev/sda2 1026048 80080895 79054848 37,7G 7 HPFS/NTFS/exFAT
/dev/sda3 * 80080896 123090943 43010048 20,5G 83 Linux

Disk /dev/sdc: 465,7 GiB, 500074283008 bytes, 976707584 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: B76C337C-E8AE-4C78-9C00-4FB2809FCADC

Device Start End Sectors Size Type
/dev/sdc1 2048 976705535 976703488 465,7G Microsoft basic data
[/code]
Pourtant, ça m’arrive de monter les partitions linux (spécialement /home) pendant que j’utilise Windows (je sais…c’est mal ! mais j’utilise si rarement Windows que je n’ai pas assez de place pour créer un disque partagé) avec l’outil conseillé par le tuto d’ubuntu (https://doc.ubuntu-fr.org/tutoriel/comment_acceder_a_ses_partitions_d_ubuntu_sous_windows ) Ext2fsd (d’ailleurs, je n’ai pas le bug signalé).
Eh bien, le problème se présente quand je l’utilise.
En quoi consiste-t-il ?
Dans l’avertissement, au démarrage de Debian suivant l’utilisation de Windows :

Si donc j’exécute e2fsck sur la partition /dev/sda3, il me communique que, en effet, “Superblock checksum does not match superblock, Superblock invalid, trying backup blocks… /dev/sda3 was not cleany unmounted, check forced”.
Et il trouve que “Free blocks count wrong for group #0 (23542, counted=5551)” jusqu’au group 151.
J’accepte la réparation qu’il me propose et elle reussit:

Inode bitman differences : Group 0 inode bitman does not match checksum. FIXED. <block bitman differences: Group 0 block bitman does not match checksum. FIXED. /dev/sda3: ***** FILE SYSTEM WAS MODIFIED ****

En effet, il a l’air d’être un problème connu de ext2fsd. Ici on lit
que plusieurs personnes ont le même souci.
, ils proposent comme solution la désinstallation de ext2fsd.

Ah, juste pour la précision, si je tape “exit” dans la consolle après le message de réussite de e2fsck, j’ai un kernel panic (photo sur demande).

Donc, je peux dire d’avoir résolu ? Je dois abandonner l’idée d’accéder à Debian depuis Windows ? Avez vous des conseils en matière ?

En tout cas, milles merci. La demande de rigueur pour la présentation du problème a fourni, d’elle-même, la “solution”.

À bientôt

En fait, je vais mettre résolu.
Ce n’est pas du tout la faute de Debian si les systèmes propriétaires ne veulent pas développer des outils fiables pour accéder à des FS tels que ext2/3/4.
Ce n’est pas un dysfonctionnement côté gnu/pingouin !
Donc, j’accueille quand même volontiers vos conseils, mais je considère inutile, voire nuisible, pour une plateforme libre de perdre du temps et de l’argent à héberger des suggestions pour améliorer le fonctionnement d’un système fermé et propriétaire, bien que cela puisse surement contribuer à la diffusion de GNU/Linux sous prétexte d’une meilleure intégration avec les systèmes “prédominants”. D’ailleurs, dans le lien précédemment cité, ils expliquent comment faire sur Windows pour qu’il unmount correctement le disque. Bref, ici on verra les problèmes de notre chère Debian, désolé pour ce post.
Ça m’apprendra à bien écrire le prochain et, comme ça m’est déjà arrivé, trouver la solution sans même besoin de poster.
Un merci à tous

Ce n’est pas à cela que je pensais. D’ailleurs je doute qu’il soit possible de mettre la racine en NTFS car ce système de fichiers ne permet pas de gérer convenablement les permissions Unix . Quant à /boot, il pourrait très bien être en NTFS et l’impossibilité de le monter ne provoquerait pas un kernel panic.

Non, je pensais plutôt à ça :

Je n’ai mentionné ce cas particulier que pour être complet et considérais cette éventualité comme très improbable, mais il semble que ce soit bien la cause du problème.

Ce n’est pas non plus la faute de Microsoft si ext2fsd est buggé avec ext4.

Soyons clair : même si Windows pouvait supporter parfaitement ext4, jamais je ne le laisserais toucher aux partitions de Linux. J’aime autant qu’il ne sache pas les lire et encore moins y écrire.

Merci pour la clarté de tes réponses.

En effet, je n’ai pas pensé à mentionner lors du premier post l’utilisation du logiciel en question (en vrai, j’y ai pensé qu’en voyant d’autres personnes avec le même erreur)

En vrai j’avais déjà eu la mauvaise idée de monter ma /home ext4 avec ext2fsd sur Win7 et il n’y avait pas eu de problème (le bug concerne les 64bit uniquement)…Ça arrive à bien d’autres projets open-source d’avoir des bugs, peut-être celui-ci aussi il va être résolu (d’ailleurs, je ne remarque que maintenait qu’il y a un ticket d’ouvert en signalant le bug :flushed: https://sourceforge.net/p/ext2fsd/bugs/163/ )

Je crois bien que je vais renoncer à l’accès à Debian (qu’en vrai devrait être read-only, selon les paramètres que j’avais donné à ext2fsd) à partir de Windows, il me semble moins pratique, mais largement plus sûr !

Merci

Bonjour, je m’excuse, mais je déterre le topic car le problème n’a pas été résolu avec la suppression de etx2fsd (je n’avais plus utilisé Windows depuis…).

Malheureusement, actuellement, je suis obligée à utiliser des logiciels propriétaires pour des raisons professionnelles, et, à chaque redémarrage après avoir lancé Windows, j’ai une erreur d’invalid superblock system.

Des idées ? Ou, à défaut, des renseignement sur les dangers pour le disque et les données ?

Un grand merci