Ubuntu Server 24.04 Offline Installers Leave Network Unconfigured

Installing Ubuntu Server 24.04 LTS in an offline mode, meaning no network cable is connected and no WiFi is configured during the installation process, results in a system where network interfaces are left unmanaged. This oversight necessitates manual network configuration after the initial setup is complete. Specifically, the installation process fails to configure the network interface using systemd-networkd, and the service itself remains disabled. This leaves systems installed in this manner without any network connectivity out-of-the-box.

This issue primarily affects Ubuntu Server installations. Ubuntu Desktop typically utilizes NetworkManager, a different service that handles network configuration differently and would likely behave as expected. For server administrators and developers relying on offline installations for security, air-gapped environments, or controlled deployment scenarios, this presents an immediate post-installation hurdle.

Manual Network Configuration with Netplan

To resolve this missing network configuration, administrators must manually create a Netplan configuration file. Netplan is Ubuntu's default network configuration tool, which abstracts away the complexities of underlying network management daemons like systemd-networkd or NetworkManager.

Upon inspecting the /etc/netplan directory on a freshly installed offline Ubuntu Server 24.04 system, administrators will likely find that the directory is empty. This indicates that the installer did not generate any default network configuration profiles. The first step is to create a new Netplan configuration file. A common convention is to name this file sequentially, such as 01-netcfg.yaml, within the /etc/netplan directory. This can be done using a text editor like vim or nano:

sudo vim /etc/netplan/01-netcfg.yaml

Once the file is created, the next step is to populate it with the necessary network configuration details. The following YAML structure provides a basic template for configuring a static IP address. Administrators should replace the placeholder values with their specific network information.

network:
  version: 2
  renderer: networkd
  ethernets:
    enp4s0:
      dhcp4: no
      addresses: [192.168.1.100/24]
      gateway4: 192.168.1.1
      nameservers:
        addresses: [8.8.8.8, 8.8.4.4]

In this configuration:

  • network: version: 2 specifies the Netplan configuration schema version.
  • renderer: networkd explicitly tells Netplan to use systemd-networkd as the backend for managing network interfaces. This is crucial as the service was disabled during the offline installation.
  • ethernets: block defines configurations for Ethernet interfaces.
  • enp4s0: refers to the specific network interface name. This name can vary depending on the hardware; it's often found using commands like ip a or lshw -C network if the system has other interfaces or has been booted with a live environment. For a fresh install with only one NIC, it's often predictable but not guaranteed.
  • dhcp4: no disables DHCP for IPv4.
  • addresses: [192.168.1.100/24] sets a static IPv4 address and subnet mask. Administrators must use an IP address that is valid within their network and does not conflict with other devices. The /24 denotes the subnet mask (255.255.255.0).
  • gateway4: 192.168.1.1 sets the default IPv4 gateway.
  • nameservers: addresses: [8.8.8.8, 8.8.4.4] specifies the DNS servers to be used for name resolution. Google's public DNS servers are used here as an example.

After saving the configuration file, administrators must apply the changes using the netplan apply command. It's good practice to first test the configuration to catch any syntax errors:

sudo netplan try

The netplan try command applies the configuration temporarily and prompts the user to confirm within a timeout period. If the network becomes inaccessible, the configuration reverts. If confirmed, it becomes permanent. If netplan try reports errors or the network doesn't come up as expected, the user should revert to the previous state (which might involve a reboot if no direct access is available) and correct the .yaml file. If the try command is not used, or after successful confirmation, the permanent application is done via:

sudo netplan apply

This command will activate the newly defined network settings. After applying the configuration, it is advisable to verify network connectivity by pinging an external IP address or a known hostname:

ping 8.8.8.8

If the ping is successful, the manual network configuration has resolved the issue. If not, further troubleshooting of the .yaml file, interface name, IP address, gateway, and DNS settings is required.

Implications for Offline Deployments

The necessity of manual network configuration for offline Ubuntu Server 24.04 LTS installations highlights a potential gap in the installer's logic for air-gapped or network-unaware environments. While Netplan offers flexibility, requiring manual intervention for a fundamental service like networking adds an extra step to what is often a streamlined deployment process. For organizations that perform extensive offline deployments, this means either updating their deployment scripts to include Netplan configuration or ensuring that a network connection is available during installation, which may defeat the purpose of an offline setup.

The surprising detail here is not that an offline install might require some manual steps, but that the installer completely abdicates network configuration responsibility, leaving the systemd-networkd service disabled and the /etc/netplan directory empty. This is a significant departure from expected behavior for a server operating system designed for robust network management.

This situation prompts an open question: Will future Ubuntu Server LTS releases continue this behavior, or will the installer be updated to provide a default, albeit basic, network configuration even when no network is detected during installation? Understanding this will be crucial for IT professionals planning long-term deployment strategies with Ubuntu Server.