From owner-freebsd-arm@freebsd.org Mon Jul 25 23:13:19 2016 Return-Path: Delivered-To: freebsd-arm@mailman.ysv.freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) by mailman.ysv.freebsd.org (Postfix) with ESMTP id BD9EDBA49BF for ; Mon, 25 Jul 2016 23:13:19 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from gromit.dlib.vt.edu (gromit.dlib.vt.edu [128.173.126.120]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client CN "gromit.dlib.vt.edu", Issuer "Chumby Certificate Authority" (not verified)) by mx1.freebsd.org (Postfix) with ESMTPS id 93ED31D3C; Mon, 25 Jul 2016 23:13:19 +0000 (UTC) (envelope-from paul@gromit.dlib.vt.edu) Received: from mather.chumby.lan (c-71-63-91-41.hsd1.va.comcast.net [71.63.91.41]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by gromit.dlib.vt.edu (Postfix) with ESMTPSA id EA55E145; Mon, 25 Jul 2016 19:03:23 -0400 (EDT) From: Paul Mather Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Subject: Using packaged base with FreeBSD/arm Date: Mon, 25 Jul 2016 19:03:23 -0400 Message-Id: <2A1CEA39-A263-451C-A5FC-F8E223A22746@gromit.dlib.vt.edu> Cc: Glen Barber To: freebsd-arm Mime-Version: 1.0 (Mac OS X Mail 9.3 \(3124\)) X-Mailer: Apple Mail (2.3124) X-BeenThere: freebsd-arm@freebsd.org X-Mailman-Version: 2.1.22 Precedence: list List-Id: "Porting FreeBSD to ARM processors." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 25 Jul 2016 23:13:19 -0000 A recent thread on freebsd-arm concerned how best to upgrade FreeBSD/arm = systems such as Raspberry Pi, BeagleBone Black, etc. via cross-building = on a fast host (e.g., FreeBSD/amd64 system). In particular, how do you = actually update the SD card on the FreeBSD/arm system without physically = having to move the SD card to the cross-build machine? Various methods = such as using rsync, cpdup, NFS, etc. proved problematic due to handling = of special file system flags or the fact that a rsync/cpdup isn't doing = exactly the same thing as installworld/installkernel appears to do. So, with that in mind, I decided over the weekend to give the new = packaging of base a try as a method of updating my 11-STABLE FreeBSD/arm = systems. I'm happy to report that it went very well! I now have the = build system I use to cross-build packages from ports for my FreeBSD/arm = systems also building base OS packages. I have managed to bootstrap a = Raspberry Pi B+, Raspberry Pi 2, and a BeagleBone Black with = FreeBSD-base packages. What's better is that this is without having to = move SD cards or wait for days as the system grinds through native = builds. :-) Congratulations to the PkgBase people! For those who might want to try this, I basically adapted my OS = cross-building environment (using the "mk" script from = https://wiki.freebsd.org/FreeBSD/arm/crossbuild) so that it also built a = PkgBase repo: --- mk.orig 2016-07-25 16:31:28.723973000 -0400 +++ mk 2016-07-24 20:43:45.278344000 -0400 @@ -9,7 +9,7 @@ # First set all tweakable variables to default values before loading # config/mk.conf which can override any of these defaults. -mk_arch=3D"armv6hf" +mk_arch=3D"armv6" mk_insdir=3D"$(pwd)/nfsroot" mk_jobs=3D"$(sysctl -n hw.ncpu)" mk_kernel=3D"GENERIC" @@ -19,6 +19,7 @@ mk_objdir=3D"$(pwd)/obj" mk_srcconf=3D"$(pwd)/config/src.conf" mk_srcdir=3D"$(pwd)/src" +mk_repodir=3D"$(pwd)/repo" mk_ubldraddr=3D"0x0" # If making a target that requires root privs, automatically add sudo. @@ -49,6 +50,8 @@ "__MAKE_CONF=3D${mk_makeconf}" \ "srcconf=3D${mk_srcconf}" \ "KERNCONF=3D${mk_kernel}" \ + "NO_INSTALLEXTRAKERNELS=3Dno" \ + "REPODIR=3D${mk_repodir}" \ "UBLDR_LOADADDR=3D${mk_ubldraddr}" \ ${mk_mkargs} \ "$@" I added the "NO_INSTALLEXTRAKERNELS=3Dno" because I want to build kernel = packages for each of the different ARM systems I have. For that reason, = I have this line in my "config/mk.conf" file: mk_kernel=3D"VIRT BEAGLEBONE RPI-B RPI2" I placed VIRT as the first kernel listed on purpose. I want it to be = the default one. To build my PkgBase repo, I have this script: #!/bin/sh mk buildworld mk buildkernel mk packages After that runs, I have a "FreeBSD:11:armv6" repo directory hierarchy in = my project "repo" directory (definable via mk_repodir in = config/mk.conf). I found the REPODIR variable by looking through the = build system Makefiles. I don't know whether this is the canonical way = to define where the repository lives, but it appears to work. It was then a matter of following the PkgBase project Wiki page = (https://wiki.freebsd.org/PkgBase) to serve this repository to my = FreeBSD/arm systems, and to add it as a "FreeBSD-base" repository to = each of them. I bootstrapped the systems using the PkgBase = instructions. Note that for the kernel I installed only the kernel package appropriate = for the target system's ARM board. So, on the BeagleBone Black system I = did a "pkg install FreeBSD-kernel-beaglebone" to install the BeagleBone = Black kernel package. The big wrinkle here is that it installs it to = /boot/kernel.KERNCONF, where "KERNCONF" is the kernel configuration file = name. So, in the case of my BeagleBone Black it installed the kernel = files to the /boot/kernel.BEAGLEBONE directory. So, in order to boot = successfully, I had to symlink /boot/kernel to /boot/kernel.BEAGLEBONE. As suggested by the PkgBase Wiki, I ran mergemaster after bootstrapping. = Unfortunately, I had a local /etc/src.conf that strips out a bunch of = components, and so mergemaster got rid of some things it probably should = not have (mainly in /etc/rc.d). I guess src.conf is not really supposed = to be used with PkgBase (i.e., the whole idea is not to install the = FreeBSD-tests package rather than exclude tests via "WITHOUT_TESTS=3Dyes" = in /etc/src.conf). When doing this on my other ARM systems I moved away = /etc/src.conf before running mergemaster. In my case, the initial bootstrap installed 400 packages + 1 package for = the appropriate kernel. I don't know whether this is an appropriate = number: I was expecting higher, as I recall a recent thread on = freebsd-current when a CFT went out for packaging base that stated there = were over 700 packages currently. There did appear to be a big = catch-all package, FreeBSD-runtime, that seemed to contain most of the = system binaries (/bin, /sbin, /usr/bin, /usr/sbin, etc.), and so maybe = the 700+ packages had that split apart into many more packages. I was nice that debug files could easily be removed via "pkg delete -g = 'FreeBSD-*-debug'" or that profile libraries could be expunged = similarly. Having bootstrapped the system, I'm not entirely sure how = granular updates are. I know that I will update via "pkg upgrade" but = upon what basis does pkg decide a FreeBSD-base package has been updated? = Is it the pkg version? If so, I know I can always force an upgrade = (re-installation of a package that is "new" but has the same version) = via "pkg upgrade -f", so I'm not too worried. (It's not clear to me how = -STABLE packages get numbered.) Anyway, I'm going to persist with this method of keeping my FreeBSD/arm = systems up to date. It has the big advantage of allowing me to offload = the heavy lifting onto my powerful build server and still be able to = update easily from the ARM client systems. This looks very promising. My next task is to figure out how I can get "mk packages" to sign the = repo with my own key... Cheers, Paul.=