diff --git a/source/clear-linux/concepts/autospec-about.rst b/source/clear-linux/concepts/autospec-about.rst
index 61575fe2..ed3e03d9 100644
--- a/source/clear-linux/concepts/autospec-about.rst
+++ b/source/clear-linux/concepts/autospec-about.rst
@@ -102,6 +102,5 @@ Related topics
 
 * :ref:`autospec`
 * :ref:`mixer`
-* :ref:`mixin`
 
 .. _autospec readme: https://github.com/clearlinux/autospec
diff --git a/source/clear-linux/concepts/mixer-about.rst b/source/clear-linux/concepts/mixer-about.rst
index 485ea846..0548ed50 100644
--- a/source/clear-linux/concepts/mixer-about.rst
+++ b/source/clear-linux/concepts/mixer-about.rst
@@ -11,10 +11,8 @@ needs.
 However, if you need additional customization or content, |CL| provides the
 mixer tool. Depending on your needs, the mixer tool allows you to:
 
-1. :ref:`create-mix` to create a distinct derivative of the |CL| that
+* :ref:`create-mix` to create a distinct derivative of the |CL| that
    contains your custom software.
-2. :ref:`create-mixin` to add custom bundles but also keep updating the OS
-   from upstream.
 
 .. _create-mix:
 
@@ -43,31 +41,6 @@ act as your own OSV. There is a greater level of responsibility, requiring
 more infrastructure and processes to adopt. However, with this approach, you
 have a higher degree of control and customization of your custom |CL|.
 
-
-.. _create-mixin:
-
-Create a mixin
-==============
-
-The second option is to use the :command:`mixin` tool, a light wrapper for
-mixer, to create custom bundles and sideload them into your upstream version
-of |CL|. A mixin is useful when you need to add custom or 3rd
-party content but want to keep on the upstream update cycle, as shown in
-Figure 2. You can also create new bundles using upstream packages.
-
-.. figure:: figures/mixer-about-2.png
-   :scale: 75%
-   :alt: Creating a custom mix.
-
-   Figure 2: With a mixin you can add custom bundles, but stay on upstream.
-
-Mixin is primarily intended for end users. It is easier to adopt as it does
-not require breaking from upstream or acting as an OSV. With mixin
-
-* You are responsible for maintaining and testing your custom bundle(s).
-* You retain access to all upstream bundles and updates.
-* You can easily revert your system back to the upstream version.
-
 Related topics
 ==============
 
@@ -76,7 +49,6 @@ mixer and related topics to decide which customization approach is best for
 you.
 
 * :ref:`mixer`
-* :ref:`mixin`
 * :ref:`bundles-about`
 * :ref:`swupd-about`
 * :ref:`deploy-at-scale`
diff --git a/source/clear-linux/concepts/security.rst b/source/clear-linux/concepts/security.rst
index ee744db8..418b75f4 100644
--- a/source/clear-linux/concepts/security.rst
+++ b/source/clear-linux/concepts/security.rst
@@ -1,10 +1,10 @@
 .. _security:
 
-OS Security 
+OS Security
 *************************
 
 |CL-ATTR| aims to make systemic and layered security-conscious decisions
-that are both performant and practical. This security philosophy is rooted 
+that are both performant and practical. This security philosophy is rooted
 within the project's codebase and operating culture.
 
 
@@ -16,21 +16,21 @@ within the project's codebase and operating culture.
 Security in Updates
 ===================
 
-The |CL| team believes in the benefits of 
-software security through open sourcing, incremental updates, and 
+The |CL| team believes in the benefits of
+software security through open sourcing, incremental updates, and
 rapidly resolving known security advisories.
- 
 
 
-The latest Linux codebase
--------------------------
 
-|CL| uses the newest version of the Linux kernel which allows the operating 
-system to leverage the latest features from the upstream Linux kernel, 
-including security fixes. 
+The latest Linux* codebase
+--------------------------
+
+|CL| uses the newest version of the Linux kernel which allows the operating
+system to leverage the latest features from the upstream Linux kernel,
+including security fixes.
+
 
 
- 
 
 Automated Effective Updating
 ----------------------------
