| meena | aciba: when are ye back to work? | 13:30 |
|---|---|---|
| meena | falcojr: I'm taking one of my PRs getting merged means: about now | 14:19 |
| minimal | FYI this proposed dhcpcd change may be relevant to cloud-init: https://github.com/NetworkConfiguration/dhcpcd/discussions/271 | 14:21 |
| falcojr | thanks for the link! | 15:04 |
| 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:55 | |
| 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] | 15:56 | |
| 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:00 |
| 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:01 |
| 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:02 |
| minimal | I'm currently working on a cc_growpart PR to cater for this | 16:03 |
| falcojr | yeah, I'm no luks experience. I was more leaning on the expertise of others for that one | 16:04 |
| falcojr | *expert | 16:04 |
| 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:05 |
| 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) | 16:07 |
| === giesen_ is now known as giesen | ||
| 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:21 |
| 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:24 |
| holmanb | just trying to skim through a backlog | 17:25 |
| 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:26 | |
| 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:28 |
| minimal | yeah that was one of the things that jumped out at me too | 17:29 |
| minimal | perhaps you need to mention to him the c-i ephemeral scenario | 17:31 |
| 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:35 | |
| holmanb | meena: I'll try to get to it today | 17:36 |
| minimal | holmanb: normally there are multiple dhcpcd processes running, Manager mode appears to replace this with a single process | 17:38 |
| 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 | 17:41 |
| holmanb | minimal: https://github.com/NetworkConfiguration/dhcpcd/discussions/271#discussioncomment-7996089 | 18:57 |
| minimal | thanks | 19:07 |
| holmanb | I also pinged the canonical dev internally who worked on the initramfs stuff to loop them into the conversation | 19:08 |
| 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 | 19:15 |
| === me_ is now known as mm-cr | ||
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!