Trigger udev to populate disk info #328
Conversation
because otherwise, sometimes the encrypted partition doesn't show up as type: crypto_LUKS but as type: unknown making kcrypt skip it completely Part of kairos-io/kairos#2511 (an additional seems to be needed in kairos-agent when locking the partitions to fully fix the issue) Signed-off-by: Dimitris Karakasilis <[email protected]>
There was a problem hiding this comment.
Im wondering if we should also trigger + sync in the luksify part, where we create the device first, then wait for it and format it.
Seems like that has never hit an issue though, so maybe its not needed. But it may make us avoid having to trigger on agetn and consumers of the lib?
I did hit this issue too and I was planning to do a similar call right after this: https://github.com/kairos-io/kairos-agent/blob/f39d257f2238f70c9399b02867f60c0d87ad1728/internal/agent/hooks/kcrypt_uki.go#L87 Should I do that in kcrypt instead (inside Luksify somewhere)? |
I think so yeah, so its the kcrypt lib the one responsible to search and retry properly to get the device. Maybe adding it in Luksify only its the correct choice (after all luksify is run in the install before the unlock fails) but triggering it twice should be of no issue. |
Signed-off-by: Dimitris Karakasilis <[email protected]>
| if err != nil { | ||
| return "", fmt.Errorf("udevadm trigger failed: %w, out: %s", err, out) | ||
| } | ||
| SH("sync") //nolint:errcheck |
There was a problem hiding this comment.
ah this answers my question in the other repo
because otherwise, sometimes the encrypted partition doesn't show up as type: crypto_LUKS but as type: unknown making kcrypt skip it completely
Part of kairos-io/kairos#2511
(an additional seems to be needed in kairos-agent when locking the partitions to fully fix the issue)