How to do an fully automated Ubuntu 20.04 Server install using PXE and the live server image?
Reason
With the 20.04 release, it seems clear Ubuntu is further pushing the live server installer (subiquity) option. The debian-installer (d-i) image has been renamed legacy. So has the netboot installer I typically prefer. The 20.04 release also introduces a new automated installation option for the live server installer.
Fully Automated Ubuntu 20.04 server install using PXE
These are steps to do a fully automated Ubuntu 20.04 Server install using PXE with the live server image. I found the process to be lightly documented and filled with issues. In these steps I am installing 20.04 on a UEFI based server.
edit: these steps were adapted for a BIOS based server at Deploy Ubuntu 20.04 on bare metal or virtualbox VM by pxelinux, cloud-init doesn't pick up user-data file
edit: these steps were created specifically for the
20.04
release of Ubuntu (subiquity 20.04.3
). The version ofsubiquity
changes with each release. E.g. the20.04.3
release of Ubuntu hassubiquity 21.08.2
. Because of the active development ofsubiquity
some of the information in this post is not completely accurate for newer releases.There are many variations to these steps possible. They can be customized and tailored to suit one's needs. The goal is to provide one example of how to accomplish this and to help other users overcome the issues encountered.
links about the installer
config references
source code
Build a tftp server
All the following steps are run as root. These were tested on an Ubuntu 18.04 server.
Install the tftp server and a web server
Configure apache to serve files from the tftp directory
Download the live server iso
Extract the kernel and initramfs from the live server iso
Download the grub image to load via PXE
Configure grub. This configuration will provide a fully automated boot option as well as a manual boot option
Configure cloud-init with the autoinstall configuration. I first ran the install manually to get the generated
/var/log/installer/autoinstall-user-data
file to use as the basis. I then made modifications based on my needs and errors encountered.Configure DHCP
Set the DHCP Options 66,67 according to the documentation for your DHCP server.
Boot your server
At this point, you should be able to boot your UEFI based server and perform a completely automatic install.
Errors encountered
cloud-config-url=/dev/null
kernel argument will preventcloud-init
from unnecessarily downloading the iso, which reduces the memory required, reduces network traffic, and speeds up boot time./var/log/installer/autoinstall-user-data
file was broken in the following waysversion
property, which caused a validation failure. I added the propertynetwork
section required another level of nesting. This bug is mentioned in the config referencepreserve
property on each item instorage
config
needed to be set to false. Otherwise curtin would not install on a blank diskkeyboard
propertytoggle
was set to null, which caused a validation failure. I simply removed the propertyreorder_uefi
. Luckily, subiquity happens to pass this configuration to curtinapt
config optiongeoip
doesn't seem to work. There were always logs for geoip requestssize: 512M
) resulted in the size being stored as a float, leading to errors when sizing LVM volumes as a percentage. Avoiding human readable values seems to fix thisOther missing features
I didn't dig into these as much. They are based on what my preseed files would do. Most of them could probably be fixed with clever use of
early-commands
,late-commands
, and cloud-init. I may have also missed somethingapt-cacher-ng
for apt, but it does not work as a general proxy. The installer assumes any proxy you configure is for everythinginteractive-sections
, but that results in 3 pauseslate-commands
, but I did not try it/run/kernel-meta-package
. This is hardcoded tolinux-generic
in the initramfs. I prefer to use thelinux-virtual
package for VMs. I was able to use the cloud-init configuration to overwrite the fileEdit 1
The resulting
/target/var/lib/cloud/seed/nocloud-net/user-data
file used by cloud-init during first boot. The replies indicate thelock-passwd
property has a typo and may affect some usersI set the timezone in the user-data file's 'user-data' section, and also set the root password there; like this: