[02:21] hey everyone i sm having all kinds of issues with yaml. when i add the 2 networks and then run netplan apply it just keeps saying the same error over and over [02:21] /etc/netplan/50-cloud-init.yaml:7:11: Error in network definition: bond0: interface 'enp0s25' is not defined [02:21] - enp0s25 [02:21] ^ [02:22] erm the ^ is pointing at the e [03:49] running into an odd issue using cifs-utils to mount a share from Windows Server on my Ubuntu Server. I can access just fine, but I cannot seem to for whatever reason delete any files, and some programs are saying they can't access the folders. Is there some way of mounting that would fix this? or has anyone in here ever tried this type of setup? I'm thinking it's a permission issue between windows/ubuntu svr yet I'm not even sure where to [03:49] look for it [03:55] I may have found the solution to this issue, sharing a root drive is something windows flat will not do, I moved the library to a folder inside the drive, shared that, and will know in a moment if it fixed it [07:18] Good morning === cpaelzer__ is now known as cpaelzer [14:55] Is there a specific channel for Canonical kubernetes (install) issues? [15:06] TJ-: https://wiki.ubuntu.com/IRC/IrcTeam/Scope [15:07] TJ-: Then again, there are channels that aren't listed, like #netplan, so maybe there's an unofficial channel. [15:08] mason: indeed; with snaps its got stuipidly difficult to figure out where support should be [15:10] TJ-: Ah, https://ubuntu.com/kubernetes/docs/get-in-touch notes #cdk8s [15:11] mason: nice find! thanks [15:12] I tried querying alis but without result [15:12] Q: I am lookinv for docs on what modules come in linux-modules-extra. I knew (of old) of some sort of docs, but I cannot find it anymore. Anyone has a pointer? === hggdh is now known as hggdh-msft [15:14] hggdh-msft: something like this https://packages.ubuntu.com/focal/amd64/linux-modules-extra-5.4.0-14-generic/filelist maybe? [15:14] hggdh-msft: There's always https://packages.ubuntu.com/ or just downloading the package and breaking it open. [15:18] yes, I looked at it (and this is how I found bout the module I needed). But what I am missing, for the client is some wording on why, and how it was split into tewo packages [15:19] (actually I found it via apt-file search gtp.ko first) [15:24] hggdh-msft: For "why" you'd need to maintain the package maintainer. [15:24] or email him [15:25] ENOCOFFEE [15:26] apw, methinks... will ping him [15:26] oh, already done :-) [20:09] I've got a headless ubuntu server runninng. ISP has gone out twice in the past week and both times the network will not recover on this machine. Has never been an issue before and restarting systemd-networkd does not solve the issue. Full reboot required. Any way to troubleshoot for a solution? [20:10] thelounge5173: Did you try ifdown/ifup ? [20:11] mason I didn't. I can try and replicate this issue to see if that solves it. But I'm hoping it's a configuration issue causing it to not come back automatically. [20:11] Then again, I'm only probably 90% certain those exist for netplan. [20:11] yeah, ifdown "command not found" [20:12] thelounge5173: firstly, if SD-ND restart doesn't bring it back up, and it's a regular wired Ethernet that suggest a hardware/link issue [20:12] Hrm. I don't think 'netplan apply' matters here since you're not changing the config. What happens when you... do you say "restart systemd-networkd" or do you say "stop" and then "start"? [20:13] mason I tried both [20:13] TJ-: Aren't there cases where restart won't work but stop/start will? ISTR reading something to that effect recently. [20:13] kk [20:13] TJ- I tried swapping out the cable before restarting thinking it could have been a connection issue. also tried different switch port. no luch [20:13] mason: I think those only apply to the semantics of how SD tries to restart a service [20:13] luck*. Only system reboot fixed it so far [20:14] thelounge5173: how about checking the kernel log? seeing what 'ethtool' reports... could be a power-save issue. would help to know the exact hardware "lspci -nn -d ::0200" [20:15] Intel Corporation Ethernet Controller 10-Gigabit X540-AT2 [20:15] TJ-: Are there any relevant logs from the ineffective restart attempts? [20:15] thelounge5173: "journalctl -b -1" would show the log from the last boot. -2 -3 -4 the previous boots and so on [20:16] Only think in syslog with 'ethtool' in it: https://pastebin.com/YUfusQrf [20:16] thelounge5173: what is the [vendor:device] that lspci -nn reports at end of line [20:16] full line: 05:00.0 Ethernet controller [0200]: Intel Corporation Ethernet Controller 10-Gigabit X540-AT2 [8086:1528] (rev 01) [20:18] thelounge5173: so the driver for that is "grep -i '8086.*1528' /lib/modules/$(uname -r)/modules*" => " /lib/modules/5.3.0-25-lowlatency/modules.alias:alias pci:v00008086d00001528sv*sd*bc*sc*i* ixgbe " [20:20] thelounge5173: try to identify a boot where the link didn't come back up from "journalctl --list-boots" ... then, if for example you decide it was -4, do 'pastebinit <( journalctl -b -4 -u systemd-networkd)" and give us the link [20:21] well it's not that it doesn't come back from boot, it just doesn't come back when the internet goes down and comes back up (ISP outage) [20:21] not sure if that's different. [20:24] thelounge5173: I know... what I'm hoping you can find is a boot where that happened, so we can find clues in the logs when the link doesn't come back up [20:25] ah [20:26] well FWIW it's not that SD-ND never came back, its status was showing as running, but there was no network on my interface [20:26] does that matter? [20:27] thelounge5173: no... we're hunting clues. if the SD-ND log doesn't help we'll widen the scope and grab the kernel log for that boot, instead [20:28] 10-4 [20:28] thelounge5173: it could be the link comes back up but fails to gain an IP address, for example, which would point to a DHCP issue [20:28] ah [20:28] got it [20:28] ooo... CB speak, good-buddy :) [20:29] :P [20:29] Ok, so nothing wrong that i can tell with journalctl's boot logs [20:31] thelounge5173: if the ISP link does down, presumably the PC itself is connected to a gateway/router on your LAN, so the wired link shouldn't change in any respect [20:31] thelounge5173: in which case the issue could be in the gateway device [20:31] So my router? [20:31] Possible. I've been meaning to increase the DHCP range in case I do hit the limit since I do have a good chunk blocked off for static IPs [20:32] well, although this server has a static IP [20:32] but could be another issue with it I suppose (the gateway I mean) [20:33] thelounge5173: so when the ISP drops does the server lose its IP address? is it IPv4, IPv6, or both? how are you determining the network doesn't recover - what tests are you doing [20:33] thelounge5173: e.g. is it only name resolution that fails, which would point to DNS not connectivity [20:34] no. I'm unable to shell into it from the same network or outsite, opening a console on the physical machine I'm unable to 'ping google.com' OR 'ping 8.8.8.8' [20:34] 'ip addr' shows no IP set for that interface either [20:35] thelounge5173: so it loses the IPv4 address, yet you say it is set to static? [20:35] yes [20:35] unless I didn't set that up properly [20:35] thelounge5173: is it 'static' as in set on the server via netplan or systemd-networkd config, or 'static' in the DHCP server? [20:35] but it does have the proper IP address :P [20:36] here's my /etc/netplan/50-cloud-init.yml: http://paste.ubuntu.com/p/hJYyBkjGQk/ [20:36] so on the host itself [20:38] thelounge5173: the weird part is the interface losing the IPv4 ... that would generally only happen if the Ethernet link itself drops. When the ISP link fails does the gateway device reboot or do anything else 'weird' ? [20:38] nope [20:38] checking uptime of the gateway just to be sure... [20:39] well.. maybe something happened: uptime: 4h 50m 44s [20:39] so yeah, something did happen with the gateway [20:42] thelounge5173: so let's imagine a scenario. Server starts, link to router/gateway comes up, everything fine. ISP link drops, for some reason the gatway device powers off/restarts, which means the Ethernet link to server drops, so SD-ND removes the IP address... link comes back up but for some reason SD-ND doesn't reset the IPv4 [20:42] thelounge5173: is the ISP device the same as the LAN gateway? [20:43] no [20:43] Got a USG for the gateway [20:46] Interesting it rebooted. My server or Pi didn't, but there is a UPS. I would swear that the USG is on that UPS but can't confirm until I get home. [20:46] which is curious why the gateway rebooted.... [20:47] But regardless, still unusual that SD-ND didn't reset the IPv4. Even after I restarted its service. [20:48] thelounge5173: if the link dropped the IPv4 would be removed... not sure if it'd be re-added on link returning I'd have to test that, but I think it does. What is weirder is restarting SD-ND not restoring it