[00:58] <blahdeblah> `ip r` would be the preferred alternative to `netstat -rn` nowadays :-)
[01:00] <sarnold> .. I couldn't remember what 'netstat -rn' actually did, so didn't know what to suggest for the replacement ;)
[01:15] <blahdeblah> :)
[02:31] <genii> !ics
[07:15] <Mathisen> hello where can i find a uptodate guide on install landscape server and client
[07:17] <Mathisen> https://ubuntu.com/landscape/install does not seem to be
[12:41] <jamespage> cpaelzer: hey - I did a bit of work on a new rabbitmq-server release which I've uploaded to Debian experimental
[12:41] <jamespage> any reason why I would not sync that to Mantic?
[13:02] <cpaelzer> jamespage: hmm, it is not in sync-blocklist afaics
[13:02] <cpaelzer> nor does it have delta
[13:21] <jamespage> cpaelzer: I shall do so then
[13:21] <jamespage> fwiw I've already built and tested it on Mantic anyway :)
[19:50] <eldowan> I am trying to configure cloud-init on a VM, and everything works except network on boot. I have a 2 minute stop during boot at "Host and Network Name Lookups". After this aborts and I am able to login, I can run dhclient and receive a DHCP address immediately. This is on a clean install. How can I start to troubleshoot this?
[19:53] <eldowan> iops
[19:56] <blackboxsw> eldowan: systemd-analyze blame/systemd-analyzes critical-chain may help inspect problems. If the problem is in cloud-init logs: sudo cloud-init analyze show; sudo cloud-init analyze blame;    Some other docs here  https://cloudinit.readthedocs.io/en/latest/reference/faq.html#failing-to-complete-on-systemd.
[19:56] <blackboxsw> eldowan:  Also check journalctl -b 0  -o short-precise and compare against timestamps in /var/log/cloud-init.log to see what else may block cloud-init if you see cloud-init just sitting without logging anything for 2 mins
[19:57] <eldowan> I'll check the links.
[19:57] <eldowan> It _looks_ at a glance like it's only the network portion that causes issues. everything else completes -- hostname, user accounts, SSH keys, etc...
[19:58] <blackboxsw> yeah I'd expect invalid routes being setup or DNS incorrectly configured
[19:59] <eldowan> Hmm. non cloud-init clients have no problems starting up, and the other ubuntu, windows, & other VMs have no issues with DNS or routes. Simple flat network DHCP/DNS/gateway on the same router appliance (pfsense)
[20:01] <eldowan> systemd-analyze blame shows the culprit to be "systemd-networkd-wait-online.service" with a time of > 2 minutes and errors showing as generic timeout. I guess it's not a cloud-init issue
[20:02] <blackboxsw> grep "Applying network config" /var/log/cloud-init.log to see if the expected network config looks reasonable and compare against what you are seeing from 'ip addr' or 'ip route'  etc. /etc/netplan/50-cloud-init.yaml is the final network config emitted by cloud-init on ubuntu systems  
[20:03] <eldowan> 50-cloud-init.yaml looks pretty standard. I only have 1 NIC set to DHCP, and the MAC is correct. Will look at the cloud-init log 
[20:05] <eldowan> cloud-init.log shows the correct nameserver, search domain, mac, and device.
[20:09] <blackboxsw> given systemd-networkd-wait-online.service being your blocker there, the device in your network config isn't reporting itself as "up" and configured yet for some reason or other. I'd check the related network driver logs in journalctl -b 0 to see when the network device is found and driver is loaded, and the device reports online.
[20:11] <blackboxsw> note if you are using netplan.io version 0.106. there  may be MAC matching issues to be aware of if you NIC is a virtual nic. https://discourse.ubuntu.com/t/netplan-0-106-call-for-testing/33932/3 not sure if that applies to your situation or not
[20:12] <eldowan> Thanks, I'll take a look there too. Stuck at startup right now, not sure of netplan.io version. Just installed a clean copy of ubuntu server 22.04 and all the updates this morning, so whatever is in teh mainline is what I'm likely running
[20:14] <blackboxsw> ok netplan 0.106 not something to be concerned with on 22.04 yet as it's currently netplan 0.105
[20:19] <eldowan> OK, I think it must have be a self inflicted wound. in "journalctl -b 0" I see "eth0 ... failed to set IAID+DUID: No such file or directory" and then timeouts after a 2 minute gap. after looking for that error message, I found a reference to `systemd-machine-id-setup` and running that + reboot fixed the issue.
[20:20] <eldowan> I'm betting I tried to prepare the system for cloud init incorrectly and gunked something up by accident.
[20:20] <sarnold> what on earth is *that*? :)
[20:27] <eldowan> Oh, during my attempt to clean and prep the system I deleted the /etc/machine-id file and I think this is what's throwing it for a loop. I'd looked for some documents on prepping for cloud-init but I only found non-related ubuntu cloud docs
[20:29] <sarnold> that might still be worth a bug report; I wonder if it would make sense for $something during boot to generate a machine-id if it is missing?
[20:32] <eldowan> the root issues seems to be if I the file is missing from disk. If I `truncate -s 0` the file it comes up correctly. When this is the case, I do see in dmesg an alert about the missing file -- so it *does* seem to be half-caught
[20:39] <eldowan> Seems my issue is explictly out of bounds for startup: https://pasteboard.co/4HPNFkKATPSt.png
[20:40] <eldowan> Considering that the log output explictly doesn't allow booting properly with the file missing from disk, would it be worth opening a bug report? Seems maybe this is intended?
[20:41] <sarnold> wow that's a much better error report than I expected
[20:43] <eldowan> So i guess the network is brought up before /etc/ is remounted as rw? I'd have assumed I would fall under criteria 3 "/etc/machine-id is missing and /etc/ is writable." except at that moment /etc/ is ro.