Oracle Linux 10 with GNOME Desktop on Azure User Guide

Overview

This guide covers the deployment and configuration of Oracle Linux 10 with the GNOME desktop on Microsoft Azure using cloudimg's pre configured virtual machine image from the Azure Marketplace.

Oracle Linux is Oracle's enterprise Linux distribution, binary compatible with Red Hat Enterprise Linux 10. Oracle publishes the binaries, updates and errata at no cost and permits redistribution, so there are no licence fees and no subscription is required to use, patch or resell it. This image is Oracle Linux 10 with the distribution's own desktop added: the AppStream environment group Oracle calls Server with GUI. It is reached with any RDP client through GNOME Remote Desktop in system mode, so you meet the GNOME login screen and sign in to a full desktop session running on the virtual machine.

Remote access here is first party. The RDP server is GNOME Remote Desktop from Oracle's own AppStream repository, so nothing outside the distribution is added to reach the desktop.

The image is built so that a freshly deployed machine exposes nothing but SSH. Remote desktop ships switched off, no account has a password, and nothing listens on the RDP port until you decide to turn it on. A desktop login always needs a password, so the image never ships one: you set your own over SSH, then enable remote desktop with a single command.

What's included:

• Oracle Linux 10 (10.2) on x86-64, binary compatible with RHEL 10, with every available update applied at build time
• Both kernels Oracle provides: the Unbreakable Enterprise Kernel (UEK), which boots by default, and the Red Hat Compatible Kernel, so you can switch if an application requires it
• The GNOME desktop from the Oracle Linux AppStream repository: GNOME Shell 49.4, the GDM 47 login screen, mutter 49.4 and gnome-settings-daemon 47.2
• Desktop applications from the same group: Files (Nautilus), the Ptyxis terminal, Firefox, Text Editor, Calculator, Camera, Software and System Monitor
• GNOME Remote Desktop 49.3 in system mode, which gives RDP remote login through the GNOME login screen
• A per-VM RDP credential and a per-VM self signed TLS certificate, generated at first boot and readable by root only
• cloudimg-remote-desktop, a small helper to show the remote desktop state, switch it on and off, and print your VM's RDP credential
• dnf-automatic armed to apply available updates, never rebooting on its own
• SELinux in enforcing mode and firewalld active, as Oracle ships them
• An LVM root layout with the root filesystem on rootlv in volume group rootvg, and a dedicated crashlv for kernel crash dumps
• Gen2 Hyper V virtual machine support
• 24/7 cloudimg support

The desktop is a Wayland session. RHEL 10 removed the Xorg server, so Oracle Linux 10 has no Xorg server to install; Xwayland 24.1.9 is present and runs X applications inside the Wayland session as normal.

Like every Oracle Linux image on Azure, this image uses an LVM root layout. That is a property of the image rather than an option: Oracle publishes only LVM rooted Oracle Linux SKUs. Step 12 documents the layout and how to grow it.

Platform: Microsoft Azure (Gen2 Hyper V, x86-64) Default user: azureuser

The two secrets, and which one goes where

This is the single thing worth reading twice. On a machine with remote desktop turned on there are two separate secrets, and both are unique to your virtual machine:

1. The per-VM RDP credential. Generated automatically at first boot into /root/cloudimg-remote-desktop-credentials.txt (mode 0600, root only). The username is your VM's own administrator account (the --admin-username you chose) and the password is 24 random alphanumeric characters. Your RDP client asks for this before the login screen is drawn, because GNOME Remote Desktop uses Network Level Authentication. It is not an operating system account and it cannot be used for SSH. Read it with sudo cloudimg-remote-desktop credentials.
2. Your account password. You set this yourself with sudo passwd <your-admin-user>. This is what the GNOME login screen asks for once Network Level Authentication has passed. The image ships with no account password at all, which is why you have to choose one.

Also generated per VM at first boot: a self signed RSA-3072 TLS certificate for the RDP server, with the VM's hostname as its common name. Its SHA-256 fingerprint is written into the same credentials file, so you can compare it with whatever your RDP client shows you.

