08:32 <decfi[m]> Imagine a failing CoreOS update that leaves the system unbootable and your disk is encrypted with clevis. How do you decrypt your disk if you don't know the luks key? i found documentation about disk encryption but i wonder why it says nothing about encrpytion key backup

08:32 <decfi[m]> s/encrpytion/encryption/

10:17 <darknao> for standard systems, I would usually set up a backup key, but I see CoreOS as a disposable system, if a node fails for whatever reasons, I can just redeploy it again in minutes

11:55 <travier[m]> decfi: We don't have a full story for this right now. You might want to enroll a backup LUKS key for breaking glass access

12:47 <walters> darknao: (I personally prefer the term "reprovisionable" https://blog.verbum.org/2020/08/22/immutable-%E2%86%92-reprovisionable-anti-hysteresis/ )

12:50 <walters> https://www.freedesktop.org/software/systemd/man/systemd-cryptenroll.html# supports recovery keys as QR codes which sounds cool (I haven't tried it, we haven't seriously investigated cryptentroll in our flows yet)

13:32 <guesswhat[m]> Anyone tried to install Podman 4.4.0 ? Will https://pastebin.com/raw/emEXchHc work? I am not sure if other packages are needed, like aardvark, extras, etc. Thanks

14:08 <travier[m]> guesswhat: https://github.com/coreos/fedora-coreos-tracker/issues/998

14:15 <guesswhat[m]> travier: seems You are missing aardvark neavark and maybe selinux packages

14:19 <travier[m]> guesswhat: don't we already have those in FCOS?

14:20 <guesswhat[m]> Well, I dont know how exactly is Podman "stack" vendored :)

14:46 <travier[m]> We don't vendor :)

18:26 <bgilbert> trivial review for anybody: https://github.com/coreos/afterburn/pull/865

20:29 <baude> bgilbert, i gotta step away for about an hour ... i'm hoping afterwards i can pick your brain on a question. making great progress otherwise and someone else also volunteered to contribute code as well

20:29 <bgilbert> +1

21:40 <baude> ok bgilbert im at the point of looking at the c code and so forth

21:40 <baude> before doing so, it looks to me like /dev/vmbus/hv_kvp is the kernel device in question

21:44 <bgilbert> okay

21:45 <bgilbert> I agree

21:45 <baude> looking at all the code https://github.com/torvalds/linux/blob/master/tools/hv/hv_kvp_daemon.c

21:45 <baude> i think more or less, we only need to implement something that reads

21:46 <baude> so i was curios firstly, is there a linux utility i should be able to use to read from that device? should dd be able to do that?

21:47 <bgilbert> for testing, you mean?

21:47 <baude> ya

21:48 <baude> i kind of what to *make sure* things are working as expected (if possible) before developing any code

21:48 <baude> and ofc, i am asking bc dd didn't work :)

21:48 <bgilbert> did you give dd a bs= argument?

21:48 <bgilbert> dd should work, but these kernel interfaces often expect reads to be a specific size

21:49 <baude> nope, you think bs and count might be applicable

21:49 <bgilbert> note that the C program does read(kvp_fd, hv_msg, sizeof(struct hv_kvp_msg))

21:49 <bgilbert> but the other issue is

21:49 <bgilbert> the first thing it does after opening the device node is to write a registration message to it

21:50 <bgilbert> and dd can't do the write + read pattern afaik

21:50 <bgilbert> one option for writing a quick test is to use Python and struct.pack()/struct.unpack()

21:51 <baude> do you know anything about that kernel registration message ?>

21:51 <baude> i saw that and didn't know if it was formality or required

21:52 <baude> again, assume i know very little about this ... because i know very little about it

21:57 <bgilbert> skimming the kernel code, it's a version handshake

21:58 <bgilbert> it's possible that it's not needed, but the kernel code will likely assume that it was done

21:58 <baude> agree

21:58 <bgilbert> so I'd be inclined to mimic what's there

21:58 <baude> agree

21:58 <bgilbert> (and ugh, it's assigning the received version to a static variable, so there are assumptions that only one process is using the device node)

21:58 <baude> yeah they take a lock

22:01 <baude> bgilbert, i guess what i am getting at, at least initially is, is reading from /dev/blahblah likely to the same as reading from a file, except maybe controlled by poll, etc?

22:01 <bgilbert> the key difference is you have to use exactly the read/write sizes expected by the kernel

22:02 <bgilbert> there's no buffering layer in between; it has to be exactly one struct of the right size