Re: 10-CURRENT i386 memstick snapshots broken?

From: Glen Barber <gjb_at_FreeBSD.org>
Date: Sat, 8 Jun 2013 13:34:11 -0400
On Fri, Jun 07, 2013 at 05:22:56PM -0400, Glen Barber wrote:
> > Has anyone else tried the i386 memstick and having the same problem?
> > 
> 
> Hmm.  Thanks for the report.  I'll take a look at the logs for i386, but
> they are generated the same way as the amd64, so in theory should not
> have any noticable difference.
> 

Jimmy, thank you for reporting this.  I'm honestly not quite sure how
this went unnoticed for so long.

So, basically here is what happens:

The scripts that run the weekly snapshot builds on FreeBSD.org check out
clean svn trees of head/ and stable/9 to use to "seed" chroot
environments, where the builds actually happen.

For amd64 and i386, native binaries are built, and installed into
scratch directories; for powerpc and powerpc64, I just use the amd64
binaries, because I cannot directly use the chroot binaries for
non-native architecture.

The scripts chroot into the scratch directories, and run the "real"
release builds.  As Jimmy noted, the
src/release/${ARCH}/make-memstick.sh script is what generates the
memstick images.  Part of that procedure is to create md(4) device, and
partition layout with gpart(8).  This is where things blow up.

Because the userland is 32-bit and the kernel is 64-bit, "something"
goes wrong, but interestingly not wrong enough that the script fails
entirely.  So, the paritions appear to be created, but in reality, they
are not.

So, for the snapshots case, the solution is to write the memstick image
from outside of the chroot environment, which is easy to do because
I already do this for creating the VM disk images (interestingly for the
same reason as the memstick creation failure).

Thanks to Jimmy for his patience in helping me make sure my solution
does in fact fix the problem, and the next set of 10.0-CURRENT and
9.1-STABLE i386 memsticks will not have this issue (builds are in-flight
now).

Glen


Received on Sat Jun 08 2013 - 15:34:20 UTC

This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:38 UTC