Rocky Linux 10.2 on Azure User Guide

Overview

This guide covers the deployment and configuration of Rocky Linux 10.2 on Microsoft Azure using cloudimg's pre configured virtual machine image from the Azure Marketplace.

Rocky Linux is a community driven enterprise Linux distribution, built by the Rocky Enterprise Software Foundation to be binary compatible with Red Hat Enterprise Linux. Version 10.2, codename Red Quartz, is a point release in the RHEL 10 family, running the 6.12 kernel.

What's included:

• Rocky Linux 10.2, binary compatible with RHEL 10
• Every available update in the 10.2 stream applied at build time
• Automatic security updates armed and enabled, so the machine keeps patching itself
• Azure Linux Agent (waagent) and cloud-init for Azure integration
• Chronyd for NTP time synchronisation
• SELinux in enforcing mode
• BaseOS, AppStream and Extras repositories enabled, so your update path is intact
• No swap on the operating system disk, and the Cockpit web console closed by default
• Gen2 Hyper V virtual machine support
• 24/7 cloudimg support

Platform: Microsoft Azure (Gen2 Hyper V) Default user: azureuser

Which Rocky Linux 10 image should I choose?

cloudimg publishes two Rocky Linux 10 images, and they are deliberately different products. Pick the one that matches how your organisation procures an operating system.

	Rocky Linux 10.2 (this image)	Rocky Linux 10
Named for	The 10.2 point release	The 10 major release
Built from	10.2 specifically, asserted at build time	Whichever Rocky 10 point release is current when it is rebuilt
Suits	Change control and validated configuration matrices that name an exact minor version	Teams who simply want current Rocky Linux 10

Choose this image when your build sheet, compliance baseline or vendor support matrix names 10.2 and you need the image you procured to say so. The build refuses to run against any other point release, so a machine launched from this listing reports release 10.2 and nothing else.

Two things are worth stating plainly, because they matter more than the marketing:

• At the time of publication, 10.2 is also the newest Rocky Linux 10 point release. Rocky publishes 10.1 and 10.2, so today the two cloudimg images carry materially the same software. The distinction becomes visible when Rocky ships 10.3: the Rocky Linux 10 image moves on, and this one continues to identify as the 10.2 build.
• This is a pin on what you procured, not a freeze on what you run. The image keeps the standard BaseOS, AppStream and Extras repositories, so your own dnf update will roll the machine forward within Rocky 10 in the normal way. If you need to hold a fleet at 10.2, see Step 6 — and read the warning there first.

Security posture

This image ships with no known credential. There is no default password and no baked in SSH key:

• The root account password is locked, so no one can log in as root with a password.
• No account on the image has a usable password at all.
• PasswordAuthentication is disabled in the SSH daemon, so every login is by key.
• PermitRootLogin is set to without-password, so root cannot be reached with a password. No root key ships in the image, so in practice root has no remote login until you create one deliberately.
• SSH host keys are removed before capture and regenerated on each machine at first boot, so no two machines you launch share a host identity.
• /etc/machine-id is cleared before capture and regenerated per machine.
• The only key that works is the public key you supply when you create the virtual machine. Azure injects it into azureuser at first boot.
• SELinux is left in enforcing mode, the Rocky Linux default.
• The Cockpit web console, which the stock Rocky Linux 10 cloud image exposes on port 9090 of every interface, is disabled here. The packages remain installed so you can turn it back on in one command, but nothing listens on 9090 until you do. On a freshly launched machine the only listener is sshd on port 22.

Prerequisites

Before deploying this image, ensure you have:

1. An active Microsoft Azure subscription
2. Access to the Azure Portal or Azure CLI
3. An SSH key pair for Linux VM access
4. Familiarity with Azure VM management

Recommended VM Size: Standard_B2s (2 vCPU, 4 GB RAM) or larger.

Step 1: Deploy the Virtual Machine

Option A: Azure Portal

