Please test autoinstalls for 20.04!

Also, It’s not clear to me how to set the config to select “Fill entire disk”, because it is not doing that when I do a fully automated install, even though that seems to be the default option? https://askubuntu.com/questions/1244293/how-to-autoinstall-config-fill-disk-option-on-ubuntu-20-04-automated-server-in?noredirect=1#comment2097575_1244293

Hello here,

I’m trying to autoinstall a VM with Ubuntu server 20.04 but I got stuck on the hard-drive partition step.

I can’t make GRUB to install itself. I tried every syntax and example provided here but each time the installation finishes with a crash and this error message: “autoinstall config did not create needed bootloader partition”

Please find the configuration I am using:
(please also note that re-using the configuration from a manual installation does the same error)

my conf

#cloud-config
autoinstall:
version: 1
refresh-installer:
update: yes
reporting:
hook:
type: webhook
endpoint:
keyboard:
layout: fr
variant: ‘’
locale: en_US

network:

ethernets:

enp0s3:

dhcp4: true

version: 2

identity:
hostname: workstation
password: password_here
realname: user
username: user
ssh:
allow-pw: true
authorized-keys: []
install-server: false
storage:
swap:
size: 0
grub:
reorder_uefi: false
install_devices:

  • /dev/sda1
    config:
  • type: disk
    id: disk-sda
    ptable: gpt
    path: /dev/sda
    preserve: false
    grub_device: false
    name: ‘system’
  • type: partition
    id: partition-efi
    device: disk-sda
    size: 512MB
    grub_device: true
    flag: boot
    number: 1
  • type: partition
    id: partition-boot
    device: disk-sda
    size: 1G
    grub_device: false
    flag: ‘’
    number: 2
  • type: partition
    id: partition-system
    device: disk-sda
    size: 100%
    grub_device: false
    flag: ‘’
    number: 3
  • type: dm_crypt
    id: dm_crypt-system
    volume: partition-system
    key: criteo
    preserve: false
  • type: lvm_volgroup
    id: lvm_volgroup-system
    name: ubuntu-vg
    devices: [dm_crypt-system]
    preserve: false
  • type: lvm_partition
    id: lvm_partition-system
    volgroup: lvm_volgroup-system
    name: ubuntu-lv
    size: 100%
    preserve: false
  • type: format
    id: format-efi
    volume: partition-efi
    fstype: fat32
    preserve: false
  • type: format
    id: format-boot
    volume: partition-boot
    fstype: ext4
    preserve: false
  • type: format
    id: format-system
    volume: lvm_partition-system
    fstype: ext4
    preserve: false
  • type: mount
    id: mount-system
    device: format-system
    path: /
  • type: mount
    id: mount-boot
    device: format-boot
    path: /boot
  • type: mount
    id: mount-efi
    device: format-efi
    path: /boot/efi

Hello did you finally solve your problem ?
I have the same. And even with the grub_device: true the installation fails with the same bootloader error

After much trial and error, I was able to netboot and autoinstall on my NUC. One issue I didn’t see talked about anywhere was the installer kept crashing while setting up the disks. I had an older Ubuntu install on this machine and it was running in legacy (BIOS) mode with MBR. I was switching it to EFI & GPT this go round and until I manually deleted the old dos partition table it would not successfully complete this step. I’m unsure if this is a bug or something missing in my config. Here is the storage section of my user-data

  storage:
    grub:
      reorder_uefi: False
    config:
      - id: disk0
        type: disk
        ptable: gpt
        serial: Samsung_SSD_850_EVO_250GB_S21NNSAFC10405E
        preserve: false
      - id: disk0-efi
        type: partition
        number: 1
        size: 512MB
        device: disk0
        flag: boot
        grub_device: true
        preserve: false
      - id: disk0-efi-fs
        type: format
        fstype: fat32
        volume: disk0-efi
        preserve: false
      - id: disk0-efi-mount
        type: mount
        path: /boot/efi
        device: disk0-efi-fs
        preserve: false
      - id: disk0-root
        type: partition
        number: 2
        size: -1
        device: disk0
        preserve: false
      - id: disk0-root-fs
        type: format
        fstype: ext4
        volume: disk0-root
        preserve: false
      - id: disk0-root-mount
        type: mount
        path: /
        device: disk0-root-fs
        options: 'defaults,noatime,discard,errors=remount-ro'
        preserve: false
