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
