Module ehci-orion not found in modules.dep

Support Debian
Tags: #<Tag:0x00007f4691f593b0>
#1

Salut tout le monde,

ce matin j’ai eu la désagréable surprise d’avoir un message d’erreur lors du démarrage de mon ordi (debian 8, /boot/initrd.img-3.16.0-4-amd64).
Hier soir déjà il s’était éteint d’une manière inhabituelle, càd beaucoup plus lente.
Au premier démarrage, il s’est arrêté à l’invite de commande root.
Au deuxième démarrage et aux suivants dans ce qu’il affiche ce que j’ai identifié comme l’erreur à corriger:
“modprobe: module ehci-orion not found in modules.dep”

Actions déjà tentées
*à partir de la page d’initialisation

  • “fsck” manuel ==> “fsck from util-linux 2.52.2”
  • “vgchange -ay” ==> “vgchange not found”
  • à partir du CD d’installation, en mode “recovery”
  • mise à jour de initramfs (“update-initramfs -u”)
  • mise à jour des paquets (“apt-get update && apt-get upgrade”)
  • dans /etc/initramfs-tools/modules j’ai ajouté “ehci-orion”

Toujours le même problème au démarrage…

Que puis-je faire?

Je vous remercie d’avance pour votre aide

#2

Salut,

Est-ce que depmod peut aider ?

Est-ce qu’il s’agit bien de volumes chiffrés ?

#3

@gandouz: aviez vous ce module avant le problème?avez vous fait des maj? peut être passer sur le kernel des backports.

#4

Bonsoir,
merci pour la réponse.
Alors pour le module, je ne sais pas si je l’avais avant.
Je fais des MAJ régulièrement avec apt-get en console, rien vu de particulier qui m’ait alerté sur la dernière.
Je n’ai pas mis les backports dans ma sources.list .

#5

Salut,
merci pour ta réponse,
je n’ai pas d’idée pour depmod. Comment est-ce que ça pourrait m’aider? Je viens de regarder ce que c’était, je ne connaissais pas avant.

Non, mes disques ne sont pas chiffrés.

#6

Salut,

C’est depmod il me semble qui génère le fichier modules.dep.

Il est possible que ce message d’erreur ne soit que du bruit et n’empêche en rien le bon fonctionnement si le module en question n’est pas utile.

Je pensais les disques chiffrés à cause de la mention sur vgchange.

Je me demande quand même si les divers problèmes, en dehors du message d’erreur, ne sont pas en rapport avec l’état des volumes disques. Il faudrait un peu plus de détails concernant le partitionnement.

#7

Salut,
effectivement, c’est possible. Le truc, c’est que ça bloque le démarrage et il faudrait voir comment contourner ce blocage pour vérifier cette hypothèse.

Il y a un disque séparé en 4 partitions primaires:

  • sda1: monté en “/” 40Go
  • sda2: monté en “swap” 4Go
  • sda3: monté en “/home” 450 Go
  • sda4: monté en “/” 25Go depuis hier soir sur lequel j’ai installé Debian 8 pour continuer à pouvoir travailler.
#8

Pourquoi avoir tenté “vgchange -ay” si LVM n’est pas utilisé ? Peu importe.

Si j’ai bien compris en cherchant un peu, ehci-orion concerne un pilote usb. Le disque est-il usb ?

Il arrive aussi que systemd et la partition swap “se fâchent” ce qui peut correspondre au ralentissement détecté à l’extinction juste avant l’apparition du problème.

#9

J’ai fait “vgchange -ay” un peu par méconnaissance en lisant ce conseil sur un forum pour un problème similaire sur un ordi il est vrai dont le disque dur était chiffré.

Je ne crois pas que ce soir un disque USB. Il est dans une tour standard. Je ne l’ai pas ouverte, elle est encore sous garantie (d’occasion).

Et comment on pourrait les “réconcilier”?

#10

Le shell d’urgence ? Pour quelle raison, qui doit être mentionnée dans les lignes précédentes.

A priori ce message est parfaitement bénin, c’est l’initramfs qui essaie de charger ce module qui n’existe que dans certains noyaux pour des architectures ARM. Il est assez fréquent qu’on ne remarque ce genre de message habituel seulement lorsqu’on rencontre un problème, et qu’on lui attribue à tort la cause du problème.

