How to Safely Patch Ubuntu 24.04 LTS on Microsoft Azure Virtual Machines: A Complete Step-by-Step Guide

Introduction

Keeping Linux virtual machines up to date is essential for maintaining security, stability, and compliance in Microsoft Azure environments.

However, patching a production Linux server requires more than simply running sudo apt upgrade. A poorly planned update can interrupt applications, restart critical services, affect network connectivity, or leave a virtual machine inaccessible after reboot.

This is particularly important for Azure VMs running business-critical services such as NGINX reverse proxies, load balancers, databases, web applications, and middleware.

In this guide, we demonstrate a structured patching process using a production-style Azure Ubuntu 24.04 LTS virtual machine.

We also explain how to handle a common situation where most updates install successfully but Ubuntu reports that some packages have been deferred due to phasing.

1. Understanding Ubuntu Linux Patching on Azure

Ubuntu patching typically includes several categories of updates:

A routine package update within Ubuntu 24.04 LTS is different from upgrading the operating system to a newer Ubuntu release.

For production environments, these should be treated as separate change-management activities.

Important: Do not run do-release-upgrade when your objective is simply to install the latest Ubuntu 24.04 patches.

2. Example Azure Ubuntu Server Environment

The following example reflects a typical Azure virtual machine used for application load balancing.

During routine inspection, the operating system reported:

32 packages can be upgraded.

It also indicated:

*** System restart required ***

Although these messages are common, the patching procedure should begin with system validation and recovery planning.

3. Step 1 – Connect to the Azure Linux VM

Connect using SSH from an authorised administrative workstation:

ssh <username>@<server-ip>

For virtual machines without public IP addresses, connect using Azure Bastion or an approved private network connection.

After connecting, confirm the current operating system:

hostnamectl

cat /etc/os-release

Check the active kernel:

uname -r

Check server uptime:

uptime

Check the last system boot:

who -b

Record these details before installing updates. They will be useful during post-patching validation and troubleshooting.

4. Step 2 – Perform Pre-Patching Health Checks

Before installing updates, verify that the operating system and applications are healthy.

Check disk space

df -hT

Also check inode availability:

df -ih

Pay particular attention to the following filesystems if configured:

• /

• /boot

• /var

• /var/log

Insufficient filesystem capacity can cause package installation failures.

Check memory

free -h

Check CPU load and uptime

uptime

Identify failed services

systemctl --failed

Review running services:

systemctl list-units \
  --type=service \
  --state=running

Investigate any failed critical services before patching.

Check recent errors

sudo journalctl -p err -b \
  --no-pager -n 100

This establishes a baseline so that pre-existing problems are not incorrectly attributed to the patching activity.

5. Step 3 – Validate Application Services

Production Azure VMs often host applications that must remain accessible during maintenance.

For an NGINX server, check:

sudo systemctl status nginx --no-pager

Verify the current NGINX version:

nginx -v

Test NGINX configuration:

sudo nginx -t

A successful configuration test resembles:

nginx: the configuration file /etc/nginx/nginx.conf syntax is ok
nginx: configuration file /etc/nginx/nginx.conf test is successful

Check whether NGINX is enabled at startup:

systemctl is-enabled nginx

Identify listening ports:

sudo ss -tulpn

For load-balancing servers, verify that upstream applications are healthy and identify the mechanism used to drain or redirect traffic.

Production recommendation: If multiple load balancers are configured, drain traffic from the node being patched and confirm that the remaining node has sufficient capacity.

If no redundant load balancer exists, arrange a planned service outage.

A package upgrade can restart a service before the final server reboot, so service continuity must be considered throughout the maintenance window.

6. Step 4 – Validate Azure Network Configuration

Networking changes are particularly sensitive when patching remote Linux servers.

Display the current IP configuration:

ip -br addr

Display the routing table:

ip route

Review Netplan configuration:

sudo netplan get

Validate Netplan configuration generation:

sudo netplan generate

The netplan generate command processes the configuration without applying new network settings to the running interfaces.

Avoid running netplan apply unnecessarily while connected remotely to a production server.

Record the expected IP addresses, routes, DNS configuration and application connectivity requirements.

7. Step 5 – Create an Azure VM Backup

Before patching, ensure that a valid recovery point is available.

Create an on-demand backup through Azure Portal

1. Sign in to the Microsoft Azure portal.

