Wild Kernels SUSFS: No nomount or zeromount Yet

Wild Kernels SUSFS: No nomount or zeromount Yet

TL;DR: Wild Kernels SUSFS builds combine KernelSU-Next with kernel-level filesystem hiding. However, the published releases and current build configuration do not include separate NoMount or ZeroMount VFS drivers. SUSFS can conceal mount evidence, but it does not make module injection mountless. Check exact device and kernel support before flashing.

Wild Kernels SUSFS: No nomount or zeromount Yet supporting illustration 1
Higgsfield-generated editorial illustration.

By the PrivacyPortal team

Last updated 29 July 2026

Wild kernels susfs is a useful option for compatible Generic Kernel Image devices. It gives KernelSU-Next access and native SUSFS support in one kernel. It does not currently provide NoMount or ZeroMount injection. That distinction matters when apps inspect mount namespaces or altered boot state. Back up every important file first. Unlocking a bootloader wipes the phone. A wrong kernel can also cause a boot loop, lost connectivity or a hard-to-recover brick.

What Wild Kernels SUSFS actually includes

Wild Kernels publishes GKI builds that combine a Linux kernel, KernelSU-Next and SUSFS patches. GKI means Generic Kernel Image. Android uses this design to separate the common kernel from hardware-specific vendor components.

KernelSU-Next grants root from kernel space. SUSFS adds kernel-level controls that can hide selected paths, mounts and other filesystem clues. A companion SUSFS module may provide settings and boot-time rules.

The project’s current release configuration does not show the separate NoMount or ZeroMount VFS drivers. Those drivers change how module files enter the filesystem. Their absence is not evidence that SUSFS is broken.

As of 29 July 2026, Wild Kernels publishes KernelSU-Next and SUSFS builds without the separate NoMount or ZeroMount VFS drivers.

See the official WildKernels release archive for published builds and release notes.

Image caption: A simplified kernel stack showing KernelSU-Next and SUSFS without NoMount or ZeroMount.

Wild Kernels nomount support explained

Wild Kernels nomount support is not present in the published builds covered by this review. NoMount is a separate approach to loading module content. It aims to avoid normal module mounts that can become visible in mount tables or namespaces.

SUSFS takes a different route. It can hide or alter evidence exposed through the filesystem. Yet the underlying module injection may still use mounts. Hiding a mount and avoiding that mount are not the same action.

This difference affects diagnosis. A SUSFS status screen can report full support while a detector still finds module-related mount behaviour. That result does not prove the SUSFS patch failed. It may show that another detection surface remains visible.

Do not install a file labelled “NoMount” unless the exact kernel supports its driver. A userspace module cannot add a missing VFS kernel implementation by itself.

Wild Kernels zeromount support explained

Wild Kernels zeromount support is also absent from the published releases and current build configuration. ZeroMount is another mount-avoidance design. It needs matching kernel code and userspace components.

A ZeroMount module made for another kernel is not a safe drop-in upgrade. At best, its feature check will fail. At worst, boot scripts may damage module state or leave the phone stuck during startup.

Names can also cause confusion. Some community modules use “mountless” as a broad marketing term. That does not prove they contain the specific ZeroMount VFS driver. Check the kernel source, build configuration and release notes.

SUSFS can hide mount evidence, but it does not turn a conventional KernelSU module mount into mountless injection.

Wild kernels susfs compared with NoMount and ZeroMount

Feature Main job Kernel support needed Current Wild Kernels status
SUSFS Hide selected filesystem and mount evidence Yes Included in supported builds
KernelSU-Next Provide kernel-based root and module control Yes Included
NoMount Inject module content without conventional mounts Yes Not included
ZeroMount Provide a separate mount-avoidance method Yes Not included
BRENE v0.0.54 Apply SUSFS and property-related rules A compatible SUSFS-patched kernel Optional module, not a VFS driver

The practical rule is simple. Use the features that the installed kernel declares. Do not infer support from a manager button or module filename.

Is GKI KernelSU SUSFS suitable for your phone?

