Erreurs update-initramfs -- 3.2.0-1-amd64 -- SID

[mazkagaz]

Bonjour,

Je suis actuellement connecté en ssh sur une de mes machines sous debian unstable.

J’ai lancé les mises à jour (update/upgrade) et certains messages lors de cette mise à jour ont attiré mon attention :

[quote]Traitement des actions différées (« triggers ») pour « initramfs-tools »…
update-initramfs: Generating /boot/initrd.img-3.2.0-1-amd64
FATAL: Module xhci not found.
FATAL: Module ext4dev not found.
FATAL: Module zfcp not found.
FATAL: Module dasd_diag_mod not found.
FATAL: Module dasd_eckd_mod not found.
FATAL: Module dasd_fba_mod not found.
WARNING: could not open /var/tmp/mkinitramfs_dXvSoP/lib/modules/3.2.0-1-amd64/modules.builtin: No such file or directory
[/quote]

Je trouve ces messages assez inquiétants et m’abstiendrai de redémarrer/étendre ce PC tant que je ne serai pas certain que le redémarrage se passera sans encombre.

“apt-cache showpkg initramfs-tools” me renvoie, entre autre,

[quote]Versions:
0.100 (/var/lib/apt/lists/ftp.fr.debian.org_debian_dists_sid_main_binary-amd64_Packages)[/quote]

N’hésitez pas à me demander des détails qui vous seraient utiles pour comprendre le soucis.

Merci d’avance pour votre aide.

Mazkagaz

[eggregor]

Bonjour,

Même message chez moi ce matin, çà s’arrangera sans doute demain, çà n’empêche pas la machine de fonctionner.

Peut-être simplement éviter un redémarrage.

[ggoodluck47]

Salut,

[quote=“eggregor”]Bonjour,

Même message chez moi ce matin, çà s’arrangera sans doute demain, çà n’empêche pas la machine de fonctionner.

Peut-être simplement éviter un redémarrage.[/quote]

Redémarrage sans problème (chez moi) avec la même erreur,mais il veut me virer complètement kde

[mazkagaz]

[quote=“ggoodluck47”]Salut,
Redémarrage sans problème (chez moi) avec la même erreur,mais il veut me virer complètement kde [/quote]

Mode troll ON : normal, kde, c’est le mal

Mode troll OFF : bonne nouvelle, mais je ne le redémarrerai pas quand même , pas tout de suite. Peut-être que les spécificités de ta configuration font que tu n’as pas besoin par exemple de l’ext4.

[vinc17]

Pour info, il y a déjà eu des problèmes du même genre à cause de modules devenus builtin: bugs.debian.org/cgi-bin/bugreport.cgi?bug=659866

Peut-être est-ce le même problème?

[mazkagaz]

[quote=“vinc17”]Pour info, il y a déjà eu des problèmes du même genre à cause de modules devenus builtin: bugs.debian.org/cgi-bin/bugreport.cgi?bug=659866

Peut-être est-ce le même problème?[/quote]
Si c’était le cas, je devrais les retrouver dans /lib/modules/3.2.0-1-amd64/modules.builtin , non ?
Parce que je ne les ai pas trouvés.

[mazkagaz]

Bonjour,

nouveau noyau ce matin, même résultat.

J’ai fait un rapport de bogue via reportbug, on verra ce qu’ils en pensent du côté des devs.

Je vous tiens informés si j’ai des news.

Mazkagaz

[lol]

Salut,
Il est urgent d’attendre… Ma dernière mise à jour date du 3, je vais patienter un peu…

[syam]

Aucun problème pour ma part avec le 3.2.0-1 ni avec le 3.2.0-2 arrivé aujourd’hui, mais je suis sur une base testing.
Donc le problème ne vient pas du noyau lui-même mais d’un autre paquet (j’allais dire initramfs-tools mais le 0.100 est à la fois dans testing et unstable, ça l’élimine comme suspect).

Ceux qui ont le problème, faudrait peut-être regarder les logs apt(itude) pour savoir quelles autres mises à jour vous avez fait en même temps ?

[mazkagaz]

Bon, d’après Michael Prokop, il s’agit bien du même bug que celui qu’avait vu vinc17 : bugs.debian.org/cgi-bin/bugreport.cgi?bug=659866

Et il vient juste de le corriger, donc on devrait voir apparaître un initramfs-tools version 0.101 dans les dépôts unstable sous peu :