2. Navigate to Virtual Machines.

3. Select the Ubuntu VM.

4. Open Backup.

5. Confirm that Azure Backup is configured.

6. Select Backup now.

7. Monitor the backup job.

8. Confirm that a successful recovery point has been created.

An Azure VM backup provides a recovery option if a serious operating system problem occurs during patching.

For business-critical systems, verify the recovery procedure and understand the implications of restoring a VM to an earlier point in time.

Back up the NGINX configuration

For an NGINX server, also create a local configuration archive:

sudo tar -czf \
  /root/nginx-config-prepatch-$(date +%F).tar.gz \
  /etc/nginx

This can help restore application configuration if it is unexpectedly changed.

A local configuration archive is not a substitute for Azure Backup.

8. Step 6 – Identify Available Ubuntu Updates

Refresh the APT package index:

sudo apt update

This command downloads current package metadata from configured repositories.

It does not install the available updates.

List pending updates:

apt list --upgradable

Example:

nginx/stable 1.30.5-1~noble
[upgradable from: 1.30.4-1~noble]

netplan.io/noble-updates
[upgradable from: previous version]

open-iscsi/noble-updates
[upgradable from: previous version]

Review the packages carefully, especially those affecting:

• Linux kernels

• OpenSSH

• Network configuration

• NGINX and other application services

• Authentication libraries

• Storage connectivity

• Azure guest agents

Also check whether any packages have been explicitly held:

apt-mark showhold

An intentionally held package is different from one deferred due to Ubuntu's phased update mechanism.

9. Step 7 – Simulate the Update Before Installation

APT allows administrators to simulate an upgrade without making changes.

Run:

sudo apt-get -s upgrade

This displays the packages and operations proposed by the upgrade.

For additional dependency analysis:

sudo apt-get -s dist-upgrade

Unlike an ordinary upgrade, dist-upgrade may propose removing installed packages to resolve dependencies.

Do not execute a full dependency-changing upgrade automatically on a production server without reviewing the proposed changes.

Check for incomplete package installations:

sudo dpkg --audit

Check dependency consistency:

sudo apt-get check

If the system reports broken dependencies, resolve them before proceeding.

10. Step 8 – Apply Ubuntu Security and Package Updates

Once the Azure backup is successful, the change is approved, and any required traffic draining has been completed, begin patch installation.

For a remote SSH session, consider using a persistent terminal such as tmux:

tmux new -s ubuntu-patching

If tmux is not installed, use an approved terminal-management alternative rather than introducing unnecessary software during maintenance.

Refresh the package index:

sudo apt update

Install the available updates:

sudo apt upgrade

APT displays the package operations and requests confirmation.

Review the summary before accepting.

During installation, Ubuntu may ask whether to keep an existing configuration file or install a package-maintainer version.

For production applications, inspect the differences and preserve required custom settings.

Do not blindly overwrite NGINX, SSH or network configurations.

After installation, check the package database:

sudo dpkg --audit

sudo apt-get check

Check for remaining updates:

apt list --upgradable

11. Step 9 – Check Whether a Reboot Is Required

Ubuntu uses a reboot-required indicator when an installed update requires a system restart.

Check:

if [ -f /run/reboot-required ]; then
    echo "Reboot required"
else
    echo "No reboot currently required"
fi

To identify packages that requested a reboot:

if [ -f /run/reboot-required.pkgs ]; then
    cat /run/reboot-required.pkgs
fi

A reboot may be required after kernel updates or changes to important system components.

A missing reboot-required flag does not replace application-specific restart requirements or maintenance validation.

12. Step 10 – Reboot the Azure VM Safely

Before rebooting:

1. Confirm that the patch installation has completed.

2. Verify that the backup recovery point is available.

3. Confirm application traffic is drained or an outage is approved.

4. Check that administrative recovery access is available.

5. Notify the relevant operational teams.

Execute:

sudo systemctl reboot

The SSH session will disconnect.

Reconnect after the VM returns to service.

If SSH does not recover, investigate VM status, boot diagnostics, Azure Serial Console and network connectivity before attempting a forced restart.

13. Step 11 – Perform Post-Patching Validation

A successful reboot does not automatically mean the maintenance is complete.

Confirm the running kernel

uname -r

Compare with the pre-patching result.

Check uptime

uptime

Check system health

systemctl --failed

df -h

free -h

Validate NGINX

