Added fix for swupd bundle-add Error

Signed-off-by: Anthony Pray anthony.s.pray@intel.com When using the docker image you may see error "Failed to install x of x" ruining "swupd clean" will fix the problems.
2026-08-24 08:48:15 +00:00 · 2020-03-09 12:11:34 -07:00
88 changed files with 603 additions and 1730 deletions
@@ -176,16 +176,7 @@ displays a preview of the site at http://localhost:8000 on your local machine.

 To stop the web server simply use ``ctrl-c``.

-<<<<<<< HEAD
-
-### Silly header to test dev branch
-
-
-
-.. _Clear Linux\* OS documentation:  https://clearlinux.org/documentation
-=======
 .. _Clear Linux\* OS documentation:  https://docs.01.org/clearlinux/
->>>>>>> 550b919bc013159156f80110867aa1ab7c858d29
 .. _Sphinx: http://sphinx-doc.org/
 .. _reStructuredText: http://www.sphinx-doc.org/en/master/usage/restructuredtext/basics.html
 .. _contribution guidelines: https://docs.01.org/clearlinux/latest/collaboration/collaboration.html
@@ -198,8 +198,6 @@ Visual Studio Code

 |

-.. _licensing_restrict:
-
 Is FFmpeg available?
 ====================

@@ -492,7 +492,6 @@ div.linenodiv:before { /*add extra new line to make sure code and line numbers a
  margin: 10px;
  border: 10px;
  background: white;
-  position: relative;
 }

 .column.featurecard {
@@ -500,29 +499,11 @@ div.linenodiv:before { /*add extra new line to make sure code and line numbers a
  width: 300px;
 }

-.column.squarecard {
-  height: 320px;
-}
-
-.column.smallcard {
-  height: 150px;
-}
-
-.endlink {
-  position: absolute;
-  bottom: 10px;
-  right: 10px;
-}
-
 .column.verticalcard {
  height: 615px;
  overflow: auto;
 }

-.multicolumns.three {
-  max-width: 1200px;
-}
-
 /* Clear floats after the columns */
 .multicolumns:after {
  content: "";
@@ -569,4 +550,4 @@ div.figure.dropshadow img {
  box-shadow: 10px 10px 10px LightGray;
 }

-/*end figure drop shadow*/
+/*end figure drop shadow*/
@@ -3,93 +3,57 @@
 About
 #####

-|CL-ATTR| does things differently. Our software architecture provides a 
-unique and innovative platform for Linux* developers focused on
-performance, security, and cutting-edge computation in the cloud. 
+The |CL| delivers a secure, hardware optimized OS. Its easy updates ensure that
+software dependencies remain mutually compatible.
+
+|CL| does this via custom infrastructure components and process innovations.

 .. contents::
   :local:
   :depth: 1


-What is |CL|?
-*************
+For detailed information on these topics, refer to the :ref:`cl-guides` guides.

-|CL| is an open source, rolling-release Linux* distribution, optimized for 
-performance and security from the cloud to the Edge.  With an emphasis on 
-customization and manageability, |CL| provides an industry blueprint on how 
-to incorporate Intel® architecture, from leveraging instruction sets to 
-optimizing kernel configurations and compiler flags, so tuning across the stack coalesces in a single, performance-driven development environment. 
-
-What |CL| isn't?
-****************
-
-|CL| is not intended to be a general-purpose Linux distribution, suitable 
-for novice end-users. While we ship common applications, our purpose isn’t 
-to make an OS for routine desktop tasks and provide immunity from all 
-security threats in all situations. Our unique focus means what we consider 
-*essential* use cases, *optional* use cases, or even *unwanted* use cases, 
-differs from other Linux distros.
-
-Target audience
-***************
-
-Rather than making a standard Linux distribution, the |CL| team decided to
-build its own. |CL| mainly targets professionals in IT, DevOps, Cloud/
-Container deployments, and :abbr:`AI (Artifical Intelligence)`. 
-
-One advantage of developing a distro in house is that our experiments help us
-continually optimize performance and deliver security patches, several times
-per week. Yet our experiments are only valuable if our software architecture 
-gives you the freedom to innovate, too. To improve manageability, |CL| 
-employs a :ref:`stateless` design, separating user and system management.  
-
-Understanding what it takes to integrate features into our own Linux distro 
-helps us collaborate with other distro owners and submit enhancements to 
-upstream. We demonstrate the value of our distro by offering users the 
-same tools we use. For example, :ref:`mixer`, a tool unique to |CL|, allows 
-users to build custom derivatives and act as their own 
-:abbr:`(OSV) OS Vendor`. 
-
-For more details on |CL| features, refer to the :ref:`cl-guides` guides.
-
-What makes |CL| different?
-**************************

 Release Cadence
-===============
+***************

 |CL| updates are based on a rolling release that can occur daily, up to a few
-times per week. Each release has a unique version number that identifies
-every component in the OS from kernel, to driver, to tool, to GUI
-application. Most components are included in entities called :ref:`bundles<bundles>`.
+times per week. Each release has a unique version number that
+identifies every component in the OS from kernel, to driver, to tool, to GUI
+application. Most components are included in entities called *bundles*.

 Updates
-=======
+*******

-By default, |CL| automatically checks for updates, ensuring the latest
+By default, |CL| automatically checks for updates, ensuring that the latest
 performance and security fixes are installed as soon as they are available.
-|CL| stays in lockstep with upstream for current security upgrades and is 
-designed to rapidly deliver security mitigations to customers.
-:ref:`swupd-guide` is designed to manage updates and bundles.
+:ref:`swupd-guide` is the custom tool designed to manage updates and bundles.
+
+|CL| is :ref:`stateless` to make sure that system components can be updated
+without impacting user settings.
+

 Ease of Use
-===========
+***********

 |CL| makes it easier to manage a number of difficult problems.

 * :ref:`autoproxy` makes it possible for |CL| tools to operate in some proxy
  environments without needing to be configured.

-* :ref:`stateless` means that configuration settings are easier to manage
+* Being :ref:`stateless` means that configuration settings are easier to manage
  and remain untouched when system software is updated.

 * :ref:`swupd-guide` simplifies managing software and maintaining compatibility.

 Custom Derivatives
-==================
+******************

-The same tools used to build the |CL| are available *in* the OS. These tools can be used to create a custom distribution that continues to benefit from upstream rolling releases.
+The same tools used to build the |CL| are available *in* the OS. These tools can
+be used to create a custom distribution that continues to benefit from upstream
+rolling releases.

 .. figure:: /_figures/about/clear-lifecycle.png
   :scale: 75%
@@ -118,191 +82,4 @@ Administrate
 |CL| provides a :ref:`telem-guide` solution for collecting useful information
 about a deployment, as well as :ref:`debug` capabilities.

-Performance and security
------------------------
-
-We apply the same strategy when it comes to performance. Our developers 
-strive to optimize performance for *essential* use cases while we ignore 
-*unwanted* or unsupported use cases.
-
-For example, while |CL| does not enable antivirus by default, we provide
-a bundle for it (`clamav`). We leave antivirus configuration to our users. 
-In addition, firewalls are less important if the OS doesn’t expose services 
-to the outside by default. In |CL|, we enforce this strategy by disabling 
-network services by default - e.g. mariadb listens on a UNIX socket, nginx 
-won’t listen at all, and other services similarly like that are restricted 
-from being accessed over the network. This strategy alone makes firewall 
-software much less urgent - there simply isn’t anything that a firewall 
-could easily block.
-
-If you want a general purpose Linux distro with little to no configuration, 
-|CL| may not be the distro enough for you. 
-
-
-Is |CL| completely Open Source?
-*******************************
-
-Wherever possible, |CL| aims to be completely open source.  Our 
-`source code`_ is available on GitHub. When considering projects for inclusion, we check that they are in active development and are well maintained. We have a very strict requirement for not accepting proprietary packages and non-open source components.  For example, many Linux distros may not be able to include certain media codecs due to  
-:ref:`licensing restrictions <licensing_restrict>`, but alternatives are available.
-
-What’s the thinking around Command line v. Desktop?
-***************************************************
-
-|CL| focuses on performance for server and cloud use-cases first because
-many design decisions associated with them are applicable to other use-cases, such as IoT and the desktop client. 
-
-While our initial focus was on the command line, we realized that many people valued the ease-of-use of a desktop environment.  We've been trying to accommodate these people as much as we can, but there are clear limits to what a desktop environment can do. This is especially true, given our desire to deliver a highly performant and secure Linux distro, one that provides unique tools for customization, and one that enables several cloud use cases. |CL| has a strong bias toward servers and what developers use, 
-rather than including "random stuff".
-
-Why create new components rather than modifying existing projects?
-******************************************************************
-
-One question that's often asked: “Why did you develop your own solution 
-instead of using <XYZ>?” (e.g. `swupd post`_).  We do evaluate existing 
-projects for inclusion in |CL|, yet there are cases where our unique 
-architecture and components would require too much customization to use 
-off-the-shelf projects.  In other situations, we may feel that using a new 
-language to develop the component would give us a performance advantage, 
-ease code development and maintenance, and grow the skills of our engineers 
-on new and upcoming programming languages.  And yes, sometimes there are 
-personal biases for and against some projects by the architects and 
-engineers.  We tend to move fast, and sometimes it’s easier to live with 
-suboptimal choices until we have the time or incentive to re-architect them 
-properly. 
-
-Which Components are used in Clear Linux?
-*****************************************
-
-.. list-table::
-   :widths: 33,33,33
-   :header-rows: 1
-
-   * - Component
-     - Enabled in OS/Bundle
-     - Optional
-
-   * - OS Installer
-     - `Clear Linux installer`_
-     - 
-
-   * - Bootloader
-     - `systemd-boot`_ (UEFI) / `syslinux`_ (Legacy)
-     - 
-
-   * - Boot Manager
-     - `Clear Linux Boot Manager`_
-     - 
-
-   * - Configuration initialization and management
-     - 
-     - `micro-config-drive`_ (minimal cloud-init), Ansible
-
-   * - Software component installer, manager, updater
-     - `swupd`_
-     - 
-
-   * - Software bundle generator - 
-     - `mixer`_ and `clr-distro-factory`_
-     - 
-
-   * - Package builder
-     - `autospec`_
-     - 
-
-   * - Software debugging
-     - 
-     - `clr-debug-info`_ 
-
-   * - Unified TLS Trust Store Management
-     - `clrtrust`_
-     - 
-
-   * - System and software telemetry
-     - 
-     - `Telemetrics`_ (disabled by default)
-
-   * - File system
-     - `EXT4`_ (default for rootfs)
-     - `VFAT`_, `EXT2 and EXT3`_, `F2FS`_
-
-   * - Disk encryption
-     - 
-     - `LUKS`_ 
-
-   * - System /Service manager  
-     - `systemd`_
-     - 
-
-   * - Display manager 
-     - `Gnome`_
-     - ``KDE``, ``i3``, ``XFCE`` ``LXQt`` (see`Clear Linux store`_)
-
-   * - Display services (Desktop installed)
-     - `X.Org`_
-     - `Wayland`_ compositor
-
-   * - Network services
-     - `NetworkManager`_ by default*, `systemd-networkd`_
-     - 
-
-   * - SSH Port scanning blocker
-     - `Tallow`_
-     - 
-
-   * - Firewall
-     - None by default
-     - iptables and `firewalld`_
-
-   * - Antivirus
-     - None by default
-     - `ClamAV®`_
-
-   * - Web browser
-     - `Lynx`_ or `links`_ for text environments, `Firefox`_ for GUI
-     - 
-
-   * - Additional Software
-     - `Supplied Bundles`_
-     - Flatpak, 3rd-party software bundles
-
-.. note::
-   
-   The |CL| OS images targeted for cloud deployments continue to use
-   ``systemd-networkd`` to manage network connections.  In earlier |CL|, 
-   ``systemd-networkd`` was used to manage Ethernet interfaces and NetworkManager was used for wireless interfaces.
-
 .. _how-to-clear: https://github.com/clearlinux/how-to-clear
-.. _Clear Linux store: https://clearlinux.org/software
-.. _source code: https://github.com/clearlinux
-.. _swupd post: https://community.clearlinux.org/t/why-does-clearlinux-use-swupd-and-not-apt-deb-rpm/
-.. _swupd: https://github.com/clearlinux/swupd-client
-.. _Clear Linux installer: https://github.com/clearlinux/clr-installer/
-.. _systemd-boot: https://www.freedesktop.org/software/systemd/man/systemd-boot.html
-.. _syslinux: https://wiki.syslinux.org/wiki/index.php?title=The_Syslinux_Project
-.. _Clear Linux Boot Manager: https://github.com/clearlinux/clr-boot-manager
-.. _mixer: https://github.com/clearlinux/mixer-tools
-.. _clr-distro-factory: https://github.com/clearlinux/clr-distro-factory
-.. _autospec: https://github.com/clearlinux/common
-.. _clr-debug-info: https://github.com/clearlinux/clr-debug-info
-.. _clrtrust: https://github.com/clearlinux/clrtrust
-.. _EXT4: https://ext4.wiki.kernel.org/index.php/Main_Page
-.. _VFAT: https://www.kernel.org/doc/html/latest/filesystems/vfat.html
-.. _EXT2 and EXT3: https://ext4.wiki.kernel.org/index.php/Main_Page
-.. _F2FS: https://www.kernel.org/doc/Documentation/filesystems/f2fs.txt
-.. _LUKS: https://gitlab.com/cryptsetup/cryptsetup/
-.. _systemd: https://www.freedesktop.org/wiki/Software/systemd/
-.. _Gnome: https://www.gnome.org/
-.. _X.Org: https://www.x.org/
-.. _Wayland: https://wayland.freedesktop.org/
-.. _NetworkManager: https://wiki.gnome.org/Projects/NetworkManager
-.. _systemd-networkd: https://www.freedesktop.org/software/systemd/man/systemd.network.html
-.. _Tallow: https://github.com/clearlinux/tallow
-.. _firewalld: https://docs.01.org/clearlinux/latest/guides/network/firewall.html#firewalld
-.. _ClamAV®: https://www.clamav.net/
-.. _Lynx: https://lynx.invisible-island.net/
-.. _links: http://links.twibright.com/
-.. _Firefox: https://www.mozilla.org/en-US/firefox/
-.. _Supplied Bundles: https://clearlinux.org/software
-.. _micro-config-drive: https://github.com/clearlinux/micro-config-drive
-.. _Telemetrics: https://github.com/clearlinux/telemetrics-backend
@@ -41,6 +41,7 @@ Install |CL| on your target system
 Ensure that your system is configured to boot UEFI. The installation method
 described below requires a wired or wireless Internet connection with DHCP.

+
 Follow these steps to install |CL| on the target system:

 #. Insert the USB drive into an available USB slot.
@@ -147,8 +147,6 @@ Upload image

   See Figure 1.

-   .. rst-class:: dropshadow
-
   .. figure:: ../../_figures/digitalocean/01-digitalocean.png
      :scale: 100 %
      :alt: DigitalOcean - Upload custom images
@@ -1,511 +0,0 @@
-.. _import-clr-aws:
-
-Import Clear Linux Image and Launch Instance on AWS
-###################################################
-
-Clear Linux is available on the AWS marketplace.  However, it may not 
-be the latest version because we only update the marketplace on a 
-periodic basis, as often as weekly or but maybe monthly as well.  
-If you want to use the latest release from us or upload your own 
-custom image, follow this guide.  
-
-.. contents::
-   :local:
-   :depth: 1
-
-Prerequisites
-*************
-
-* You are familiar with AWS and how to use it
-
-Download or create a |CL| image for AWS
-***************************************
-
-Obtain an AWS |CL| image using one of these methods.  
-
-Download pre-built image
-========================
-#. Go to the `Downloads`_ page and download the 
-   *Amazon\* Web Services (AWS)* image.
-
-#. Uncompress it.  
-
-Create a custom image using clr-installer
-=========================================
-#. On a |CL| system, open a terminal.
-
-#. Install the `clr-installer` bundle.
-
-   .. code-block:: bash
-
-      sudo swupd bundle-add clr-installer
-
-#. Download a sample `aws.yaml`_ configuration file. 
-
-#. Make changes to the configuration file as needed.
-   See `Installer YAML Syntax`_ for more information on clr-installer 
-   configuration YAML syntax.
-
-#. Download the `AWS image post-install script`_ and make it executable.
-
-#. Produce an image with clr-installer.
-
-   .. code-block:: bash
-      
-      clr-installer --template $PWD/aws.yaml
-
-Create an S3 bucket
-*******************
-
-#. Log into AWS.
-
-#. Go to :guilabel:`Services`, :guilabel:`Storage`, and select :guilabel:`S3`.
-   See Figure 1. 
-
-   .. figure:: ../../_figures/aws/import-clr-aws-01.png
-      :scale: 100%
-      :alt: AWS Services - S3 Management Console
-
-      Figure 1: AWS Services - S3 Management Console
-
-#. Click :guilabel:`+ Create bucket`.
-
-   .. figure:: ../../_figures/aws/import-clr-aws-02.png
-      :scale: 100%
-      :alt: AWS S3 - Create bucket
-
-      Figure 2: AWS S3 - Create bucket
-
-#. Set a bucket name and select a region.  
-   See Figure 3.
-
-   .. figure:: ../../_figures/aws/import-clr-aws-03.png
-      :scale: 100%
-      :alt: AWS S3 - Create bucket - Set bucket name and region
-
-      Figure 3: AWS S3 - Create bucket - Set bucket name and region
-
-#. Leave the :guilabel:`Configure options" and :guilabel:`Set permissions`
-   settings as is or configure as desired.  See Figure 4 and 5.
-
-   .. figure:: ../../_figures/aws/import-clr-aws-04.png
-      :scale: 100%
-      :alt: AWS S3 - Create bucket - Configure options
-
-      Figure 4: AWS S3 - Create bucket - Configure options
-
-   .. figure:: ../../_figures/aws/import-clr-aws-05.png
-      :scale: 100%
-      :alt: AWS S3 - Create bucket - Set permissions
-
-      Figure 5: AWS S3 - Create bucket - Set permissions
-
-#. At the :guilabel:`Review` screen, click :guilabel:`Create bucket`.
-
-   .. figure:: ../../_figures/aws/import-clr-aws-06.png
-      :scale: 100%
-      :alt: AWS S3 - Create bucket - Review
-
-      Figure 6: AWS S3 - Create bucket - Review
-
-   The created bucket should appear.  See Figure 7.
-
-   .. figure:: ../../_figures/aws/import-clr-aws-07.png
-      :scale: 100%
-      :alt: AWS S3 - Created bucket
-
-      Figure 7: AWS S3 - Created bucket
-
-Upload the |CL| image into the bucket
-*************************************
-
-#. Click on the bucket.
-   See Figure 8.
-
-   .. figure:: ../../_figures/aws/import-clr-aws-08.png
-      :scale: 100%
-      :alt: AWS S3 - Select bucket
-
-      Figure 8: AWS S3 - Select bucket
-
-#. Click :guilabel:`Upload`.
-   See Figure 9.
-
-   .. figure:: ../../_figures/aws/import-clr-aws-09.png
-      :scale: 100%
-      :alt: AWS S3 - Upload
-
-      Figure 9: AWS S3 - Upload
-
-#. Click :guilabel:`Add files` and select the |CL| image file to upload.
-   See Figure 10.
-
-   .. figure:: ../../_figures/aws/import-clr-aws-10.png
-      :scale: 100%
-      :alt: AWS S3 - Add files
-
-      Figure 10: AWS S3 - Add files
-
-#. Click :guilabel:`Next`.  Leave remaining settings as is or set as desired.
-   See Figure 11, Figure 12, and Figure 13.
-
-   .. figure:: ../../_figures/aws/import-clr-aws-11.png
-      :scale: 100%
-      :alt: AWS S3 - Add files
-
-      Figure 11: AWS S3 - Add files
-
-   .. figure:: ../../_figures/aws/import-clr-aws-12.png
-      :scale: 100%
-      :alt: AWS S3 - Set permissions
-
-      Figure 12: AWS S3 - Set permissions
-
-   .. figure:: ../../_figures/aws/import-clr-aws-13.png
-      :scale: 100%
-      :alt: AWS S3 - Set properties
-
-      Figure 13: AWS S3 - Set properties
-
-#. Click :guilabel:`Upload` to upload the image.
-   See Figure 14.
-
-   .. figure:: ../../_figures/aws/import-clr-aws-14.png
-      :scale: 100%
-      :alt: AWS S3 - Upload
-
-      Figure 14: AWS S3 - Upload
-
-Add a user to IAM with AWS_CLI privilege
-****************************************
-
-#. Go to :guilabel:`Services`, :guilabel:`Security, Identity, & Compliance`,
-   and select :guilabel:`IAM`.
-   See Figure 15. 
-
-   .. figure:: ../../_figures/aws/import-clr-aws-08.png
-      :scale: 100%
-      :alt: AWS Services - IAM
-
-      Figure 15: AWS Services - IAM
-
-#. On the left navigation bar under :guilabel:`Access management`, 
-   select :guilabel:`Users`.
-   See Figure 16.
-
-   .. figure:: ../../_figures/aws/import-clr-aws-16.png
-      :scale: 100%
-      :alt: AWS AIM - Access management
-
-      Figure 16: AWS AIM - Access management
-
-#. Click :guilabel:`Add user`.
-   See Figure 17.
-   
-   .. figure:: ../../_figures/aws/import-clr-aws-17.png
-      :scale: 100%
-      :alt: AWS AIM - Add user
-
-      Figure 17: AWS AIM - Add user
-
-#. Under the :guilabel:`Set user details` section, enter a user name.
-   See Figure 18.
-
-   .. figure:: ../../_figures/aws/import-clr-aws-18.png
-      :scale: 100%
-      :alt: AWS AIM - Enter user name and select access type
-
-      Figure 18: AWS AIM - Enter user name and select access type
-
-#. Under the :guilabel:`Select AWS access type` section, 
-   checkmark :guilabel:`Programmatic access`.
-   See Figure 18.
-
-#. Click :guilabel:`Next: Permissions`.
-
-#. Under :guilabel:`Set permissions`, select :guilabel:`Add user to group`.
-   See Figure 19.
-
-   .. figure:: ../../_figures/aws/import-clr-aws-19.png
-      :scale: 100%
-      :alt: AWS AIM - Set user permissions
-
-      Figure 19: AWS AIM - Set user permissions
-
-#. Under :guilabel:`Add user to group`, enter `AWS_CLI` into search window.
-   Checkmark :guilabel:`AWS_CLI`.
-   See Figure 19.
-
-#. Click :guilabel:`Next: Tags`.
-
-#. Click :guilabel:`Next: Review`.
-
-#. Click :guilabel:`Create user`.
-   See Figure 20.
-
-   .. figure:: ../../_figures/aws/import-clr-aws-20.png
-      :scale: 100%
-      :alt: AWS AIM - Create user
-
-      Figure 20: AWS AIM - Create user
-
-#. After the user is successfully added, save the :guilabel:`Access key ID`
-   and the :guilabel:`Secret access key`.  These will be used when setting up
-   the AWS CLI tool at a later step.
-   See Figure 21.
-
-   .. figure:: ../../_figures/aws/import-clr-aws-21.png
-      :scale: 100%
-      :alt: AWS AIM - Access key ID and secret access key
-
-      Figure 21: AWS AIM - Access key ID and secret access key
-
-#. Click :guilabel:`Close`.
-
-Install and configure the AWS CLI tool on your system
-*****************************************************
-
-#. To install the tool on |CL|, simply run:
-
-   .. code-block:: bash
-
-      sudo swupd bundle-add cloud-api
-
-   .. note:
-
-      If you are using a different OS, follow the 
-      `Installing the AWS CLI version 2`_ guide.
-
-#. Configure it with your security credentials, default region,
-   and default output format. See `Configuring the AWS CLI`_ for more information.
-
-   .. code-block:: bash
-
-      aws configure
-
-   Below is an example (using the security credentials that was created in 
-   the previous section):
-
-   .. code-block:: console
-
-      AWS Access Key ID [None]: AKIA5LEGQPQ3EUB3JMS7
-      AWS Secret Access Key [None]: EcvbWpWr+Gp7NhBoVEacwR3EifzN7xTTg8B1PHvO
-      Default region name [None]: us-west-2
-      Default output format [None]: json 
-
-#. Verify your credentials are good.
-
-   .. code-block:: bash
-      
-      aws iam list-access-keys
-
-   If you get something like the example below, then make sure you set your 
-   system date and time properly.
-
-   .. code-block:: console
-
-      An error occurred (SignatureDoesNotMatch) when calling the ListAccessKeys operation: Signature expired: 20200305T153154Z is now earlier than 20200305T231847Z (20200305T233347Z - 15 min.)
-
-Import a snapshot of the |CL| image
-***********************************
-
-#. Create a :file:`container.json` with the description of the image to import.
-   Specify the name of the S3 bucket that was created earlier for the 
-   `S3Bucket` field and the name of |CL| image that was uploaded to the S3 bucket
-   for the `S3Key`.
-
-   Here's an example:
-
-   .. code-block:: console
-
-      {
-        "Description": "My Clear Linux AWS 32400 Image",
-        "Format": "raw",
-        "UserBucket": {
-          "S3Bucket": "my-clearlinux-bucket",
-          "S3Key": "clear-32400-aws.img"
-        }
-      }
-
-#. Import a snapshot of the image.
-
-   .. code-block:: bash
-
-      aws ec2 import-snapshot \
-      --description "My Clear Linux AWS 32400 Snapshot" \
-      --disk-container file://container.json
-
-   You should get an output similar this example:
-
-   .. code-block:: console
-
-      {
-        "Description": "My Clear Linux AWS 32400 Snapshot",
-        "ImportTaskId": "import-snap-00fa9ccd98e9b8378",
-        "SnapshotTaskDetail": {
-            "Description": "My Clear Linux AWS 32400 Snapshot",
-            "DiskImageSize": 0.0,
-            "Format": "RAW",
-            "Progress": "3",
-            "Status": "active",
-            "StatusMessage": "pending",
-            "UserBucket": {
-                "S3Bucket": "my-clearlinux-bucket",
-                "S3Key": "clear-32400-aws.img"
-            }
-        }
-    }
-
-#. Using the `ImportTaskId` from the previous step, check the status 
-   of the import.  For example:
-
-   .. code-block:: bash
-
-      snapshot_id=$(aws ec2 describe-import-snapshot-tasks \
-      --import-task-ids "import-snap-00fa9ccd98e9b8378" \
-      | grep SnapshotId | awk -F '"' '{print $4}')
-
-   Wait for the `Status` field to show `completed` before proceeding.
-
-   The resulting `snapshot_id` will be used to create an AMI in 
-   the next section.
-
-Create an AMI from the snapshot
-*******************************
-
-There are 2 methods to create an AMI from the snapshot.
-
-* *AWS CLI Method*:
-    
-  .. code-block:: bash
-    
-     aws ec2 register-image \
-     --name "My-Clear-Linux-32400-AMI" \
-     --description "My Clear Linux 32400 AMI" \
-     --architecture x86_64 \
-     --virtualization-type hvm \
-     --ena-support \
-     --root-device-name "/dev/sda1" \
-     --block-device-mappings "[ 
-       { 
-         \”Deviceame\": \"/dev/sda1\", 
-         \"Ebs\": {
-           \"SnapshotId\": \"$snapshot_id\" 
-         } 
-       } 
-     ]"
-
-* *GUI Method*: 
-
-  #. Go to :guilabel:`Services`, :guilabel:`Compute`, and select 
-     :guilabel:`EC2`.
-     See Figure 22. 
-
-   .. figure:: ../../_figures/aws/import-clr-aws-22.png
-      :scale: 100%
-      :alt: AWS Services - EC2
-
-      Figure 22: AWS Services - EC2
-    
-  #. Click :guilabel:`Snapshots`.
-     See Figure 23. 
-
-   .. figure:: ../../_figures/aws/import-clr-aws-23.png
-      :scale: 100%
-      :alt: AWS Services - Snapshots
-
-      Figure 23: AWS Services - Snapshots
-
-  #. Locate the snaphot using the `Snapshot ID`.
-     See Figure 24.
-
-   .. figure:: ../../_figures/aws/import-clr-aws-24.png
-      :scale: 100%
-      :alt: AWS Services - Snapshots
-
-      Figure 24: AWS Services - Snapshots
-    
-  #. Right-click it and select :guilabel:`Create Image`.
-
-  #. Configure as follows:
- 
-     * Enter the name in the :guilabel:`Name` field
-     * Enter the description in the :guilabel:`Description` field
-     * Set the :guilabel:`Architecture` as `x86_64`
-     * Set the :guilabel:`Virtualization type` as `Hardware-assisted virtualization`
-     * Set the :guilabel:`Root device name` as `/dev/sda1`
-
-     See Figure 25.
-
-     .. figure:: ../../_figures/aws/import-clr-aws-25.png
-        :scale: 100%
-        :alt: AWS Services - Snapshots
-
-        Figure 25: AWS Services - Snapshots
-    
-  #. Click :guilabel:`Create`.
-
-Launch an instance
-******************
-
-#. Go to :guilabel:`Services`, :guilabel:`Compute`, and select 
-   :guilabel:`EC2`.
-   See Figure 26. 
-
-   .. figure:: ../../_figures/aws/import-clr-aws-26.png
-      :scale: 100%
-      :alt: AWS Services - EC2
-
-      Figure 26: AWS Services - EC2
-    
-#. Click the :guilabel:`Launch Instance` dropdown and select 
-   :guilabel:`Launch Instance`.
-   See Figure 27. 
-
-   .. figure:: ../../_figures/aws/import-clr-aws-27.png
-      :scale: 100%
-      :alt: AWS Services - Launch instance
-
-      Figure 27: AWS Services - Launch instance
-
-#. On the left navigation bar, select :guilabel:`My AMIs`.
-   See Figure 28. 
-
-   .. figure:: ../../_figures/aws/import-clr-aws-28.png
-      :scale: 100%
-      :alt: AWS Services - Select AMI
-
-      Figure 28: AWS Services - Select AMI
-
-#. Find your AMI and click :guilabel:`Select`.
-
-#. From here onward, configure the details of your instance as desired 
-   and launch it.
-   
-Connect to your |CL| instance
-*****************************
-
-#. Follow these steps to `connect to your instance`_.
-
-Related topics
-**************
-
-* :ref:`azure`
-* :ref:`gce`
-* :ref:`clr-digitalocean`
-
-.. _Downloads: 
-   https://clearlinux.org/downloads
-.. _aws.yaml: 
-   https://cdn.download.clearlinux.org/current/config/image/aws.yaml
-.. _AWS image post-install script:
-   https://cdn.download.clearlinux.org/current/config/image/aws-disable-root.sh
-.. _Installing the AWS CLI version 2: 
-   https://docs.aws.amazon.com/cli/latest/userguide/install-cliv2.html
-.. _Configuring the AWS CLI: 
-   https://docs.aws.amazon.com/cli/latest/userguide/cli-chap-configure.html
-.. _connect to your instance: 
-   https://docs.01.org/clearlinux/latest/get-started/cloud-install/aws-web.html#connect-to-your-clear-linux-os-basic-instance
-.. _Installer YAML Syntax:
-   https://github.com/clearlinux/clr-installer/blob/master/scripts/InstallerYAMLSyntax.md
-
@@ -3,11 +3,10 @@
 Install using clr-installer and a configuration file
 ####################################################

