You can keep an application available while moving a SLES 15 SP5 cluster to SP6, but you cannot upgrade and reboot a single operating-system instance with literally zero interruption. SUSE supports the SP5-to-SP6 service-pack migration, and the online migration process still requires a system restart. To avoid service downtime, upgrade one node at a time in a supported SUSE Linux Enterprise High Availability (SLE HA) cluster, or build a replacement SP6 environment and move traffic to it. The service must have somewhere healthy to run while each host is unavailable.
This beginner-oriented guide focuses on the rolling-upgrade path for a SLE HA cluster. It also explains what to do if you have only one server, what to check before the change, and how to tell whether the service stayed healthy. The exact commands and order for moving workloads depend on your cluster resources, storage, and application.
A service-pack migration replaces system packages while the source system is running. SUSE calls this an online migration. It reduces the need to boot from installation media, but the official procedure says to restart the system after a successful migration. Online migration is not the same as a live upgrade that leaves the same host continuously serving requests.
For a clustered service, a rolling upgrade means taking one node out of service, migrating and rebooting it, returning it to the cluster, and then repeating on the next node. The application can remain available from another node if failover works and the remaining capacity is enough. A failover may still cause a short interruption for active sessions, so measure the user-facing service rather than assuming that “high availability” guarantees every connection remains untouched.
SUSE lists SLES 15 SP5 as a supported source for SP6, both online and offline. The supported path is documented in the SLES 15 SP6 upgrade-path guide. SUSE HA documentation supports a cluster rolling upgrade between service packs within the same major release. See the SLE HA cluster upgrade guide.
zypper migration directly on a SUSE Manager client.If your service is a database or another stateful application, treat application compatibility and data replication as a separate workstream. An operating-system migration path does not automatically upgrade the database or prove that its replication and failover design is safe.
Check that every node is on SLES 15 SP5, with the SLE HA extension and other modules or products registered as expected. The migration target list depends on installed products and extensions. A missing SP6 target can indicate a registration, repository, or extension-availability issue; do not try to force a different repository path just to make the target appear.
For a registered system, the following read-only checks can help establish its state:
cat /etc/os-release
sudo SUSEConnect --status
sudo zypper lr -u
Compare the installed SLES and SLE HA products, repositories, and architecture across all nodes. If the host is managed by SUSE Manager, use the corresponding client migration procedure instead of the direct steps below.
SUSE requires the source system to be at its most recent patch level before upgrading. Apply current SP5 maintenance updates and review the SP6 release notes for package, module, and application changes. SUSE’s upgrade preparation instructions also call for a current backup and a review of release notes.
Back up system configuration and application data, and verify that the backup can be restored. Test the whole procedure on a staging cluster that matches production, including network interfaces, storage, cluster resources, third-party repositories, and application health checks. Record how long migration and reboot take on each node so you can estimate the change window.
Before removing a node, confirm the cluster is healthy and has no unresolved resource failures. Check that another node can run the services, mount or access required storage, and handle expected traffic. If losing one node would overload CPU, memory, network, or storage, add capacity, reduce load, or schedule a maintenance window instead of claiming no downtime.
Make sure cluster fencing is configured and functioning according to your established HA design. Fencing protects shared resources by isolating a node that cannot be trusted; disabling it to make an upgrade seem easier can create a split-brain risk. Keep console or out-of-band access available in case a node does not return after reboot.
Use the steps below as a planning outline. Follow the procedure for your exact SLE HA version and resource setup; do not copy a resource-management sequence blindly into production.
crm status is one documented way to inspect cluster status.crm cluster stop.sudo zypper migration. Review the offered SP6 target and repository changes. Read the proposed package actions, especially packages to remove or downgrade, before confirming. The official SLES online migration instructions describe this command-line path.crm cluster start. Check crm status or Hawk2 and verify that the node rejoins without resource failures.SUSE states that mixed-version cluster nodes are supported only temporarily during the rolling upgrade and that the upgrade should be completed within one week. Plan a short, controlled sequence rather than leaving a mixed-version cluster in place indefinitely. Finish by confirming that all nodes run SP6, checking cluster and application health, and reviewing logs and repository registration.
Define a measurable success condition before the change. For example: the service’s external health check continues to pass throughout each node’s maintenance, error rates remain within the agreed threshold, and a representative user transaction succeeds while one node is unavailable. Record any failover gap, dropped sessions, queued work, or degraded performance. If the endpoint stayed up but a key workflow failed, the migration did not meet the service-level goal.
A rolling upgrade can keep an appropriately designed service available while individual servers reboot. It cannot guarantee uninterrupted sessions, compensate for a cluster with insufficient capacity, or remove the reboot from each migrated host. For single-node deployments, stateful applications without tested replication, or clusters with unsupported extensions, use a planned maintenance window or build and validate a replacement environment before shifting production traffic.
Capture Linux desktop audio in Audacity by routing its recording stream to your output device’s monitor source. Follow PulseAudio and PipeWire steps, export tips, and fixes for silent tracks.
Install Dropbox on Linux from the official package, sign in, sync a local folder, manage selective sync, and check status from the command line.
Install Inkscape from your Linux distribution’s repositories, the Ubuntu stable PPA, Snap, or Flathub, with current commands and notes for choosing a package source.
Use FSlint to scan selected Linux folders, review duplicate groups, and safely delete redundant files or learn when hard-link merging is appropriate.
Install SABnzbd on Ubuntu or Debian, or run it in Docker on another Linux host. Then open the web interface and configure your provider and download folders.
Install the Paper GTK theme from supported Linux repositories, enable it for GTK apps in GNOME Tweaks, and see what the legacy theme can and cannot change.
The old OpenMediaVault Plex plugin is archived. Set up Plex on OMV 8 with OMV-Extras, the Compose plugin, persistent storage, and Plex’s official container.
Clean and speed up Ubuntu with safe APT cleanup, storage checks, and startup controls that help free space and troubleshoot a sluggish desktop.
Install Hiri on Linux with its Snap package or official tarball, add a desktop launcher, and check supported accounts plus a warning about Hiri’s old Snap release.
Use Fastfetch and built-in Linux commands to check your distro, kernel, CPU, memory, graphics, storage, and connected devices, then save a clear report.
