Hi, Aurelien Jarno <aurelien@aurel32.net> (2014-02-25): > Yes, we get this bug happening regularly because the binaries on the > image went through the library reduction process with a given libc (here > 2.18), and later a different version of the libc is unpacked over it > (here 2.17). Therefore some symbols are missings, causing the segfault. > In addition I think there are also some version mismatches between libnss-* > and libc6 when the old one is getting unpacked. alright, thanks. > > This rings some bells: > > | eglibc (2.18-2) unstable; urgency=medium > > | > > | [ Aurelien Jarno ] > > | * any/local-ldconfig-ignore-ld.so.diff: new patch to ignore the dynamic > > | linker in ldconfig. Closes: #699206, #707185, #727786, #736097, > > | #739734, #739758. > > No it's not related to that. This bug is when you have multiple libc of > the same architecture on a system (e.g. libc6:amd64 and > libc6-amd64:i386, or libc6:i386 and libc-i386:amd64) OK, thanks. > > eglibc maintainers, can you please suggest further directions for me to > > look into? Initial d-i bug report with busybox sh segfaults: > > http://bugs.debian.org/740068 > > > > You just have to ensure that the libc used for building the image is the > same as the one used later in d-i. Said slightly otherwise, this issue should go away as soon as eglibc hits testing. I guess we can live with a few days of breakages, if that only happens when a new major eglibc release appears in unstable, and lasts until it's ready to migrate to testing. If that's correct, it would be nice to announce new major releases to -boot@ a few days before it gets uploaded. Or I could monitor that along with linux kernel versions… Will think about it. Thanks again for the explanations; I'll keep this bug report open as a placeholder for the time being. Mraw, KiBi.
Attachment:
signature.asc
Description: Digital signature