Date: Tue, 15 Dec 2015 09:29:13 -0600 From: Karl Denninger <karl@denninger.net> To: "freebsd-arm@freebsd.org" <freebsd-arm@freebsd.org> Subject: Re: Updating / keeping current strategies? Message-ID: <567031C9.2090109@denninger.net> In-Reply-To: <1450190791.25138.30.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>
next in thread | previous in thread | raw e-mail | index | archive | help
This is a cryptographically signed message in MIME format. --------------ms070903070802050207080900 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable 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@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.=20 >>>> 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=20 >>>> 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.:)=20 >>>> 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.=20 >>> 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=20 jitter =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D=3D= =3D=3D=3D 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 =20 karl@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. --=20 Karl Denninger karl@denninger.net <mailto:karl@denninger.net> /The Market Ticker/ /[S/MIME encrypted email preferred]/ --------------ms070903070802050207080900 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 hvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0xNTEyMTUxNTI5MTNaME8GCSqGSIb3DQEJBDFCBED6 4XWi0rsoy+BviTecqpyeffA9MLxvZYq2sXvxR49+2qxx/PE5CK4unCB34WrkNF6SaNa8b+VB gdfgZm3RFFTjMGwGCSqGSIb3DQEJDzFfMF0wCwYJYIZIAWUDBAEqMAsGCWCGSAFlAwQBAjAK BggqhkiG9w0DBzAOBggqhkiG9w0DAgICAIAwDQYIKoZIhvcNAwICAUAwBwYFKw4DAgcwDQYI KoZIhvcNAwICASgwgacGCSsGAQQBgjcQBDGBmTCBljCBkDELMAkGA1UEBhMCVVMxEDAOBgNV BAgTB0Zsb3JpZGExEjAQBgNVBAcTCU5pY2V2aWxsZTEZMBcGA1UEChMQQ3VkYSBTeXN0ZW1z IExMQzEcMBoGA1UEAxMTQ3VkYSBTeXN0ZW1zIExMQyBDQTEiMCAGCSqGSIb3DQEJARYTQ3Vk YSBTeXN0ZW1zIExMQyBDQQIBKTCBqQYLKoZIhvcNAQkQAgsxgZmggZYwgZAxCzAJBgNVBAYT AlVTMRAwDgYDVQQIEwdGbG9yaWRhMRIwEAYDVQQHEwlOaWNldmlsbGUxGTAXBgNVBAoTEEN1 ZGEgU3lzdGVtcyBMTEMxHDAaBgNVBAMTE0N1ZGEgU3lzdGVtcyBMTEMgQ0ExIjAgBgkqhkiG 9w0BCQEWE0N1ZGEgU3lzdGVtcyBMTEMgQ0ECASkwDQYJKoZIhvcNAQEBBQAEggIAZIkGgjVe lHDafyR3S8CuSux1JWeqMU3gKIRbV3xqfU68t9GYuhDuqfdkcvvLjDZ+x0jOUaVQS3ZJxkM1 DZDwBCLKLA32UBQ1Ay7VdDsDNSq5JQd3yu+w+IPqTdxL/TwP1x1UiqJjy/Y0OxadtKtt4bwt Aaq3f+liY5ecNkHJNw0dQatxmmF9KF46vtkQ3Xzil7d+iLPhVlSpMjzNKDrD+ihnMGKU39G4 9MzwNvAaKJ67W87NIkwus5JGfYENa33/UgBf8OvT3H5/AzZgDqUu9CYInBsP3NmM94QMej8n 0o5rIC1/CfaJ7Cq9fBBQGvI7AJJOhhx/tB0zpCs+hSNEF10disOTqa14efU2DWlZxWOgB5X0 ZpkOTYAEb3wZjKhN9uqqdMMiqQ9lq8IeMQ3RyJ83bbbYQVjai1sR0gxpwFA4C+IDaYcHRiKN HVm+xB4yKXSTqoFBvT5CiYL6JUxRQGfyfrVNUE0qPDxYvo1sTrhPOWvInh1g8BGTNpI39SGi L5GBMAH4WDcxdkrUAnhouSR13MU55VFBKjkzWqQP5wmT3RiE9QKI8HVfkRipNdF2ZjCP9yYY 3Tz01MV5M51Q7bvS+zG4CLyqCkgIFxN4kPPuudeg8367To5vHAsNVUYBD7oPF91YcMhT6fsj DNmkgsAowPnVNJQWhivPlY4wOBgAAAAAAAA= --------------ms070903070802050207080900--
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?567031C9.2090109>