@@ -38,43 +38,43 @@ Automated Effective Updating
 |CL| is incrementally updated multiple times per day.
 
 This `rolling release model`_ allows |CL| to consume the latest security
-fixes of software packages as soon as they become available. 
-There is no waiting for major or minor releases on |CL|. 
+fixes of software packages as soon as they become available.
+There is no waiting for major or minor releases on |CL|.
 
-An update is not effective if it is just simply downloaded onto a system. 
+An update is not effective if it is just simply downloaded onto a system.
 It needs to be obtained *AND* ensured that the new patched copy is being
-used; not an older copy loaded into memory. |CL| will let you know when a 
-service needs to be rebooted or do it for your automatically after 
+used; not an older copy loaded into memory. |CL| will let you know when a
+service needs to be rebooted or do it for your automatically after
 a software update, if desired.
 
 
-In |CL| updates are delivered automatically, efficiently, 
-and effectively. For more information see 
+In |CL| updates are delivered automatically, efficiently,
+and effectively. For more information see
 `documentation about Software Updates`_ in |CL|.
 
- 
+
 
 
 
 Automated CVE Scanning and Remediation
 --------------------------------------
 
-The sheer number of software packages and security vulnerabilities is growing 
-exponentially. Repositories of Common Vulnerabilities and Exposures (CVEs) 
-and their fixes, if known, are published by :abbr:`NIST` in a 
+The sheer number of software packages and security vulnerabilities is growing
+exponentially. Repositories of Common Vulnerabilities and Exposures (CVEs)
+and their fixes, if known, are published by :abbr:`NIST` in a
 National Vulnerability Database \ |NVD|\  and at \ |MITRE|\  .
 
 
 |CL| employs a proactive and measured approach to addressing known
 and fixable :abbr:`CVEs (Common Vulnerabilities and Exposures)`.
-Packages are automatically scanned against 
-:abbr:`CVEs (Common Vulnerabilities and Exposures)` daily, and security 
-patches are deployed as soon as they are available. 
+Packages are automatically scanned against
+:abbr:`CVEs (Common Vulnerabilities and Exposures)` daily, and security
+patches are deployed as soon as they are available.
 
-These combined practices minimize the amount of 
+These combined practices minimize the amount of
 time |CL| systems are exposed to unnecessary security risk.
 
- 
+
 
 
 
@@ -86,18 +86,18 @@ Minimized attack surface
 -------------------------
 
 |CL| removes legacy, unneeded, or redundant standards and
-components as much as possible to enable the use of best known security 
-standards. Below are some examples: 
+components as much as possible to enable the use of best known security
+standards. Below are some examples:
 
-* `RC4`, `SSLv3`, `3DES`, and `SHA-1` ciphers which have had known 
-  vulnerabilities, have been explicitly disabled within many |CL| packages to 
-  avoid their accidental usage. 
+* `RC4`, `SSLv3`, `3DES`, and `SHA-1` ciphers which have had known
+  vulnerabilities, have been explicitly disabled within many |CL| packages to
+  avoid their accidental usage.
 
-* Services and subsystems which expose sensitive system information 
+* Services and subsystems which expose sensitive system information
   have been removed such as the `finger` and `tcpwrappers`.
 
-* `SFTP` has been disabled by default due to security 
-  considerations. 
+* `SFTP` has been disabled by default due to security
+  considerations.
 
 
 Verified trust
@@ -105,65 +105,62 @@ Verified trust
 
 |CL| encourages the use of secure practices such as encryption
 and digital signature verification throughout the system and discourages blind
-trust. Below are some examples: 
+trust. Below are some examples:
 
-* All update operations from swupd are transparently encrypted and checked 
-  against the |CL| maintainers' public key for authenticity. 
-  More information can be found in this blog post: 
-  `blog post about swupd security`_ 
+* All update operations from swupd are transparently encrypted and checked
+  against the |CL| maintainers' public key for authenticity.
+  More information can be found in this blog post:
+  `blog post about swupd security`_
 
-* Before being built, packages available from |CL| verify checksums and 
+* Before being built, packages available from |CL| verify checksums and
   signatures provided by third party project codebases and maintainers.
 
