svn commit: r48058 - head/en_US.ISO8859-1/htdocs/news/status
Benjamin Kaduk <[email protected]>
| Newsgroups | gmane.os.freebsd.devel.cvs.doc |
|---|---|
| Message-ID | <[email protected]> |
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>[email protected]</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>
_______________________________________________
[email protected] mailing list
https://lists.freebsd.org/mailman/listinfo/svn-doc-all
To unsubscribe, send any mail to "[email protected]"