Fedora 44 ARM64

Option A: Azure Portal

• Open the Azure Marketplace and search for "Fedora Linux 44 Arm64 SecureAnyCloud".
• Select the image and click Create.
• Choose your subscription, resource group and region.
• Pick an Arm64 size such as Standard_D2pds_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 these commands on your own workstation, and 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:fedora-44-arm64:default:latest
az vm create \
  --resource-group myResourceGroup \
  --name my-fedora-44-arm64-vm \
  --image sac1647283583153:fedora-44-arm64:default:latest \
  --size Standard_D2pds_v6 \
  --admin-username azureuser \
  --generate-ssh-keys \
  --public-ip-sku Standard

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

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

Only the key you supplied at create time is accepted. There is no password login.

Confirm that you have Fedora Linux 44, built for Arm:

cat /etc/os-release

NAME="Fedora Linux" VERSION="44 (Cloud Edition)" RELEASE_TYPE=stable ID=fedora VERSION_ID=44 VERSION_CODENAME="" PRETTY_NAME="Fedora Linux 44 (Cloud Edition)" ANSI_COLOR="0;38;2;60;110;180" LOGO=fedora-logo-icon CPE_NAME="cpe:/o:fedoraproject:fedora:44" HOME_URL="https://fedoraproject.org/" DOCUMENTATION_URL="https://docs.fedoraproject.org/en-US/fedora/f44/" SUPPORT_URL="https://ask.fedoraproject.org/" BUG_REPORT_URL="https://bugzilla.redhat.com/" REDHAT_BUGZILLA_PRODUCT="Fedora" REDHAT_BUGZILLA_PRODUCT_VERSION=44 REDHAT_SUPPORT_PRODUCT="Fedora" REDHAT_SUPPORT_PRODUCT_VERSION=44 SUPPORT_END=2027-05-19 VARIANT="Cloud Edition" VARIANT_ID=cloud

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

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 kernel, which is what almost all software expects:

uname -r && getconf PAGESIZE

7.2.5-200.fc44.aarch64 4096

The kernel is a packaged, managed kernel, so it receives updates through the normal update path. Superseded kernels are removed before capture, so exactly one is installed:

rpm -q kernel-core

kernel-core-7.2.5-200.fc44.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, which is Fedora's standard choice, with separate subvolumes for root, boot, home and var:

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

NAME SIZE FSTYPE MOUNTPOINT sda 30G ├─sda1 100M vfat /boot/efi └─sda2 29.9G btrfs /home sr0 628K nvme0n1 110G /dev/sda2[/root] btrfs

The root filesystem is reported as a subvolume path. This is normal for Fedora and is not a fault. The same applies to the MOUNTPOINT shown against sda2. That one partition carries several btrfs subvolumes, and lsblk prints only one of them. Which one it picks is arbitrary: /home here, /var on another boot. The findmnt output above is the authoritative answer for /.

sr0 is the small virtual CD-ROM that Azure attaches to pass in provisioning data. To see the subvolumes:

sudo btrfs subvolume list /

ID 256 gen 174 top level 5 path root ID 257 gen 156 top level 5 path boot ID 258 gen 171 top level 5 path home ID 259 gen 176 top level 5 path var

The gen numbers are btrfs generation counters and differ on your machine. The four subvolume names are what matter.

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.1G 29G 4% / /dev/sda1 vfat 100M 15M 86M 15% /boot/efi

swapon --show prints nothing, which means no swap is configured. Azure image certification requires that, and Fedora's usual zram swap is disabled in this image for the same reason. If a workload needs swap, restore it with:

printf '[zram0]\nzram-size = ram / 2\n' | sudo tee /etc/systemd/zram-generator.conf
sudo systemctl unmask systemd-zram-setup@zram0.service
sudo systemctl start systemd-zram-setup@zram0.service

The local NVMe disk, if your size has one

