diff --git a/installing/installing_bare_metal/installing-bare-metal-network-customizations.adoc b/installing/installing_bare_metal/installing-bare-metal-network-customizations.adoc index 84e4cef22d8f..b1114e42d21e 100644 --- a/installing/installing_bare_metal/installing-bare-metal-network-customizations.adoc +++ b/installing/installing_bare_metal/installing-bare-metal-network-customizations.adoc @@ -56,8 +56,8 @@ include::modules/installation-generate-ignition-configs.adoc[leveloffset=+1] == Creating {op-system-first} machines Before you install a cluster on bare metal infrastructure that you provision, -you must create {op-system} machines for it to use. Follow either the steps -to use an ISO image or network PXE booting to create the machines. +you must create {op-system} machines for it to use. To create the machines, follow either the steps +to use an ISO image or network PXE booting. There are several methods of configuring {op-system} during ISO and PXE installations. These include: @@ -65,27 +65,24 @@ PXE installations. These include: * Kernel arguments: For a PXE install, you can `APPEND` arguments to the kernel of the live installer. For an ISO install, you can interrupt the live install boot process to add kernel arguments. In both cases, you can use -special `coreos-inst*` arguments to direct the installer, as well as +special `coreos.inst.*` arguments to direct the installer, as well as standard boot arguments for turning standard kernel services on or off. -* Ignition configs: You need to generate an {product-title} Ignition config -(*.ign) file for the type of node you are installing (worker, control plane, +* Ignition configs: You need to generate an {product-title} Ignition config file +(`*.ign`) for the type of node you are installing (worker, control plane, or bootstrap). You pass the location of the Ignition config to the installed -system so that it takes effect on first boot. You can also embed that Ignition -Config into the ISO before you boot it. In special cases, you can create a -separate, limited Ignition config to pass to the live system. That limited -Ignition config could do a limited -set of tasks, like reporting reporting success to a provisioning system -after completing installation. -This special Ignition config is consumed by the installer and should not +system so that it takes effect on first boot. In special cases, you can create a +separate, limited Ignition config to pass to the live system. That Ignition config could do a certain set of tasks, such as reporting success to a provisioning system +after completing installation. This special Ignition config is consumed by the installer and should not be used to include the standard `worker` and `master` Ignition configs. -* coreos-installer: You can boot the live ISO installer to a shell prompt, +* `coreos-installer`: You can boot the live ISO installer to a shell prompt, which allows you to prepare the permanent system in a variety of ways -before first boot. In particular, you can manually run the `coreos-installer` -command from a shell prompt, passing it options to configure -some details of the installed system. +before first boot. In particular, you can run the `coreos-installer` +command to identify various artifacts to include, work with disk partitions, +and set up networking. In some cases, you can configure features on +the live system and copy them to the installed system. Whether to use an ISO or PXE install depends on your situation. A PXE install requires an available DHCP service and more preparation, diff --git a/installing/installing_bare_metal/installing-bare-metal.adoc b/installing/installing_bare_metal/installing-bare-metal.adoc index 3e21ff4eebe3..4e9c723aa9ee 100644 --- a/installing/installing_bare_metal/installing-bare-metal.adoc +++ b/installing/installing_bare_metal/installing-bare-metal.adoc @@ -60,8 +60,8 @@ include::modules/installation-user-infra-generate-k8s-manifest-ignition.adoc[lev == Creating {op-system-first} machines Before you install a cluster on bare metal infrastructure that you provision, -you must create {op-system} machines for it to use. Follow either the steps -to use an ISO image or network PXE booting to create the machines. +you must create {op-system} machines for it to use. To create the machines, follow either the steps +to use an ISO image or network PXE booting. There are several methods of configuring {op-system} during ISO and PXE installations. These include: @@ -69,19 +69,19 @@ PXE installations. These include: * Kernel arguments: For a PXE install, you can `APPEND` arguments to the kernel of the live installer. For an ISO install, you can interrupt the live install boot process to add kernel arguments. In both cases, you can use -`special coreos-inst*` arguments, to direct the live installer, as well as -standard installation boot arguments, for turning standard kernel services +special `coreos.inst.*` arguments to direct the live installer, as well as +standard installation boot arguments for turning standard kernel services on or off. -* Ignition configs: You need to generate an {product-title} Ignition config -(*.ign) file for the type of node you are installing (worker, control plane, +* Ignition configs: You need to generate an {product-title} Ignition config file +(`*.ign`) for the type of node you are installing (worker, control plane, or bootstrap). You pass the location of the Ignition config to the installed -system, so it takes effect on first boot. You can also embed that Ignition -Config into the ISO before you boot it. In special cases, you can create a -separate Ignition config to pass to the live system, to do things like disk -configuration before installing the system. +system so that it takes effect on first boot. In special cases, you can create a +separate, limited Ignition config to pass to the live system. That Ignition config could do a certain set of tasks, such as reporting success to a provisioning system +after completing installation. This special Ignition config is consumed by the installer and should not +be used to include the standard `worker` and `master` Ignition configs. -* coreos-installer: You can boot the live ISO installer to a shell prompt, +* `coreos-installer`: You can boot the live ISO installer to a shell prompt, which allows you to prepare the permanent system in a variety of ways before first boot. In particular, you can run the `coreos-installer` command to identify various artifacts to include, work with disk partitions, @@ -97,7 +97,7 @@ up more than a few machines. [NOTE] ==== As of {product-title} 4.6, the {op-system} ISO and other installation artifacts -provide support for installation on disks with 4k sectors. +provide support for installation on disks with 4K sectors. ==== diff --git a/installing/installing_bare_metal/installing-restricted-networks-bare-metal.adoc b/installing/installing_bare_metal/installing-restricted-networks-bare-metal.adoc index 7bed568cb2f8..fe9b08da2c77 100644 --- a/installing/installing_bare_metal/installing-restricted-networks-bare-metal.adoc +++ b/installing/installing_bare_metal/installing-restricted-networks-bare-metal.adoc @@ -73,8 +73,8 @@ include::modules/installation-user-infra-generate-k8s-manifest-ignition.adoc[lev == Creating {op-system-first} machines Before you install a cluster on bare metal infrastructure that you provision, -you must create {op-system} machines for it to use. Follow either the steps -to use an ISO image or network PXE booting to create the machines. +you must create {op-system} machines for it to use. To create the machines, follow either the steps +to use an ISO image or network PXE booting. There are several methods of configuring {op-system} during ISO and PXE installations. These include: @@ -82,19 +82,19 @@ PXE installations. These include: * Kernel arguments: For a PXE install, you can `APPEND` arguments to the kernel of the live installer. For an ISO install, you can interrupt the live install boot process to add kernel arguments. In both cases, you can use -`special coreos-inst*` arguments, to direct the live installer, as well as -standard installation boot arguments, for turning standard kernel services +special `coreos.inst.*` arguments to direct the live installer, as well as +standard installation boot arguments for turning standard kernel services on or off. -* Ignition configs: You need to generate an {product-title} Ignition config -(*.ign) file for the type of node you are installing (worker, control plane, +* Ignition configs: You need to generate an {product-title} Ignition config file +(`*.ign`) for the type of node you are installing (worker, control plane, or bootstrap). You pass the location of the Ignition config to the installed -system, so it takes effect on first boot. You can also embed that Ignition -Config into the ISO before you boot it. In special cases, you can create a -separate Ignition config to pass to the live system, to do things like disk -configuration before installing the system. +system so that it takes effect on first boot. In special cases, you can create a +separate, limited Ignition config to pass to the live system. That Ignition config could do a certain set of tasks, such as reporting success to a provisioning system +after completing installation. This special Ignition config is consumed by the installer and should not +be used to include the standard `worker` and `master` Ignition configs. -* coreos-installer: You can boot the live ISO installer to a shell prompt, +* `coreos-installer`: You can boot the live ISO installer to a shell prompt, which allows you to prepare the permanent system in a variety of ways before first boot. In particular, you can run the `coreos-installer` command to identify various artifacts to include, work with disk partitions, diff --git a/modules/installation-user-infra-machines-advanced.adoc b/modules/installation-user-infra-machines-advanced.adoc index 337191333b12..5954bf0f4806 100644 --- a/modules/installation-user-infra-machines-advanced.adoc +++ b/modules/installation-user-infra-machines-advanced.adoc @@ -10,39 +10,40 @@ A key reason for doing a bare metal installation of {op-system-first} nodes for {product-title} is to be able to do configuration that is not available through default {product-title} installation methods. -This section describes some of the configurations you can do using +This section describes some of the configurations that you can do using techniques that include: * Passing kernel arguments to the live installer -* Running the coreos-installer during a live installation +* Running `coreos-installer` manually from the live system * Embedding Ignition configs in an ISO -The most useful advanced configuration topics for bare metal {op-system-first} -installations relate to disk partitioning, networking, and using Ignition configs in different ways. +The advanced configuration topics for bare metal {op-system-first} +installations detailed in this section relate to disk partitioning, networking, and using Ignition configs in different ways. [id="installation-user-infra-machines-advanced_network_{context}"] -== Networking +== Using advanced networking options for PXE and ISO installations Networking for {product-title} nodes uses DHCP by default to gather all -necessary configuration settings. If you want to set up static IP addresses -or configure special settings, such as bonding, you can do that by either: +necessary configuration settings. To set up static IP addresses or configure special settings, such as bonding, you can do one of the following: -* Passing special kernel parameters when you boot the live installer, -* Using MachineConfigs to copy networking files to the installed system, or -* Configuring networking from a live installer shell prompt, then copying -those settings to the installed system so they take effect when the -installed system first boots. +* Pass special kernel parameters when you boot the live installer. -For a PXE or iPXE installation, see the `Configure advanced networking` table for network-related kernel arguments to APPEND to the kernel or use MachineConfigs to copy networking files to the installed system. +* Use a MachineConfig to copy networking files to the installed system. -For an ISO installation, do the following: +* Configure networking from a live installer shell prompt, then copy those settings to the installed system so that they take effect when the installed system first boots. + +To configure a PXE or iPXE installation, use one of the following options: + +* See the "Advanced RHCOS installation reference" tables. +* Use a MachineConfig to copy networking files to the installed system. + +To configure an ISO installation, use the following procedure. .Procedure . Boot the ISO installer. . From the live system shell prompt, configure networking for the live system using available RHEL tools, such as `nmcli` or `nmtui`. -. Include the `--copy-network option` with the options when you run the -`coreos-installer` command. For example: +. Run the `coreos-installer` command to install the system, adding the `--copy-network` option to copy networking configuration. For example: + [source,terminal] ---- @@ -50,26 +51,22 @@ $ coreos-installer install --copy-network \ --ignition-url=http://host/worker.ign /dev/sda ---- -. Once the installer is done, boot up to the system you installed to disk, which will include the new network settings. +. Reboot into the installed system. [id="installation-user-infra-machines-advanced_disk_{context}"] == Disk partitioning In most cases, the {product-title} installer should be allowed to configure -your disk partitions. However, here are two cases where you might want to +your disk partitions. However, there are two cases where you might want to intervene to override the default partitioning when installing an {product-title} node: -* Creating separate partitions: For greenfield installations on an empty -disk, you may want to add separate storage to a partition. This is only +* Create separate partitions: For greenfield installations on an empty +disk, you might want to add separate storage to a partition. This is only officially supported for making `/var` or a subdirectory of `/var` a separate -partition (not both). If you create more than one partition, Kubernetes +partition, but not both. If you create more than one partition, Kubernetes will not be able to monitor them both. -* Retaining existing partitions: For a brownfield installation, where you -are reinstalling on an existing {product-title} node, or a greenfield -installation where you just want to partition a disk manually before -starting the installation, there are both boot arguments and options to -`coreos-installer` that let you retain existing data partitions. +* Retain existing partitions: For a brownfield installation, where you are reinstalling on an existing {product-title} node and want to retain data partitions from your previous operating system, there are both boot arguments and options to `coreos-installer` that allow you to retain existing data partitions. [id="installation-user-infra-machines-advanced_vardisk_{context}"] === Creating a separate `/var` partition @@ -86,14 +83,10 @@ as more images and containers are added to a system. * `/var`: Holds data that you might want to keep separate for purposes such as auditing. -Storing the contents of a `/var` directory separately allows you to more easily -grow storage to those areas as needed, and to reinstall {product-title} -at a later date and keep that data intact. In other words, you would not have -to pull all your containers again or copy off massive log files when you -update your systems. +Storing the contents of a `/var` directory separately makes it easier to grow storage for those areas as needed and reinstall {product-title} at a later date and keep that data intact. With this method, you will not have to pull all your containers again, nor will you have to copy massive log files when you update systems. Because `/var` must be in place before a fresh installation of -{op-system-first}, this procedure sets up the separate `/var` partition +{op-system-first}, the following procedure sets up the separate `/var` partition by creating a MachineConfig that is inserted during the `openshift-install` preparation phases of an {product-title} installation. @@ -107,7 +100,7 @@ $ mkdir $HOME/clusterconfig ---- . Run `openshift-install` to create a set of files in the `manifest` and -`openshift` subdirectories. Answer questions as prompted: +`openshift` subdirectories. Answer the system questions as you are prompted: + [source,terminal] ---- @@ -128,7 +121,7 @@ and set the storage size as appropriate. This attaches storage to a separate `/v directory. + -[source,terminal] +[source,yaml] ---- apiVersion: machineconfiguration.openshift.io/v1 kind: MachineConfig @@ -183,122 +176,107 @@ metal installation procedures to install {op-system-first} systems. [id="installation-user-infra-machines-advanced_retaindisk_{context}"] === Retaining existing partitions -For an ISO installation, you can add options to the `coreos-installer` +For an ISO installation, you can add options to the `coreos-installer` command line that causes the installer to maintain one or more existing partitions. -For a PXE installation, you can APPEND `coreos.inst` options to preserve partitions. +For a PXE installation, you can `APPEND` `coreos.inst` options to preserve partitions. Saved partitions might be partitions from an existing {product-title} -system that has data partitions that you want to keep, or partitions -that you just manually created. Here are a few tips: +system that has data partitions that you want to keep. Here are a few tips: -* Make sure you assign at least the recommended amount of disk space to the -OpenShift partitions at the beginning of the disk. +* If you save existing partitions, and those partitions do not leave enough space for {op-system}, installation will fail without damaging the saved partitions. * Identify the disk partitions you want to keep either by partition -number or label. +label or by number. -For an ISO installation: +.For an ISO installation -The following example illustrates running `coreos-installer` in a way that preserves -the sixth (6) partition on the disk: +This example preserves any partition in which the partition label begins with `data` (`data*`): [source,terminal] ---- # coreos-installer install --ignition-url http://10.0.2.2:8080/user.ign \ - --save-partindex 6 /dev/sda + --save-partlabel 'data*' /dev/sda ---- -This example preserves partitions 5 and higher: +The following example illustrates running the `coreos-installer` in a way that preserves +the sixth (6) partition on the disk: [source,terminal] ---- -# coreos-installer install --ignition-url http://10.0.2.2:8080/user.ign - --save-partindex 5- /dev/sda +# coreos-installer install --ignition-url http://10.0.2.2:8080/user.ign \ + --save-partindex 6 /dev/sda ---- -This example preserves any partition in which the partition label begins with `data` (`data*`): +This example preserves partitions 5 and higher: [source,terminal] ---- # coreos-installer install --ignition-url http://10.0.2.2:8080/user.ign - --save-partlabel ‘data*’ /dev/sda + --save-partindex 5- /dev/sda ---- -In all of those examples, after the install completes, on the first boot of -the new system, Ignition will recreate the partition at the same place it -was before (the same offset), and the filesystem will be intact. +In the previous examples where partition saving is used, `coreos-installer` recreates the partition immediately. -For a PXE installation: +.For a PXE installation -This APPEND option preserves the sixth partition: +This `APPEND` option preserves any partition in which the partition label begins with 'data' ('data*'): [source,terminal] ---- -coreos.inst.save_part=6 +coreos.inst.save_partlabel=data* ---- -This APPEND option preserves the all partitions from 5 and higher: +This `APPEND` option preserves partitions 5 and higher: [source,terminal] ---- -coreos.inst.save_part=5- +coreos.inst.save_partindex=5- ---- -This APPEND option preserves any partition in which the partition label begins with `data` (`data*`): +This `APPEND` option preserves partition 6: [source,terminal] ---- -coreos.inst.save_partindex=’data*’ +coreos.inst.save_partindex=6 ---- [id="installation-user-infra-machines-advanced_ignition_{context}"] == Identifying Ignition configs -There are different ways to manage Ignition config files when you do -bare metal installations. To begin with, there are two different types -of Ignition configs you can provide during {op-system-first} installation and two -different reasons for providing them: - -* **Live install Ignition config**: This Ignition config should be rarely -used and is one you create manually from scratch. It is passed to the live -install medium and it is run immediately upon booting that live medium to do setup -tasks BEFORE the process that actually installs the {op-system-first} system to disk. -This should only be used for performing tasks that need to be done once and -not applied again later, such as some advanced partitioning that cannot be done using MachineConfigs. There are currently no officially supported procedures for using Ignition configs in this way. -+ -For PXE or ISO boots, you can create the Ignition config -and APPEND the `ignition.config.url=` option to identify the location of -the Ignition config. You also need to append `ignition.firstboot ignition.platform.id=metal` -or the `ignition.config.url` option will be ignored. +When doing an {op-system} bare metal installation, there are two types of Ignition configs that you can provide, with different reasons for providing each one: -* **Permanent install Ignition config**: Every bare metal {op-system-first} installation +* **Permanent install Ignition config**: Every bare metal {op-system} installation needs to pass one of the Ignition config files generated by `openshift-installer`, -including `bootstrap.ign`, `master.ign` and `worker.ign`, to the carry out the -installation. It is not recommended to modify these files. +such as `bootstrap.ign`, `master.ign` and `worker.ign`, to carry out the +installation. ++ +[IMPORTANT] +==== +It is not recommended to modify these files. +==== + -For PXE installs, you pass the Ignition configs on the APPEND line using the -`coreos.inst.ignition_url=` option. For ISO installs, after the ISO boots to +For PXE installations, you pass the Ignition configs on the `APPEND` line using the +`coreos.inst.ignition_url=` option. For ISO installations, after the ISO boots to the shell prompt, you identify the Ignition config on the `coreos-installer` command line with the `--ignition-url=` option. + -Instead of passing the location of an Ignition config via a kernel or -command-line option, you can embed an Ignition config into the ISO -installer image. This allows you to do bare metal installs with the ISO, -without requiring access to an HTTP server. See “Embedding an Ignition -config in the {op-system-first} ISO” for details. -[id="installation-user-infra-machines-advanced_embedignition_{context}"] -=== Embedding an Ignition config in the {op-system-first} ISO -The following procedures describe how to embed an Ignition config into -the ISO so it is applied when the new installation first boots from disk. +* **Live install Ignition config**: This type must be created manually and should be avoided if possible, as it is not supported by Red Hat. With this method, the Ignition config passes to the live install medium, runs immediately upon booting, and performs setup tasks before and/or after the {op-system} system installs to disk. This method should only be used for performing tasks that must be performed once and not applied again later, such as with advanced partitioning that cannot be done using a MachineConfig. ++ +For PXE or ISO boots, you can create the Ignition config +and `APPEND` the `ignition.config.url=` option to identify the location of +the Ignition config. You also need to append `ignition.firstboot ignition.platform.id=metal` +or the `ignition.config.url` option will be ignored. -To embed an Ignition config named `worker.ign` into an ISO image -(for example rhcos--live.x86_64.iso), copy the image to -a local directory, then run the coreos-installer container with -that directory mounted, as follows: +[id="installation-user-infra-machines-advanced_embedignition_{context}"] +=== Embedding an Ignition config in the {op-system} ISO +You can embed a live install Ignition config directly in an {op-system} ISO image. When +the ISO image is booted, the embedded config will be applied automatically. .Procedure -. Get the {op-system-first} ISO and Ignition config file and copy them into an accessible directory, such as `/mnt`. +. Download the `coreos-installer` binary from the following image mirror page: https://mirror.openshift.com/pub/openshift-v4/clients/coreos-installer/latest/. + +. Retrieve the {op-system} ISO image and the Ignition config file, and copy them into an accessible directory, such as `/mnt`: + [source,terminal] ---- @@ -306,36 +284,47 @@ that directory mounted, as follows: # chmod 644 /mnt/rhcos--live.x86_64.iso ---- -. Run the following command to run `coreos-installer` from a container to embed the -Ignition config into the ISO: +. Run the following command to embed the Ignition config into the ISO: + [source,terminal] ---- -# podman run -it -v /mnt:/mnt:z quay.io/coreos/coreos-installer:release \ - iso ignition embed --force -i /mnt/bootstrap.ign /mnt/rhcos.test.iso +# ./coreos-installer iso ignition embed -i /mnt/bootstrap.ign \ + /mnt/rhcos--live.x86_64.iso ---- - -You can now use that ISO to install {op-system-first} with the included Ignition config -without needing to pull the Ignition config from an HTTP server. - -To show the contents of the embedded Ignition config and direct it into a file, run: - ++ +You can now use that ISO to install {op-system} using the specified live install +Ignition config. ++ +[IMPORTANT] +==== +Using `coreos-installer iso ignition embed` to embed a file generated by `openshift-installer`, such as `bootstrap.ign`, `master.ign` and `worker.ign`, is unsupported and not recommended. +==== ++ +. To show the contents of the embedded Ignition config and direct it into a file, run: ++ +[source,terminal] +---- +# ./coreos-installer iso ignition show /mnt/rhcos--live.x86_64.iso > mybootstrap.ign +---- ++ [source,terminal] ---- -# podman run -it -v /mnt:/mnt:z quay.io/coreos/coreos-installer:release \ - iso ignition show /mnt/rhcos.test.iso > mybootstrap.ign # diff -s bootstrap.ign mybootstrap.ign +---- ++ +.Example output +[source,terminal] +---- Files bootstrap.ign and mybootstrap.ign are identical ---- -To remove the Ignition config and return the ISO to its pristine state (so -you can reuse it), run: - +. To remove the Ignition config and return the ISO to its pristine state so +you can reuse it, run: ++ [source,terminal] ---- -# podman run -it -v /mnt:/mnt:z quay.io/coreos/coreos-installer:release \ - iso ignition remove /mnt/rhcos.test.iso +# ./coreos-installer iso ignition remove /mnt/rhcos--live.x86_64.iso ---- - ++ You can now embed another Ignition config into the ISO or use the ISO in its pristine state. diff --git a/modules/installation-user-infra-machines-iso.adoc b/modules/installation-user-infra-machines-iso.adoc index 2f3861e7faf5..d7fb97b93ab4 100644 --- a/modules/installation-user-infra-machines-iso.adoc +++ b/modules/installation-user-infra-machines-iso.adoc @@ -24,16 +24,12 @@ machines. .Prerequisites * Obtain the Ignition config files for your cluster. -* Have access to an HTTP server that you can access from your computer and that -the machines that you create can access. If that is not possible, you can embed -the Ignition config you want to use into the ISO you use for installation. +* Have access to an HTTP server that can be accessed from your computer, and from the machines that you create. .Procedure . Upload the control plane, compute, and bootstrap Ignition config files that the installation program created to your HTTP server. Note the URLs of these files. -As an alternative, you could embed the Ignition config into the ISO installation -medium as described later. + [IMPORTANT] @@ -66,8 +62,8 @@ Only use ISO images for this procedure. ==== + ISO file names resemble the following example: - -`rhcos--installer..iso` ++ +`rhcos--live..iso` endif::openshift-origin[] ifdef::openshift-origin[] . Obtain the {op-system} images from the diff --git a/modules/installation-user-infra-machines-static-network.adoc b/modules/installation-user-infra-machines-static-network.adoc index b5f9dcb2ab70..3096f6991898 100644 --- a/modules/installation-user-infra-machines-static-network.adoc +++ b/modules/installation-user-infra-machines-static-network.adoc @@ -102,17 +102,7 @@ The following table shows the {op-system} live installer boot options for ISO an a|`coreos.inst.install_dev` -a|Required. The block device on the system to install to. It is recommended to use the full path, such as `/dev/sda`. - -a|`coreos.inst.image_url` - -a|Optional: Download and install the specified {op-system} image. - -* This argument should not be used in production environments and is intended for debugging purposes only. - -* While this argument can be used to install a version of {op-system} that does not match the live media, it is recommended that you instead use the image that matches the version you want to install. - -* If you are using `coreos.inst.image_url`, you must also use `coreos.inst.insecure`. This is because the bare-metal media are not GPG-signed for {product-title}. +a|Required. The block device on the system to install to. It is recommended to use the full path, such as `/dev/sda`, although `sda` is allowed. a|`coreos.inst.ignition_url` @@ -130,6 +120,16 @@ a|`coreos.inst.insecure` a|Optional: Permits the OS image that is specified by `coreos.inst.image_url` to be unsigned. +a|`coreos.inst.image_url` + +a|Optional: Download and install the specified {op-system} image. + +* This argument should not be used in production environments and is intended for debugging purposes only. + +* While this argument can be used to install a version of {op-system} that does not match the live media, it is recommended that you instead use the media that matches the version you want to install. + +* If you are using `coreos.inst.image_url`, you must also use `coreos.inst.insecure`. This is because the bare-metal media are not GPG-signed for {product-title}. + a|`coreos.inst.skip_reboot` a|Optional: The system will not reboot after installing. Once the install finishes, you will receive a prompt that allows you to inspect what is happening during installation. This argument should not be used in production environments and is intended for debugging purposes only. @@ -146,9 +146,7 @@ a|Optional: The URL of the Ignition config for the live boot. For example, this [discrete] == `coreos-installer` options for ISO install -You can run the `coreos-installer` command to identify various artifacts to include, to work with disk partitions, and to set up networking. In some cases, you can configure features on the live system and copy them to the installed system. - -This allows you to prepare the permanent system in a variety of ways before first boot. +You can also install {op-system} by invoking the `coreos-installer` command directly from the command line. The kernel arguments in the previous table provide a shortcut for automatically invoking `coreos-installer` at boot time, but you can pass similar arguments directly to `coreos-installer` when running it from a shell prompt. The following table shows the options and subcommands you can pass to the `coreos-installer` command from a shell prompt during a live install. @@ -225,13 +223,13 @@ a|The destination device. |*Command* |*Description* -a|`$ coreos-installer iso ignition embed ` +a|`$ coreos-installer iso ignition embed --ignition-file ` a|Embed an Ignition config in an ISO image. -a|`coreos-installer iso ignition show ` +a|`coreos-installer iso ignition show ` |Show the embedded Ignition config from an ISO image. -a|`coreos-installer iso ignition remove ` +a|`coreos-installer iso ignition remove ` a|Remove the embedded Ignition config from an ISO image. 2+|_coreos-installer ISO Ignition options_ @@ -254,8 +252,13 @@ a|Print help information. |*Command* |*Description* -a|`coreos-installer pxe ignition wrap ` -a|Wrap an Ignition config in an `initrd` image. +2+|Note that not all of these options are accepted by all subcommands. + +a|`coreos-installer pxe ignition wrap ` +a|Wrap an Ignition config in an image. + +a|`coreos-installer pxe ignition unwrap ` +a|Show the wrapped Ignition config in an image. a|`coreos-installer pxe ignition unwrap ` a|Show the wrapped Ignition config in an `initrd` image.