'Using packaged base with FreeBSD/arm'

[prev in list] [next in list] [prev in thread] [next in thread] 

List:       freebsd-arm
Subject:    Using packaged base with FreeBSD/arm
From:       Paul Mather <paul () gromit ! dlib ! vt ! edu>
Date:       2016-07-25 23:03:23
Message-ID: 2A1CEA39-A263-451C-A5FC-F8E223A22746 () gromit ! dlib ! vt ! edu
[Download RAW message or body]

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="armv6hf"
+mk_arch="armv6"
 mk_insdir="$(pwd)/nfsroot"
 mk_jobs="$(sysctl -n hw.ncpu)"
 mk_kernel="GENERIC"
@@ -19,6 +19,7 @@
 mk_objdir="$(pwd)/obj"
 mk_srcconf="$(pwd)/config/src.conf"
 mk_srcdir="$(pwd)/src"
+mk_repodir="$(pwd)/repo"
 mk_ubldraddr="0x0"

 # If making a target that requires root privs, automatically add sudo.
@@ -49,6 +50,8 @@
     "__MAKE_CONF=${mk_makeconf}" \
     "srcconf=${mk_srcconf}" \
     "KERNCONF=${mk_kernel}" \
+    "NO_INSTALLEXTRAKERNELS=no" \
+    "REPODIR=${mk_repodir}" \
     "UBLDR_LOADADDR=${mk_ubldraddr}" \
     ${mk_mkargs} \
     "$@"



I added the "NO_INSTALLEXTRAKERNELS=no" 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="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=yes" 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.
_______________________________________________
freebsd-arm@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-arm
To unsubscribe, send any mail to "freebsd-arm-unsubscribe@freebsd.org"


[prev in list] [next in list] [prev in thread] [next in thread] 