nvme0n1 above is the local resource disk that the d in Standard_D2pds_v6 provides: 110 GB of directly attached NVMe on this size. It is ephemeral. Its contents are lost whenever the machine is stopped and deallocated, or moved to another host.

This image leaves the disk exactly as Azure presents it: unformatted, unmounted and with /mnt empty. Guessing a filesystem and a mount point for you would be worse than leaving it alone.

lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINT | grep -E 'NAME|nvme'

NAME SIZE TYPE FSTYPE MOUNTPOINT nvme0n1 110G disk

To use it as scratch space, for example for a build cache, a scratch database or temporary files, run the commands below. Never use it for anything that must survive a deallocation:

sudo mkfs.xfs /dev/nvme0n1
sudo mkdir -p /mnt/scratch
sudo mount /dev/nvme0n1 /mnt/scratch

If you add an /etc/fstab entry for it, use the nofail option. Without it, a machine that comes back on a host where the disk has been re-provisioned fails to boot. Sizes without the d, such as Standard_D2ps_v6, have no nvme0n1, and this section does not apply to them.

Fedora 44 uses DNF 5. The dnf command is dnf5, and the older DNF 4 is not installed. Almost every familiar command works unchanged.

The image was fully updated immediately before capture, so the check below reported nothing pending at build time. A later launch may list updates released since:

sudo dnf check-update; echo "exit code: $?"

Updating and loading repositories: Repositories loaded. exit code: 0

dnf check-update exits 0 when nothing is pending and 100 when updates are available, which makes it convenient in scripts.

Your update path is the fedora and updates repositories, with GPG checking enabled:

dnf repolist

repo id repo name fedora Fedora 44 - aarch64 fedora-cisco-openh264 Fedora 44 openh264 (From Cisco) - aarch64 updates Fedora 44 - aarch64 - Updates

Those three repository definitions are the ones Fedora itself ships in the fedora-repos package. No third-party repository is preloaded. fedora-cisco-openh264 is a Fedora shipped definition pointing at Cisco's freely redistributable H.264 builds, and nothing from it is installed.

Apply updates yourself at any time with:

sudo dnf upgrade --refresh

Automatic updates

This image installs dnf5-plugin-automatic and enables its timer, which the stock Fedora Cloud Base image does not:

systemctl is-enabled dnf5-automatic.timer && systemctl list-timers dnf5-automatic.timer --no-pager

enabled NEXT LEFT LAST PASSED UNIT ACTIVATES Tue 2026-09-15 06:09:06 UTC 3h 58min Tue 2026-09-15 01:03:12 UTC - dnf5-automatic.timer dnf5-automatic.service 1 timers listed.

The unit runs daily at 06:00 with a randomised delay of up to an hour, so a fleet booted from this image does not all hit the mirrors at once. The policy it applies is in /etc/dnf/automatic.conf:

cat /etc/dnf/automatic.conf

# sac: keep this Fedora Linux 44 Arm64 VM patching itself.
# Overrides /usr/share/dnf5/dnf5-plugins/automatic.conf (see dnf5-automatic(8)). [commands] apply_updates = yes upgrade_type = security download_updates = yes random_sleep = 300 reboot = never [emitters] emit_via = motd

Security updates are applied automatically. The machine never reboots itself, so a kernel update waits for a reboot that you schedule. To run the updater now, or to turn it off if your change control requires that:

sudo systemctl start dnf5-automatic.service
sudo systemctl disable --now dnf5-automatic.timer

Check whether a reboot is needed to activate what has been installed:

sudo dnf needs-restarting -r

Updating and loading repositories: Repositories loaded. No core libraries or services have been updated since boot-up. Reboot should not be necessary.

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

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

permitrootlogin prohibit-password passwordauthentication no kbdinteractiveauthentication no permitemptypasswords no

Those settings come from /etc/ssh/sshd_config.d/00-sac-hardening.conf, which sorts first and therefore wins, because sshd takes the first value it is given for each of these keywords.