[quote]/lib/modules/3.2.0-1-amd64/modules.builtin is probably missing in
your initrd, that’s the reason for the failure.

The new release 0.101 should show up in Debian/unstable in the next
few minutes, please give it a try.

regards,
-mika-[/quote]
Bon, je comprends toujours pas pourquoi ça devrait régler le soucis puisque les modules en questions ne sont pas listés dans /lib/modules/3.2.0-1-amd64/modules.builtin. Mais il doit maîtriser son sujet donc je lui fais confiance

[vinc17]

[quote=“mazkagaz”]Si c’était le cas, je devrais les retrouver dans /lib/modules/3.2.0-1-amd64/modules.builtin , non ?
Parce que je ne les ai pas trouvés.[/quote]
Idem, mais peut-être que la fonctionnalité est sous une autre forme. D’ailleurs, au moins pour ext4dev, il n’était ni builtin, ni un vrai module pour les anciens noyaux Debian.

Les noms des modules en question viennent du fichier /usr/share/initramfs-tools/hook-functions (cf fonction auto_add_modules, qui est appelée par mkinitramfs, script lui-même exécuté par update-initramfs).

[mazkagaz]

[quote=“vinc17”][quote=“mazkagaz”]Si c’était le cas, je devrais les retrouver dans /lib/modules/3.2.0-1-amd64/modules.builtin , non ?
Parce que je ne les ai pas trouvés.[/quote]
Idem, mais peut-être que la fonctionnalité est sous une autre forme. D’ailleurs, au moins pour ext4dev, il n’était ni builtin, ni un vrai module pour les anciens noyaux Debian.

Les noms des modules en question viennent du fichier /usr/share/initramfs-tools/hook-functions (cf fonction auto_add_modules, qui est appelée par mkinitramfs, script lui-même exécuté par update-initramfs).[/quote]
J’ai vu que tu avais rouvert le bogue, ça me rassure, je ne suis pas encore totalement rouillé
Je vais jeter un oeil à tout ça pour voir si je peux corriger à la mano.
Pour ext4dev, il me semble qu’il a changé de nom pour devenir ext4 tout court. Il y a peut-être un alias quelque part et ext4 est présent dans modules.order, ceci explique peut-être cela…
@ suivre…

[mazkagaz]

Bonjour,

J’ai des éléments supplémentaires mais ne sais pas comment répondre directement dans les rapports de bogues. J’imagine qu’on peut faire ça en écrivant un mail suivant un format spécifique, avec le sujet et l’adresse qui vont bien…

Toujours est-il que j’ai un peu regardé le contenu de /usr/share/initramfs-tools/hook-functions :

• dans auto_add_modules, pour tous les modules qui nous intéressent dans le bug 662766, la fonction invoquée est manual_add_modules.
• dans manual_add_modules, d’entrée, il cherche les dépendances du module via un " modprobe --show-depends …". Hors si je lance un “modprobe xhci” j’obtiens un joli :

FATAL: Module xhci not found.

et j’obtiendrai a fortiori la même chose si je cherche les dépendances.

Si xhci est builtin dans les noyaux récents, alors c’est normal, on demande simplement l’impossible en forçant la recherche du module. Il me semble que le problème est amont. Pour ces modules, on ne devrait pas arriver jusque dans manual_add_modules. Mais alors pourquoi n’est-il pas mentionné dans le fichier module.builtin ? Ce serait un bogue de création du noyau ?
Si xhci n’est pas builtin, alors il manque à l’appel ou a changé de nom.

Un indice : la commande “locate xhci” renvoie :

[quote]/lib/modules/2.6.32-5-amd64/kernel/drivers/usb/host/xhci.ko
/lib/modules/3.2.0-1-amd64/kernel/drivers/usb/host/xhci-hcd.ko
/lib/modules/3.2.0-2-amd64/kernel/drivers/usb/host/xhci-hcd.ko
/usr/src/linux-headers-3.2.0-1-amd64/include/config/usb/xhci
/usr/src/linux-headers-3.2.0-1-amd64/include/config/usb/arch/has/xhci.h
/usr/src/linux-headers-3.2.0-1-amd64/include/config/usb/xhci/hcd.h
/usr/src/linux-headers-3.2.0-2-amd64/include/config/usb/xhci
/usr/src/linux-headers-3.2.0-2-amd64/include/config/usb/arch/has/xhci.h
/usr/src/linux-headers-3.2.0-2-amd64/include/config/usb/xhci/hcd.h[/quote]
On voit que le module xhci disparaît à partir des 3.2, on voit aussi apparaître xhci-hcd.
On voit aussi qu’il est présent dans les entêtes des noyaux 3.2 mais pas dans ceux du 2.6.