-In addition to the interactive GUI and text-based modes,
-:command:`clr-installer` also supports an unattended mode where you 
-simply provide it a YAML configuration file.  
-
-This guide shows you two examples of how to use its unattended mode.  
+This page explains how to install |CL-ATTR| using the clr-installer tool
+with a configuration file. The configuration file (:file:`clr-installer.yaml`)
+can be reused to duplicate the same installation configuration on additional
+machines.

 .. contents::
   :local:
@@ -16,63 +15,67 @@ This guide shows you two examples of how to use its unattended mode.
 Prerequisites
 *************

-For installation onto bare metal, ensure that your target system 
-supports these requirements:
+Ensure that your target system supports the installation:

 * :ref:`system-requirements`
 * :ref:`compatibility-check`

-Download and make bootable USB of the live server image
-*******************************************************
+Process
+*******

-See :ref:`bootable-usb`.
+This guide describes two methods for using a configuration file with the
+clr-installer tool. You can use either method to achieve the same goal. Choose
+the method that works best for your setup.

-Example 1: Fresh installation onto bare metal
-*********************************************
+If you are installing |CL| for the first time, we recommend Example 1.

-This example uses a YAML configuration file to perform a new installation.
+To clone an existing |CL| setup on another system, we recommend Example 2.

-#. Boot up the |CL| Live Server USB thumb drive.
+Example 1
+=========

