| === chris14_ is now known as chris14 | ||
| === blackboxsw is now known as blackboxsw_away | ||
| === ctcphelper is now known as CISHNIK | ||
| === shokohsc51 is now known as shokohsc5 | ||
| stenno | good day, during installation of ubuntu-server, after completing the installation, it immediately starts 'unattended-upgrades'. I cannot opt out of this from the instsaller menu. Pressing the 'Cancel update and reboot' button just continues the update, and i cannot reboot the vm via hypervisor as the machine is 'busy'. | 10:16 |
|---|---|---|
| stenno | This was the state of my installer (minus the last two lines) for about 20 minutes https://i.imgur.com/EA4dEUY.png | 10:16 |
| stenno | in the 'full log', i could still see packages being unpacked and prepared | 10:17 |
| stenno | is this a known issue? | 10:17 |
| === JanC_ is now known as JanC | ||
| === shokohsc51 is now known as shokohsc5 | ||
| === smoser1 is now known as smoser | ||
| === blackboxsw_away is now known as blackboxsw | ||
| === shokohsc57 is now known as shokohsc5 | ||
| === CodeMouse92 is now known as Guest2830 | ||
| === Guest2830 is now known as CodeMouse92 | ||
| znf | How the hell do you dhcpv6 client in netplan? | 21:47 |
| rfm | znf, "dhcp6: yes" in the device entry | 21:51 |
| znf | enp0s6: Re-configuring with /run/systemd/network/10-netplan-enp0s6.network | 21:54 |
| znf | enp0s6: DHCPv4 connection considered critical, ignoring request to reconfigure it. | 21:54 |
| znf | enp0s6: DHCPv6 lease lost | 21:54 |
| znf | enp0s6: DHCPv4 address 10.0.0.196/24 via 10.0.0.1 | 21:54 |
| znf | enp0s6: Re-configuring with /run/systemd/network/10-netplan-enp0s6.network | 21:54 |
| znf | enp0s6: DHCPv4 connection considered critical, ignoring request to reconfigure it. | 21:54 |
| znf | oops | 21:54 |
| znf | too many lines, my bad | 21:54 |
| znf | but if I dhclient -6 enp0s6, it works just fine | 21:56 |
| rfm | znf, well always worked for me (in fact I had considerable trouble turning it off because I didn't want it.) I suspect there's something in the router advertisements that controls this, but I don't know what. | 22:06 |
| rfm | znf: look at https://netplan.readthedocs.io/en/stable/netplan-yaml/ and search for dhcp6, note the bit about "autoconfiguration will ... only use DHCP if requested in the RA: | 22:08 |
| rfm | znf, and ipv6 address autoconfiguration is all done in the kernel, dhclient shouldn't need to be involved. | 22:10 |
| znf | well, this provider uses dhcpv6 not slaac | 22:12 |
| znf | and the only way to test the functionality is with dhclient | 22:13 |
| znf | unelss you know a better one | 22:13 |
| rfm | znf, I suppose you could try "accept-ra: no" to tell it not to pay attention to the router advertisements | 22:19 |
| rfm | znf: if that works probably should talk to the provider about fixing their RAs | 22:19 |
| znf | let's see | 22:20 |
| znf | nope, still loses it instantly | 22:21 |
| znf | weird | 22:21 |
| rfm | znf, beginning to sound to me like the dhcpv6 server is busted | 22:22 |
| znf | why would it work with dhclient -6 then? | 22:22 |
| rfm | znf, couldn't say. something about the mac address being used, or the lease time is different maybe. sniffing the packets (e.g. wireshark) might give clues. | 22:24 |
| rfm | znf ah, I looked at https://bugs.launchpad.net/ubuntu/+source/systemd/+bug/1776013 (which doesn't really seem to be the same problem) and it reminded me that it's systemd-networkd handing DHCPV6, not the kernel (which should just do SLAAC) | 22:29 |
| -ubottu:#ubuntu-server- Launchpad bug 1776013 in systemd (Ubuntu) "systemd-networkd: DHCP lease lost (Ubuntu 18.04)" [Undecided, Invalid] | 22:29 | |
| znf | lemme see | 22:30 |
| rfm | znf, is it at all possible you have two systems on this net using the same MAC? This can happen with cloned VMs, or with virtualbox VMs bridging to a wireless connection | 22:39 |
| znf | nope | 22:39 |
| znf | this is on a public cloud | 22:39 |
| znf | specifically oracle's public cloud | 22:39 |
| znf | I'm fairly positive they have everything neatly isolated | 22:40 |
| rfm | znf, did you check (with "ip -6 a" to see if there was a non-SLAAC ipv6 addr after the netplan apply? presumably if it "lost its lease" it should then request a new ip and use that. | 22:48 |
| znf | yes, there's only the link local address | 22:49 |
| rfm | znf, well, I'm baffled. Seems Oracle Cloud's dhcp server and systemd-networkd's dhcp client don't like each other. Hard to believe you are the first one to hit this. | 22:52 |
| znf | can't find any info anywhere | 22:52 |
| znf | it *should* be automatically configured by cloud-init | 22:52 |
| znf | but it doesn't seem to be | 22:52 |
| znf | I _am_ getting the routes tough | 22:52 |
| rfm | znf, well, it does seem to be configured, the "lost lease" message shows networkd is trying to get an address, it's just failing. | 22:53 |
| znf | https://i.imgur.com/tUORaAD.png | 23:04 |
| znf | oh, ok | 23:04 |
| znf | > One of the systemd developers confirmed the issue lies with malformed DHCP packets sent by OCI: | 23:04 |
| rfm | znf, yeah, now that I get the google query right it's all over. | 23:39 |
| === hyperreal5 is now known as hyperreal | ||
| minimal | znf: you should raise this on either the cloud-init channel or as an issues on the cloud-init github repo | 23:53 |
| znf | they're aware already | 23:53 |
| minimal | znf: hadn't noticed anything in either place | 23:54 |
| rfm | not sure what c-i could do about this. I did notice systemd has already integrated a change to ignore the bogus junk, but no doubt will be a while before that gets in a systemd release and even longer before it gets to ubuntu | 23:59 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!
