Grub rescue (unknown filesystem)

Support Debian
#1

Salut,

Comme le titre l’indique, il s’agit d’un autre poste dû à un problème de boot. Mon problème est le suivant :
Très souvent (environ quatre fois sur cinq je dirais), lorsque je tente de démarrer mon PC, je me retrouve face au grub rescue affichant le message suivant : error: file ‘/grub/i386-pc/normal.mod’ not found

J’ai lu quelques post sur les forums qui parlent du même genre de problème, mais aucun d’eux ne semble correspondre exactement à ce que je recherche (ou du moins je ne l’ai pas trouvé).
Voila une photo de ce que ça donne quand je tente de "redefinir les variables prefixe et root (qui ne semble pas être bonnes) :
P_20180210_114846

Pour mettre un peu de contexte derrière cette erreur, je viens d’installer Debian sur un SSD que je vient d’ajouter à mon PC portable. Celui-ci dispose donc d’un DD qui me sert au stockage des données ( qui correspond au (hd0,msdo1) sur la photo ) et le SSD qui contient le système, avec le home sur une partition séparée. Le SSD et le DD sont tout deux formaté en ext4.

J’ai déjà essayé un grub_install /dev/sda sans que ça ne change quoi que ce soit

Petite précision, le système sembme cherche le fichier normal.mod dans /grub/i386-pc/ alors que le fichier est dans /boot/grub/i386-pc/

Voila, j’espère que vous pourrez m’aider :slight_smile:

#2

Note : ce GRUB a été installé sur le disque dur avec une partition /boot séparée. C’est peut-être le reste d’un ancienne installation.

Si tu as installé GRUB sur le SSD sans partition /boot séparée, alors il y a deux GRUB différents, et parfois c’est le mauvais qui est lancé. Il faut fixer le disque de boot dans le BIOS.

#3

Effectivement, j’ai installé le GRUB sur le SSD sans partition /boot séparée, mais je ne vois pas pourquoi ça implique qu’il y ai deux GRUB différents. Est-ce que tu pourrais éclairer ma lanterne ? :slight_smile:

Avant l’installation de mon SSD, mon précédent système était sur l’autre disque dur (forcement), mais je l’ai entièrement formaté avant d’installer mon nouveau système donc le précédent GRUB devrait avoir disparu, non ?

Sinon pour le disque de boot, j’avais déjà défini l’ordre de boot dans le BIOS (avec le SSD en tête), mais je ne vois pas comment faire mieux (et dans ces conditions le problème survient assez fréquemment).

Est-t-il possible de faire une partition /boot séparée sans avoir à tout réinstaller ? (sous entendu : si oui, comment ? Est-ce qu’il suffit que je de créer une partition, disons sda4, et de faire un grub-install /dev/sda4 ? je ne suis pas un expert dans le domaine :slight_smile: )

En tout cas merci de ta réponse !

#4

Le GRUB qui se lance (installé avec /boot séparé) ne peut pas être celui du SSD (installé sans /boot séparé), donc il y a forcément deux GRUB.

Non. La partie de GRUB qui se lance au démarrage et dont on voit l’affichage sur la photo se trouve en dehors des partitions et n’est pas supprimée par le formatage.

Regarde si tu peux carrément supprimer le disque dur de l’ordre de boot du BIOS et ne laisser que le SSD.

La question n’est pas là. Le /boot séparé ou pas était juste un indice pour confirmer qu’il y a bien deux GRUB différents.
Par contre en contournement tu peux réinstaller un autre exemplaire de GRUB dans le MBR du disque dur à la place de l’ancien GRUB afin de lancer le bon GRUB quel que soit le disque qui démarre. Si le disque dur est sdb (et le SSD sda) :

grub-install /dev/sdb
#5

