cryptsetup-var: encrypt a grown /var in place, report conversion size/progress - #321
Closed
mobileoverlord wants to merge 1 commit into
Closed
cryptsetup-var: encrypt a grown /var in place, report conversion size/progress#321mobileoverlord wants to merge 1 commit into
mobileoverlord wants to merge 1 commit into
Conversation
…ing converted Turning rootfs var.encrypt on for a device that already ran plaintext failed closed: grow-var had resized the btrfs to fill the partition, so encrypt_in_place found no 32 MiB tail for the LUKS2 header and exited with 'leaves no 32 MiB for a LUKS header' - /var never mounted and the board sat in the emergency shell after the OTA. Only a fresh flash (fs far smaller than its expand-to-fill partition) ever worked. btrfs shrinks online, so when the headroom is short, mount the filesystem on /run/cryptsetup-var-shrink, 'btrfs filesystem resize' it by exactly the deficit, unmount, and continue with the same --reduce-device-size 32M reencryption. A shrink refusal (tail chunk in use, no free space) still fails closed with a message naming that. A seeded /var can be tens of GiB and the conversion then runs for many minutes with nothing on the console: print the MiB being converted, that it is a one-time resumable migration, and pass --progress-frequency 30 when the installed cryptsetup (>= 2.4) has it. tests: grown-fs case (shrink by the deficit, mount->resize->umount before the reencrypt, device-size covers the result), the small flashed case is not shrunk, and the console line is present.
Contributor
Author
|
Merged into wrynose via #316 (rebased, commits preserved). Closing as included. |
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
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.
Follow-up to #310/#317 for the OTA scenario: a device deployed with a plaintext
/varreceives an update that turnsvar.encrypton.Before:
encrypt_in_placeneeds 32 MiB of free tail for the LUKS2 header, but on any deployed device grow-var has already resized the btrfs to fill the partition, so the guard fired (leaves no 32 MiB for a LUKS header - cannot encrypt in place),cryptsetup-var.servicefailed,/varnever mounted, emergency shell. Only fresh flashes (461 M seed inside a 55 G partition, as tested on Thor/Orin) ever converted.Now:
/run/cryptsetup-var-shrink,btrfs filesystem resize -<deficit>M, unmount, then the unchanged--reduce-device-size 32Mreencryption. A shrink refusal (tail chunk in use / full) still fails closed with a message saying so.--progress-frequency 30when cryptsetup ≥ 2.4 advertises it — a seeded/varcan be tens of GiB and this step runs for minutes with nothing else on screen.Generic (meta-avocado core); every target using
cryptsetup-vargets it. The initramfs already has btrfs-progs and the btrfs module (it mounts/var), andmount(util-linux/busybox).Not in this PR: bounding the work to used data (shrink to used+slack before encrypting, re-grow after).
--device-sizestill covers btrfstotal_bytes, so a 40 G fs with 5 G used encrypts 40 G. That needs a chunk-relocation pass and is a separate trade-off.Tests:
tests/test-cryptsetup-var-inplace.sh11/11 (new: grown-fs shrink by exact deficit, mount→resize→umount ordering before reencrypt, resulting device-size, console size line, and that a small flashed fs is never shrunk).