Tell BitLocker users to decrypt, not suspend (#105)
The free-space install detects BitLocker by the -FVE-FS- signature at offset 3, and suspending BitLocker leaves that signature in place: the volume stays encrypted, it just gains a clear-key protector. So the old message sent users to do something that could never let the install proceed. Aborting on a suspended volume is deliberate, so only the wording needed fixing. Fixes #99 Co-authored-by: Claude Opus 5 (1M context) <noreply@anthropic.com>
This commit is contained in:
1 parent
22eb81ebf5
commit
8b3dcc68b2
1 file changed
+3
-2
@@ -507,8 +507,9 @@ run_partition_decide() {
|
||||
bl_part=$(detect_bitlocker || true)
|
||||
if [[ -n "$bl_part" ]]; then
|
||||
say --foreground 1 "BitLocker signature detected on $bl_part."
|
||||
say "Suspend or disable BitLocker in Windows before installing alongside it."
|
||||
abort "Aborted: BitLocker is active on this disk."
|
||||
say "Turn BitLocker off in Windows and wait for the drive to finish decrypting, then try again."
|
||||
say "Suspending BitLocker is not enough — the drive stays encrypted."
|
||||
abort "Aborted: BitLocker is enabled on this disk."
|
||||
fi
|
||||
|
||||
# Omarchy always creates its own dedicated ESP in free space and never
|
||||
|
||||
Reference in new issue
Block a user