/srv/irclogs.ubuntu.com/2021/07/12/#cloud-init.txt

frezHi01:12
frezHave a customer deploying Azure VMSS from ARM Template and they occassionally encountere issue where the 'cloud_init01:13
frezfails with the creation of the users.01:14
frezErrors:01:14
frezRunning module scripts-user (module 'cloudinit.config.cc_scripts_user' from '/usr/lib/python3/dist-packages/cloudinit/config/cc_scripts_user.py') failed01:14
frezUploaded file: https://uploads.kiwiirc.com/files/9554647d9097f0555a5d6a787e1fd937/pasted.txt01:15
frez[ 167.124968] cloud-init[2341]: 2021-06-25 10:27:34,980 - util.py[WARNING]: Failed running /var/lib/cloud/instance/scripts/part-001 [137]01:15
frez[ 167.163108] cloud-init[2341]: 2021-06-25 10:27:35,040 - cc_scripts_user.py[WARNING]: Failed to run module scripts-user (scripts in /var/lib/cloud/instance/scripts)01:15
frez[ 167.187380] cloud-init[2341]: 2021-06-25 10:27:35,040 - util.py[WARNING]: Running module scripts-user (module 'cloudinit.config.cc_scripts_user' from '/usr/lib/python3/dist-packages/cloudinit/config/cc_scripts_user.py') failed01:15
frezthis doesnt look an issue on the image but most likely the 'cloud01:15
frez-'cloud_init' script failing.01:15
frezjust like to know who i can reach out to on behalf of my customer for this issue.01:17
tz0pyhi guys, is it possible to change root password on ubuntu with cloudinit?07:42
jbga deployment of mine using cloud-init has started failing to boot in CI. I suspect it's due to systemd 249. the error is during netplan.py render_network_state, and it fails to run `udevadm test-builtin net_setup_link /sys/class/net/lo` with exit code 1 and this output: https://0paste.com/26653310:22
jbgany ideas?10:22
=== rbasak_ is now known as rbasak
Guest16Hi ,I was trying to configure logdna via cloud-init12:54
Guest16i was wondering if there is any logdna module in could-init ?12:54
=== Guest6437 is now known as andrewbogott
rharperjbg: thanks for the paste, that does look like a systemd/udevd issue, can you file a bug (ubuntu bug cloud-init I think should work, or cloud-init collect-logs  on a failed instance and attach log to launchpad bug)  14:36
jbgrharper: sure, will do!14:37
rharperfalcojr: blackboxsw_ ^  looks like we're going to sort out what to do for newer udevd  14:37
blackboxsw_heya folks.15:04
blackboxsw_rharper  nice! jbg: Thanks for the headsup (and for running CI :) ) 15:06
rharperwondering what release that's in 15:08
blackboxsw_rharper: speaking of udev ... I'm wrapping up testing on falcojr's hotplug iteration branch today based on your branch from 4 years ago :)   (wanted to check on Rocky to see how it handles sysconfig dev hotplug first) https://github.com/canonical/cloud-init/pull/936  15:09
ubottuPull 936 in canonical/cloud-init "Initial hotplug support (SC-19)" [Open]15:09
blackboxsw_my plan was to try to get that PR in and upload to impish early this week so we can get some bake time and exercise some of this in public cloud images on multiple platforms15:10
blackboxsw_..... only a couple years since your initial spike :)15:10
blackboxsw_paride: or others, I put up a minor tooling PR for building rpms on Rocky with our scripts https://github.com/canonical/cloud-init/pull/94015:11
ubottuPull 940 in canonical/cloud-init "tools: add support for building rpms on rocky linux" [Open]15:11
blackboxsw_thanks for looking over it Ryan. I'll field those comments on his PR15:29
rharperblackboxsw_: jbg : https://github.com/systemd/systemd/issues/13035  which points to  https://github.com/systemd/systemd/commit/84ea567eb4326eb970a33188649fde6bea2a0d4e#diff-fd460a87ba85f4b05ee20317be02b21aR1115:40
ubottuIssue 13035 in systemd/systemd "New default.link file breaks previously working udevadm command" [Closed]15:40
ubottuCommit 84ea567 in systemd/systemd "udev,network: warn when .link or .network file has no [Match] section"15:40
jbgaha.16:15
jbgthat definitely looks like the issue16:15
rharperso maybe systemd regression or some distro udev without that fix ;  16:50
rharperoh, and I missed your line about passing in /sys/class/net/lo  ;  that's surprising, other possiblities are LOOPBACK is not configured in kernel (or it's a module an not loaded);    or, there's something in the network config that lists 'lo' as a device that netplan needs to configure;    there's no reason for us to attempt to try to "rename" lo  ... I don't think;  I can't say we've ever tested that 16:52

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!