Autre observation :

[quote]~# cd /lib/modules/3.2.0-2-amd64
~# for i in modules.; do echo $i; grep xhci $i; done
modules.alias
alias pci:vdsvsdbc0Csc03i30 xhci_hcd
modules.alias.bin
Fichier binaire modules.alias.bin concordant
modules.builtin
modules.builtin.bin
modules.dep
kernel/drivers/usb/host/xhci-hcd.ko: kernel/drivers/usb/core/usbcore.ko kernel/drivers/usb/usb-common.ko
modules.dep.bin
Fichier binaire modules.dep.bin concordant
modules.devname
modules.order
kernel/drivers/usb/host/xhci-hcd.ko
modules.softdep
modules.symbols
modules.symbols.bin[/quote]
Si j’ai bien compris comment ça marche, il me semble vraiment que le module xhci devrait se trouver dans modules.builtin.

Bref, tout ça pour dire que j’ai plutôt l’impression que ça vient de la génération du kernel et de tout ce qui l’entoure plutôt que de initramfs-tools.

@ suivre…

[sidell]

Quelqu’un peut m’assurer qu’un reboot après cette maj (et cette erreur kernel) ne pose pas problème ? Le système boot sur le nouveau kernel ?

[vinc17]

Bonjour,

J’ai des éléments supplémentaires mais ne sais pas comment répondre directement dans les rapports de bogues.

Pour répondre, il suffit d’envoyer un mail à l’adresse mail du bug, de la forme <numéro>@b.d.o. Mais pour éviter de casser les fils de discussion, je conseille d’installer le paquet devscripts, qui fournit une commande très utile: bts. Ici, pour récupérer le rapport de bug et l’ensemble des messages s’y rapportant:

Ça met un peut de temps, car les messages doivent être téléchargés. Cela lance Mutt sur une boîte-aux-lettres temporaire avec l’ensemble des messages (“man bts” pour plus d’info). On peut aussi souscrire au bug (cf commande “subscribe” de bts ou lien “subscribe” sur la page d’un bug) pour recevoir les messages futurs du bug.

[quote=“mazkagaz”]Toujours est-il que j’ai un peu regardé le contenu de /usr/share/initramfs-tools/hook-functions :

• dans auto_add_modules, pour tous les modules qui nous intéressent dans le bug 662766, la fonction invoquée est manual_add_modules.
• dans manual_add_modules, d’entrée, il cherche les dépendances du module via un " modprobe --show-depends …". Hors si je lance un “modprobe xhci” j’obtiens un joli :

FATAL: Module xhci not found.

et j’obtiendrai a fortiori la même chose si je cherche les dépendances.

Si xhci est builtin dans les noyaux récents, alors c’est normal, on demande simplement l’impossible en forçant la recherche du module. Il me semble que le problème est amont.[/quote]
Oui, avec l’option --quiet, on ne devrait pas obtenir de message d’erreur si le module n’est pas trouvé. C’est documenté dans la page man de modprobe, et c’est le bug 662822: bugs.debian.org/cgi-bin/bugreport.cgi?bug=662822

Pour ces modules, on ne devrait pas arriver jusque dans manual_add_modules. Mais alors pourquoi n’est-il pas mentionné dans le fichier module.builtin ? Ce serait un bogue de création du noyau ?

Pas forcément. Le noyau a peut-être été modifié ou il s’agit d’un ancien module qui n’existe plus dans les nouveaux noyaux, ou il a changé de nom. Mais a priori, kmod doit pouvoir supporter les anciens et les nouveaux noyaux. D’où l’utilité de l’option --quiet (si elle fonctionnait).

[quote=“mazkagaz”]Autre observation :

