How-To: Ubuntu Server Installation Explained Step by Step

Introduction and Video Overview

Hello everyone, and welcome to the Techaptic channel. Today we are going to install Ubuntu Server 26.04 LTS, which is currently the latest version of Ubuntu Server. The goal of this video is not to perform a standard installation by simply clicking Next, Next. We will move forward by explaining what we are doing and why we are doing it.

Especially during critical configuration steps such as network and storage, we will talk in detail about what the available options actually do, some common misconceptions in the industry, and which settings make sense in different scenarios. By the end of this video, you should be able to approach your future Ubuntu Server installations with much more informed decisions and configure your infrastructure according to your actual needs. If you’re ready, let’s get started.

Ubuntu Server vs Desktop and LTS Releases

As you know, Ubuntu is an open-source operating system backed by a large community. The two editions we come across most often are Server and Desktop. Contrary to what some people think, the Server edition is not a paid edition, and it uses packages from the same Ubuntu ecosystem as Desktop.

The main difference is that Ubuntu Server gives us a more minimal, text-based starting point focused on server services. When we look at it this way, we can deploy server workloads on either edition. But since we want to build a foundation for future videos on topics such as Nginx, Docker, and Kubernetes, we will use Ubuntu Server instead of starting with a desktop environment.

We will also install an LTS release, which stands for Long Term Support. Ubuntu releases an LTS version every two years, and it allows us to receive five years of standard security updates for packages in the main repository. Especially in production environments, this gives us a longer and more predictable lifecycle.

Virtual Machine Resources and UEFI

Now let’s move on to the installation settings. In this video, we will install Ubuntu Server on a virtual machine. For this environment, I have assigned two vCPUs, 4 GB of memory, and a 40 GB disk. I’m not saying these are production specifications, because hardware requirements can change from one environment and workload to another.

Canonical’s basic installation guide even shows that we can start with lower resources. But our goal here is to demonstrate the installation settings and explain when our choices may need to change, so I went with a moderate resource configuration.

I already created the virtual machine template, but before we start, I’m going to make one small change. The template uses BIOS as the default firmware type, and we will change that to UEFI. We are not choosing UEFI simply because it is faster, but because it is a more commonly used firmware and boot interface on modern systems compared with Legacy BIOS. After this change, we can move on to the installation.

Installation Start: Language and Keyboard

We will select Try or Install Ubuntu Server. On the welcome screen, the system asks us to choose the installation language. I will continue in English. We can use the up and down arrow keys to select the language and continue.

On the Keyboard Configuration screen, we are asked which keyboard layout should be used when we enter characters. In my environment, I will select Turkish as the keyboard layout and continue.

Ubuntu Server vs Minimized Installation

With this screen, we are starting to see settings where we need to make more meaningful choices. First, we need to understand the difference between the standard Ubuntu Server option and the Minimized option. Minimized starts with a smaller software set and can be preferred especially in environments where users are not expected to log in regularly. The normal Ubuntu Server option includes the standard packages and provides a more comfortable operating system experience.

If your goal is to start with an operating system that has as few packages as possible and install the packages or services you need one by one, you can continue with the Minimized option. Starting with fewer packages can make the initial system lighter, but it can also create additional operational work. You should choose the installation type based on your needs. In our example, we do not have a special requirement like that, so we will continue with the standard Ubuntu Server option.

Third-Party Drivers

At the bottom of the page, there is also an option to search for third-party drivers. These are generally additional vendor drivers that Ubuntu may provide for certain hardware. For example, on a physical system, some hardware may require these types of drivers, and the installer can search for them at this stage.

Since we do not need any special hardware drivers for this virtual machine, we will skip this part and continue.

Network: Netplan, DHCP, Static IP, VLAN and Bonding

Now we are on the network configuration settings. Ubuntu Server uses Netplan for network configuration, which allows us to manage basic settings such as DHCP, static IP addressing, and VLANs. On this screen, we can see that the installer detected our virtual network adapter and received an IP address through DHCP.

If we want to configure a static IP address, we can open the NIC settings and edit the IPv4 configuration. We can also define a VLAN tag if needed. There is also a Create Bond option. If you have multiple interfaces in your environment, bonding allows you to use them under a single logical interface for purposes such as redundancy or link aggregation.

