Bug#190110: libc6: Sub-processes flaking out.
GOTO Masanori <firstname.lastname@example.org> writes:
>> Note that mounting the old disk in the rebuilt system and using it
>> for a chrooted environment fails to reproduce the problem. So, I
>> thought, "perhaps a corrupted kernel" and used dpkg --root=/mnt to
>> install a new kernel on the old partition. Yet, the problem is
>> still there if I boot from the old partition after doing this.
> Does not 2.4.20-686 help you?
I use XFS and so have to custom-compile a kernel. But I think I've
pretty much ruled out the kernel as the issue here as well (see
> Hm, so do you have problems only for debuild?
No. For example, I can't start apache-ssl at all. Courier IMAPd is
giving me terrible problems. And the problem does seem to be time
related -- the longer the kernel is running the worse the problem
seems to get.
I mentioned I have two systems that showed the same problem. I
cleared up some disk space on my other system and did an installation
there using testing as the source. It works (as I expected).
Now, the interesting thing:
Here is how I'm pretty sure that the problem is not the kernel.
Running the old system while I configured the chrooted environment
under /mnt, I found that the chrooted system had no problems -- I was
able to run 'apt-get dist-upgrade' w/o tar freaking out. Since the
only difference was the chroot, I would assume that the problem wasn't
And I did md5sum /lib/libc.so.6, /lib/ld-linux.so.2, etc on the root
and chroot, but failed to find any differences.
As I said, doing a clean install to testing seemed to do the trick.
Still, this seems like an upgrade problem rather than a glibc problem,
per se. I'm not how to investigate this further unless someone wants
me to send them my hard drive.
 "Failed to create cache file: maildirwatch Error:
Input/output error" for most any IMAP command.
 It is production, so even though it is buggy I've at least got it