Will it work on my machine? Check this first
- Your
/bootmust be a separate partition if you boot with GRUB or extlinux. Fedora-family installs always have one. Ubuntu, Debian and openSUSE defaults often keep/booton the root filesystem, and LinuxLocker refuses those before touching anything: GRUB would then have to unlock the disk, which this tool never sets up. Check withfindmnt /boot. No output means/bootis on root. Machines that boot systemd-boot, a UKI or a Raspberry Pi keep the kernel on the ESP or firmware partition and are fine. - Your root filesystem must be shrinkable by 32 MiB, for the LUKS2 header: ext2/3/4, btrfs and f2fs are. xfs cannot shrink and works only with 32 MiB of slack already at the end of the partition.
- Not on a Mac with Apple Silicon. Running Fedora Asahi Remix? Use AsahiLocker instead. LinuxLocker detects Asahi and exits before touching any device.
- You need a live USB for the machine (the target distro's own live ISO is safest), a verified backup, and AC power on a laptop.
What LinuxLocker does
- Detects the partitions, the target OS from its own
/etc/os-release, the filesystem and subvolumes, and the boot partitions. It takes those from the target's own fstab, not from guesses. - Installs missing tools with the live system's package manager: dnf, apt, pacman, zypper, apk, xbps or emerge.
- Shrinks the filesystem by 32 MiB to make room for the header.
- Encrypts in place with
cryptsetup reencrypt --encrypt: AES-256-XTS, argon2id, sha512, checksum resilience. - Verifies the header, opens the container, confirms the inner filesystem type and UUID are unchanged, and grows the filesystem back.
- Rewrites boot configuration for whatever this target uses, then rebuilds
every initramfs in a chroot. Any image that comes out without
cryptsetupordm-cryptis rebuilt again. - Rebuilds and re-signs the Unified Kernel Image, if the target boots one.
- Gates the reboot behind a verification pass. A check that doesn't apply to this target is reported as SKIP, never silently passed.
Re-run it any time. If it finds an interrupted encryption, it finishes it. If it finds an
already-encrypted volume, it offers to strengthen the KDF or redo the boot config. A LUKS1
volume can be converted to LUKS2 in place. A partition with no /etc/fstab inside
is a data disk, and gets encrypted with no boot changes at all.
Supported distros
Support depends on what is installed on the target, not on the distro's name, so derivatives inherit it from their family.
| Family | Initramfs | Boot config handled |
|---|---|---|
| Fedora · RHEL · Rocky · Alma | dracut | GRUB defaults, BLS entries, /etc/kernel/cmdline, rd.luks.* |
| Debian · Ubuntu · Mint · Pop!_OS | initramfs-tools | crypttab with initramfs, update-grub, installs cryptsetup-initramfs if missing |
| Arch · Manjaro · EndeavourOS | mkinitcpio | encrypt or sd-encrypt hook, cryptdevice= / rd.luks.* |
| openSUSE | dracut | GRUB defaults, rd.luks.* |
| Raspberry Pi OS | initramfs-tools | cmdline.txt root=, auto_initramfs=1 |
| ARM boards on U-Boot distro-boot | any of the above | extlinux.conf APPEND |
Every kernel command-line carrier is found and rewritten, including Ubuntu's
grub.d drop-ins, refind_linux.conf and limine.conf. A
root=PARTUUID= that names the raw partition is pointed at the mapper.
GRUB, systemd-boot, Unified Kernel Images and Secure Boot
| Boot stack | What happens |
|---|---|
| GRUB (+ BLS) | Defaults, drop-ins and every BLS entry patched; config regenerated. |
| systemd-boot | Detected from the loader on the ESP; entries patched with the ESP at /efi, /boot/efi or /boot, with or without XBOOTLDR. |
| UKI | The .efi is rebuilt with the backend that owns it (mkinitcpio _uki=, kernel-install layout=uki, dracut --uki-file or ukify), and its .cmdline section is read back to prove the LUKS arguments are in it. |
| Secure Boot + UKI | Re-signed with sbctl or sbsign; the reboot is refused if any UKI came out unsigned. |
| Secure Boot, no UKI | Nothing to do: the initramfs isn't in the verified chain, and shim, the bootloader and vmlinuz are never touched. |
Why this matters on Arch and Manjaro: sbctl's signing
hook is a pacman hook. It fires on package transactions, not when something runs
mkinitcpio -P by hand. A UKI rebuilt any other way comes out unsigned, and a Secure
Boot machine then refuses to load it. LinuxLocker signs the UKI itself and verifies the
signature.
Filesystems
| Filesystem | In place? |
|---|---|
| ext4 · ext3 · ext2 | Yes: resize2fs shrink → encrypt → grow |
| btrfs | Yes: online resize; subvolume layouts auto-detected |
| f2fs | Yes, with f2fs-tools ≥ 1.16 |
| xfs | Only with ≥ 32 MiB of existing slack at the end of the partition (xfs cannot shrink) |
| ntfs · vfat | Yes, for data partitions |
| exfat · udf · swap | No: workarounds here |
What is verified, and what is not yet
An encryption tool should tell you exactly what has been proven on real hardware. Here it is:
- Verified in production: Manjaro on an x86_64 ASUS ZenBook (btrfs with snapper, systemd-boot, UKIs from mkinitcpio, Secure Boot with sbctl). It runs the strongest profile in daily use; its journal records 56 real boots, and the unlock times below are measured from them.
- Tested in CI on every push, on x86_64 and aarch64: a loopback suite that does the real shrink, in-place encryption, hard-kill-and-resume, recovery-key enrolment and LUKS1 → LUKS2 conversion against throwaway loop devices, plus fixture suites covering every UKI, systemd-boot and command-line layout. None of these is a boot.
- Not yet boot-tested end to end: the Fedora, Ubuntu and Arch
GRUB paths. The code and tests cover them, but no real machine has yet been
encrypted and booted on those paths. If yours is one,
a report is very welcome, and a
--dry-runfirst is strongly recommended.
Step by step
-
Back up, and check the list above
A backup you have actually restored from or browsed. In-place encryption rewrites every sector of the partition.
-
Put the kit on a USB drive
git clone https://github.com/doug445/LinuxLocker.gitPut it on media that survives a reboot, not in the live session's RAM. Logs, the pre-encryption state and the recovery key are written next to the scripts.
-
Boot a live USB for the machine
The target distro's own live ISO is safest, because its
cryptsetupand filesystem tools match the target. Any live Linux withcryptsetup2.4 or later works. The script refuses to run from the installed system itself. -
Rehearse, then run
sudo /path/to/LinuxLocker/bin/linuxlocker.sh deploy --dry-run sudo /path/to/LinuxLocker/bin/linuxlocker.shThe dry run prints everything it detected and the exact
cryptsetupcommand, and changes nothing. The real run detects the live OS, installs what it needs, and walks you through it: pick the root partition from a scored menu, run an optional read-only fsck, choose a KDF profile benchmarked on this machine, and typeENCRYPT. Just before the passphrase prompt it asks for a lower-caseyes, which can't be typed with Caps Lock on.Everything after that is automated. Do not reboot if the gate reports errors: it prints exactly what failed.
-
First encrypted boot
The splash is stripped for this boot so the passphrase prompt stays visible. If the screen looks hung, type the passphrase and press Enter.
-
Finish on the encrypted system
sudo /path/to/LinuxLocker/bin/post-encryption-setup.shThis saves a recovery bundle, restores the splash and verifies the system end to end. Then move the recovery key and header backup to offline storage, and take a fresh backup.
argon2id profiles
Every keyslot is argon2id. There is no pbkdf2 profile and no flag to get one, and
fast is a hard floor. argon2id's cost is memory: every guess against your
disk must hold 1–4 GiB of RAM, on a GPU, an ASIC or anything else. RAM does not get cheaper for
an attacker than it does for you.
| Profile | Memory | Iterations | Unlock time* |
|---|---|---|---|
aggressive | 4 GiB | 10 | ~16 s (measured over 56 boots) |
moderate (default) | 2 GiB | 8 | ~8 s |
fast | 1 GiB | 9 | ~4 s |
* Intel Core i7-10510U laptop. The installer benchmarks your machine and shows
your own numbers before you choose, and it refuses any profile whose memory cost exceeds your
RAM. Already encrypted with weak settings? luks-tune.sh re-costs existing keyslots
upward, without re-encrypting anything.
Manual encryption vs LinuxLocker
| By hand | LinuxLocker | |
|---|---|---|
| Filesystem shrink | You pick the resize tool and size | Per-filesystem handler, 32 MiB, re-run safe |
| Which distro? | Follow the matching guide | Detected from the target's own files |
| KDF | cryptsetup auto-benchmark, sha256 | Pinned argon2id + sha512, with a floor |
| Boot config | Edit crypttab, fstab, cmdline and bootloader config by hand | Every carrier this target uses, rewritten |
| Initramfs | Rebuild and hope the module is in | Every image rebuilt, checked, self-repaired |
| UKI / Secure Boot | Find out after reboot that the old cmdline is baked in, or the signature broke | Rebuilt, re-signed, read back and verified |
| Did it work? | You find out at reboot | The gate refuses the reboot until it passes |
| Interrupted | Debug the header yourself | Detected and resumed |
Risks: read these
- Choosing the wrong partition is catastrophic. The script cross-checks your
pick against the target's fstab and makes you type
ENCRYPT, but you are the final authority. - Power loss mid-encryption is recoverable. Re-run the script, but don't format anything in a panic first.
- Forget the passphrase with no recovery key enrolled, and the data is gone.
- No TPM unlock. You type the passphrase at every boot.
- Encrypted
/bootis never set up. An existing GRUB-unlocked volume is recognised and kept within what that GRUB can open.
Frequently asked questions
Can I encrypt Linux after installation, without reinstalling?
Yes, that is the whole point. cryptsetup reencrypt --encrypt converts an existing
filesystem to LUKS2 in place. LinuxLocker automates that plus every boot change it forces, and
refuses to let you reboot until the result verifies.
Will my files, filesystem UUID and snapshots survive?
Yes. The filesystem inside the container is the same filesystem with the same UUID, and btrfs subvolumes and snapshots come through untouched. The script checks the inner type and UUID after encryption and fails the run if either changed.
Can I encrypt Ubuntu or Linux Mint after installing it?
Yes, if /boot is its own partition, or the machine boots systemd-boot or a UKI.
Ubuntu's default install often puts /boot on the root filesystem. Under GRUB,
LinuxLocker refuses that before touching anything. The fix is a separate, unencrypted
/boot partition of about 1 GiB.
Why is /boot left unencrypted?
So the initramfs unlocks root at the full argon2id cost of up to 4 GiB per guess. GRUB can't
do that: it takes argon2id memory as one allocation from the firmware heap, which on x86 UEFI
has never reliably meant more than 1 GiB, and stock GRUB 2.12 cannot open argon2id at all. An
encrypted /boot would become the cheapest way into the machine.
Does it work on a Raspberry Pi or another ARM board?
Yes. Raspberry Pi OS is a first-class target (cmdline.txt and
auto_initramfs=1), and ARM boards on U-Boot distro-boot get their
extlinux.conf rewritten. The 4 GiB profile needs about 6 GiB free at unlock, and
the installer refuses profiles larger than your RAM.
Does it work with Secure Boot?
Yes. Without a UKI, there's nothing to do: the initramfs isn't part of the verified chain.
With a UKI, the rebuilt .efi is re-signed with sbctl or
sbsign, and the reboot is refused unless the signature verifies. pesign/NSS
setups are detected and refused with an explanation rather than left unsigned.
Can it unlock with a TPM, or with no passphrase?
No. It enrolls a passphrase and, optionally, a recovery key. TPM2, PCR sealing and network-bound unlock are not implemented.
What if the encryption is interrupted?
LUKS2 re-encryption is journaled. Re-run the script. It detects the interrupted state, repairs the journal if needed, finishes, and redoes the configuration.
Can I encrypt a second data disk instead?
Yes. A partition with no /etc/fstab inside is offered data-partition mode:
encrypt, enroll a recovery key, back up the header, no boot changes.
I'm on a Mac with Apple Silicon.
Use AsahiLocker. It does the same job with the boot guards Fedora Asahi Remix needs. LinuxLocker detects Asahi and exits before touching any device.
How do I know it is safe to run?
Don't take it on trust. Run deploy --dry-run and read the plan, and read
what is verified above. The audits so far, and who did them, are
recorded in the README.
Further reading
- Arch Wiki: Encrypt an existing unencrypted file system, the manual method in detail.
cryptsetup-reencrypt(8), the command underneath all of this.- INSTALL.md · BOOTLOADERS.md · FILESYSTEMS.md · RECOVERY.md
- AsahiLocker, the Apple Silicon sibling.