openSUSE Leap 16 ARM64

Option A: Azure Portal

• Open the Azure Marketplace and search for "openSUSE Leap 16 Arm64 SecureAnyCloud".
• Select the image and click Create.
• Choose your subscription, resource group and region.
• Pick an Arm64 size such as Standard_D2ps_v6.
• Set the administrator username and paste your SSH public key.
• Allow inbound port 22 (SSH) and create the machine.

Option B: Azure CLI

Run the commands below on your own workstation. Substitute your resource group, VM name and preferred region. Accept the Marketplace terms once per subscription, then create the machine:

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

The --size must be an Arm64 size (Standard_D2ps_v6 above). Azure rejects an x86 size for an Arm image at create time.

ssh azureuser@<your-vm-public-ip>

Azure accepts only the key you supplied at create time. There is no password login.

Confirm that you have genuine openSUSE Leap 16.0, built for Arm:

cat /etc/os-release

NAME="openSUSE Leap" VERSION="16.0" ID="opensuse-leap" ID_LIKE="suse opensuse" VERSION_ID="16.0" PRETTY_NAME="openSUSE Leap 16.0" ANSI_COLOR="0;32" CPE_NAME="cpe:/o:opensuse:leap:16.0" BUG_REPORT_URL="https://bugs.opensuse.org" HOME_URL="https://www.opensuse.org/" DOCUMENTATION_URL="https://en.opensuse.org/Portal:Leap" LOGO="distributor-logo-Leap"

Confirm the architecture and the processor. aarch64 is the Arm 64-bit architecture, and Neoverse-N2 is the core that Azure Cobalt 100 uses:

uname -m && lscpu | grep -E 'Architecture|Model name|BIOS Model'

aarch64 Architecture: aarch64 Model name: Neoverse-N2 BIOS Model name: Cobalt 100 None CPU @ 3.4GHz

Check the kernel and its page size. This image uses the standard 4k page size kernel:

uname -r && getconf PAGESIZE

6.12.0-160000.37-default 4096

The kernel is a packaged, managed kernel, so it receives patches through the normal update path. Confirm the kernel package:

rpm -q kernel-default

kernel-default-6.12.0-160000.37.1.aarch64

The disk layout

The image uses a flat GPT layout: an EFI system partition and a root partition, with no LVM. The root filesystem is btrfs, openSUSE's standard choice, with separate subvolumes for the directories that benefit from them:

lsblk -o NAME,SIZE,FSTYPE,MOUNTPOINT && findmnt -no SOURCE,FSTYPE /

NAME SIZE FSTYPE MOUNTPOINT sda 30G ├─sda1 512M vfat /boot/efi └─sda2 29.5G btrfs /var sr0 1024M /dev/sda2[/@/.snapshots/1/snapshot] btrfs

It is normal for openSUSE to report the root filesystem as a subvolume path, and it is not a fault. To see the subvolumes, run:

sudo btrfs subvolume list /

ID 256 gen 11 top level 5 path @ ID 257 gen 16 top level 256 path @/.snapshots ID 258 gen 63 top level 257 path @/.snapshots/1/snapshot ID 259 gen 46 top level 256 path @/home ID 260 gen 16 top level 256 path @/opt ID 261 gen 55 top level 256 path @/root ID 262 gen 16 top level 256 path @/srv ID 263 gen 66 top level 256 path @/var ID 264 gen 16 top level 256 path @/boot/writable ID 265 gen 55 top level 256 path @/usr/local ID 266 gen 16 top level 256 path @/boot/grub2/arm64-efi ID 267 gen 16 top level 256 path @/boot/grub2/i386-pc

The operating system disk is 30 GB and carries no swap:

df -hT / /boot/efi && swapon --show

Filesystem Type Size Used Avail Use% Mounted on /dev/sda2 btrfs 30G 1.8G 28G 7% / /dev/sda1 vfat 512M 4.3M 508M 1% /boot/efi

swapon --show prints nothing, which means no swap is configured. Azure image certification requires this. You can add swap yourself if a workload needs it.

openSUSE uses zypper, not dnf or apt. The image was patched at build time, so a freshly launched machine reports only patches released since then. When there are none, the output reads:

sudo zypper patch-check

Loading repository data... Reading installed packages... 0 patches needed (0 security patches)

zypper patch-check exits 0 when nothing is pending, 100 when ordinary patches are available and 101 when security patches are available. This makes it convenient in scripts.

Your update path is the repo-oss repository, with GPG checking enabled:

sudo zypper lr -E

# | Alias | Name | Enabled | GPG Check | Refresh --+------------------------+----------------------+---------+-----------+-------- 3 | openSUSE:repo-openh264 | repo-openh264 (16.0) | Yes | (r ) Yes | Yes 4 | openSUSE:repo-oss | repo-oss (16.0) | Yes | (r ) Yes | Yes

If you are used to Leap 15, note that Leap 16 does not have a separate repo-update. Maintenance patches are delivered through repo-oss itself, so the two repositories above are the whole update path.

Apply patches yourself at any time with:

sudo zypper refresh && sudo zypper patch

Automatic updates

openSUSE has no dnf-automatic and no unattended-upgrades, so this image ships a SecureAnyCloud systemd timer. The timer runs zypper patch daily with a randomized delay of up to an hour:

systemctl is-enabled sac-zypper-patch.timer && systemctl list-timers sac-zypper-patch.timer --no-pager

enabled NEXT LEFT LAST PASSED UNIT ACTIVATES Tue 2026-09-15 00:06:31 UTC 1h 31min - - sac-zypper-patch.timer sac-zypper-patch.service 1 timers listed.

To see what the timer will run, or to run it immediately:

systemctl cat sac-zypper-patch.service
sudo systemctl start sac-zypper-patch.service

If your change control requires it, turn automatic patching off:

sudo systemctl disable --now sac-zypper-patch.timer

Some patches need a reboot to take effect. Check whether one is needed:

sudo zypper needs-rebooting

Confirm the effective SSH configuration. This command reads the parsed, effective settings rather than the file, so it accounts for every drop-in:

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

permitrootlogin without-password passwordauthentication no kbdinteractiveauthentication no permitemptypasswords no

without-password is the older spelling of prohibit-password and means the same thing: root may not log in with a password.

Confirm the root account has no usable password:

sudo passwd -S root

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

The L means locked.

Confirm SELinux is enforcing:

getenforce

Enforcing

Confirm that SSH is the only service listening off the machine. This is worth checking on any image you run, not just this one:

ss -tln && ss -uln

State Recv-Q Send-Q Local Address:Port Peer Address:Port LISTEN 0 128 0.0.0.0:22 0.0.0.0:* LISTEN 0 128 [::]:22 [::]:* State Recv-Q Send-Q Local Address:Port Peer Address:Port UNCONN 0 0 127.0.0.1:323 0.0.0.0:* UNCONN 0 0 [::1]:323 [::]:*

Port 22 is the only port reachable from outside the machine. The two UDP sockets on port 323 are chrony's control interface. They are bound to the loopback address only, so they are not reachable from the network.

Confirm the Azure Linux Agent is present and running:

waagent --version

WALinuxAgent-2.14.0.1 running on opensuse 16.0 Python: 3.13.14 Goal state agent: 2.14.0.1

Confirm that cloud-init completed cleanly. This is where the first-boot fix shows up. On the stock image, this command reports degraded:

cloud-init status --long

status: done extended_status: done boot_status_code: enabled-by-generator detail: DataSourceAzure [seed=/var/lib/waagent] errors: [] recoverable_errors: {}

Check how long the machine took to boot:

systemd-analyze

Startup finished in 949ms (kernel) + 4.016s (initrd) + 5.244s (userspace) = 10.211s

For comparison, the stock vendor image reaches the same point after 5 minutes and 19 seconds, because of the DHCP stall described earlier.

Confirm time synchronization against the Azure host clock. PHC0 is the hypervisor clock, and stratum 1 means the machine is synchronized directly to it:

chronyc tracking

Reference ID : 50484330 (PHC0) Stratum : 1 System time : 0.000002129 seconds slow of NTP time

Confirm nothing failed during boot:

systemctl list-units --state=failed

An empty list is the expected result.

The Azure serial console works through the Arm PL011 UART. This is ttyAMA0, not the ttyS0 you would see on an x86 machine:

cat /proc/cmdline | tr ' ' '\n' | grep console=

console=tty1 console=ttyAMA0

No host firewall is installed or enabled on this image. Your Azure Network Security Group is the firewall, which is the usual arrangement for an Azure Linux image. Manage inbound rules there, and you have one place to look.

If you also want a host firewall, install one:

sudo zypper install firewalld
sudo systemctl enable --now firewalld
sudo firewall-cmd --permanent --add-service=ssh sudo firewall-cmd --reload

Add the firewall after you have confirmed SSH access. Always keep port 22 open in the rule set, or you will lock yourself out.

Install packages with zypper:

sudo zypper refresh
sudo zypper install nginx

Search for a package:

zypper search nginx

Find which package owns a file:

zypper search --provides /usr/bin/python3

If you are coming from a Red Hat family distribution, the rough translations are dnf install to zypper install, dnf search to zypper search, dnf update to zypper update, and dnf upgrade --security to zypper patch.