Cloud-init error

LXD
1

Hi, cloud-init doesn’t seem to be running correctly on some images

lxd 4.20

lxc profile show p1

config:
  user.user-data: |
    #cloud-config
    users:
      - name: test
description: P1 LXD profile
devices:
  eth0:
    name: eth0
    nictype: bridged
    parent: lxdbr0
    type: nic
  root:
    path: /
    pool: default
    type: disk
name: p1
used_by:
- /1.0/instances/c3?project=myproject
- /1.0/instances/c4?project=myproject

lxc launch images:debian/11/cloud c1 --profile p1
lxc exec c1 -- ls /home/
debian #should be test

lxc launch images:centos/8-Stream/cloud c3 --profile p1
lxc exec c3 -- ls /home/
test #ok

lxc exec c1 -- cat /var/log/cloud-init.log
...
2021-11-17 17:33:15,827 - util.py[WARNING]: Failed loading yaml blob. Invalid format at line 4 column 12: "while scanning for the next token
found character '%' that cannot start any token
  in "<unicode string>", line 4, column 12:
        name: {% if instance.type == "virtual-m ... 
...

lxc exec c1 -- cat /var/lib/cloud/seed/nocloud-net/network-config

version: 1
config:
  - type: physical
    name: {% if instance.type == "virtual-machine" %}enp5s0{% else %}eth0{% endif %}
    subnets:
      - type: dhcp
        control: auto

lxc exec c3 -- cat /var/lib/cloud/seed/nocloud-net/network-config

version: 1
config:
  - type: physical
    name: eth0
    subnets:
      - type: dhcp
        control: auto
      - type: dhcp6
        control: auto

Thanks

2 Likes
2

Faced the same problem!

3

@monstermunchkin any ideas, as you’ve been looking at cloud-init and the image templates?

Thanks

4

At previous version cloud-init 21.3-1-g6803368d-0ubuntu1~20.04.3 all works fine.
Its look like bug cloud-init 21.3-1-g6803368d-0ubuntu1~20.04.4

5

fixed.
Use fingerprint by date 20211115 03eacb10808797fc21fc99f3750834660f7c8bac187f370978ce299ccde7f3eb

lxc launch images:03eacb10808797fc21fc99f3750834660f7c8bac187f370978ce299ccde7f3eb c7
6

I think it’s related to a recent change in distrobuilder and the image template.

7

I think the bug is here. The content variable is parsed by the template engine but the properties[“default”] is not. Line 138

bug introduce in this commit:

9
1 Like
10

Thank you @monstermunchkin