Operating Systems Azure

Fedora Linux 44 Arm64 on Azure User Guide

Last updated: 2026-09-15 | Product: Fedora Linux 44 Arm64 on Azure

Overview

This guide covers the deployment and configuration of Fedora Linux 44 on 64-bit Arm (AArch64/arm64) on Microsoft Azure using cloudimg's pre configured virtual machine image from the Azure Marketplace.

Fedora Linux is the community distribution produced by the Fedora Project and sponsored by Red Hat, and it is where a great deal of enterprise Linux technology appears first. This is the native Arm build of Fedora Linux 44 Cloud Edition. It runs on Azure's Arm virtual machine sizes, which are powered by the Azure Cobalt 100 processor, where many workloads deliver the same performance at a lower cost than on x86.

What's included:

Fedora Linux 44 Cloud Edition, native 64-bit Arm (arm64 / AArch64) with the standard 4k page size kernel
Every available update applied at build time, and again immediately before capture
Automatic security updates installed, armed and enabled, so the machine keeps patching itself
Azure Linux Agent (waagent) and cloud-init for Azure integration
Chrony for NTP time synchronisation against the Azure host clock
SELinux in enforcing mode, the Fedora default
The fedora and updates repositories enabled and GPG checked, so your update path is intact
SSH as the only network listener, with no swap on the operating system disk
Gen2 Hyper V virtual machine support
24/7 cloudimg support

Platform: Microsoft Azure (Gen2 Hyper V, Arm64, Azure Cobalt 100) Default user: azureuser

Read this first: Fedora's support window is about 13 months

Fedora Linux is a fast moving distribution, and that is the point of it — recent kernels, recent compilers, recent runtimes. It is not a long term support distribution, and this listing does not pretend otherwise.

Fedora Linux 44 was released on 28 April 2026 and reaches end of life on 2 June 2027. That date comes from the Fedora Project's own release system, Bodhi, which records Fedora 44 as state: current, eol: 2027-06-02. After that date there are no further updates of any kind, including security updates.

Two things follow from that, and both are worth planning for before you deploy:

Plan the upgrade to Fedora 45 or 46 before June 2027. Fedora is upgraded in place with dnf system-upgrade; the procedure is in Step 9 below.
If you need a multi year support window, this is the wrong image. cloudimg publishes AlmaLinux, Rocky Linux and Oracle Linux Arm64 images with ten year enterprise lifecycles, and those are the right choice for a long lived production fleet.

One detail that will look like a contradiction if you go looking: the image's own /etc/os-release carries SUPPORT_END=2027-05-19. That value was baked into the Fedora 44 compose in April 2026 and is two weeks earlier than the date Bodhi now records. 2 June 2027 is the authoritative figure; treat the os-release field as an estimate frozen at build time.

This is Fedora Cloud Edition, on Arm

The base is Fedora Cloud Edition, which is the headless, server ready edition Fedora publishes for cloud platforms. It is not Fedora Server Edition, and this listing does not call itself "Fedora Server" for that reason. Everything you would expect of a server base is here; the one visible difference is that Fedora Server Edition's Cockpit web console is not pre installed. If you want it, sudo dnf install cockpit && sudo systemctl enable --now cockpit.socket is the whole job, and you would then open TCP 9090 in your Network Security Group.

Because this is the Arm build, it is a genuinely separate product from the x86 Fedora Linux image: it carries aarch64 packages and an aarch64 kernel, and it only runs on Arm virtual machine sizes. It uses a flat partition layout — a plain EFI system partition plus a root partition, with no LVM — and the standard 4k page size kernel.

A note on where this image comes from, because it matters. The Fedora Project publishes no official Fedora image to the Azure Marketplace, and every Fedora offer currently in the Marketplace comes from a third party repackager. This image is built from the Fedora Project's own official Azure disk image, downloaded from dl.fedoraproject.org, with its SHA-256 checked against Fedora's published checksum file and that checksum file's GPG signature verified against the Fedora 44 signing key. It therefore carries no Marketplace purchase plan of its own, and you do not need to accept any vendor terms beyond cloudimg's own to launch it.

What this image changes from the stock Fedora Cloud Base Arm image

Everything below was measured on the stock vendor image before it was changed, and every change is reversible in one command. Nothing is removed that you cannot put back.