-* |CL| features a unified certificate store, `clrtrust`_ which comes 
-  ready to work with well-known Certificate Authorities out of the box. 
-  `clrtrust`_ also offers an easy to use command line interface for managing 
-  system-wide chains of trust, instead of ignoring foreign certificates. 
+* |CL| features a unified certificate store, `clrtrust`_ which comes
+  ready to work with well-known Certificate Authorities out of the box.
+  `clrtrust`_ also offers an easy to use command line interface for managing
+  system-wide chains of trust, instead of ignoring foreign certificates.
+
 
 
- 
 
 
 
 Compiled with secure options
 ----------------------------
 
-While |CL| packages are optimized for performance on 
-Intel® architecture, security conscious kernel and compiler options are 
-sensibly taken advantage of. Below are some examples: 
+While |CL| packages are optimized for performance on
+Intel® architecture, security conscious kernel and compiler options are
+sensibly taken advantage of. Below are some examples:
 
- 
-* Kernels shipped with |CL| are signed and disallow the usage of 
+
+* Kernels shipped with |CL| are signed and disallow the usage of
   custom kernel modules to maintain verifiable system integrity.
 
-* `Address space layout randomization (ASLR)`_ and 
+* `Address space layout randomization (ASLR)`_ and
   `Kernel address space layout randomization (KASLR)`_  are kernel features
-  which defend against certain memory based attacks. 
+  which defend against certain memory based attacks.
   More information can be found in a `blog post about PIE executables`_ .
 
-* `dm-verity`_ is a kernel mechanism readily available in |CL| 
-  which verifies integrity of the devices being written to, like hard disks,
-  to help ensure they have not been tampered with.  
 
 
 
-  
+
 
 Security in System Design
 =========================
 
-Simple, yet effective, techniques are used throughout the 
+Simple, yet effective, techniques are used throughout the
 |CL| system design to defend against common attack vectors and enable
-good security hygiene. Below are some examples: 
+good security hygiene. Below are some examples:
 
 
-* Full disk encryption using `Linux Unified Key Setup`_ (LUKS)  is available 
+* Full disk encryption using `Linux Unified Key Setup`_ (LUKS)  is available
   during installation.
 
 * |CL| uses the PAM cracklib module to harden user login and password
-  security resulting in: 
+  security resulting in:
 
-  - No default username or root password set out of the box with 
+  - No default username or root password set out of the box with
     |CL|, you will be asked to set your own password immediately.
 
   - Simple password schemes, which are known to be easily compromised,
@@ -172,9 +169,9 @@ good security hygiene. Below are some examples:
   - A password blacklist, to avoid system passwords being set to
     passwords which have been compromised in the past.
 
-* `Tallow`_, a lightweight service which monitors and blocks suspicious SSH 
-  login patterns, is installed with the :command:`openssh-server` bundle. 
-        
+* `Tallow`_, a lightweight service which monitors and blocks suspicious SSH
+  login patterns, is installed with the :command:`openssh-server` bundle.
+
 
 
 
@@ -190,7 +187,7 @@ good security hygiene. Below are some examples:
 .. _`dm-verity`: https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/tree/Documentation/device-mapper/verity.txt
 .. _`SELinux`: https://github.com/SELinuxProject
 .. _`Linux Unified Key Setup`: https://gitlab.com/cryptsetup/cryptsetup/
-.. _`blog post about PIE executables`: https://clearlinux.org/blogs/recent-gnu-c-library-improvements 
+.. _`blog post about PIE executables`: https://clearlinux.org/blogs/recent-gnu-c-library-improvements
 .. _`Tallow`: https://github.com/clearlinux/tallow
 
 .. |NVD| raw:: html
@@ -200,4 +197,3 @@ good security hygiene. Below are some examples:
 .. |MITRE| raw:: html
 
     <a href="https://cve.mitre.org/" target="_blank">https://cve.mitre.org/</a>
-
diff --git a/source/clear-linux/guides/deploy-at-scale.rst b/source/clear-linux/guides/deploy-at-scale.rst
index 8488e1b0..6935f378 100644
--- a/source/clear-linux/guides/deploy-at-scale.rst
+++ b/source/clear-linux/guides/deploy-at-scale.rst
@@ -3,8 +3,8 @@
 Deploy at Scale
 ###############
 
-Once you are comfortable with |CL-ATTR| :ref:`concepts <concepts>`, your next step
-as a system administrator is to understand how to deploy |CL|
+Once you are comfortable with |CL-ATTR| :ref:`concepts <concepts>`, your
+next step as a system administrator is to understand how to deploy |CL|
 at scale in your environment.
 
 In this document the term *endpoint* refers to a system targeted for
@@ -32,39 +32,10 @@ Different business scenarios call for different deployment methodologies.
 distribution or the option to fork away from the |CL| distribution and
 act as your own :abbr:`OSV (Operating System Vendor)`.
 
-Below are overviews of both approaches and some considerations.
+Below is an overview of some considerations.
 
-Option #1: Use the |CL| as the upstream origin (mixin)
-------------------------------------------------------
-
-This approach is *easier to adopt* by relying on the |CL| upstream for
-packaging updates for you to deploy.
-
-Custom software or packages that are not available in a preformed bundle
-can be added using the `mixin process`_ to form a custom bundle.
-If custom bundles are needed, you will be responsible for maintaining
-the custom bundle(s) and testing between |CL| releases in your environment,
-while the rest of the operating system and preformed bundles come from the
-|CL| upstream.
-
-#. Ensure |CL| systems are able to be inventoried, managed, and orchestrated
-   to coordinate software updates.
-
-#. With autoupdate enabled, |CL| is updated daily, however you may wish to
-   act as an intermediary buffer between the OS releases. If you do decide
-   to act as a gate to |CL| versions, define a desired release cadence for
-   yourself which is realistic with the operational expectations of your
-   environment.
-
-#. Use a web caching proxy for |CL| updates for devices connected to
-   a local area network (LAN), like a datacenter, to increase the speed
-   and resiliency of updates from the |CL| update servers.
-
-   Your caching proxy server is just like any other web application.
-   |WEB-SERVER-SCALE|
-
-Option #2: Create your own Linux distribution (mix)
----------------------------------------------------
+Create your own Linux distribution (mix)
+----------------------------------------
 
 This approach forks away from the |CL| upstream and has you act as your own
 :abbr:`OSV (Operating System Vendor)` by leveraging the `mixer process`_ to
@@ -267,7 +238,6 @@ Continuously test its use; Automate its use by redeploying |CL| and
 application on new hosts. This naturally minimizes configuration drift,
 challenges your monitoring systems, and business continuity plans.
 
-.. _`mixin process`: https://clearlinux.org/documentation/clear-linux/guides/maintenance/mixin
 .. _`mixer process`: https://clearlinux.org/documentation/clear-linux/guides/maintenance/mixer
 .. _`downloads page`: https://clearlinux.org/downloads/
 .. _`containers page`: https://clearlinux.org/downloads/containers
diff --git a/source/clear-linux/guides/guides.rst b/source/clear-linux/guides/guides.rst
index 96ec9bd6..d773743d 100644
--- a/source/clear-linux/guides/guides.rst
+++ b/source/clear-linux/guides/guides.rst
@@ -4,6 +4,7 @@ Guides
 ######
 
 The following guides provide step-by-step instructions on using |CL|.
+Note: As of 22 May 2019 :file:`mixin` is no longer supported.
 
 Tooling
 =======
diff --git a/source/clear-linux/guides/tooling/autospec.rst b/source/clear-linux/guides/tooling/autospec.rst
index 864ee77e..3779e52c 100644
--- a/source/clear-linux/guides/tooling/autospec.rst
+++ b/source/clear-linux/guides/tooling/autospec.rst
@@ -238,11 +238,14 @@ and dependencies in order for autospec to complete a successful build.
 
       cd packages/opae-sdk
 
-#. Add a license:
+#. Add one or more valid license identifier from the
+   `SPDX License List <https://spdx.org/licenses/>`_.
+   In the example below, two different licenses are appropriate based on the 
+   opae-sdk project licensing:
 
    .. code-block:: bash
 
-      echo "Intel Corporation" > opae-sdk.license
+      echo "BSD-3-Clause MIT" > opae-sdk.license
 
 #. Run autospec again:
 
