[13:30] <meena> aciba: when are ye back to work?
[14:19] <meena> falcojr: I'm taking one of my PRs getting merged means: about now
[14:21] <minimal> FYI this proposed dhcpcd change may be relevant to cloud-init: https://github.com/NetworkConfiguration/dhcpcd/discussions/271
[15:04] <falcojr> thanks for the link!
[15:55] <meena> holmanb: i would've just banned this account https://github.com/canonical/cloud-init/pull/4720#issuecomment-1874176078 
[15:55] -ubottu:#cloud-init- Pull 4720 in canonical/cloud-init "proposed commit message because PRs are squash merged by default." [Closed]
[15:56] <meena> Also this one https://github.com/canonical/cloud-init/issues/4712 
[15:56] -ubottu:#cloud-init- Issue 4712 in canonical/cloud-init "[docs]:" [Closed]
[16:00] <minimal> falcojr: re that growpart Issue, I never understood why cc_growpart added the key stuff as I've resized LUKS partitions without it (via bootcmds, not via cc_growpart) and now I've sort-of figured it out
[16:01] <minimal> for LUKS *v1* "cryptsetup resize" does NOT need any keys for a LUKS that is already unlocked (i.e. the one containing the rootfs or whatever filesystem you want to grow)
[16:02] <minimal> for LUKS *v2* however I do see that "cryptsetup resize" of an unlocked LUKS *does* prompt for passphrase, I haven't yet figured out why
[16:03] <minimal> I'm currently working on a cc_growpart PR to cater for this
[16:04] <falcojr> yeah, I'm no luks experience. I was more leaning on the expertise of others for that one
[16:04] <falcojr> *expert
[16:05] <minimal> for locally I've modified cc_growpart to not require a key for rootfs and tested - works as expected for rootfs on LUKSv1, however doesn't for rootfs on LUKSv2 (as expected, "cryptsetup resize" is blocking waiting for passphrase input
[16:07] <minimal> I'm hoping to shortly raise an PR to address issues with cc_growpart's handling of LUKS and LVM (as I finally came up with a code change to fix an Alpine-related issue that let's me test this now)
[17:21] <holmanb> meena and minimal: we're back today - nice to see you o/
[17:21] <holmanb> meena: no perms to ban in github I don't think
[17:24] <holmanb> meena: thanks for the link on the dhcpcd stuff - I've been tracking the dhcpcd conversation, didn't want to jump into it yet because I didn't have time to over the break
[17:24] <minimal> holmanb: that was me ;-)
[17:24] <holmanb> bleh
[17:24] <holmanb> sorry minimal
[17:24] <minimal> you still on the Egg Nog? lol
[17:24] <holmanb> heh
[17:24] <holmanb> don't like the nog unfortunately
[17:25] <holmanb> just trying to skim through a backlog
[17:26] <holmanb> minimal: Roy is aware that Ubuntu's initramfs-tools is using dhcpcd in the same way that cloud-init likely will, and offered to keep around at least one flag that he was going to remove[1], so I think we're in the clear as long as we make our use case clear
[17:26] <holmanb> [1] https://github.com/NetworkConfiguration/dhcpcd/issues/276#issuecomment-1872556229
[17:26] -ubottu:#cloud-init- Issue 276 in NetworkConfiguration/dhcpcd "Waiting for carrier blocks timeout" [Open]
[17:28] <holmanb> minimal: but the line in the discussion you linked "dhcpcd-11 will require starting as a service in the same way as..." makes me nervous, so I'll need to follow up on that
[17:29] <minimal> yeah that was one of the things that jumped out at me too
[17:31] <minimal> perhaps you need to mention to him the c-i ephemeral scenario
[17:35] <holmanb> minimal: planning on it - I wanted to grok what manager mode even is before continuing the conversation
[17:35] <meena> holmanb: got time for https://github.com/canonical/cloud-init/pull/4677 ? I wanna get that fixed, and the OpenBSD port submitted
[17:35] -ubottu:#cloud-init- Pull 4677 in canonical/cloud-init "fix(runpath): On *BSD, create /run is not ephemeral" [Open]
[17:36] <holmanb> meena: I'll try to get to it today
[17:38] <minimal> holmanb: normally there are multiple dhcpcd processes running, Manager mode appears to replace this with a single process
[17:41] <minimal> e.g. on the Alpine VM I have in front of me there are the following dhcpcd processes running: "dhcpcd: eth0 [ip4] [ip6}", "dhcpcd: [privileged proxy] eth0 [ip4] [ip6]", "dhcpcd: [network proxy] eth0 [ip4] [ip6]", "dhcpcd: [BPP ARP] eth0 a.b.c.d", "dhcpcd: [DHCP6 proxy] aabb:ccdd:eeff:gghh:iijj", "dhcpcd: [BOOT proxy] a.b.c.d"
[17:41] <minimal> that's 7 dhcpcd processes
[18:57] <holmanb> minimal: https://github.com/NetworkConfiguration/dhcpcd/discussions/271#discussioncomment-7996089
[19:07] <minimal> thanks
[19:08] <holmanb> I also pinged the canonical dev internally who worked on the initramfs stuff to loop them into the conversation
[19:15] <minimal> falconjr: BTW I think I see why there's a difference in LUKSv1 vs LUKSv2 behaviour: "Starting with cryptsetup 2.0 we load VK in kernel keyring by default for LUKSv2 devices (when dm-crypt with the feature is available)."
[19:15] <minimal> from: https://gitlab.com/cryptsetup/cryptsetup/-/blob/main/docs/Keyring.txt