Date: Tue, 15 Dec 2015 11:07:27 -0600 From: Karl Denninger <karl@denninger.net> To: "freebsd-arm@freebsd.org" <freebsd-arm@freebsd.org> Subject: Re: Updating / keeping current strategies? Message-ID: <567048CF.1000803@denninger.net> In-Reply-To: <1450198950.25138.50.camel@freebsd.org> References: <5666F37C.4060908@denninger.net> <10BBDDBB-75AA-4034-B494-9EB28D009882@gromit.dlib.vt.edu> <566EEAC4.1060306@denninger.net> <566F0238.9060605@denninger.net> <1450190791.25138.30.camel@freebsd.org> <567031C9.2090109@denninger.net> <1450195123.25138.42.camel@freebsd.org> <56703E2D.8050504@denninger.net> <1450198950.25138.50.camel@freebsd.org>
next in thread | previous in thread | raw e-mail | index | archive | help
This is a cryptographically signed message in MIME format.
--------------ms050903080109000306000300
Content-Type: text/plain; charset=windows-1252
Content-Transfer-Encoding: quoted-printable
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@Pool-MCP:/pics/CrossBuild # ./mk installkernel
>> TARGET_ARCH=3Darmv6hf
>> + cd /pics/CrossBuild/src
>> + nice -10 make -j 4 -DNO_CLEAN 'TARGET_ARCH=3Darmv6hf'
>> 'DESTDIR=3D/pics/CrossBuild/nfsroot'
>> '__MAKE_CONF=3D/pics/CrossBuild/config/make.conf'
>> 'srcconf=3D/pics/CrossBuild/config/src.conf' 'KERNCONF=3DRPI2'
>> 'UBLDR_LOADADDR=3D0x2000000' installkernel 'TARGET_ARCH=3Darmv6hf'
>> --- installkernel ---
>> --- installkernel ---
>> --------------------------------------------------------------
>>>>> Installing kernel RPI2
>> --------------------------------------------------------------
>> cd /pics/CrossBuild/obj/arm.armv6hf/pics/CrossBuild/src/sys/RPI2;=20
>> MAKEOBJDIRPREFIX=3D/pics/CrossBuild/obj/arm.armv6hf=20
>> MACHINE_ARCH=3Darmv6hf=20
>> MACHINE=3Darm CPUTYPE=3D
>> GROFF_BIN_PATH=3D/pics/CrossBuild/obj/arm.armv6hf/pics/CrossBuild/src/=
t
>> mp/legacy/usr/bin=20
>> GROFF_FONT_PATH=3D/pics/CrossBuild/obj/arm.armv6hf/pics/CrossBuild/src=
/
>> tmp/legacy/usr/share/groff_font=20
>> GROFF_TMAC_PATH=3D/pics/CrossBuild/obj/arm.armv6hf/pics/CrossBuild/src=
/
>> tmp/legacy/usr/share/tmac
>> CC=3D"cc " CXX=3D"c++ " DEPFLAGS=3D"" CPP=3D"cpp " AS=3D"as" AR=3D=
"ar"
>> LD=3D"ld"
>> NM=3Dnm OBJDUMP=3Dobjdump OBJCOPY=3D"objcopy" RANLIB=3Dranlib STRING=
S=3D=20
>> SIZE=3D"size"
>> PATH=3D/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=20
>> make KERNEL=3Dkernel 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@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.=20
>>> 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=3D<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@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.=
"
--=20
Karl Denninger
karl@denninger.net <mailto:karl@denninger.net>
/The Market Ticker/
/[S/MIME encrypted email preferred]/
--------------ms050903080109000306000300
Content-Type: application/pkcs7-signature; name="smime.p7s"
Content-Transfer-Encoding: base64
Content-Disposition: attachment; filename="smime.p7s"
Content-Description: S/MIME Cryptographic Signature
MIAGCSqGSIb3DQEHAqCAMIACAQExDzANBglghkgBZQMEAgMFADCABgkqhkiG9w0BBwEAAKCC
Bl8wggZbMIIEQ6ADAgECAgEpMA0GCSqGSIb3DQEBCwUAMIGQMQswCQYDVQQGEwJVUzEQMA4G
A1UECBMHRmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3Rl
bXMgTExDMRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhND
dWRhIFN5c3RlbXMgTExDIENBMB4XDTE1MDQyMTAyMjE1OVoXDTIwMDQxOTAyMjE1OVowWjEL
MAkGA1UEBhMCVVMxEDAOBgNVBAgTB0Zsb3JpZGExGTAXBgNVBAoTEEN1ZGEgU3lzdGVtcyBM
TEMxHjAcBgNVBAMTFUthcmwgRGVubmluZ2VyIChPQ1NQKTCCAiIwDQYJKoZIhvcNAQEBBQAD
ggIPADCCAgoCggIBALmEWPhAdphrWd4K5VTvE5pxL3blRQPyGF3ApjUjgtavqU1Y8pbI3Byg
XDj2/Uz9Si8XVj/kNbKEjkRh5SsNvx3Fc0oQ1uVjyCq7zC/kctF7yLzQbvWnU4grAPZ3IuAp
3/fFxIVaXpxEdKmyZAVDhk9az+IgHH43rdJRIMzxJ5vqQMb+n2EjadVqiGPbtG9aZEImlq7f
IYDTnKyToi23PAnkPwwT+q1IkI2DTvf2jzWrhLR5DTX0fUYC0nxlHWbjgpiapyJWtR7K2YQO
aevQb/3vN9gSojT2h+cBem7QIj6U69rEYcEDvPyCMXEV9VcXdcmW42LSRsPvZcBHFkWAJqMZ
Myiz4kumaP+s+cIDaXitR/szoqDKGSHM4CPAZV9Yh8asvxQL5uDxz5wvLPgS5yS8K/o7zDR5
vNkMCyfYQuR6PAJxVOk5Arqvj9lfP3JSVapwbr01CoWDBkpuJlKfpQIEeC/pcCBKknllbMYq
yHBO2TipLyO5Ocd1nhN/nOsO+C+j31lQHfOMRZaPQykXVPWG5BbhWT7ttX4vy5hOW6yJgeT/
o3apynlp1cEavkQRS8uJHoQszF6KIrQMID/JfySWvVQ4ksnfzwB2lRomrdrwnQ4eG/HBS+0l
eozwOJNDIBlAP+hLe8A5oWZgooIIK/SulUAsfI6Sgd8dTZTTYmlhAgMBAAGjgfQwgfEwNwYI
KwYBBQUHAQEEKzApMCcGCCsGAQUFBzABhhtodHRwOi8vY3VkYXN5c3RlbXMubmV0Ojg4ODgw
CQYDVR0TBAIwADARBglghkgBhvhCAQEEBAMCBaAwCwYDVR0PBAQDAgXgMCwGCWCGSAGG+EIB
DQQfFh1PcGVuU1NMIEdlbmVyYXRlZCBDZXJ0aWZpY2F0ZTAdBgNVHQ4EFgQUxRyULenJaFwX
RtT79aNmIB/u5VkwHwYDVR0jBBgwFoAUJHGbnYV9/N3dvbDKkpQDofrTbTUwHQYDVR0RBBYw
FIESa2FybEBkZW5uaW5nZXIubmV0MA0GCSqGSIb3DQEBCwUAA4ICAQBPf3cYtmKowmGIYsm6
eBinJu7QVWvxi1vqnBz3KE+HapqoIZS8/PolB/hwiY0UAE1RsjBJ7yEjihVRwummSBvkoOyf
G30uPn4yg4vbJkR9lTz8d21fPshWETa6DBh2jx2Qf13LZpr3Pj2fTtlu6xMYKzg7cSDgd2bO
sJGH/rcvva9Spkx5Vfq0RyOrYph9boshRN3D4tbWgBAcX9POdXCVfJONDxhfBuPHsJ6vEmPb
An+XL5Yl26XYFPiODQ+Qbk44Ot1kt9s7oS3dVUrh92Qv0G3J3DF+Vt6C15nED+f+bk4gScu+
JHT7RjEmfa18GT8DcT//D1zEke1Ymhb41JH+GyZchDRWtjxsS5OBFMzrju7d264zJUFtX7iJ
3xvpKN7VcZKNtB6dLShj3v/XDsQVQWXmR/1YKWZ93C3LpRs2Y5nYdn6gEOpL/WfQFThtfnat
HNc7fNs5vjotaYpBl5H8+VCautKbGOs219uQbhGZLYTv6okuKcY8W+4EJEtK0xB08vqr9Jd0
FS9MGjQE++GWo+5eQxFt6nUENHbVYnsr6bYPQsZH0CRNycgTG9MwY/UIXOf4W034UpR82TBG
1LiMsYfb8ahQJhs3wdf1nzipIjRwoZKT1vGXh/cj3gwSr64GfenURBxaFZA5O1acOZUjPrRT
n3ci4McYW/0WVVA3lDGCBRMwggUPAgEBMIGWMIGQMQswCQYDVQQGEwJVUzEQMA4GA1UECBMH
RmxvcmlkYTESMBAGA1UEBxMJTmljZXZpbGxlMRkwFwYDVQQKExBDdWRhIFN5c3RlbXMgTExD
MRwwGgYDVQQDExNDdWRhIFN5c3RlbXMgTExDIENBMSIwIAYJKoZIhvcNAQkBFhNDdWRhIFN5
c3RlbXMgTExDIENBAgEpMA0GCWCGSAFlAwQCAwUAoIICTTAYBgkqhkiG9w0BCQMxCwYJKoZI
hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNTEyMTUxNzA3MjdaME8GCSqGSIb3DQEJBDFCBEAq
VKTTuZ2R3/qOo8UIh6UDZmZc7nPppQm/e3/dA5khHQSKQTT6BF5QuI5VumEUUQzxm7xpAzaz
oZHRF8NZw4u8MGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK
BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI
KoZIhvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNV
BAgTB0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1z
IExMQzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3Vk
YSBTeXN0ZW1zIExMQyBDQQIBKTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYT
AlVTMRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1
ZGEgU3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG
9w0BCQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECASkwDQYJKoZIhvcNAQEBBQAEggIAEV8WGSKy
8kkTEb5Q8IAKOiCy/snEWGAd2Xguk29slfdhRyLBZ2c2nQTwpBc1KZHF8o0Vydi46mpAFxfN
crpgv9F8QUjlilF3Y1V2xIsy7/+ChFb/mn2UFkbpRfRmVrJMcVASzPPv65oeiVTv6NafMjLr
sEg1ZU4Bklr4Q0ZLO/gWSs0YD1FMpkwxaOwiLpzhKe7ryfIc0EYlOn5+u2mkeV+9Ka/uCzFO
mS83r7njmVRwE5N157YBf14368fmqRuZgKpkMKRnW4IwINeVRtIY/d0kGS1g9a1UMfED2Pc9
SKnDF5dsw2YVoNEkCf3/NSLsYH5hIdMAWtJCtCT0MAoiAJew1pprC3ne1gI2qRka3rhAcG11
nDZtSNe097fVmpX0vtbKgkYNRrRzc/hi6mo5ln+o/O5y7KNIWM7RKAqE3ReigAbUZUPgwCCA
VgGCRpHjFQoNndyc0Ap148D8qFSTuqIg81/hI/2TsFpg/RTiIVW/3E+/icpESfcCDP055Cby
M9k5NUHi/zqmfSJ3eEn9JlA0ghgFr2E7lxJYu9PyUnJiI0hG2DJfmUpNXUB3Gg9Z9X2BI2ut
JFMkkgmqDufF/5bE40pMraWSiJpqUNuUEE/BmDGZ6I+bzNvphZzV7vg86QE2d6/Hixdieakm
atW90d3jpVJMI3s8Git6fxue38UAAAAAAAA=
--------------ms050903080109000306000300--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?567048CF.1000803>