In our example, we do not need any of these changes, so we will keep the default settings and continue.

Proxy Server Settings

On this screen, we have the proxy server settings that can be used to access package repositories or the Snap Store, which hosts the Snap applications we will see later. We do not have a proxy server in this environment, so we will leave this field empty and continue.

Ubuntu Archive and Mirror Settings

On this screen, we have the mirror settings for the Ubuntu Archive. You can think of the Ubuntu Archive as the repository source from which Ubuntu packages are downloaded. Because these resources are available from different regions, it is generally more appropriate for a server to download packages from a source that is closer to it.

That is why the Ubuntu Archive has multiple addresses, and we call them mirrors. In some large organizations, this address may also point to a central repository where the organization keeps these packages internally.

If you want the system to use a specific source address, you can change it at the top, or you can continue with the default address. If you change it, I recommend choosing a location that you have confirmed is reachable based on the test results. We will continue with the default address here.

Storage Basics: Disk, Partition, File System and Mount Point

Now we have reached one of the most important topics: storage configuration. To shape this correctly for different requirements, we first need to briefly explain a few concepts and how they work.

Let’s start with the classic disk structure in Linux. We can summarize it like this: first the disk, then partitions, then file systems, and then mount points. Let me explain these concepts using a plot-of-land analogy.

We can think of the disk as the physical or virtual disk we already know. In this analogy, it represents the entire plot of land. A partition is an area whose boundaries we define on that disk. You can think of partitions as the individual parcels into which the land is divided.

But creating a partition by itself is not enough to store files. We also need a structure that defines how files and directories are stored inside that area. This is the file system. You can think of a file system as an organizational plan that defines how the roads, sections, and other parts inside that parcel are arranged. Just as we use NTFS or FAT32 on Windows, on Linux we use file systems such as EXT4 or XFS.

There is an important difference on the Linux side. Instead of showing partitions as separate drive letters like Windows does, Linux uses them inside a single directory tree. In our land analogy, you can think of this as an address system that lets us reach all the parcels and the sections inside them and tells us where everything is.

Let me update the diagram to explain this better. At the top of the directory tree, we have the root directory. Directories such as `/var`, `/home`, and `/boot` are under the root directory, and there can be many more subdirectories below them. For example, `/home` is where user files are stored, while `/var` is commonly used for logs and some application data.

So how do the file systems we create connect to this directory tree? During installation, the main file system used by the operating system is attached to the root directory, which is why we generally call it the root file system.

One of the concepts that can be confusing here is the difference between a directory and a file system. A directory represents a location inside the directory tree, while a file system is the structure that defines how files and directories are stored on the storage area. Connecting a file system to a directory inside the directory tree is called mounting, and the directory it is attached to is called the mount point.

For example, the root file system is mounted to the `/` directory. The same idea can be applied to directories such as `/home`, `/var`, or `/boot`. If we mount a separate file system to one of these directories, that directory becomes the mount point for that file system. This is why, in practice, you may hear expressions such as “var file system” or “home file system.” What we mean is not that the `/var` or `/home` directory itself becomes a file system, but that a separate file system is mounted to that directory.

This distinction becomes especially important when we talk about capacity management. For example, if we did not create a separate file system for `/var` or `/home`, the data in those directories is stored on the root file system, and they share the same capacity. Let’s say we have a 100 GB root file system and a service running under `/var` generates 95 GB of data. In that case, it is not only `/var` that is almost full; the root file system itself is almost full.

If we had created a separate partition for `/var`, created a separate file system on it, and mounted it to the `/var` directory, `/var` would still be a directory, but this time we would have separated its capacity usage from the root file system.

Linux File Systems: EXT4, XFS and Btrfs

Separating capacity is not the only reason to use separate file systems. Depending on the requirement, we may also want to use the features of different file systems. For example, EXT4 is a widely used general-purpose file system on Linux, while XFS is strong and scalable, especially for large files and high I/O workloads.

There is also Btrfs, or B-tree file system. It is a modern file system that provides features such as snapshots and copy-on-write, among others. So what can we do if we want to manage these storage areas more flexibly?

LVM Explained: PV, VG and LV