[quote]~# cd /lib/modules/3.2.0-2-amd64
~# for i in modules.; do echo $i; grep xhci $i; done
modules.alias
alias pci:vdsvsdbc0Csc03i30 xhci_hcd
modules.alias.bin
Fichier binaire modules.alias.bin concordant
modules.builtin
modules.builtin.bin
modules.dep
kernel/drivers/usb/host/xhci-hcd.ko: kernel/drivers/usb/core/usbcore.ko kernel/drivers/usb/usb-common.ko
modules.dep.bin
Fichier binaire modules.dep.bin concordant
modules.devname
modules.order
kernel/drivers/usb/host/xhci-hcd.ko
modules.softdep
modules.symbols
modules.symbols.bin[/quote]
Si j’ai bien compris comment ça marche, il me semble vraiment que le module xhci devrait se trouver dans modules.builtin.[/quote]
Pas sûr. Il y a le module xhci_hcd (ou xhci-hcd?), qui est différent de xhci. Aucune trace de xhci seul ci-dessus.

[vinc17]

Quelqu’un peut m’assurer qu’un reboot après cette maj (et cette erreur kernel) ne pose pas problème ? Le système boot sur le nouveau kernel ?

Je n’ai semble-t-il pas de problème. Je pense que l’erreur peut aussi se produire avec les anciens noyaux. Ce qui a changé, semble-t-il, c’est qu’avant, l’option --quiet fonctionnait: quand un module n’était pas trouvé (ce qui est généralement normal dans le cas présent), il n’y avait pas de message d’erreur. Cf http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=662822.

Si tu upgrades, vérifie que c’est initramfs-tools 0.101 qui est installé, car cette version corrige un autre bug.

[mazkagaz]

Je pense que l’erreur peut aussi se produire avec les anciens noyaux.

Oui, j’avais déjà fait le test avec la version 0.100, voilà ce que ça donne avec la 0.101 :

[quote]~# update-initramfs -k 2.6.32-5-amd64 -u
update-initramfs: Generating /boot/initrd.img-2.6.32-5-amd64
FATAL: Module xhci-hcd not found.
FATAL: Module hid-logitech-dj not found.
FATAL: Module af_packet not found.
FATAL: Module atkbd not found.
FATAL: Module zfcp not found.
FATAL: Module dasd_diag_mod not found.
FATAL: Module dasd_eckd_mod not found.
FATAL: Module dasd_fba_mod not found.
FATAL: Module unix not found.
WARNING: could not open /var/tmp/mkinitramfs_qNTZAI/lib/modules/2.6.32-5-amd64/modules.builtin: No such file or directory[/quote]
Je constate d’ailleurs que le WARNING perdure sur le 2.6… Etrange. Pourtant la 0.101 l’a bien fait disparaître pour le 3.2 :

[quote]~# update-initramfs -u
update-initramfs: Generating /boot/initrd.img-3.2.0-2-amd64
FATAL: Module xhci not found.
FATAL: Module zfcp not found.
FATAL: Module dasd_diag_mod not found.
FATAL: Module dasd_eckd_mod not found.
FATAL: Module dasd_fba_mod not found.[/quote]

[quote=“sidell”]Quelqu’un peut m’assurer qu’un reboot après cette maj (et cette erreur kernel) ne pose pas problème ? Le système boot sur le nouveau kernel ?

Je n’ai semble-t-il pas de problème.[/quote]
C’est bon pour moi aussi.

Donc d’après toi, ce message d’erreur serait un effet de bord d’une commande (modprobe) qui ne renvoie pas la bonne information. Donc en gros, il n’y aurait pas de problème majeur, juste un message un peu flippant la première fois qu’on le voit. (il faut dire qu’un message qui commence par “FATAL”, forcément, ça interpelle ) Tant mieux si c’est le cas !

[vinc17]

Je constate d’ailleurs que le WARNING perdure sur le 2.6… Etrange. Pourtant la 0.101 l’a bien fait disparaître pour le 3.2 :

D’après http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=659866#73, ça se produit pour les noyaux d’avant 3.2 (y compris pour 3.1), et la réponse est que c’est un nouveau bug.

Donc d’après toi, ce message d’erreur serait un effet de bord d’une commande (modprobe) qui ne renvoie pas la bonne information. Donc en gros, il n’y aurait pas de problème majeur, juste un message un peu flippant la première fois qu’on le voit. (il faut dire qu’un message qui commence par “FATAL”, forcément, ça interpelle ) Tant mieux si c’est le cas !

Je suis tout à fait d’accord qu’avec le FATAL, on prend peur…

[AnatomicJC]

Quelqu’un peut m’assurer qu’un reboot après cette maj (et cette erreur kernel) ne pose pas problème ? Le système boot sur le nouveau kernel ?

Je viens de faire la mise à jour à l’instant, j’ai eu ce message d’erreur mais j’ai tenté le reboot.

Pas de problèmes.