TL;DR: The reported SUSFS 2.2.0 build is Theettam Kernel v2.1 for Xiaomi “peridot”, meaning the POCO F6 and Redmi Turbo 3. It combines a Linux 6.1.175 kernel base with kernel-level SUSFS support. It is not a universal Android kernel, a Magisk module or a guaranteed way to satisfy banking and Play Integrity checks.
By the PrivacyPortal team
Last updated July 2026
SUSFS is a kernel patch designed to conceal selected filesystem artefacts associated with root and device modification. In this report, three version numbers describe separate layers: Linux 6.1.175 is the underlying kernel revision, SUSFS 2.2.0 is the upstream patch generation, and Theettam v2.1 is the device-specific release package. That distinction matters because flashing a kernel built for another phone can leave the device unable to boot. Back up everything before proceeding: bootloader unlocking wipes user data, and kernel modification can affect security, over-the-air updates, warranty support, banking apps and Play Integrity.
Image caption: The reported build’s three layers are Theettam v2.1, Linux 6.1.175 and SUSFS 2.2.0.
What does the reported SUSFS build actually include?
The current stable report concerns Theettam Kernel v2.1, released on 18 July 2026 for the Xiaomi peridot platform. Peridot is the shared device codename used by the POCO F6 and Redmi Turbo 3. The older Theettam v2.0.1 release, dated 17 July 2026, remains a possible fallback when the maintainer’s notes recommend it.
The reported stack contains three independently versioned components:
- Device kernel package: Theettam Kernel v2.1, built specifically for peridot.
- Linux base: Linux 6.1.175, an upstream long-term-support kernel revision released on 1 June 2026.
- Filesystem-hiding patch: the Android 14/6.1 upstream SUSFS branch, which identifies itself as version 2.2.0.
A release labelled “SUSFS 2.2.0” does not imply that every part of the ZIP has that version. Nor does it make the ZIP portable between devices sharing Android 14 or Linux 6.1. The device tree, boot-image layout, kernel configuration and vendor modules must all match.
Linux 6.1.175 was released upstream on 1 June 2026; Theettam Kernel v2.1 followed on 18 July 2026.
What SUSFS does at kernel level
SUSFS, short for “sus file system”, adds hiding behaviour inside the Linux kernel. A compatible root framework can use that behaviour to conceal selected mount information, paths and other filesystem-facing signs of modification from ordinary application processes.
This is materially different from a module that filters information only in Android userspace. Kernel-level handling occurs closer to the source of filesystem data, reducing some inconsistencies that detection tools can find when they compare multiple interfaces. The official SUSFS4KSU project repository contains the upstream implementation and supported branch history.
SUSFS is not a complete root solution. A working configuration normally involves:
- a kernel compiled with the matching patch;
- a compatible KernelSU-family implementation and manager;
- the correct userspace component or WebUI where required by that build;
- careful per-app root permissions and hiding rules.
Some kernels integrate more of this stack than others. Follow the Theettam release notes rather than installing every similarly named module. If its manager reports “SusFS not supported”, the running kernel lacks usable support, the patch and userspace components do not match, or the intended kernel was not successfully booted.
SUSFS is not the same as Magisk hiding
| Approach | Where it operates | Kernel requirement | Practical limitation |
|---|---|---|---|
| SUSFS with a KernelSU-family build | Kernel filesystem interfaces | Kernel compiled with compatible support | Highly device- and version-dependent |
| KernelSU or KernelSU Next alone | Kernel-level root and permission control | Compatible built-in or loadable implementation | Does not conceal every modification by itself |
| Magisk with Zygisk modules | Boot image and Android userspace | No SUSFS kernel patch | Cannot turn an unpatched kernel into a SUSFS kernel |
| Stock locked configuration | No intentional root layer | Vendor-supplied kernel | Least flexible, but generally the safest compatibility baseline |
Magisk and SUSFS are not interchangeable. Installing a Magisk module cannot add kernel code that was absent when the kernel was compiled. Likewise, a Magisk-patched boot image is not a substitute for the boot image expected by KernelSU or its forks.
KernelSU Next and SukiSU Ultra are related but distinct projects with their own managers, kernels and compatibility expectations. Do not install one manager simply because its interface resembles another. Use the implementation explicitly named by the kernel maintainer.
The upstream Android 14/6.1 SUSFS branch identifies itself as v2.2.0, while the device-specific Theettam package is v2.1.
Who should use the Theettam build?
The reported package is relevant only if the phone is a POCO F6 or Redmi Turbo 3 with the exact codename peridot, an unlockable bootloader and a ROM supported by the chosen Theettam release. The Android Generic Kernel Image documentation explains why devices may share a generic kernel foundation while still requiring compatible device and vendor components.
A sensible decision framework is:
- Proceed: the codename is peridot, the installed ROM and firmware are listed as compatible, matching stock images are saved, and the release specifies an installation path you understand.
- Wait: the device is peridot but the current ROM, Android build or root manager is absent from the compatibility notes.
- Do not flash: the codename differs, the ZIP’s origin or checksum cannot be verified, or no recoverable stock boot image is available.
Owners of other phones need a build compiled for their own model. Even another Xiaomi device using Linux 6.1 is not close enough.
Before installing: backup and compatibility checklist
Bootloader unlocking normally performs a factory reset. Copy photos, authenticator recovery data, encryption keys, application exports and other irreplaceable material away from the phone before unlocking. Confirm the backup can actually be opened.
- Check the codename using a trusted device-information method; it must report peridot.
- Record the exact ROM, Android version, firmware and current kernel.
- Download Theettam v2.1 and the specifically required manager from the “Modules, apps & files to try” section supplied with this guide.
- Retain matching factory boot, init_boot and vendor_boot images where the firmware package provides them.
- Install current Android platform-tools on the computer and test both ADB and fastboot connectivity.
- Verify the release checksum where the maintainer publishes one.
- Charge the phone and confirm that recovery or fastboot mode is accessible.
Unlocking and flashing may change the device’s verified-boot state, stop incremental OTA installation, require restoring stock images for updates, or cause a boot loop. Root also enlarges the security impact of a malicious module or an incorrectly granted superuser request.
How to install and verify Theettam with SUSFS
The exact flashing interface can vary between Theettam releases. These steps deliberately defer to the v2.1 release’s named partitions and installer instead of guessing them. Never flash a file to a partition merely because another device guide uses that command.
- Back up and unlock first. Complete a verified off-device backup. Use Xiaomi’s official bootloader-unlock process for your own device, accepting that unlocking wipes its data. Reboot Android and finish the initial setup before modifying the kernel.
- Confirm the target. Verify that the device codename is peridot and compare the installed ROM, firmware and Android generation with the Theettam v2.1 compatibility notes. Stop if any required match is uncertain.
- Save recovery images. Obtain the unmodified boot-related images from the exact firmware currently installed. Store copies on the computer, together with the full firmware package where available.
- Download the matched files. Use Theettam Kernel v2.1 and only the KernelSU-family manager or companion component specified for that release. The relevant names are listed in the appended “Modules, apps & files to try” section. Do not substitute a Magisk-patched image.
- Verify the package. Check the filename, source and published checksum. Read the release notes for required firmware, recovery support, installation slot handling and known conflicts. Do not continue with a repacked or unexplained ZIP.
- Enter the supported flashing environment. Reboot to the custom recovery or fastboot-based installer named by the maintainer. Confirm that the computer detects the phone before making changes.
- Flash exactly as documented. If v2.1 is supplied as a recovery-flashable kernel ZIP, install that ZIP through the supported recovery. If the release instead supplies a boot image or dedicated installer, use only its documented target and method. Do not flash boot content to init_boot or vendor_boot without explicit instructions.
- Boot and allow time for first start. Reboot normally. A first boot can take longer after a kernel change, but repeated restarts or an extended boot animation indicate failure. Use the documented recovery route and restore the matching stock images if necessary.
- Install the matching manager. Open the manager named in the release notes and confirm that its kernel implementation is detected. Grant root only to applications you trust; KernelSU-family managers commonly deny access by default.
- Verify SUSFS support. Open the supplied SUSFS WebUI or status page, if the release requires one. Confirm that it reports supported and shows the expected version or feature state. “SusFS not supported” means the installation is not ready for hiding rules.
- Test conservatively. Reboot once more, confirm calls, Wi-Fi, cameras and storage, then test ordinary applications. Keep logs of any boot, battery or app regression. Add extra integrity or hiding modules only when their current documentation confirms compatibility.
Image caption: Confirm the peridot codename, matching firmware and recoverable stock images before flashing.
What actually happens with banking apps and Play Integrity?
SUSFS can reduce filesystem-level evidence of root, but it does not guarantee that an app will accept the device. Applications can consider bootloader state, verified boot, hardware-backed key attestation, ROM properties, installed packages, behavioural signals and server-side risk decisions.
Google Play Integrity also has multiple verdicts. Passing one level does not imply that every app will work, and a result can change after an app, Play services or server policy update. No responsible guide can promise that this configuration defeats a particular bank’s checks.
A kernel reporting working SUSFS support can still fail Play Integrity or an individual app’s independent security assessment.
In practice, piling on modules can make diagnosis harder. Community reports include combinations that work with no additional hiding modules and other combinations that fail even with several integrity tools installed. Integrity Box has also been reported to conflict with some SUSFS4KSU releases by adding paths or rules aggressively. Treat such reports as configuration-specific observations, not universal recipes.
Common pitfalls and recovery choices
- Wrong device: similar marketing names do not replace the peridot codename check.
- Wrong component generation: a manager, userspace module and kernel patch from different releases may connect poorly or not at all.
- Assuming the ZIP provides everything: built-in kernel support may still need the manager or userspace tooling named by the maintainer.
- Flashing over an unsupported ROM: vendor-module or boot-layout mismatches can cause a boot loop, broken hardware or missing connectivity.
- Updating Android without restoring stock: an OTA may fail, overwrite the custom kernel or leave incompatible components behind.
- Installing overlapping modules: multiple tools changing mount rules, properties or integrity behaviour can conflict.
- No rollback material: restoring a random stock image from another firmware can compound the problem.
If v2.1 produces a documented regression, Theettam v2.0.1 may be a fallback only when it supports the installed firmware and the maintainer permits downgrading. Otherwise, restore the exact stock images for the current build. Readers new to boot images may also want PrivacyPortal’s guide to unlocking an Android bootloader safely before attempting a kernel flash.
Image caption: A reliable rollback kit contains the exact stock images and firmware matching the installed build.
Frequently asked questions
Can I install SUSFS 2.2.0 as a normal APK?
No. The core feature is compiled into or patched into the kernel. An APK can provide a manager or interface, but it cannot add missing kernel support by itself.
Does Theettam v2.1 work on every POCO phone?
No. The reported release targets Xiaomi peridot, covering the POCO F6 and Redmi Turbo 3. A different POCO codename requires its own compatible kernel build.
Can I use this build with Magisk?
Do not assume so. SUSFS4KSU is designed around compatible KernelSU-family integration, while Magisk uses a different root architecture. Follow the Theettam maintainer’s stated combination and avoid mixing patched boot images.
Does SUSFS make a rooted phone secure?
No. Hiding modification indicators is not the same as restoring a locked, vendor-verified security state. Root can give approved applications extensive control, so permissions and modules must be treated as highly trusted code.
Will it make my banking apps or Google Wallet work?
Possibly, but there is no guarantee. Each application can use different local and server-side checks, and successful Play Integrity results do not promise acceptance by a particular bank or payment service.
Will normal OTA updates still install?
They may fail or overwrite the custom kernel. The safe update sequence depends on the ROM and release instructions and often involves restoring stock boot-related images before applying an OTA, then obtaining a newly compatible kernel.
Is Theettam v2.0.1 safer than v2.1?
Not inherently. V2.0.1 is an older fallback, not a universal “safe” release. Choose the version whose documented firmware and ROM support match the device, and retain exact stock images for recovery.
The practical verdict
The reported release is best understood as a specific peridot kernel package, not a universal SUSFS download. Theettam v2.1 brings together a Linux 6.1.175 base and an upstream patch line identifying as SUSFS 2.2.0, but safe installation still depends on the exact phone, firmware, ROM, manager and flashing route.
Experienced peridot owners who can recover boot partitions may find the kernel-level approach more coherent than stacking userspace hiding modules. Beginners should first become comfortable with bootloader unlocking, stock-image restoration and fastboot recovery. For people who want privacy without maintaining a rooted flashing setup, PrivacyPortal’s privacy-first Android phones offer a more supported route to reducing dependence on Google services.