At this point, we can go one step further and talk about LVM, which stands for Logical Volume Manager. The way LVM works is very similar to a storage pool in storage systems. In other words, we can logically group the capacity of disks or partitions and manage that capacity more flexibly.

To fully understand LVM, we need to know three basic concepts: PV, or Physical Volume; VG, or Volume Group; and LV, or Logical Volume.

A Physical Volume provides the storage capacity that LVM will use. We can define disks or partitions as PVs and combine one or more PVs to create a Volume Group. We can compare the Volume Group to a storage pool in storage systems. Logical Volumes, or LVs, can be compared to classical partitions.

By creating LVs inside a Volume Group, we get logical storage areas, and we can create file systems such as EXT4 or XFS on top of them. In a classic structure, we create a file system on a partition and attach it to a mount point. When we use LVM, the Physical Volume, Volume Group, and Logical Volume layers are added before the file system. After that, we still create a file system on the Logical Volume and mount it to the directory we want.

Let’s use an example to make this clearer. Assume that we have a 100 GB Volume Group. We can allocate 30 GB to a `root LV`, allocate another 20 GB to a `var LV`, and leave the remaining 50 GB free in the VG.

If we later need more capacity in one of these areas, we can increase the size of the related Logical Volume using the free space in the Volume Group and then expand the file system on top of it. The purpose of using LVM here is not to get a faster disk. The main goal is to manage the available space more flexibly and make it easier to expand later when needed.

Guided LVM and Scaled Sizing

Now that we have covered the theory, let’s go back to the user interface and see how these concepts appear in the installer. In our example, we will continue with Use an entire disk and Set up this disk as an LVM group. These options tell the system to use the entire disk and automatically create the LVM structure.

Now let’s see what kind of layout this gives us. At the top of the summary page, we can see three mount points: `/`, `/boot`, and `/boot/efi`. Both the root and `/boot` file systems use EXT4, but they are two separate file systems created on different storage areas. This means the space used by the `/boot` file system does not consume the free space of the root file system.

Because we started the server in UEFI mode, we can also see the EFI partition, which contains the boot files used to start the operating system. It is mounted to the `/boot/efi` directory.

In the middle of the page, we can see that a Volume Group called `ubuntu-vg` will be created with a capacity of about 37 GB. Notice that it also shows approximately 18.5 GB of free space. This is because the installer has not assigned all the available space in the Volume Group to the root Logical Volume.

The reason for this is scaled sizing, which is the sizing policy Ubuntu’s installer uses for Guided LVM. This policy automatically determines how much space is assigned to root based on the available capacity in the Volume Group. When the available space is below 10 GB, it gives all the remaining space to root. Between 10 and 20 GB, it assigns 10 GB to root. Between 20 and 200 GB, as in our example, it assigns roughly half. When the available Volume Group space is above 200 GB, it assigns 100 GB to root.

The remaining space is not lost. We can later use it for a new Logical Volume or snapshot space if needed. Finally, at the bottom of the page, we can see details about the devices, partitions, and file systems that will be used.

Custom Storage Layout and Manual Partitioning

Now let’s also look at where we can configure these settings manually. We will go back to the previous screen and select Custom Storage Layout.

First, the system shows us information about the disks available to us. Here we have a disk called `/dev/sda` with about 40 GB of free space. If we want to create additional partitions on this disk, format them, and use different mount points, we can select the free space area, choose Add GPT Partition, and enter the required information. We can also define the partition size and select the file system we want to use.

When defining partition sizes, we should remember that every partition we create takes space from the total disk capacity, so it is better to plan the layout in advance. Under the format options, we can also see the file systems we discussed earlier.

Linux Swap: What It Is and How to Size It

There is also a swap option under the format settings, so I want to briefly talk about swap. First of all, swap is not a file system. When Linux experiences memory pressure, it can move some memory pages to swap areas on disk, which can help reduce pressure on RAM.

Of course, disk-based storage is much slower than RAM, so we should not think of swap as additional RAM. Also, contrary to a common misconception, there is no universal rule that says the swap size must be twice the amount of RAM. The appropriate size depends on factors such as the amount of RAM assigned to the system, hibernation requirements, and the workload in the environment.