@@ -327,7 +330,7 @@ Test packaged software
 
 After software has been packaged with autospec, the resulting RPMs can be
 tested for functionality before being integrated and deployed into a |CL|
-image with the :ref:`Mixer tool <mixer>` or :ref:`Mixin tool <mixin>`.
+image with the :ref:`Mixer tool <mixer>`.
 
 The |CL| development tooling offers two ways to quickly test autospec
 generated RPMs.
@@ -500,7 +503,6 @@ Related topics
 **************
 
 * :ref:`Mixer tool <mixer>`
-* :ref:`Mixin tool <mixin>`
 
 .. _user-setup script: https://github.com/clearlinux/common/blob/master/user-setup.sh
 .. _`Makefile.common file on GitHub`: https://github.com/clearlinux/common/blob/master/Makefile.common
diff --git a/source/clear-linux/guides/tooling/mixer.rst b/source/clear-linux/guides/tooling/mixer.rst
index fefafa3e..4aa85479 100644
--- a/source/clear-linux/guides/tooling/mixer.rst
+++ b/source/clear-linux/guides/tooling/mixer.rst
@@ -829,7 +829,6 @@ Related topics
 **************
 
 * :ref:`About mixer <mixer-about>`
-* :ref:`mixin`
 * :ref:`autospec-about`
 * :ref:`bundles-about`
 * :ref:`swupd-about`
