Hi @mwhudson, I was thinking about this way as well, but I am worried that I am cutting off the installation procedure prematurely, preventing the system from properly finishing up. Should I be worried at all?
1 Like
Is it possible to have the hostname set by the dhcp response, so that you could have multiple servers installing from the same config file and not end up with duplicate names?
Latest issues with the new 20.04.2 version of subiquity that bricked our install pipelines. This is getting ridiculous.
Feature Request: please allow more channels in the snap repo. The inability to change to channel 20.09.1 which is the last working one from my perspective is arbitrarily restrictive and workflow breaking.
Is it possible to see the output of late-commands printed to terminal along with other installation output?
From what I’ve seen it does do that by default. I know my apt update command does the normal update output.
late-commands do not print to console (the code seems to confirm it):
I ended up printing last lines of syslog from error-commands (they do output to console)
So this whole thing was working for me with server 20.04.1. However, I just tested with 20.04.2 and it crashes. It tries to download a vendor-data file from the autoinstall web server that I specify. I tried creating a blank file with that name as well as just copying the user-data file. Neither work.
1 Like
I’ve been having the same problem. everything worked fine on 20.04.1, but once I moved to 20.04.2 the autoinstall process stopped working, I noticed the same thing you did, vendor-data tries to get downloaded. Did you ever find out what was causing this? I’m a little stuck myself.
I have not. But I haven’t really been looking into either as I’m busy with other stuff.
Did u solve your problem?
I have the same problem as u mention in your crash file? I don’t know how to solve it.
CrashDB: {‘impl’: ‘launchpad’, ‘project’: ‘subiquity’}
It seems regardless of my settings autoinstall will create a LVM of 24GB in size. Is there a config option that simply creates the max available lvm group of whatever physical disk is provided?
Hi all. Some time ago I created a script to create ISO images that can be used for unattended autoinstalls. I saw that there was a lot of demand for a tool to easily make automated installation media for Ubuntu 20.04 desktop edition as well, but the new autoinstall procedure does not work there yet.
I have created another tool for automating Ubuntu 20.04 desktop installs too: https://github.com/covertsh/ubuntu-preseed-iso-generator
I realize this is not totally related to testing autoinstalls so might be off-topic in this thread, however as there has been a fair amount of demand in the comments here I hope it helps somebody.
2 Likes
Its not about installing a system with known vulnerabilities. Many IoT vendors who support Ubuntu Server running on their devices explicity instruct Admins to disable auto-updates from Ubuntu during installation and require them to manually install a deb package that points the update repo to the vendor’s own update servers - after all the vendor builds custom kernels that enables Ubuntu to run on their hardware. This is done only during the initial installation process. Once the manual deb package installation is run as a late-command, updates resume normally again. The manual deb package installation is never run as an early-command, since an Ubuntu instance does not exist yet at that point.
I am not sure if skipping updates in autoinstall is controlled through refresh-installer.update=false:
"refresh-installer": {
"type": "object",
"properties": {
"update": {
"type": "boolean"
},
"channel": {
"type": "string"
}
},
"additionalProperties": false
},
Or if the apt object needs a new property called update, which by default is always true, but can be modified to false if needed for situations where updates need to be skipped:
"apt": {
"type": "object",
"properties": {
"preserve_sources_list": {
"type": "boolean"
},
"primary": {
"type": "array"
},
"geoip": {
"type": "boolean"
},
"sources": {
"type": "object"
},
"update": {
"type": "boolean"
}
}
},
Autoinstall with network as interactive option does work with focal fossa live server ubuntu version (https://releases.ubuntu.com/focal/ubuntu-20.04.2-live-server-amd64.iso
Autoinstall breaks with official live server ubuntu download version (https://releases.ubuntu.com/20.04.2/ubuntu-20.04.2-live-server-amd64.iso)
What is the difference between two ubuntu flavours though both have same LTS support and using same kernel(5.4) versions? What is causing interactive mode to be failed in official download version?
Below is my setup :
Both boot configuration files /boot/grub/grub.cfg & /boot/grub/loopback.cfg has bellow parameter
ds=nocloud\;s=/cdrom/nocloud/
Configuration file isolinux/txt.cfg has below parameter
ds=nocloud;s=/cdrom/nocloud/
Path /cdrom/nocloud/ has two seed files
/cdrom/nocloud/user-data
/cdrom/nocloud/meta-data
Config Content :
cat > /cdrom/nocloud/user-data <<EOF
#cloud-config
autoinstall:
version: 1
interactive-sections:
- network
identity:
realname: Ubuntu
username: ubuntu
hostname: ubuntu-server
# ubuntu
password: ‘$6$wdAcoXrU039hKYPd$508Qvbe7ObUnxoj15DRCkzC3qO7edjH0VV7BPNRDYK4QR8ofJaEEF2heacn0QgD.f8pO8SNp83XNdWG6tocBM1’
EOF
cat > /cdrom/nocloud/meta-data <<EOF
#empty
EOF
1 Like
Another question I have after working with this a bit. I can see that the ISO gets downloaded 3 times over the network when doing an automated install. Is there a way I can make it not do that?
192.168.1.225 - - [06/Apr/2021:22:09:47 +0000] "GET /ubuntu-20.04.1-live-server-amd64.iso HTTP/1.1" 200 958398464 "-" "Wget"
192.168.1.225 - - [06/Apr/2021:22:13:24 +0000] "GET /ubuntu-20.04.1-live-server-amd64.iso HTTP/1.1" 200 958398464 "-" "Cloud-Init/20.2-45-g5f7825e2-0ubuntu1~20.04.1"
192.168.1.225 - - [06/Apr/2021:22:16:50 +0000] "GET /ubuntu-20.04.1-live-server-amd64.iso HTTP/1.1" 200 958398464 "-" "Cloud-Init/20.2-45-g5f7825e2-0ubuntu1~20.04.1"Dumb Question: Is there any way to do a JOIN between the AutoInstall Guide and the Cloud-Init Guide and clearly demarcate what parts of Cloud-Init can and cannot be used in AutoInstall?
I just found out that one can significantly speed-up boot times from the second boot onwards by adding the following in one’s autoinstall config (recommended only for OnPrem/IoT installations):
user-data: timezone: UTC runcmd: - echo "¤¤¤ autoinstall first-boot runcmd start ¤¤¤" - rm -rvf /etc/cloud - rm -rvf /var/lib/cloud - apt purge -y cloud-init - echo "¤¤¤ autoinstall first-boot runcmd end ¤¤¤" late-commands: - echo "¤¤¤ autoinstall late-commands start ¤¤¤" - curtin in-target --target=/target -- systemctl disable systemd-networkd-wait-online - curtin in-target --target=/target -- systemctl mask systemd-networkd-wait-online - "sudo sed -i -e \"2s/^.*/datasource_list: [ None ]/g\" /target/etc/cloud/cloud.cfg.d/90_dpkg.cfg" - curtin in-target --target=/target -- dpkg-reconfigure -f noninteractive cloud-init - echo "¤¤¤ autoinstall late-commands end ¤¤¤"
NOTE: Despite the serious errors shown by cloud-final.service at the first boot, the system is perfectly installed and usable. The errors exist becasue you have just used cloud-init to remove itself and save quite a chunk of time in booting up. Mind you - the serial time thief is actually systemd-networkd-wait-online and the config above kills it off too.
Finally - I have no clue why one needs to “sudo sed”, but that is what is required. “sed” alone will not cut it and the installation fails without “sudo” due to permission issues.
Looking forward to cutting down installation time by a further 30% once AutoInstall Config supports the omission of:
1 Like
Is there any documentation on how to debug why your autoinstall is not truly automatic autoinstall? Eg why you get to the select language step if you have something wrong in your user-data config.
I can’t get Ubuntu 20.04 to be truly automatic autoinstall if I throw multipath/SAN disks into the mix, can anyone confirm that it works? 
I have fully working autoinstall with PXE in my ESXi enviroment without any problem. But I cant get it to work with Cisco UCS/Multipathed SAN disks. If I take my user-data config that works on ESXi and replace the “storage” configuration with the storage configuration from “autoinstall-user-data” that was created on a manual install on the physical server, it should be “correct” config, right?
I’m finding the need to add autoinstall to the kernel commandline to be very inconvenient. My usual Ansible-based installation process for CentOS is to mount the stock ISO in a VM along with a separate Kickstart ISO, boot up the VM, and wait for it to finish the install and shut down. With Ubuntu Server, I would have to extract, modify, and repack the Ubuntu ISO for this to work, and redo this after each upgrade.
Is there some alternative way to indicate “yes, I’m sure I want to autoinstall” and override the manual confirmation without modifying the ISO? Could the confirmation be skipped when the target disk has no partition table?
How does one put the LUKS encryption key in the autoinstall file in an encrypted form? So far I’ve only managed to do this in plain text. This has been a limitation of the old preseed method, and apparently it’s been carried over to autoinstall.
I’ve tried to omit the "key: " section, but then crutin just crashes.
I’ve also tried to set the “storage” section to interactive, but then it apparently discards my settings for storage altogether. (on the edge channel it also crashes as a bonus lol)
It’d be great if I could tell autoinstall to ask interactively just for the encryption passphrase, and nothing else. Is there a way?
Trying to work out why something has not happened is always hard but perhaps we should add some tips to the documentation about this. I’d start by looking at the cloud init logs and seeing if it’s finding a data source at all.
I’d like to solve this with better tooling really. One thing would be to provide a tool to make modifying the kernel command line arguments in the ISO a one liner (I have some code for this but it’s a bit terrible at the moment). The other thing is to provide a better way to create VM images than booting an installer in the VM – it’s really not what the installer is designed for! (This would be a much bigger project).
How would this work? luksFormat needs the unencrypted passphrase, it’s not like a password for authentication where supplying a hash is sufficient. If you simply don’t want to have it in the autoinstall file I guess you can have that reference a keyfile and use an early-command to fetch the passphrase from wherever and put the it into the keyfile (I haven’t tried this mysef).
Neither of those sound great 
Can you file bugs?
Not today. I would suggest you use an early-command again but it’s hard to be interactive from an early command as they run in a process without a controlling terminal. I guess in some circumstances you can assume that any interaction will take place on /dev/tty0.