Debian10 fails on final reboot

Users
21

@ltrager from the bug i opened with cloud-init, Bug #1927020 “cloudconfig not writing maas data source” : Bugs : cloud-init

Looking at the logs, a few things stand out:

  • /etc/cloud/cloud.cfg is practically empty. This is usually baked into the image, so to me this suggests a problem happening before we get to cloud-init.
  • ds-identify.log shows it couldn’t detect a datasource. This means this check returned false, but it should be returning true on MAAS (cloud-init/tools/ds-identify at main · canonical/cloud-init · GitHub).
  • The cloud-init code could also not detect a datasource. This again seems to suggest a problem with the image or fabric itself, not cloud-init.

As mentioned in my 2nd to last message in this thread I’ve also tried not setting preserve_sources_list: true after you mentioned that is a point at which maas cloud config is written but not when preserve_sources is set. Unfortunately it still doesn’t create the cloud-init files, is there any debug we can set to see whats going on?

22

@ltrager @billwear This is either a problem with MAAS or with curtin, definitely not cloud-init as its just not being provided the required files. I’ve noticed this in the curtin install log which look like its removing/cleaning the required files?

Applying debconf selections
Running command ['unshare', '--fork', '--pid', '--', 'chroot', '/tmp/tmpihv32ogj/target', 'debconf-set-selections'] with allowed return codes [0] (capture=True)
Running command ['unshare', '--fork', '--pid', '--', 'chroot', '/tmp/tmpihv32ogj/target', 'dpkg-query', '--list'] with allowed return codes [0] (capture=True)
unconfiguring cloud-init
cleaning cloud-init config from: ['/tmp/tmpihv32ogj/target/etc/cloud/cloud.cfg.d/90_dpkg_local_cloud_config.cfg', '/tmp/tmpihv32ogj/target/etc/cloud/cloud.cfg.d/90_dpkg_maas.cfg', '/tmp/tmpihv32ogj/target/etc/cloud/cloud.cfg.d/90_dpkg.cfg']

As the target machine does actually start up fine and install ssh keys etc, if I quickly login and create the files with the associated oauth keys from maas admin machine get-curtin-config ykfy3r and then run

cloud-init clean
cloud-init init

It completes the install and marks it in MAAS as such. Yay!

As a work around I was thinking of just adding these files as a write_files or late_commands step in the curtin_userdata_custom. The problem is I would need to inject the tokens but they don’t seem to be available as environment variables. Do you have any pointers as to how I could inject the below or create some long lived ones for all these machines?

    manage_etc_hosts: true
    manual_cache_clean: true
    reporting:
      maas:
        consumer_key: $CONSUMER_KEY
        endpoint: http://192.168.50.10:5248/MAAS/metadata/status/$INSTANCE_ID
        token_key: $TOKEN_KEY
        token_secret: $TOKEN_SECRET
        type: webhook```
23

@cbnorman, i dunno, but i’ll ping lee later today when he comes in. seems like you’re almost there with a workaround, anyway, wanna keep that balloon in the air! :slight_smile:

24

That indicates that the bug is in Curtin. I’ve associated your bug with Curtin so the Curtin developers can take a look.

MAAS generates a new OAUTH1 token for every deployment. As these are security credentials MAAS does not share this data as a variable for the template. You may be able to add a runcmd to the preseed to copy 90_dpkg.cfg to something like 91_dpkg.cfg

I would not run cloud-init in the preseed. The system still needs to reboot and it is possible the reboot will fail.

25

Hi guys,

Anyone managed to get it working ?

Thanks

26

closing this one as related to a bug (see bug link above).