diff --git a/source/clear-linux/guides/tooling/mixin.rst b/source/clear-linux/guides/tooling/mixin.rst
deleted file mode 100644
index 37e47ef8..00000000
--- a/source/clear-linux/guides/tooling/mixin.rst
+++ /dev/null
@@ -1,191 +0,0 @@
-.. _mixin:
-
-mixin
-#####
-
-mixin is a tool provided in the |CL-ATTR| that allows users to add custom
-content to their client systems and still receive updates from their upstream OS
-vendor.
-
-.. contents::
-   :local:
-   :depth: 1
-
-Description
-***********
-
-mixin uses the mixer tool to generate a local update for client systems. With
-the mixin tool, a user can add remote RPM repositories or local RPMs and mix
-them into their update stream, while continuing to get upstream bundles and
-updates. The metadata generated from the mixin tool is merged with the upstream
-metadata to provide a single source of update content, which swupd uses to
-perform updates.
-
-The mixin tool is included in the :command:`mixer` bundle.
-
-How to use
-**********
-
-Learn the mixin tool set up and workflow.
-
-.. contents::
-   :local:
-   :depth: 1
-
-Prerequisites
-=============
-
-Install the :command:`mixer` bundle to add the mixin tool. Refer to
-`Install a bundle`_ for more details.
-
-Workflow
-========
-
-The following steps show how to create and add a custom bundle with the mixin
-tool:
-
-#. Add or create a new repo(s)
-
-   mixin pulls packages to build your custom bundle from locations referred to
-   as repos. There are two default repos for mixin:
-
-   * upstream
-   * local
-
-   Additional repos can be added, such as other locations on your local system
-   or remote repos.
-
-   RPMs must be built specifically for |CL| in order for them to work properly.
-   Refer to :ref:`autospec` for instruction on creating RPMs for |CL|.
-
-#. Create a custom bundle with desired RPMs
-
-   Add the desired packages to your new bundle and build the bundle. By default,
-   the bundle will be named after its parent repo.
-
-   The first time you build the bundle, mixer will create a new OS version by
-   taking your current upstream |CL| version and multiplying it by 1000. For
-   example, if your upstream version is 27650, your custom version will be
-   27650000. For each subsequent call to mixin, mixer will increment the version
-   by 10.
-
-   View the `mixin man page`_ for more information on mixin commands.
-
-#. Update system to make custom bundle available
-
-   Update your system using swupd to make your custom bundle accessible.
-
-   When you first create your mix, you will have to do a one-time migration to
-   your custom mix as part of the update. After you migrate, the system version
-   switches over to your last custom version number as noted in the previous
-   step. As long as you remain on your custom version of |CL| you can continue
-   to create and add new bundles to your mix with no extra migration step.
-
-#. Install custom bundles
-
-   Install your custom bundle using the normal swupd :command:`bundle-add`
-   command.
-
-   View the `swupd man page`_ for more information on swupd commands.
-
-Examples
-********
-
-Complete all `Prerequisites`_ before using these examples.
-
-Example 1: Add custom helloclear bundle
-=======================================
-
-This example shows the basic steps of adding a custom bundle from a local repo.
-
-#. Check that :command:`helloclear` does not exist on your system:
-
-   .. code-block:: bash
-
-      helloclear
-
-   .. code-block:: console
-
-      helloclear: command not found
-
-#. Follow the "Build a new RPM" example from :ref:`autospec` to create a new
-   `helloclear` RPM.
-
-   The resulting RPMs are in `~/clearlinux/packages/helloclear/rpms`.
-
-#. Create a new repo.
-
-   #. Create a local repo folder and copy the new `helloclear` RPM files into
-      the repo:
-
-      .. code-block:: bash
-
-         mkdir ~/mixin-repo
-         cp ~/clearlinux/packages/helloclear/rpms/helloclear-v1.0-1.x86_64.rpm ~/mixin-repo
-         cp ~/clearlinux/packages/helloclear/rpms/helloclear-bin-v1.0-1.x86_64.rpm ~/mixin-repo
-
-   #. Create the repo data:
-
-      .. code-block:: bash
-
-         cd ~/mixin-repo
-         createrepo_c .
-
-   #. Add the repo name:
-
-      .. code-block:: bash
-
-         sudo mixin repo add mylocalrepo file://$HOME/mixin-repo/
-
-#. Create custom bundle with the new `helloclear` RPM. Add `helloclear` to the
-   :command:`helloclear-bundle` bundle and build the bundle:
-
-   .. code-block:: bash
-
-      sudo mixin package add helloclear --bundle helloclear-bundle
-      sudo mixin build
-
-#. Migrate your |CL| to your custom mix. Check your version before and after the
-   update to see the switch to your custom mix:
-
-   .. code-block:: bash
-
-      sudo swupd check-update
-      sudo swupd update --migrate
-      sudo swupd check-update
-
-#. Install your custom bundle. Check that the `helloclear-bundle` is now
-   available and install it to your system:
-
-   .. code-block:: bash
-
-      sudo swupd bundle-list -a | grep helloclear-bundle
-      sudo swupd bundle-add helloclear-bundle
-
-#. Test for `helloclear` again to see that it is installed:
-
-   .. code-block:: bash
-
-      helloclear
-
-#. Revert your system back to upstream (optional). This example reverts back to
-   upstream version 27650:
-
-   .. code-block:: console
-
-      sudo swupd verify --fix --picky --force -m 27650 -C /usr/share/clear/update-ca/Swupd_Root.pem
-      sudo swupd clean --all
-      sudo swupd check-update
-
-Related topics
-**************
-
-* :ref:`About mixer <mixer-about>`
-* :ref:`mixer`
-* :ref:`autospec-about`
-* :ref:`bundles-about`
-* :ref:`swupd-about`
-
-.. _mixin man page: https://github.com/clearlinux/mixer-tools/blob/master/docs/mixin.1.rst
-.. _swupd man page: https://github.com/clearlinux/swupd-client/blob/master/docs/swupd.1.rst
-.. _Install a bundle: https://clearlinux.org/documentation/clear-linux/guides/maintenance/swupd-guide#adding-a-bundle
\ No newline at end of file
diff --git a/source/clear-linux/tutorials/nvidia.rst b/source/clear-linux/tutorials/nvidia.rst
index afccf20c..55c84a88 100644
--- a/source/clear-linux/tutorials/nvidia.rst
+++ b/source/clear-linux/tutorials/nvidia.rst
@@ -52,12 +52,12 @@ Install the appropriate DKMS bundle using the instructions below:
    :end-before: kernel-modules-dkms-install-end:
 
 
-Download and install the NVIDIA Linux Driver
-********************************************
+Download and install the NVIDIA Drivers
+***************************************
 
 
-Download the NVIDIA Linux Driver
-================================
+Download the NVIDIA Drivers for Linux
+=====================================
 
 #. Identify the model of NVIDIA GPU that is installed.
 
