Hmm strange, setting the username certainly works for me via nocloud-net. I’ll try the CIDATA drive approach later, no time right now.
Hi everyone:
I’ve made quite a lot of progress in setting up autoinstall yaml to replace my old seed files. I’ve got a successful file that has network and storage set and I’ve been working on storage setups today (90% of all my machines use the same partitioning so I like to automate it).
I am able to do successful automated storage installs on MBR virtual machines, but I want to move forward and create a storage setup that is UEFI compatible. I can’t find any examples of this online in any cloud-init data. If someone knows of a good example of how to set properly set up the partitioning for UEFI systems using curti I would greatly appreciate it because I am guessing that I am only missing something small.
The storage setup below works in MBR mode but doesn’t work with EFI. I am testing it out with virtualbox. The error that I find when looking at the crash dump is: “autoinstall config did not create needed bootloader partition”.
storage:
version: 1
config:
### drive
- id: disk0
type: disk
ptable: gpt
grub_device: true
wipe: superblock
### partitions
- id: bios_boot_partition
type: partition
size: 1MB
device: disk0
flag: bios_grub
- id: efi_partition
type: partition
size: 512MB
device: disk0
flag: boot
- id: boot_partition
type: partition
size: 5GB
device: disk0
- id: root_partition
type: partition
size: -1
device: disk0
### format and mount efi partitions
- id: efi_vfat
type: format
fstype: fat32
volume: efi_partition
- id: efi_partition
type: mount
path: /boot/efi
device: efi_vfat
### format and mount boot partition
- id: boot_ext4
type: format
fstype: ext4
volume: boot_partition
- id: boot_mount
type: mount
path: /boot
device: boot_ext4
Hopefully more experienced eyes can see what is going on here…
I’ve also been experimenting with this on a UEFI device. I put my full process up at https://askubuntu.com/questions/1235723/automated-20-04-server-installation-using-pxe-and-live-server-image
I don’t have the generated curtin config handy, but the autoinstall config is there
I think you just need to set grub_device: true on the ESP.
1 Like
Thanks. I think that was it. At least it was a necessary change. It’s changed my
error and I think it is typo related now.
Thanks. It’s working.
–dcl
2 Likes
I’ve just tried this now and it worked OK. Can you tar up /var/log/installer and maybe /var/log/cloud-init* from the installed system and attach it to a bug report?
user-data:
timezone: Pacific/Auckland
should work.
Thank you so much! It worked like a charm.
Now I’m confused. Regarding the apt issue, I removed the work around, put in a basic apt config and it is working as intended. I’m not sure at this point where the mix up was happening. If I run in to it again I’ll file a bug report with the requested logs.
The user-date/timezone addition worked. Thank you!
ds=ovf and autoinstall ds=ovf were the first thing I tried, sadly it still prefers the empty NoCloud seed. The cloud-init.log is exactly the same with either of those options.
Unless I misunderstand, the cloud images (in particular vmdk and ova) are preconfigured for a certain disk size out of the box (10 GB with potential for expansion), they boot in legacy/BIOS mode, assume old hypervisor version for compatibility etc. I’m typically configuring my VMs for smaller virtual disk size, and also boot them in UEFI mode with Secure Boot enabled, hence installing from the ISO.
I thought I managed to reproduce the problem once in dry-run testing on my machine, but never again so either I was confused and looking at the wrong file or there was some kind of race somewhere. I don’t know where though, this code is not very complicated!
We have the same problem - we configure a static IP in the 90_autoinstall.cfg:
network:
network:
version: 2
renderer: networkd
ethernets:
ens192:
dhcp4: false
addresses:
- 192.168.3.33/24
gateway4: 192.168.3.1
nameservers:
addresses: [192.168.3.2, 192.168.3.3]
search: [meteoswiss.ch]
but after the install, the system is configured to use dhcp in /etc/netplan/00-installer-config.yaml:
This is the network config written by ‘subiquity’
network:
ethernets:
ens192:
dhcp4: true
version: 2
As detailed in another post I’ve just released a new version of subiquity to the stable channel. If you put
refresh-installer:
update: yes
in your autoinstall config, the installer will update and provide a less buggy experience.
… including fixing this one!
1 Like
Hi,
I try to use this parameter to update the installer (I use https://releases.ubuntu.com/20.04/ubuntu-20.04-live-server-amd64.iso):
refresh-installer:
update: yes
But when I add this, fails with a HTTPError 400 client error. Howto fix this?
Regards
Hi,
I’m using the 10th May daily server build (focal-live-server-amd64.iso) which now has subiquity 20.05.1 baked into the installer. I’m using the autoinstall feature (by injecting autoinstall.yaml into the iso renamed as user-data in the root of a partition with the label ‘cidata’). The server is connected to a network that doesn’t have DHCP so I’m using fixed ip addressing. Virtually everything works which is great.
However, I’m having problems setting the server’s hostname. My autoinstall.yaml doesn’t have an ‘identity’ section but does have a ‘user-data’ section which includes the tags ‘hostname’ and ‘fqdn’. The server gets installed OK but with the default hostname. As a work-around I can use ‘hostnamectl set-hostname MYHOST’ in the user-data->runcmd section.
Setting the hostname in the user-data section of the autoinstall.yaml file did work in the original Ubuntu 20.04 release ISO (with a previous version of subiquity).
Not sure if this now the correct behaviour or is this a bug in subiquity 20.05.1? Should setting the hostname in the user-data section of the autoinstall.yaml file where there is no ‘identity’ section work?
Thanks,
Bob
Hi,
I have a question for the Ubuntu installers. By default the disk root is formatted in ext4.
Others O.S. already use by default xfs for root partition and ext4 for boot partition (good).
Because the default for root is ext4 in Ubuntu?
Regards
My virt-install command for anyone else trying this out:
virt-install \
--name test1 \
--ram 4096 \
--disk pool=default,size=32,bus=virtio,format=qcow2 \
--vcpus 4 \
--os-type linux \
--os-variant ubuntu20.04 \
--virt-type kvm \
--graphics vnc,port=5901,listen=0.0.0.0 \
--autostart \
--location ubuntu-20.04-live-server-amd64.iso,kernel=casper/vmlinuz,initrd=casper/initrd \
--extra-args "autoinstall ds=nocloud-net;s=http://10.0.0.3:3003/"```
in a www folder I have two files, meta-data (empty) and user-data with:
#cloud-config
autoinstall:
version: 1
locale: "en_US.UTF-8"
refresh-installer:
update: true
keyboard:
layout: "us"
storage:
layout:
name: "direct"
identity:
hostname: "test"
username: "testuser"
password: "$1$ZeMGfns1$OzT9fj4qy9vIncBDm2wbY1"
ssh:
install_server: true
I used python3 -m http.server 3003 to serve these files as the quick-start recommended.
Notes:
- I could not get auto-install to work with
http://ftp.ubuntu.com/ubuntu/dists/focal/universe/installer-amd64/as the installer location. - The trailing “/” in the extra arguments is important - it gave me a “could not parse 10.0.0.3:3003meta-data” error without it.
- Should the wiki have a section on how to generate the password? I had to go looking for how to do this. Here is what I did:
echo "password" > password && makepasswd --clearfrom password --crypt-md5
1 Like
FWIW, these ISOs are not really intended for general use, as they are more intended for SRU verification – they have the “proposed” pocket enabled.
Yay!
In the absence of an ‘identity’ section then setting hostname in the user-data section should definitely work. I’m having a hard time seeing how this could have changed behaviour in 20.05.1. Can you run cloud-init collect-logs on the installed system and get the resulting tarball to me somehow?
This really isn’t the thread for this. I’m not an expert but my understanding is that ext4 is still considered a good default filesystem. Changing to a different default is an easy change to make but “everyone else is doing it” isn’t really a good enough reason 
Ah nice that you managed to get it to work with virt-install!
That’s a debian-installer style URL so no, that’s not going to work.
Yep! Perhaps the docs need to be clearer about this.
This is a good point. I tend to use the Python repl for this, which is hardly very clean. I think echo ubuntu | mkpasswd -m sha512crypt --stdin is perhaps a bit more canonical. I’ll update the wiki.
This works for me (I just tried again to be sure). Can you show me the logs?
Hi,
Thanks for the very quick response. Much appreciated.
I think I’ve discovered why using the 20.04 live-server release iso (with an earlier version of subiquity) worked. Due to the networking issues (with netplan config) I ran up a DHCP server on the network - and this supplied the hostname using a DHCP reservation (sorry I should have realised that last night!).
I’ve now added a ‘preserve_hostname: false’ tag in the user-data section of the autoinstall.yaml file, but this doesn’t fix the problem.
I checked the ‘autoinstall-user-data’ file (in /var/log/installer) and it accurately reflects the autoinstall.yaml user-data settings (hostname, fqdn & preserve_hostname). However in the cloud-init seed (/var/lib/cloud/seed/nocloud-net/user-data) ‘preserve_hostname’ is true. If I edit the seed user-data file and set ‘preserve_hostname’ to false (as in the original autoinstall.yaml file) and then run ‘cloud-init clean --reboot’ the hostname is configured correctly.
I will email you the cloud-init logs shortly.
Thanks for your help.
Bob
Oh right, yes this makes sense. Will have a think about what to do here. No need for the logs