Updating FreeBSD on Raspberry Pi

[Hornpipe2]

I have successfully set up FreeBSD 11.0 on a Raspberry Pi model B+, using ISO images from the Wiki page. My current running version is

FreeBSD 11.0-STABLE (RPI-B) #0 r308738: Thu Nov 17 06:47:11 UTC 2016

This is several months out of date... in fact, I see there was a release just yesterday.

How can I update a running FreeBSD armv6 installation to the latest version? freebsd-update obviously does nothing, because armv6 is only Tier 2 support and not Tier 1.

 

[Phishfry]

You can either natively build with the new patches(takes a long time) or use crochet. I use crochet and keep my data separate on my Pi -so I rebuild my machine after every patch/update.

Building natively you would start here and follow manual to build world:
https://www.freebsd.org/doc/handbook/makeworld.html

I wouldn't recommend this to my worst enemy. Create a data storage scheme for your files and make images with crochet when you want to patch.

If your not running FreeBSD then maybe use an old computer for crochet.
It's so simple. Simply patch your build box and create an image.
Crochet builds images with the updates. Any updates after the first crochet build only takes minutes, unless a full rebuild is needed(2-4hrs.).
Messing with GPIO I find myself having to build new kernels frequently so crochet has been a great tool.

 

[SirDice]

freebsd-update obviously does nothing, because armv6 is only Tier 2 support and not Tier 1.

That's not going to work anyway even if it was supported, freebsd-update(8) can only update/upgrade -RELEASE versions, not -STABLE.

The only way to update a -STABLE version is by doing a source update and building world. That's going to take a while though.

 

[obsigna]

... The only way to update a -STABLE version is by doing a source update and building world. That's going to take a while though.

I wrote a Howto on updating FreeBSD x.y-CURRENT on a Beaglebone Black. I assume that this should work with a Raspberry Pi and FreeBSD x.y-STABLE as well. Just pick the correct FreeBSD image from the ftp server and change the device identifiers to those the Raspberry knows about.

Howto: Updating FreeBSD x.y-CURRENT installations using respective snapshots

 

[Hornpipe2]

There has GOT to be a better way to do this... just imagining everyone rebuilding everything from the ground up each release is mind-boggling.

Is there not a way for us (me?) to stand up a mirror, which freebsd-update can bounce off of to get updates or new package lists?

 

[SirDice]

Again, freebsd-update(8) only works on -RELEASE versions. -STABLE or -CURRENT versions always have to be built from source.

Ports are not bound to certain versions of the base OS, all versions[*] of FreeBSD use the exact same ports tree.

[*] all versions means exactly that, all -RELEASE versions, all -STABLE versions and -CURRENT have the same ports tree.

 

[ekingston]

There has GOT to be a better way to do this... just imagining everyone rebuilding everything from the ground up each release is mind-boggling.

Is there not a way for us (me?) to stand up a mirror, which freebsd-update can bounce off of to get updates or new package lists?

You *could* set-up a build server and a binary repository that mimics the tier-1 servers provided by the FreeBSD Foundation and build your own *releases*(1). Then you could make it available over the Internet to save everyone else who uses it from having to compile. I believe there is a way to change the update server in one of the config files.

Of course, that is more work in the set-up and just as much work for each update as doing what people are currently doing. Which is probably why nobody has yet.

(1) I mean to say, that one would create their own unofficial -RELEASE, not that there is an official -RELEASE for the Pi yet.

 

[Phishfry]

I seriously doubt freebsd-updates will ever work on armv6 or armv7. Notice the different builds for each board. You could never run freebsd-update against that. Maybe if we ever got a unified Arm Release but i don't see that happening on 32bit Arm. There was an attempt to merge all the uboot board builds into one master uboot port which seems like a good starting point.
That is still a long way from a unified Arm build.
To me it was disappointing to see a board kernconf come out for the RPi3. I was hoping aarch64 would be unified not individual builds for each board. That has to be a nightmare to maintain..

I have found that building images on Crochet is even better now that you can have packages pre-installed. Plus I am slipstreaming in my config files with the /overlay directory.
I am storing my data on NFS shares.

 

[tingo]

Also note: freebsd-update only updates the operating system (and only -RELEASE versions, as has been pointed out in this thread already). For ports (source code based) you would use portsnap to update the ports tree (then you need to build and install the upgraded ports). If you use packages, pkg is the tool to use for updating those. Everything is documented, but you do have to *read* the documentation provided.
So, for FreeBSD itself you can do it two ways: freebsd-update and follow the -RELEASEs, or source code based (where you can get -STABLE) , but then you have to build each update from source yourself.
And for third-party programs (ports / packages) which are the programs that most people actually use, there are two ways: package-based (via pkg, you can choose between quarterly and latest repository) or source-based (ports) - but then you have to build and install from source.

 

