Please test autoinstalls for 20.04!

Server
86

Thank you so much! It worked like a charm.

87

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!

88

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.

89

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!

90

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

91

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
92

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

93

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

94

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

95

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
96

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 :slight_smile:

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.

97

This works for me (I just tried again to be sure). Can you show me the logs?

98

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

99

Oh right, yes this makes sense. Will have a think about what to do here. No need for the logs :slight_smile:

100

https://github.com/CanonicalLtd/subiquity/pull/763 should fix this, I think.

You may know this. but one thing to watch for when setting the hostname via cloud-init is that it gets set on every boot.

101

For those who’s also trying to use the OVF data source, I got it working for me! Specifically the guestinfo transport.

  1. The correct kernel command line is (source: canonical/cloud-init ds-identify#L8):

    autoinstall ci.ds=OVF

    This forces cloud-init to use the OVF data source directly, because otherwise it’s distracted by the empty NoCloud config present in the Ubuntu image.

  2. My autoinstall user-data now looks as follows:

    user-data.yaml 
    #cloud-config
autoinstall:
  version: 1
  refresh-installer:
    update: yes
  apt:
    primary:
      - arches: [i386, amd64]
        uri: "http://mirror.yandex.ru/ubuntu"
      - arches: [default]
        uri: "http://mirror.yandex.ru/ubuntu-ports"
    security:
      - arches: [i386, amd64]
        uri: "http://security.ubuntu.com/ubuntu"
      - arches: [default]
        uri: "http://ports.ubuntu.com/ubuntu-ports"
    conf: |
      Acquire::ForceIPv4 "true";
  identity:
    hostname: test-vm
    realname: Firstname Lastname
    username: username
    password: "$6$..."
  ssh:
    install-server: yes
    allow-pw: no
  user-data:
    users:
      - name: ansible
        gecos: Ansible
        sudo: "ALL=(ALL) NOPASSWD:ALL"
        ssh_authorized_keys:
          - "ssh-ed25519 AAAA..."
        shell: /bin/bash
    package_update: yes
    package_upgrade: yes

    It’s not 100% working as intended though, see below.

While working on this solution, I got some thoughts/questions:

  1. identity and user-data/users sections are not being merged.

    In my autoinstall user-data above, I have the default user defined in the identity section, and a secondary user defined in the users section of the nested user-data.

    The resulting nocloud-net user-data in the installed system only retains the default user, but not the one I specified in the nested user-data.

    A workaround for this would be to specify both users in the nested user-data, however:

    • One has to figure out what configuration does the default account get (settings, group membership etc.), and check for changes whenever a new Ubuntu version comes out.
    • As also described above by ububob, setting the hostname in nested user-data doesn’t work yet.

    Ideally, the contents of both sections should be merged together.

  2. Why is there an empty NoCloud configuration in the image?

    The presence of empty configuration confuses cloud-init, and doesn’t let it automatically choose the most appropriate data source.

    If I don’t force cloud-init to use OVF, ds-identify successfully detects that I have a guestinfo OVF transport, yet sticks with NoCloud, because that’s what it finds first/prioritises.

  3. daily-live images contain packages from proposed repo.

    Somewhat unrelated to the main topic, but thought I’d mention it anyway.

    It would be nice to have daily stable ISOs (in addition to cloud images) without the proposed repo. It would minimise the amount of updates one has to install on first boot.

102

Hi, I tried to use the autoinstall feature. First, I installed it interactively to generate the user-data file
that the installer saves, and then I wanted to create a modified ISO image containing this file.

What I observed:

  • the file created by the installer does not contain “version: 1” (is this mandatory?)
  • the file created by the installer is not respected at all when trying to “seed” an installation with it.
    I actually started from the gist file that was posted here (https://gist.github.com/s3rj1k/55b10cd20f31542046018fcce32f103e) and copy-pasted one section of my generated user-data file to the gists one, and after each section I tried whether it would still work. Currently stuck on the storage section (I want encryption…)
  • the “identity” is not applied. The given user is not even registered.
  • whenever I had something off in the user-data file and was asked questions during the installation, I had no clue what was wrong. A debian installer preseed I could inspect, as it logged in an understandable format (when enabling some switch, IIRC) I could not find anything about debugging the autoinstall process in the documentation.
103

Hi,
I use in my automated repo the following:
Howto generate crypted passwords: python -c ‘import crypt,base64,os; print(crypt.crypt(“password”, “$6$” + base64.b64encode(os.urandom(6))))’

But I have never had to use it until now (I only use packer / packer in plain), since I generate a user after the virtual machine has been created

104

Its working!
A very difficult, some common sense… When add this refresh, then I need to review the cloud-init format to use new format… :frowning:

105

Hi,

I cannot find examples to configure languages and keyboards in cloud-init.
I see locale: en_US, or locale: C, but, howto configure one default lang and others supplementary?
Anaconda example: lang en_US.UTF-8 --addsupport=es_ES.UTF-8

In keyboard, I see:
keyboard:
layout: gb

But, howto config variants, etc?
Anaconda example: keyboard --vckeymap=es-winkeys --xlayouts=‘es (winkeys)’,‘us’