Nothing above is baked into the image, and no two machines you launch share any of it.

Security posture

This image ships with no known credential:

• No account has a password. The root account is locked and your administrator account is created at first boot with only the SSH key you supply.
• SSH is key only (PasswordAuthentication no). Setting an account password for the desktop does not enable password logins over SSH.
• The remote desktop server is installed but disabled: a new virtual machine listens on SSH port 22 only, and 22 is the only port the listing advertises.
• At first boot the machine generates its own RDP credential and its own TLS certificate. Nothing is shared between two machines.
• Remote desktop cannot be switched on until an administrator account has a password, so the login screen is never exposed with nothing behind it.
• SSH host keys are removed before capture and regenerated on each machine at first boot, and /etc/machine-id is regenerated per machine, so no two machines share a host identity.
• SELinux is left in enforcing mode, the Oracle Linux default, and GDM automatic login is not enabled.
• The rpcbind portmapper ships enabled and listening on port 111 on the stock Oracle Linux cloud image. This image switches it off, so a new machine exposes port 22 and nothing else. It is still installed, and one command turns it back on (Step 11).
• firewalld is left active, as Oracle ships it and as every other cloudimg Oracle Linux image does. Its stale allowance for a console that is not installed has been removed, so the advertised firewall surface matches what is actually there.

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. An RDP client: Windows App or Remote Desktop Connection on Windows, Windows App on macOS, or Remmina or FreeRDP on Linux

Recommended VM Size: Standard_B2ms (2 vCPU, 8 GB RAM) or larger. GNOME's login screen plus a remote session does not fit in the 4 GB of Standard_B2s; for smooth everyday use pick Standard_D4s_v5 or larger. There is no GPU requirement, as the desktop renders in software.

Step 1: Deploy the Virtual Machine

Option A: Azure Portal

1. Navigate to the Azure Marketplace and search for "Oracle Linux 10 with GNOME Desktop 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_B2ms or larger
9. Under Administrator Account, select SSH public key and enter your key
10. Under Inbound Port Rules, allow SSH (port 22) only. You do not need to open port 3389: the recommended way to reach the desktop is through an SSH tunnel (Step 6)
11. Click Review + Create, then Create

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:oel-10-gui:default:latest

az vm create \
  --resource-group myResourceGroup \
  --name my-oracle-desktop \
  --image cloudimg1647283583153:oel-10-gui:default:latest \
  --size Standard_B2ms \
  --admin-username azureuser \
  --generate-ssh-keys \
  --public-ip-sku Standard

To start with a larger operating system disk, add --os-disk-size-gb 128 and follow Step 12 once the machine is up. The root filesystem is on a logical volume, so Azure's extra capacity is not claimed automatically.

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-oracle-desktop --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 and the desktop

Check that the machine is Oracle Linux 10, that it boots to the graphical target, that the GNOME login screen (GDM) is running, and which desktop packages are installed:

cat /etc/oracle-release
uname -srm
systemctl get-default
systemctl is-active gdm.service
rpm -q --qf '%{NAME} %{VERSION}\n' gdm gnome-shell gnome-settings-daemon mutter gnome-remote-desktop

Expected output:

Oracle Linux Server release 10.2
Linux 6.12.0-206.104.3.3.el10uek.x86_64 x86_64
graphical.target
active
gdm 47.0
gnome-shell 49.4
gnome-settings-daemon 47.2
mutter 49.4
gnome-remote-desktop 49.3

The desktop comes from the distribution's own environment group, not from a third party repository:

dnf group list --installed | grep -i 'Server with GUI' || true
echo "packages installed: $(rpm -qa | wc -l)"
df -h /

There is no Xorg server on Oracle Linux 10, because RHEL 10 removed it. The session is Wayland, and Xwayland runs X applications inside it:

rpm -q xorg-x11-server-Xorg || echo "(no Xorg server: Oracle Linux 10 GNOME is Wayland only)"
rpm -q --qf '%{NAME} %{VERSION}\n' xorg-x11-server-Xwayland

Step 4: Check that remote desktop is off

A new virtual machine has remote desktop switched off. The helper shows the whole picture in one command:

sudo cloudimg-remote-desktop status

The helper lives at /usr/local/sbin/cloudimg-remote-desktop. On Oracle Linux, sudo replaces your PATH with its own secure_path (/sbin:/bin:/usr/sbin:/usr/bin), which does not include /usr/local/sbin — so the image also ships /usr/sbin/cloudimg-remote-desktop as a symlink to it. The short form sudo cloudimg-remote-desktop status used throughout this guide therefore works, and so does the full path.

Expected output on a new VM (the fingerprint is unique to your machine):

remote desktop service: disabled / inactive
RDP backend: disabled
listening on 3389: no
per-VM RDP credential: generated (/root/cloudimg-remote-desktop-credentials.txt)
TLS certificate SHA-256: <the SHA-256 fingerprint of this VM's own certificate>
accounts able to log in at the GNOME login screen: none (set one with: sudo passwd <user>)

Confirm it from the network side as well:

sudo ss -tln | awk '$1=="LISTEN"{print $4}' | sort

0.0.0.0:22
[::]:22

SSH on port 22 is the only service reachable from outside the machine. Any other entry you see is bound to a loopback address (127.0.0.1 or ::1) and is not reachable from the network.

Step 5: Set your account password and turn remote desktop on

The GNOME login screen asks for your account password, and a new VM has none. Choose your own. Run this yourself on the VM and enter the new password twice when prompted:

sudo passwd azureuser

Your SSH access is unaffected: SSH remains key only, and this does not enable SSH password logins. Now switch remote desktop on:

sudo cloudimg-remote-desktop enable

Expected output:

remote desktop enabled: listening on port 3389
TLS certificate SHA-256: <the SHA-256 fingerprint of this VM's own certificate>
RDP credential: sudo cloudimg-remote-desktop credentials
safest route: ssh -L 3389:localhost:3389 <user>@<vm-ip>, then point your RDP client at localhost:3389
note: firewalld is active on this image. The SSH tunnel needs no firewall change;
      a DIRECT connection to 3389 needs the port opened in the Azure NSG AND in firewalld.

If no administrator account has a password yet, the helper refuses rather than opening a login screen with nothing behind it, and tells you exactly which command to run first:

refusing to enable remote desktop: no administrator account has a password yet,
so the GNOME login screen would have nothing to accept. Set your own first:
  sudo passwd azureuser

The setting survives reboots. Under the hood the helper runs grdctl --system rdp enable followed by systemctl enable --now gnome-remote-desktop.service, then waits until port 3389 is genuinely listening before it reports success.

Now print this VM's RDP credential, which you need in the next step:

sudo cloudimg-remote-desktop credentials

RDP_USERNAME=azureuser
RDP_PASSWORD=<24 random characters, generated at this VM's first boot>
RDP_PORT=3389
RDP_TLS_SHA256=<SHA-256 fingerprint of this VM's certificate>
RDP_TLS_SHA1=<SHA-1 fingerprint of the same certificate, shown as the thumbprint by Windows>

RDP_USERNAME is your own administrator account name, but RDP_PASSWORD is used by your RDP client only: it is not an operating system password and it does not work for SSH.

Step 6: Connect with your RDP client

Port 3389 is not open by default, and the SSH tunnel is the recommended route. It keeps RDP inside your existing SSH connection, so nothing new is exposed to the internet, and it needs no firewall change on either side. On your own workstation, open the tunnel and leave it running:

ssh -N -L 3389:localhost:3389 azureuser@<vm-ip>

Then point your RDP client at localhost:3389:

• Windows: Remote Desktop Connection (mstsc) or Windows App, computer localhost:3389
• macOS: Windows App, add a PC with the name localhost:3389
• Linux: Remmina (RDP), server localhost:3389, or FreeRDP 3 (xfreerdp on Oracle Linux and Fedora, xfreerdp3 on Debian and Ubuntu): xfreerdp /v:localhost:3389 /u:azureuser /gfx /bpp:32

