The challenger has no business logic in here, and kcrypt should just
read what it needs. This goes in parallel with https://github.com/kairos-io/kcrypt-challenger/pull/10
Not blocking each other.
Signed-off-by: mudler <mudler@c3os.io>
Now the kcrypt configuration will be just a block (`kcrypt`) in the regular
kairos configuration files.
We will use the config mechanism of looking up in multiple directories
becase the old code was only looking at `/oem` but at boot time
(initramfs) the configuration was present in `/sysroot/oem`.
The reason it "worked" was that we had a bug and a sealedvolume was
matching our request simply because we sent an empty UUID/Label/Name
and the sealedvolume had and empty UUID (empty matches empty, right?)
With that fixed on the challenger server side, it became obvious that we
never actually read the partition_info file because we were looking for
it at the wrong place.
Signed-off-by: Dimitris Karakasilis <dimitris@karakasilis.me>
e.g. when we first create it
because it throws this error:
```
panic: assignment to entry in nil map
goroutine 1 [running]:
github.com/kairos-io/kcrypt/pkg/partition_info.PartitionInfo.UpdateMapping({{0xa60325?, 0x18?}, 0x0?}, {0xc000302000?, 0x1?})
/go/pkg/mod/github.com/kairos-io/kcrypt@v0.4.2/pkg/partition_info/partition_info.go:69 +0x99
```
Signed-off-by: Dimitris Karakasilis <dimitris@karakasilis.me>
so that the caller doesn't have to care if it's the first time the
partition is encrypted or not.
Signed-off-by: Dimitris Karakasilis <dimitris@karakasilis.me>
Now the code can simply initialize a PartitionInfo from a file and then
call LookupUUIDForLabel on it.
Signed-off-by: Dimitris Karakasilis <dimitris@karakasilis.me>
to be used both here (when trying to find the partition UUID using a
label) and on the kairos side when updating the file after calling
kcrypt to encrypt a partition (which causes the UUID to change).
Signed-off-by: Dimitris Karakasilis <dimitris@karakasilis.me>