Coming back to our storage configuration, if we create these partitions without LVM, we are building a classic disk layout. If we want to use LVM, we first create a Volume Group and then create the Logical Volumes inside it. After that, we can format those LVs with the file system we want and attach them to the appropriate mount points.

LUKS Disk Encryption

The installer also gives us the option to encrypt the LVM group using LUKS. LUKS stands for Linux Unified Key Setup. It is one of the standard mechanisms used for block device encryption on Linux and provides data-at-rest protection against directly reading the data on the disk while the system is powered off.

In other words, if the server is running, the encrypted area is already unlocked, and an attacker gains sufficient privileges on the system, LUKS does not protect the data from that access. This is very similar in concept to BitLocker on Windows, but they are different technologies.

If we use LUKS with a passphrase, the encrypted area has to be manually unlocked when the system starts after a reboot. This is something we need to consider operationally, especially for remotely managed servers or systems that may need to be rebooted.

To wrap up this part, we can configure our disks either with a classic disk structure or by using the additional flexibility that LVM provides, and then prepare the system for installation. I am going to return to the previous menu and continue with the settings I consider appropriate. Since I am not going to use encryption, I will leave Encrypt the LVM group with LUKS unchecked and continue. The installer warns us that the data on the disk will be erased. We can accept that and continue.

Hostname, User Account and sudo Privileges

On this page, we will enter the user account information and the server name. In the Your Name field, we can enter information similar to the display name concept in Windows. In my example, I will enter Melih Cinar. For the Server Name, I am entering `srv-ubuntu-01`. Then we define the username we want to use and specify a password for the account.

The user account we create during installation will be an administrative account with sudo privileges. In Ubuntu, the root account cannot log in directly with a password by default, but we can log in with this user and perform administrative tasks with sudo when needed. Let’s save this and move on to the next setting.

Ubuntu Pro, ESM and Livepatch

On this screen, we are asked whether we want to use Ubuntu Pro. Ubuntu Pro is an optional service. It has paid plans, but there is also a free plan for personal use.

An Ubuntu LTS release already includes five years of standard security maintenance. Ubuntu Pro can extend the security maintenance period through ESM, or Expanded Security Maintenance, and it also provides additional features such as Livepatch and a broader set of security options. If your environment needs this kind of support and feature set, you can continue with Ubuntu Pro. In our environment, we do not need it right now, so we will continue with the Skip for now option.

OpenSSH Server and SSH Authentication

On this screen, we can see the SSH configuration settings for the server. By default, Ubuntu Server does not have an enabled service accepting remote SSH connections. If we want to connect to this server over SSH, we need to install OpenSSH Server.

Being able to connect to and manage our servers remotely is generally something we want, so we will enable the Install OpenSSH Server option. The installer also gives us two basic authentication approaches for SSH: password authentication and SSH key authentication.

SSH key authentication uses a key pair that we call a Private Key and a Public Key. We can explain this with a lock-and-key analogy. The lock, which is the Public Key, is on the server, while the Private Key stays with the person or system making the connection. When the server verifies that we have the correct Private Key, authentication is completed. The important point is that the Private Key is not sent to the server; it stays only on the side making the connection.

In this video, we are not configuring SSH keys, so we will continue with password authentication. As you can see, Allow password authentication over SSH is automatically enabled. If we already had an SSH key in our environment, we could import the required Public Key from the Import SSH Key section. In that case, the system would disable password authentication over SSH by default. Of course, this behavior can be changed later if needed. Let’s continue.

Featured Server Snaps

Now we have reached the last page before the installation begins: Featured Server Snaps. This page lists some Snap packages that can be useful in server environments. Snap is one of the application packaging and distribution methods in the Ubuntu ecosystem, and these packages are completely optional.

Installation Completion, Reboot and First Login

We do not need any of these packages in our environment, so we will leave everything unselected and start the installation. The installation time depends on the resources assigned to the system, but unless you have given it very limited resources, it usually does not take too long.

The installation is complete, so now let’s restart the computer. Before we continue, the system asks us to remove the ISO file we attached. Let’s make the necessary change and press Enter.

When the system starts, it asks us for the username at the login screen. Let’s enter the account information and confirm that we can log in successfully. Yes, everything looks fine here. With this final check, we have reached the end of this video. Thank you for watching, and see you next time. Bye.