To enable the LTSS extension, perform the following steps:

1. Make sure your system is registered with a subscription that is eligible for LTSS. If the system is not yet registered, run:

   > sudo SUSEConnect -r REGISTRATION_CODE -e EMAIL_ADDRESS

2. Make sure the LTSS extension is available for your system:

   > sudo SUSEConnect --list-extensions | grep LTSS
   SUSE Linux Enterprise Server LTSS 15 SP4 x86_64
   Activate with: SUSEConnect -p SLES-LTSS/15.4/x86_64 -r ADDITIONAL REGCODE

3. Activate the module as instructed:

   > sudo SUSEConnect -p SLES-LTSS/15.4/x86_64 -r REGISTRATION_CODE

1. Create a file named repositories.bak.repo containing a list of all used repositories:

   # zypper lr -e repositories.bak

2. Also create a file named installed-software.bak containing a list of all installed packages:

   # rpm -qa --queryformat '%{NAME}\n' >
        installed-software.bak

3. Back up both files. The repositories and installed packages can be restored with the following commands:

   # zypper ar repositories.bak.repo
   # zypper install $(cat installed-software.bak)

   

   Note: Number of packages increases with an update to a new major release

   A system upgraded to a new major version (SLE X+1) may contain more packages than the initial system (SLE X). It will also contain more packages than a fresh installation of SLE X+1 with the same pattern selection. Reasons for this are:

   • Packages were split to allow a more fine-grained package selection. For example, 37 texlive packages on SLE 11 were split into over 3000 packages on SLE 15.

   • When a package has been split, all new packages are installed in the upgrade case to retain the same functionality as with the previous version. However, the new default for a fresh installation of SLE X+1 may be to not install all packages.

   • Legacy packages from SLE X may be kept for compatibility reasons.

   • Package dependencies and the scope of patterns may have changed.

1. Check if the LTSS extension is enabled:

   > sudo SUSEConnect --list-extensions | grep LTSS
   SUSE Linux Enterprise Server LTSS 12 SP4 x86_64 (Installed)
   Deactivate with: SUSEConnect -d -p SLES-LTSS/12.4/x86_64

2. Disable the LTSS extension with the command from the SUSEConnect output above:

   > sudo SUSEConnect -d -p SLES-LTSS/12.4/x86_64
   Deregistered SUSE Linux Enterprise Server LTSS 12 SP4 x86_64
   To server: https://scc.suse.com/

3. Verify the LTSS repository is no longer present with zypper lr.

1. Make sure the following preconditions are fulfilled:

   • If not already done, upgrade any package of the old PostgreSQL version to the latest release through a maintenance update.

   • Create a backup of your existing database.

   • Install the packages of the new PostgreSQL major version. For SLE 15 SP4 this means to install postgresql13-server and all the packages it depends on.

   • Install the package postgresql13-contrib which contains the command pg_upgrade.

   • Make sure you have enough free space in your PostgreSQL data area, which is /var/lib/pgsql/data by default. If space is tight, try to reduce size with the following SQL command on each database (can take very long!):

     VACUUM FULL

2. Stop the PostgreSQL server with either:

   # /usr/sbin/rcpostgresql stop

   or

   # systemctl stop postgresql.service

   (depending on the SLE version you use as the start version for your upgrade).

3. Rename your old data directory:

   # mv /var/lib/pgsql/data /var/lib/pgsql/data.old

4. Initialize your new database instance either manually with initdb or by starting and stopping PostgreSQL, which will do it automatically:

   # /usr/sbin/rcpostgresql start
   # /usr/sbin/rcpostgresql stop

   or

   # systemctl start postgresql.service
   # systemctl stop postgresql.service

   (depending on the SLE version you use as the start version for your upgrade).

5. If you have changed your configuration files in the old version, consider transferring these changes to the new configuration files. This may affect the files postgresql.auto.conf, postgresql.conf,pg_hba.conf and pg_ident.conf. The old versions of these files are located in /var/lib/pgsql/data.old/, the new versions can be found in /var/lib/pgsql/data.

   Note that copying the old configuration files is not recommended, because this may overwrite new options, new defaults and changed comments.

6. Start the migration process as user postgres:

   # su - postgres
   postgres > pg_upgrade \
    --old-datadir "/var/lib/pgsql/data.old" \
    --new-datadir "/var/lib/pgsql/data" \
    --old-bindir "/usr/lib/postgresql12/bin/" \
    --new-bindir "/usr/lib/postgresql13/bin/"