1. Navigate to the Azure Marketplace and search for "Rocky Linux 10.2 cloudimg"
2. Select the image and click Create
3. Configure the basics:
4. Subscription: Select your Azure subscription
5. Resource Group: Create new or select existing
6. Virtual Machine Name: Enter a name for your VM
7. Region: Select your preferred Azure region
8. Size: Standard_B2s recommended
9. Under Administrator Account, select SSH public key and enter your key
10. Under Inbound Port Rules, allow SSH (port 22)
11. Click Review + Create, then Create

Option B: Azure CLI

az vm create \
  --resource-group myResourceGroup \
  --name my-rocky-10-2-vm \
  --image cloudimg:rocky-linux:rocky10-2:latest \
  --size Standard_B2s \
  --admin-username azureuser \
  --generate-ssh-keys \
  --public-ip-sku Standard

Step 2: Connect via SSH

Run these on your own workstation, not on the VM. Find the public IP, then connect:

az vm show --resource-group myResourceGroup --name my-rocky-10-2-vm --show-details --query publicIps -o tsv
ssh azureuser@<vm-ip>

There is no password to enter. If SSH asks you for one, the key you supplied at create time is not the key your client is offering.

Step 3: Confirm the release

The first thing to check is that the machine is the point release you paid for.

cat /etc/rocky-release

Rocky Linux release 10.2 (Red Quartz)

The os-release fields carry the same information in a machine readable form, which is what configuration management tools read:

grep -E '^(NAME|VERSION|ID|VERSION_ID|PLATFORM_ID)=' /etc/os-release

NAME="Rocky Linux"
VERSION="10.2 (Red Quartz)"
ID="rocky"
VERSION_ID="10.2"
PLATFORM_ID="platform:el10"

VERSION_ID is 10.2, not 10. That is the field an inventory or compliance tool keys on, and it is the reason this listing exists as a separate product.

The RHEL compatibility lineage is asserted by the distribution itself:

cat /etc/redhat-release

Rocky Linux release 10.2 (Red Quartz)

And the kernel:

uname -srm

Linux 6.12.0-211.37.1.el10_2.x86_64 x86_64

Step 4: Check the patch level and automatic updates

Every update available in the 10.2 stream was applied when this image was built. dnf check-update exits 100 when updates are pending and 0 when none are:

dnf -q check-update >/dev/null 2>&1; echo "exit=$?"

exit=0

Nothing is waiting on a reboot either:

dnf needs-restarting -r

No core libraries or services have been updated since boot-up.
Reboot should not be necessary.

Your update path is intact. Three repositories are enabled:

dnf repolist --enabled

repo id                         repo name
appstream                       Rocky Linux 10 - AppStream
baseos                          Rocky Linux 10 - BaseOS
extras                          Rocky Linux 10 - Extras

CRB (CodeReady Builder) and the Devel repository ship configured but disabled, which is the Rocky default. Enable CRB only if you are building software that needs its development headers:

sudo dnf config-manager --set-enabled crb

Automatic security updates

Unlike a stock Rocky Linux cloud image, this machine keeps patching itself. dnf-automatic is installed and its timer is enabled, so the machine applies security updates on its own schedule:

systemctl is-enabled dnf-automatic.timer

enabled

systemctl list-timers dnf-automatic.timer

NEXT                            LEFT LAST PASSED UNIT                ACTIVATES
Mon 2026-07-27 06:52:34 UTC 4h 17min -         - dnf-automatic.timer dnf-automatic.service

The policy applied is deliberately conservative — security updates only, and never an automatic reboot, so a kernel update waits for a window you choose rather than restarting a production machine without warning:

grep -E '^(apply_updates|upgrade_type|reboot|random_sleep)' /etc/dnf/automatic.conf

upgrade_type = security
random_sleep = 300
apply_updates = yes
reboot = never

Because reboot = never, check periodically whether a restart is owed after a kernel update, using the needs-restarting -r command above. To opt out entirely, run sudo systemctl disable --now dnf-automatic.timer.

Step 5: Verify the security posture

