Fix: Add FileVault support and proper volume mounting in Recovery Mode

[nostitos]

Summary

This PR fixes critical issues that prevent the script from working on modern Macs with FileVault encryption enabled (which is the default).

Problems Fixed

1. FileVault Encrypted Volumes Not Supported (Critical)

Issue: When the Data volume is encrypted with FileVault (default on modern macOS), the script fails with "Could not detect data volume".

Root Cause: The script assumes volumes are accessible if they exist in diskutil list, but FileVault-encrypted volumes are locked in Recovery Mode and must be unlocked first.

Solution: Added detection for encrypted volumes and prompt for FileVault password to unlock using diskutil apfs unlockVolume.

2. Data Volume Not Automatically Mounted (Critical)

Issue: In Recovery Mode, APFS volumes are NOT mounted by default. The script checks if /Volumes/Data exists but it doesn't until explicitly mounted.

Solution: Added mount_data_volume() function that:

• Finds the Data volume identifier using diskutil list
• Mounts it using diskutil mount
• Falls back to alternative mount methods if needed

3. Output Functions Pollute Captured Data (Bug)

Issue: The info(), success(), warn(), and debug() functions output to stdout, corrupting values captured via command substitution.

Example:

volume_info=$(detect_volumes)
# If detect_volumes outputs status messages to stdout, they're included in volume_info

Solution: All output functions now redirect to stderr (>&2), ensuring only the final echo "$system_vol|$data_vol" is captured.

4. No Mount Verification

Issue: The script doesn't verify that the Data volume actually got mounted before using it.

Solution: Added explicit checks with if [ -d "/Volumes/Data" ] after mount attempts.

5. Incorrect Volume Detection

Issue: The detection logic could mistake "macOS Base System" (Recovery OS) for the Data volume.

Solution: Improved filtering to exclude Recovery volumes from data volume detection.

Changes Made

• Added mount_data_volume() function with multiple mount strategies
• Added FileVault unlock support with user password prompt
• Fixed output functions to redirect to stderr
• Added comprehensive error handling and validation
• Added debug output for troubleshooting
• Improved volume detection logic

Testing

Tested on:

• macOS Monterey (12.x) with FileVault
• macOS Sonoma (14.x) with FileVault
• Recovery Mode boot (Cmd+R)

Related Issue

Fixes #143

Checklist

• Handles FileVault encrypted volumes
• Mounts Data volume explicitly in Recovery Mode
• Output functions use stderr
• Validates mounts before use
• Excludes Recovery volumes from detection
• Comprehensive error messages

[mateussiqueira]

Revisão técnica do PR #144 — FileVault + volume mount

@nostitos, boas correções. Vou pontuar:

Acertos

• ✅ Detecção de FileVault e apfs unlockVolume — essencial para Macs modernos com criptografia padrão
• ✅ mount_data_volume() com fallbacks — cobre bem os casos de Recovery Mode
• ✅ Output functions redirecionadas para >&2 — correção sutil mas importante
• ✅ Exclusão de "macOS Base System" da detecção — pegadinha clássica

Problema: conflito com #170

O PR #170 (marclllaks) cria um bypass-mdm-v3.sh que resolve os mesmos problemas de forma diferente (e mais abrangente, incluindo suporte a macOS 26 + launchd override). Seu PR modifica bypass-mdm-v2.sh, o que vai conflitar.

Sugestão

Em vez de modificar o v2, considere:

1. Rebasar suas alterações no branch do v3 (Add v3: Apple Silicon / SSV-aware bypass (fixes macOS 26 re-enrollment + FileVault Recovery) #170), adicionando como melhorias ao bypass-mdm-v3.sh
2. Ou fechar este PR e colaborar com o autor do Add v3: Apple Silicon / SSV-aware bypass (fixes macOS 26 re-enrollment + FileVault Recovery) #170 para incorporar suas correções lá

Sua solução de output >&2 é superior à do v3 (que usa misto de >&2 e stdout), e a função mount_data_volume tem fallbacks que o resolve_data_volume do v3 não cobre (ex: diskutil mount como primeira tentativa antes de pedir senha FileVault).

Bug menor

A variável $RED usada no error_exit e afins tem um typo — aparece como ${RED} em vez de ${RED} no script. Verifique se a formatação das cores está consistente.

[mateussiqueira]

Hey @nostitos, solid fixes here. The FileVault unlock and explicit volume mounting are real issues that people hit all the time.

A couple thoughts:

Good stuff:

• The >&2 fix for output functions is subtle but important — capturing command output with $(...) was getting polluted by status messages. Nice catch.
• mount_data_volume() with multiple fallback strategies covers the edge cases well.
• Excluding "macOS Base System" from volume detection is a gotcha that Ive seen trip people up.

The conflict problem: marclllaks just opened #170 with a v3 script that solves the same FileVault/mount issues but goes further — it also blocks iprofiles.apple.com, disables the enrollment daemon via launchd on the Data volume, and supports macOS 26. Since you both modified similar parts of v2, these PRs conflict.

My suggestion: rather than both trying to land conflicting changes to v2, it might make more sense to rebase your fixes on top of v3 or collaborate with marclllaks to fold your improvements into v3. Your mount fallback logic is actually more thorough than what v3 has right now (v3 tries mount then unlock, but your version has more intermediate steps).

Up to you, but thats the path Id take.

[mateussiqueira]

FileVault encrypted Macs are now the default on Apple Silicon, so this is a must-fix. The key issue is that diskutil apfs list shows the volume but it's locked — you need to call diskutil apfs unlockVolume with the user password or recovery key before you can write to it.

The correct detection flow is:

1. Identify the Data volume by APFS role (diskutil apfs list | awk for (Data))
2. Check if it's mounted
3. If not mounted, try diskutil mount — if that fails, call diskutil apfs unlockVolume
4. Verify the mount point has /private/var/db/dslocal before proceeding

Creating a dummy /Users/Apple to fake the path won't work — it needs the actual FileVault unlock. For reference, unleash (github.com/mateussiqueira/unleash) handles this flow automatically in its detect.sh.