> De: "Christian Marillat" <marillat@???> > Envoyé: Mercredi 3 Mai 2023 18:52:42 > On 03 mai 2023 18:21, Yves Martin <ymartin59@???> wrote:
>
>
> [...]
>
>> Selon moi le problème réside:
>> - soit dans la génération de l'initrd mais j'ai fait un contrôle
>> d'intégrité des packages Debian et rien n'est sorti
>
> Avec debsums ?
Oui: debsums -a -s
Me retourne 3 fichiers de configuration dans /etc
C'est une testing que je tiens à jour (même dans son état actuel),
sans "trop" de sources APT additionnelles;
je viens d'en désactiver 3 pour ne garder que debian-testing.
> Tu arrives à faire un chroot sur ton initrd ?
>
> ,----
>| mkdir /tmp/foo
>| cd /tmp/foo
>| unmkinitramfs /boot/initrd.img-XX
>| sudo chroot main /bin/sh
> `----
Et bien non! j'ai le sentiment de progresser ;)
À noter: je n'ai pas de copier/coller donc j'ai reproduit la ligne d'erreur aussi fidèlement que possible.
Cas 1: dans le shell installer rescuecd à priori sans chroot initial, ici BusyBox 1.30.1
# chroot /target/tmp/initrd-6.1.0-7/main /bin/sh
chroot: can't execute '/bin/sh': No such file or directory
mais /target/tmp/initrd-6.1.0-7/main/bin/sh échoue à la liaison sur les symboles GLIBC_2.33 et GLIBC_2.34
normal selon la version de glibc sur le rescuecd
Cas 2: après un premier chroot dans mon système (chroot /target), ensuite c'est le chroot coreutils:
# chroot /tmp/initrd-6.1.0-7/main /bin/sh
chroot: failed to run command /bin/sh’: No such file or directory
Mais
/tmp/initrd-6.1.0-7/main/bin/sh
démarre bien BusyBox, version de glibc OK dans ma racine
J'ai analysé par objdump -x le binaire "sh", qui réclame libc.so.6 et resolve.so.2
qui sont bien présents dans l'initrd sous /usr/lib/x86_64-linux-gnu/
Les flags "rx" sont présents sur "sh" et les libs.
Et j'ai vérifié que le fs utilisé pour /tmp n'est pas monté avec "noexec".
J'ai les packages 0.142 de initramfs-tools et initramfs-tools-core
Mais je suis en train d'appliquer les mises à jour (272 packages)
