Updating / keeping current strategies?

Tue Dec 15 15:29:58 UTC 2015

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.

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.

There appears to be something else odd going on with recent -CURRENT
builds on RPI2s.  I built on an Rpi2, mounted src and obj directories
over NFS to the target and (apparently successfully) did a "make
install" after setting TMPDIR to /var/tmp (attempting to go to the
memdisk for /tmp runs out of space) -- specifically, everything "mostly"
appears to be working but I am getting this in ntp:

ntpq> peer
     remote           refid      st t when poll reach   delay   offset 
jitter
==============================================================================
 FS.Denninger.ne .GPS.            1 u   48   64  377  1000.00  -109.55
1000.00
ntpq>

And of course it won't lock with the delay and jitter being what they
are there (those are not valid).  That also looks like a floating-point
problem and it is with a current build on a RPI2 and then installed over
NFS.

FreeBSD 11.0-CURRENT #3 r291949M: Mon Dec  7 13:37:41 CST 2015    
karl at IPGw.Denninger.Net:/mnt/obj/mnt/usr/src/sys/RPI2

I've updated to be current as of this morning and am attempting another
build to see if I can isolate what went wrong in that regard.

-- 
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/20151215/06040935/attachment.bin>