have done inplace uplace upgrades form Redhat Enterprise Linux 7.9 to 8.10. After upgrade not able to bring back server to network. Not able to SSH to server

Question

have done inplace uplace upgrades form Redhat Enterprise Linux 7.9 to 8.10. After upgrade not able to bring back server to network. Not able to SSH to server

Jadwani, Prakash 0

have done in-place upgrades form Redhat Enterprise Linux 7.9 to 8.10. After upgrade not able to bring back server to network. Not able to SSH to server. How to fix the issue.

Himanshu Shekhar 6,700 Reputation points Microsoft External Staff Moderator

2026-06-15T02:25:25.0566667+00:00
Hi Prakash,

Thank you for reaching out. Since SSH is broken after the in-place Leapp upgrade from RHEL 7.9 > 8.10, please follow these steps to bring the VM back online:

Access the VM (out-of-band)

Log in via Azure Serial Console (Help > Serial console) using a local user with sudo rights. If the VM is completely unbootable, restore from the pre-upgrade snapshot/backup and retry the upgrade after applying the fixes below.

Validate networking from inside the VM

RHEL 8 uses NetworkManager by default; the old network.service and ifcfg scripts from RHEL 7 often get orphaned during Leapp.

nmcli device status nmcli connection show ip a ip route systemctl status NetworkManager

If the interface (usually eth0) shows unmanaged/disconnected, bring it up:
nmcli device set eth0 managed yes

nmcli con add type ethernet ifname eth0 con-name eth0 ipv4.method auto ipv6.method auto nmcli con up eth0

Confirm the VM gets an IP from Azure DHCP (168.63.129.16 reachable, default route via the Azure gateway). 3. Validate SSH service & firewall ```yaml systemctl status sshd systemctl enable --now sshd ss -tlnp | grep :22 firewall-cmd --list-all firewall-cmd --permanent --add-service=ssh && firewall-cmd --reload

Validate Azure Linux Agent (waagent)

systemctl status waagent journalctl -u waagent -b

If waagent is down, networking provisioning extensions and DHCP renewal can fail. Re-enable: systemctl enable --now waagent.

Ansible packages present pre-upgrade → not supported; remove and re-run.

Verify Azure side

NSG (subnet + NIC) allows inbound TCP 22 from your source IP.

Public IP / Bastion configuration intact.

No effective route blocking outbound 168.63.129.16.

If recovery isn't possible

Attach the OS disk to a rescue/repair VM (az vm repair create > repair run > repair restore) to fix fstab, grub, NetworkManager configs offline.

If unrecoverable and no backup exists, deploy a fresh RHEL 8.x VM from the Azure Marketplace and migrate workloads/data.

References

Troubleshoot Red Hat OS upgrade issues

Perform an upgrade for RHEL PAYG VMs using Leapp

Red Hat Enterprise Linux in-place upgrades on Azure
Himanshu Shekhar 6,700 Reputation points Microsoft External Staff Moderator

2026-06-16T05:30:29.9166667+00:00

Prakash - Just checking if provided response was helpful! please let me know if you have any queries.

1 answer

Your answer

Himanshu Shekhar 6,700 Reputation points Microsoft External Staff Moderator

2026-06-16T05:30:29.9166667+00:00

Prakash - Just checking if provided response was helpful! please let me know if you have any queries.

Answer 1

After an in-place upgrade from RHEL 7.9 to 8.10 on an Azure VM, loss of SSH connectivity is typically due to OS-level issues (network, fstab, cgroups, packages) that occurred during the Leapp upgrade. Use the following approach:

Access the VM for recovery
Since SSH is unavailable, use Azure-side access methods:
- Use Azure Serial Console for Linux to log in with a local account and troubleshoot from inside the VM.
- If the VM is completely unbootable or stuck, restore from the snapshot/backup taken before the upgrade (recommended prerequisite for Leapp upgrades).
Check for Leapp upgrade issues that break boot or mounts
If the VM boots but networking/SSH is broken, first verify whether the Leapp upgrade hit a known issue:
- Review the Leapp logs and report:
```
     sudo less /var/log/leapp/leapp-report.txt
     sudo less /var/log/leapp/leapp-upgrade.log
```
- If the upgrade failed to mount a device during the process (common cause of boot/network issues), follow the documented fix:
  1. Restore the VM from the snapshot or backup taken before the upgrade.
  2. On the restored VM, check whether the UUID from the error exists and is referenced in /etc/fstab:
```
        sudo blkid
        sudo cat /etc/fstab
```
  3. Comment out or remove the problematic UUID entry in /etc/fstab.
  4. Run the Leapp upgrade again.
- If the logs show Failed to mount n/a on /sys/fs/cgroup or cgroup2: Unknown parameter 'mode', remove the systemd.unified_cgroup_hierarchy=1 kernel parameter before re-running the upgrade:
  1. Restore the VM from snapshot/backup.
  2. Check for the parameter:
```
        cat /proc/cmdline
        sudo cat /etc/default/grub
```
  3. Remove systemd.unified_cgroup_hierarchy=1 from /etc/default/grub, regenerate grub config as appropriate for the distro, and reboot.
  4. Run the Leapp upgrade again.
Fix conflicts that can break services after upgrade
Some packages and custom libraries can cause Leapp to misconfigure the system, which may indirectly affect networking or SSH:
- If Ansible packages were installed on RHEL 7.9, the in-place upgrade is unsupported. Before re-running the upgrade, remove Ansible:
```
     sudo yum remove ansible ansible-test
```
- If there is a custom OpenSSL library path (for example /etc/ld.so.conf.d/openssl-1.1.1d.conf), it can cause library mismatches:
```
     sudo cat /etc/ld.so.conf.d/openssl-1.1.1d.conf
```
  If present, move it away and refresh the linker cache:
```
     sudo mv /etc/ld.so.conf.d/openssl-1.1.1d.conf /tmp
     sudo ldconfig
```
  Then retry the upgrade.
Verify network and SSH configuration from Serial Console
Once the VM boots cleanly after a corrected upgrade:
- Confirm that network interfaces are up and have IP addresses (commands depend on RHEL 8 networking setup).
- Ensure sshd is installed and enabled, and that firewall rules allow SSH (port 22).
- Confirm Azure-side NSG rules and public IP configuration are correct (inbound rule for TCP 22, no higher-priority deny).
If upgrade still fails
If the Leapp upgrade from 7.9 to 8.10 repeatedly fails and leaves the VM in a bad state, use an intermediate target version:
- Restore from snapshot/backup of RHEL 7.9.
- Run:
```
     sudo leapp preupgrade --target 8.8 --no-rhsm
```
  Resolve all inhibitors in /var/log/leapp/leapp-report.txt.
- Then run the actual upgrade to 8.8. After a successful intermediate upgrade, attempt an upgrade from 8.8 to 8.10 if needed.
Future prevention
Before repeating the upgrade on this or other VMs:
- Follow the documented prepare steps for RHEL 7.9 → 8.x on Azure: enable the correct RHUI repos, install leapp-rhui-azure or leapp-rhui-azure-sap as applicable, install leapp-upgrade, update all packages, reboot, disable antivirus and configuration management tools, and then run leapp preupgrade and fix all reported issues before leapp upgrade.

If the VM cannot be recovered even via Serial Console and no usable backup exists, the remaining option is to build a new RHEL 8.x VM and migrate workloads/data to it.

References:

Share via

have done inplace uplace upgrades form Redhat Enterprise Linux 7.9 to 8.10. After upgrade not able to bring back server to network. Not able to SSH to server

1 answer

Your answer