7. Start your new database instance with either:

   # /usr/sbin/rcpostgresql start

   or

   # systemctl start postgresql.service

   (depending on the SLE version you use as the start version for your upgrade).

8. Check if the migration was successful. The scope of the test depends on your use case and there is no general tool to automate this step.

9. Remove any old PostgreSQL packages and your old data directory:

   # zypper search -s postgresql12| xargs zypper rm -u
   # rm -rf /var/lib/pgsql/data.old

1. Create a dump file:

   # mysqldump -u root -p --all-databases --add-drop-database > mysql_backup.sql

   By default, mysqldump does not dump the INFORMATION_SCHEMA or performance_schema database. For more details refer to https://mariadb.com/kb/en/mariadb-dumpmysqldump/.

2. Store your dump file, the configuration file /etc/my.cnf, and the directory /etc/mysql/ for later investigation (not installation!) in a safe place.

3. Perform the SUSE Linux Enterprise Server upgrade. After the upgrade, your former configuration file /etc/my.cnf will still be intact. You can find the new configuration in the file /etc/my.cnf.rpmnew.

4. Configure your MariaDB database to your needs. Do not use the former configuration file and directory, but use it as a reminder and adapt it.

5. Make sure you start the MariaDB server:

   # systemctl start mariadb

   If you want to start the MariaDB server on every boot, enable the service:

   # systemctl enable mariadb

6. Verify that MariaDB is running properly by connecting to the database:

   # mariadb -u root -p

1. Open a terminal and log in as root.

2. Create a private key:

   # openssl genrsa -out server.key 1024

   If you want a stronger key, replace 1024 with a higher number, for example, 4096.

3. Create a certificate signing request (CSR):

   # openssl req -new -key server.key -out server.csr

4. Self-sign the certificate:

   # openssl x509 -req -days 365 -in server.csr -signkey server.key -out server.crt

5. Create the PEM file:

   # cat server.key server.crt > server.pem

6. Place the files server.crt, server.csr, server.key, and server.pem in the respective directories where the keys can be found. For Tomcat, for example, this directory is /etc/tomcat/ssl/.

1. Log in to the client machine.

