dermotbradley/create-alpine-disk-image

Digital Ocean support

Opened this issue · 2 comments

winny- commented

Following up from IRC. Didn't see a memoserv bot so I'll just open a ticket to continue the discussion:

Tested out latest commit on default branch (c59b1c8) with invocation ./create-alpine-disk-image --cloud digitalocean --image-filename alpine-do.img --script-filename create-do.sh. Here's a screenshot showing the serial console's output and output from trying to ssh into the host. I believe cloud init isn't picking up the configuration from the cloud provider.
do-cloud-init-issue

dermotbradley commented

I believe cloud init isn't picking up the configuration from the cloud provider.

Yeah, that image will be configured to only use the ConfigDrive datasource which is what DO are supposed to use to pass to cloud-init (as an ISO) for it to get network and user-data configuration.

You could try editing the file definitions/cloud/digitalocean/defines and modifying the value of CADI_SUPPORTED_CLOUD_INIT_DATASOURCES from "ConfigDrive" to "ConfigDrive,DigitalOcean" and re-run create-alpine-disk-image etc again and try that - that change would configure cloud-init to use either ConfigDrive or DigitalOcean datasources (the c-i DO datasource even though it was written by DO is no longer being developed by DO and indeed in the next cloud-init it will be marked deprecated and so that's why my script isn't using it.)

Perhaps the DigitalOcean datasource will work. If it does then you would be able to examine the /var/log/cloud-init.log file to see whether a ConfigDrive ISO was detected or not by cloud-init if you enabled debug (--debug) when you ran create-alpine-disk-image.

Or if you have another machine running another distro that works with cloud-init then (as "root") check the output of cloud-init status --long which should indicate the datasource it used.

  • 👍1
dermotbradley commented

I think I figured this out - with the switch from the "DigitalOcean" datasource to the "ConfigDrive" data source I forgot to ensure that /etc/filesystems (a "mount" workaround) was created in that situation.

My images are using Busybox mount which has a known issue/restriction where it cannot mount a filesystem if the kernel module for it is not already loaded - the "full flat" mount from util-linux handles this by autoloading the relevant kernel module. There is a workaround for Busybox mount of creating an appropriate /etc/filesystems file, I just forgot with the switch to ConfigDrive to enable it for DO.

Fixed in the PR I just merged.

Please let me know if you get a chance to retest.