[ralphbsz]

There has GOT to be a better way to do this... just imagining everyone rebuilding everything from the ground up each release is mind-boggling.

To you it might be mind-boggling. To others its sensible. To some religious fanatics is the "only true way". I know lots of people who recompile absolutely everything from scratch, for a variety of reasons. One is a trust issue (to make sure the executables actually match the source, which can be easily inspected by humans). Another is to make sure the executables are optimized for exactly the right processor (code generation varies in subtle ways between processors).

For embedded systems that are not self-hosting, this causes a little bit of extra work, as one has to set up a cross-compilation environment on another machine. But lots of people who do serious development on those machines need that hosting environment anyhow. The Raspberry Pi and similar machines are strange hybrids: they are theoretically capable of self-hosting (they can run a full compiler suite), but because of their low speed (in particular the very slow file system on the SD card), it's tedious to compile everything. That really just indicates that we are now less patient than we used to be; I used to compile the Linux kerne 0.99.14 and glibc on a 386-40 (took overnight), and that was considered acceptable in the late 90s.

Don't want to do the compilation yourself? Run the RELEASE version. Don't want to compile the ports? Use packages. Don't want to compile anything? Run Linux. Life is full of tradeoffs.

Is there not a way for us (me?) to stand up a mirror, which freebsd-update can bounce off of to get updates or new package lists?

I think crochet is the closest thing today that works today. I need to find a few hours to set up crochet myself. Unfortunately, due to other tasks, my RPi3 work is on the back burner for a few weeks.

 

[Hornpipe2]

You *could* set-up a build server and a binary repository that mimics the tier-1 servers provided by the FreeBSD Foundation and build your own *releases*(1). Then you could make it available over the Internet to save everyone else who uses it from having to compile. I believe there is a way to change the update server in one of the config files.

Of course, that is more work in the set-up and just as much work for each update as doing what people are currently doing. Which is probably why nobody has yet.

(1) I mean to say, that one would create their own unofficial -RELEASE, not that there is an official -RELEASE for the Pi yet.

Right... this is what I'm envisioning - a third-party provider for binrepos for the Tier 2 architectures.

I mean, somebody out there is building RPi releases on a regular basis already: ftp://ftp.freebsd.org/pub/FreeBSD/snapshots/arm/armv6/ISO-IMAGES/11.0

It seems sensible that these could ALSO be unpacked to somewhere, staged, and then freebsd-update or pkg (or both) pointed to that staging location to pull updates. It's not "trusted" in the same way you would get from build-it-yourself or built-by-the-FreeBSD-foundation, but it could be miles better than the current situation.

I guess this is precisely the sort of thing I should start Doing instead of Talking About, so...

---

root@server:/home/grkenn # freebsd-update fetch
src component not installed, skipped
Looking up update.FreeBSD.org mirrors... 4 mirrors found.
Fetching public key from update5.freebsd.org... failed.
Fetching public key from update4.freebsd.org... failed.
Fetching public key from update3.freebsd.org... failed.
Fetching public key from update6.freebsd.org... failed.
No mirrors remaining, giving up.

Ok, let's look at /etc/freebsd-update.conf

# $FreeBSD: stable/11/etc/freebsd-update.conf 257694 2013-11-05 09:30:06Z glebius $

# Trusted keyprint.  Changing this is a Bad Idea unless you've received
# a PGP-signed email from <security-officer@FreeBSD.org> telling you to
# change it and explaining why.
KeyPrint 800651ef4b4c71c27e60786d7b487188970f4b4169cc055784e21eb71d410cc5

# Server or server pool from which to fetch updates.  You can change
# this to point at a specific server if you want, but in most cases
# using a "nearby" server won't provide a measurable improvement in
# performance.
ServerName update.FreeBSD.org

# Components of the base system which should be kept updated.
Components src world kernel

# Example for updating the userland and the kernel source code only:
# Components src/base src/sys world

# Paths which start with anything matching an entry in an IgnorePaths
# statement will be ignored.
IgnorePaths

# Paths which start with anything matching an entry in an IDSIgnorePaths
# statement will be ignored by "freebsd-update IDS".
IDSIgnorePaths /usr/share/man/cat
IDSIgnorePaths /usr/share/man/whatis
IDSIgnorePaths /var/db/locate.database
IDSIgnorePaths /var/log

# Paths which start with anything matching an entry in an UpdateIfUnmodified
# statement will only be updated if the contents of the file have not been
# modified by the user (unless changes are merged; see below).
UpdateIfUnmodified /etc/ /var/ /root/ /.cshrc /.profile