Automatic security updates are installed and armed. The stock Fedora Cloud Base image has no automatic update mechanism at all. This image installs dnf5-plugin-automatic and enables its timer, configured to apply security updates daily and never to reboot on its own.
The zram swap device is removed. Fedora ships zram-generator-defaults, which creates a compressed swap device in RAM at boot — 7.7 GB of it on the size this image was built on. Azure image certification requires that a Marketplace image ship with no swap on the operating system disk, so the package is removed and an empty /etc/systemd/zram-generator.conf disables every zram device. Step 3 shows how to put it back if you want it.
LLMNR is switched off. The stock image's systemd-resolved binds Link Local Multicast Name Resolution on 0.0.0.0:5355 and [::]:5355, on both TCP and UDP. LLMNR is a well known name resolution spoofing vector and is useless on a cloud server, so it is disabled. That is what leaves SSH as the only port reachable from off the machine.
SSH is hardened by a drop in file that sorts ahead of every other SSH configuration file, so a later package update cannot quietly loosen it.

For the avoidance of doubt, three changes that cloudimg's Rocky Linux Arm images need are deliberately not made here, because the problems do not exist on this base: Fedora Cloud Base ships no Cockpit web console (so nothing listens on port 9090), no rpcbind (so nothing listens on port 111) and no rng-tools (so nothing fails at boot for want of a hardware random number generator). The port check in Step 5 proves the result either way.

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 and keyboard interactive authentication are disabled in the SSH daemon, so every login is by key.
PermitRootLogin is set to prohibit-password, so root can never log in with a password. No root key ships in the image, so in practice root has no SSH login at all until you add one deliberately. Use sudo from azureuser instead.
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 build account is deleted before capture, and the image is checked to confirm no account with a user ID of 1000 or above survives.
The only key that works is the public key you supply when you create the virtual machine. Azure injects it into the administrator account you name at first boot.
SELinux is left in enforcing mode, the Fedora default, and is pinned enforcing for the next boot.

Prerequisites

Before deploying this image, ensure you have:

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

Recommended VM Size: Standard_D2pds_v6 (2 vCPU, 8 GB RAM, 110 GB local NVMe, Azure Cobalt 100) or larger. This is an Arm64 image, so it must be launched on an Arm virtual machine size. An x86 size such as Standard_B2s will not accept this image.

Standard_D2ps_v6 is the same processor and memory without the local NVMe disk, and is the cheaper choice if you do not need ephemeral local storage. See Step 3 for what the local disk is and is not.

Step 1: Deploy the Virtual Machine

Option A: Azure Portal

Navigate to the Azure Marketplace and search for "Fedora Linux 44 Arm64 cloudimg"
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 this on your own workstation, substituting 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 cloudimg1647283583153:fedora-44-arm64:default:latest

az vm create \
  --resource-group myResourceGroup \
  --name my-fedora-44-arm64-vm \
  --image cloudimg1647283583153:fedora-44-arm64:default:latest \
  --size Standard_D2pds_v6 \
  --admin-username azureuser \
  --generate-ssh-keys \
  --public-ip-sku Standard

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

Step 2: Connect via SSH

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

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

Step 3: Confirm the release, the architecture and the disk

Confirm you have genuine 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 being reported as a subvolume path is normal for Fedora and is not a fault. So is the MOUNTPOINT shown against sda2: that one partition carries several btrfs subvolumes, lsblk prints only one of them, and which one it picks is arbitrary — /home here, /var on another boot. findmnt above is the authoritative answer for /. sr0 is the small virtual CD-ROM Azure attaches to pass provisioning data in. 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 will 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 wants swap back, the one line change is:

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 it exactly as Azure presents it — unformatted, unmounted and with /mnt empty — because 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 a build cache, a scratch database or temporary files, never for anything you need to 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, or a machine that comes back on a host where the disk has been re-provisioned will fail to boot. Sizes without the d, such as Standard_D2ps_v6, have no nvme0n1 at all and this section does not apply to them.

Step 4: Check the patch level and automatic updates

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

The image was fully updated immediately before capture, so a freshly launched machine should report nothing pending:

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 pre loaded. 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

# cloudimg: 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 you schedule. To run it 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.

Step 5: Verify the security posture

Confirm the effective SSH configuration. This 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 prohibit-password
passwordauthentication no
kbdinteractiveauthentication no
permitemptypasswords no

Those settings come from /etc/ssh/sshd_config.d/00-cloudimg-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: the account is locked. The date is just the epoch-derived last-change field left by waagent -deprovision; it carries no meaning here.

Confirm SELinux is enforcing:

getenforce

Enforcing

Confirm SSH is the only thing 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 would also show 0.0.0.0:5355 and [::]:5355 for LLMNR, on both TCP and UDP.

Step 6: Verify Azure integration

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: {}