+This method uses a configuration file template to perform a new installation.
+
+Perform the following steps:
+
+#. Go to `Downloads`_ and download the latest Clear Linux OS Server image.
+
+   For example:
+   https://download.clearlinux.org/releases/30010/clear/clear-30010-live-server.iso.xz
+
+#. Follow the instructions to :ref:`bootable-usb` based on your OS.
+
+#. Boot up the USB thumb drive.
 #. Select :guilabel:`Clear Linux OS` from the menu.
-
-#. In the console window, log in as `root` and set a password.
-
+#. In the console window, log in as root and set a password.
 #. Verify you have a network connection to the Internet and configure proxy
   settings if you're working behind a firewall.
+#. Download a :file:`live-server.yaml` template.

-#. Download a sample YAML configuration file. For example, if you want to 
-   install |CL| with a desktop GUI, you might want to use :file:`live-desktop.yaml`.
-   Or you can use the :file:`live-server.yaml` if you want to install a non-GUI version
-   of |CL|.
+   For example:

-   * *Desktop:*
+   .. code-block:: bash

-     .. code-block:: bash
+      curl -O https://download.clearlinux.org/releases/30010/clear/config/image/live-server.yaml

-        curl -O https://cdn.download.clearlinux.org/current/config/image/live-desktop.yaml
+#. Edit the template and change the settings as needed.

-   * *Server:*
+   Commonly-changed settings include:

-     .. code-block:: bash
+.. _install-configfile-yaml-begin:

-        curl -O https://cdn.download.clearlinux.org/current/config/image/live-server.yaml
-
-#. Edit the YAML configuration file and change the settings as needed.
-
-   Commonly-changed settings include (refer to the example below):
-
-   a. Under *block-devices* (line 15), set your target media.  For example: ``file: "/dev/sda"``.
-   #. Under *targetMedia* (line 34), set the third partition size to “0” to use the entire disk space.
-   #. Under *bundles* (line 37), add additional bundles as needed.
+   #. Under *block-devices*, set “file: "/dev/sda"” or enter your preferred device.
+   #. Under *targetMedia*, set the third partition size to “0” to use the entire disk space.
+   #. Under *bundles*, add additional bundles as needed.
   #. Delete the *post-install* section unless you have post-installation scripts.
-   #. Under *Version* (line 50), set a version number. To use the latest version, set to “0”.
+   #. Under *Version*, set a version number. To use the latest version, set to “0”.

+   Commonly-changed settings are shown in lines 15, 34, 37, and 51 below.
   See `Installer YAML Syntax`_ for more details.

-   .. code-block:: console
+   .. code-block:: bash
      :linenos:
-      :emphasize-lines: 14,15,34,37,50
+      :emphasize-lines: 14,15,34,37,51

 		#clear-linux-config

@@ -118,6 +121,7 @@ This example uses a YAML configuration file to perform a new installation.
 		telemetry: false
 		iso: true
 		keepImage: true
+		autoUpdate: false

 		keyboard: us
 		language: en_US.UTF-8
@@ -125,67 +129,56 @@ This example uses a YAML configuration file to perform a new installation.

 		version: 30010

-#. Start the unattended installation using the `--config` option.
+.. _install-configfile-yaml-end:
+
+Start the installation with the command:
+
+.. code-block:: bash
+
+   clr-installer --config live-server.yaml
+
+Example 2
+=========
+
+This method uses a saved configuration file from a previous installation,
+which you can use to easily duplicate the installation on additional machines.
+
+Perform the following steps:
+
+#. Open a console window on a system where |CL| was installed to retrieve a
+   copy of the configuration file.
+
+#. In the console window, log in as root and enter your password.
+
+#. Change directory to :file:`/root` and copy the :file:`clr-installer.yaml`
+   file to a USB thumb drive.

   .. code-block:: bash

-      clr-installer --config live-server.yaml
+   	  cd /root
+   	  cp clr-installer.yaml <USB-thumb-drive>

-#. Reboot your system after installation is completed.
+Start the installation on the target with the following steps:

-Example 2: Replicate a previous installation
-********************************************
+#. Go to `Downloads`_ and download the latest Clear Linux OS Server image.

-This example uses a saved configuration file from a previous installation,
-which you can use to easily clone the installation on additional machines
-, ideally with the same hardware configuration.
+   For example:
+   https://download.clearlinux.org/releases/30010/clear/clear-30010-live-server.iso.xz

-.. warning::
-   
-   Be aware of the following when applying a saved configuration on a new machine:
-   
-   * Make sure the target media on the new machine matches up
-   
-   * The users' credentials will be replicated as well
+#. Follow the instructions to :ref:`bootable-usb` based on your OS.

-#. On a system where |CL| was installed, open a terminal window.
-
-#. Get root privilege.
+#. Boot up the USB thumb drive.
+#. Select :guilabel:`Clear Linux OS` from the menu.
+#. In the console window, log in as root and set a password.
+#. Verify you have a network connection to the Internet and configure proxy
+   settings if you're working behind a firewall.
+#. Plug in and mount the USB thumb drive containing the retrieved
+   :file:`clr-installer.yaml` configuration file.
+#. Start the installation with the command:

   .. code-block:: bash

-      sudo su
-
-#. Copy the :file:`clr-installer.yaml` from :file:`/root` to a USB thumb drive.
-
-   .. code-block:: bash
-
-      cp /root/clr-installer.yaml <USB-thumb-drive>
-
-#. Install on target system.
-
-   a. Boot up the |CL| Live Server USB thumb drive.
-
-   #. Select :guilabel:`Clear Linux OS` from the menu.
-
-   #. In the console window, log in as `root` and set a password.
-
-   #. Verify you have a network connection to the Internet and configure proxy
-      settings if you're working behind a firewall.
-
-   #. Plug in and mount the USB thumb drive containing the retrieved
-      :file:`clr-installer.yaml` configuration file.
-   
-   #. Doublecheck to make sure the target media in the saved configuration file
-      matches with the target system's. 
-
-   #. Start the installation.
-
-      .. code-block:: bash
-
-         clr-installer --config clr-installer.yaml
-
-   #. Reboot your system after installation is completed.
+      clr-installer --config clr-installer.yaml

 References
 **********
@@ -193,5 +186,7 @@ References
 * `Clear Linux Installer`_
 * `Installer YAML Syntax`_

+.. _Downloads: https://clearlinux.org/downloads
 .. _Clear Linux Installer: https://github.com/clearlinux/clr-installer
-.. _Installer YAML Syntax: https://github.com/clearlinux/clr-installer/blob/master/scripts/InstallerYAMLSyntax.md
+
+.. _Installer YAML Syntax: https://github.com/clearlinux/clr-installer/blob/master/scripts/InstallerYAMLSyntax.md
@@ -100,27 +100,17 @@ Setup nginx web server to host iPXE

   .. code-block:: bash

-      # setup nginx
      sudo mkdir -p /etc/nginx/conf.d
      sudo cp /usr/share/nginx/conf/nginx.conf.example /etc/nginx/nginx.conf
