[01:12] <frez> Hi
[01:13] <frez> Have a customer deploying Azure VMSS from ARM Template and they occassionally encountere issue where the 'cloud_init
[01:14] <frez> fails with the creation of the users.
[01:14] <frez> Errors:
[01:14] <frez> Running module scripts-user (module 'cloudinit.config.cc_scripts_user' from '/usr/lib/python3/dist-packages/cloudinit/config/cc_scripts_user.py') failed
[01:15] <frez> Uploaded file: https://uploads.kiwiirc.com/files/9554647d9097f0555a5d6a787e1fd937/pasted.txt
[01: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') failed
[01:15] <frez> this doesnt look an issue on the image but most likely the 'cloud
[01:15] <frez> -'cloud_init' script failing.
[01:17] <frez> just like to know who i can reach out to on behalf of my customer for this issue.
[07:42] <tz0py> hi guys, is it possible to change root password on ubuntu with cloudinit?
[10:22] <jbg> a 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/266533
[10:22] <jbg> any ideas?
=== rbasak_ is now known as rbasak
[12:54] <Guest16> Hi ,I was trying to configure logdna via cloud-init
[12:54] <Guest16> i was wondering if there is any logdna module in could-init ?
=== Guest6437 is now known as andrewbogott
[14:36] <rharper> jbg: 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:37] <jbg> rharper: sure, will do!
[14:37] <rharper> falcojr: blackboxsw_ ^  looks like we're going to sort out what to do for newer udevd  
[15:04] <blackboxsw_> heya folks.
[15:06] <blackboxsw_> rharper  nice! jbg: Thanks for the headsup (and for running CI :) ) 
[15:08] <rharper> wondering what release that's in 
[15:09] <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] <ubottu> Pull 936 in canonical/cloud-init "Initial hotplug support (SC-19)" [Open]
[15:10] <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 platforms
[15:10] <blackboxsw_> ..... only a couple years since your initial spike :)
[15:11] <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/940
[15:11] <ubottu> Pull 940 in canonical/cloud-init "tools: add support for building rpms on rocky linux" [Open]
[15:29] <blackboxsw_> thanks for looking over it Ryan. I'll field those comments on his PR
[15:40] <rharper> blackboxsw_: jbg : https://github.com/systemd/systemd/issues/13035  which points to  https://github.com/systemd/systemd/commit/84ea567eb4326eb970a33188649fde6bea2a0d4e#diff-fd460a87ba85f4b05ee20317be02b21aR11
[15:40] <ubottu> Issue 13035 in systemd/systemd "New default.link file breaks previously working udevadm command" [Closed]
[15:40] <ubottu> Commit 84ea567 in systemd/systemd "udev,network: warn when .link or .network file has no [Match] section"
[16:15] <jbg> aha.
[16:15] <jbg> that definitely looks like the issue
[16:50] <rharper> so maybe systemd regression or some distro udev without that fix ;  
[16:52] <rharper> oh, 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