extended_status: done rather than degraded is the result you want. 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 every later boot skips: growing the root filesystem to the full disk, generating this machine's SSH host keys and systemd machine ID, and letting 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 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

Step 7: Networking and the firewall

No host firewall is installed or enabled on this image — 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 prefer a host firewall as well, install one:

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

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

Step 8: Install software

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

A few DNF 5 differences worth knowing if you are coming from Fedora 40 or from RHEL: 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 adding a third party repository — a third party repository is the usual cause of a broken dnf system-upgrade later.

Step 9: Upgrading to the next Fedora release

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, read the Fedora release notes for the version you are moving to, and do it on a test machine before a production one. Skipping more than two releases in one step is not supported — go 44 to 45, then 45 to 46.

Common Use Cases

Development and test environments that need current toolchains on Arm
Validating software against packages heading for enterprise Linux
Build and test agents for software that ships aarch64 binaries or container images
Container and cloud native workloads on a recent kernel, on Azure Cobalt 100

Troubleshooting

Cannot connect via SSH

Check the Network Security Group allows inbound TCP 22 from your address, that the machine is running, and that you are using the private key matching the public key you supplied at create time. Password authentication is disabled by design, so a password prompt means the key was not offered.

The VM will not create, or will not boot

The most common cause is an x86 virtual machine size. This is an Arm64 image and only runs on Arm sizes such as Standard_D2pds_v6 or Standard_D2ps_v6. Confirm with uname -m, which must print aarch64.

Azure agent not running

sudo systemctl status waagent
sudo systemctl restart waagent

Package manager issues

Refresh the repository metadata first:

sudo dnf makecache --refresh

If a repository fails to refresh, confirm the machine has outbound internet access. If dnf reports that another process holds the lock, the automatic update timer may be running; wait for it to finish or stop it with sudo systemctl stop dnf5-automatic.service.

Disk is full

The root filesystem is btrfs. Check usage with df -h / and sudo btrfs filesystem usage /. Grow the operating system disk in the Azure portal, then extend the filesystem:

sudo btrfs filesystem resize max /

Do not use the local nvme0n1 disk for anything you need to keep — it is ephemeral.

A service is blocked and the logs mention SELinux

sudo ausearch -m AVC -ts recent

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.

The boot log mentions an I/O scheduler error on sr0

Reading the error level boot log is a sensible first move on any machine:

journalctl -p err -b --no-pager

On a freshly launched machine there is normally exactly one line, and it looks like this:

(udev-worker)[594]: sr0: /usr/lib/udev/rules.d/60-block-scheduler.rules:3 ATTR{queue/scheduler}="bfq": Failed to write "bfq" to sysfs attribute "queue/scheduler", ignoring: Device or resource busy

sr0 is the virtual CD-ROM that Azure attaches to pass provisioning data to the machine. udev tries to set the BFQ I/O scheduler on it, the kernel refuses because the device is in use, and udev says so and carries on — note the word ignoring. It is a host platform artefact on a read only virtual optical device, it has no effect on the machine, and it is safe to ignore.

The other line you are likely to see, within minutes of giving the machine a public IP address, is this one, usually many times over:

sshd-session[5593]: error: kex_exchange_identification: read: Connection reset by peer

That is an inbound connection from an internet SSH scanner that disconnected before completing the key exchange. It is a fact about the internet rather than about your machine, and it is the normal background noise of exposing port 22. If you would rather not see it, restrict the source address range on the Network Security Group rule for port 22 to the addresses you actually connect from.

Important Notes

Fedora Linux is free and open source. It is not covered by a single licence: the distribution is a collection of independently licensed packages. On this image, 441 installed packages carry 138 distinct licence strings, most commonly GPL-2.0-or-later, LGPL-2.1-or-later, MIT, GPL-3.0-or-later, BSD-3-Clause and Apache-2.0. You can read any package's terms with rpm -qi <package> or under /usr/share/licenses/. No subscription, entitlement or licence key is required, and no per seat cost applies.

Fedora and the Infinity design logo are trademarks of Red Hat, Inc. cloudimg is not affiliated with, endorsed by or sponsored by the Fedora Project or Red Hat, and uses the name only to identify the distribution this image contains. This image is not provided or supported by the Fedora Project; support for it comes from cloudimg. Everything installed in it comes from Fedora's own repositories. For the distribution itself, see fedoraproject.org.

Fedora Linux 44 was released on 28 April 2026 and reaches end of life on 2 June 2027, a supported life of about 13 months. Check the Fedora release schedule for the dates that apply to your deployment, and plan your dnf system-upgrade before support ends.

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