Updating / keeping current strategies?

[Ian Lepore]

On Tue, 2015-12-15 at 09:29 -0600, Karl Denninger wrote:
> On 12/15/2015 08:46, Ian Lepore wrote:
> > On Mon, 2015-12-14 at 11:54 -0600, Karl Denninger wrote:
> > > On 12/14/2015 10:13, Karl Denninger wrote:
> > > > On 12/8/2015 09:41, Paul Mather wrote:
> > > > > On Dec 8, 2015, at 10:13 AM, Karl Denninger <
> > > > > karl at denninger.net>
> > > > > wrote:
> > > > > 
> > > > > > What are people doing in this regard with devices like the
> > > > > > Raspberry Pi2?
> > > > > > 
> > > > > > Build times for a "make buildworld" are measured in (many)
> > > > > > hours to a
> > > > > > day or more and require a USB-attached disk for temporary
> > > > > > storage, as
> > > > > > the ramdisk for /tmp that is typically mounted blows up due
> > > > > > to
> > > > > > lack of
> > > > > > space and SD cards are slow enough on writes (especially
> > > > > > small
> > > > > > writes)
> > > > > > as to make the process virtually impossible.  But even with
> > > > > > a
> > > > > > USB-attached disk the process is ridiculous in terms of
> > > > > > consumed
> > > > > > walllclock time.
> > > > > > 
> > > > > > Further, "make installworld" sometimes fails inexplicably.
> > > > > > 
> > > > > > Kernel builds are a bit more reasonable, only requiring a
> > > > > > couple of hours.
> > > > > > 
> > > > > > I'm wondering what the best option is to not only build
> > > > > > current
> > > > > > code on
> > > > > > a regular basis (since -CURRENT is a "work in progress")
> > > > > > but
> > > > > > also to
> > > > > > deploy and update existing devices.  What are people doing
> > > > > > that
> > > > > > has a
> > > > > > history of working well?
> > > > > I cross-build kernel and world on a FreeBSD/amd64 system.  It
> > > > > takes about 30 minutes to do a full buildkernel and
> > > > > buildworld
> > > > > there.  Then, when I want to update my Raspberry Pi, I shut
> > > > > down
> > > > > the Pi and move the SD card from it to the FreeBSD/amd64
> > > > > system. 
> > > > >  Having mounted the SD card, I cross-install kernel and world
> > > > > onto the SD card and then run mergemaster against it.  I use
> > > > > the
> > > > > wrapper script from 
> > > > > https://wiki.freebsd.org/FreeBSD/arm/crossbuild to make
> > > > > things
> > > > > easier.
> > > > > 
> > > > > After updating the SD card, I unmount it from the
> > > > > FreeBSD/amd64
> > > > > system and move it back to the Raspberry Pi.  Finally, I boot
> > > > > up
> > > > > the Raspberry Pi.
> > > > > 
> > > > > This has proved a reliable way for me to update my Raspberry
> > > > > Pi
> > > > > and BeagleBone Black.  The manual step of moving the SD card
> > > > > isn't ideal, but has proved to be the most pragmatic approach
> > > > > for
> > > > > me.  (Clang seems more reliable on FreeBSD/amd64, for one.:) 
> > > > >  Someone suggested once to do the cross build/install on the
> > > > > FreeBSD/amd64 system and then rsync over to the Pi/BBB to
> > > > > update
> > > > > the SD card, but I could never get that to work.  Similarly,
> > > > > I
> > > > > could never get a NFS install to work either.  To be fair, I
> > > > > didn't troubleshoot that problem very much.
> > > > > 
> > > > > Cheers,
> > > > > 
> > > > > Paul.
> > > > > 
> > > > There seem to be some problems with this in the general sense,
> > > > unless
> > > > you're willing to move the media around (I'm generally not.)
> > > > 
> > > > Using that script in the Wiki appears to work, but there are
> > > > problems. 
> > > > If you try to nfs mount the object and source directories on
> > > > the
> > > > target
> > > > so you can do a "make installworld" or "make installkernel" on
> > > > the
> > > > target you quickly find that clang wasn't cross-built in the
> > > > object
> > > > directory; the "tmp" directory in object contains a copy of it,
> > > > but
> > > > it's
> > > > compiled for your _*source*_ machine (in this case
> > > > FreeBSD/amd64)
> > > > and
> > > > the install blows up as it can't determine the cc version.  The
> > > > interesting thing is that what's in ~/nfsroot/usr/bin/cc is
> > > > correct
> > > > which doesn't appear to make sense, but it is what it is.
> > > > 
> > > > I'm going to see if I can get a rsync-type thing to work....
> > > > 
> > > It.... gets.... worse.
> > > 
> > > I can update using rsync.  However, the armv6hf target given in
> > > the
> > > wiki
> > > at https://wiki.freebsd.org/FreeBSD/arm/crossbuild produces
> > > binaries
> > > that blow up when floating point is attempted.  Armv6 is
> > > deprecated
> > > and
> > > won't build at all.
> > > 
> > I'm having a hard time understanding this.  Nobody else is
> > reporting
> > problems with cross-built binaries that use floating point.  Also,
> > armv6 is deprecated only in the sense that armv6hf is more
> > efficient
> > and there's no reason to use the old softfp ABI anymore.  But that
> > doesn't mean it can't be built, it builds and cross-builds just
> > fine.
> > 
> > -- Ian
> 
> Well, I'm reporting what I got.  I followed the instructions in the
> Wiki, got a product nfsroot directory and the expected src and obj
> directories, attempted to mount the src and obj directories over nfs
> and
> execute a "make installworld" on the target and that blew up with
> complaints about expected directories being missing.
> 

Oh, you can't do that.  The pathnames in the obj directory are correct
for the build machine, but wrong when nfs-mounted on another machine.

The instructions in the wiki page you cited are how to set up a
development environment that uses an nfs-mounted root directory.  You
can also use it as a source for rsync, but you can't install directly
from the objdir of such a build environment using an nfs mount unless
the target system has the exact directory layout of the build system
after nfs-mounting the source and obj dirs.

Another way to make it work is to nfs-mount the target's root directory
on your build machine, then you can make installworld DESTDIR=<mountpt>

> I then attempted to rsync the nfsroot directory to the target machine
> (a
> Raspberry Pi2); that succeeded.  But, once the machine was rebooted
> any
> attempt to execute anything that had floating point operations
> dumped;
> "awk", for example, blows up.
> 

I built on a 10.2-STABLE machine, if that matters.
> 

Using a kernel and world built yesterday for armv6hf...

    root at wand    :~ # awk "BEGIN {print 2.7+4.2 }"
    6.9

I do all my building on a 10-stable machine.

I wonder if your first attempt to installworld somehow installed some
x86 stuff by accident and now you've got a mixed/broken world, and rsyn
c didn't fix it because some of the broken files were more recent?

-- Ian

[ntpd stuff snipped]