ld.so.conf prevents libc6 from upgrading in a 32-bit chroot on amd64

That error is produced by the libc6 preinst script
(/var/lib/dpkg/info/libc6.preinst) around line 135.
It does actually check to see if the ld.so.conf paths begin with /emul/ which
appears to be related to ia64.
So, you could symlink /emul/ to your chroot and change the ld.so.conf paths.
libc upgrades will then work.

The problem with giving folks on option on this kind of sanity check is that
people are likely to just say 'proceed' without reading the message, potentially
rendering their system completely useless. The decision to do this, however,
was made before amd64 game on the scene.

I'm not as familiar with the amd64 setup. Is having these in your ld.so really
the right thing? Do you install and run 32 bit apps on your main system, or
only in your chroot? If everything is inside that chroot, I don't see why it
would need to be listed in the main ld.so.conf file.

I really run ia32 applications outside the chroot. I'd prefer to use ia32-libs,
but I need some libraries which are not present in ia32-libs. Including chroot
into ld.so.conf is an easiest and common way to solve this problem.
Is it difficult to check architecture of libc that was found? It may be done,
for example, with "file" utility if it is installed.

If you don't want to make the problem go away by using the /emul/ method above
it could make sense to make the script aware of dchroot's config file. That is
the only way I know of for "registering" a chroot install somehow, so it's the
only predictable way to find them other than if they are all mounted in /emul/
(which is handled now, so this is perhaps just a documentation issue?)
Probing each one to try and find out what it is is the wrong behaviour imo, it
would imply that suitable architectures would be worth paying attention to in
some way. Ignoring them outright would certainly be quicker :)

I do not understand the last comment. I can solve _my_ problems (using the
/emul/ method above or by other ways). I supposed that _you_, Ubuntu team, are
interested in bug reports. If it is not true -- OK, I will not report the
problems which I have to solve with Ubuntu.
Many Debian amd64-related documentation tells about /var/chroot/, not about
/emul/. Average user will use the place described in documentation. Average user
will install dchroot (from Universe) and use it with /var/chroot/ or /chroot/,
as described in /usr/share/doc/dchroot/README. By the way, I believe that libc
scripts should not parse dchroot config while dchroot is in universe :-).

(In reply to comment #5)
> I do not understand the last comment. I can solve _my_ problems (using the
> /emul/ method above or by other ways). I supposed that _you_, Ubuntu team, are
> interested in bug reports. If it is not true -- OK, I will not report the
> problems which I have to solve with Ubuntu.

Please take a breath; your bug report is not being rejected. It is open and
assigned to an Ubuntu developer for analysis.

This bug sounds pretty Confirmed to me...

Thank you for posting this bug.

Does this occur in Lucid?

Closing because if no response.