sudo nginx -t

sudo systemctl is-active nginx

nginx -v

Check service logs:

sudo journalctl -u nginx \
  -b --no-pager -n 100

Verify application connectivity through the expected endpoints.

For an HTTPS endpoint:

curl -I https://your-application.example.com

Replace the example address with the real application endpoint.

If the load balancer exposes TCP services, perform an appropriate end-to-end connection test.

Validate networking

ip -br addr

ip route

Check that network interfaces, IP addresses, routes and backend connectivity match the expected configuration.

Validate Azure resources

In Azure Portal, verify:

• VM running state

• Azure VM Agent health

• Azure Monitor metrics and alerts

• Load Balancer health probes

• Backend pool availability

• Application response times

• Relevant network and application logs

Only return the VM to active production traffic after service validation has succeeded.

14. Step 12 – Why Does Ubuntu Still Show Packages That Can Be Upgraded?

A common situation occurs after patching and rebooting.

An administrator executes:

sudo apt-get -s upgrade

And receives:

The following upgrades have been deferred due to phasing:
  libopeniscsiusr open-iscsi

0 upgraded, 0 newly installed,
0 to remove and 2 not upgraded.

Running sudo apt upgrade produces the same result.

Does this indicate a failed patching exercise?

Not necessarily. This is normal behaviour when Ubuntu is gradually rolling out package updates.

Understanding Ubuntu phased updates

Ubuntu uses phased updates to deploy certain updates progressively rather than making them immediately available to every machine.

The purpose is to identify potential regressions before an update reaches the entire Ubuntu environment.

Ubuntu security updates are not phased in the same way as standard Stable Release Updates.

For production systems, phased updates can reduce the risk of immediately receiving a problematic non-security update.

Example: Deferred Open-iSCSI packages

In our patching example, the following two updates remained available:

These packages relate to iSCSI storage connectivity.

Their appearance in the deferred list does not necessarily indicate an iSCSI problem or a failed upgrade.

Check phased update information

Run:

apt policy open-iscsi libopeniscsiusr

This displays the installed versions, candidate versions and repository information, including phasing details where available.

Check whether iSCSI is being used

sudo iscsiadm -m session

Review configured targets:

sudo iscsiadm -m node

If iSCSI is actively used, assess the effect of storage-related updates before installation.

Should deferred updates be forced?

For most production servers, the recommended approach is to allow Ubuntu's phased rollout mechanism to operate normally.

Avoid manually forcing deferred packages simply to achieve an empty update list.

If there is an operational requirement to install a particular version, perform an additional risk assessment and confirm the relevant release notes or security advisory.

Key lesson: Two deferred packages do not automatically mean that an otherwise successful patching exercise has failed.

15. Step 13 – Investigate Firmware Update Notifications

Some Azure Ubuntu virtual machines may display:

1 device has a firmware upgrade available.

Investigate using:

fwupdmgr get-devices

fwupdmgr get-upgrades

Do not automatically execute a firmware upgrade without identifying the affected component and confirming the applicable Microsoft and Canonical guidance.

In Azure environments, firmware-related notifications may require specific attention to the supported virtual machine security configuration.

Treat these updates as a separate maintenance activity when appropriate.

16. Step 14 – Validate Patch Compliance

Once the VM has rebooted and application validation is complete, run:

sudo apt update

apt list --upgradable

sudo apt-get check

sudo dpkg --audit

Also confirm no additional reboot is requested:

test -f /run/reboot-required \
  && echo "Reboot required" \
  || echo "No reboot required"

A production change record should capture:

Maintain the change record for troubleshooting, audit and compliance purposes.

17. Common Ubuntu Patching Problems and Troubleshooting

Problem: APT reports held-back packages

Check:

apt-mark showhold

apt policy <package-name>

Determine whether the package is explicitly held, deferred by phasing, or blocked by dependencies.

Problem: NGINX fails after an update

Check configuration:

sudo nginx -t

Inspect logs:

sudo journalctl -u nginx \
  -b --no-pager -n 100

Compare configuration against the pre-patching backup.

Do not repeatedly restart the service without identifying the cause.

Problem: Network connectivity fails after reboot

Use Azure Boot Diagnostics or Azure Serial Console where supported.

Inspect networking:

ip -br addr
ip route
sudo netplan get

Review Netplan and relevant system logs before making changes.