#11

Est-ce qu’il s’arrête sur l’invite root ou est-ce qu’il continue ?

Ce n’est pas très clair.

#12

Bonsoir,
alors, la première fois il s’est arrêté sur l’invite root, les fois suivantes il s’est arrêté avant.
Je vous retranscris le texte entier:

Loading, please wait…
modprobe: module ehci-orion not found in modules.dep
/dev/sda1 contains a file system with errors, check forced.
/dev/sda1:
Directory inode 1055091, block #0, offset 0: directory corrupted

/dev/sda1: UNEXPECTED INCONSISTENCY; RUN fsck MANUALLY.
(i.e., without -a or -p oprions)
fsck exited with status code 4
The root filesystem on /dev/sda1 requires a manual fsck
modprobe: module ehci-orion not found in modules.dep

BusyBox v1.22.1 (Debian 1:1.22.0-9+deb8u1) built-in shell (ash)
Enter ‘help’ for a list of built-in commands.

/bin/sh: can’t access tty; job control turned off
(initramfs)

Et ensuite plus rien, je suis sur l’invite de commande d’initramfs.

#13

Le système de fichiers racine dans /dev/sda1 a un répertoire corrompu. Il faut faire ce qui est demandé pour réparer :

fsck /dev/sda1

Note : La réparation ne pourra pas forcément restaurer le répertoire et risque de transformer les fichiers qu’il contient en inodes orphelins qui vont se retrouver dans /lost+found mais sans leurs noms d’origine.

#14

RTFM, j’avais tapé “fsck” sans préciser le disque à vérifier. Merci.

Alors la chose faite, il y a eu 5 “pass” et en conclusion du test et des corrections, il y a marqué:

/dev/sda1: ***** FILE SYSTEM WAS MODIFIED ****
/dev/sda1: 368275/2445984 files (0.1% non-contiguous), 3375815/9764864 blocks
(initramfs)

La commande “reboot” ne fonctionne pas, je force le redémarrage et ça démarre…

#15

… et ça démarre, mais il y a une étape nouvelle au démarrage qui s’est ajoutée et elle dure 1min 30:

A start job is running for dev-disk-by\x2duuid-496ffc82\x2db45b\x2d46e6\x2d2f08d…device (1min 18s / 1min 30s )

J’ai redémarré pour vérifier et elle a eu lieu aux deux démarrages.

#16

Il faut regarder dans le contenu de /etc/fstab et la sortie de blkid pour voir à quel volume cet UUID est censé appartenir.

#17

Dans /etc/fstab, il s’agit du swap (/dev/sda2)
Et à la sortie de “blkid”, l’UUID du swap est différente.

Si j’anticipe la suite, il faudrait que je copie-colle l’UUID du swap de blkid pour remplacer l’actuel dans /etc/fstab, correct?

#18

Oui. Même chose dans le fichier /etc/initramfs-tools/conf.d/resume si l’ancien UUID s’y trouve, suivi de l’exécution de update-initramfs (c’est pour l’hibernation).

J’aurais dû y penser : si tu n’as pas fait attention à l’empêcher, l’installation du second système Debian a réutilisé le swap existant et l’a reformaté avec un nouvel UUID. Cela n’a aucun rapport direct avec le problème sur sda1.

#19

Yeapa, c’est bueno, merci.
Effectivement, il avait reformaté le swap lors de l’installation du deuxième système Debian. Je l’avais laissé faire, je voyais pas le souci.
Bon, il y a d’autres trucs chelous qui s’affichent au démarrage, mais on verra ça une autre fois, la bête a l’air de tourner à nouveau.

Encore merci à vous trois pour m’avoir aidé et n’oublions pas de lire ce putain de manuel!!

A plus

#20

Ce sont peut-être d’autres messages anodins qui s’affichaient déjà avant le problème et auxquels tu ne faisais pas attention, comme celui concernant ehci-orion. Mais ils peuvent aussi être liés au répertoire qui était corrompu.

“Réparer” un système de fichiers consiste essentiellement à remettre les méta-données dans un état cohérent, pas forcément à préserver les données. Des fichiers ont pu être perdus. Tu peux regarder ce qui se trouve dans le répertoire /lost+found.