|
| 1 | +<?xml version="1.0" encoding="UTF-8"?> |
| 2 | +<!-- This file originates from the project https://github.com/openSUSE/doc-kit --> |
| 3 | +<!-- This file can be edited downstream. --> |
| 4 | +<!DOCTYPE topic |
| 5 | +[ |
| 6 | + <!ENTITY % entities SYSTEM "../common/generic-entities.ent"> |
| 7 | + %entities; |
| 8 | +]> |
| 9 | +<!-- refers to legacy doc: <add github link to legacy doc piece, if applicable> --> |
| 10 | +<!-- point back to this document with a similar comment added to your legacy doc piece --> |
| 11 | +<!-- refer to README.md for file and id naming conventions --> |
| 12 | +<!-- metadata is dealt with on the assembly level --> |
| 13 | +<topic xml:id="reference-sle16-upgrade-distribution-migration-system" |
| 14 | + role="reference" xml:lang="en" |
| 15 | + xmlns="http://docbook.org/ns/docbook" version="5.2" |
| 16 | + xmlns:its="http://www.w3.org/2005/11/its" |
| 17 | + xmlns:xi="http://www.w3.org/2001/XInclude" |
| 18 | + xmlns:xlink="http://www.w3.org/1999/xlink" |
| 19 | + xmlns:trans="http://docbook.org/ns/transclusion"> |
| 20 | + <info> |
| 21 | + <title>Distribution migration system configuration reference</title> |
| 22 | + <!--add author's email address--> |
| 23 | + < meta name= "maintainer" content= "[email protected]" its:translate= "no"/> |
| 24 | + <abstract><!-- can be changed via merge in the assembly --> |
| 25 | + <para> |
| 26 | + The upgrade live image is pre-configured to run without any further setup. The following |
| 27 | + configuration options are completely optional. Only change something if you need to and know |
| 28 | + what you are doing. |
| 29 | + </para> |
| 30 | + </abstract> |
| 31 | + </info> |
| 32 | + <section xml:id="reference-sle16-upgrade-distribution-migration-system-configuration"> |
| 33 | + <title>Optional configuration of the upgrade process</title> |
| 34 | + <para> |
| 35 | + The migration system reads a custom configuration file from the system to be upgraded. The |
| 36 | + content of this file modifies the behavior of the upgrade process. Prior to the start of the |
| 37 | + upgrade process, create the following file if a change of the default behavior is needed: |
| 38 | + </para> |
| 39 | +<screen>&prompt.sudo; <command>ssh</command> INSTANCE_USER@IP_OF_INSTANCE touch <filename>/etc/sle-migration-service.yml'</filename></screen> |
| 40 | + <para> |
| 41 | + The custom config file supports the following settings: |
| 42 | + </para> |
| 43 | + <variablelist> |
| 44 | + <varlistentry> |
| 45 | + <term>Control Zypper Installation Mode</term> |
| 46 | + <listitem> |
| 47 | + <para> |
| 48 | + If the upgrade process is used on systems that are not registered or for which the |
| 49 | + repository server has no upgrade path, it is required to switch off the use of the |
| 50 | + migration workflow. |
| 51 | + </para> |
| 52 | +<screen>use_zypper_migration: true|false</screen> |
| 53 | + <note> |
| 54 | + <para> |
| 55 | + The use of the migration workflow is the default behavior. If the migration workflow is |
| 56 | + not used, the setup of the repositories must be performed manually. Once done, the |
| 57 | + upgrade process uses <command>zypper dup</command> and expects all required repositories to be |
| 58 | + setup correctly. |
| 59 | + </para> |
| 60 | + </note> |
| 61 | + </listitem> |
| 62 | + </varlistentry> |
| 63 | + <varlistentry> |
| 64 | + <term>Specify Migration Product</term> |
| 65 | + <listitem> |
| 66 | + <para> |
| 67 | + By default the system will be migrated to SLES15 SP3. This default |
| 68 | + target can be changed via the <literal>migration_product</literal> setting. |
| 69 | + The product must be specified with the triplet <literal>name/version/arch</literal> |
| 70 | + found in <filename>/etc/products.d/baseproduct</filename> of the target product, |
| 71 | + for example: |
| 72 | + </para> |
| 73 | +<screen>migration_product: SLES/15.3/x86_64</screen> |
| 74 | + <warning> |
| 75 | + <para> |
| 76 | + Changing the default product leads to unsupported territory and |
| 77 | + is not tested nor covered by the SUSE support offering ! |
| 78 | + The specified product name must be supported by the repository |
| 79 | + server used for the migration. If the given product does not |
| 80 | + exist or the repository server cannot calculate an upgrade |
| 81 | + path, an error message from the repository server will be |
| 82 | + logged in the migration log file. Also see: |
| 83 | + <link xlink:href="https://documentation.suse.com/sles/15-SP6/html/SLES-all/cha-upgrade-background.html">Lifecycle and support</link> |
| 84 | + </para> |
| 85 | + </warning> |
| 86 | + </listitem> |
| 87 | + </varlistentry> |
| 88 | + <varlistentry> |
| 89 | + <term>Preserve System Data</term> |
| 90 | + <listitem> |
| 91 | + <para> |
| 92 | + Preserve custom data file(s) e.g. udev rules from the system |
| 93 | + to be migrated into the upgrade live system and make sure |
| 94 | + they will become effective. |
| 95 | + </para> |
| 96 | + <para> |
| 97 | + The <literal>preserve</literal> section has three subsections that govern file |
| 98 | + preservation and system actions: |
| 99 | + </para> |
| 100 | + <itemizedlist> |
| 101 | + <listitem> |
| 102 | + <para> |
| 103 | + <literal>static</literal>: Files in this subsection are copied into the DMS |
| 104 | + directly, with no further processing. |
| 105 | + </para> |
| 106 | + </listitem> |
| 107 | + <listitem> |
| 108 | + <para> |
| 109 | + <literal>rules</literal>: If this subsection contains files, they are preserved, and |
| 110 | + the DMS reloads udev to make these rules effective. |
| 111 | + </para> |
| 112 | + </listitem> |
| 113 | + <listitem> |
| 114 | + <para> |
| 115 | + <literal>sysctl</literal>: Preserving these files triggers sysctl --system to apply |
| 116 | + the configuration changes. |
| 117 | + </para> |
| 118 | +<screen>preserve: |
| 119 | + rules: |
| 120 | + - /etc/udev/rules.d/a.rules |
| 121 | + - /etc/udev/rules.d/b.rules |
| 122 | + static: |
| 123 | + - /etc/sysconfig/proxy |
| 124 | + - /path/to/be/preserved/*.suffix</screen> |
| 125 | + <note> |
| 126 | + <para> |
| 127 | + udev rules that require custom drivers will not have the desired effect |
| 128 | + as the migration system will not include these drivers and therefore |
| 129 | + execution of those rules will fail. Rules with such properties should |
| 130 | + not be listed. |
| 131 | + </para> |
| 132 | + </note> |
| 133 | + <note> |
| 134 | + <para> |
| 135 | + The DMS provides a set of default preservable files that vary based on |
| 136 | + the target version and architecture. User-defined values will supplement |
| 137 | + this default list. |
| 138 | + </para> |
| 139 | + </note> |
| 140 | + </listitem> |
| 141 | + </itemizedlist> |
| 142 | + </listitem> |
| 143 | + </varlistentry> |
| 144 | + <varlistentry> |
| 145 | + <term>Enable Debug Mode</term> |
| 146 | + <listitem> |
| 147 | + <para> |
| 148 | + If enabled, prevents the upgrade system from rewinding the setup |
| 149 | + steps and rebooting due to a failed upgrade, allowing the issue to |
| 150 | + be debugged. |
| 151 | + </para> |
| 152 | +<screen>debug: true|false</screen> |
| 153 | + </listitem> |
| 154 | + </varlistentry> |
| 155 | + <varlistentry> |
| 156 | + <term>Configure Reboot Method</term> |
| 157 | + <listitem> |
| 158 | + <para> |
| 159 | + By default, the migration system uses <literal>kexec</literal> to boot back into the host |
| 160 | + system once migration is complete. If this is in any way problematic, |
| 161 | + a regular <literal>reboot</literal> can be requested by setting <literal>soft_reboot: false</literal>. |
| 162 | + </para> |
| 163 | + <screen>soft_reboot: true|false</screen> |
| 164 | + </listitem> |
| 165 | + </varlistentry> |
| 166 | + <varlistentry> |
| 167 | + <term>Enable verbosity for zypper migration</term> |
| 168 | + <listitem> |
| 169 | + <para> |
| 170 | + If enabled, it will run the zypper migration plugin with increased verbosity. |
| 171 | + </para> |
| 172 | +<screen>verbose_migration: true|false</screen> |
| 173 | + </listitem> |
| 174 | + </varlistentry> |
| 175 | + <varlistentry> |
| 176 | + <term>Enable the fix option for pre_checks</term> |
| 177 | + <listitem> |
| 178 | + <para> |
| 179 | + If enabled (default), the run_pre_checks systemd process will use the <literal>--fix</literal> |
| 180 | + option to automatically remediate applicable issues before the migration |
| 181 | + is started. |
| 182 | + </para> |
| 183 | +<screen>pre_checks_fix: true|false</screen> |
| 184 | + </listitem> |
| 185 | + </varlistentry> |
| 186 | + <varlistentry> |
| 187 | + <term>Configure Make initrd Method</term> |
| 188 | + <listitem> |
| 189 | + <para> |
| 190 | + The live system may not contain all necessary tools to create an initrd that |
| 191 | + meets the need of the system being upgraded. Building a host independent |
| 192 | + initrd will create an initrd in a way that contains the tools and |
| 193 | + modules available on the system being upgraded. If this is needed, a host |
| 194 | + independent initrd can be created by setting |
| 195 | + <literal>build_host_independent_initrd: True</literal>. |
| 196 | + </para> |
| 197 | +<screen>build_host_independent_initrd: true|false</screen> |
| 198 | + </listitem> |
| 199 | + </varlistentry> |
| 200 | + <varlistentry> |
| 201 | + <term>Configure Dependency Solver Test Case Generation</term> |
| 202 | + <listitem> |
| 203 | + <para> |
| 204 | + It is possible that during the migration packages get installed that were not |
| 205 | + on the system previously and are pulled in because of dependencies. This |
| 206 | + setting will setup the migration such that a solver test case is generated. |
| 207 | + The information form the test case can then be used to understand why a |
| 208 | + given package was installed. |
| 209 | + </para> |
| 210 | + <screen>debug_solver: true|false</screen> |
| 211 | + </listitem> |
| 212 | + </varlistentry> |
| 213 | + </variablelist> |
| 214 | + </section> |
| 215 | +</topic> |
0 commit comments