Updating / keeping current strategies?

[Karl Denninger]

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.

This is bad for obvious reasons; it looks like cross-compile may APPEAR
to work but in fact it does not.

I have managed to mount (via NFS) the object and source directories from
one Pi2 to another (having used the first as the build environment), and
can installworld and installkernel this way, much like I would
otherwise.... the performance isn't great, but it works.

-- 
Karl Denninger
karl at denninger.net <mailto:karl at denninger.net>
/The Market Ticker/
/[S/MIME encrypted email preferred]/
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 2996 bytes
Desc: S/MIME Cryptographic Signature
URL: <http://lists.freebsd.org/pipermail/freebsd-arm/attachments/20151214/4205b104/attachment.bin>