mirror of
https://github.com/clearlinux/clear-linux-documentation.git
synced 2026-10-03 23:48:28 +00:00
Merge branch 'master' of github.com:clearlinux/clear-linux-documentation into rtd-theme
This commit is contained in:
Kevin Putnam
@@ -354,11 +354,7 @@ team for improvements. For more information, see :ref:`telemetry-about`.
|
||||
|
||||
#. From :guilabel:`Required Options`, select :guilabel:`Telemetry`.
|
||||
|
||||
#. Select :kbd:`Confirm`.
|
||||
|
||||
#. If you don't wish to participate, deselect :kbd:`Enable Telemetry`.
|
||||
|
||||
#. Select :kbd:`Confirm`.
|
||||
#. Select :kbd:`Yes`.
|
||||
|
||||
.. figure:: figures/bare-metal-install-desktop-12.png
|
||||
:scale: 100%
|
||||
@@ -366,6 +362,8 @@ team for improvements. For more information, see :ref:`telemetry-about`.
|
||||
|
||||
Figure 12: Enable Telemetry
|
||||
|
||||
#. If you don't wish to participate, select :kbd:`No`.
|
||||
|
||||
Advanced options
|
||||
****************
|
||||
|
||||
|
||||
BIN
Binary file not shown.
|
Before Width: | Height: | Size: 57 KiB After Width: | Height: | Size: 53 KiB |
@@ -49,6 +49,11 @@ Follow these steps to install |CL| on the target system:
|
||||
#. Open the system BIOS setup menu by pressing the :kbd:`F2` key.
|
||||
Your BIOS setup menu entry point may vary.
|
||||
|
||||
.. note::
|
||||
|CL| supports UEFI boot. Some hardware may list UEFI and non-UEFI USB
|
||||
boot entries. In this case, you should select the `UEFI` boot
|
||||
option.
|
||||
|
||||
#. In the setup menu, enable the UEFI boot and set the USB drive as the first
|
||||
option in the device boot order.
|
||||
|
||||
|
||||
Binary file not shown.
|
Before Width: | Height: | Size: 55 KiB After Width: | Height: | Size: 88 KiB |
@@ -35,7 +35,7 @@ checksum file designated with the suffix `-SHA512SUMS`.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
shasum -a512 ./clear-[version number]-[image type].[compression type] | diff ./clear-[version number]-[image type].[compression type]-SHA512SUMS -
|
||||
shasum -a512 clear-[version number]-[image type].[compression type] | diff clear-[version number]-[image type].[compression type]-SHA512SUMS -
|
||||
|
||||
If the checksum of the downloaded image is different than the original
|
||||
checksum, the differences will be displayed. Otherwise, an empty output indicates
|
||||
@@ -44,8 +44,8 @@ a match and your downloaded image is good.
|
||||
Decompress the |CL| image
|
||||
*************************
|
||||
|
||||
We compress all released |CL| images by default with either GNU zip
|
||||
(`.gz`) or xz (`.xz`). The compression type we use depends on the target
|
||||
We compress all released |CL| images by default with either GNU zip
|
||||
(`.gz`) or xz (`.xz`). The compression type we use depends on the target
|
||||
platform or environment. To decompress the image, follow these steps:
|
||||
|
||||
#. Start the Terminal app.
|
||||
|
||||
+73
-71
@@ -3,7 +3,7 @@
|
||||
mixer
|
||||
#####
|
||||
|
||||
mixer is the tool used by the |CL-ATTR| team to generate official update content
|
||||
**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.
|
||||
@@ -23,13 +23,13 @@ mixer uses the following sources as inputs to generate update content:
|
||||
|
||||
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).
|
||||
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 metadata, stored as manifests, describes all of the bundle
|
||||
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 swupd. Refer to
|
||||
:ref:`swupd <swupd-guide>` for additional information regarding updates and
|
||||
@@ -52,9 +52,9 @@ Prerequisites
|
||||
Add the mixer tool with the :command:`mixer` bundle. Refer to
|
||||
`Install a bundle`_ for more details.
|
||||
|
||||
* Docker container
|
||||
* Docker\* container
|
||||
|
||||
mixer by default runs all build commands in a Docker container to make sure
|
||||
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
|
||||
@@ -67,8 +67,8 @@ Prerequisites
|
||||
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 if you are behind a corporate proxy for the correct
|
||||
values.
|
||||
Consult your IT department for the correct values if you are behind a
|
||||
corporate proxy.
|
||||
|
||||
Refer to `Configure Docker proxy info`_ for instruction.
|
||||
|
||||
@@ -85,23 +85,23 @@ Mix setup
|
||||
==========
|
||||
|
||||
Follow these steps to create and initialize the mixer workspace. Complete
|
||||
setup before you create a mix.
|
||||
the setup before you create a mix.
|
||||
|
||||
#. Create workspace.
|
||||
|
||||
The mixer tool uses a simple workspace to contain all input and output in a
|
||||
basic directory structure. The workspace is simply an empty folder that you
|
||||
will execute the mixer commands from. Each mix will use its own separate
|
||||
basic directory structure. The workspace is simply an empty folder from
|
||||
which you execute the mixer commands. Each mix uses its own separate
|
||||
workspace.
|
||||
|
||||
#. Initialize the workspace and mix.
|
||||
|
||||
Before you create a mix, you must explicitly initialize the mixer workspace.
|
||||
During initialization, the mixer workspace is configured and the base for
|
||||
your mix is defined. By default, your mix will be based on the latest
|
||||
upstream version and start with the minimum set of bundles. Your first custom
|
||||
mix version number will start at 10. You can alternately select other
|
||||
versions or bundle sets to start from.
|
||||
your mix is defined. By default, your mix is based on the latest
|
||||
upstream version and starts with the minimum set of bundles. Your first custom
|
||||
mix version number starts at 10. Alternatively, you can select other
|
||||
versions or bundle sets from which to start.
|
||||
|
||||
Initialization creates the directory structure within the workspace and adds
|
||||
the :file:`builder.conf` file, which is used to configure the mixer tool.
|
||||
@@ -109,7 +109,7 @@ setup before you create a mix.
|
||||
View the `mixer.init man page`_ for more information on mixer
|
||||
initialization.
|
||||
|
||||
View the list of `suitable versions`_ to mix from.
|
||||
View the list of `suitable versions`_ from which to mix.
|
||||
|
||||
#. Edit builder.conf.
|
||||
|
||||
@@ -129,7 +129,7 @@ A mix is created with the following steps:
|
||||
|
||||
#. Add custom RPMs and set up local repo (optional).
|
||||
|
||||
If you are adding custom RPMs to your mix, you will need to add the RPMs to
|
||||
If you are adding custom RPMs to your mix, you must add the RPMs to
|
||||
your mix workspace and set up a corresponding local repository.
|
||||
|
||||
Go to the :ref:`autospec<autospec>` guide to learn to build RPMs from
|
||||
@@ -143,7 +143,7 @@ A mix is created with the following steps:
|
||||
#. Update and build bundles.
|
||||
|
||||
Add, edit, or remove bundles that will be part of your content and build
|
||||
them. mixer will automatically update the :file:`mixbundles` file when you
|
||||
them. mixer automatically updates the :file:`mixbundles` file when you
|
||||
update the bundles in your mix.
|
||||
|
||||
View the `mixer.bundle man page`_ for more information on configuring bundles
|
||||
@@ -161,17 +161,17 @@ A mix is created with the following steps:
|
||||
(for all builds after version 0).
|
||||
|
||||
A zero-pack is the full set of content needed to go from mix version 0
|
||||
(nothing) to the mix version you just built content for.
|
||||
(nothing) to the mix version for which you just built content.
|
||||
|
||||
A delta-pack provides the content *delta* between a `PAST_VERSION` to a
|
||||
`MIX_VERSION` which allows the transition from one mix version to another.
|
||||
`MIX_VERSION` that allows the transition from one mix version to another.
|
||||
|
||||
View :ref:`swupd-guide` for more information on update content.
|
||||
|
||||
#. Create image.
|
||||
|
||||
mixer creates a bootable image from your updated content using
|
||||
the ister 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.
|
||||
|
||||
@@ -185,7 +185,7 @@ A mix is created with the following steps:
|
||||
Maintain or modify mix
|
||||
======================
|
||||
|
||||
Update or modify your content to a new version by following the same steps to
|
||||
Update or modify your content to a new version by following the steps to
|
||||
create a mix. Increment the mix version number for the next mix.
|
||||
|
||||
Examples
|
||||
@@ -196,7 +196,7 @@ use:
|
||||
|
||||
* A stock installation of |CL|.
|
||||
* A web server that comes with |CL| to host the content updates.
|
||||
* A simple VM that will update against the locally produced content created in
|
||||
* A simple VM that updates against the locally produced content created in
|
||||
Example 2.
|
||||
|
||||
Complete all `Prerequisites`_ before using these examples.
|
||||
@@ -204,7 +204,8 @@ Complete all `Prerequisites`_ before using these examples.
|
||||
Example 1: Mix set up
|
||||
======================
|
||||
|
||||
This example shows the basic steps for first time setup of mixer for a new mix.
|
||||
This example shows the basic steps for the first-time setup of
|
||||
mixer for a new mix.
|
||||
|
||||
#. Create an empty directory to use as a workspace for mixer:
|
||||
|
||||
@@ -213,18 +214,17 @@ This example shows the basic steps for first time setup of mixer for a new mix.
|
||||
mkdir ~/mixer
|
||||
|
||||
#. In your mixer workspace, generate an initial mix based on the latest upstream
|
||||
|CL| version, with minimum bundles:
|
||||
|CL| version, with minimum bundles. In the initialization output, be aware
|
||||
that your initial mix version is set to 10 and that the minimum bundles have
|
||||
been added.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
cd ~/mixer
|
||||
mixer init
|
||||
|
||||
Note in the initialization output, that your initial mix version is set to
|
||||
10 and that the minimum bundles have been added.
|
||||
|
||||
#. Edit :file:`builder.conf` to set the value of CONTENTURL and VERSIONURL to
|
||||
the IP address of the nginx server you set up in the prerequisite
|
||||
the IP address of the nginx\* server you set up in the prerequisite
|
||||
`Set up a nginx web server for mixer`_. For example:
|
||||
|
||||
.. code-block:: console
|
||||
@@ -238,11 +238,11 @@ Example 2: Create a simple mix
|
||||
==============================
|
||||
|
||||
This example shows how to create a simple custom mix using upstream content.
|
||||
We'll create an image for a QEMU virtual machine which we can later use to test
|
||||
We'll create an image for a QEMU virtual machine that we can use later to test
|
||||
our mix.
|
||||
|
||||
We can use the default bundles that were added during intialization, but these
|
||||
include the :command:`native-kernel` bundle which is intended to be used on a
|
||||
We can use the default bundles that were added during initialization, but 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.
|
||||
|
||||
@@ -327,13 +327,13 @@ set to get a smaller kernel image, which will also be faster to load.
|
||||
mixer build bundles
|
||||
mixer build update
|
||||
|
||||
And build optional delta-packs, which will help reduce client update time:
|
||||
Build optional delta-packs, which helps reduce client update time:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
mixer build delta-packs --from 10 --to 20
|
||||
|
||||
Refresh your \http://localhost site and now you can see the update content for
|
||||
Refresh your \http://localhost site to see the update content for
|
||||
mix version 20.
|
||||
|
||||
Look in ~/mixer/update/www/<mix version> to see the update content in your
|
||||
@@ -344,7 +344,7 @@ Example 3: Deploy updates to target
|
||||
|
||||
The image created in Example 2 is directly bootable in QEMU. In this example,
|
||||
we'll boot the image from Example 2 to verify it, and update the image from mix
|
||||
version 10 (which the image was built from), to mix version 20.
|
||||
version 10 (from which the image was built), to mix version 20.
|
||||
|
||||
#. Set up the QEMU environment.
|
||||
|
||||
@@ -381,8 +381,10 @@ version 10 (which the image was built from), to mix version 20.
|
||||
swupd bundle-list
|
||||
swupd bundle-list -a
|
||||
|
||||
Note that you cannot see the curl bundle that you added in Example 2 because
|
||||
your mix is still on version 10.
|
||||
.. note::
|
||||
|
||||
You cannot see the curl bundle that you added in Example 2 because
|
||||
your mix is still on version 10.
|
||||
|
||||
Check for updates. You should see that version 20 is available. Use swupd to
|
||||
update your mix:
|
||||
@@ -394,7 +396,7 @@ version 10 (which the image was built from), to mix version 20.
|
||||
swupd bundle-list -a
|
||||
|
||||
Now your mix should be at version 20 and curl is now available. Try using
|
||||
curl. This will fail as curl is not yet installed:
|
||||
curl. This will fail because curl is not yet installed:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
@@ -408,7 +410,7 @@ version 10 (which the image was built from), to mix version 20.
|
||||
swupd bundle-add curl
|
||||
curl -O https://download.clearlinux.org/image/start_qemu.sh
|
||||
|
||||
And shutdown your VM:
|
||||
Shutdown your VM:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
@@ -478,11 +480,11 @@ Additional explanation of variables in :file:`builder.conf` is provided in Table
|
||||
| | :file:`Manifest.MoM` file to provide security for the |
|
||||
| | updated content you create. |
|
||||
| | |
|
||||
| | The chroot-builder uses the certificate file to sign |
|
||||
| | the root :file:`Manifest.MoM` file, to provide |
|
||||
| | chroot-builder uses the certificate file to sign |
|
||||
| | the root :file:`Manifest.MoM` file to provide |
|
||||
| | security for content verification. |
|
||||
| | |
|
||||
| | The swupd uses this certificate to verify the |
|
||||
| | swupd uses this certificate to verify the |
|
||||
| | :file:`Manifest.MoM` file's signature. |
|
||||
| | |
|
||||
| | For now, we strongly recommend that you do not modify |
|
||||
@@ -496,8 +498,8 @@ Additional explanation of variables in :file:`builder.conf` is provided in Table
|
||||
| | VERSIONURL is the IP address where the swupd client |
|
||||
| | looks to determine if a new version is available. |
|
||||
| | |
|
||||
| | CONTENTURL is the location where swupd will pull content |
|
||||
| | updates from. |
|
||||
| | 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 |
|
||||
@@ -506,16 +508,16 @@ Additional explanation of variables in :file:`builder.conf` is provided in Table
|
||||
| | |
|
||||
| | These URLs are embedded in the images created by mixer. |
|
||||
+-------------------------------+----------------------------------------------------------+
|
||||
| `DOCKER_IMAGE_PATH` | Sets the base name of the docker image mixer will pull |
|
||||
| | down in order to run builds in the proper container. |
|
||||
| `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 |
|
||||
| | edited versions of upstream bundles. |
|
||||
+-------------------------------+----------------------------------------------------------+
|
||||
| `SERVER_STATE_DIR` | Sets the path for where mixer outputs content. By |
|
||||
| | default, mixer will automatically set the path. |
|
||||
| `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 |
|
||||
@@ -541,8 +543,8 @@ variable in the :file:`mixer.state` file. Variables in the :file:`mixer.state`
|
||||
are used by mixer between executions and should not be manually changed.
|
||||
|
||||
If `Format` increments to a new epoch (a "format bump"), the OS has changed in
|
||||
such a way that updating from build M in format X, to build N in format Y will
|
||||
not work. Generally, this scenario occurs when the software updater/the software
|
||||
such a way that updating from build M in format X to build N in format Y will
|
||||
not work. Generally, this scenario occurs when the software updater or the software
|
||||
has a change such that it is no longer compatible with the previous update
|
||||
scheme, or when a package is removed from the update stream and the update
|
||||
must ensure the files associated with that package are removed from the system.
|
||||
@@ -550,7 +552,7 @@ must ensure the files associated with that package are removed from the system.
|
||||
Using a format increment, we make sure pre- and co-requisite changes flow out
|
||||
with proper ordering. The updated client will only update to the latest
|
||||
release in its respective format version, unless overridden by command line
|
||||
flags. This way we can guarantee that all clients update to the final version
|
||||
flags. In this way, we can guarantee that all clients update to the final version
|
||||
in their given format.
|
||||
|
||||
The given format *must* contain all the changes needed to understand the content
|
||||
@@ -558,7 +560,7 @@ built in the next format. Only after reaching the final release in the old
|
||||
format can a client continue to update to releases in the new format.
|
||||
|
||||
The format version is incremented only when a compatibility breakage is
|
||||
introduced. Normal updates, like updating a software package, do not require a
|
||||
introduced. Normal updates, such as updating a software package, do not require a
|
||||
format increment.
|
||||
|
||||
.. rst-class:: content-collapse
|
||||
@@ -567,16 +569,16 @@ Bundles
|
||||
=======
|
||||
|
||||
mixer stores information about the bundles included in a mix in a flat file
|
||||
called :file:`mixbundles`, located in the path set by the VERSIONS_PATH
|
||||
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 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 explicitley added.
|
||||
bundle in one of the bundles you explicitly added.
|
||||
|
||||
A bundle will fill into one of two categoris: upstream or local. Upstream
|
||||
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.
|
||||
|
||||
@@ -609,7 +611,7 @@ upstream bundles locally, and edit into a local variation.
|
||||
Bundle configuration
|
||||
--------------------
|
||||
|
||||
mixer provides commands to configure the bundles for a mix, for example to add a
|
||||
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.
|
||||
@@ -617,14 +619,16 @@ 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.
|
||||
|
||||
A note on removing bundles from a mix: By default, removing a bundle will only
|
||||
remove the bundle from the mix. The local bundle defintion file will still
|
||||
remain. To completely remove a bundle, including its local bundle definition
|
||||
file, use the :command:`--local` flag.
|
||||
.. note::
|
||||
|
||||
If you remove the bundle definition file for a local, edited version of an
|
||||
upstream bundle in a mix, the mix will revert to reference the original upstream
|
||||
version of the bundle.
|
||||
Removing bundles from a mix: By default, removing a bundle will only
|
||||
remove the bundle from the mix. The local bundle definition file will still
|
||||
remain. To completely remove a bundle, including its local bundle definition
|
||||
file, use the :command:`--local` flag.
|
||||
|
||||
If you remove the bundle definition file for a local, edited version of an
|
||||
upstream bundle in a mix, the mix reverts to reference the original upstream
|
||||
version of the bundle.
|
||||
|
||||
.. rst-class:: content-collapse
|
||||
|
||||
@@ -651,7 +655,7 @@ Use these steps to enable Docker for the mixer tool. Make sure to
|
||||
Pull Docker container manually (optional)
|
||||
-----------------------------------------
|
||||
|
||||
By default, mixer will automatically pull a Docker container for mixing if one
|
||||
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.
|
||||
|
||||
@@ -686,15 +690,13 @@ Configure Docker proxy info
|
||||
|
||||
If needed, use these steps to configure the Docker proxy information.
|
||||
|
||||
Configure the Docker daemon proxies:
|
||||
|
||||
#. 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
|
||||
#. Create :file:`/etc/systemd/system/docker.service.d/http-proxy.conf` and
|
||||
add the following using your own proxy values:
|
||||
|
||||
.. code-block:: console
|
||||
@@ -709,8 +711,8 @@ Configure the Docker daemon proxies:
|
||||
|
||||
sudo systemctl daemon-reload
|
||||
|
||||
Configure the Docker container proxies, in order to pass proxy
|
||||
settings to containers:
|
||||
Configure the Docker container proxies, to pass proxy settings to
|
||||
containers:
|
||||
|
||||
#. Create a directory for your container config:
|
||||
|
||||
@@ -741,8 +743,8 @@ settings to containers:
|
||||
sudo chown "$USER":"$USER" /home/"$USER"/.docker -R
|
||||
sudo chmod g+rwx "$HOME/.docker" -R
|
||||
|
||||
Lastly, configure proxies to allow mixer to access upstream content from behind
|
||||
a firewall. For example:
|
||||
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:
|
||||
|
||||
@@ -95,11 +95,16 @@ Version compatibility
|
||||
|
||||
We validated these steps against the following software package versions:
|
||||
|
||||
* |CL| 26240 (Lower version not supported)
|
||||
* |CL| 26240 (Minimum supported version)
|
||||
* Docker 18.06.1
|
||||
* Kubernetes 1.11.3
|
||||
* Go 1.11.12
|
||||
|
||||
|
||||
.. note::
|
||||
|
||||
The Deep Learning Reference Stack was developed to provide the best user experience when executed on a |CL| host. However, as the stack runs in a container environment, you should be able to complete the following sections of this tutorial on other Linux* distributions, provided they comply with the Docker*, Kubernetes* and Go* package versions listed above. Look for your distribution documentation on how to update packages and manage Docker services.
|
||||
|
||||
TensorFlow single and multi-node benchmarks
|
||||
*******************************************
|
||||
|
||||
@@ -448,6 +453,79 @@ You can continue working in this notebook, or you can download existing
|
||||
notebooks to take advantage of the Deep Learning Reference Stack's optimized
|
||||
deep learning frameworks. Refer to `Jupyter Notebook`_ for details.
|
||||
|
||||
Uninstallation
|
||||
**************
|
||||
|
||||
To uninstall the Deep Learning Reference Stack, you can choose to stop the container so that it is not using system resources, or you can stop the container and delete it to free storage space.
|
||||
|
||||
To stop the container, execute the following from your host system:
|
||||
|
||||
#. Find the container's ID
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
docker container ls
|
||||
|
||||
This will result in output similar to the following:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
CONTAINER ID IMAGE COMMAND CREATED STATUS PORTS NAMES
|
||||
e131dc71d339 clearlinux/stacks-dlrs-oss "/bin/sh -c 'bash'" 23 seconds ago Up 21 seconds oss
|
||||
|
||||
#. You can then use the ID or container name to stop the container. This example uses the name "oss":
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
docker container stop oss
|
||||
|
||||
|
||||
#. Verify that the container is not running
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
docker container ls
|
||||
|
||||
|
||||
#. To delete the container from your system you need to know the Image ID:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
docker images
|
||||
|
||||
This command results in output similar to the following:
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
REPOSITORY TAG IMAGE ID CREATED SIZE
|
||||
clearlinux/stacks-dlrs-oss latest 82757ec1648a 4 weeks ago 3.43GB
|
||||
clearlinux/stacks-dlrs-mkl latest 61c178102228 4 weeks ago 2.76GB
|
||||
|
||||
#. To remove an image use the image ID:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
docker rmi 82757ec1648a
|
||||
|
||||
.. code-block:: console
|
||||
|
||||
# docker rmi 827
|
||||
Untagged: clearlinux/stacks-dlrs-oss:latest
|
||||
Untagged: clearlinux/stacks-dlrs-oss@sha256:381f4b604537b2cb7fb5b583a8a847a50c4ed776f8e677e2354932eb82f18898
|
||||
Deleted: sha256:82757ec1648a906c504e50e43df74ad5fc333deee043dbfe6559c86908fac15e
|
||||
Deleted: sha256:e47ecc039d48409b1c62e5ba874921d7f640243a4c3115bb41b3e1009ecb48e4
|
||||
Deleted: sha256:50c212235d3c33a3c035e586ff14359d03895c7bc701bb5dfd62dbe0e91fb486
|
||||
|
||||
|
||||
Note that you can execute the :command:`docker rmi` command using only the first few characters of the image ID, provided they are unique on the system.
|
||||
|
||||
#. Once you have removed the image, you can verify it has been deleted with:
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
docker images
|
||||
|
||||
|
||||
Related topics
|
||||
**************
|
||||
|
||||
|
||||
+23
-22
@@ -1,17 +1,18 @@
|
||||
.. _nvidia:
|
||||
|
||||
Install NVIDIA Drivers
|
||||
######################
|
||||
Install NVIDIA\* Drivers
|
||||
########################
|
||||
|
||||
NVIDIA is a manufacture of graphics processing units (GPU), also known as
|
||||
NVIDIA manufactures graphics processing units (GPU), also known as
|
||||
graphics cards.
|
||||
|
||||
NVIDIA devices on Linux have two popular device driver options: the opensource
|
||||
drivers from the `nouveau project`_ or the proprietary drivers published by
|
||||
NVIDIA. The nouveau drivers are built into the |CL-ATTR| kernel and are loaded
|
||||
automatically at system boot if a compatible card is detected.
|
||||
NVIDIA devices on Linux\* have two popular device driver options: the
|
||||
opensource drivers from the `nouveau project`_ or the proprietary drivers
|
||||
published by NVIDIA. The nouveau drivers are built into the |CL-ATTR|
|
||||
kernel and are loaded automatically at system boot if a compatible card
|
||||
is detected.
|
||||
|
||||
These instructions show how to use the proprietary NVIDIA drivers which
|
||||
These instructions show how to use the proprietary NVIDIA drivers, which
|
||||
require a manual installation.
|
||||
|
||||
.. warning::
|
||||
@@ -35,7 +36,7 @@ Prerequisites
|
||||
*************
|
||||
|
||||
* A |CL| system with a desktop installed
|
||||
* A NVIDIA device installed
|
||||
* An NVIDIA device installed
|
||||
|
||||
|
||||
Install DKMS
|
||||
@@ -95,7 +96,7 @@ Disable the nouveau Driver
|
||||
==========================
|
||||
|
||||
The proprietary NVIDIA driver is incompatible with the nouveau driver and
|
||||
needs to be disabled before installation can continue.
|
||||
must be disabled before installation can continue.
|
||||
|
||||
#. Disable the nouveau driver by creating a blacklist file under
|
||||
:file:`/etc/modprobe.d` and reboot.
|
||||
@@ -108,7 +109,7 @@ needs to be disabled before installation can continue.
|
||||
|
||||
|
||||
#. Reboot the system and log back in. It is normal for the graphical
|
||||
environment to not start with no NVIDIA driver loaded.
|
||||
environment not to start without the NVIDIA driver loaded.
|
||||
|
||||
|
||||
|
||||
@@ -119,11 +120,11 @@ Configure Alternative Software Paths
|
||||
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| system files under :file:`/usr`. The dynamic linker and X
|
||||
server will need to be configured to use the content under
|
||||
server must be configured to use the content under
|
||||
:file:`/opt/nvidia`.
|
||||
|
||||
|
||||
#. Configure the dynamic linker to look for and cache shared libraries under
|
||||
#. Configure the dynamic linker to look for and to cache shared libraries under
|
||||
:file:`/opt/nvidia/lib` and :file:`/opt/nvidia/lib32` in addition to the
|
||||
default paths.
|
||||
|
||||
@@ -199,7 +200,7 @@ Install the NVIDIA Drivers
|
||||
is loaded. Return to the working terminal and log back in if necessary.
|
||||
|
||||
|
||||
#. Validate the nvidia kernel modules are loaded.
|
||||
#. Confirm that the NVIDIA kernel modules are loaded.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
@@ -233,10 +234,10 @@ 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.
|
||||
#. Follow the steps in the `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
|
||||
#. Temporarily set the default boot target to the *multi-user*, which is
|
||||
a non-graphical runtime.
|
||||
|
||||
.. code-block:: bash
|
||||
@@ -245,9 +246,9 @@ not in use.
|
||||
|
||||
|
||||
#. Reboot the system and log back in. It is normal for the graphical
|
||||
environment to not start.
|
||||
environment not to start.
|
||||
|
||||
#. Follow the steps in `Install the NVIDIA Drivers`_ section to update
|
||||
#. Follow the steps in the `Install the NVIDIA Drivers`_ section to update
|
||||
the NVIDIA drivers. This installation will overwrite the previous NVIDIA
|
||||
drivers and files.
|
||||
|
||||
@@ -261,7 +262,7 @@ not in use.
|
||||
#. 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.
|
||||
with the new NVIDIA drivers for the flatpak apps that require it.
|
||||
|
||||
.. code-block:: bash
|
||||
|
||||
@@ -272,7 +273,7 @@ Uninstalling the NVIDIA Drivers
|
||||
*******************************
|
||||
|
||||
The NVIDIA drivers and associated software can be uninstalled and nouveau
|
||||
driver restored by:
|
||||
driver restored with the instructions in this section.
|
||||
|
||||
#. Remove the :file:`modprobe.d` file that prevents nouveau from loading.
|
||||
|
||||
@@ -281,7 +282,7 @@ driver restored by:
|
||||
sudo rm /etc/modprobe.d/disable-nouveau.conf
|
||||
|
||||
|
||||
#. Remove the :file`xorg.conf.d` file that adds a search path for X modules.
|
||||
#. Remove the :file:`xorg.conf.d` file that adds a search path for X modules.
|
||||
|
||||
.. code:: bash
|
||||
|
||||
|
||||
Reference in New Issue
Block a user