2. The following step depends on the current operating system of the client:

   • For SUSE Linux Enterprise 11, execute the following commands:

     > sudo suse_register -E
     > sudo rm -f /etc/SUSEConnect
     > sudo rm -rf /etc/zypp/credentials.d/*
     > sudo rm -rf /etc/zypp/repos.d/*
     > sudo rm -f /etc/zypp/services.d/*
     > sudo rm -f /var/cache/SuseRegister/*
     > sudo rm -f /etc/suseRegister*
     > sudo rm -f /var/cache/SuseRegister/lastzmdconfig.cache
     > sudo rm -f /etc/zmd/deviceid
     > sudo rm -f /etc/zmd/secret

   • For SUSE Linux Enterprise 12, execute the following commands:

     > sudo SUSEConnect --de-register
     > sudo SUSEConnect --cleanup
     > sudo rm -f /etc/SUSEConnect
     > sudo rm -rf /etc/zypp/credentials.d/*
     > sudo rm -rf /etc/zypp/repos.d/*
     > sudo rm -f /etc/zypp/services.d/*

3. Log in to the SMT server.

4. Check if the client has successfully been deregistered by listing all client registrations:

   > sudo smt-list-registrations

5. If the client's host name is still listed in the output of this command, get the client's Unique ID from the first column. (The client might be listed with multiple IDs.)

6. Delete the registration for this client:

   > sudo smt-delete-registration -g UNIQUE_ID

7. If the client is listed with multiple IDs, repeat the step above for each of its unique IDs.

8. Check if the client has now successfully been deregistered by re-running:

   > sudo smt-list-registrations

1. Find the hibernation device:

   > sudo grep resume /etc/default/grub
   GRUB_CMDLINE_LINUX_DEFAULT="resume=/dev/sda1 splash=silent quiet showopts"

   The hibernation device is /dev/sda1. If the command returns nothing, hibernation is not configured.

2. Get the UUID for /dev/sda1:

   > sudo blkid /dev/vda1 
   /dev/vda1: UUID="a1d1f2e0-b0ee-4be2-83d5-78a98c585827" TYPE="swap" PARTUUID="000134b5-01"

   The UUID for /dev/sda1 is a1d1f2e0-b0ee-4be2-83d5-78a98c585827.

3. Edit /etc/default/grub and adjust the resume parameter. Replace /dev/sda1 with UUID=a1d1f2e0-b0ee-4be2-83d5-78a98c585827. The result will look like this:

   GRUB_CMDLINE_LINUX_DEFAULT="resume=UUID=a1d1f2e0-b0ee-4be2-83d5-78a98c585827 splash=silent quiet showopts"

4. Update the configuration of the grub boot manger:

   > sudo grub2-mkconfig -o /boot/grub2/grub.cfg

1. Select and prepare a boot medium, see Book “Deployment Guide”.

2. Insert the Unified Installer DVD for SUSE Linux Enterprise Server 15 SP4 and boot your machine. A Welcome screen is displayed, followed by the boot screen.

3. (Optional) To force the installer to only install packages from the DVD and not from network sources, add the boot option media_upgrade=1.

4. Start up the system by selecting Upgrade in the boot menu.

5. Proceed with the upgrade process as described in Section 4.4, “Upgrading SUSE Linux Enterprise”.

Note: SUSE Customer Center and Internet connection

If the system you want to upgrade is registered with the SUSE Customer Center, make sure to have an Internet connection during the following procedure.

1. After you have booted (either from an installation medium or the network), select the Upgrade entry on the boot screen.

   

   Warning: Wrong choice may lead to data loss

   Make sure you select Upgrade at this point. If you select Installation by mistake, your data partition will be overwritten with a fresh installation.

   YaST starts the installation system.

2. On the Welcome screen, choose Language and Keyboard. Proceed with Next.

   YaST checks your partitions for already installed SUSE Linux Enterprise systems.

3. On the Select for Upgrade screen, select the partition to upgrade and click Next.

4. YaST mounts the selected partition and displays the license agreement for the upgraded product. To continue, accept the license.

5. On the Previously Used Repositories screen, adjust the status of the repositories. By default all repositories are removed. If you have not added any custom repositories, do not change the settings. The packages for the upgrade will be installed from DVD, and you can optionally enable the default online repositories in the next step.

   If you have custom repositories, you have two choices:

   • Leave the repository in state Removed. Software that was installed from this repository will be removed during the upgrade. Use this method if no version of the repository that matches the new release is available.

   • Update and enable the repository if it matches the new release. Change its URL by clicking the repository in the list, and then click Change. Enable the repository by checking Toggle Status until it is set to Enable.

   Do not keep repositories from the previous release, as the system may be unstable or not work at all. Then proceed by clicking Next.

6. The next step depends on whether the upgraded system is registered with the SUSE Customer Center or not.

   1. If the system is not registered with the SUSE Customer Center, YaST displays a pop-up message suggesting using a second installation medium, the SLE-15-SP4-Full-ARCH-GM-media1.iso image.

      If you do not have that medium, the system cannot be upgraded without registration.

   2. If the system is registered with the SUSE Customer Center, YaST will show possible migration targets and a summary.

      Select one migration target from the list and proceed with Next.

7. In the next dialog you can optionally add an additional installation medium. If you have additional installation media, activate the I would like to install an additional Add On Product option and specify the media type.

8. Review the Installation Settings for the upgrade.

9. If all settings are according to your wishes, start the installation and removal procedure by clicking Update.

   

   Tip: Upgrade failure on SMT clients

   If the machine to upgrade is an SMT client, and the upgrade fails, see Procedure 3.1, “Deregistering a SUSE Linux Enterprise client from an SMT server” and restart the upgrade procedure afterward.

10. After the upgrade process has finished successfully, perform post-upgrade checks as described in Section 6.1, “Post-upgrade checks”.

1. Start YaST and select Software › Product Registration to open the Registration dialog.

2. Provide the E-mail address associated with the SUSE account you or your organization uses to manage subscriptions. In case you do not have a SUSE account yet, go to the SUSE Customer Center home page (https://scc.suse.com/) to create one.

3. Enter the Registration Code you received with your copy of SUSE Linux Enterprise Server.

4. If one or more local registration servers are available on your network, you can choose one of them from a list.

5. To start the registration, proceed with Next.

   After successful registration, YaST lists extensions, add-ons, and modules that are available for your system. To select and install them, proceed with Book “Deployment Guide”, Chapter 9 “Registering SUSE Linux Enterprise and managing modules/extensions”, Section 9.4 “Managing modules and extensions in a running system”.

1. Deactivate all unused extensions on your registration server to avoid future dependency conflicts. If you forget an extension, YaST will later detect unused extension repositories and deactivate them.

2. If you are logged in to a GNOME session running on the machine you are going to update, switch to a text console. Running the update from within a GNOME session is not recommended. Note that this does not apply when being logged in from a remote machine (unless you are running a VNC session with GNOME).

3. Run YaST online update to get the latest package updates for your system.

4. Install the package yast2-migration and its dependencies (in YaST under Software › Software Management).

5. Restart YaST, otherwise the newly installed module will not be shown in the control center.

6. In YaST, choose Online Migration (depending on the version of SUSE Linux Enterprise Server that you are upgrading from, this module is categorized under either System or Software). YaST will show possible migration targets and a summary. If more than one migration target is available for your system, select one from the list.

7. Select one migration target from the list and proceed with Next.

8. If the migration tool offers update repositories, it is recommended to proceed with Yes.

9. If the online migration tool finds obsolete repositories from DVD or a local server, it is highly recommended to disable them. Obsolete repositories are for a previous service pack. Old repositories from SUSE Customer Center or RMT are removed automatically.

   If the registration server does not offer migrations for a module or extension, its repository configuration will remain unchanged. This usually happens with 3rd party repositories such as the NVIDIA Compute Module that are not specific to a product version or service pack. If necessary, you can manually check the repository configuration after the migration.

10. Check the summary and proceed with the migration by clicking Next. Confirm with Start Update.

11. After the successful migration restart your system.

1. If you are logged in to a GNOME session running on the machine you are going to update, switch to a text console. Running the update from within a GNOME session is not recommended. Note that this does not apply when being logged in from a remote machine (unless you are running a VNC session with GNOME).

2. Register your SUSE Linux Enterprise machine if you have not done so:

   > sudo SUSEConnect --regcode YOUR_REGISTRATION_CODE

3. Start the migration:

   > sudo zypper migration

   Some notes about the migration process:

   • If more than one migration target is available for your system, Zypper allows you to select one SP from the list. This is the same as skipping one or more SPs. Keep in mind, online migration for base products (SLES, SLED) remains available only between the SPs of a major version.

   • By default, Zypper uses the option --no-allow-vendor-change which is passed to zypper dup. If a package was installed from a third-party repository, this option prevents packages from being replaced with the same package coming from SUSE.

   • If Zypper finds obsolete repositories coming from DVD or a local server, it is highly recommended to disable them. Old SUSE Customer Center or RMT repositories are removed automatically.

4. Review all the changes, especially the packages that are going to be removed. Proceed by typing y (the exact number of packages to upgrade can vary on your system):

   266 packages to upgrade, 54 to downgrade, 17 new, 8 to reinstall, 5 to remove, 1 to change arch.
   Overall download size: 285.1 MiB. Already cached: 0 B  After the operation, additional 139.8 MiB will be used.
   Continue? [y/n/? shows all options] (y):

   Use the Shift–Page ↑ or Shift–Page ↓ keys to scroll in your shell.

5. After successful migration restart your system.

1. If you are logged in to a graphical session running on the machine you are going to migrate, log out of that session and switch to a text console. Running the update from within a graphical session is not recommended. Note that this does not apply when being logged in from a remote machine (unless you are running a VNC session with X).

2. Update the package management tools with the old SUSE Linux Enterprise repositories:

   > sudo zypper patch --updatestack-only

3. Get a list of packages that currently do not have a repository assigned to them (orphaned packages). These packages will not be migrated and there is no guarantee that they will work after the migration (because other packages they rely on may have changed in such a way that they are no longer compatible). To get the list, run:

   > sudo zypper packages --orphaned

   Carefully review the list and remove all orphaned packages that are no longer needed. Make a note of all remaining orphaned packages, you will need it later for comparison.

4. Get a list of all repositories that the system is currently subscribed to by running:

   > sudo zypper repos -u

   Update each repository URL so that its product version number is 15-SP4. For example, if the URL of a repository is

   http://rmt.example.com/repo/SUSE/Products/SLE-15-SP2-Product-SLES/x86_64/product/

   change it to

   http://rmt.example.com/repo/SUSE/Products/SLE-15-SP3-Product-SLES/x86_64/product/

   This needs to be done with all repositories that are enabled. You may want to consider also doing this for repositories that are currently disabled, to avoid having wrong installation sources in the system when activating them at a later point in time.

   To change the repository URLs you have the following options:

   1. Using YaST › Software › Software Repositories. Select a repository and click Edit to make the required change. Repeat this for all repositories.

   2. Using Zypper. Remove the old repository by running

      > sudo zypper removerepo OLD_REPO_ID

      Then add the corresponding new repository by running

       > sudo zypper addrepo -f URL NAME-15-SP4

   3. By editing repository configuration files in /etc/zypp/repos.d. Each repository is represented by one configuration file. Changing the value for the baseurl parameter is required in each file.

5. Review your changes by running zypper repos -u and update the repositories by running:

   > sudo zypper refresh -f -s

   In case updating a repository fails, double-check whether you entered the wrong URL. If the problem cannot be fixed, it is recommended to disable the failing repository.

   If all repositories are correctly configured, run

   > sudo zypper refresh -f -s

   again, to make sure all repositories are up-to-date.

6. Before starting the migration it is recommended do a test run first:

   > sudo zypper dup -D --no-allow-vendor-change --no-recommends

   The parameter -D will perform a dry run that simulates the migration without actually changing the system. If problems occur, fix them before proceeding. In case the test run succeeds, perform the real migration by running:

   > sudo zypper dup --no-allow-vendor-change --no-recommends

   -no-allow-vendor-change ensures that third-party RPMs will not overwrite RPMs from the base system. The option --no-recommends ensures that packages deselected during initial installation will not be added again.

7. When the migration has finished and the system has booted into the new service pack version, run the check for orphaned packages again:

   > sudo zypper packages --orphaned

   Compare the new list with the one you generated before starting the migration. If new packages appear in the list, it may be because they were moved to a different module in the new service pack. If you did not have that module in the previous installation, the package did not get updated.

   You can check to which module a package belongs at https://scc.suse.com/packages. Add the missing modules using zypper addrepo or the YaST Software Repositories module, and update the orphaned packages afterwards by running:

   > sudo zypper install --no-recommends LIST OF PACKAGES

8. You have successfully migrated to a new service pack!

1. Get a list of all Snapper snapshots:

   > sudo snapper list

   Review the output to locate the snapshot that was created immediately before the service pack migration was started. The column Description contains a corresponding statement and the snapshot is marked as important in the column Userdata. Memorize the snapshot number from the column # and its date from the column Date.

2. Reboot the system. From the boot menu, select Start boot loader from a read-only snapshot and then choose the snapshot with the date and number you memorized in the previous step. A second boot menu (the one from the snapshot) is loaded. Select the entry starting with SLES 15 SP4 and boot it.

3. The system boots into the previous state with the system partition mounted read-only. Log in as root and check whether you have chosen the correct snapshot. Also make sure everything works as expected. Note that since the root file system is mounted read-only, restrictions in functionality may apply.

   In case of problems or if you have booted the wrong snapshot, reboot and choose a different snapshot to boot from—up to this point no permanent changes have been made. If the snapshot is correct and works as expected, make the change permanent by running the following command:

   > sudo snapper rollback

   Reboot the machine. On the boot screen, choose the default boot entry to reboot into the reinstated system.

4. Check if the repository configuration has been properly reset. Furthermore, check if all products are properly registered. If either one is not the case, updating the system at a later point in time may no longer work, or the system may be updated using the wrong package repositories.

   Make sure the system can access the Internet before starting this procedure.

   1. Refresh services and repositories by running

      > sudo zypper ref -fs

   2. Get a list of active repositories by running

      > sudo zypper lr

      Carefully check the output of this command. No services and repositories that were added for the update should be listed. For example, if you are rolling back from SLES 15 SP4 to SLES15 GA, the list must contain the SLES15-GA repositories, and not the SLES15-SP4 repositories.

      If wrong repositories are listed, delete them and, if necessary, replace them with the versions matching your product or service pack version. For a list of repositories for the supported migration paths refer to Section 2.3, “Module dependencies and lifecycles”. (Note that manual intervention should not be necessary, as the repositories should be updated automatically, but it is a best practice to verify and make any necessary corrections.)

   3. Last, check the registration status for all products installed by running

      > sudo SUSEConnect --status

      All products should be reported as being Registered. If this is not the case, repair the registration by running

      > sudo SUSEConnect --rollback