When the client asks for credentials, enter RDP_USERNAME and RDP_PASSWORD from Step 5. This happens before any screen is drawn. On the first connection the client shows the server's certificate: it is self signed and unique to your VM, so compare its fingerprint with RDP_TLS_SHA256 (or RDP_TLS_SHA1, which is what Windows displays as the thumbprint) before you accept it.

The GNOME login screen then appears. Select your account and enter the password you set in Step 5, and the full desktop session opens.

If you prefer a direct connection instead of the tunnel, remember that firewalld is active on this image, so the port must be open in both places. From your workstation, allow 3389 in the network security group from your own public address only, never from the whole internet:

az network nsg rule create --resource-group myResourceGroup --nsg-name my-oracle-desktopNSG \
  --name allow-rdp-from-me --priority 1010 --access Allow --protocol Tcp \
  --direction Inbound --destination-port-ranges 3389 --source-address-prefixes <your-public-ip>/32

and then allow it in firewalld on the VM itself:

sudo firewall-cmd --permanent --add-port=3389/tcp
sudo firewall-cmd --reload

Step 7: Use the desktop

Open Activities, or press the Super key, to reach the application grid. The dock carries Files (Nautilus), Software, the Ptyxis terminal, Text Editor and Calculator; the grid adds Clocks, Settings, Camera, Characters, Firefox, ULN Registration and the Utilities and System folders. These are the applications the Server with GUI group installs — nothing is added on top of the distribution.

ULN Registration is Oracle's optional tool for registering the machine with the Unbreakable Linux Network, which is for customers who hold a paid Oracle Linux Support subscription. You do not need it: this image already receives its updates from Oracle's public repositories, with no registration and no account.

A terminal inside the session behaves exactly as your SSH session does, and your administrator account keeps its sudo rights. To confirm you are on a Wayland session, run this in Ptyxis inside the desktop:

echo "$XDG_SESSION_TYPE"

To add software, use dnf as on any Oracle Linux machine, for example sudo dnf install -y libreoffice, then open the application from the grid.

Disconnecting your RDP client leaves the session running on the VM; connect again and you return to it.

Step 8: Turn remote desktop off again

When you have finished, switch it back off. This closes port 3389 and keeps it closed across reboots:

sudo cloudimg-remote-desktop disable

remote desktop disabled: nothing listening on port 3389

sudo cloudimg-remote-desktop status shows the state at any time, whether the service is on or off.

Step 9: Verify the security posture

Confirm SELinux is enforcing, that SSH is key only, and that no account has a password until you set one:

getenforce
sudo sshd -T | grep -E '^(passwordauthentication|kbdinteractiveauthentication) '
sudo passwd -S root | awk '{print $1, $2}'
sudo awk -F: '$2 !~ /^[!*]/ && $2 != "" {n++} END {print "accounts with a password: " n+0}' /etc/shadow

Expected output on a new VM (after Step 5 the last line reads 1, your own account):

Enforcing
passwordauthentication no
kbdinteractiveauthentication no
root L
accounts with a password: 0

L in the second field means the root account is locked. The SSH policy is pinned by a drop in file, so a later package update to the main configuration cannot quietly loosen it:

grep -vE '^#' /etc/ssh/sshd_config.d/60-cloudimg-hardening.conf

PermitRootLogin prohibit-password
PasswordAuthentication no
KbdInteractiveAuthentication no
PermitEmptyPasswords no

Step 10: Patching and updates

Every available update was applied when this image was built, and dnf-automatic is armed so the machine applies updates on its own schedule:

systemctl is-enabled dnf-automatic.timer
grep -E '^(upgrade_type|download_updates|apply_updates) ' /etc/dnf/automatic.conf

Expected output:

enabled
upgrade_type = default
download_updates = yes
apply_updates = yes

Updates are applied, not merely downloaded. upgrade_type is default rather than security deliberately: a security only policy resolves against errata metadata and silently applies nothing for any update that does not carry it, so this image applies the full set. Check whether anything is pending yourself at any time:

