[102] in athena10
Re: Debathena materials not imported
daemon@ATHENA.MIT.EDU (Greg Hudson)
Tue Mar 4 13:01:28 2008
From: Greg Hudson <ghudson@MIT.EDU>
To: Timothy G Abbott <tabbott@mit.edu>
Cc: athena10@mit.edu
In-Reply-To: <Pine.LNX.4.64L.0803031710070.17031@vinegar-pot.mit.edu>
Content-Type: text/plain
Date: Tue, 04 Mar 2008 13:00:39 -0500
Message-Id: <1204653639.6272.26.camel@error-messages.mit.edu>
Mime-Version: 1.0
Content-Transfer-Encoding: 7bit
On Mon, 2008-03-03 at 17:17 -0500, Timothy G Abbott wrote:
> Sounds like the Ubuntu dapper repository stopped generating Contents
> files. I don't have a browser handy, but it's probably worth looking for
> the Contents.gz in the dapper apt repository...
Confirmed: the Contents files in the dapper apt repository are empty.
> I'm guessing the lenny-i386 one is intended for using an i386 userspace
> with an amd64 kernel (linerva does this, for example).
Okay, that sounds vaguely important to make work.
> I think the edgy ones are the reason we use edgy-backports for our openafs
> modules. I recall some gutsy failures related to weird kernels
> (real-time, etc.), but 15 sounds high. I seem to recall some of the
> things our find-openafs-kernels script found for Gutsy were not
> really kernel headers.
All of the gutsy kernels failed for me. I reran one of them this
morning and it succeeded.
Looking at the build-openafs code a bit more, it follows the same
pattern as debathenificator: set up a package directory in /tmp and then
build it in a session chroot. I'm probably falling prey to the same
memory corruption bug in LVM snapshot creation.
I can either do the same workaround (create schroot session, then set
up /tmp directory) or I can try to find a kernel which does not have
this LVM snapshot bug. Someone on the linux-lvm list asked me to try
reproducing the corruption problem with a development Linux kernel, so
perhaps I will do that. Either I'll advance the LVM plot or I'll have a
more stable build machine.