1 Like

Hi, I want to give some feedback about the new autoinstaller for ubuntu 20.04 after spending all day trying to make it work:

Setting the ubuntu user password never worked:

#cloud-config
autoinstall:
  version: 1
  identity:
    hostname: ubuntu-server
    password: "$6$exDY1mhS4KUYCE/2$zmn9ToZwTKLhCw.b4/b.ZRTIZM30JZ4QrOQ2aOXJ8yk96xpcCof0kxKwuX1kqLG/ygbJ1f8wxED22bTL4F46P0"
    username: ubuntu

Even using the quickstart example verbatim never resulted in an installed system that I could log-in to with the ‘ubuntu’ user. I tried so many different ways to set the ubuntu user password, and nothing ever worked:

  • openssl passwd -6 -salt xyz ubuntu
  • echo ubuntu | mkpasswd -m sha512crypt --stdin
  • mkpasswd --method=SHA-512 --rounds=4096
  • simply using the plaintext ‘ubuntu’ as the value of the password field
  • quoting or not-quoting the value in the password field

I’m really curious if/how anyone ever got an autoinstalled system with a defined password that actually worked, or what specifically you need to do to generate a proper password and how to communicate it to the autoinstaller

ssh authorized keys configuration never worked

  ssh:
      install-server: yes
      authorized-keys:
          - ssh-rsa <some key infomation>
      allow-pw: yes

Because setting a password (see above) never worked, I next tried to set ssh authorized keys. Using the exact same format and data from a known working cloud-init configuration.

This did not work. I tried quoting and not-quoting the values passed via authorized-keys.

refresh-installer crashes with the May 31st focal server daily ISO:

  refresh-installer:
    update: yes

As I was desperately trying to make this work, I tried combinations of the GA release of ubuntu server 20.04 and the latest focal server dailies. I observed that attempting to set refresh-installer causes the installer to crash when using the May 31st version of the focal server daily ISO.

attempting to install some packages causes the autoinstaller to crash:

  packages:
    - curl
    - wget
    - htop
    - nfs-common

Attempting to install nfs-common caused the autoinstaller to crash. The only remedy was to remove that package from the packages: section.

networking configuration never worked:

I tried combinations of removing the nested networking: stanza and different interface names without ever having a successful network configuration set via autoinstaller. Because I couldn’t even log into the installed system (see the problems with the passwords above) it wasn’t possible to figure out what was being applied.

  network:
    network:
      version: 2
      ethernets:
          ens18:
            dhcp4: false
            optional: true
      vlans:
        vlan.20:
          dhcp4: true
          id: 20
          link: ens18

user-data setting never worked:

Thinking that autoinstaller is perhaps too problematic to use (based on the experiences above), I tried to make the ‘autoinstall’ portion as minimal as possible and inject a known working cloud-init configuration in the user-data section. This did not work.

I assume it’s a current bug based on this and I could never find a working combination of settings which resulted in settings defined in the user-data section of the autoinstall configuration to actually apply.

conclusion:

After dozens of installation attempts and trying combinations of attempts with both the official ubuntu 20.04 GA release server installer ISO, the May 31st ‘daily’ version of the focal server installer ISO, and refresh-installer (when it worked), it never resulted in a successful installation.

I know that some settings were being applied as I could set the hostname via the identity section and see the some of the packages were being installed (except the ones that caused it to crash); so I feel confident that it was properly consuming the referenced user-data (I also checked for tabs vs spaces in the user-data file).

Is the autoinstall approach still considered something to be tested/beta, or is it intended to be a GA usable installation approach for ubuntu server?