-      
-      # grant $USER permission to run the web server
-      sudo tee -a /etc/nginx/nginx.conf << EOF
-      user $USER;
-      EOF
-
-      # web server config
      sudo tee -a /etc/nginx/conf.d/${IPXE_APP_NAME}.conf << EOF
      server {
        listen ${IPXE_PORT};
        server_name localhost;
-
        # directory to store ipxe
        location /${IPXE_APP_NAME}/ {
          root ${WEB_ROOT_DIR}/${IPXE_APP_NAME};
          rewrite ^/${IPXE_APP_NAME}(/.*)$ \$1 break;
        }
-
        # directory to store clr-installer configs
        location /${CLR_INSTALLER_CONF_DIR}/ {
          root ${WEB_ROOT_DIR}/${CLR_INSTALLER_CONF_DIR};
@@ -133,7 +123,8 @@ Setup nginx web server to host iPXE

   .. code-block:: bash

-      sudo systemctl enable nginx --now
+      sudo systemctl enable nginx
+      sudo systemctl start nginx

 Configure iPXE
 **************
@@ -1,79 +0,0 @@
-.. _cl-guides:
-
-|CL-ATTR|
-#########
-
-.. note::
-
-   As of 22 May 2019 :file:`mixin` is no longer supported.
-
-.. container:: multicolumns three
-
-   .. container:: column smallcard featurecard
-
-      :ref:`swupd-guide`
-         Learn how to manage software and system updates in |CL|.
-
-   .. container:: column smallcard featurecard
-
-      :ref:`debug`
-         Discover how to use :command:`clr-debug-info` to leverage your
-         network to debug system software.
-
-   .. container:: column smallcard featurecard
-
-      :ref:`telem-guide`
-         Learn how you can opt-in to allow |CL| to collect data to identify
-         and fix bugs.
-
-   .. container:: column smallcard
-      
-      :ref:`autoproxy`
-          Discover how |CL| makes working behind a corporate proxy smoother.
-
-   .. container:: column smallcard
-
-      :ref:`autospec`
-         Learn about :command:`autospec` and how it used to automatically
-         include and maintain open source software in |CL|.
-
-   .. container:: column smallcard
-
-      :ref:`bundles-guide`
-         Find out what a bundle is and why it is an important part of
-         what makes |CL| secure and high performance. 
-
-   .. container:: column smallcard
-
-      :ref:`compatible-kernels`
-         Learn about all of the kernels available as installable bundles.
-
-   .. container:: column smallcard
-
-      :ref:`ister`  
-         Find out how |CL| uses this template-based installer to produce
-         images for each release.
-
-   .. container:: column smallcard
-
-      :ref:`mixer`
-         Learn how the |CL| team generates official update content and
-         releases.
-
-   .. container:: column smallcard
-
-      :ref:`security`
-         Learn how |CL| is designed to ensure the security of updates and
-         software.
-
-   .. container:: column smallcard
-
-      :ref:`stateless`
-         |CL| is stateless is designed to need little to no user
-         configuration.
-
-.. toctree::
-   :glob:
-   :hidden:
-
-   *
@@ -0,0 +1,92 @@
+.. _ister:
+
+ister.py image builder
+######################
+
+The `ister.py`_ tool is a template-based installer used by |CL-ATTR| to produce
+images for each release. The same ister tool is available for use in |CL| to
+create custom images based on an upstream image.
+
+.. contents::
+   :local:
+   :depth: 1
+
+Description
+***********
+
+|CL| is a rolling release and produces an average of 10 releases per week using the
+ister tool. With each release, we produce multiple
+:ref:`image types for different environments <image-types>` and use cases such
+as installers, Hyper-V, KVM, or VMWare.
+
+Each image has a JSON configuration file that is used by ister to generate the 
+image. These JSON configuration files describe the image type, partitions, version,
+and bundles that will be preinstalled by default with the image. For each image
+type we produce, the corresponding JSON configuration file for the image also is
+published.
+
+The :ref:`mixer<mixer>` tool also uses ister to build images for your custom
+mix. Like upstream images, a JSON configuration file is defined for the image,
+which ister uses to generate the image. Refer to the :ref:`mixer<mixer>` guide
+for instructions on using ister to build an image for a custom mix.
+
+Examples
+********
+
+Recreate an upstream image
+==========================
+
+The published configuration files for upstream images may be used to recreate an
+image. Here are some examples:
+
+* Use an older version of |CL| and the image is no longer available (only after
+  March 2017).
+* Customize the partitions of an image.
+* Customize the bundles preinstalled in an image.
+* Run your own post installation script.
+
+
+Follow these steps to recreate an upstream image based on the image's JSON
+configuration file:
+
+#. Install the :command:`os-installer` bundle. Refer to :ref:`swupd-guide` for
+   more information on installing bundles.
+
+#. Download the `ister.py`_ tool and grant it sudo privileges.
+
+#. Download the JSON configuration file for the desired image (located in
+   :file:`config/image/`):
+
+   * `Current release`_
+   * `Previous releases`_ (only after March 2017)
+
+   For a previous release, navigate to `Previous releases`_, select the version
+   you want, and find the JSON configuration file under
+   :file:`/clear/config/image`. For example:
+   ``https://cdn.download.clearlinux.org/releases/15700/clear/config/image/``
+
+#. Download the “PostNonChroot” script (if applicable).
+
+   The JSON configuration file for the image may have an accompanying
+   “PostNonChroot” script that is executed at the end of the image creation
+   process. If it does, download the script and make it executable.
+
+#. Edit the JSON configuration file as needed.
+
+#. If your configuration file has an accompanying "PostNonChroot" script, change
+   the default path of the script to match your path.
+
+#. Generate the new image with the following command:
+
+   .. code-block:: bash
+
+   	sudo ister.py -t [JSON configuration]
+
+Related topics
+**************
+
+* :ref:`mixer`
+
+.. _ister.py: https://github.com/bryteise/ister
+.. _Current release: https://cdn.download.clearlinux.org/current/
+.. _Previous releases: https://cdn.download.clearlinux.org/releases/
@@ -3,9 +3,10 @@
 mixer
 #####

-The |CL-ATTR| team uses **mixer** to generate official update content and 
-releases. The update content generated by mixer is then consumed by swupd on 
-a downstream client. The same mixer tool is available to those who wish to create customized update content and releases.
+**mixer** is the tool used by the |CL-ATTR| team to generate official update
+content and releases. The update content generated by mixer is then consumed
+by swupd on a downstream client. The same mixer tool is available as part of
+|CL| to create your own customized update content and releases.

 .. contents::
   :local:
@@ -19,21 +20,13 @@ mixer uses the following sources as inputs to generate update content:
 * Upstream |CL| bundles with their corresponding RPM packages
 * Locally-defined bundles with their corresponding local RPM packages
 * Locally-defined bundles with upstream RPM packages
-* Locally-defined bundles with non-RPM content

-Using the mixer tool, you select which content from these sources that
-becomes part of your update. Your selection of sources produces a unique 
-combination of functionality for your custom update content, known as 
-a **mix**.
+Using the mixer tool, you select which set of content from these sources
+will be part of your update. You can select content from each of these sources to make a unique combination of functionality for your custom update content, known as a **mix**.

 The update content that mixer generates consists of various pieces of OS
 content, update metadata, as well as a complete image. The OS content
-includes all files in an update, as well as zero- and delta-packs for
-improved update performance. The update metadata, stored as manifests, 
-describes all of the bundle information for the update. Update content 
-produced by mixer is then published to a web server and consumed by clients 
-via :command:`swupd`. Refer to :ref:`swupd <swupd-guide>` for additional 
-information regarding updates and update content.
+includes all files in an update, as well as zero- and delta-packs for improved update performance. The update metadata, stored as manifests, describes all of the bundle information for the update. Update content produced by mixer is then published to a web server and consumed by clients via :command:`swupd`. Refer to :ref:`swupd <swupd-guide>` for additional information regarding updates and update content.

 How it works
 ************
@@ -52,6 +45,26 @@ Prerequisites
  Add the mixer tool by installing the :command:`mixer` bundle. Refer to
  :ref:`swupd-guide` for more information on installing bundles.

+* Docker\* container
+
+  mixer by default runs all build commands in a Docker container to ensure
+  the correct tool versions are used. This also allows custom mixes to
+  automatically perform downstream format bumps when the upstream releases a
+  format bump. See `Format version`_ for additional information regarding
+  format bumps.
+
+  Refer to `Configure and enable Docker`_ for instruction.
+
+* Docker proxy (optional)
+
+  If you use a proxy server, you must set your proxy environment variables and
+  create a proxy configuration file for the Docker daemon and container.
+
+  Consult your IT department for the correct values if you are behind a
+  corporate proxy.
+
+  Refer to `Configure Docker proxy info`_ for instruction.
+
 * Location to host the update content and images

  In order for :command:`swupd` to make use of your mix, the update content for your mix must be hosted on a web server. Your mix will be configured with an update location URL, which :command:`swupd` will use to pull down updates.
@@ -147,7 +160,7 @@ A mix is created with the following steps:
 #. Create image.

   mixer creates a bootable image from your updated content using
-   the `clr-installer`_ tool. In this step you can specify which bundles you want
+   the :ref:`ister` tool. In this step you can specify which bundles you want
   *preinstalled* in the image. Users can later install other bundles available
   in your mix.

@@ -243,13 +256,11 @@ these include the :command:`native-kernel` bundle that is intended to be
 used on a bare metal system instead of a VM. So we will modify the default
 bundle set to get a smaller kernel image, which will also be faster to load.

-.. note:: 
-   
-   The only bundles available to :command:`swupd` for a given release are 
-   those that were added to the mix during build time. A mix doesn’t 
-   automatically inherit all upstream bundles.
+The only bundles available to :command:`swupd` for a given release are those
+that were added to the mix during build time. A mix doesn’t automatically
+inherit upstream bundles.

-#. Ensure that you have run `mixer init`, shown in Example 1.
+#. Assure that you have run `mixer init`, shown in Example 1.

 #. Update bundles in mix:

@@ -699,6 +710,11 @@ Follow the `afb.sh reference script`_ to learn how to do a manual format bump. T

 * Do a format bump to remove the deprecated bundle

+.. 
+  Example: Create a mix with custom RPM
+..
+  TODO future example to show copy into local-rpms...
+
 References
 **********

@@ -722,89 +738,32 @@ content.

   #builder.conf

-   #VERSION 1.2
+   #VERSION 1.0

   [Builder]
-      CERT = "/home/clr/mix/Swupd_Root.pem"
-      SERVER_STATE_DIR = "/home/clr/mix/update"
-      VERSIONS_PATH = "/home/clr/mix"
-      YUM_CONF = "/home/clr/mix/.yum-mix.conf"
+     CERT = "/home/clr/mix/Swupd_Root.pem"
+     SERVER_STATE_DIR = "/home/clr/mix/update"
+     VERSIONS_PATH = "/home/clr/mix"
+     YUM_CONF = "/home/clr/mix/.yum-mix.conf"

   [Swupd]
-      BUNDLE = "os-core-update"
-      CONTENTURL = "<URL where the content will be hosted>"
-      VERSIONURL = "<URL where the version of the mix will be hosted>"
-      COMPRESSION = ["external-xz"]
-      UPSTREAM_BUNDLES_URL = "https://github.com/clearlinux/clr-bundles/archive/"
+     BUNDLE = "os-core-update"
+     CONTENTURL = "<URL where the content will be hosted>"
+     VERSIONURL = "<URL where the version of the mix will be hosted>"

   [Server]
-      DEBUG_INFO_BANNED = "true"
-      DEBUG_INFO_LIB = "/usr/lib/debug"
-      DEBUG_INFO_SRC = "/usr/src/debug"
+     DEBUG_INFO_BANNED = "true"
+     DEBUG_INFO_LIB = "/usr/lib/debug"
+     DEBUG_INFO_SRC = "/usr/src/debug"

   [Mixer]
-      LOCAL_BUNDLE_DIR = "/home/clr/mix/local-bundles"
-      LOCAL_REPO_DIR = "/home/clr/mix/local-yum"
-      LOCAL_RPM_DIR = "/home/clr/mix/local-rpms"
-      OS_RELEASE_PATH = ""
+     LOCAL_BUNDLE_DIR = "/home/clr/mix/local-bundles"
+     LOCAL_REPO_DIR = ""
+     LOCAL_RPM_DIR = ""
+     DOCKER_IMAGE_PATH = "clearlinux/mixer"

-Additional explanation of variables in :file:`builder.conf` is provided in 
-Table 1.
-
-.. list-table:: **Table 1**: Variables in builder.conf   
-   :widths: 50, 50
-   :header-rows: 1
-
-   * - **Variable**
-     - **Description**
-
-   * - `CERT` 
-     - Sets the path where mixer stores the certificate file used to sign
-       content for verification. mixer automatically generates the 
-       certificate if you do not provide the path to an existing one, and 
-       signs the :file:`Manifest.MoM` file to provide security for the 
-       updated content you create. 
-
-       chroot-builder uses the certificate file to sign the root :file:`
-       Manifest.MoM` file to provide security for content verification. 
-       swupd uses this certificate to verify the :file:`Manifest.MoM` file's 
-       signature. 
-
-       For now, we strongly recommend that you do not modify this variable, 
-       as swupd expects a certificate with a very specific configuration to sign and verify properly.  
-
-   * - `CONTENTURL` and `VERSIONURL`
-     - Set these variables to the IP address of the web server hosting the
-       update content. 
-
-       VERSIONURL is the IP address where the swupd client 
-       looks to determine if a new version is available. 
-
-       CONTENTURL is the location from which swupd pulls content updates. If 
-       the web server is on the same machine as the SERVER_STATE_DIR 
-       directory, you can create a symlink to the directory in your web 
-       server's document root to easily host the content. 
-
-       These URLs are embedded in the images created by mixer.
-
-   * - `LOCAL_BUNDLE_DIR` 
-     - Sets the path where mixer stores the local bundle definition files. 
-       The bundle definition files include any new, original bundles you 
-       create, along with any edited versions of upstream bundles.  
-
-   * - `SERVER_STATE_DIR`
-     - Sets the path to which mixer outputs content. By default, mixer
-       automatically sets the path.    
-
-   * - `VERSIONS_PATH`
-     - Sets the path for the mix version and upstream version's two state
-       files: :file:`mixversion` and :file:`upstreamversion`. mixer creates 
-       both files for you when you set up the workspace.
-    
-   * - `YUM_CONF`  
-     - Sets the path where mixer automatically generates the  
-       :file:`.yum-mix.conf` file. The yum configuration file points the 
-       chroot-builder to where the RPMs are stored.
+Additional explanation of variables in :file:`builder.conf` is provided in Table
+1.

 +-------------------------------+----------------------------------------------------------+
 | **Variable**                  | **Explanation**                                          |
@@ -844,6 +803,9 @@ Table 1.
 |                               |                                                          |
 |                               | These URLs are embedded in the images created by mixer.  |
 +-------------------------------+----------------------------------------------------------+
+| `DOCKER_IMAGE_PATH`           | Sets the base name of the docker image that mixer pulls  |
+|                               | down to run builds in the proper container.              |
+-------------------------------+----------------------------------------------------------+
 | `LOCAL_BUNDLE_DIR`            | Sets the path where mixer stores the local bundle        |
 |                               | definition files. The bundle definition files include    |
 |                               | any new, original bundles you create, along with any     |
@@ -915,12 +877,13 @@ Bundles
 =======

 mixer stores information about the bundles included in a mix in a flat file
-called :file:`mixbundles`, which is located in the path set by the 
-VERSIONS_PATH variable in :file:`builder.conf`. :file:`mixbundles` is 
-automatically created when the mix is initiated. mixer will refresh the file 
-each time you change the bundles in the mix.
+called :file:`mixbundles`, which is located in the path set by the VERSIONS_PATH variable in :file:`builder.conf`. :file:`mixbundles` is automatically created when the mix is initiated. mixer will refresh the file each time you change the bundles in the mix.

-Bundles belong in one of two categories: upstream or local. Upstream
+Bundles can include other bundles. Nested bundles can themselves include
+other bundles. If you see an unexpected bundle in your mix, it is likely a
+nested bundle in one of the bundles you explicitly added.
+
+A bundle will fill into one of two categories: upstream or local. Upstream
 bundles are those provided by |CL|. Local bundles are either modified upstream bundles or new local bundles.

 Upstream bundles
@@ -934,8 +897,8 @@ contents of this directory before repopulating it on-the-fly if a new
 version must be downloaded.

 The mixer tool automatically caches the bundles for the |CL| version
-configured in the :file:`upstreamversion` file. :command:`mixer` also 
-cleans up old versions once they are no longer needed.
+configured in the :file:`upstreamversion` file. mixer also cleans up old
+versions once they are no longer needed.

 Local bundles
 -------------
@@ -950,62 +913,13 @@ precedence over any upstream bundles that have the same name. This
 precedence enables you to copy upstream bundles locally, and edit into a
 local variation.

-
-Bundle definition files
-----------------------
-
-A ``bundle definition`` file consists of a header, followed by a list 
-of packages and directives. The header holds important meta-data, like 
-the TITLE, DESCRIPTION, and STATUS. Other meta-data include TAGS, which 
-define a bundle's function in the ecosystem, and MAINTAINER, which gives 
-contact information. 
-
-Following the header are the directives, shown in Table 2. 
-
-.. list-table:: **Table 2**: Bundle directives
-   :widths: 50,50
-   :header-rows: 1 
-
-   * - **Directive**
-     - **Description**
-
-   * - ``include(<required-bundle-name>)``
-     - Add <required-bundle-name> with this bundle
-
-   * - ``also-add(<optional-bundle-name>)``
-     - Add <optional-bundle-name> unless the option ``--skip-optional`` is used with ``swupd bundle-add``.
-
-   * - ``content(<full/path/to/non-packaged/content>)``
-     - Add the non-packaged content to the bundle. Refer to :ref:`swupd-3rd-party` for usage of this directive. 
-
-Following is `cluster-tools`, an upstream bundle definition file. The
-directives are highlighted, and the rest are packages.
-
-.. code-block:: bash
-   :emphasize-lines: 8-12
-
-   [TITLE]: cluster-tools
-   [DESCRIPTION]: Utilities to manage computer clusters
-   [STATUS]: Active
-   [CAPABILITIES]: HPC
-   [TAGS]: Tools and Utilities
-   [MAINTAINER]: Juro Bystricky <juro.bystricky@intel.com>
-
-   include(curl)
-   include(libglib)
-   include(libX11client)
-   also-add(openmpi)
-   also-add(modules)
-   munge
-   pmix
-   pdsh
-   slurm
-
 Bundle configuration
 --------------------

 mixer provides commands to configure the bundles for a mix, such as to add a
-bundle to a mix, to create a new bundle for a mix, or to remove a bundle from a mix. View the `mixer.bundle man page`_ for a full list of commands and more information on configuring bundles in a mix.
+bundle to a mix, to create a new bundle for a mix, or to remove a bundle from a
+mix. View the `mixer.bundle man page`_ for a full list of commands and more
+information on configuring bundles in a mix.

 Editing an existing local bundle is as simple as opening the bundle definition
 file in your favorite editor, making the desired edits, and saving your changes.
@@ -1021,57 +935,187 @@ file in your favorite editor, making the desired edits, and saving your changes.

 .. rst-class:: content-collapse

-.. _set-up-nginx-web-server-start:
+Configure and enable Docker
+===========================
+
+Use these steps to enable Docker for the mixer tool. Make sure to
+`Configure Docker proxy info`_ first if needed.
+
+#. Start the Docker daemon:
+
+   .. code-block:: bash
+
+      sudo systemctl start docker
+      sudo chmod 777 /var/run/docker.sock
+      sudo docker info
+
+#. Add user to the docker group
+
+   .. code-block:: bash
+
+      sudo usermod -G docker -a <username>
+
+Pull Docker container manually (optional)
+-----------------------------------------
+
+By default, mixer automatically pulls a Docker container for mixing if one
+does not already exist. If you need to troubleshoot the mixer container, it
+may be useful to manually pull a mixer Docker container.
+
+Versions of the mixer Docker container are available under the tags for the
+`clearlinux/mixer repo <https://hub.docker.com/r/clearlinux/mixer/tags/>`_
+on Docker Hub. Each version of the mixer Docker container is named after the
+associated |CL| upstream format version. Refer to `Format version`_ for
+additional information on upstream format versions.
+
+Use the following steps to manually pull a mixer Docker container:
+
+#. Find the version of the container you need by viewing the tags for the
+   `clearlinux/mixer repo <https://hub.docker.com/r/clearlinux/mixer/tags/>`_
+   on Docker Hub.
+
+#. Pull the latest container version:
+
+   .. code-block:: bash
+
+      docker pull clearlinux/mixer:<upstream-format-version>
+
+#. View local docker images:
+
+   .. code-block:: bash
+
+      docker images
+
+.. rst-class:: content-collapse
+
+Configure Docker proxy info
+===========================
+
+If needed, use these steps to configure the Docker proxy information.
+
+#. Create the Docker daemon proxy config directory:
+
+   .. code-block:: bash
+
+      sudo mkdir -p /etc/systemd/system/docker.service.d
+
+#. Create :file:`/etc/systemd/system/docker.service.d/http-proxy.conf` and
+   add the following using your own proxy values:
+
+   .. code-block:: console
+
+      [Service]
+      Environment="HTTP_PROXY=<HTTP proxy URL>:<port number>"
+      Environment="HTTPS_PROXY=<HTTPS proxy URL>:<port number>"
+
+#. Reload the Docker daemon:
+
+   .. code-block:: bash
+
+      sudo systemctl daemon-reload
+
+Configure the Docker container proxies, to pass proxy settings to
+containers:
+
+#. Create a directory for your container config:
+
+   .. code-block:: bash
+
+      mkdir ~/.docker
+
+#. Create the config file :file:`~/.docker/config.json` and add the following
+   entries, using your own proxy values:
+
+   .. code-block:: console
+
+      {
+        "proxies":
+        {
+          "default":
+          {
+            "httpProxy": "<proxy-url>:<port>",
+            "httpsProxy": "<proxy-url>:<port>"
+          }
+        }
+      }
+
+#. Set ownership and permission on the docker config directory:
+
+   .. code-block:: bash
+
+      sudo chown "$USER":"$USER" /home/"$USER"/.docker -R
+      sudo chmod g+rwx "$HOME/.docker" -R
+
+Configure proxies to allow mixer to access upstream content from behind
+a firewall.
+
+#. Open your :file:`$HOME/.bashrc` file and add proxy and port values for the
+   following:
+
+   .. code-block:: console
+
+      export http_proxy="<proxy-url>:<port>"
+      export https_proxy="<proxy-url>:<port>"
+      export HTTP_PROXY="<proxy-url>:<port>"
+      export HTTPS_PROXY="<proxy-url>:<port>"
+      export no_proxy="<...>"
+
+#. Log out and log back in for the proxies to take effect.
+
+.. rst-class:: content-collapse

 Set up a nginx web server for mixer
 ===================================

-A web server is needed to host your update content. In this example, 
-the nginx web server is used.
+A web server is needed to host your update content. In this example, we use
+the nginx web server, which comes with |CL|.

-#. Install the :command:`nginx` bundle.
+Set up a nginx web server for mixer with the following steps:
+
+#. Install the :command:`nginx` bundle:

   .. code-block:: bash

      sudo swupd bundle-add nginx

-#. Create a symbolic link to the mixer update content directory. 
+#. Make the directory where mixer updates will reside:

   .. code-block:: bash

      sudo mkdir -p /var/www

+#. Create a symbolic link between your workspace updates and the updates on
+   the local nginx web server. In this example, `$HOME/mixer` is the
+   workspace for the mix.
+
+   .. code-block:: bash
+
      sudo ln -sf $HOME/mixer/update/www /var/www/mixer

-#. Set up nginx configuration files.
+#. Set up ``nginx`` configuration:

   .. code-block:: bash

      sudo mkdir -p  /etc/nginx/conf.d

+#. Copy the default example configuration file:
+
+   .. code-block:: bash
+
      sudo cp -f /usr/share/nginx/conf/nginx.conf.example /etc/nginx/nginx.conf

-#. Grant ``$USER`` permission to run the web server.
+#. Configure the mixer update server. Create and add the following server
+   configuration content to :file:`/etc/nginx/conf.d/mixer.conf` (sudo required):

-   .. code-block:: bash
+   .. code-block:: console

-      sudo tee -a /etc/nginx/nginx.conf << EOF
-      user $USER;
-      EOF
-
-#. Configure the mixer update server. 
-
-   .. code-block:: bash
-
-      sudo tee -a /etc/nginx/conf.d/mixer-server.conf << EOF
      server {
-        server_name localhost;
-        location / {
-          root /var/www/mixer;
-          autoindex on;
-        }
+           server_name localhost;
+           location / {
+                     root /var/www/mixer;
+                     autoindex on;
+           }
      }
-      EOF

 #. Restart the daemon, enable nginx on boot, and start the service.

@@ -1079,13 +1123,13 @@ the nginx web server is used.

      sudo systemctl daemon-reload

-      sudo systemctl enable nginx --now
+      sudo systemctl enable nginx

-#. Verify the web server is running at \http://<IP-address-of-web-server>.
-   If there's no mix content yet, the expected response from nginx will be 
-   a ``404 Not Found``.
+      sudo systemctl start nginx

-.. _set-up-nginx-web-server-end:
+#. Verify the web server is running at \http://<ip-address>,
+   where <ip-address> is the same one that you captured in
+   `Example 1: Mix set up`_.

 Related topics
 **************
@@ -1093,8 +1137,8 @@ Related topics
 * :ref:`autospec`
 * :ref:`bundles-guide`
 * :ref:`swupd-guide`
-* :ref:`swupd-3rd-party`

+.. _Docker Hub: https://hub.docker.com/r/clearlinux/mixer/tags/
 .. _mixer man page: https://github.com/clearlinux/mixer-tools/blob/master/docs/mixer.1.rst
 .. _mixer.init man page: https://github.com/clearlinux/mixer-tools/blob/master/docs/mixer.init.1.rst
 .. _mixer.bundle man page: https://github.com/clearlinux/mixer-tools/blob/master/docs/mixer.bundle.1.rst
@@ -4,7 +4,7 @@ Stateless
 #########

 In most operating systems, user data, system data, and configuration files
-can become intermingled, which can make them challenging to manage.
+can become intermingled.

 .. figure:: figures/stateless-1.png
   :scale: 45%
@@ -24,7 +24,7 @@ ephemeral or non-persistent.
 File-level separation
 *********************

-To accomplish a stateless design, the |CL| filesystem hierarchy is separated
+To accomplish a stateless design the Linux Filesystem Hierarchy is separated
 between user-owned areas and |CL|-owned areas.

 .. figure:: figures/stateless-2.png
@@ -63,17 +63,16 @@ Default configurations
 ======================

 Software in |CL| provides default configuration values so that it is
-immediately functional, except for some that require additional configuration.
+immediately functional, whenever it is appropriate to do so.

-If an upstream software puts default configurations in multiple locations 
-such as :file:`/usr/` and :file:`/etc`, it will be modified by the |CL| 
-distro to comply with the stateless design.  Also, some default configurations 
-may be modified to close security loopholes.  Defaults will reside 
-under :file:`/usr/share/defaults`.  These files can be referenced as 
-templates for customization.
+|CL| distributed software packages may be directly modified to include default
+configuration values or default configuration files may be provided by |CL|
+under :file:`/usr/share/defaults`. These files can be referenced as templates
+for customization.
+
+For example, the default configuration that Apache uses when installed can be
+found at :file:`/usr/share/defaults/httpd/httpd.conf` directory.

-For example, after installing the `httpd` bundle for Apache web server, its 
-default configurations appear in the :file:`/usr/share/defaults/httpd/` directory.

 Overriding configurations
 =========================
@@ -82,36 +81,30 @@ If a configuration needs to be changed, the appropriate file should be
 modified by the user under :file:`/etc/`. If the configuration file does not
 already exist, it can be created in the appropriate location.

-User-defined configuration files should contain the minimal set of desired
+User defined configuration files should contain the minimal set of desired
 changes and rely on default configuration for the rest.

 For example, a customized Apache configuration can be used instead by:

-#. Install the Apache web server bundle.
-
-   .. code-block:: bash
-
-      sudo swupd bundle-add httpd
-
-#. Create the destination directory for the configuration.
+#. Create the destination directory for the configuration:

   .. code-block:: bash

      sudo mkdir /etc/httpd

-#. Copy the default configuration as a reference template.
+#. Copy the default configuration as a reference template:

   .. code-block:: bash

      sudo cp /usr/share/defaults/httpd/httpd.conf /etc/httpd/

-#. Make any desired modifications to the configurations.
+#. Make any desired modifications to the configurations:

   .. code-block:: bash

      sudoedit /etc/httpd/httpd.conf

-#. Reload the service or reboot the system to pickup any changes.
+#. Reload the service or reboot the system to pickup any changes:

   .. code-block:: bash

@@ -123,7 +116,7 @@ The `stateless man page`_ has application-specific examples.
 System reset
 ************

-One advantage of the stateless design is that the system defaults can be
+Once advantage of the stateless design is that the system defaults can be
 easily restored by simply deleting everything under :file:`/etc/` and
 :file:`/var`.

@@ -135,8 +128,8 @@ just installed:
   sudo rm -rf /etc
   sudo rm -rf /var

-In other Linux distributions, this can be a catastrophic action that may render
-a system unable to boot and/or inaccessible.
+In other Linux distributions, this can be a catastrophic action that renders
+a system unable to boot.

 Additional information
 **********************
@@ -1,273 +0,0 @@
-.. _swupd-3rd-party:
-
-swupd 3rd-party 
-###############
-
-Upstream |CL| offers a plethora of `bundles`_ to choose from.  
-
-For users who want access to additional software outside of the distro, 
-|CL| provides support for 3rd-party bundles.  
-
-There are two components to 3rd-party bundles:
-
-* Use :command:`mixer` to create 3rd-party bundles
-
-* Use the :command:`swupd` subcommand :command:`3rd-party` to manage repos, 
-  consume and manage bundles
-
-Follow this guide to set up a web server to host 3rd-party bundles, 
-build an example 3rd-party bundle, install and manage the bundle on a 
-client system. 
-
-.. contents::
-   :local:
-   :depth: 1
-
-Prerequisite
-*************
-
-* Familiarity with :command:`mixer`
-* Familiarity with :command:`swupd`
-* You must be running |CL| version 32570 or higher
-
-.. include:: ./mixer.rst
-   :start-after: set-up-nginx-web-server-start:
-   :end-before: set-up-nginx-web-server-end:
-
-Create directory to hold 3rd-party app
-**************************************
-
-#. Create a top-level directory to hold all apps.
-	
-   .. code-block:: bash
-      
-      mkdir ~/my-3rd-party-apps && pushd $_
-
-#. Create a directory for each app and put the content of your software in it.  
-
-   In this example, the `helloclear.sh` app simply prints
-   "Hello Clear!" when invoked.  
-
-   .. code-block:: bash
-
-      # make helloclear directory
-      mkdir -p helloclear/usr/bin && pushd $_
-
-      # create helloclear.sh script
-      cat > helloclear.sh << EOF
-      #!/bin/bash
-      echo "Hello Clear!"
-      EOF
-
-      # make script executable
-      chmod +x helloclear.sh
-
-      popd
-
-   .. note:: 
-      
-      * You can put whatever you want in your app's directory. All of the content 
-        within each directory will get copied onto the client system under 
-        :file:`/opt/3rd-party/bundles/<repo-name>/`.
-
-      * To use a 3rd-party RPM, it is recommended to extract the content of the RPM 
-        into a directory.  Use :command:`rpm2cpio <RPM>| sudo cpio -idv`.
-       
-Create bundle of 3rd-party app with mixer
-*****************************************
-
-Next, use :command:`mixer` to create a bundle for each of the apps from the previous 
-section.  
-
-#. Install the mixer tool.
-   
-   .. code-block:: bash
-
-      sudo swupd bundle-add mixer
-
-#. Create a mixer workspace.
-   
-   .. code-block:: bash
-
-      mkdir ~/mixer && cd $_
-
-#. Initialize a mix without any default bundles.
-   
-   .. code-block:: bash
-
-      mixer init --no-default-bundles
-
-#. Configure :file:`builder.conf` to set the default bundle, CONTENTURL, and VERSIONURL.  
-   For the "URL"s in this example, it will be IP address of the web server that was
-   set up earlier.
-   Substitute <IP-address-of-web-server> with the IP address of your host.  
-
-   .. code-block:: bash
-      
-      mixer config set Swupd.BUNDLE "os-core"
-      mixer config set Swupd.CONTENTURL "http://<IP-address-of-web-server>"
-      mixer config set Swupd.VERSIONURL "http://<IP-address-of-web-server>"
-
-#. Create an empty local `os-core` bundle.  :command:`swupd` client expects the 
-   `os-core` bundle to exist in a mix even if it’s empty.
-
-   .. code-block:: bash
-      
-      mixer bundle create os-core --local
-
-#. Using the `helloclear` app as an example, create the `helloclear` bundle  
-   and use the `content()` directive with the path to the `helloclear` directory in
-   the bundle definition.
-
-   Refer to `bundle definition`_ for addition information on how to define a bundle.
-
-   .. code-block:: bash
-      
-      mixer bundle create helloclear --local
-      echo "content($HOME/my-3rd-party-apps/helloclear/)" >> local-bundles/helloclear
-
-#. Add both bundles to the mix.
-
-   .. code-block:: bash
-      
-      mixer bundle add os-core
-      mixer bundle add helloclear
-
-#. Build the bundles and generate the update content.
-
-   .. code-block:: bash
-      
-      sudo mixer build bundles
-      sudo mixer build update
-
-Install and manage 3rd-party bundle on client system
-****************************************************
-
-Finally, use the :command:`swupd` client tool to install and 
-manage the bundle created with :command:`mixer` earlier.
-All installed 3rd-party bundles reside in :file:`/opt/3rd-party/bundles/<repo-name>/`.
-
-#. First, add a repo link to the web server.
-   The `os-core` bundle will be added automatically when adding a repo.  
-   It contains items that mixer injected into the mix such as version information, 
-   format, CONTENTURL, VERSIONURL, and certificate.
-    
-   .. code-block:: bash
-
-      sudo swupd 3rd-party add my-3rd-party-repo \
-      http://<IP-address-of-web-server> --allow-insecure-http
-
-   .. note::
-      
-      By default, the :command:`swupd` client is designed to communicate 
-      with an HTTPS server. For development purposes, the swupd client 
-      can talk to an HTTP server if you add the flag ``--allow-insecure-http``.
-
-      To avoid adding this flag each time when invoking :command:`swupd`, enter:
-
-      .. code-block:: bash
-
-         sudo mkdir -p /etc/swupd
-
-         sudo tee -a /etc/swupd/config << EOF
-         [GLOBAL]
-         allow-insecure-http=true
-         EOF
-
-#. Query the list of bundles from the repo.
-   
-   .. code-block:: bash
-
-      sudo swupd 3rd-party bundle-list -a 
-
-#. Add the `helloclear` bundle.
-   
-   .. code-block:: bash
-
-      sudo swupd 3rd-party bundle-add helloclear
-
-#. List installed 3rd-party bundles.
-
-   .. code-block:: bash
-
-      sudo swupd 3rd-party bundle-list
-
-#. Look in :file:`/opt/3rd-party` to confirm they were installed there.  
-   
-   .. code-block:: bash
-
-      tree /opt/3rd-party
-
-   Example out:
-   
-   .. code-block:: console
-
-      /opt/3rd-party/
-      ├── bin
-      │   └── helloclear.sh
-      ├── bundles
-      │   └── my-3rd-party-repo
-      │       └── usr
-      │           ├── bin
-      │           │   └── helloclear.sh
-      │           ├── lib
-      │           │   └── os-release
-      │           └── share
-      │               ├── clear
-      │               │   ├── bundles
-      │               │   │   ├── helloclear
-      │               │   │   └── os-core
-      │               │   ├── update-ca
-      │               │   │   └── Swupd_Root.pem
-      │               │   ├── version
-      │               │   └── versionstamp
-      │               └── defaults
-      │                   └── swupd
-      │                       ├── contenturl
-      │                       ├── format
-      │                       └── versionurl
-      └── repo.ini
-
-      12 directories, 12 files
-
-Create more bundles and add to client
-*************************************
-
-From here on, to add new bundles to your mix, follow these steps:
-
-#. Follow the steps above to add a new directory for each app and put content into it.
-
-#. In the mixer workspace, run :command:`mixer versions update`.
-
-#. Follow the remaining mixer process to add and build bundles.  
-
-On the client side:
-
-#. Run :command:`sudo swupd 3rd-party update` to update to the latest version of your mix.
-
-#. Now, you can see and add the new bundles.
-
-Some limitations of 3rd-party bundles
-*************************************
-
-#. You cannot upload your bundles to a shared community repo because bundles
-   are tied to your particular mix with its own certificate. 
-   You have to host your own and share your repo.
-
-#. As with upstream bundles, 3rd-party bundles installation is simply the unpacking 
-   of files onto your system.  It cannot perform pre or post-installation actions such as 
-   adding a favorite shortcut to the Gnome desktop dock, for example.
-
-Related topics
-**************
-
-* :ref:`autospec`
-* :ref:`mixer`
-* :ref:`bundles`
-* :ref:`swupd-guide`
-
-.. _bundles: 
-   https://clearlinux.org/software
-.. _bundle definition:
-   https://docs.01.org/clearlinux/latest/guides/clear/mixer.html#id16
-
@@ -3,75 +3,55 @@
 Guides
 ######

-.. rst-class:: colh2
+The following guides provide step-by-step instructions on using |CL|.

-Featured Guides
+.. note::

-.. container:: multicolumns three
+   As of 22 May 2019 :file:`mixin` is no longer supported.

-   .. container:: column smallcard
-      
-      :ref:`stateless`
-         |CL| is stateless is designed to need little to no user
-         configuration. 
+.. _cl-guides:

-   .. container:: column smallcard
-
-      :ref:`mixer`
-          Learn how the |CL| team generates official update content and
-          releases.
-
-   .. container:: column smallcard
-
-      :ref:`dars`
-         Learn how to use the :abbr:`DARS (Data Analytics Reference Stack)`,
-         and build your own DARS container image.
-
-   .. container:: column smallcard
-
-      :ref:`dbrs`
-         Learn about the hardware and installation requirements of
-         :abbr:`DBRS (Database Reference Stack)`, and how to use |CL|
-         to host it.
-
-   .. container:: column smallcard
-
-      :ref:`cpu-performance`
-         Learn how to modify CPU power and performance settings for your
-         usecase. 
-
-   .. container:: column smallcard
-
-      :ref:`developer-workstation`
-         Set your workstation up with all bundles needed to
-         start your |CL| development project.
-
-   .. container:: column smallcard
-
-      :ref:`vnc`
-         Learn how to use VNC to connect to a remote |CL| host.
-
-   .. container:: column smallcard
-
-      :ref:`openssh-server`
-         Learn how to set up the SSH service.
-
-   .. container:: column smallcard
-
-      :ref:`kernel-modules`
-         Learn how to correctly and reliably add kernel modules manually.
-
-   .. container:: column smallcard
-
-     :ref:`kernel-development`
-         Learn how to compile a Linux\* kernel from source using |CL|
-         development tooling.
+Clear Linux
+===========

 .. toctree::
-   :hidden:
+   :maxdepth: 1
+   :glob:

-   clear/index
-   maintenance/index
-   network/index
-   kernel/index
-   stacks/index
+   clear/*
+
+Maintenance
+===========
+
+.. toctree::
+   :maxdepth: 1
+   :glob:
+
+   maintenance/*
+
+Network
+=======
+
+.. toctree::
+   :maxdepth: 1
+   :glob:
+
+   network/*
+
+Kernel
+=======
+
+.. toctree::
+   :maxdepth: 1
+   :glob:
+
+   kernel/*
+
+Stacks
+=======
+
+.. toctree::
+   :maxdepth: 1
+   :glob:
+
+   stacks/*
@@ -1,9 +0,0 @@
-.. _kernel-guides:
-
-Kernel
-######
-
-.. toctree::
-   :glob:
-
-   *
@@ -39,9 +39,8 @@ Install DKMS

 .. _kernel-modules-dkms-install-begin:

-The :command:`kernel-native-dkms` bundle provides the DKMS program and Linux
-kernel headers, which are placed under :file:`/usr/lib/modules/$(uname
-r)/build/include/` and are required to compile kernel modules.
+The :command:`kernel-native-dkms` bundle provides the DKMS program and
+Linux kernel headers, which are required for compiling kernel modules.

 The :command:`kernel-native-dkms` bundle also:

@@ -56,12 +56,11 @@ following example. See :ref:`swupd-guide` for more information.
 Submit a request to add the module
 ==================================

-If the kernel module you need is already open source (for example, in the
-Linux kernel upstream) and likely to be useful to others, consider submitting
-a request to add or enable it in the |CL| kernel.
+If the kernel module you need is already open source (for example, in the Linux
+upstream) and likely to be useful to others, consider submitting a request to
+add or enable it in the |CL| kernel.

-Make enhancement requests to the |CL| `Distribution Project on GitHub
-<https://github.com/clearlinux/distribution>`_.
+Make enhancement requests to the |CL| 'Distribution Project'_ on GitHub.

 .. _kernel-modules-availability-end:

@@ -103,9 +102,8 @@ Build and install kernel module
      5.XX.YY-ZZZZ.native

 #. Install the kernel dev bundle corresponding to the installed kernel. The
-   kernel dev bundle contains the kernel headers, which are placed under
-   :file:`/usr/lib/modules/$(uname -r)/build/include/` and are required to
-   compile kernel modules. For example:
+   kernel dev bundle contains the kernel headers, which are required for
+   compiling kernel modules. For example:

   * :command:`linux-dev` for developing against the native kernel.
   * :command:`linux-lts-dev` for developing against the LTS kernel.
@@ -114,8 +112,6 @@ Build and install kernel module

      sudo swupd bundle-add linux-dev

-   
-
 #. Follow instructions from the kernel module source code to compile the
   kernel module. For example:

@@ -178,19 +174,17 @@ Optional: Specify module options and aliases
 Use the :command:`modprobe` command to load a module and set options.

 :command:`modprobe` may add or remove more than one module due to module
-interdependencies. You can specify which options to use with individual
-modules, by using configuration files under the :file:`/etc/modprobe.d`
-directory.
+interdependencies. You can specify which options to use with individual modules,
+by using configuration files under the :file:`/etc/modprobe.d` directory.

 .. code-block:: bash

   sudo mkdir /etc/modprobe.d

 All files underneath the :file:`/etc/modprobe.d` directory that end with the
-:file:`.conf` extension specify module options to use when loading. You can
-use :file:`.conf` files to create convenient aliases for modules or to
-override the normal loading behavior altogether for those with special
-requirements.
+:file:`.conf` extension specify module options to use when loading. You can use
+:file:`.conf` files to create convenient aliases for modules or to override the
+normal loading behavior altogether for those with special requirements.

 Learn more about :command:`modprobe` on the modprobe.d manual page:

@@ -226,3 +220,4 @@ Related topic

 * :ref:`kernel-modules-dkms`

+.. _`Distribution Project`: https://github.com/clearlinux/distribution
@@ -55,7 +55,7 @@ tools you need to start. Consider these profiles as a starting point.
           - `machine-learning-web-ui <https://clearlinux.org/software/bundle/machine-learning-web-ui/>`_

         * - Machine learning Docker container.
-           - `machine-learning <https://clearlinux.org/software/docker/machine-learning-ui/>`_
+           - `machine-learning <https://clearlinux.org/software/docker/machine-learning/>`_

         * - Pre-built Python libraries for Data Science.
           - `python-extras <https://clearlinux.org/software/bundle/python-extras>`_
@@ -183,14 +183,14 @@ tools you need to start. Consider these profiles as a starting point.
         * - Run a secure shell (SSH) server for access from remote machines.
           - `openssh-server <https://clearlinux.org/software/bundle/openssh-server/>`_

-         * - Run an HTTP server.
-           - `nginx <https://clearlinux.org/software/bundle/nginx>`_
+         * - Run a HTTP web server.
+           - `web-server-basic <https://clearlinux.org/software/bundle/web-server-basic>`_

         * - Run an application server via HTTP.
           - `application-server <https://clearlinux.org/software/bundle/application-server/>`_

-         * - Run a SQLite database.
-           - `sqlite <https://clearlinux.org/software/bundle/sqlite>`_
+         * - Run an SQL database.
+           - `database-basic <https://clearlinux.org/software/bundle/database-basic>`_

         * - Bundle to automatically launch the GUI upon boot.
           - `desktop-autostart <https://clearlinux.org/software/bundle/desktop-autostart/>`_
@@ -10,6 +10,7 @@ editing kernel command line parameters, etc.

 To set a timeout value for the systemd-boot menu, follow these steps:

+
 #. Boot up |CL|.

 #. Log in.
@@ -19,5 +20,6 @@ To set a timeout value for the systemd-boot menu, follow these steps:
   .. code-block:: bash
      
      sudo clr-boot-manager set-timeout 20
+      sudo clr-boot-manager update

 #. Reboot.
@@ -1,9 +0,0 @@
-.. _maintain-guides:
-
-Maintenance
-###########
-
-.. toctree::
-   :glob:
-
-   *
@@ -1,9 +0,0 @@
-.. _network-guides:
-
-Network
-#######
-
-.. toctree::
-   :glob:
-
-   *
@@ -3,7 +3,7 @@
 Enable and configure SSH service
 ################################

-This guide describes how to set up the SSH service.
+This guide describes how to set up SSH service.

 .. contents::
   :local:
@@ -14,7 +14,7 @@ Overview

 The :command:`openssh-server` bundle provides the OpenSSH package that
 enables an SSH service in |CL-ATTR|. Remote users require an SSH service to be
-able to use an encrypted login shell. The SSH daemon has all of its configuration built in and no template configuration file is present on the file system.
+able to use an encrypted login shell.

 |CL| enables the `sshd.socket` unit, which listens on port 22 by default
 and starts the OpenSSH service as required. The first time OpenSSH starts, it
@@ -104,26 +104,43 @@ Enable SFTP
 ***********

 |CL| *disables* the :abbr:`SFTP (SSH File Transfer Protocol)` subsystem by
-default due to security considerations. To enable the SFTP subsystem, you can
-configure the :file:`/etc/ssh/sshd_config` file.
+default due to security considerations. To enable the SFTP subsystem, you must
+configure the :abbr:`SSHD (SSH Daemon)` service file.

-#. Create the following file, if it does not already exist:
-   :file:`/etc/ssh/sshd_config`
+#. Create a systemd drop-in directory for the SSHD service:

-#. Add the the SFTP subsystem in :file:`/etc/ssh/sshd_config`:
+   .. code-block:: bash
+
+      sudo mkdir -p /etc/systemd/system/sshd@.service.d
+
+#. Create the following file:
+   :file:`/etc/systemd/system/sshd@.service.d/sftp.conf`
+
+#. Add the OPTIONS environment variable to the :file:`sftp.conf` file.

   .. code-block:: console

-      subsystem sftp /usr/libexec/sftp-server
+      [Service]
+      Environment="OPTIONS=-o Subsystem=\"sftp /usr/libexec/sftp-server\""

+#. Reload systemd configuration:

-Congratulations! The SFTP subsystem is enabled. You do not need to restart the sshd service.
+   .. code-block:: bash
+
+      sudo systemctl daemon-reload
+
+Congratulations! The SFTP subsystem is enabled.

 Enable root login
 *****************

 To enable root login via SSH, perform the following steps:

+#. Create an *ssh* directory in :file:`/etc`, if it does not already exist.
+
+   .. code-block:: bash
+
+      mkdir /etc/ssh

 #. Create the following file, if it does not already exist:
   :file:`/etc/ssh/sshd_config`
@@ -134,8 +151,6 @@ To enable root login via SSH, perform the following steps:

      PermitRootLogin yes

-You have now enabled root login on your system.  You do not need to restart the sshd service. 
-
 Enable X11-forwarding
 *********************

@@ -144,6 +159,12 @@ clients) over the SSH connection. This enables remote GUI apps without the need
 for full VNC or remote desktop setup. To enable X11-forwarding via SSH,
 perform the following steps:

+#. Create an *ssh* directory in :file:`/etc`, if it does not already exist.
+
+   .. code-block:: bash
+
+      mkdir /etc/ssh
+
 #. Create the following file, if it does not already exist:
   :file:`/etc/ssh/sshd_config`

@@ -155,5 +176,3 @@ perform the following steps:
      X11UseLocalhost yes
      X11DisplayOffset 10
      X11Forwarding yes
-
-You have now enabled X11-forwarding!  You do not need to restart the sshd service.
@@ -15,7 +15,7 @@ Overview

 The Database Reference Stack is integrated, highly-performant, open source,
 and optimized for 2nd generation Intel® Xeon® Scalable Processors and Intel®
-Optane™ persistent memory. This open source community release is part of
+Optane™ DC Persistent Memory. This open source community release is part of
 an effort to ensure developers have easy access to the features and
 functionality of Intel Platforms.

@@ -23,24 +23,15 @@ Stack Features
 ==============

 Current supported  database applications are Apache Cassandra* and Redis*, which
-have been enabled for `Intel Optane PMM`_.
+have been enabled for `Intel Optane DC PMM`_.

 DBRS with Apache Cassandra can be deployed as a standalone container or inside a
 Kubernetes* cluster.

 The Redis stack application is enabled for a multinode Kubernetes
-environment, using AEP PMem DIMM in fsdax mode for storage.
-
-Releases
-********
-
-Refer to the `Database Reference Stack website`_ for information and download links for the different versions and offerings of the stack.
-
-The release announcement for each release provides more detail about the stack features, as well as benchmark results.
-
-* `DBRS V2.0`_ release announcement.
-* `DBRS V1.0`_ release announcement.
+environment, using AEP persistent memory DIMM in fsdax mode for storage.

+The `release announcement`_ for this release provides more detail about the stack features, as well as benchmark results.

 .. note::

@@ -52,10 +43,10 @@ The release announcement for each release provides more detail about the stack f
 Hardware Requirements
 *********************

-* Intel® Xeon Scalable Platform with Intel® C620 chipset series
-* 2nd Gen Intel® Xeon Scalable processor CPU (Intel® Optane™ PMM-enabled stepping) Provides cache & memory control.  Intel® Optane™  PMem works only on systems powered by 2nd Generation Intel® Xeon® Platinum or Gold processors.
+* Intel Xeon Scalable Platform with Intel C620 chipset series
+* 2nd Gen Intel Xeon Scalable processor CPU (Intel Optane DC PMM-enabled stepping) Provides cache & memory control.  Intel Optane DC persistent memory works only on systems powered by 2nd Generation Intel® Xeon® Platinum or Gold processors.
 * BIOS with Reference Code
-* Intel®Optane™ PMem
+* Intel Optane DC persistent memory

 Hardware configuration used in stacks development
 =================================================
@@ -64,12 +55,12 @@ Hardware configuration used in stacks development
 * BIOS with Reference Code
  * BIOS ID: SE5C620.86B.0D.01.0438.032620191658
  * BMC Firmware: 1.94.6b42b91d
-  * Intel® Optane™ PMemFirmware: 1.2.0.5310
-* 2x Intel® Xeon Platinum 8268 Processor
-* Intel® SSD DC S5600 Series 960GB 2.5in SATA Drive
+  * Intel® Optane™ DC Persistent MemoryFirmware: 1.2.0.5310
+* 2x Intel Xeon Platinum 8268 Processor
+* Intel SSD DC S5600 Series 960GB 2.5in SATA Drive
 * 64 GB RAM - Distributed in 4x 16 GB DDR4 DIMM's
-* 2x Intel® Optane™ PMem 256GB Module
-* 1-1-1 Layout 8 Optane™ : 1 RAM ratio
+* 2x Intel Optane DC Persistent Memory 256GB Module
+* 1-1-1 Layout 8 Optane : 1 RAM ratio


 .. list-table:: **Table 1. IMC**
@@ -117,13 +108,12 @@ Firmware Update Steps
 #. After update BMC firmware, system BIOS, ME firmware,FD, FRUSDR, system will reboot automatically.


-If Intel® Optane™ PMem is installed, run startup.nsh a second time after the first reboot to upgrade Intel® Optane™ PMem Firmware:
+If Intel Optane DC Persistent Memory is installed, run startup.nsh a second time after the first reboot to upgrade Intel Optane DC Persistent Memory Firmware:

 * Boot to EFI shell.
 * Input "fsx(x:0,1,...):" to enter into your usb disk
 * Run "startup.nsh" again to update the corresponding AEP FW.

-.. _dbrs-hardware-configuration:

 Hardware Configuration
 **********************
@@ -134,14 +124,14 @@ Online Resources

 Before going through the configuration steps, we strongly recommend visiting the following resources and wikis to have a broader understanding of what is being done

-* `Quick Start Guide`_ Configure Intel® Optane™ PMem Modules on Linux
+* `Quick Start Guide`_ Configure Intel Optane DC Persistent Memory Modules on Linux
 * `Managing NVDIMMs`_
-* `Configure, Manage, and Profile`_ Intel® Optane™ PMem Modules
+* `Configure, Manage, and Profile`_ Intel Optane DC Persistent Memory Modules

-Optane™ DIMM Configuration
-==========================
+Optane DIMM Configuration
+=========================

-The PMem DIMMs can be configured in devdax or fsdax mode. The use case to enable database stack on a kubernetes environment currently only support fsdax mode.
+The persistent memory DIMMs can be configured in devdax or fsdax mode. The use case to enable database stack on a kubernetes environment currently only support fsdax mode.

 Configuration Steps
 ===================
@@ -151,20 +141,20 @@ Configuration Steps
   Run the following steps with root privileges (sudo) as shown in the examples


-#. To configure Optane™ DIMMs for App direct mode run this command
+#. To configure Optane DIMMs for App direct mode run this command 

   .. code-block:: bash

      sudo ipmctl create -goal PersistentMemoryType=AppDirect

-#. Verify the Optane™ Configuration by showing the defined region, then reboot the system for your changes to take effect
+#. Verify the Optane Configuration by showing the defined region, then reboot the system for your changes to take effect

   .. code-block:: bash

      sudo ipmctl show -region


-#. Next, list the defined namespaces for the pmem devices in the system. If they are not defined, create them as shown in the following step.
+#. Next, list the defined namespaces for the pmem devices in the system. If they are not defined, create them as shown in the following step. 


   .. code-block:: bash
@@ -569,7 +559,7 @@ Eventually all the given nodes will be shown as running using :command:`kubectl
 Running DBRS with Redis
 ***********************

-The Redis stack application is enabled for a multinode Kubernetes environment using Intel® Optane™ DCPMM PMem DIMMs in fsdax mode for storage.
+The Redis stack application is enabled for a multinode Kubernetes environment using Intel Optane DCPMM persistent memory DIMMs in fsdax mode for storage.

 The source code used for this application can be found in the `Github repository`_

@@ -584,7 +574,7 @@ The following examples will use the `Docker image with Redis`_.  You can also bu
 Single node
 ===========

-Prior to starting the container, you will need to have the Intel® Optane™ DCPMM module in fsdax with a file system and mounted in `/mnt/dax0` as shown above.
+Prior to starting the container, you will need to have the Intel Optane DCPMM module in fsdax with a file system and mounted in `/mnt/dax0` as shown above.

 Use the following to start the container, replacing ${DOCKER_IMAGE} with the name of the image you are using.

@@ -622,46 +612,6 @@ To start a redisfailover instance in Kubernetes run the following

   There is a `known issue`_ in which the sentinels do not have enough memory to create the InitContainer. The current workaround is to build the image increasing the limits for the InitContainer memory to 32Mb

-Running DBRS with Memcached
-***************************
-
-With DBRS V2.0 you can use the DBRS stack with `Memcached`_, a free and open source, high performance, distributed meory object caching system. This stack is ready to use DCPMM in fsdax for storage.   The source for this application can be found in the `Memcached`_ repository.
-
-.. note::
-
-   The DBRS v2.0 release does not support Redis or Cassandra.
-
-
-
-Build the DBRS Memcached image
-==============================
-
-To build the Memcached enabled image, use the Dockerfile with this command:
-
-.. code-block:: bash
-
-   docker build --force-rm --no-cache -f Dockerfile -t ${DOCKER_IMAGE} .
-
-
-Run DBRS with Memcached as a standalone container
-=================================================
-
-Prior to launching the container, you will need to configure the DCPMM in fsdax mode with a file system, and have it mounted in :file:`/mnt/dax0`. Instructions for configuration can be found in :ref:`dbrs-hardware-configuration`.
-
-To launch the container run this command:
-
-.. code-block:: bash
-
-   docker run --mount type=bind,source=/mnt/dax0,target=/mnt/pmem0 -i -d --name pmem-memchached ${DOCKER_IMAGE} -e /mnt/pmem0/memcached.file -m 64 -c 1024 -p 11211
-
-where:
-
-:command:`-m` is the maximum memory limit to use in megabytes
-:command:`-e` is the mmap path for external memory (DCPMM storage).  For this container the DCPMM sould be mounted inside the container on :file:`/mnt/pmem0`
-:command:`-c` is the number of concurrent connections
-:command:`-p` is the TCP connection port.
-
-For more information please refer to this `blog post`_ from `Memcached`_



@@ -693,20 +643,10 @@ For more information please refer to this `blog post`_ from `Memcached`_

 .. _Docker image with Redis: https://hub.docker.com/r/clearlinux/stacks-dbrs-redis

-.. _Intel Optane PMM: https://www.intel.com/content/www/us/en/architecture-and-technology/optane-technology/optane-for-data-centers.html
+.. _Intel Optane DC PMM: https://www.intel.com/content/www/us/en/architecture-and-technology/optane-technology/optane-for-data-centers.html

 .. _pmem-csi: https://github.com/intel/pmem-csi/blob/release-0.6/README.md

 .. _DBRS Terms of Use: https://clearlinux.org/stacks/database/terms-of-use

-
-
-.. _Database Reference Stack website: https://clearlinux.org/stacks/database-reference
-
-.. _DBRS V1.0: https://clearlinux.org/news-blogs/database-reference-stack-dbrs-v10-now-available
-
-.. _DBRS V2.0: https://clearlinux.org/blogs-news/database-reference-stack-dbrs-v2-now-available
-
-.. _Memcached: https://memcached.org
-
-.. _blog post: https://memcached.org/blog/persistent-memory/
+.. _release announcement: https://clearlinux.org/news-blogs/database-reference-stack-dbrs-v10-now-available
@@ -1,9 +0,0 @@
-.. _stacks-guides:
-
-Stacks
-######
-
-.. toctree::
-   :glob:
-
-   *
@@ -21,12 +21,9 @@ complex standard-compliant encoders, and optimizing across the
 hardware-software stack for efficiency are all engineering and time
 investments for developers.

-The Media Reference Stack (MeRS) offers a highly optimized software stack for
-Intel Architecture to enable media prioritized workloads, such as transcoding
-and analytics. |MERS| abstracts away the complexity of integrating multiple
-software components and specifically tunes them for Intel platforms. |MERS|
-allows media and visual cloud developers to deliver experiences using a simple
-containerized solution. 
+The Media Reference Stack (MeRS) offers a highly optimized software stack for Intel Architecture to enable media prioritized workloads, such as
+transcoding and analytics. |MERS| abstracts away the complexity of 
+integrating multiple software components and specifically tunes them for Intel platforms. |MERS| allows media and visual cloud developers to deliver experiences using a simple containerized solution. 

 Prerequisites
 =============
@@ -57,8 +54,7 @@ The |MERS| provides a `pre-built Docker image available on DockerHub
 <https://hub.docker.com/r/clearlinux/stacks-mers>`_, which includes
 instructions on build the image from source. |MERS| is open-sourced to ensure
 developers have easy access to the source code and are able to customize it.
-|MERS| is built using the *clearlinux:latest* Docker image and aims to support
-the latest |CL| version.
+|MERS| is built using the *clearlinux:latest* Docker image and aims to support the latest |CL| version.

 |MERS| provides the following libraries:

@@ -76,32 +72,30 @@ the latest |CL| version.

 Components of the |MERS| include:

-* |CL| as a base for performance and security.
+* |CL| as a base for performance and security

-* `OpenVINO™ toolkit
-  <https://01.org/openvinotoolkit>`_ for inference.
+* `Intel® Distribution of OpenVINO™ toolkit
+  <https://software.intel.com/en-us/openvino-toolkit>`_ for inference.

-* `FFmpeg* <https://www.ffmpeg.org>`_ with `Scalable Video Technology (SVT)
+* `FFmpeg <https://www.ffmpeg.org>`_ with `Scalable Video Technology (SVT)
  <https://01.org/svt>`_ plugins for encoding, decoding, and transcoding.

-* `GStreamer* <https://gstreamer.freedesktop.org/>`_  with `Scalable Video
+* `GStreamer <https://gstreamer.freedesktop.org/>`_  with `Scalable Video
  Technology (SVT) <https://01.org/svt>`_ and `OpenVINO™ toolkit
-  <https://01.org/openvinotoolkit>`_ plugins for analytics.
-
+  <https://software.intel.com/en-us/openvino-toolkit>`_ plugins for
+  analytics.

 .. note::

   The pre-built |MERS| container image configures :command:`FFmpeg` without
   certain elements (specific encoder, decoder, muxer, etc.) that you may
-   require. If you require changes to :command:`FFmpeg` we suggest starting at
-   :ref:`building-the-mers-container-image`.
+   require. If you require changes to :command:`FFmpeg` we suggest starting at :ref:`building-the-mers-container-image`.

 .. note::

   The Media Reference Stack is a collective work, and each piece of software
   within the work has its own license. Please see the `MeRS Terms of Use
-   <https://clearlinux.org/stacks/media/terms-of-use>`_ for more details about
-   licensing and usage of the Media Reference Stack.
+   <https://clearlinux.org/stacks/media/terms-of-use>`_ for more details about licensing and usage of the Media Reference Stack.


 Getting the pre-built |MERS| container image
@@ -125,8 +119,7 @@ To use the |MERS|:
      The |MERS| docker image is large in size and will take some time to
      download depending on your Internet connection.

-      If you are on a network with outbound proxies, be sure to configure
-      Docker allow access. See the `Docker service proxy
+      If you are on a network with outbound proxies, be sure to configure Docker allow access. See the `Docker service proxy
      <https://docs.docker.com/config/daemon/systemd/#httphttps-proxy>`_ and
      `Docker client proxy
      <https://docs.docker.com/network/proxy/#configure-the-docker-client>`_
@@ -140,12 +133,10 @@ To use the |MERS|:

   This will launch the image and drop you into a bash shell inside the
   container. :command:`GStreamer` and :command:`FFmpeg` programs are
-   installed in the container image and accessible in the default $PATH. These
-   programs can be used as you would normally outside of |MERS|.
+   installed in the container image and accessible in the default $PATH. These programs can be used as you would normally outside of |MERS|.

-   Paths to media files and video devices, such as cameras, can be shared from
-   the host to the container with the :command:`--volume` switch `using Docker
-   volumes <https://docs.docker.com/storage/volumes/>`_.
+   Paths to media files and video devices, such as cameras, can be shared from the host to the container with the :command:`--volume` switch 
+   `using Docker  volumes <https://docs.docker.com/storage/volumes/>`_.

 .. _building-the-mers-container-image:

@@ -248,9 +239,8 @@ Guide <https://github.com/opencv/gst-video-analytics/wiki>`_ except simply
 substituting the *gst-video-analytics* docker image for the
 *clearlinux/stacks-mers* image.

-The example below shows how to use the |MERS| container image to perform video
-with object detection and attributes recognition of a video using GStreamer
-using pre-trained models and sample video files.
+The example below shows how to use the |MERS| container image to perform 
+video with object detection and attributes recognition of a video using GStreamer using pre-trained models and sample video files.

 #. On the host system, setup a workspace for data and models:

@@ -415,6 +405,3 @@ using pre-trained models and sample video files.
     .. code:: bash

       ./gst-video-analytics/samples/shell/console_measure_fps_cpu.sh $VIDEO_EXAMPLES_DIR/bolt-detection.mp4
-
-
-**OpenVINO is a trademark of Intel Corporation or its subsidiaries.**
@@ -75,4 +75,4 @@
   tutorials/index
   reference/index
   FAQ/index
-   collaboration/collaboration
+   collaboration/collaboration
@@ -15,7 +15,4 @@ Bundle list
 .. raw:: html
   :file: bundles.html.txt

-
-Another silly test!
-
 .. _clr-bundles repo: https://github.com/clearlinux/clr-bundles/tree/master/bundles
@@ -279,6 +279,7 @@ also provide a path to chain-boot GRUB.
   .. code-block:: bash	

      sudo clr-boot-manager set-timeout 20 --path=/mnt/clearlinux
+      sudo clr-boot-manager update --path=/mnt/clearlinux

 #. Add a system-boot boot entry for GRUB.
   
@@ -230,6 +230,8 @@ If you prefer not to use your BIOS to load the :guilabel:`Boot Menu` and select

      sudo clr-boot-manager set-timeout 20 --path=/mnt/clearlinux

+      sudo clr-boot-manager update --path=/mnt/clearlinux
+
 #. Umount all partitions.

   .. code-block:: bash
@@ -240,12 +240,17 @@ Install the NVIDIA drivers

      cd ~/Downloads/

+#. Make the :file:`NVIDIA-Linux-x86_64-<VERSION>.run` file executable.
+
+   .. code-block:: bash
+
+      chmod +x NVIDIA-Linux-x86_64-<VERSION>.run

 #. Run the installer with the advanced options below.

   .. code-block:: bash

-      sudo sh NVIDIA-Linux-x86_64-<VERSION>.run \
+      sudo ./NVIDIA-Linux-x86_64-<VERSION>.run \
      --utility-prefix=/opt/nvidia \
      --opengl-prefix=/opt/nvidia \
      --compat32-prefix=/opt/nvidia \
@@ -275,11 +280,11 @@ Install the NVIDIA drivers
      lsmod | grep ^nvidia

 #. Optional: Create a link for the nvidia-settings desktop entry to
-   :file:`~/.local/share/applications` so that it appears in the launcher for easy access. 
+   :file:`~/.local/share` so that it appears in the launcher for easy access. 

   .. code-block:: bash

-      ln -sv /opt/nvidia/share/applications/nvidia-settings.desktop $HOME/.local/share/applications
+      ln -sv /opt/nvidia/share/applications/nvidia-settings.desktop $HOME/.local/share


 Updating
@@ -355,22 +360,6 @@ driver restored with the instructions in this section.
   .. code-block:: bash

      sudo rm /etc/modprobe.d/disable-nouveau.conf
-      
-#. Remove the :file:`nvidia.conf` file so that dynamic linker does not
-   look for cached libraries under :file:`/opt/nvidia/lib` and :file:`/opt/nvidia/lib32`.
-   
-   .. code-block:: bash
-   
-      sudo rm /etc/ld.so.conf.d/nvidia.conf
-      sudo ldconfig
-
-   Optionally, restore :file:`ld.so.conf` to default if no other configuration files under :file:`/etc/ld.so.conf.d`
-   needs to be included.
-
-   .. code-block:: bash
-      
-      sudo sed -i '/^include \/etc\/ld\.so\.conf\.d\/\*\.conf$/d' /etc/ld.so.conf
-

 #. Remove the :file:`xorg.conf.d` file that adds a search path for X modules.

@@ -379,11 +368,11 @@ driver restored with the instructions in this section.
      sudo rm /etc/X11/xorg.conf.d/nvidia-files-opt.conf

 #. Remove the nvidia-settings desktop entry file if it was linked to
-   :file:`~/.local/share/applications`.
+   :file:`~/.local/share`.

   .. code:: bash

-      unlink -v $HOME/.local/share/applications/nvidia-settings.desktop
+      unlink -v $HOME/.local/share/nvidia-settings.desktop


 #. Run the :command:`nvidia-uninstall` command.