Date: Mon, 25 Jul 2016 19:03:23 -0400 From: Paul Mather <paul@gromit.dlib.vt.edu> To: freebsd-arm <freebsd-arm@freebsd.org> Cc: Glen Barber <gjb@FreeBSD.org> Subject: Using packaged base with FreeBSD/arm Message-ID: <2A1CEA39-A263-451C-A5FC-F8E223A22746@gromit.dlib.vt.edu>
next in thread | raw e-mail | index | archive | help
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.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?2A1CEA39-A263-451C-A5FC-F8E223A22746>