| === seednode4 is now known as seednode | ||
| eoli3n | Hi | 12:19 |
|---|---|---|
| eoli3n | what's the way to run commands in chrooted autoinstall env with ubuntu ? | 12:19 |
| meena | 🤷🏻♀️ | 12:34 |
| meena | eoli3n: maybe the people in #ubuntu-server are better at answering this kind of question | 12:37 |
| eoli3n | i asked | 12:38 |
| eoli3n | thanks | 12:38 |
| === frickler is now known as frickler_pto | ||
| 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. | 16:45 |
| 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:09 |
| amansi26 | There is some syntax error in this file in my downstream branch v19.1 due to which systemd-tmpfiles-setup.service fails. | 17:10 |
| amansi26 | smoser: blackboxsw: Odd_Bloke: ^^ | 17:13 |
| 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:24 |
| Odd_Bloke | amansi26: What distro is this on? I don't believe upstream or Ubuntu ship such a file. | 17:35 |
| 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:37 |
| Odd_Bloke | tryfan: Can you pastebin /var/log/cloud-init.log from an affected instance? | 17:38 |
| tryfan | Odd_Bloke: pm'd | 17:41 |
| 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:03 |
| 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:05 |
| 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:08 |
| 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:14 |
| 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:15 |
| 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:17 |
| 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:18 |
| Odd_Bloke | tryfan: Can you pastebin your `cloud-init.service` definition? | 18:21 |
| tryfan | Odd_Bloke: sure https://paste.centos.org/view/fa86ce33 | 18:23 |
| 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:32 |
| tryfan | Odd_Bloke: I appreciate the assistance. I tried in #centos but I haven't gotten a response just yet | 18:39 |
| 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. | 18:46 |
| tryfan | Odd_Bloke: good plan, trying now | 19:00 |
| 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:35 |
| 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:49 |
| tryfan | thanks very much for the help, just talking it out is half the battle | 19:50 |
| Odd_Bloke | tryfan: :) | 20:20 |
| 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:28 |
| Odd_Bloke | tryfan: Might https://cloudinit.readthedocs.io/en/latest/topics/modules.html#resolv-conf help? | 20:32 |
| 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:46 |
| 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. | 20:47 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!