1 Like

Are you perhaps booting your VM in legacy mode? (i.e. not UEFI) The config looks appropriate for a UEFI system on a quick glance.

There were some bugs in this area. They should be fixed in the release in the stable channel or on the latest dailies though, so if you’re still seeing failures I’d like to see the logs.

This sounds a bit as if the cloud-init config that should configure these things never ran on first boot. Can you fish out the /var/log/cloud-init* files from the installed system (by booting the installer again, or mounting the disk image if you installed a VM or something like that)?

I shall have to try this tomorrow. It certainly shouldn’t crash!

:frowning:

It’s intended to be usable but it’s new and some bugs are to be expected. You’ve definitely had a bad run though, sorry about that. I’ll try to reproduce your issues in the next day or so and see what I can figure out.

1 Like

Hello that was indeed the case :slight_smile:
I edited manualy the ISO file to add autoinstall menu and in broke GRUB. So my VM was booting ISOLINUX+BIOS instead of GRUB+EFI

Hello

Did somebody tried to execute multi-lines commands in the ‘late-commands’ section ?
I am trying to write a new file with text inside, but it fails.

Autoinstall file extract:

      late-commands:
        - cat <<EOT >> /target/lib/systemd/system/example.service
          [Unit]
          Wants=network-online.target
          [Service]
          Type=oneshot
          ExecStart=example.sh
          [Install]
          WantedBy=multi-user.target
          EOT
#cloud-config
autoinstall:
  version: 1
  identity:
    realname: UBUNTU_REMOVE_ME
    username: ubuntu
    password: $6$GSmxlvP1$K38Inpkh3FavGYA1oJGQciLYTBLNCqlqUSq6xeF7P.rk8GvRLg.OgcwP8cQBx/A1MZJ3sVs9PdC9GzYyqMTyo0
    hostname: changeme

Hostname gets done, user in fact does not exist in /etc/shadow

which just confirms what others have been saying. Identity user stuff is being ignored.

3 Likes

Ah good.

      late-commands:
        - |
          cat <<EOT >> /target/lib/systemd/system/example.service
          [Unit]
          Wants=network-online.target
          [Service]
          Type=oneshot
          ExecStart=example.sh
          [Install]
          WantedBy=multi-user.target
          EOT

should work I think.

Can you get me /var/lib/cloud and /var/log/cloud-init* somehow?

2 Likes

Hi,

Should I report Please test autoinstalls for 20.04! on Launchpad?

I’m not sure as I’m using daily isos and the subiquity edge channel - which I know could be problematic.

Looks like edge has not been updated for a couple of weeks.

Thanks in advance.

Thanks! It works fine with a pipe at the beginning

Yes please, I’d forgotten about that one…

Done #1881887 :slightly_smiling_face:. I did try to install today to check the issue still exists, and it does.

I’m facing the exactly same issue.
User created via CI-DATA drive is not working.
Have you found another way than repacking a new iso with the commands inside?

A (very ugly) solution is to set the encrypted password using late-commands but i don’t really like it.

And I finally committed a fix for this.

Thanks, I’ve tested with today’s edge channel and all is OK.

1 Like

It took some trial and error but I got a late-command working that sets up rootfs and home btrfs subvolumes.

Complete example autoinstall for EFI systems.

For some reason I’m still getting swap.img in addition to my swap partition in the fstab. The presence of a swap partition and the root partition being btrfs should prevent swap.img from being added based on what I see in the code. :confused:

Nice!

At some point, I’m going to add a documentation page with some examples. Would you be OK with your example being used on it?

Hmm it looks like the logic for that doesn’t actually fire in the autoinstall case. Can you file a bug? You can probably work around this by adding something like this to your config:

storage:
    config: ...
    swap: {swap: 0}

Would you be OK with your example being used on it?

Sure!

Can you file a bug?

https://bugs.launchpad.net/subiquity/+bug/1883706

You can probably work around this by adding something like this to your config

That worked, thank you.