Re: Debian kernel boot failure

Top Page

Reply to this message
Author: ymartin59
Date:  
To: Guilde ML
Subject: Re: Debian kernel boot failure
On Sat, 2023-05-06 at 08:18 +0200, Christian Marillat wrote:

> On 05 mai 2023 22:47, [ mailto:ymartin59@free.fr | ymartin59@??? ] wrote:
>
> > Finalement debsums a trouvé un package corrompu:
> > # debsums -c
> > /usr/bin/pzstd
> > /usr/bin/zstd
> > /usr/share/doc/zstd/changelog.Debian.gz
> > /usr/share/man/man1/pzstd.1.gz
>
> Quand même. Depuis initramfs-tools 0.141 en date du 10 avril 2022 la
> compression de l'initrd est faite par défaut par zstd.


Vu que mkinitramfs et unmkinitramfs n'en semblaient pas affectés,
je suppose qu'il devait s'agir des binaires d'une version précédente.
Est-ce l'interruption de l'install ou un reboot/fsck violent qui
serait à l'origine de l'incohérence ? Ce point est réglé.

> > initrd fonctionnel (avec quelques fichiers divers en moins que
> > l'autre):
> > /usr/lib64/ld-linux-x86-64.so.2
> > -> ../lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
> >
> > initrd non fonctionnel:
> > pas de lien depuis /usr/lib64/ mais
> > /usr/lib/ld-linux-x86-64.so.2
> > -> ld-linux.so.2
> > -> x86_64-linux-gnu/ld-linux-x86-64.so.2
> >
> > Et pourquoi ld-linux est installé différemment entre mes deux
> > systèmes ?
> > Probablement un lien avec l'âge du système, ça doit dater de la
> > version de l'installer...


> /usr/lib64 est manquant. Il n'y a pas eu des problèmes ave usrmerge ?


Non, tout me semble normal de ce côté.
Simplement /usr/lib64 est vide dans l'image initrd non fonctionnelle,
mais l'image fonctionnelle contient un lien vers ld-linux-x86-64.so.2

Mon système contient bien
/lib64/ld-linux-x86-64.so.2 -> /lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
mais pas les images initrd produites avec.

lrwxrwxrwx 1 root root     37 May  5 22:39 initrd-6.1.0-3/main/usr/lib/ld-linux.so.2 -> x86_64-linux-gnu/ld-linux-x86-64.so.2
lrwxrwxrwx 1 root root     13 May  5 22:39 initrd-6.1.0-3/main/usr/lib/ld-linux-x86-64.so.2 -> ld-linux.so.2
-rwxr-xr-x 1 root root 210968 Apr 10 10:35 initrd-6.1.0-3/main/usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
lrwxrwxrwx 1 yma  yma      37 Apr  3 04:21 initrd-6.1.0.7/main/usr/lib/ld-linux.so.2 -> x86_64-linux-gnu/ld-linux-x86-64.so.2
lrwxrwxrwx 1 yma  yma      13 Apr  3 04:21 initrd-6.1.0.7/main/usr/lib/ld-linux-x86-64.so.2 -> ld-linux.so.2
-rwxr-xr-x 1 yma  yma  210968 Jan  7 12:29 initrd-6.1.0.7/main/usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
lrwxrwxrwx 1 yma  root     44 May  5 17:39 initrd-ok/main/usr/lib64/ld-linux-x86-64.so.2 -> ../lib/x86_64-linux-gnu/ld-linux-x86-64.so.2
-rwxr-xr-x 1 yma  root 210968 Jan  7 12:29 initrd-ok/main/usr/lib/x86_64-linux-gnu/ld-linux-x86-64.so.2



> Pourquoi les locales de coreutils sont-elles chargées alors que
> /usr/bin/sh doit être celui de busybox ?


Mon interprétation est que chroot cherche à traduire le message d'erreur "No such file or directory"
à la réception de l'erreur execve.

> Que donne ls -l main/usr/bin/sh


Pour les deux images, la même chose et kdiff3 me confirme qu'ils sont identiques:

root@YMAdebian:/home/yma/tmp# ls -l initrd-ok/main/usr/bin/sh
-rwxr-xr-x 256 yma root 772880 Feb 25 19:53 initrd-ok/main/usr/bin/sh
root@YMAdebian:/home/yma/tmp# ls -l initrd-6.1.0.7/main/usr/bin/sh
-rwxr-xr-x 256 yma yma 772880 Feb 25 19:53 initrd-6.1.0.7/main/usr/bin/sh

J'ai commencé à lire le code mkinitramfs et tous les fichiers de configuration, hooks,
histoire de comprendre ce qui aurait dû produire /usr/lib64/ld-linux-x86-64.so.2
et ne le ferait pas.

--
Yves