blackboxswholmanb: I can confirm password authentication still works on jammy for "tom" per our integration tests. So we can be sure something didn't degrade as far as functionality or behavior in that respect. Digging further to assess the mechanics of the integration test failure and what useradd is doing under the hood that converts the hashed password to yescrypt00:21
blackboxswon Jammy 00:21
holmanbblackboxsw: +1 sounds good thanks for digging into that00:22
esvhey folks, I am trying to deploy a vm with a populated home directory, unfortunately the cloud-init version my deployment is using does not support the defer opion yet for write_files00:57
esvis there an alternate way to delay write_files? 00:58
esvI am using 20.2 00:58
kags2100blackboxsw Hey, did you find something in the logs?09:54
ClouduserHi, I am looking for ansible role for cloudinit or cloud cfg jinja2 template14:13
holmanbClouduser: Making sure I understand: You are trying to use ansible to create cloud-configs?15:37
holmanbClouduser: I don't know if you have seen this already, but I see an ansible role one galaxy related to cloud init that points to this github repo: https://github.com/mrlesmithjr/ansible-cloud-init15:38
holmanbClouduser: if you are asking about launching ansible on an instance using cloud-init, we don't have a module for that at this time.15:39
esvhey folks, about creating once per instance scripts, are these created using write_files? 16:00
esvI don't see a key in the documentation, just making sure I'm not missing anything 16:01
falcojresv: yes, that's one way. There's also an open PR to allow creating such scripts in userdata as part of a multipart mime message16:05
falcojrblackboxsw: I noticed while playing with https://hackmd.io/ilz5fDx_RpiofaMsO1B8KA?view (great write-up btw!) that I think LXD VMs aren't detecting the LXD datasource when they should16:16
falcojron a jammy VM, ds-identify says it only found NoCloud, even though /dev/lxd/sock exists16:17
falcojrand LXD is in the datasource list16:17
falcojrin /etc/cloud16:18
falcojrdon't really know the details of that particular file, but wondering if it doesn't exist until after ds-identify looks for it16:20
blackboxswfalcojr: thanks, as we just chatted, I was under the impression that no systems should actually come up from cloud-init as discovering LXD from the python code because cloudimage metadata still defines NoCloud template configuration which forces NoCloud datasource in front of LXD. As you clarified, we still want ds-identify to detect maybe/yes for LXD as a possible datasource to datasource match. 17:38
blackboxswAs we discussed, we think LXD VM specifically not detecting /dev/lxd/sock is a race condition due to a latent lxd-agent setup and configuration in the client (which also prevents us from ssh ing into the VM early in boot as well). I don't think this affects the container images because the lxd-agent is activated in the images sooner. But yes let's card or bug it up and dig into that for LXD datasource support of VMs.17:40
minimalanyone free to review my cloud-utils PR #35?17:43
blackboxswfalcojr: holmanb LXD VM might be racy with the fact that /dev/lxd/sock file looks to get removed/recrated during lxd handler setup here https://github.com/lxc/lxd/blob/master/lxd-agent/devlxd.go#L226 ?17:47
blackboxswminimal: what's the link sorry?17:48
ubottuPull 35 in canonical/cloud-utils "growpart: Add support for overprovisioning" [Open]17:48
blackboxswminimal: ahh thx I misread cloud-init PR #35 and got lost :/17:57
blackboxswwill get an initial review on that today17:58
blackboxswcontext intent and docs look good. will test it out.18:00
minimalblackboxsw: thanks18:03
kags2100blackboxsw Hey, sorry I can't see if you replied to my bug-report logs, did you have to look it over?18:19
blackboxswkags2100: no worries I saw you dropped out of IRC earlier and was waiting for a ping. Your cloud-init.tar.gz isn't attached to the bug https://bugs.launchpad.net/cloud-init/+bug/1960360 I was going to launch an instance with some semblance of your user-data but didn't get around to it yet today. Do you have /var/log/cloud-init.log handy? If not I'll launch a VM today and double check18:21
ubottuLaunchpad bug 1960360 in cloud-init "package_reboot_if_required breaks power_state: shutdown" [Undecided, New]18:21
kags2100blackboxsw It isn't? I can see it as being attatched: Bug attachments18:25
kags2100cloud-init.tar.gz (edit)18:25
kags2100Add attachment18:25
kags2100But I also added it as a comment, if that helps?18:25
kags2100I can get it for you, if you can't use the log I already attached?18:26
blackboxswkags2100: for your other comment  "Btw, is there a way to manually set the user-data file while inside the VM? Right now I have to re-create the VM each time to pass the user-data file. Would be great if I could use that schema verification tool you showed me!" You should generally be able to use `sudo cloud-init clean --logs;` to make sure cloud-init now views the machine as green-field, (fresh boot of a new system) so all 18:26
blackboxswcloud-init config operations would/should run again18:26
blackboxswkags2100: if you wanted to walk through all cloud-init's boot stages individually without rebooting I think it's something like `sudo cloud-nit init --local; sudo cloud-init init; sudo cloud-init  modules --mode=config; sudo cloud-init modues --mode=final`  These are the stages cloud-init systemd services exec during boot process as seen by `cat /lib/systemd/system/cloud-*`18:28
blackboxswrechecking the bug again18:28
blackboxswstrange, now I see the attachement thanks18:28
kags2100blackboxsw Yeah, did try that before, but had some issues where it didn't take the new UserData properly. But I'll try again, might just be that I had a formatting error, didn't really look into it much.18:28
kags2100blackboxsw Hm, I'll try it out later this week then, thanks!18:30
blackboxswkags2100: ok cloud-init analyze show -i <your_cloud-init_logs> shows three reboots on that system. I'll dig in now to see what's up18:30
blackboxswkags2100: during first boot cloud-init marked a semaphore file due to successful run of |`->config-power-state-change ran successfully @111.93800s +00.01900s18:31
blackboxswthe 2nd boot it says is skipped due to that semaphore (because >config-power-state-change runs only once per instance-id change) `|`->config-power-state-change previously ran @15.37300s +00.00100s`18:32
blackboxswand 3rd boot it also ignores it `|`->config-power-state-change previously ran @15.04100s +00.00000s`18:32
blackboxswso during the first boot I'm thinking the /var/run/reboot-required flag didn't exist on the system.18:33
kags2100Well that's weird that it reboots 3 times. It should only reboot once? That's the behavior I've seen at least18:33
blackboxswI'll check the more details logs now to see what happened first boot18:34
kags2100Yeah great18:34
blackboxswquick review minimal on your PR. not sure what thoughts/preferences  you have for typical over-provisioning use-cases.18:37
blackboxswI dropped comments in the PR18:37
blackboxswkags2100: ok I see tracebacks there in logs pointing to IO errors from invoking /sbin/reboot18:42
blackboxswcloudinit.subp.ProcessExecutionError: Unexpected error while running command.   18:42
blackboxswCommand: ['/sbin/reboot']                                                       18:42
blackboxswExit code: -                                                                    18:42
blackboxswReason: [Errno 5] Input/output error    18:42
blackboxswthat's the symptom/problem  on this system18:42
blackboxswgrep Traceback /var/log/cloud-init.log18:43
kags2100Hm okay18:43
kags2100So what does mean?18:43
blackboxswcloud-init status --long on the system generally should also surface these errors to you.   18:45
blackboxswkags2100: I'm grasping at straws but your journalctl -b 0  shows "kernel reports TIME_ERROR: 0x41: Clock Unsynchronized" which can cause a mess of issues on a system if you have bogus clock values 18:46
kags2100blackboxsw Hm, true, but dosn't the system sync on boot? I did set the time service correct right? Also the VM has all outbound ports open, so that shouldn't be an issue either.18:48
blackboxswkags2100: sorry am being pulled into interview prep at the moment. But investigating why /sbin/reboot isn't firing in that environment is likely our source of probs18:48
kags2100blackboxsw No worries, thanks for all the help so far! Yeah, I'll try to look into it too later!18:49
blackboxswno worries, any findings lets put in the bug18:50
kags2100Sure thing!18:50
minimalblackboxsw: re: typical over-provisioning use cases - I use it for physical machines (e.g. Raspberry Pis with SD cards) where I only partition 90% of the SD card19:06
kags2100blackboxsw Was just able to fix this! Needed to add a serial socket to the VM, so the Input/output error makes sense now! Added the fix to the report, but not sure I close it. Thanks for all your help though!20:57
blackboxswwoot!. thanks kags2100 for getting to the bottom of it !21:37
kags2100blackboxsw Well thanks for the support :)21:52
kags2100blackboxsw Another question, my plan is to deploy a base template using the User-Data file. Then after run cloud-init clean, from that template I can then provision new VMs that are then setup for their specific purpose, like Docker Server, etc. Is this a good idea?21:56
apple-corps[m]I'm having trouble getting a user-data script deployed by terraform to a custom ami executed or seeing debugging information. I had a look at /var/lib/cloud/instance/user-data.txt and see the contents of the script deployed. There seems to be a cloud-init systemd unit on the system. When I set an invalid hostname in the script I recieved an error. However after removing I don't see any of the script actions take place, no error22:14
apple-corps[m]logs, etc.22:14
apple-corps[m]Can any cloud-init folks help me debug?22:14
apple-corps[m]Posted a greater question to the mailing list22:32
blackboxswapple-corps[m]: so `sudo cloud-init devel schema --system` should tell you if your user-data is valid for the system22:35
apple-corps[m]Vlid cloud-config: system userdata22:35
blackboxsw+1. step 1 unlocked :) any script output that is run will be emitted to /var/log/cloud-init-output.log by default. So errors or traces might show up there 22:36
apple-corps[m]So how can I tell what user the cloud-config is executed as? For example I added a line - echo "" > /tmp/cc under the runcmd: . I don't see the file created but almost any user should be able to write to /tmp/22:38
apple-corps[m]Not seeing any logs in journalctl related to this22:38
blackboxswapple-corps[m]: would have the ability to past the user-data so we can see the intent? `sudo cloud-init query userdata |  pastebinit` should drop your entire userdata to paste.ubuntu.com22:41
blackboxswapple-corps[m]: beware if you have passwords in user-data^22:41
blackboxswapple-corps[m]: runcmd section should write out a runcmd file in /var/ somewhere that cloud-init executes after converting the YAML content to shell via a shellify function. you'd be able to find that script output written with `grep runcmd /var/log/cloud-init.log`22:43
blackboxswI'll fire off a container to double check the script file written by cloud-init. you'd be able to attempt to re-run that runcmd script on the live system after cloud-init boot to see if it fails as you expect or has bad formatting or something else22:43
blackboxsw  /var/lib/cloud/instances/t-j/scripts/runcmd is what you want22:45
blackboxswwhere "t-j" is your instance name22:45
blackboxswif that script doesn't run the way you expect, something is off with your runcmd: YAML content22:46
blackboxswand/or your might have a traceback or warning in /var/log/cloud-init.log that tells "Failed to shellify"22:48
blackboxswthis error would be seen on a system with `cloud-init status --long`22:48
apple-corps[m]blackboxsw: I'll get back with this in a short while.22:59
blackboxswno worries reponded in mailinglist too23:01
apple-corps[m]I can't send the file from the host but I can reproduce and share here23:44

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