Gros problème avec update-initramfs

Support Debian
#1

Bonjour,
Lors de la mise à jour de ce matin, aptitude s’est planté au moment de la mise à jour des initramfs.
Quelque chose coince à ce moment-là, c’est en fait update-initramfs qui plante.
Je dois le tuer à la main, CTRL-C ne fonctionne pas.
Il plante au moment, ou juste après, la construction du module raid10 (que je n’utilise pas).
Voici les dernières actions avant le plantage (obtenues avec l’option -v) :

Calling hook cryptpassdev
Calling hook cryptopensc
Calling hook cryptkeyctl
Calling hook cryptgnupg-sc
Calling hook cryptgnupg
Calling hook ntfs_3g
Adding binary /bin/ntfs-3g
Adding library-link /lib/i386-linux-gnu/libntfs-3g.so.883.0.0
Adding library /lib/i386-linux-gnu/libntfs-3g.so.883.0.0
Calling hook reiserfsprogs
Calling hook mdadm
Adding binary /sbin/mdadm
Adding binary /sbin/mdmon
Adding module /lib/modules/4.17.0-3-686-pae/kernel/drivers/md/linear.ko
Adding module /lib/modules/4.17.0-3-686-pae/kernel/drivers/md/multipath.ko
Adding module /lib/modules/4.17.0-3-686-pae/kernel/drivers/md/raid0.ko
Adding module /lib/modules/4.17.0-3-686-pae/kernel/drivers/md/raid1.ko
Adding module /lib/modules/4.17.0-3-686-pae/kernel/drivers/md/raid10.ko

Et là il s’arrête. J’ai essayé avec strace, je n’ai rien de plus.
Est-ce que quelqu’un a une piste ?

P.S. : J’ai envoyé un rapport de bug et j’ai aussi envoyé un message sur la liste de diffusion.

#2

Il s’arrête ou il se bloque (sans rendre la main) ?
Quelle version de Debian ?
Qu’est-ce que c’est que ce noyau 4.17 ?
Il y a assez d’espace libre dans /var, /tmp et /boot ?

#3

Il se bloque sans rendre la main.
J’ai le même problème avec le noyau 5.4.
Debian Sid, je pense que j’ai assez de place :

> df
Sys. de fichiers blocs de 1K   Utilisé Disponible Uti% Monté sur
udev                 2014836         0    2014836   0% /dev
tmpfs                 406400      2708     403692   1% /run
/dev/sda2           51474392  45269604    3583384  93% /
tmpfs                2031996    150192    1881804   8% /dev/shm
tmpfs                   5120         4       5116   1% /run/lock
tmpfs                2031996         0    2031996   0% /sys/fs/cgroup
/dev/sdb6          696001044 302319092  358320480  46% /mnt/musique
/dev/sda1            2007024    156160    1747248   9% /boot
/dev/sda5           72117576  54728068   13719496  80% /usr/local
/dev/sda6          112297732 102133956    4452672  96% /home
tmpfs                 406396        36     406360   1% /run/user/1000
#4

Avec sid, il ne faut pas s’étonner. N’y aurait-il pas dans les dernières mises à jour un paquet en relation avec l’initramfs ?

#5

Aucune idée, je n’ai rien vu.
Comment je peux savoir ?
J’ai lu ailleurs que ça pouvait être un verrou coincé quelque part mais je ne vois pas.
J’ai déjà rétabli les liens symboliques de la racine vers les sauvegardes de /boot. Au moins, mon système redémarrera. :smiley:
Sinon, comme j’utilise lilo, est-ce qu’il a une vérification pour savoir si l’initrd correspond au noyau ?

#6

Tu peux regarder l’historique récent des mises à jour dans /var/log/apt/.

lilo ne vérifie rien du tout, il ne fait que prendre en compte les fichiers (ou liens symboliques) vmlinuz* et initrd* spécifiés dans lilo.conf.

#7

Pas de bol, je n’ai pas l’historique récent.
Il semble que ce soit mdadm qui foire (je n’ai pas de RAID).
Je vois des processus mdadm avec un état D dans htop.

#8

Si tu utilises aptitude pour les mises à jour les logs doivent être dans /var/log/aptitude.

#9

Après un redémarrage sur une sauvegarde d’un initrd (merci dpkg), dpkg --configure -a arrive au bout et le problème est réglé.
Je n’ai rien compris mais merci quand même de l’aide. :+1:

#10

Il y a une case à cocher pour marquer le sujet comme résolu.