1. Home
  2. Our Blogs
  3. Advanced Troubleshooting Guide for Updating/Patching SUSE Linux End of Life Package Versions in Public Cloud Environments

26 March 2025

Advanced Troubleshooting Guide for Updating/Patching SUSE Linux End of Life Package Versions in Public Cloud Environments

This blog provides an advanced troubleshooting guide for updating or patching SUSE Linux Enterprise Server (SLES) in public cloud environments, focusing on systems that have not been updated for two to three years or more. Regular updates are essential for security, stability, and compatibility, but outdated configurations, repository mismatches, and dependency conflicts can cause update failures. The blog addresses two major issues: failed communication with SUSE Update/Repo Servers and instance boot failure after a zypper update in SLES 15 SP3. For connection failures, it outlines solutions such as re-registering the system, fixing system clock issues, checking network settings, and manually updating critical packages. To prevent boot failures, it provides best practices like locking the grub2-x86_64-efi package before migrating service packs and performing updates sequentially to maintain compatibility. Additionally, it stresses the importance of regular backups and post-migration updates to ensure system stability. By following these troubleshooting steps, IT teams can resolve update failures efficiently, minimize downtime, and maintain a secure, well-functioning enterprise environment in public cloud deployments.
Categories
Latest Articles
Archives

Introduction: SLES is popular and regular updates are a must 

Up-to-date software is an integral component for maintaining security, stability, and performance in any enterprise environment. Today, many enterprises adopt the SUSE Linux Enterprise Server (SLES) operating system.

