Date: Mon, 18 Jan 2016 22:35:01 +0000 (UTC) From: Benjamin Kaduk <bjk@FreeBSD.org> 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 Message-ID: <201601182235.u0IMZ18D031447@repo.freebsd.org>
next in thread | raw e-mail | index | archive | help
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 @@ <tt>relaunchd</tt>.</p> </body> </project> + + <project cat='misc'> + <title>NanoBSD Modernization</title> + + <contact> + <person> + <name> + <given>Warner</given> + <common>Losh</common> + </name> + <email>imp@FreeBSD.org</email> + </person> + </contact> + + <body> + <p>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.</p> + + <p>When NanoBSD was written, &os;'s build system required root + privileges for the install step and onward. NanoBSD added to this + by creating a <tt>md(4)</tt> 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 <tt>NO_ROOT</tt> 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 + <tt>makefs(8)</tt> to create a UFS image with the proper + permissions. The UFS image, and sometimes a DOS FAT partition, + are then passed to <tt>mkimg(1)</tt> 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).</p> + + <p>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 <tt>ubldr(8)</tt>, creating + the right <tt>boot1.elf</tt> 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.</p> + + <p>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.</p> + + <p>In addition to these items, a number of minor improvements + have been made:</p> + + <ul> + <li>Support for <tt>CPUTYPE</tt>-specialized builds. This + includes both NanoBSD support as well as important bug fixes + in the base system.</li> + + <li>Support for marking MBR partitions as active.</li> + + <li>Support for more partition types.</li> + </ul> + </body> + + <help> + <task> + <p><tt>mkimg(8)</tt> 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.</p> + </task> + + <task> + <p>The chroot functionality of some NanoBSD configurations + has not yet been migrated for non-privileged builds.</p> + </task> + + <task> + <p>The functionality to manipulate <tt>mtree(8)</tt> files + should be moved into the base system for use by other build + orchestration tools.</p> + </task> + + <task> + <p>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.</p> + </task> + + <task> + <p>The <tt>growfs</tt> 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 <tt>growfs</tt> <tt>rc.d(8)</tt> + script.</p> + </task> + </help> + </project> </report>
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?201601182235.u0IMZ18D031447>