# When upgrading to a new FreeBSD release, files which match MergeChanges
# will have any local changes merged into the version from the new release.
MergeChanges /etc/ /boot/device.hints

### Default configuration options:

# Directory in which to store downloaded updates and temporary
# files used by FreeBSD Update.
# WorkDir /var/db/freebsd-update

# Destination to send output of "freebsd-update cron" if an error
# occurs or updates have been downloaded.
# MailTo root

# Is FreeBSD Update allowed to create new files?
# AllowAdd yes


# Is FreeBSD Update allowed to delete files?
# AllowDelete yes

# If the user has modified file ownership, permissions, or flags, should
# FreeBSD Update retain this modified metadata when installing a new version
# of that file?
# KeepModifiedMetadata yes

# When upgrading between releases, should the list of Components be
# read strictly (StrictComponents yes) or merely as a list of components
# which *might* be installed of which FreeBSD Update should figure out
# which actually are installed and upgrade those (StrictComponents no)?
# StrictComponents no

# When installing a new kernel perform a backup of the old one first
# so it is possible to boot the old kernel in case of problems.
# BackupKernel yes

# If BackupKernel is enabled, the backup kernel is saved to this
# directory.
# BackupKernelDir /boot/kernel.old

# When backing up a kernel also back up debug symbol files?
# BackupKernelSymbolFiles no

Ok, so just
* stand up a server,
* rewrite the KeyPrint with my own.

Hmm, where would I find out more info on how to set up a workalike of update.freebsd.org?

 

[ekingston]

...
Hmm, where would I find out more info on how to set up a workalike of update.freebsd.org?

That's a darn good question. Again, into the *I think* territory...

I *think* the FreeBSD update (and package) repositories are just ftp servers (not sftp, just plain old anonymous ftp). I also *think* updating.freebsd.org is some sort of a redirector that gives you the update1, update2, ... list of actual ftp servers.

I will dig up my old RPi2 and see if I can get a base FreeBSD on it so I can test your update server when you are ready.

 

[DrJohnnyFever]

Has anyone tried using crochet to do the build and mounted the resulting obj and src to an arm board over NFS and done a make installkernel and installworld as to avoid using a completely new image but still using crochet for the build? It seems to me if this is workable it would be a decent way to solve this problem.

 

[DrJohnnyFever]

Has anyone tried using crochet to do the build and mounted the resulting obj and src to an arm board over NFS and done a make installkernel and installworld as to avoid using a completely new image but still using crochet for the build? It seems to me if this is workable it would be a decent way to solve this problem.

Well, forget that idea. make tried to use the cross-tools during the install which naturally doesn't work.

 

[trev]

I've rebuilt FreeBSD 11-STABLE on a Raspberry Pi 2 (900 MHz 32-bit quad-core ARM Cortex-A7) with /usr on a USB memory stick. It only took just over 12 hours I wouldn't even try on an SD-card.

 

[trev]

I've rebuilt FreeBSD-12-Current on a Raspberry Pi 3 (1.2GHz 64-bit quad-core ARM Cortex A53) on a SanDisk Extreme (UHS3) 32GB SD-card with no issues (using external USB memory sticks for /usr caused "out of memory" process kills despite having plenty of free swap whether that swap was on the SanDisk Ultra 16GB SD-card or USB memory stick).

The only other option that worked was using a USB connected spinning rust disk for /usr which leads me to the conclusion that that the OOM process kills were due to speed or lack thereof of the disk i/o.

 

[complexinput]

I've rebuilt FreeBSD-12-Current on a Raspberry Pi 3 (1.2GHz 64-bit quad-core ARM Cortex A53) on a SanDisk Extreme (UHS3) 32GB SD-card with no issues (using external USB memory sticks for /usr caused "out of memory" process kills despite having plenty of free swap whether that swap was on the SanDisk Ultra 16GB SD-card or USB memory stick).

The only other option that worked was using a USB connected spinning rust disk for /usr which leads me to the conclusion that that the OOM process kills were due to speed or lack thereof of the disk i/o.

There was a discussion on the mailing list about this. Increasing vm.pageout_oom_seq seemed to help.


Mailing list discussion: http://freebsd.1045724.x6.nabble.com/GPT-vs-MBR-for-swap-devices-td6263514.html
More info about pageout_oom_seq: https://reviews.freebsd.org/D16659

 

[trev]

There were many more protracted discussions about OOM issues on RPis on the ARM mailing list, in some of which I participated. Anyway, the faster sd-card solved my OOM issues completely.