On 2011-08-03 13:11 +0200, Michal Suchanek wrote:
> Excerpts from Jonathan Nieder's message of Wed Aug 03 12:54:12 +0200 2011:
>> Michal Suchanek wrote:
>>
>> > It's possible to take some random binary which is likely to be native
>> > (eg. /bin/sh), run ldd on it, and parse the output to determine what
>> > libc is actually used.
>>
>> But that's the point. Which libc is used depends on the binary.
>> /bin/sh might be an i386 binary and /bin/ls be amd64. How does
>> update-initramfs cope with that?
>
> Currently all libraries are installed in /lib in initramfs so there
> should be only one flavour of binaries (i386 or amd64).
That seems to be wrong:
,----
| $ lsinitramfs /boot/initrd.img-$(uname -r) | grep -c $(dpkg-architecture
-qDEB_HOST_MULTIARCH)
| 9
`----
> On current system there is some main subarch and perhaps a few binaries
> of another subarch which are second grade citizens at best with very few
> libraries to support their installation.
>
> Is that going to change to the point that the essential binaries
> installed in initramfs are going to be a mix of architectures or is
> there still going to be main architecture in the future?
Most systems will probably not need binaries from foreign architectures,
but they should already work if you can execute them at all.
> If the latter then dpkg can show what the main architecture is and only
> binaries from packages of that architecture should be allowed in
> initramfs. If the former then initramfs-tools need multiarch support.
The copy_exec function that installs a binary into the initramfs runs
ldd and installs the libraries that ldd reports. Don't you think this
is sufficient?
Cheers,
Sven
--
To UNSUBSCRIBE, email to [email protected]
with a subject of "unsubscribe". Trouble? Contact [email protected]
