Updating / keeping current strategies?

Tue Dec 15 17:08:12 UTC 2015

On 12/15/2015 11:02, Ian Lepore wrote:
> On Tue, 2015-12-15 at 10:22 -0600, Karl Denninger wrote:
>> Well, but they are if I maintain the paths.
>>
>> Example: I have the build at /pics/CrossBuild on the source (10.2
>> -STABLE
>> amd64) machine.
>> I export /pics/CrossBuild.
>>
>> I then mount that at /pics/CrossBuild on the target.  Now the paths
>> are
>> the same.
>>
>> But..... when I try to do a "make installkernel" as you would do if
>> doing this on a consistent architecture what I get is this:
>>
>> root at Pool-MCP:/pics/CrossBuild # ./mk installkernel
>> TARGET_ARCH=armv6hf
>> + cd /pics/CrossBuild/src
>> + nice -10 make -j 4 -DNO_CLEAN 'TARGET_ARCH=armv6hf'
>> 'DESTDIR=/pics/CrossBuild/nfsroot'
>> '__MAKE_CONF=/pics/CrossBuild/config/make.conf'
>> 'srcconf=/pics/CrossBuild/config/src.conf' 'KERNCONF=RPI2'
>> 'UBLDR_LOADADDR=0x2000000' installkernel 'TARGET_ARCH=armv6hf'
>> --- installkernel ---
>> --- installkernel ---
>> --------------------------------------------------------------
>>>>> Installing kernel RPI2
>> --------------------------------------------------------------
>> cd /pics/CrossBuild/obj/arm.armv6hf/pics/CrossBuild/src/sys/RPI2; 
>> MAKEOBJDIRPREFIX=/pics/CrossBuild/obj/arm.armv6hf 
>>  MACHINE_ARCH=armv6hf 
>> MACHINE=arm  CPUTYPE=
>> GROFF_BIN_PATH=/pics/CrossBuild/obj/arm.armv6hf/pics/CrossBuild/src/t
>> mp/legacy/usr/bin 
>> GROFF_FONT_PATH=/pics/CrossBuild/obj/arm.armv6hf/pics/CrossBuild/src/
>> tmp/legacy/usr/share/groff_font 
>> GROFF_TMAC_PATH=/pics/CrossBuild/obj/arm.armv6hf/pics/CrossBuild/src/
>> tmp/legacy/usr/share/tmac
>> CC="cc " CXX="c++  "  DEPFLAGS=""  CPP="cpp "  AS="as" AR="ar"
>> LD="ld"
>> NM=nm  OBJDUMP=objdump OBJCOPY="objcopy"  RANLIB=ranlib STRINGS= 
>> SIZE="size"
>> PATH=/pics/CrossBuild/obj/arm.armv6hf/pics/CrossBuild/src/tmp/legacy/
>> usr/sbin:/pics/CrossBuild/obj/arm.armv6hf/pics/CrossBuild/src/tmp/leg
>> acy/usr/bin:/pics/CrossBuild/obj/arm.armv6hf/pics/CrossBuild/src/tmp/
>> legacy/bin:/pics/CrossBuild/obj/arm.armv6hf/pics/CrossBuild/src/tmp/u
>> sr/sbin:/pics/CrossBuild/obj/arm.armv6hf/pics/CrossBuild/src/tmp/usr/
>> bin:/sbin:/bin:/usr/sbin:/usr/bin 
>> make  KERNEL=kernel install
>> sh: cc: Exec format error
>> make[2]: "/pics/CrossBuild/src/share/mk/bsd.compiler.mk" line 137:
>> Unable to determine compiler type for cc .  Consider setting
>> COMPILER_TYPE.
>> *** [installkernel] Error code 1
>>
>> make[1]: stopped in /pics/CrossBuild/src
>> 1 error
>>
>> make[1]: stopped in /pics/CrossBuild/src
>> *** [installkernel] Error code 2
>>
>> make: stopped in /pics/CrossBuild/src
>> 1 error
>>
>> make: stopped in /pics/CrossBuild/src
>> root at Pool-MCP:/pics/CrossBuild #
>>
>> When investigating this what I find is that the executable in the
>> path
>> for "cc" is in fact an arm64 executable!  So I have a built system
>> but
>> no way to install it.
>>
>>
>>> 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.
>> Except that doesn't work because the PATH contains executables for
>> the
>> source which is a different architecture.
>>
>> And when I tried to rsync it I got a system that booted and ran, sort
>> of, but anything that did floating point blew up.  That might be
>> because
>> of schg flags prevented some of the copies and rsync has no good way
>> to
>> get around that (removing them from the target is undesirable for all
>> the obvious reasons.)
>>
>>> 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>
>> That's an interesting idea that I will look into. It's undesirable
>> for a
>> number of reasons down the road (enabling nfs server on these
>> machines
>> isn't my idea of a good thing over time) but it might get me going
>> for
>> the moment.
>>>> 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
>> Maybe.  But I don't think so; I suspect the issue revolves around
>> schg
>> flags (in other words some things didn't update) and if so it's a
>> problem since I don't believe rsync can deal with that.
>>
> I had forgotten about the "can't determine compiler" error, other
> people have reported that too.  It's another roadblock that adds up to
> "you can't do that" (install a crossbuilt system by mounting the objdir
> on the target).  The way the crossbuild works is to create a bunch of
> cross-tools and put them in a PATH that makes them get used before the
> standard system tools; they're still there at install time.  I'm not
> sure it's impossible to cross-build then non-cross install, but it
> certainly can't be done with the way the build system currently works.
>
> At $work we deal with updating by having readonly rootfs and all
> modified data on a different filesystem.  We have two slices for rootfs
> so if we're running from slice 1 we newfs then populate slice 2, switch
> the active flag in the MBR, and reboot.  Warner has recently been
> adding similar features to nanobsd, so it may be available as a
> solution for this stuff pretty soon.
>
> -- Ian
>
Thanks...

This is turning into a production .vs. development issue here in that
I'm working on a home automation package that I intend to distribute and
will run under FreeBSD on the Pi2.  It's working extremely well and will
bring down the price-point of such things in a big way (because the
hardware is so cheap) while allowing all sorts of interesting things
(like direct measurement analog inputs and relay-switched outputs.)

But to do this and make it workable I have to be able to update a number
of these machines consistently and, since -CURRENT is not really
recommended for any sort of production anything (and -STABLE won't run
on the Pi2) I am stuck with "gotta find a way to get 'stable enough'
code" that I can point people at and is able to be reproduced "on demand."

-- 
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/2dc68198/attachment.bin>