Install openSUSE on a home server: the first ten minutes

Which image to download

Get the image from get.opensuse.org: the offline (full) image for Leap 16, or the offline or network image for Tumbleweed. Check the SHA-256 checksum that is published next to it, then write it to a USB stick:

sha256sum openSUSE-*.iso                # compare with the .sha256 file
lsblk                                   # find the USB stick, e.g. /dev/sdb
sudo dd if=openSUSE-*.iso of=/dev/sdb bs=4M status=progress oflag=sync

dd needs root and overwrites the target without asking. Double-check the device name with lsblk: /dev/sda is usually your own disk.

Installer choices that matter later

Leap 16 installs with the new Agama installer; Tumbleweed images may still use the classic one. The screens differ, the decisions do not:

• Storage: keep btrfs with snapshots for the root file system. That is the whole point of the snapper rollback guide. Give root at least 40 GB; snapshots need room.
• Software: no desktop. Pick a minimal or server selection. A headless server has less to update and less to break.
• Users: create your own user and set a root password (or a root SSH key). The SSH guide covers how sudo works on openSUSE.
• SSH: enable the service and open the port in the firewall, or you will be walking to the server with a keyboard after the first reboot.

First boot: update, name, time

Log in (over SSH or on the console) and run these; everything with sudo needs root:

sudo zypper refresh
sudo zypper up                          # Leap: update to the latest patches
sudo zypper dup                         # Tumbleweed: move to the latest snapshot
sudo hostnamectl set-hostname homeserver
sudo timedatectl set-timezone Europe/Brussels
timedatectl                             # "System clock synchronized: yes"
sudo reboot                             # the first update often brings a new kernel

Why up on one and dup on the other is explained in the zypper updates guide. Pick your own time zone: timedatectl list-timezones lists them.

What the two checks look like on a machine that is set up right:

$ hostnamectl | grep -E 'Static hostname|Operating System|Kernel|Architecture'
 Static hostname: laptop
Operating System: openSUSE Tumbleweed
          Kernel: Linux 7.2.2-1-default
    Architecture: x86-64
$ timedatectl | head -7
               Local time: Mon 2026-09-28 06:36:27 CEST
           Universal time: Mon 2026-09-28 04:36:27 UTC
                 RTC time: Mon 2026-09-28 04:36:27
                Time zone: Europe/Brussels (CEST, +0200)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

A fixed IP address

A server needs an address that does not wander. The easiest way is a DHCP reservation in your router: the server keeps DHCP, the router always hands it the same address. If you prefer to set it on the server, NetworkManager does it with nmcli:

nmcli connection show                   # find the connection name, e.g. "enp1s0"
sudo nmcli connection modify enp1s0 \
  ipv4.method manual \
  ipv4.addresses 192.168.1.10/24 \
  ipv4.gateway 192.168.1.1 \
  ipv4.dns 192.168.1.1
sudo nmcli connection up enp1s0         # applies it; your SSH session may drop
ip -br address                          # check the new address

Do this from the console, or be ready to reconnect to the new address. What the /24 means is explained in the network basics guide.

A quick health check

systemctl --failed                      # should list 0 units
journalctl -b -p err                    # errors since this boot
sudo snapper list                       # snapshots exist, so rollback works
sudo btrfs filesystem usage /           # real free space on btrfs
cat /sys/kernel/security/lsm            # selinux or apparmor?

A few firmware or Bluetooth errors on a mini PC are normal; repeated errors from a service are not. The journalctl command builder helps you narrow the journal down to one unit or one time window. Next: users and SSH hardening.

Two of these on a real machine. findmnt proves the root runs from a snapshot, and systemctl --failed is rarely empty on a machine that has been in use for a while:

$ findmnt -t btrfs -o TARGET,SOURCE
TARGET                   SOURCE
/                        /dev/mapper/system-root[/@/.snapshots/1/snapshot]
├─/.snapshots            /dev/mapper/system-root[/@/.snapshots]
├─/boot/grub2/i386-pc    /dev/mapper/system-root[/@/boot/grub2/i386-pc]
├─/boot/grub2/x86_64-efi /dev/mapper/system-root[/@/boot/grub2/x86_64-efi]
├─/home                  /dev/mapper/system-root[/@/home]
├─/opt                   /dev/mapper/system-root[/@/opt]
├─/root                  /dev/mapper/system-root[/@/root]
├─/srv                   /dev/mapper/system-root[/@/srv]
├─/var                   /dev/mapper/system-root[/@/var]
└─/usr/local             /dev/mapper/system-root[/@/usr/local]

$ systemctl --failed --no-pager --no-legend
● vboxadd-service.service loaded failed failed Start/Stop VirtualBox Guest Linux module
● cockpit.socket          loaded failed failed Cockpit Web Service Socket

Look at each with systemctl status NAME. The Cockpit one is a real, fixable problem, explained in the Cockpit gotchas guide.

Frequently asked questions