Upgrade kcrypt partitions on boot #122
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Codecov Report
📣 This organization is not using Codecov’s GitHub App Integration. We recommend you install it so Codecov can continue to function properly for your repositories. Learn more @@ Coverage Diff @@
## master #122 +/- ##
==========================================
- Coverage 18.60% 18.14% -0.47%
==========================================
Files 14 15 +1
Lines 1510 1549 +39
==========================================
Hits 281 281
- Misses 1205 1244 +39
Partials 24 24
📣 We’re building smart automated test selection to slash your CI/CD build times. Learn more |
Itxaka
force-pushed
the
upgrade-kcrypt-path
branch
4 times, most recently
from
f8ee8e7
to
0f0c21f
Compare
|
This works, tested upgrading from 1.X encrypted to master with this patch included. |
This solves the issue of upgrading from the old method of mappings to identify the kcrypt partitions, with the new one that uses predictable uuids to identify them. On boot we check for luks partitions that match the partitions persistent label (NOT THE FS LABEL) as that gets stored properly. If it matches persistent, we get its uuid and match it agsint the know uuid. If they dont match, we update it to match and proceed with booting. Signed-off-by: Itxaka <itxaka.garcia@spectrocloud.com>
Itxaka
force-pushed
the
upgrade-kcrypt-path
branch
from
0f0c21f
to
6fe8200
Compare
jimmykarily
reviewed
May 8, 2023
jimmykarily
approved these changes
May 8, 2023
Co-authored-by: Dimitris Karakasilis <jimmykarily@gmail.com>
Itxaka
commented
May 8, 2023
|
|
||
| // Mount COS_OEM (After root as it mounts under s.Rootdir/oem) | ||
| s.LogIfError(s.MountOemDagStep(g, cnst.OpMountRoot, cnst.OpLvmActivate, cnst.OpKcryptUnlock), "oem mount") | ||
| s.LogIfError(s.MountOemDagStep(g, cnst.OpMountRoot, cnst.OpLvmActivate), "oem mount") |
There was a problem hiding this comment.
Im still nto sure about this. Potentially on 2.1.X we could allow encrypting COS_OEM as well, in that case this should depend on the unlock method. But it has not been tested so.....making it easy for now
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This solves the issue of upgrading from the old method of mappings to identify the kcrypt partitions, with the new one that uses predictable uuids to identify them.
On boot we check for luks partitions that match the partitions persistent label (NOT THE FS LABEL) as that gets stored properly. If it matches persistent, we get its uuid and match it agsint the know uuid. If they dont match, we update it to match and proceed with booting.
Fixes: kairos-io/kairos#1379