Skip site navigation (1)Skip section navigation (2)
Date:      Sat, 8 Jun 2013 13:34:11 -0400
From:      Glen Barber <gjb@FreeBSD.org>
To:        Jimmy <jimmy.kelley@charter.net>
Cc:        freebsd-current@freebsd.org
Subject:   Re: 10-CURRENT i386 memstick snapshots broken?
Message-ID:  <20130608173411.GD13292@glenbarber.us>
In-Reply-To: <20130607212256.GG38117@glenbarber.us>
References:  <20130607205129.GA1103@jmobile.jimmy.net> <20130607212256.GG38117@glenbarber.us>

next in thread | previous in thread | raw e-mail | index | archive | help

--48TaNjbzBVislYPb
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

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?
> >=20
>=20
> 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.
>=20

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
=66rom 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


--48TaNjbzBVislYPb
Content-Type: application/pgp-signature

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v2.0.20 (FreeBSD)

iQEcBAEBCAAGBQJRs2sTAAoJEFJPDDeguUajjWEIAKBez9XkiAXCE7jj67tVz/D7
YRYM/a94+Gs32Lto/DLwBy96XdS82qLEI+WElOlvripHUzFtUO7Oq9NNRK2QvyZu
daA156v5t2rZ1WQXh/WrIuJT5S0Ia6v6WlrjJWukjGPBFWnmIzGFwAv9YTykfqmq
mNhe/7203YtTYb10pSQegZzvlht1jxTBU9uwIV45zaiBcTNV8cNdu1FRQiHmPGUf
wXSNhx2dvlmC9Y1Uy7QVD70mN6tgT6T2vc0TdAx3HKYbGXeZcoHtxIOUgGrlm7rp
EOkad8cbtur0PifmFzXo1sFln9SYwTgDdOAsS5hfuerw6gxjvDiZRQspx34qkoo=
=bl3e
-----END PGP SIGNATURE-----

--48TaNjbzBVislYPb--



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20130608173411.GD13292>