Ensuring that your enterprise has the latest SLES is important to: 

  • Patch security vulnerabilities that could expose systems to cyber threats.
  • Improve system performance and improve resource usage.
  • Resolve compatibility issues with new software and hardware.
  • Enhance features and provide new capabilities.

    • While it’s known for its robustness and scalability,  failure to update SLES packages results in vulnerabilities, system incompatibilities, and operational disruptions. Reasons for package update failures vary. They can occur due to outdated configurations, repository mismatches, or system-specific issues. 

    We provide an in-depth analysis of common SUSE package update failures, their causes, and advanced troubleshooting methodologies to restore full system functionality while ensuring future-proof update management in this blog. 

    Our how-to guide is specially written for servers that have not been patched or updated for an extended period, typically two to three years or more. It does not apply to well-maintained systems that follow structured update and patch management cycles, whether weekly, quarterly, or annually. Instead, it focuses on troubleshooting long-unpatched environments that face significant challenges such as dependency conflicts, outdated repositories, and broken package management. 

    The issues we encountered

    Keeping the system updated regularly is challenging at times. But it is a must. We recently worked with a client who needed their SLES system updated and the best practices that we share in this blog are derived from this experience.

    The following two major issues confronted us:

  • SUSE instance failed to communicate with SUSE Update/Repo Servers
  • Instance boot failure after Zypper Update in SLES 15 SP3 \

    • Situation 1: SUSE instance failed to communicate with SUSE Update/Repo Servers

    The root cause
    An outdated system that becomes incompatible with the SUSE update infrastructure API leads to this situation. When systems are not regularly patched, they may fail to communicate with the update servers, leading to broken repository configurations and failed updates. 

    Possible additional causes
  • Corrupted repository metadata due to interrupted updates or network issues.
  • System clock misconfiguration where an incorrect system time can prevent SSL verification, blocking access to secure update servers.
  • Expired or missing certificates result in disruptions to secure communication with SUSE servers.
  • Network or firewall restrictions may block access to SUSE repositories.
  • Misconfigured proxy settings could have interfered with update requests.

    • Step-by-step issue resolution

    1. Initial cleanup and re-registration

    Run the following commands to clear existing configurations and attempt re-registration.

    sudo registercloudguest --clean
    sudo SUSEConnect --cleanup
    sudo rm -rf /etc/zypp/credentials.d/*
    sudo rm -rf /etc/zypp/repos.d/*
    sudo rm -rf /etc/zypp/services.d/*
    sudo rm -rf /etc/pki/trust/anchors/*
    sudo sed -i '/^# Added by SMT reg/,+1d' /etc/hosts
    sudo registercloudguest --force-new
    #If you got a success with above then check the status using bellow command.
    sudo SUSEConnect --status-text

    If this fixes the issue, ignore the steps listed below. But if not, then follow these instructions.

    2. Verify and fix system clock issues

    Incorrect time settings can prevent SSL verification and block updates. Synchronize your system clock with an NTP server.

    sudo systemctl restart chronyd
    sudo timedatectl set-ntp true
    sudo timedatectl

    3. Check network connectivity

    Ensure there are no network restrictions preventing access to SUSE repositories.

    ping updates.suse.com
    curl -v https://updates.suse.com

    If there are connection issues, then inspect firewall settings and proxy configurations.

    sudo iptables -L
    cat /etc/sysconfig/proxy

    4. Manually update packages if re-registration fails

    This step includes creating a fresh instance in your cloud platform with the same version that you are experiencing the issue with. For example, if you have an issue with SUSE SP3, then you need to create an instance as the same in the platform.

    Login as root and create a temporary directory for downloading required packages.

    mkdir -p /root/packages/rpms

    The focus here is to create a package dump to replace the outdated packages that we require to register the system using SUSEConnect.

    Based on your cloud provider, download and run the commands below.

    For Google Cloud:

    sudo zypper --pkg-cache-dir /root/packages/ download cloud-regionsrv-client
    cloud-regionsrv-client-plugin-gce
    regionServiceClientConfigGCE python3-gcemetadata
    SUSEConnect python3-cssselect python3-toml
    python3-lxml python3-M2Crypto python3-zypp-plugin

    For AWS:

    sudo zypper --pkg-cache-dir /root/packages/ download cloud-regionsrv-client
    cloud-regionsrv-client-plugin-ec2
    regionServiceClientConfigEC2 python3-ec2metadata
    SUSEConnect python3-cssselect python3-toml
    python3-lxml python3-M2Crypto python3-zypp-plugin

    For Azure:

    sudo zypper --pkg-cache-dir /root/packages/ download cloud-regionsrv-client
    cloud-regionsrv-client-plugin-azure
    regionServiceClientConfigAzure python3-azuremetadata
    SUSEConnect python3-cssselect python3-toml
    python3-lxml python3-M2Crypto python3-zypp-plugin

    After successfully creating a local dump of the packages, you can bundle and copy them to the SUSE server behind the issue. Once you have successfully created a local dump of the problematic packages, the next step is to bundle these files together.

    Transfer this bundled file to the SUSE server for further analysis and troubleshooting by SUSE support.

    sudo find /root/packages/ -type f -name "*.rpm" -exec cp {}
    /root/packages/rpms/ \;
    sudo cd /root/packages

    ● sudo tar -czvf suse-public-registration.tgz rpms

    Transfer suse-public-registration.tgz to the broken instance.

    Navigate to the suse-public-registration.tgz location and run the following:

    tar xvfz suse-public-registration.tgz
    cd rpms
    sudo zypper --no-refresh --no-remote --non-interactive install *.rpm

    #This will install the extracted package to the system as an update of the packages

    sudo registercloudguest --force-new

    #If you got a success with above then check the status using bellow command.

    sudo SUSEConnect --status-text

    If the above is successful, then you can update the system.

    It is important to note that during the troubleshooting process, we identified another potential issue. The updated system may crash completely due to instance metadata corruption. This issue affects virtual machines across almost all cloud providers. Before performing an update on SLES 15 SP3, refer to Situation 2 for important considerations.

    Situation 2: Instance boot failure after update (SLES 15 SP3)

    We observed situation 2 exclusively on non-SAP versions of SUSE Linux. It did not have any effect on SAP versions. (At the time of writing this blog, the SUSE 15 SP3 SAP version will continue to receive extended support until December 31, 2025.)

    The root cause

    Often, changes in the grub2-x86_64-efi package will result in boot failures after a zypper update. These changes can lead to incompatible bootloader configurations or EFI settings, rendering the system unbootable.

    Possible additional causes

  • Corrupt bootloader due to an interrupted update.
  • Missing EFI boot entries.
  • Mismatch between kernel and bootloader versions.


    • Key considerations to note

  • Ensure that the grub2-x86_64-efi package remains locked during the initial migration to prevent boot failures.
  • After successfully migrating to a higher Service Pack (e.g., SP6), unlock the package and update it to ensure compatibility with the new environment.

    • Step-by-step issue resolution

    1. Lock the grub2-x86_64-efi package to prevent it from being updated.

    sudo zypper al grub2-x86_64-efi

    To verify the lock:

    sudo zypper locks

    2. Perform the zypper update. Update the system while keeping the grub2-x86_64-efi package locked.

    Update the system while keeping the grub2-x86_64-efi package locked:

    sudo zypper update
    Service pack migration best practices

    1. Migrate to the target Service Pack (e.g., SP5 or SP6) using the following command:

    sudo zypper migration

    2. During the migration:

  • Select the target Service Pack (e.g., SP5 or SP6).

  • Choose Solution 1 to ignore its update when prompted about the locked grub2-x86_64-efi package.

  • Proceed with the migration.

    • 3. Unlock and update the grub2-x86_64-efi package after migration.

    4. Once the migration is complete, unlock the grub2-x86_64-efi package and update it to ensure compatibility with the new service pack using the commands included below.

    To unlock the package:
    sudo zypper rl grub2-x86_64-efi
    To update the package:
    sudo zypper update grub2-x86_64-efi
    To reboot the system:
    sudo reboot

    Important things to note when migrating to SLES 15 SP6 from SP3

  • Sequential migration

    • Always migrate from SLES 15 SP3 to SP5 before moving to SP6. Skipping service packs can lead to errors.

  • Post-migration updates

    • After migrating to SP6, perform a full system update to ensure all packages are compatible with the new environment.

  • Backup

    • Take a snapshot or create a machine image of the instance to ensure you can recover it in case of issues before starting the migration.

    Concluding thoughts

    Maintaining a robust and resilient system environment is vital to ensure timely, successful updates. SUSE package update failures can present significant challenges for any enterprise, but adopting a proactive approach to troubleshooting can minimise risks and reduce downtime. Regular patching not only enhances security and improves system performance, but it also ensures smooth compatibility with modern applications and hardware.

    By implementing the advanced strategies outlined in this blog, IT teams can effectively resolve update failures, prevent system downtime, and build a foundation for long-term stability and security. Continuous learning, regular system audits, and leveraging support resources are key to maintaining a secure and efficient operating environment in public cloud environments.

    For further information, refer to the official SUSE Knowledge Base: SUSE Support.

    Learn how we can help your enterprise.

    Contact our team today