Confirm SELinux is enforcing:

getenforce

Enforcing

Confirm the root account is locked. The L in the second field means locked:

passwd -S root

root L 2009-12-22 -1 -1 -1 -1

Confirm no account on the machine has a usable password. This prints nothing on a clean image:

sudo awk -F: '($2 !~ /^[!*]/) && ($2 != "") {print $1}' /etc/shadow

Read the SSH daemon's effective policy rather than the config file, since the running daemon is what a client actually meets:

sudo sshd -T | grep -E '^(permitrootlogin|passwordauthentication|pubkeyauthentication) '

permitrootlogin without-password
pubkeyauthentication yes
passwordauthentication no

There is no swap on the operating system disk. Azure manages swap on the ephemeral resource disk if you want it, and a swap file baked into a Marketplace image is not permitted, so this prints nothing:

swapon --show

Confirm the Cockpit web console is closed and that sshd is the only thing listening:

systemctl is-enabled cockpit.socket
ss -tlnH | awk '{print $1, $4}'

disabled
LISTEN 0.0.0.0:22
LISTEN [::]:22

Re-enabling the Cockpit web console

Cockpit is a browser based server manager. It is installed but switched off. To use it, open port 9090 in your Azure Network Security Group and then:

sudo systemctl enable --now cockpit.socket

Cockpit authenticates against local system accounts. Since this image ships no account with a password, create one for yourself before you rely on Cockpit for access, and restrict port 9090 to your own address range in the NSG rather than opening it to the internet.

Step 6: Holding a machine at 10.2

By default this machine behaves like any other Rocky Linux 10 system: sudo dnf update moves it forward within the Rocky 10 series, including across future point releases. That is the right behaviour for most workloads, and it is how you receive security fixes.

If your change control genuinely requires a fleet to stay on the 10.2 package set, Rocky's mechanism is the releasever variable:

echo "10.2" | sudo tee /etc/dnf/vars/releasever

Read this before you do it. Rocky serves a pinned minor release from its vault, and a vault is only populated once that release has been superseded. At the time of writing, 10.2 is the current release and https://dl.rockylinux.org/vault/rocky/10.2/ returns 404, so pinning today would point dnf at a location that does not exist yet. More importantly, once a vault is frozen it stops receiving new security backports — so pinning trades security currency for version stability. Pin only if a compliance obligation requires it, revisit the decision on a schedule, and never pin a machine that is exposed to the internet without compensating controls.

For most people the correct answer is to leave the repositories alone, let the automatic security updates run, and use this listing for what it is: a guarantee about the release you procured.

Step 7: Verify Azure integration

The Azure Linux Agent handles provisioning, extensions and the portal's serial console:

systemctl is-active waagent
rpm -q WALinuxAgent cloud-init

active
WALinuxAgent-2.14.0.1-3.el10.noarch
cloud-init-24.4-7.el10_2.1.rocky.0.1.noarch

Cloud-init should report done, which means provisioning finished cleanly:

cloud-init status

status: done

The kernel puts a console on ttyS0, which is what makes boot diagnostics and the portal's serial console work when you cannot reach the machine over SSH:

grep -o 'console=ttyS0[^ ]*' /proc/cmdline

Time synchronisation runs through chronyd against the Azure host clock:

chronyc -n sources | head -3

MS Name/IP address         Stratum Poll Reach LastRx Last sample
===============================================================================
#* PHC0                          2   3   377     4    +20us[  +24us] +/- 5212ns

Azure attaches an ephemeral resource disk, which waagent formats and mounts at /mnt. It is fast, local and erased whenever the machine is deallocated or moved, so use it for scratch and caches, never for data you need to keep:

df -h / /mnt

Filesystem      Size  Used Avail Use% Mounted on
/dev/sdb4       8.4G  1.2G  7.2G  15% /
/dev/sda1       7.8G   28K  7.4G   1% /mnt

Step 8: Networking and the firewall

The Azure Network Security Group is the control plane for inbound and outbound traffic, and it is the first and usually the only place you need to open a port.

