----- Mail original -----
> De: "Christian Marillat" <marillat@???>
> Envoyé: Vendredi 5 Mai 2023 13:09:13
> Objet: Re: Debian kernel boot failure
> On 04 mai 2023 09:40, Christian Marillat <marillat@???> wrote:
>
>> On 04 mai 2023 09:12, ymartin59@??? wrote:
>>
> Explication un peu basique de busybox.
>
> busybox est un binaire qui combine plus de 250 applications de
> base (258 pour la version 1.35.0)
> Busybox utilise le nom avec lequel il est appelé argv[0] pour
> l'exécuter.
Merci Christian
(je le savais déjà)
Comme je l'avais écrit au début des messages ici, tout à commencer (selon moi)
par une mise à jour volumineuse qui s'est interrompue par manque d'espace
disque... j'ai rattrapé l'affaire (et d'habitude je n'ai pas de soucis ensuite)
mais probablement que la chaîne de construction des images initrd a souffert au passage.
L'essentiel pour moi est déjà d'avoir retrouvé l'accès à mon système
"complet" (pas seulement un shell démarré par rescuecd) en recopiant
"simplement" l'initrd produit depuis un système similaire.
Je veux continuer à décortiquer le problème pour savoir quels fichiers
pourraient être corrompus, pour aboutir à cette erreur de démarrage du
Busybox depuis le chroot de l'extraction de image initrd.
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
Après réinstallation, et génération d'un initrd, toujours échec de démarrage
de /bin/sh dans un chroot. Bref, ce n'était pas ça.
Comme ce Busybox démarre depuis le rescuecd (hors chroot initrd),
ça doit venir des libs en liaison, et il n'y en a que deux:
libc et libresolv ou encore du ld-linux...
Je viens de faire un "gros kdiff3" entre les deux extractions et les binaires
des libs et busybox sont identiques. La différence que j'ai constatée se trouve
aux niveaux des liens symboliques ld-linux:
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 la lib ld-linux elle-même est strictement identique, y compris le timestamp
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...
Du coup, étape suivante, comparaison des ld.so.conf.d/ avec des spécialités "multiarch"
et "fakeroot" et "fakechroot" des outils de packaging.
Et donc /etc/ld.so.conf.d/x86_64-linux-gnu.conf pointe bien /usr/lib/x86_64-linux-gnu
J'ai tenté de faire un "strace -f chroot main /bin/sh" mais ça ne m'avance guère:
chroot("main") = 0
chdir("/") = 0
execve("/usr/bin/sh", ["/usr/bin/sh"], 0x7ffe70362b38 /* 21 vars */) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/share/locale/locale.alias", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/share/locale/en_US/LC_MESSAGES/coreutils.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/share/locale/en/LC_MESSAGES/coreutils.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
write(2, "chroot: ", 8chroot: ) = 8
write(2, "failed to run command \342\200\230/usr/bi"..., 39failed to run command ‘/usr/bin/sh’) = 39
openat(AT_FDCWD, "/usr/share/locale/en_US/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, "/usr/share/locale/en/LC_MESSAGES/libc.mo", O_RDONLY) = -1 ENOENT (No such file or directory)
write(2, ": No such file or directory", 27: No such file or directory) = 27
Le problème est bien caché derrière ce "execve".
--
Yves