GKI KernelSU SUSFS is most practical on phones with a compatible GKI kernel. The Android version alone is not enough. Linux version, kernel branch, patch level, boot layout and vendor modules must also match.

Android’s official GKI documentation explains how the common kernel interacts with vendor modules. A mismatch can stop Wi-Fi, touch, cameras or mobile data. It may also prevent booting.

An archived r4 package is named 6.1.145-android14-2025-08-AnyKernel3.zip. That filename describes an Android 14-era 6.1 branch. It does not establish Android 16 or Pixel 9 compatibility.

Non-GKI phones usually need a device-specific kernel built from source. Do not flash a generic image merely because KernelSU supports the same Android release.

The r4 archive named 6.1.145-android14-2025-08-AnyKernel3.zip does not, by its name alone, prove Pixel 9 or Android 16 support.

Image caption: Kernel branch, Android generation and vendor module compatibility must all match.

How to install Wild Kernels SUSFS

Use this process only on your own device and only when its kernel matches a published WildKernels build.

  1. Check the phone model, Android build, Linux kernel version and active slot. Record each value before downloading anything.
  2. Back up photos, messages, authenticator recovery codes and app data. Test that the backup can be opened elsewhere.
  3. Download the matching WildKernels AnyKernel3 release, KernelSU-Next manager and required SUSFS companion module. Use the files listed in the “Modules, apps & files to try” section.
  4. Save the complete stock firmware package. Keep copies of the original boot, init_boot and vendor_boot images where the device firmware provides them.
  5. Unlock the bootloader through the phone maker’s supported process. This wipes user data and may affect warranty service.
  6. Boot Android once after the wipe. Confirm the current firmware and slot still match the chosen kernel package.
  7. Install the KernelSU-Next manager APK. Do not use a Magisk-patched boot image as a substitute for a KernelSU kernel.
  8. Flash the matching AnyKernel3 archive through a supported custom recovery. Follow the release’s method and do not guess which partition to flash.
  9. Reboot and confirm normal touch, Wi-Fi, mobile data, cameras and charging. Restore the stock image if essential hardware fails.
  10. Open KernelSU-Next and verify root plus SUSFS support. Install SUSFS-FOR-KERNELSU or BRENE only when its documented version matches the kernel.

Prerequisites and recovery plan

You need an unlocked bootloader, a compatible GKI device and platform tools on a trusted computer. Charge the phone above 60%. Use a sound USB cable.

Know how to enter bootloader and recovery modes before flashing. Keep stock firmware offline. Learn the maker’s restore tool and slot recovery process.

Unlocking wipes the device. Relocking with modified partitions can also brick it. Restore every stock partition before considering a relock.

The official KernelSU installation guide describes supported installation models. WildKernels release instructions take priority for its own archive.

Verification after the first boot

KernelSU-Next should show an installed kernel version and grant root only to approved apps. The SUSFS WebUI should report kernel support. “SusFS not supported” means the required kernel patch is missing or incompatible.

Check the kernel string and boot logs for the expected build. Then make a normal call and test Bluetooth, cameras, Wi-Fi and sleep. Watch heat and battery drain for a full day.

Do not treat a passed root checker as proof of safety. Also test system updates, work profiles and apps you depend on. No setup can promise access to a particular banking app.

How to configure SUSFS without causing conflicts

Start with default settings. Disable verbose SUSFS logging once basic checks pass. If the supported WebUI offers kernel-version spoofing, confirm its output before enabling it at boot.

The SUSFS-FOR-KERNELSU path list is commonly stored at /data/adb/susfs4ksu/sus_path.txt. Do not copy a stranger’s full list. An incorrect system path can hide files needed by Android.

Community reports link a LineageOS overlay idmap entry in that file with horizontal display faults. Remove the last added rule if the interface rotates or renders incorrectly.

Late-mounted modules pose another problem. Fast unmount behaviour may isolate clean zygote namespaces from mounts created later. A module designed for normal KernelSU mounting may need explicit namespace handling.