This image is a minimal build, so firewalld is not installed:

rpm -q firewalld || echo "(firewalld absent - the Azure NSG is your only firewall)"

package firewalld is not installed
(firewalld absent - the Azure NSG is your only firewall)

That is deliberate: with no host firewall in the way, your NSG rules take effect exactly as written, with no second layer to keep in sync. Confirm what is listening before you open anything:

ss -tlnp

If your policy requires a host firewall as well, install and enable it yourself:

sudo dnf install -y firewalld
sudo systemctl enable --now firewalld
sudo firewall-cmd --permanent --add-port=443/tcp
sudo firewall-cmd --reload

Once firewalld is running, a port must be open in both the Azure NSG and firewalld before traffic reaches your service.

Step 9: Install software

AppStream carries the application packages. Search it, then install what you need:

dnf search nginx

Install a package and enable it in the usual way, for example sudo dnf install -y nginx followed by sudo systemctl enable --now nginx.

Note that modularity is deprecated in Rocky Linux 10. The dnf module streams that shaped package selection on Rocky 8 are on their way out, and DNF will warn you if you use them. On Rocky 10 you generally install the single version AppStream carries, and reach for a vendor repository or a container when you need a different one.

To add another administrator, create the account with sudo adduser <name>, add it to the wheel group with sudo usermod -aG wheel <name>, then copy your public key into /home/<name>/.ssh/authorized_keys with mode 600 and the .ssh directory mode 700, owned by that user. The image ships with no human accounts at all, so azureuser is the only login until you add one:

getent group wheel

Common Use Cases

• An enterprise Linux base for application servers where the exact minor release is part of a validated configuration
• A RHEL compatible platform for workloads certified against RHEL 10 without a subscription
• A standard operating system baseline for fleets managed by Ansible, Puppet or Salt
• A build and test host for software that must be verified against a named RHEL 10 point release

Troubleshooting

Cannot connect via SSH

Check the Network Security Group allows inbound TCP 22 from your address, confirm the machine is running, and make sure your client is offering the private key that matches the public key you supplied at create time. Password authentication is disabled, so a password prompt means key negotiation already failed.

az vm show --resource-group myResourceGroup --name my-rocky-10-2-vm --show-details --query powerState -o tsv

Azure agent not running

systemctl status waagent --no-pager
sudo journalctl -u waagent -n 50 --no-pager

If waagent is stopped, extensions and portal features that depend on it stop working. Restart it with sudo systemctl restart waagent.

Package manager issues

Clear the metadata cache and rebuild it:

sudo dnf clean all
sudo dnf makecache

If a repository is unreachable, confirm the machine has outbound HTTPS and that DNS resolves, since Rocky's mirror system is reached over both.

A service is blocked and the logs mention SELinux

SELinux is enforcing, which is the secure default and should stay that way. Look at the denial rather than disabling SELinux:

sudo ausearch -m AVC -ts recent 2>/dev/null || echo "no recent AVC denials"

Most denials on a fresh machine come from software installed into a non standard path. Relabel with sudo restorecon -Rv /path before considering any policy change.

Important Notes

Rocky Linux is free and open source. It is not covered by a single licence: the distribution is a collection of free and open source licences across its package set, predominantly GPL, with BSD, MIT, Apache and others. No subscription, entitlement or licence key is required, and no per seat cost applies.

Rocky Linux and the Rocky Linux logo are trademarks of the Rocky Enterprise Software Foundation. cloudimg is not affiliated with or endorsed by the Rocky Enterprise Software Foundation.

Rocky Linux 10 follows the RHEL 10 lifecycle, with support running into the 2030s. Check the Rocky Linux release notes for the dates that apply to your deployment.

Support

For assistance with this image, contact cloudimg support:

• Website: www.cloudimg.co.uk
• Product Catalogue: www.cloudimg.co.uk/products
• User Guides: www.cloudimg.co.uk/guides
• SLA: 24 hour response guaranteed