From f32a0494e1747385093c77e9ca2be14a2274a1c5 Mon Sep 17 00:00:00 2001 From: Benjamin Kaduk Date: Mon, 18 Jan 2016 22:35:01 +0000 Subject: [PATCH] Add nanobsd entry from imp --- .../news/status/report-2015-10-2015-12.xml | 117 ++++++++++++++++++ 1 file changed, 117 insertions(+) diff --git a/en_US.ISO8859-1/htdocs/news/status/report-2015-10-2015-12.xml b/en_US.ISO8859-1/htdocs/news/status/report-2015-10-2015-12.xml index ac1e808120..bdff21bc5b 100644 --- a/en_US.ISO8859-1/htdocs/news/status/report-2015-10-2015-12.xml +++ b/en_US.ISO8859-1/htdocs/news/status/report-2015-10-2015-12.xml @@ -3820,4 +3820,121 @@ relaunchd.

+ + + NanoBSD Modernization + + + + + Warner + Losh + + imp@FreeBSD.org + + + + +

The NanoBSD updates target three main areas. First, + building a NanoBSD image required root privileges. Second, + building for embedded platforms required detailed knowledge of the + formate required to boot. Third, the exact image sizes needed to + be known to produce an image.

+ +

When NanoBSD was written, &os;'s build system required root + privileges for the install step and onward. NanoBSD added to this + by creating a md(4) device to construct the image. Some + configurations of NanoBSD added further to this by creating a + chroot in which to cleanly build packages. NanoBSD solves the + first problem using the new NO_ROOT build option to + create a meta file. NanoBSD also augments this record as files + are created and removed. The meta file is then fed into + makefs(8) to create a UFS image with the proper + permissions. The UFS image, and sometimes a DOS FAT partition, + are then passed to mkimg(1) to create the final SD image. + The mtree manipulation has been written as a separate script to + allow it to move into the base system where it could assist with + other build orchestration tools (though the move has not happened + yet).

+ +

The detailed knowledge of how to build each embedded image + (as well as some of the base images for qemu) has always been hard + to enshrine. Crochet puts this knowledge into its builds. The + &os; release system puts it into its system. NanoBSD, prior to + the current work, provided no way to access its knowledge of how + to build images. The current state of this project allows the + user to set a simple image type and have NanoBSD deal with all of + the details needed to create that image type. This includes using + the u-boot ports and installing the right files into a FAT + partition so that &os; can boot with ubldr(8), creating + the right boot1.elf file for powerpc64 qemu booting, or + the more familiar (though needlessly complicated) x86 setup. + Previous versions of NanoBSD required too much specialized + knowledge from the user. This work aims to concentrate the + knowledge into a set of simple scripts for any build orchestration + system to use.

+ +

Finally, NanoBSD images in the past have needed very + specific knowledge of the target device. Part of this is a legacy + of the BIOS state-of-the-art a decade ago, which required very + careful matching of the image to the actual device in the deployed + system. Although relevant at the time, such systems are now + vanishingly rare. Support for them will be phased out (though + given the flexibility of NanoBSD, it can be moved to the few + remaining examples in the tree and also partially covered by the + generic image scripts). Today, the typical use case is to create + an SD or microSD card image, and have the image resize itself on + boot. NanoBSD now supports that workflow.

+ +

In addition to these items, a number of minor improvements + have been made:

+ + + + + + +

mkimg(8) needs to be augmented to create images + for the i.MX6 and Allwinner (and others) SoCs. These SoCs require + a boot image to be written after the MBR, but before the first + partition starts.

+ + + +

The chroot functionality of some NanoBSD configurations + has not yet been migrated for non-privileged builds.

+ + + +

The functionality to manipulate mtree(8) files + should be moved into the base system for use by other build + orchestration tools.

+ + + +

The script to create a bootable image from one or more + trees of files, as well as some creation of those trees, should be + moved into the base system for use with other build orchestration + tools.

+ + + +

The growfs functionality works great for single + images growing to the whole disk. However, NanoBSD would prefer + that the boot FS/partition grow to approximately 1/2 the size of + the media and another identical (or close) partition be created + for the ping-ponging upgrades that NanoBSD is setup for. This + needs to be implemented in the growfs rc.d(8) + script.

+ + +