=== 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
[10:16] <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:17] <stenno> in the 'full log', i could still see packages being unpacked and prepared
[10:17] <stenno> is this a known issue?
=== 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
[21:47] <znf> How the hell do you dhcpv6 client in netplan?
[21:51] <rfm> znf, "dhcp6: yes" in the  device entry
[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> 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:56] <znf> but if I dhclient -6 enp0s6, it works just fine
[22:06] <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:08] <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:10] <rfm> znf, and ipv6 address autoconfiguration is all done in the kernel, dhclient shouldn't need to be involved.
[22:12] <znf> well, this provider uses dhcpv6 not slaac
[22:13] <znf> and the only way to test the functionality is with dhclient
[22:13] <znf> unelss you know a better one
[22:19] <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:20] <znf> let's see
[22:21] <znf> nope, still loses it instantly
[22:21] <znf> weird
[22:22] <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:24] <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:29] <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:30] <znf> lemme see
[22:39] <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:40] <znf> I'm fairly positive they have everything neatly isolated
[22:48] <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:49] <znf> yes, there's only the link local address 
[22:52] <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:53] <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.
[23:04] <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:39] <rfm> znf, yeah, now that I get the google query right it's all over. 
=== hyperreal5 is now known as hyperreal
[23:53] <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:54] <minimal> znf: hadn't noticed anything in either place
[23:59] <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