From ffd2474b4e42ee95132bb98e096e2139094cd68d Mon Sep 17 00:00:00 2001 From: Bob Furu Date: Fri, 5 Nov 2021 16:37:37 -0400 Subject: [PATCH] BZ2010870: Load custom firmware blobs via MC manifest --- modules/rhcos-load-firmware-blobs.adoc | 63 +++++++++++++++++++ .../machine-configuration-tasks.adoc | 8 ++- 2 files changed, 69 insertions(+), 2 deletions(-) create mode 100644 modules/rhcos-load-firmware-blobs.adoc diff --git a/modules/rhcos-load-firmware-blobs.adoc b/modules/rhcos-load-firmware-blobs.adoc new file mode 100644 index 0000000000..d4ad26f822 --- /dev/null +++ b/modules/rhcos-load-firmware-blobs.adoc @@ -0,0 +1,63 @@ +// Module included in the following assemblies: +// +// * post_installation_configuration/machine-configuration-tasks.adoc + +[id="rhcos-load-firmware-blobs_{context}"] += Loading custom firmware blobs in the machine config manifest + +Because the default location for firmware blobs in `/usr/lib` is read-only, you can locate a custom firmware blob by updating the search path. This enables you to load local firmware blobs in the machine config manifest when the blobs are not managed by {op-system}. + +.Procedure + +. Create a Butane config file, `98-worker-firmware-blob.bu`, that updates the search path so that it is root-owned and writable to local storage. The following example places the custom blob file from your local workstation onto nodes under `/var/lib/firmware`. ++ +[NOTE] +==== +See "Creating machine configs with Butane" for information about Butane. +==== +.Butane config file for custom firmware blob ++ +[source,yaml] +---- +variant: openshift +version: 4.9.0 +metadata: + labels: + machineconfiguration.openshift.io/role: worker + name: 98-worker-firmware-blob +storage: + files: + - path: /var/lib/firmware/ <1> + contents: + local: <2> + mode: 0644 <3> +openshift: + kernel_arguments: + - 'firmware_class.path=/var/lib/firmware' <4> +---- ++ +<1> Sets the path on the node where the firmware package is copied to. +<2> Specifies a file with contents that are read from a local file directory on the system running Butane. The path of the local file is relative to a `files-dir` directory, which must be specified by using the `--files-dir` option with Butane in the following step. +<3> Sets the permissions for the file on the {op-system} node. It is recommended to set `0644` permissions. +<4> The `firmware_class.path` parameter customizes the kernel search path of where to look for the custom firmware blob that was copied from your local workstation onto the root file system of the node. This example uses `/var/lib/firmware` as the customized path. + +. Run Butane to generate a `MachineConfig` object file that uses a copy of the firmware blob on your local workstation named `98-worker-firmware-blob.yaml`. The firmware blob contains the configuration to be delivered to the nodes. The following example uses the `--files-dir` option to specify the directory on your workstation where the local file or files are located: ++ +[source,terminal] +---- +$ butane 98-worker-firmware-blob.bu -o 98-worker-firmware-blob.yaml --files-dir +---- +. Apply the configurations to the nodes in one of two ways: ++ +* If the cluster is not running yet, after you generate manifest files, add the `MachineConfig` object file to the `/openshift` directory, and then continue to create the cluster. ++ +* If the cluster is already running, apply the file: ++ +[source,terminal] +---- +$ oc apply -f 98-worker-firmware-blob.yaml +---- ++ +A `MachineConfig` object YAML file is created for you to finish configuring your machines. ++ +. Save the Butane config in case you need to update the `MachineConfig` object in the future. diff --git a/post_installation_configuration/machine-configuration-tasks.adoc b/post_installation_configuration/machine-configuration-tasks.adoc index 91ce358b91..3a33ce601f 100644 --- a/post_installation_configuration/machine-configuration-tasks.adoc +++ b/post_installation_configuration/machine-configuration-tasks.adoc @@ -29,6 +29,11 @@ link:https://access.redhat.com/solutions/4510281[updating] SSH authorized keys, There might be situations where the configuration on a node does not fully match what the currently-applied machine config specifies. This state is called _configuration drift_. The Machine Config Daemon (MCD) regularly checks the nodes for configuration drift. If the MCD detects configuration drift, the MCO marks the node `degraded` until an administrator corrects the node configuration. A degraded node is online and operational, but, it cannot be updated. For more information on configuration drift, see xref:../post_installation_configuration/machine-configuration-tasks.adoc#machine-config-drift-detection_post-install-machine-configuration-tasks[Understanding configuration drift detection]. +[TIP] +==== +Use the following "Configuring chrony time service" procedure as a model for how to go about adding other configuration files to {product-title} nodes. +==== + include::modules/installation-special-config-chrony.adoc[leveloffset=+2] include::modules/cnf-disable-chronyd.adoc[leveloffset=+2] include::modules/nodes-nodes-kernel-arguments.adoc[leveloffset=+2] @@ -42,8 +47,7 @@ include::modules/nodes-nodes-cgroups-2.adoc[leveloffset=+2] include::modules/nodes-nodes-rtkernel-arguments.adoc[leveloffset=+2] include::modules/machineconfig-modify-journald.adoc[leveloffset=+2] include::modules/rhcos-add-extensions.adoc[leveloffset=+2] - -Use the "Configuring chrony time service" section as a model for how to go about adding other configuration files to {product-title} nodes. +include::modules/rhcos-load-firmware-blobs.adoc[leveloffset=+2] [id="configuring-machines-with-custom-resources"] == Configuring MCO-related custom resources