@@ -107,28 +107,35 @@ needs to be disabled before installation can continue.
 
 
 
-Install the NVIDIA Linux Driver
-===============================
+Configure the Dynamic Linker
+============================
 
 The NVIDIA installer will be directed to install files under
 :file:`/opt/nvidia` as much as possible to keep its contents isolated from the
-rest of the |CL| files under :file:`/usr`. 
+rest of the |CL| system files under :file:`/usr`.  The dynamic linker will
+need to be configured to use the NVIDIA-provided libraries.
+
+
+#. Configure the dynamic linker to look for and cache shared libraries under
+   :file:`/opt/nvidia/lib` and :file:`/opt/nvidia/lib32`.
+
+   .. code-block:: bash
+      
+      echo "include /etc/ld.so.conf.d/*.conf" |  sudo tee --append /etc/ld.so.conf
+      
+      sudo mkdir /etc/ld.so.conf.d
+      printf "/opt/nvidia/lib \n/opt/nvidia/lib32 \n" | sudo tee --append /etc/ld.so.conf.d/nvidia.conf
+      
+
+
+Install the NVIDIA Drivers
+==========================
 
 
 #. A terminal not running on */dev/tty1* is useful to view uninterrupted
    installation progress. Switch to a secondary virtual terminal by pushing
    :command:`CTRL + ALT + F2` or remotely login over SSH. 
 
-#. Configure the dynamic linker to look for and cache shared libraries under
-   :file:`/opt/nvidia/lib` and :file:`/opt/nvidia/lib32` where the NVIDIA
-   installer will place libraries. 
-
-   .. code-block:: bash
-      
-      echo "include /etc/ld.so.conf.d/*.conf" |  sudo tee --append /etc/ld.so.conf
-      sudo mkdir /etc/ld.so.conf.d
-      printf "/opt/nvidia/lib \n/opt/nvidia/lib32 \n" | sudo tee --append /etc/ld.so.conf.d/nvidia.conf
-
 
 #. Navigate into the directory where the NVIDIA installer was downloaded.
 
@@ -183,8 +190,55 @@ rest of the |CL| files under :file:`/usr`.
    with the proprietary NVIDIA drivers installed.
       
 
-Uninstalling the NVIDIA driver
-******************************
+
+
+Updating the NVIDIA Drivers
+***************************
+
+The proprietary NVIDIA drivers are installed manually outside of :ref:`swupd
+<swupd-about>` and must be updated manually when needed.
+
+Updating the NVIDIA drivers follows the same steps as initial installation,
+however the desktop environment must first be stopped so that the drivers are
+not in use. 
+
+#. Follow the steps in `Download the NVIDIA Drivers for Linux`_ section to get
+   the latest NVIDIA drivers.
+
+#. Temporarily set the default boot target to the *multi-user* which is
+   a non-graphical runtime.
+
+   .. code-block:: bash
+
+      sudo systemctl set-default multi-user.target
+
+
+#. Reboot the system and log back in. It is normal for the graphical
+   environment to not start.
+
+#. Follow the steps in `Install the NVIDIA Drivers`_ section to update
+   the NVIDIA drivers. This installation will overwrite the previous NVIDIA
+   drivers and files.
+
+#. Set the default boot target back to the *graphical* target.
+
+   .. code-block:: bash
+
+      sudo systemctl set-default graphical.target
+
+
+#. Reboot the system and log back in. 
+
+#. Trigger a flatpak update which will download the runtime corresponding
+   with the new NVIDIA drivers for flatpak apps requiring it.
+
+   .. code-block:: bash
+
+      flatpak update
+
+
+Uninstalling the NVIDIA Drivers
+*******************************
 
 The NVIDIA drivers and associated software can be uninstalled and nouveau
 driver restored by: 
@@ -202,8 +256,8 @@ driver restored by:
 #. Follow the prompts on the screen and reboot the system. 
 
 
-Debugging NVIDIA driver installation
-************************************
+Debugging Installation of NVIDIA Drivers 
+****************************************
 
 * The NVIDIA driver places installer and uninstaller logs under
   :file:`/var/log/nvidia-install` and :file:`/var/log/nvidia-uninstall`.