Change one setting at a time. Reboot and test after each change. This makes a failed rule easy to identify.

Common failure modes in practice

  • “SusFS not supported”: the kernel lacks a compatible SUSFS patch. Installing more WebUI modules will not fix it.
  • Boot loop after flashing: the kernel branch, patch level or vendor modules may not match. Restore the original images.
  • Manager shows no KernelSU: the wrong slot may be active, or the flashed archive did not patch the expected boot path.
  • Modules appear but do nothing: late mounts may not reach the zygote namespaces used by apps.
  • Battery drain or lost performance: revert and compare under the same ROM, workload and power settings.
  • Integrity result changes: remove recent modules first. SUSFS and integrity helper modules can conflict.
  • OTA update fails: restore stock partitions, update, then obtain a kernel built for the new firmware.

Image caption: A recovery checklist for boot loops, missing SUSFS support and broken hardware.

Security, banking and update risks

Root expands what approved processes can change. A careless root grant can expose private files or weaken Android’s app isolation. Use a strict allow-list and remove modules you no longer trust.

An unlocked bootloader also changes the phone’s verified boot state. SUSFS cannot restore the original hardware-backed trust chain. Play Integrity and app checks can change without notice.

No kernel, module or property tweak can guarantee that a bank will accept a device. Some apps use server-side signals. Others add their own checks after an update.

Kernel changes may block over-the-air updates or cause a boot failure after one. Restore stock images before an OTA unless the device maintainer documents another safe path.

Readers who prefer a supported daily driver can explore our guide to de-Googled Android phones. Our Android backup guide before bootloader unlocking covers the data you should save.

A practical decision framework

Choose Wild Kernels when the release explicitly matches your GKI branch and firmware. It is a strong fit when you want KernelSU-Next plus native SUSFS controls.

Wait for a device-specific build when compatibility is inferred only from Android version. Also wait if you need NoMount or ZeroMount. Installing unrelated modules cannot supply their missing kernel drivers.

Stay on the stock kernel when banking access, corporate device policy or seamless OTA updates matter most. Root hiding lowers some signals. It does not return a modified phone to a stock security state.

Experienced users should inspect the build configuration and commits. Beginners should rely on a maintained device release with clear restore steps.

Frequently asked questions

Does Wild kernels susfs include NoMount?

No. The published releases and current build configuration reviewed in July 2026 do not include the separate NoMount VFS driver. SUSFS may hide mount evidence, but module injection still uses its configured mounting method.

Does Wild Kernels include ZeroMount?

No current published evidence shows ZeroMount in the WildKernels build. A ZeroMount-labelled userspace module cannot add a kernel driver that was not compiled into the kernel.

Can I use SUSFS with Magisk?

Not in this setup. SUSFS for KernelSU needs a kernel patched for SUSFS and a compatible KernelSU implementation. A Magisk-patched boot image does not create that kernel support.

Do I need the SUSFS-FOR-KERNELSU module?

The kernel patch is essential. A companion module may still be required for rules, WebUI controls and boot-time configuration. Follow the exact WildKernels release notes and avoid duplicate SUSFS control modules.

Will Wild kernels susfs make banking apps work?

It may reduce some filesystem signals, but there is no guarantee. Banks can inspect boot state, Play Integrity, runtime behaviour and server-side risk data. Never depend on a hiding method for urgent account access.

Can I flash the r4 Android 14 archive on Android 16?

Do not assume that it is compatible. The named r4 archive targets a 6.1 Android 14-era GKI branch. Use a release that explicitly matches the installed firmware, kernel branch and device requirements.

What should I do if the phone boot-loops?

Stop repeated experiments and enter bootloader or recovery mode. Restore the saved stock images for the active slot. If that fails, use the phone maker’s full firmware restore process.

Want the private phone without the hassle?
PrivacyPortal sells ready-to-use, de-Googled GrapheneOS Pixels — hardened, kept updated, and shipped with our encrypted Graphite messenger. Browse privacy phones →
Back to blog

Leave a comment