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
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:38 UTC