Troubleshooting Automated Ubuntu Server ISO Installs with Cloud-Init

Setting up automated installations of Ubuntu Server using a USB stick and cloud-init’s NoCloud datasource can present a series of hurdles. This article outlines some of the issues encountered while attempting this process, focusing on potential pitfalls and observations that can aid in troubleshooting.

One initial point of friction arises from modifying system release files. Altering /etc/os-release or /etc/lsb-release can disrupt cloud-init’s ability to recognize devices labeled with cidata. It’s crucial to ensure that any modifications to these files are carefully reviewed for unintended whitespace or formatting issues by comparing them to a standard, unmodified system.

Another significant challenge lies in cloud-init’s path handling. The seedfrom kernel parameter, intended to point to the NoCloud data source, is susceptible to pathing errors. If the provided seedfrom value lacks a trailing directory separator, cloud-init may fail to correctly join it with filenames, leading to installation failures. The rationale behind cloud-init’s reliance on a directory for seedfrom in NoCloud setups remains unclear, especially given the limited audience for verbose output in such scenarios.

Furthermore, detecting a separate vfat volume labeled cidata for cloud-init data proved problematic. Workarounds involving embedding user-data and meta-data within a modified unsquashed filesystem, similar to methods described by covertsh and others, became necessary. However, even with this approach, inconsistencies emerged. While cloud-init appeared to recognize the datasource initially, as indicated by successful loading of variables from DataSourceNoCloud.py, the subiquity installer subsequently rejected the previously recognized seedfrom value, causing the installer to revert back to the live environment. The reasons behind this rejection are currently unknown.

The necessity for cloud-init to modify files within /var/lib/cloudinit and /run/cloudinit is also not immediately apparent. Understanding the timing and purpose of these write operations could significantly streamline the debugging process for similar issues.

As a workaround, a manual installation of the live server with the addition of ubuntu-desktop (excluding recommended packages) yielded a functional system, albeit lacking initial Wi-Fi support. Manually installing wpa_supplicant and its dependencies rectifies the Wi-Fi connectivity issue, albeit as an undesirable extra manual step after installation from the standard live server ISO.

The ultimate goal is to establish a local network service that offers custom Ubuntu Server Iso images for download. This would enable employees to easily create bootable USB drives for rapid base system deployment. This approach is preferred over netbooting, as physical USB drives are specifically desired for the deployment process, rather than direct network provisioning to the target machines.

Comments

No comments yet. Why don’t you start the discussion?

Leave a Reply

Your email address will not be published. Required fields are marked *