Ubuntu Server Guide Changes, errors and bugs

type: mapping default: type: print which causes output on tty1 and any configured serial consoles can
be interactive: no
The installer supports reporting progress to a variety of destinations. Note that this section is ignored if
there are any interactive sections; it only applies to fully automated installs.
The config, and indeed the implementation, is 90% the same as that used by curtin.
Each key in the reporting mapping in the config defines a destination, where the type sub-key is one of:
The rsyslog reporter does not yet exist
• print: print progress information on tty1 and any configured serial console. There is no other config-
uration.
• rsyslog: report progress via rsyslog. The destination key specifies where to send output.
• webhook: report progress via POSTing JSON reports to a URL. Accepts the same configuration as
curtin.
• none: do not report progress. Only useful to inhibit the default output.
338

---

Examples:
The default configuration is:
Report to rsyslog:
Suppress the default output:
Report to a curtin-style webhook:
## user-data
type: mapping default: {} can be interactive: no
Provide cloud-init user-data which will be merged with the user-data the installer produces. If you supply
this, you don’t need to supply an identity section (but then it’s your responsibility to make sure that you
can log into the installed system!).
Netbooting the server installer on amd64
amd64 systems boot in either UEFI or legacy (“BIOS”) mode (many systems can be configured to boot
in either mode). The precise details depend on the system firmware, but both modes usually support the
PXE (“Preboot eXecution Environment”) specification, which allows the provisioning of a bootloader over
the network.
The process for network booting the live server installer is similar for both modes and goes like this:
1. The to-be-installed machine boots, and is directed to network boot.
2. The DHCP/bootp server tells the machine its network configuration and where to get the bootloader.
3. The machine’s firmware downloads the bootloader over tftp and executes it.
4. The bootloader downloads configuration, also over tftp, telling it where to download the kernel, ramdisk
and kernel command line to use.
5. The ramdisk looks at the kernel command line to learn how to configure the network and where to
download the server ISO from.
6. The ramdisk downloads the ISO and mounts it as a loop device.
7. From this point on the install follows the same path as if the ISO was on a local block device.
The difference between UEFI and legacy modes is that in UEFI mode the bootloader is a EFI executable,
signed so that is accepted by SecureBoot, and in legacy mode it is PXELINUX. Most DHCP/bootp servers
can be configured to serve the right bootloader to a particular machine.