Confirm the root account has no usable password:

sudo passwd -S root

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

The L is the part that matters: it shows the account is locked. The date is the epoch-derived last-change field left by waagent -deprovision and carries no meaning here.

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 4096 127.0.0.53%lo:53 0.0.0.0:* LISTEN 0 4096 127.0.0.54:53 0.0.0.0:* 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.54:53 0.0.0.0:* UNCONN 0 0 127.0.0.53%lo:53 0.0.0.0:* 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 127.0.0.53 and 127.0.0.54 sockets are systemd-resolved's DNS stubs, and the port 323 sockets are chrony's control interface. All of them are bound to the loopback address only, so they are not reachable from the network. On the stock Fedora image, this listing also shows 0.0.0.0:5355 and [::]:5355 for LLMNR, on both TCP and UDP.

Confirm the Azure Linux Agent is present and running:

waagent --version

WALinuxAgent-2.15.0.1 running on fedora 44 Python: 3.14.7 Goal state agent: 2.16.0.2

Confirm cloud-init completed cleanly:

cloud-init status --long

status: done extended_status: done boot_status_code: enabled-by-generator last_update: Thu, 01 Jan 1970 00:00:44 +0000 detail: DataSourceAzure [seed=/dev/sr0] errors: [] recoverable_errors: {}

You want extended_status: done rather than degraded. Next, check how long the machine took to boot:

systemd-analyze

Startup finished in 402ms (kernel) + 6.071s (initrd) + 38.281s (userspace) = 44.755s multi-user.target reached after 36.161s in userspace.

That is the first boot, which does one-off work that every later boot skips. It grows the root filesystem to the full disk, generates this machine's SSH host keys and systemd machine ID, and lets SELinux label the files those steps create. A subsequent reboot of the same machine reaches multi-user.target in about eight seconds.

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

chronyc tracking | head -6

Reference ID : 50484330 (PHC0) Stratum : 1 Ref time (UTC) : Tue Sep 15 02:10:55 2026 System time : 0.000005549 seconds fast of NTP time Last offset : +0.000005812 seconds RMS offset : 0.000006495 seconds

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, which is ttyAMA0 rather than the ttyS0 you would see on an x86 machine:

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

console=tty1 console=ttyAMA0,115200n8

No host firewall is installed or enabled on this image, because Fedora Cloud Base does not ship firewalld. 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 dnf install firewalld
sudo systemctl enable --now firewalld
sudo firewall-cmd --permanent --add-service=ssh sudo firewall-cmd --reload

Add the host 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 dnf, which on Fedora 44 is DNF 5:

sudo dnf install nginx

Search for a package, or find which package owns a file:

dnf search nginx
dnf provides /usr/bin/python3

If you are coming from Fedora 40 or from RHEL, note a few DNF 5 differences. dnf repoquery replaces several older query subcommands, dnf list --installed replaces dnf list installed, and dnf history output is laid out differently. dnf --help is accurate for the version installed.

Fedora carries a very large package set, and because releases are short-lived, those packages are recent. If you need a package that is not in Fedora's repositories, prefer a container or a language-level package manager over a third-party repository. A third-party repository is the usual cause of a broken dnf system-upgrade later.

Fedora is upgraded in place, and you should plan to do this before 2 June 2027. The supported procedure is:

sudo dnf upgrade --refresh sudo dnf install dnf5-plugin-system-upgrade
sudo dnf system-upgrade download --releasever=45 sudo dnf system-upgrade reboot

The machine reboots, applies the upgrade offline and reboots again. On an Arm virtual machine of this size, that takes a few minutes. Take a snapshot of the operating system disk first, and read the Fedora release notes for the version you are moving to. Try the upgrade on a test machine before a production one.

Skipping more than two releases in one step is not supported. Go from 44 to 45, then from 45 to 46.