Ok, je comprend mieux d’où viens le problème alors. Je ne trouve pas de manière de supprimer le disque dur de l’ordre de boot du BIOS (je chercherais un peu plus sérieusement plus tard, mais google ne semble pas donner de solution.

J’ai opté pour le
grub-install /dev/sdb

Mais au final, au lieu de réinstaller mon “bon” grub dans e MBR du disque dur, je peux pas supprimer l’ancien grub du MBR ?

#6

On ne peut pas juste supprimer l’amorce de GRUB du MBR. Il faudrait la remplacer par une autre amorce qui va rendre la main au BIOS qui va essayer d’amorcer le disque suivant.
J’ignore si le code amorce installé par install-mbr du paquet mbr se comporte ainsi quand aucune partition du disque n’est marquée amorçable, ou s’il se contente d’afficher un message d’erreur et de bloquer.

Certains BIOS considèrent (à tort) un disque comme amorçable seulement si une des partitions définies dans le MBR a le drapeau “boot”. Avec un tel BIOS, il suffit donc qu’aucune partition n’ait ce drapeau pour que le disque ne soit pas amorçable. Si aucune partition de ton disque n’a le drapeau boot, alors ton BIOS ne prend pas le drapeau des partitions en compte (ce qui est normal).

L’alternative, ce serait de supprimer la signature du MBR qui rend le disque amorçable. Mais cette signature indique aussi que le MBR contient une table de partition, donc la supprimer rendrait les partitions non visibles et il faudrait utiliser le disque non partitionné. Faisable s’il n’y avait qu’une partition ou avec LVM pour définir plusieurs volumes logiques remplaçant les partitions. Evidemment cela nécessiterait de sauvegarder et restaurer toutes les données du disque.

#7

Ok, merci pour tes explications, je vais en rester au grub-install /dev/sdb pour le moment !

Je reviendrais faire un point d’ici quelques jours histoire de voir si le problème est bien réglé.

#8

Très bien. Tiens-nous au courant.
C’est quand même curieux que le BIOS démarre sur le disque dur alors que le SSD est en premier dans l’ordre de boot.

Si c’est un problème de détection du SSD par le BIOS, alors normalement GRUB ne pourra pas afficher le menu et affichera une erreur lorsqu’il démarrera depuis le disque dur. Dans ce cas c’est peut-être une question de temporisation à régler dans le BIOS pour la détection des disques.

#9

Me revoilà pour les nouvelles. Le problème n’est pas réglé, mais il a évolué. Maintenant, au démarrage l’erreur n’est plus la même :
P_20180215_095242
sachant que l’UUID du “no such device” correspond à sda1, la partition de mon système

#10

Tiens donc, ne serait-ce pas ce que j’avais prédit ?
Peux-tu rapporter ce qu’affichent les commandes set et ls à cette invite ?
Quelque chose me dit qu’il n’y aura pas de hd1 dans la liste des volumes.

#11

Voilà les commandes que tu as demandé :
P_20180216_114651

Je ne sais pas si ça aide, mais j’ai l’impression que le problème ne survient que lors des démarrages “à froid”. Par exemple, hier soir j’ai essayé de redémarrer mon pc quelques fois après avoir vu ton message, mais il démarrait sans problème. En revanche, au premier démarrage, le problème survient presque systématiquement…

P.S. : le (hd0) est encore considéré comme “unknow filesystem”

#12

Comme prévu ls n’affiche que le disque de boot hd0 et sa partition, donc le BIOS n’a pas détecté le SSD. Cela collerait bien avec l’hypothèse du démarrage à froid. Comme je l’ai déjà suggéré, regarde dans les paramètres du BIOS s’il y a une option pour augmenter le délai de détection des disques.

(hd0) est partitionné donc il ne contient pas directement de système de fichiers. Les valeurs de $prefix et $root sont juste les valeurs par défaut car le système de fichiers recherché, qui devrait être sur (hd1), est introuvable.

#13

J’ai cherché dans le BIOS, mais celui-ci est très basique et je n’ai pas trouvé d’option pour le délai de détection des disques.
En revanche, j’ai essayé d’échangé mon SSD et mon disque dur de port SATA (donc au niveau materiel), en pensant qu’un des port était peut-être prioritaire, ou quelque chose comme ça…

Pour le moment ça à l’air de marcher (en tout cas sur les 2 derniers démarrages à froid). Je redonnerais des nouvelles dans quelques jours .