GOTO Masanori <[EMAIL PROTECTED]> 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 below). > 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[1]. 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[2] 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 the kernel. 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. Mark. Footnotes: [1] "Failed to create cache file: maildirwatch Error: Input/output error" for most any IMAP command. [2] It is production, so even though it is buggy I've at least got it stumbling along.