dnf -q check-update >/dev/null 2>&1; echo "exit=$? (0 = nothing pending, 100 = updates available)"

Automatic updates never restart the machine for you, so check whether a restart is owed after a kernel update and pick your own window:

dnf needs-restarting -r || true

You can always update on your own schedule with sudo dnf -y upgrade, and reboot if a new kernel was installed. To opt out of the automatic updates entirely, run sudo systemctl disable --now dnf-automatic.timer.

This image boots the Unbreakable Enterprise Kernel by default and also carries the Red Hat Compatible Kernel. Both lines are kept patched by the same update path.

Step 11: Networking, the firewall, and services that ship switched off

The Azure Network Security Group is the outer firewall for this image, and firewalld is the host firewall inside it. Both are enforced, so a port you open for a direct connection must be open in both.

Several daemons are switched off in this image. rpcbind arrives enabled on the Oracle Linux cloud base itself — the stock base leaves it listening on port 111 — and Cockpit, Avahi, CUPS and Bluetooth arrive with the Server with GUI group. All of them are left installed but disabled, never masked, so the image exposes only port 22 and you can turn any of them back on with a single command:

for u in cockpit.socket avahi-daemon.service cups.service bluetooth.service rpcbind.socket; do
  echo "$u: $(systemctl is-enabled "$u" 2>/dev/null || true)"
done

cockpit.socket: disabled
avahi-daemon.service: disabled
cups.service: disabled
bluetooth.service: disabled
rpcbind.socket: disabled

To enable any of them, for example the Cockpit web console, run sudo systemctl enable --now cockpit.socket and open the port in your Network Security Group and in firewalld.

firewalld itself is left active and enabled, as Oracle ships it and as every other cloudimg Oracle Linux image does:

systemctl is-active firewalld
sudo firewall-cmd --list-services

active
dhcpv6-client ssh

The network stack is NetworkManager, the native enterprise Linux stack, configured by cloud-init exactly as on Oracle Linux Server. The desktop adds no second network stack.

Step 12: The LVM disk layout, and growing it

Like every Oracle Linux image on Azure, this image uses an LVM root layout: the root filesystem sits on a logical volume inside volume group rootvg, alongside a dedicated crashlv for kernel crash dumps. The /boot and EFI partitions stay as plain partitions, which is what the firmware and boot loader need.

findmnt -no SOURCE,FSTYPE /
sudo vgs
sudo lvs

Because the root filesystem is on a logical volume, cloud-init does not extend it automatically when you provision a larger operating system disk. Growing it is three standard commands. First find the disk and partition that carries the LVM physical volume:

sudo pvs -o pv_name,vg_name --noheadings
lsblk -o NAME,SIZE,TYPE,FSTYPE,MOUNTPOINT

The physical volume is partition 4 of the operating system disk. With that name in hand, grow the partition, make LVM see the extra space, then extend the logical volume and its XFS filesystem in one step:

sudo growpart /dev/sda 4
sudo pvresize /dev/sda4
sudo lvextend -r -l +100%FREE /dev/rootvg/rootlv

Substitute the disk name you saw in lsblk if it is not /dev/sda. Confirm the result:

df -h /

Adding a separate data volume instead is the ordinary LVM path: attach an Azure data disk, pvcreate it, vgextend rootvg onto it, then lvcreate a new volume or lvextend an existing one.

Verify what you are running

Three commands answer the three questions that matter: which release this is, that it is a desktop image, and whether remote desktop is currently on.

cat /etc/oracle-release
systemctl get-default
sudo cloudimg-remote-desktop status

Common Use Cases

• A cloud workstation for enterprise Linux development with a full GNOME desktop, reachable from any RDP client
• Running graphical administration and data tools close to your Azure resources
• A RHEL 10 compatible desktop for testing applications certified against RHEL, without a subscription
• Training labs and demonstrations that need a desktop rather than a shell
• A secure jump desktop, reachable only through an SSH tunnel

Troubleshooting

The RDP client connects, then the screen stays black or it disconnects

