Please test autoinstalls for 20.04!

[mwhudson]

@jinxcappa

I myself am having issues. Im trying to use the autoinstall-user-data file that gets generated by the installer as a template. taking the file right after installation and attempting to use it as a config file for the same server fails in a couple areas.

First off the file is missing the version: 1 key to properly read the file

Oops.

@jinxcappa

Second after adding that the next failure comes from the toggle: key under keyboard: . the set value in the file is null but that throws an error in the installation:

None is not of type 'string'

changing the value from null to '' gets passed that error

Also oops. Both of these should be easy to fix, at least.

@blackline-silverfiel

• Is it feasible to throw a more visible error if, for whatever reason, user-data is not accessible and autoinstall was specified on the kernel command line? Just dropping the user into the non-automated installer is very confusing.

Yes, this is a good idea.

@blackline-silverfiel

• Where should I be looking for more information about what cloud-init is trying and failing to do? /var/log/cloud-init.log mentioned in the cloud-init docs does not appear to contain information about this part of the process, it seems to start by reading 0 bytes from /var/lib/cloud/seed/nocloud/user-data .

There is also /var/log/cloud-init-output.log but I’m not sure it helps with this. It’s always hard to debug why something isn’t happening! Looking in /var/lib/cloud/instance/datasource or the output of ‘cloud-init query’ might help.

@geschnei

I changed the network configuration in the autoinstall.yml to look like this:

network:
  network:
    ethernets:
      ens160: {dhcp4: true}
    version: 2

With this the installation went through.

Oh argh. I’ll fix this one soon so that the double network key is not necessary (but leave some code in so it works).

@geschnei

Next problem: Can I add multiple autoinstall configurations? On my previous ISO I had multiple preseed files with corresponding menu entries on the boot screen.

Trying to do the same with the new method I got the message

Confirmation is required to continue.

Add ‘autoinstall’ to your kernel command line to avoid this

when I booted from the second configuration. It seems that the parameter autoinstall is not just a name for the configuration to load, but a keyword.

You can put ds=nocloud,s=/autoinstall-variant1 on the kernel command line (and put user-data and meta-data files into the /autoinstall-variant1 directory). Or you can have an early-command swap a different yaml file into place depending on a marker you put into the kernel command line.

@robdumas

I’m planning a nuke-and-pave for my server now that 20.04 is out and I’m interested in using autoinstall (with either the server or netinstall USB ISOs) to automate the early installation, such as:

• Partitioning the SSD (ESP/boot.ext4/root.xfs)
• Set hostname, network (DHCP)
• Install a few packages (e.g., openssh-server , build-essential , etc.)
• Add a specified user with SSH authorized key and sudo permissions

All this should be very straightforward.

@robdumas

Right now, I’m trying to figure out how to access autoinstall in VirtualBox (6.1.6 as of this writing) to model it before trying it on the live server, but I’m feeling a bit lost. Must the autoinstall be served via HTTP or can it be local? Could I put it on another disk plugged into the machine, like a USB drive? I’m thinking here of the way Kickstart will look for a volume labeled “OEMDRV” and then pull the Kickstart config from there. Here’s a rough screenshot of what I’m talking about. Is that possible with autoinstall? How would I use GRUB’s command line to tell the server/netinstall disc to load an autoinstall (and/or cloud-config) file from a second disk that’s plugged in?

Yes, you can use a filesystem with the cidata (or CIDATA) label for this. As I replied to someone else earlier Comment #4 : Bug #1869291 : Bugs : subiquity has a recipe for this, but I do need to write this up somewhere.