[12:19] <eoli3n> Hi
[12:19] <eoli3n> what's the way to run commands in chrooted autoinstall env with ubuntu ?
[12:34] <meena> 🤷🏻‍♀️
[12:37] <meena> eoli3n: maybe the people in #ubuntu-server are better at answering this kind of question
[12:38] <eoli3n> i asked
[12:38] <eoli3n> thanks
[16:45] <tryfan> Hopefully a common problem...I'm running cloud-init 19.4 on centos 7.9, cloud-init service shows network is up and dhcp has been completed, cloud-config runs directly afterward, but it can't resolve any hosts for the package updates.  After this, I can ping and yum update as per normal.
[17:09] <amansi26> Hi.. I have a query about /usr/lib/tmpfiles.d/cloud-init.conf file . how this file get generated. If I wanted to change something on this file. Where can I made change to?
[17:10] <amansi26> There is some syntax error in this file in my downstream branch v19.1 due to which systemd-tmpfiles-setup.service fails.
[17:13] <amansi26> smoser: blackboxsw: Odd_Bloke: ^^
[17:24] <meena> tryfan: this sounds familiar, and might have to do with NetworkManager. i think one of our redhat people has been working on a fix for that
[17:35] <Odd_Bloke> amansi26: What distro is this on?  I don't believe upstream or Ubuntu ship such a file.
[17:37] <tryfan> meena: we were doing lots of work disabling NM, and I'm trying to play by the rules with a new build, this is just making it tough
[17:38] <Odd_Bloke> tryfan: Can you pastebin /var/log/cloud-init.log from an affected instance?
[17:41] <tryfan> Odd_Bloke: pm'd
[18:03] <Odd_Bloke> tryfan: Thanks!  Looking at that, cloud-init seems to have behaved as I would expect.  If you examine the journal alongside cloud-init.log, does it appear that cloud-init's 'init' step is actually running after networking is up?  ("2020-11-26 16:16:21,602 - util.py[DEBUG]: Cloud-init v. 19.4 running 'init' at Thu, 26 Nov 2020 16:16:21 +0000. Up 8.52 seconds." is the relevant timestamp/line from your log.)
[18:05] <tryfan> Odd_Bloke: yes, network manager startup is complete after successful DHCP client run, states both CONNECTED_LOCAL and CONNECTED_SITE, default route is set, etc. I'll paste that bit from the logs
[18:08] <Odd_Bloke> tryfan: Hmm, that does look how I expect; I don't really have much CentOS experience so I'm out of ideas I'm afraid.  otubo might be able to help more?
[18:14] <tryfan> Odd_Bloke: right after cloud-init finishes, I see a NetworkManager restart.  did cloud-init request that?  if the network is really an issue, I'd be able to troubleshoot if I could stop the execution right there
[18:15] <tryfan> Nov 26 16:18:55 nc-vmware-packerbuild-3021 cloud-init: Cloud-init v. 19.4 finished at Thu, 26 Nov 2020 16:18:55 +0000. Up 14.61 seconds ; then ; Nov 26 16:18:55 nc-vmware-packerbuild-3021 echo: try restart NetworkManager.service
[18:17] <Odd_Bloke> tryfan: I don't believe so; if you examine the journal with `-o short-precise` then you can see the exact timings and compare.
[18:18] <Odd_Bloke> (But cloud-init expects network configuration to be fully applied much earlier than this, so it would be surprising if it were responsible.)
[18:21] <Odd_Bloke> tryfan: Can you pastebin your `cloud-init.service` definition?
[18:23] <tryfan> Odd_Bloke: sure https://paste.centos.org/view/fa86ce33
[18:32] <Odd_Bloke> tryfan: Hmm, yeah, that's what I would expect.  Not sure what's going on, I'm afraid; have you tried asking in CentOS support channels?
[18:39] <tryfan> Odd_Bloke: I appreciate the assistance.  I tried in #centos but I haven't gotten a response just yet
[18:46] <Odd_Bloke> tryfan: One thought I had: if you can insert a sleep before cloud-init.service runs (perhaps with ExecStartPre?), you might be able to figure out if this is a "simple" race condition (where cloud-init is incorrectly being started before networking is _really_ ready, somehow) or if there's something deeper going on.
[19:00] <tryfan> Odd_Bloke: good plan, trying now
[19:35] <tryfan> Odd_Bloke: putting a 10s delay did nothing, and I did confirm the delay is functioning.  then I figured out that cloud-final is the service that restarts network manager
[19:49] <tryfan> Odd_Bloke: Got it, I disabled the NM reload and discovered that cloud-init is rewriting resolv.conf and the reload is restoring it.
[19:50] <tryfan> thanks very much for the help, just talking it out is half the battle
[20:20] <Odd_Bloke> tryfan: :)
[20:28] <tryfan> Odd_Bloke: I guess the next step is to figure out how to add search domains to NM while not disrupting resolv.conf directly
[20:32] <Odd_Bloke> tryfan: Might https://cloudinit.readthedocs.io/en/latest/topics/modules.html#resolv-conf help?
[20:46] <meena> so i'm looking at cc_puppet.py, and it hasn't seen love in a long time… and i think the last time i was looking at this, i was wondering… what does a version × distros × other sources config look like? i don't know, but what i do know is that Puppet 4 is EOL.
[20:47] <meena> and while Puppet 5 is on its way out, too, a lot of the distro versions we support still have that in their repos.