GNOME Remote Desktop requires the RDP graphics pipeline. Current clients support it: Windows App, Remote Desktop Connection (mstsc), Windows App on macOS and Remmina are all fine. With FreeRDP you must pass /gfx /bpp:32; without those flags the server closes the connection after authentication. Read the server side with:

sudo journalctl -u gnome-remote-desktop --no-pager -n 20

Do not remove module_blacklist=hyperv_fb from the kernel command line

The image boots with module_blacklist=hyperv_fb. This is load bearing on Azure and it is why the desktop works at all. Two drivers can claim the Hyper-V synthetic video device: the legacy framebuffer driver hyperv_fb and the modern DRM driver hyperv_drm. If hyperv_fb claims it first there is no DRM device, GNOME Shell reports "No GPUs found", and the login screen never appears even though gdm.service still looks active. Keeping the module blacklisted lets hyperv_drm bind and provide the display.

It is set on every installed kernel and in /etc/kernel/cmdline, so kernels you install later inherit it. Check it with:

grep -o 'module_blacklist=hyperv_fb' /proc/cmdline
ls /dev/dri

If you ever remove it and lose the login screen, add it back with sudo grubby --update-kernel=ALL --args="module_blacklist=hyperv_fb" and reboot.

"Connection refused" on localhost:3389

Remote desktop is disabled on a fresh VM by design. Run sudo cloudimg-remote-desktop enable first, and check the SSH tunnel is still up in its own terminal window. sudo cloudimg-remote-desktop status tells you whether anything is listening on 3389.

The login screen appears but rejects my password

That screen wants your account password, the one you set with sudo passwd <your-user>, not the RDP credential. The RDP credential was already used, before the screen was drawn. If you have not set an account password yet, set it over SSH and try again.

My RDP client says the credentials are wrong before any screen appears

That is the opposite case: the client wants the RDP credential from sudo cloudimg-remote-desktop credentials, not your account password.

A certificate warning on the first connection

Expected. The TLS certificate is self signed and unique to your virtual machine, generated at its first boot with the VM's hostname as its common name. Verify the SHA-256 fingerprint your client shows against RDP_TLS_SHA256 from sudo cloudimg-remote-desktop credentials (Windows shows the SHA-1 value as the thumbprint), then accept it.

A direct connection to 3389 times out, but the SSH tunnel works

firewalld is active on this image. A direct connection needs 3389 open in the Azure Network Security Group and in firewalld (Step 6). The SSH tunnel needs neither.

Cannot connect via SSH

1. Verify the VM is in Running state in the Azure Portal
2. Check that port 22 is allowed in the Network Security Group
3. Ensure you are using the administrator username you named at create time
4. Verify your SSH key matches the one you supplied at create time. Password login over SSH is disabled by design, so a password prompt means key negotiation already failed.

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 </dev/null 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

Oracle Linux is free and open source, and Oracle explicitly permits redistribution: Oracle provides the binaries, updates and errata at no cost, and a paid Oracle Linux Support subscription is optional and is not required to use, patch or resell the operating system. This is not Oracle Database and carries no Oracle Database licensing.

The distribution is not covered by a single licence: it is a collection of thousands of independently packaged components, each carrying its own terms, predominantly GPL and LGPL, with MIT, BSD, Apache 2.0, MPL and others. The GNOME desktop, GDM and GNOME Remote Desktop are free software packaged in the Oracle Linux AppStream repository. Every package's terms are readable on the machine with rpm -qi <package> and under /usr/share/licenses/.

Oracle Linux 10 is not an end of life product. It reached general availability in June 2025, with Premier Support until June 2030 and Extended Support until June 2035. Check Oracle's lifetime support policy for the dates that apply to your deployment.

Oracle and Oracle Linux are trademarks of Oracle Corporation, and GNOME is a trademark of the GNOME Foundation. Both names are used here nominatively, only to identify the distribution and the desktop environment this image contains. cloudimg is not affiliated with, endorsed by or sponsored by Oracle Corporation or the GNOME Foundation.

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