From owner-svn-doc-all@freebsd.org Mon Jan 18 22:35:02 2016 Return-Path: Delivered-To: svn-doc-all@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 98D47A868C8; Mon, 18 Jan 2016 22:35:02 +0000 (UTC) (envelope-from bjk@FreeBSD.org) Received: from repo.freebsd.org (repo.freebsd.org [IPv6:2610:1c1:1:6068::e6a:0]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (Client did not present a certificate) by mx1.freebsd.org (Postfix) with ESMTPS id 587841F2B; Mon, 18 Jan 2016 22:35:02 +0000 (UTC) (envelope-from bjk@FreeBSD.org) Received: from repo.freebsd.org ([127.0.1.37]) by repo.freebsd.org (8.15.2/8.15.2) with ESMTP id u0IMZ1Hx031448; Mon, 18 Jan 2016 22:35:01 GMT (envelope-from bjk@FreeBSD.org) Received: (from bjk@localhost) by repo.freebsd.org (8.15.2/8.15.2/Submit) id u0IMZ18D031447; Mon, 18 Jan 2016 22:35:01 GMT (envelope-from bjk@FreeBSD.org) Message-Id: <201601182235.u0IMZ18D031447@repo.freebsd.org> X-Authentication-Warning: repo.freebsd.org: bjk set sender to bjk@FreeBSD.org using -f From: Benjamin Kaduk Date: Mon, 18 Jan 2016 22:35:01 +0000 (UTC) To: doc-committers@freebsd.org, svn-doc-all@freebsd.org, svn-doc-head@freebsd.org Subject: svn commit: r48058 - head/en_US.ISO8859-1/htdocs/news/status X-SVN-Group: doc-head MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-BeenThere: svn-doc-all@freebsd.org X-Mailman-Version: 2.1.20 Precedence: list List-Id: "SVN commit messages for the entire doc trees \(except for " user" , " projects" , and " translations" \)" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 18 Jan 2016 22:35:02 -0000 Author: bjk Date: Mon Jan 18 22:35:01 2016 New Revision: 48058 URL: https://svnweb.freebsd.org/changeset/doc/48058 Log: Add nanobsd entry from imp Modified: head/en_US.ISO8859-1/htdocs/news/status/report-2015-10-2015-12.xml Modified: head/en_US.ISO8859-1/htdocs/news/status/report-2015-10-2015-12.xml ============================================================================== --- head/en_US.ISO8859-1/htdocs/news/status/report-2015-10-2015-12.xml Mon Jan 18 22:00:24 2016 (r48057) +++ head/en_US.ISO8859-1/htdocs/news/status/report-2015-10-2015-12.xml Mon Jan 18 22:35:01 2016 (r48058) @@ -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:

+ +
    +
  • Support for CPUTYPE-specialized builds. This + includes both NanoBSD support as well as important bug fixes + in the base system.
    • + +
  • Support for marking MBR partitions as active.
    • + +
  • Support for more partition types.
    • +
+ + + + +

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.

+ + +