TL;DR: Wild Kernels SUSFS does not yet offer NoMount or ZeroMount in a tagged release. The r8 pre-release includes KernelSU-Next and SUSFS 2.2.0. NoMount landed in source on 17 August 2026, so it is coming. ZeroMount remains absent. Flash only a device-matched build, after a full backup.
By the PrivacyPortal team
Last updated August 2026
As of 25 August 2026, wild kernels susfs users must distinguish released packages from newer source code. WildKernels r8 is the latest published GKI package. It does not advertise NoMount or ZeroMount. The repository now contains NoMount integration, but no later tagged build was found. A custom build may include that work. The r8 download does not gain it after release.
This guide explains what is available, how to check compatibility and how to test a suitable build. Back up everything first. Unlocking the bootloader wipes the phone. A wrong kernel can cause a boot loop or leave the device unable to start.
Caption: The release timeline separates the r8 package from the later NoMount source changes.
Wild Kernels SUSFS status in August 2026
The latest package on the official WildKernels release page is r8. It is marked as a pre-release and dated 12 August 2026. Its notes advertise KernelSU-Next and SUSFS 2.2.0. They do not advertise NoMount or ZeroMount.
WildKernels r8, published on 12 August 2026, advertises KernelSU-Next and SUSFS 2.2.0 but not NoMount or ZeroMount.
NoMount integration appeared in the WildKernels GKI source repository on 17 August. The changes include CONFIG_NOMOUNT=y and a matching metamodule build. That is useful evidence of planned support. It is not evidence that r8 contains the feature.
On 17 August 2026, WildKernels added CONFIG_NOMOUNT=y and a matching NoMount metamodule build to its GKI repository.
No official WildKernels GKI workflow currently shows ZeroMount integration. Wild Kernels zeromount support should therefore be treated as unavailable unless a future release says otherwise.
What SUSFS, NoMount and ZeroMount actually do
SUSFS means “SUS File System”. It adds kernel-level controls that can hide selected paths and other root-related signs. SUSFS for KernelSU requires a kernel built with the matching patches. Installing only a manager app or module cannot add missing kernel code.
NoMount and ZeroMount concern how modules expose files to Android. Their aim is to avoid some conventional mount patterns. They are separate from SUSFS. A kernel can support SUSFS without supporting either method.
These tools do not make a modified phone invisible. Apps can inspect boot state, hardware-backed signals, system properties and behaviour. Detection methods also change without notice.
Wild Kernels nomount support now exists in source form. Users still need a compatible kernel build and its matching userspace component. ZeroMount is a different implementation. Its name should not be used as a general label for mount hiding.
Released packages compared with current source
| Option | KernelSU | SUSFS | NoMount | ZeroMount | Practical status |
|---|---|---|---|---|---|
| WildKernels r8 pre-release | KernelSU-Next | 2.2.0 advertised | Not advertised | Not advertised | Newest tagged package found |
| Repository after 17 August 2026 | KernelSU-Next workflow | Present | Integrated in source | Not found | Requires a trusted custom build or later release |
| Archived r4 package | Included | Included | No | No | Older Android 14 branch |
| Future tagged release | Check its notes | Check its notes | Possible | Unconfirmed | Do not assume features before publication |
The archived r4 file is named 6.1.145-android14-2025-08-AnyKernel3.zip. Its filename identifies an Android 14 kernel branch. It does not establish Pixel 9 or Android 16 support.
Caption: A compatible package must match the phone, Android kernel branch and expected root manager.
How to install and test wild kernels susfs
Use this process only on your own device and only when its maintainer confirms compatibility.
- Back up the phone. Copy photos, messages, authenticator recovery codes and app data elsewhere.
- Record the exact model. Note the device codename, Android build and output from adb shell uname -r.
- Download the stock recovery files. Keep the matching boot, init_boot and vendor_boot images before changing anything.
- Check GKI compatibility. Compare the device kernel branch with the selected WildKernels asset. A similar filename is not enough.
- Unlock the bootloader if required. This normally performs a factory reset and may affect warranty support.
- Install the matching KernelSU-Next manager. Use the app named in the release notes or the files section supplied with this guide.
- Flash the matched kernel package. Use only the recovery or kernel-flashing method approved by the device maintainer.
- Reboot before adding modules. Confirm Android starts and that touch, Wi-Fi, mobile data and cameras work.
- Add the matching SUSFS component if required. Do not install SUSFS4KSU through Magisk or mix manager families.
- Verify support. Check the KernelSU-Next manager and SUSFS WebUI before granting root access to other apps.
Prerequisites before flashing
The phone needs an unlockable bootloader and a confirmed recovery path. It also needs a GKI build that matches the device. GKI means Generic Kernel Image. Android uses it to standardise the kernel core across supported devices.
The official Android GKI documentation explains the architecture. GKI does not make every generic kernel safe for every phone. Vendor modules and boot layouts still differ.
Charge the battery above 60%. Install current platform tools on the computer. Test adb and fastboot access before flashing. Never relock the bootloader while custom or mismatched images remain installed.
How to verify real SUSFS and NoMount support
Open the KernelSU-Next manager after the first clean boot. It should recognise the installed kernel. The SUSFS interface must also report kernel support. “SusFS not supported” means the required patch is missing or mismatched.
Do not treat an installed APK as proof. Manager apps can install on unsupported kernels. A module may also appear in a list while its kernel calls fail.
For NoMount, seek an explicit statement from the build maintainer. Confirm that the build was produced after the integration and includes its matching metamodule. Seeing CONFIG_NOMOUNT in current source does not prove an older binary contains it.
Test normal phone functions before testing app compatibility. Keep logs enabled during diagnosis. Disable SUSFS logs only after the setup is stable.
Safe SUSFS configuration
Start with default settings. Change one option at a time and reboot after each change. This makes faults easier to trace.
Community setups often disable SUSFS logs after testing. They may also remove “KSU” from the displayed kernel version and enable spoofing on boot. Such changes can reduce simple string-based signals. They cannot guarantee that an app will accept the phone.
Avoid copying large path lists from another device. One reported example involves adding a LineageOS overlay idmap path to /data/adb/susfs4ksu/sus_path.txt. That change caused a horizontal display fault. Paths can differ between ROMs and builds.
BRENE v0.0.54 is an optional module for SUSFS-patched KernelSU kernels. It targets SUSFS 2.2.0 and adds settings such as framework resource hiding. Establish a stable base first. Optional modules add more variables and can make recovery harder.
Real risks and common failure modes
- Data loss: bootloader unlocking wipes local user data on most supported phones.
- Boot loops: a wrong kernel branch or vendor module mismatch can stop Android starting.
- OTA failures: over-the-air updates may reject modified partitions or replace the custom kernel.
- App rejection: banking, workplace and media apps may use Play Integrity or their own checks.
- Security changes: an unlocked bootloader weakens protection against some physical attacks.
- Performance faults: users have reported battery drain or frame-rate drops with some KernelSU builds.
- Module conflicts: Integrity Box v6 has been reported to conflict with newer SUSFS4KSU setups.
No root stack can promise support for a specific bank. Passing one test does not ensure acceptance by every app. An app update can also change the result.
If the phone stops booting, restore the exact stock images for its installed build. Do not flash random images from a close model. Follow a device-specific unbrick guide where EDL or other low-level recovery is required.
Caption: Keep stock images and a tested USB connection ready before changing the active kernel.
Which option should you choose?
Choose r8 only if the release asset matches your device and you need its advertised KernelSU-Next and SUSFS features. Do not choose it for NoMount.
Choose a post-17 August custom build only when you trust its builder. Ask for the source revision, build log and package checksum. Confirm that its NoMount metamodule matches the kernel.
Wait for a tagged release if you want the simplest audit trail. This is the safer choice for most beginners. It gives maintainers time to document support and known faults.
Keep the stock system if banking access, work controls or reliable OTA updates matter most. A de-Googled phone explained in our practical guide can offer more privacy without relying on a root-hiding stack. Readers considering a ROM change should also review our GrapheneOS installation guide.
Modules, apps and files to try
Use the verified files supplied with this article rather than search-engine mirrors. Relevant names include the WildKernels GKI KernelSU SUSFS release package, the matching KernelSU-Next manager and SUSFS-FOR-KERNELSU.
BRENE v0.0.54 is optional. Install it only after basic SUSFS operation is confirmed. Do not mix Magisk, APatch and KernelSU modules merely because their ZIP files look similar. Their kernel hooks and service layouts differ.
Frequently asked questions
Does WildKernels r8 include NoMount?
No. The r8 release notes do not advertise NoMount. NoMount integration entered the repository five days after r8 was published. A later source build may contain it, but the tagged r8 package does not gain later changes.
Does Wild Kernels support ZeroMount?
No official WildKernels GKI release or current workflow was found with ZeroMount support as of 25 August 2026. Treat any third-party claim separately. Ask for its source revision, build log and device support details.
Can I install SUSFS with Magisk?
Not as SUSFS for KernelSU. SUSFS needs a patched kernel and the matching KernelSU or KernelSU-Next setup. A Magisk-patched boot image is not a KernelSU kernel. Do not assume a Magisk module can supply the missing kernel feature.
Will wild kernels susfs make banking apps work?
It may hide some filesystem signs, but it offers no guarantee. Apps can check boot state, Play Integrity, hardware-backed data and their own risk signals. Never depend on root hiding for urgent access to money or work accounts.
Can I flash the r4 archive on a Pixel 9 or Android 16?
The available facts do not establish that compatibility. The r4 filename identifies Linux 6.1.145 and an Android 14 2025-08 branch. Use a build explicitly approved for the exact device, Android release and current firmware.
Should beginners use a custom NoMount build?
Most beginners should wait for a documented tagged release. A custom GKI KernelSU SUSFS build needs careful checks, a known recovery path and trust in its builder. Source availability helps, but it does not prove that a shared binary was built from that source.
Modules, apps & files to try
Here are the actual tools the rooting community uses for this, each linked to its official source. They're third-party community projects, so download only from the official page below, back up your boot.img first, and follow each project's own instructions. PrivacyPortal isn't affiliated with these projects and can't guarantee third-party files — flash at your own risk.
| File | What it is & how to use it safely |
|---|---|
| Magisk (GITHUB) | The original and most widely used Android root manager; systemless root via boot-image patching, with built-in Zygisk, a module system and a DenyList for hiding root. Download ONLY from the official repo github.com/topjohnwu/Magisk — its README states GitHub is the sole official source, and third-party "Magisk Manager" sites/APKs are frequently repackaged with malware. Rooting trips Play Integrity and can brick a device: back up your stock boot.img before patching/flashing, and never flash a Magisk ZIP/APK obtained from a Telegram link or random mirror. |
| KernelSU (GITHUB) | The original kernel-based root manager — implements root as a kernel module rather than patching the boot ramdisk like Magisk; needs a GKI 2.0 or KernelSU-supported kernel. Official open-source (GPL) project, actively maintained — latest KernelSU v3.2.4 (Apr 2026). Kernel-level root requires a GKI 2.0 / kernel 5.10+ device (older 4.14+ kernels need a manually built kernel). Only download from the official GitHub Releases page (github.com/tiann/KernelSU/releases), never a Telegram link or mirror; verify the .apk/kernel matches your exact device and back up your boot.img before flashing, as a bad kernel image can bootloop the device. The companion KernelSU-Next fork (github.com/KernelSU-Next/KernelSU-Next) is also legitimate and supports wider kernel ranges (4.4–6.6). |
| APatch (GITHUB) | Kernel-level Android root manager that patches the kernel image directly and provides its own KPM (Kernel Patch Module) system; an alternative to Magisk and KernelSU. APatch is a legitimate open-source, kernel-level root manager (built on KernelPatch; UI/module code derived from KernelSU). Only download the APK from the official GitHub Releases page (github.com/bmax121/APatch/releases) or the official docs at apatch.dev — avoid third-party APK mirrors. Because it patches the kernel directly, ALWAYS back up your boot.img before flashing, and choose a strong SuperKey: the SuperKey has higher privileges than root, so a weak or leaked key can hand full control of your device to an attacker. Rooting voids warranties, can trip banking/Play Integrity checks, and a bad patch can bootloop the device. |
| SUSFS (GITLAB) | Kernel-level filesystem-hiding patch (VFS layer) that hides root-related files and mounts from apps; requires kernel support and is applied via the patched kernel. SUSFS is a kernel-level patch, not a one-click app — it requires a SUSFS-patched kernel, so back up your boot.img/stock kernel before flashing and only use the official simonpunk GitLab repo or a reputable pre-patched kernel. Upstream calls it experimental; a bad flash can bootloop your device. |
PrivacyPortal sells ready-to-use, de-Googled GrapheneOS Pixels — hardened, kept updated, and shipped with our encrypted Graphite messenger. Browse privacy phones →
