Rocky 9 arm64

Option A: Azure Portal

• Open the Azure Marketplace and search for "Rocky Linux 9 Arm64 SecureAnyCloud".
• Select the image and click Create.
• On the Basics tab, set Subscription to your Azure subscription.
• Set Resource Group to a new or existing group.
• Enter a Virtual Machine Name.
• Pick your preferred Region.
• Set Size to Standard_D2ps_v6 (recommended, an Arm64 size).
• Under Administrator Account, select SSH public key and enter your key.
• Under Inbound Port Rules, allow SSH (port 22).
• Click Review + Create, then Create.

Option B: Azure CLI

Run this on your own workstation. Substitute your resource group, VM name and preferred region:

az vm image terms accept --urn sac1647283583153:rocky-9-arm64:default:latest
az vm create \
  --resource-group myResourceGroup \
  --name my-rocky-9-arm64-vm \
  --image sac1647283583153:rocky-9-arm64:default:latest \
  --size Standard_D2ps_v6 \
  --admin-username azureuser \
  --generate-ssh-keys \
  --public-ip-sku Standard

The --size must be an Arm64 size, such as Standard_D2ps_v6 above. Azure rejects an x86 size for an Arm image at create time.

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

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

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

Check that the machine runs Rocky Linux 9 on Arm.

cat /etc/rocky-release

Rocky Linux release 9.8 (Blue Onyx)

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

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

NAME="Rocky Linux" VERSION="9.8 (Blue Onyx)" ID="rocky" VERSION_ID="9.8" PLATFORM_ID="platform:el9"

The distribution itself asserts its RHEL compatibility lineage:

cat /etc/redhat-release

Rocky Linux release 9.8 (Blue Onyx)

The kernel string shows the architecture:

uname -srm

Linux 5.14.0-687.44.1.el9_8.aarch64 aarch64

aarch64 from uname confirms this is the native 64-bit Arm build, not an emulated or x86 image. The version reported is the Rocky Linux 9 point release the image was patched to. This listing tracks the 9 major release, so dnf update rolls it forward across future point releases.

Every available update was applied when this image was built. The command 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:

dnf needs-restarting -r

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

The base repositories are enabled, so your update path is intact:

dnf repolist --enabled

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

CRB (CodeReady Builder) ships configured but disabled, which is the Rocky Linux default. Enable it only if you build software that needs its development headers:

sudo dnf config-manager --set-enabled crb

Automatic updates

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

systemctl is-enabled dnf-automatic.timer

enabled

systemctl cat dnf-automatic.timer | grep -E 'OnCalendar|RandomizedDelaySec'

OnCalendar=*-*-* 6:00 RandomizedDelaySec=60m

The policy applies all available updates, not only those tagged as security errata. It never reboots automatically, so a kernel update waits for a window you choose instead of restarting a production machine without warning:

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

upgrade_type = default download_updates = yes apply_updates = yes reboot = never reboot_command = "shutdown -r +5 'Rebooting after applying package updates'"

upgrade_type is deliberately default rather than security. Errata metadata is not always populated, so a security-only policy can silently resolve to applying nothing. The default setting is the one that actually keeps the machine current.

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

Confirm SELinux is enforcing:

getenforce

Enforcing

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

passwd -S root

root LK 2009-12-22 -1 -1 -1 -1 (Alternate authentication scheme in use.)

Confirm that 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, because 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 your VM size has one, and a swap file baked into a Marketplace image is not permitted. This prints nothing:

swapon --show

Confirm what is listening. On a freshly launched machine, sshd on port 22 is your remote access. The base OS also runs rpcbind on port 111 and chronyd, bound to the loopback address, for time synchronization:

ss -tulnH | awk '{print $1, $5}' | sort -u

tcp 0.0.0.0:111 tcp 0.0.0.0:22 tcp [::]:111 tcp [::]:22 udp 0.0.0.0:111 udp 127.0.0.1:323 udp [::1]:323 udp [::]:111

The Azure Network Security Group controls inbound traffic. Only the ports you explicitly open in the NSG are reachable from outside the VM, regardless of what is bound locally.

If you do not use RPC-based services and want to close port 111 on the host as well, run sudo systemctl disable --now rpcbind.socket rpcbind.service to stop it.

The Azure Linux Agent handles provisioning, extensions and the portal's serial console. Check the agent and the related package versions:

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

active WALinuxAgent-2.14.0.1-4.el9.noarch cloud-init-24.4-8.el9_8.1.rocky.0.1.noarch chrony-4.8-1.el9.aarch64

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

cloud-init status

status: done

The kernel puts a console on ttyAMA0, the Arm PL011 serial port. This makes boot diagnostics and the portal's serial console work when you cannot reach the machine over SSH. On x86 images the console is ttyS0. On Arm it is ttyAMA0.

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

console=ttyAMA0

Time synchronization runs through chronyd against the Azure host clock:

chronyc -n sources | head -4

MS Name/IP address Stratum Poll Reach LastRx Last sample =============================================================================== #* PHC0 2 3 377 9 +9225ns[ +10us] +/- 9529ns ^- 144.202.41.38 4 6 37 12 +286us[ +287us] +/- 34ms

PHC0 is the Azure host clock, and it is the source chronyd selects (the * marks it). Public NTP servers remain as fallbacks.

The operating system disk is a 10 GB Gen2 disk with a simple, non-LVM layout: an EFI system partition, a /boot partition and an XFS root.

lsblk -o NAME,SIZE,FSTYPE,MOUNTPOINTS

NAME SIZE FSTYPE MOUNTPOINTS sda 10G ├─sda1 100M vfat /boot/efi ├─sda2 1000M xfs /boot └─sda3 8.9G xfs / sr0 1024M

df -hT / /boot

Filesystem Type Size Used Avail Use% Mounted on /dev/sda3 xfs 8.9G 1.2G 7.7G 14% / /dev/sda2 xfs 936M 407M 530M 44% /boot

Two things follow from this layout.

There is no ephemeral resource disk on Dpsv6. The recommended Standard_D2ps_v6 size has no local temporary disk, so nothing is mounted at /mnt. For fast local scratch storage, choose a Dpdsv6 size (the d denotes a local disk) or attach a managed data disk. Do not write scratch data to /mnt expecting a separate volume. On this size it is only a directory on the root filesystem.

Expand the root disk if you need more than 10 GB. First resize the managed disk in Azure (the VM must be deallocated). Then grow the partition and the filesystem in place. XFS grows online, so no reboot is needed after the disk is enlarged:

sudo dnf install -y cloud-utils-growpart
sudo growpart /dev/sda 3
sudo xfs_growfs /

To attach persistent storage instead, add a managed data disk in the portal or with az vm disk attach. Then partition and format it, and add it to /etc/fstab keyed by UUID.

The Azure Network Security Group controls inbound and outbound traffic. 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)

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

ss -tlnp

If your policy also requires a host firewall, 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.

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. Everything in the repositories is built for Arm, so dnf resolves aarch64 packages automatically. There is nothing extra to configure for the architecture.

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 on the file and mode 700 on the .ssh directory, both owned by that user.

The image ships with no human accounts, so azureuser is the only login until you add one:

getent group wheel

wheel:x:10: