The topics of the autoinstall process for Ubuntu Server in 20.04 has been muchdiscussedhere.
It’s taken longer than I’d hoped, but we’re finally at a point where we can ask for you all to test. I’ve written a “quick start” document that has the minimal steps required to perform an autoinstall in a VM on your own system. I encourage everyone reading this to try these steps out and then go on to try other autoinstall features that look interesting to you. I’d be especially interested in tests on real hardware (possibly in conjunction with netboot) as I don’t have access to the hardware I usually test this sort of thing on right now. Reports of failures or missing features are of course interesting, but reports of success are welcome too
I’ve made a few minor changes as things got implemented, but I’ve been keeping the introductory and reference documentation up to date as I’ve been going so please refer to that if you have questions and then reply here if the docs don’t help!
I want to try this because recently we have a recent support case that one customer wants to install 18.04 over a serial connection and it is better to have this tested early than later it ends up in another support case, and
Ah, I can see one way this might be a problem (subiquity tries to read which is the “main” console from the kernel command line but doesn’t parse options). I’ll try to get a fix out early next week.
I’m attempting to ‘remaster’ the ISO with a few edits - essentially using this slightly-edited ISO to kick-off automated installs.
Previously, to customize the alternate installer, I would extract the ISO contents, and then place a customized ks.cfg and ks.preseed in the root of the OS files, and would also update kernel parameters at boot/grub/grub.cfg before using xorisso commands to regenerate the ISO.
Going forward, I understand that my ks.cfg and ks.preseed would be replaced by customizations in my cloud-init file on an HTTP server, but I was hoping to still customize boot/grub/grub.cfg to point to that cloud-init file on the HTTP server. Essentially, that grub.cfg file is the only file I’m wishing to change.
Ah, close but not quite. The easiest way of providing a config on the ISO right now – we should come up with something better – is to unpack the installer.squashfs and put something in /etc/cloud/cloud.cfg.d, like for example:
Then all you need to do is add ‘autoinstall’ to grub.cfg and repack the ISO. I find xorriso completely confusing, but there is a script in the subiquity source that you can probably adapt into something useful for your needs.
Basic autoinstall functionality seems to work as expected, but I seem to have some trouble getting user-data config key to work as expected. The config data seems to be captured correctly in installer logs, but doesn’t seem to be included in the cloud-init seed file. I have provided more details here - let me know if I can provide any additional detail:
Could you elaborate a little on all you need to do is add ‘autoinstall’ to grub.cfg and repack the ISO? I can only find some examples on how to add external http sources, but not what to add to grub.cfg to read the information directly from the iso.
I’d appreciate some additional clarity on the process for loading autoinstall config at boot time, as the documentation is very sparse here.
My use case is a little different from the quickstart example – I’m using HashiCorp Packer with the VirtualBox builder. This also supplies the config file (preseeding or autoinstall or whatever) at a local HTTP address, but when I boot with an equivalent command line, I’m dropped into the installer with no automation and no error messages. Here’s the grub boot commands I’m using:
set gfxpayload=keep
linux /casper/vmlinuz autoinstall ds=nocloud-net;s=http://10.0.2.2:8028/autoinstall.yaml ---
initrd /casper/initrd
boot
This did not work for me. Digging around in the logs now looking for clues.
Some documentation that would be helpful which I have not been able to find (sorry if it exists):
What do the kernel parameters “ds” and “s” mean, and what options are available for them?
Is it possible to see and/or customize the exact file name the automated installer is trying to load? Relying on the file to be named “user-data” always complicates having multiple configs.
Is it possible to see whether the installer is aware it should be running in automated mode or not, e.g. if it noticed the “autoinstall” parameter? And if so, does/can it report why it was unable to load the config file, e.g. a yaml parsing or json schema error?
Dont know all the answers but from nocloud’s website:
Alternatively, you can provide meta-data via kernel command line or SMBIOS “serial number” option. The data must be passed in the form of a string:
ds=nocloud[;key=val;key=val]
or
ds=nocloud-net[;key=val;key=val]
The permitted keys are:
h or local-hostname
i or instance-id
s or seedfrom
With ds=nocloud , the seedfrom value must start with / or file:// . With ds=nocloud-net , the seedfrom value must start with http:// , https:// or ftp://
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
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
The last error that im up to that I just cannot figure out is configuring the network. I have copied the file exactly and its always the same error:
Command ‘[‘netplan’, ‘apply’]’ returned non-zero exit status 1
…
AttributeError: ‘ScrollBarListBox’ object has no attribute ‘_w’
I even found the default netplan configuration in the squashfs file and used that and netplan apply still returns 1
I do not know how to automatically configure the nextwork and cannot proceed.
i’ll attach images from my kvm sessions if they help any.
@Jinxcappa thanks for pointing me to that doc, I didn’t realize cloud-init was a separate project.
@all It appears that cloud-init is not properly downloading the user-data file for some reason. The command cloud-init analyze dump has lots of “SUCCESS” in it. In the directory /var/lib/cloud/seed/nocloud/ , the user-data file is empty, despite the fact that I can curl http://10.0.2.2:8xxx/user-data and see the file is accessible over http.
Perhaps this is not the right forum for this, but two additional questions:
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.
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 .
Works a treat here, much better than hours of trying to debug d-i statements!
Slotted in easily on a CentOS 7 PXE/TFTP server alongside our kickstarts.
Rsyslog implementation would be awesome, I see that is in the pipeline. We use this heavily to validate CentOS builds currently.
Few questions:
Any thoughts on ZFS support? I did some experimentation with adding the curtin zfsroot config but got python exceptions (which I kind of expecting).
Is it possible to run commands in the /target “chroot”, for example I have a template that installs apache2 but I don’t want it to start on default boot until it has been configured by the end customer.
Lastly, what are the credentials to ssh in to a crashed installer to debug?
