Using the AWS console, I’m launching an instance using a custom AMI. A few XML files need to be updated as part of the system initialization. Although I entered the user data, it doesn’t appear to be working.
Upon checking ds-idenify.log and cloud-init-generator.log, I can see that cloud-init is unable to obtain the data source.
**cat ds-identify.log**
[up 1.17s] ds-identify
policy loaded: mode=search report=false found=all maybe=all notfound=disabled
no datasource_list found, using default: MAAS ConfigDrive NoCloud AltCloud Azure Bigstep CloudSigma CloudStack DigitalOcean AliYun Ec2 GCE OpenNebula OpenStack OVF SmartOS Scaleway Hetzner IBMCloud Oracle Exoscale RbxCloud
DMI_PRODUCT_NAME=t3.small
DMI_SYS_VENDOR=Amazon EC2
DMI_PRODUCT_SERIAL=ec2972df-81d1-c72e-f54d-0da7741efa46
DMI_PRODUCT_UUID=DF7229EC-D181-2EC7-F54D-0DA7741EFA46
PID_1_PRODUCT_NAME=unavailable
DMI_CHASSIS_ASSET_TAG=Amazon EC2
FS_LABELS=any:scandir,any:scandir,any:scandir,any:scandir,var,config,deferred,logs,wk,boot,opt,root,notused,rescue
ISO9660_DEVS=
KERNEL_CMDLINE=BOOT_IMAGE=/vmlinuz-x.x.xx-x.xx..0.x86_64 ro root=LABEL=root quiet nmi_watchdog=2 fsck.repair=yes fips=1 elevator=noop rootdelay=300 console=ttyS0,115200n8 aws nvme_core.io_timeout=255 rootfstype=ext4
VIRT=kvm
UNAME_KERNEL_NAME=Linux
UNAME_KERNEL_RELEASE=x.x.xx-x.xx..0.x86_64
UNAME_KERNEL_VERSION=#1 SMP Thu Mar 21 13:43:44 UTC 2024
UNAME_MACHINE=x86_64
UNAME_NODENAME=mlos-tiny
UNAME_OPERATING_SYSTEM=GNU/Linux
DSNAME=
DSLIST=MAAS ConfigDrive NoCloud AltCloud Azure Bigstep CloudSigma CloudStack DigitalOcean AliYun Ec2 GCE OpenNebula OpenStack OVF SmartOS Scaleway Hetzner IBMCloud Oracle Exoscale RbxCloud
MODE=search
ON_FOUND=all
ON_MAYBE=all
ON_NOTFOUND=disabled
pid=734 ppid=722
is_container=false
is_ds_enabled(IBMCloud) = true.
ec2 platform is 'Unknown'.
is_ds_enabled(IBMCloud) = true.
No ds found [mode=search, notfound=disabled]. Disabled cloud-init [1]
[up 1.44s] returning 1
**cat cloud-init-generator.log**
/usr/lib/systemd/system-generators/cloud-init-generator normal=/run/systemd/generator early=/run/systemd/generator.early late=/run/systemd/generator.late
kernel command line (/proc/cmdline): BOOT_IMAGE=/vmlinuz-x.x.xx-x.xx.xx.x.x86_64 ro root=LABEL=root quiet nmi_watchdog=2 fsck.repair=yes fips=1 elevator=noop rootdelay=300 console=ttyS0,115200n8 aws nvme_core.io_timeout=255 rootfstype=ext4
kernel_cmdline found unset
etc_file found unset
default found enabled
checking for datasource
ds-identify rc=1
ds-identify _RET=notfound
**cloud-init is enabled but no datasource found, disabling**
already disabled: no change needed [no /run/systemd/generator.early/multi-user.target.wants/cloud-init.target]
[root@ip-xx-xx-xx-xx cloud-init]#
Version of the cloud init used : cloud-init-19.4-12
I have added the datasource_list in /etc/cloud/cloud.cfg
[root@ip-xx-xx-xx-xx ~]# cat /etc/cloud/cloud.cfg
users:
- default
disable_root: 0
ssh_pwauth: 0
mount_default_fields: [~, ~, 'auto', 'defaults,nofail,x-systemd.requires=cloud-init.service', '0', '2']
resize_rootfs_tmp: /dev
ssh_deletekeys: 1
ssh_genkeytypes: ~
syslog_fix_perms: null
disable_vmware_customization: false
datasource_list: [Ec2]
datasource:
Ec2:
metadata_urls: ["http://169.254.169.254:80"]
max_wait: 120
timeout: 50
strict_id: false
#/etc/hosts file will be replaced with the one in /etc/cloud/templates.
manage_etc_hosts: true
cloud_init_modules:
- disk_setup
- migrator
- bootcmd
- write-files
- growpart
- resizefs
- set_hostname
- update_hostname
- update_etc_hosts
- rsyslog
- users-groups
- ssh
cloud_config_modules:
- mounts
- locale
- set-passwords
- rh_subscription
- yum-add-repo
- package-update-upgrade-install
- timezone
- puppet
- chef
- salt-minion
- mcollective
- runcmd
cloud_final_modules:
- rightscale_userdata
- scripts-per-once
- scripts-per-boot
- scripts-per-instance
- scripts-user
- ssh-authkey-fingerprints
- keys-to-console
- phone-home
- final-message
- power-state-change
system_info:
default_user:
name: centos
lock_passwd: true
gecos: Cloud User
groups: [adm, systemd-journal]
sudo: ["ALL=(ALL) NOPASSWD:ALL"]
shell: /bin/bash
distro: rhel
paths:
cloud_dir: /var/lib/cloud
templates_dir: /etc/cloud/templates
ssh_svcname: sshd
# vim:syntax=yaml
I’m using the following user data to test the same.
Content-Type: multipart/mixed; boundary="//"
MIME-Version: 1.0
--//
Content-Type: text/cloud-config; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="cloud-config.txt"
#cloud-config
cloud_final_modules:
- [scripts-user, always]
runcmd:
- [ mkdir, /test-cloudinit ]
write_files:
- path: /test-cloudinit/cloud-init.txt
content: Created by cloud-init
--//
Content-Type: text/x-shellscript; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment; filename="userdata.txt"
#!/bin/bash
mkdir test-userscript
touch /test-userscript/userscript.txt
echo "Created by bash shell script" >> /test-userscript/userscript.txt
--//--
I am new to AWS. Kindly inform me if there is something I am overlooking. Thanks for any assistance.
2
Answers
Got the issues, Line number 102 (uuid = util.read_dmi_data('system-uuid')) in the cloudinit/sources/DataSourceEc2.py file's exception section was returning a value that did not begin with ec2.
I used the following patch to rebuild the cloud-init source rpm:. I made an AMI using the altered ISO. Following that, it began operating without issue, and the logs showed no errors.
This is was caused by a bug in cloud-init that affects only EC2. The UUID was reported in a different bytorder, which is technically a supported way for ec2 to identify itself. I just filed a PR to fix it.
Note: The patch you posted doesn’t match the documented way to identify ec2 instances, so I wouldn’t recommend doing it that way.