Problem: APT package installation is incomplete

Check:

sudo dpkg --audit

Review APT and dpkg logs:

sudo less /var/log/apt/history.log

sudo less /var/log/dpkg.log

Determine the failing package and underlying error before applying corrective commands.

Problem: A kernel update causes boot failure

Investigate the Azure VM boot logs and available recovery options.

Depending on the failure, recovery may require boot diagnostics, serial console, an alternative boot environment, or restoring from an Azure backup recovery point.

Avoid removing kernels or modifying boot configuration without a verified recovery plan.

18. Best Practices for Production Ubuntu Patching on Azure

A reliable patching strategy should extend beyond ad hoc manual updates.

Establish regular patching windows. Schedule operating system updates based on the organisation's security policies and application availability requirements.

Use recovery points. Verify Azure Backup coverage and restoration procedures before major changes.

Test important updates. Where practical, validate changes in non-production environments before production rollout.

Patch redundant systems sequentially. Avoid rebooting every node of a load-balanced or high-availability service at the same time.

Review third-party repositories. Packages supplied by external vendors may follow different release and support policies from Ubuntu packages.

Monitor after maintenance. Validate business transactions, application logs and connectivity, not just basic VM availability.

Consider Azure Update Manager. Azure Update Manager can assist with patch assessment, scheduled installation, maintenance configurations and reporting across supported machines.

Maintain an audit trail. Record installed updates, outstanding exceptions, validation evidence and change approvals.

19. When Should You Consider Automated Azure VM Patching?

Manual patching works for a small number of servers, but it becomes difficult to manage consistently as an Azure environment grows.

Organisations operating tens or hundreds of Linux and Windows virtual machines should consider centralised patch management.

Microsoft Azure Update Manager can help with:

Scheduled patch maintenance

• Patch assessment
• Installation monitoring
• Compliance reporting
• Maintenance windows
• Managing supported Azure and Azure Arc-enabled machines

Automation must still be designed around application dependencies, availability requirements, recovery procedures and maintenance approval.

It should not be treated as permission to reboot critical production servers without coordinating the affected services.

20. Conclusion

Patching Ubuntu 24.04 LTS on Microsoft Azure is relatively straightforward from a technical perspective, but production environments require additional operational controls.

The most important steps are to assess application dependencies, verify Azure backups, review the proposed APT transaction, apply patches in a controlled maintenance window, reboot where required and validate the complete application service afterward.

Our example also demonstrates that deferred phased updates are not necessarily a sign of failure.

Understanding Ubuntu's update mechanisms helps administrators avoid unnecessary package installation risks while maintaining a secure and stable environment.

By combining disciplined Linux patching procedures with Azure monitoring, backup and change management, organisations can reduce security exposure without introducing avoidable production outages.

Need Help Managing Your Azure Linux Infrastructure?

At Onsys Technologies, we help organisations across Australia and the Pacific manage, secure, troubleshoot and maintain their cloud and enterprise IT environments.

Our services include:

• Azure virtual machine administration and maintenance
• Linux and Windows server patching
• Azure infrastructure health assessments
• Application and database performance troubleshooting
• Azure networking and connectivity troubleshooting
• Backup, disaster recovery and business continuity
• Cloud infrastructure optimisation and modernisation
• Managed infrastructure and technical consulting

Whether you manage a single production Azure VM or a complex multi-server environment, Onsys can help establish secure, reliable and repeatable maintenance procedures.

Contact Onsys Technologies to discuss your Azure infrastructure support and maintenance requirements.

Website: https://onsys.com.au

Technical References

1. Ubuntu Server Documentation – Managing software: https://ubuntu.com/server/docs/tutorial/managing-software/

2. Ubuntu – About APT upgrade and phased updates: https://ubuntu.com/server/docs/about-apt-upgrade-and-phased-updates/

3. Ubuntu – Release upgrade guidance: https://ubuntu.com/server/docs/how-to-upgrade-your-release/

4. NGINX – Command-line parameters and configuration testing: https://nginx.org/en/docs/switches.html

5. Microsoft Learn – Azure Backup documentation: https://learn.microsoft.com/azure/backup/

6. Microsoft Learn – Azure Update Manager: https://learn.microsoft.com/azure/update-manager/

Disclaimer: The commands in this article are provided for technical guidance. Validate them against your environment, applicable support requirements and change-management policies before execution on production systems.