Date: Tue, 15 Dec 2015 08:58:43 -0700 From: Ian Lepore <ian@freebsd.org> To: Karl Denninger <karl@denninger.net>, "freebsd-arm@freebsd.org" <freebsd-arm@freebsd.org> Subject: Re: Updating / keeping current strategies? Message-ID: <1450195123.25138.42.camel@freebsd.org> In-Reply-To: <567031C9.2090109@denninger.net> 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>
next in thread | previous in thread | raw e-mail | index | archive | help
On Tue, 2015-12-15 at 09:29 -0600, Karl Denninger wrote: > 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. > > > > > 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. > Oh, you can't do that. The pathnames in the obj directory are correct for the build machine, but wrong when nfs-mounted on another machine. 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. 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> > 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 [ntpd stuff snipped]
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1450195123.25138.42.camel>