How to Check Android Kernel KALLSYMS Support for KernelSU and SUSFS

TL;DR: To assess susfs for kernelsu compatibility, inspect the running Android kernel configuration for CONFIG_KALLSYMS and CONFIG_KSU_SUSFS. CONFIG_KALLSYMS=y only confirms that a kernel symbol table exists. KernelSU still needs the correct integration and matching kernel interface, while SUSFS requires kernel-side patches that a userspace module cannot add.

By the PrivacyPortal team

Last updated 17 July 2026

Checking KALLSYMS is a useful first diagnostic, but it is not a compatibility test by itself. A workable KernelSU and SUSFS installation needs the right device kernel, Android release, Generic Kernel Image or device-specific integration, and Kernel Module Interface. Before changing anything, back up your files and retain the exact stock boot, init_boot and other relevant factory images. Unlocking the bootloader wipes user data. Flashing an incompatible kernel can cause a boot loop or brick, affect warranty support and over-the-air updates, weaken security, and stop banking, payment or DRM apps from working. No configuration can be promised to pass a particular app’s Play Integrity or root-detection checks.

What KALLSYMS means for SUSFS for KernelSU

KALLSYMS is the Linux kernel’s symbol-table facility. Kernel symbols are names associated with functions and data inside the kernel. Root frameworks and kernel patches may use these symbols to find or interact with kernel functionality, especially when supporting multiple compatible builds.

CONFIG_KALLSYMS=y means the kernel contains its core symbol table. CONFIG_KALLSYMS_ALL=y extends coverage beyond functions to more symbols. CONFIG_KALLSYMS_BASE_RELATIVE=y changes how addresses are stored, reducing the table’s size on supported architectures. CONFIG_KALLSYMS_ABSOLUTE_PERCPU may remain disabled without proving that KernelSU is incompatible.

As of 17 July 2026, CONFIG_KALLSYMS=y confirms a core kernel symbol table; it does not prove KernelSU or SUSFS compatibility.

SUSFS, short for “SUS file system”, implements kernel-level facilities used to conceal selected mounts and filesystem artefacts. The SUSFS4KSU module supplies userspace controls, scripts and configuration, but those controls need corresponding SUSFS code in the running kernel.

Image caption: A kernel configuration check separates general symbol support from KernelSU integration and SUSFS-specific support.

The four checks that actually determine compatibility

Check	What a positive result establishes	What it does not establish
CONFIG_KALLSYMS=y	The kernel includes its core symbol table.	That KernelSU hooks, SUSFS patches or the right KMI are present.
KernelSU integration is documented	The kernel was built or packaged for a stated KernelSU installation path.	That it matches your precise firmware or supports SUSFS.
CONFIG_KSU_SUSFS=y	The build configuration enables SUSFS integration for KernelSU.	That every required patch is correct or that apps will accept the device.
SUSFS manager status is supported	The running kernel and userspace module can communicate.	Guaranteed stability, successful hiding or Play Integrity verdicts.

A trustworthy compatibility claim should satisfy all four checks, not merely show a screenshot of CONFIG_KALLSYMS. It should also name the supported device, ROM type, Android release, kernel version and firmware base.

Prerequisites before checking or installing

• A computer with the current official Android SDK Platform-Tools, including adb and fastboot.
• USB debugging enabled and an authorised adb connection.
• The exact device model, current build fingerprint and kernel release.
• A complete backup, because bootloader unlocking performs a factory reset.
• Stock factory images for the installed firmware, including the relevant boot or init_boot image.
• A KernelSU or KernelSU Next build explicitly intended for the device and firmware.
• A SUSFS-patched kernel plus the matching SUSFS4KSU userspace module.

Do not mix images from similar model names, different regional variants or a newer security update. Kernel and vendor modules must agree on their Kernel Module Interface, commonly abbreviated to KMI. A file that boots on one monthly build may fail after an over-the-air update.

The Android Generic Kernel Image documentation explains how the generic kernel, vendor modules and stable KMI fit together. KernelSU’s official installation guide should be used to identify the appropriate installation method rather than assuming every GKI device accepts the same image.

How to check and use SUSFS with KernelSU

1. Back up and record the baseline. Copy personal data off the phone, export authenticator recovery information and save the matching factory images. Run adb shell getprop ro.build.fingerprint and adb shell uname -a, then retain both outputs. If the bootloader is still locked, understand that unlocking it will erase the phone before proceeding.
2. Confirm adb access. Connect the phone, run adb devices and approve the debugging prompt on the handset. The serial number should show as “device”, not “unauthorised”. This inspection does not itself require root when the manufacturer exposes the kernel configuration publicly.
3. Check whether the running configuration is exposed. Run adb shell ls -l /proc/config.gz. If the file exists and is readable, continue. If it is absent, that does not mean KALLSYMS is disabled; some production kernels omit CONFIG_IKCONFIG_PROC or restrict access. Obtain the exact build configuration from the kernel maintainer or corresponding published kernel source instead.
4. Extract the relevant configuration. Run adb shell "zcat /proc/config.gz | grep -E 'CONFIG_(KALLSYMS|KSU|KSU_SUSFS)'". A typical symbol-enabled kernel may report CONFIG_KALLSYMS=y, CONFIG_KALLSYMS_ALL=y and CONFIG_KALLSYMS_BASE_RELATIVE=y. Save the complete output rather than reporting only the first matching line.
5. Interpret KALLSYMS conservatively. CONFIG_KALLSYMS=y passes only the symbol-table check. A missing CONFIG_KSU entry may mean KernelSU is not compiled into the running kernel, although exact labels and integration details can vary between maintained implementations. Do not infer support from the kernel version alone.
6. Look for explicit SUSFS support. CONFIG_KSU_SUSFS=y is the important configuration indicator. Confirm that the maintainer also states the SUSFS version, KernelSU or KernelSU Next version, supported firmware and installation route. A generic “KSU supported” label is insufficient.
7. Obtain matching files. Use only a kernel or boot image published for the exact model, ROM type, Android build and KMI. Download the matching KernelSU Next manager and SUSFS4KSU userspace module named in the “Modules, apps & files to try” section supplied with this guide. Verify any published checksum before installation.
8. Test the kernel using the documented device procedure. Some bootloader implementations permit a temporary fastboot boot test; others require flashing a specific partition and some do not support temporary booting at all. Follow the device maintainer’s command exactly. Never guess between boot and init_boot, and do not flash a kernel archive through a tool unless its documentation explicitly supports that format.
9. Install the manager and userspace component. After the compatible KernelSU kernel boots, install its matching manager application. From the manager’s module page, install the corresponding SUSFS4KSU module and reboot if its documented procedure requests it. The module cannot retrofit SUSFS into an unpatched kernel.
10. Verify the running result. Re-run adb shell uname -a, confirm that KernelSU reports an expected version, then open the SUSFS module’s WebUI. Check its status before enabling any hiding options. If it displays “SusFS not supported”, stop: the running kernel lacks usable SUSFS support or the versions do not match.
11. Test stability before adding other modules. Check Wi-Fi, mobile data, camera, biometrics, sleep, charging and several cold boots. Then test important apps without assuming they will work. Add optional components such as ReZygisk, Play Integrity Fix or TrickyStore only one at a time, with a reboot and test between changes; these tools address different layers and are not required merely to prove SUSFS kernel support.

Image caption: The SUSFS WebUI should confirm kernel support before any hiding rules or companion modules are enabled.

Why a module cannot add missing SUSFS support

The downloadable SUSFS4KSU package is often described casually as a module, which can make it sound self-contained. In practice, it is the userspace side of a two-part system. The kernel must already contain compatible SUSFS patches and configuration; the module exposes controls and applies policy to those kernel facilities.

If the WebUI says “SusFS not supported”, reinstalling the same module, changing its permissions or adding Zygisk will not create the absent kernel code. The viable options are to obtain a correctly patched kernel for the exact build, compile one from matching published source, or return to a stock or otherwise supported configuration.

The upstream SUSFS4KSU project source is the appropriate reference for patch and userspace-component relationships. Forked packages may change scripts, defaults or version compatibility, so confirm provenance before granting them root-level access.

A “SusFS not supported” status is a kernel-support failure, not evidence that the userspace module needs more permissions.

GKI, KMI and integration paths

GKI means Generic Kernel Image, Android’s effort to separate a reusable core kernel from device-specific vendor modules. KMI defines the interface those modules expect. Matching a broad label such as “android14-6.1” is necessary but may not be sufficient: the precise KMI generation, vendor requirements and firmware build still matter.

Current KernelSU implementations offer different integration paths depending on kernel generation and device support. A patched boot or init_boot image for KernelSU is not interchangeable with a Magisk-patched image. Magisk applies its own boot-image modifications and does not add SUSFS kernel patches.

On a non-GKI phone, KernelSU generally needs a device kernel compiled from source with the appropriate integration. On supported GKI devices, a maintained generic build may be possible, but only when its KMI and packaging match the device. SUSFS adds another requirement: the selected kernel build must explicitly include its patches.

Image caption: GKI compatibility depends on the generic kernel, vendor modules and KMI matching as a complete set.

Common failure modes and what they mean

• Only CONFIG_KALLSYMS appears: symbol support exists, but KernelSU and SUSFS support remain unproven.
• /proc/config.gz is missing: inspect the maintainer’s build configuration or exact kernel source; do not treat absence as CONFIG_KALLSYMS=n.
• The manager says KernelSU is not installed: the expected KernelSU-enabled kernel is not running, the installation targeted the wrong image, or the integration is incompatible.
• The WebUI says SUSFS is unsupported: kernel-side SUSFS support is missing or incompatible.
• The phone boot-loops after flashing: restore the exact stock image using the device’s documented recovery method. Repeatedly flashing unrelated builds increases risk.
• OTA installation fails: modified boot partitions commonly disrupt incremental updates. Restore stock images and follow the framework’s documented update procedure.
• Banking or payment apps still refuse to run: apps evaluate multiple signals, including bootloader state, Play Integrity, installed software and behavioural checks. SUSFS addresses only some kernel and filesystem visibility.
• Battery drain or performance regression appears: compare against the recorded stock baseline. Community reports vary by kernel build, so a regression is grounds to restore stock rather than add more modules.

A practical go or no-go decision framework

Proceed only when the maintainer identifies your exact device and firmware, publishes the KernelSU and SUSFS versions, confirms the integration route, provides recovery instructions, and the configuration includes CONFIG_KSU_SUSFS=y.

Pause when only CONFIG_KALLSYMS=y is known, the download is labelled merely by kernel series, or the package comes from an unverifiable repost. Ask the maintainer for the build configuration and supported KMI.

Do not proceed when the device variant is uncertain, stock recovery images are unavailable, the package expects another ROM family, or an essential banking or workplace app cannot tolerate an unlocked bootloader.

One AOSP-only Vantom build paired KernelSU Next 1.0.7 build 12646 with SUSFS 1.5.7; those version numbers describe that build, not universal device compatibility.

If root is not essential, retaining the locked bootloader and stock verified boot is normally the safer choice. Readers who want a broader foundation can consult our Android rooting and boot-image guide and bootloader unlocking safety checklist.

Frequently asked questions

Does CONFIG_KALLSYMS=y mean my phone supports KernelSU?

No. It confirms that the kernel contains its core symbol table. KernelSU also needs a supported integration path, a compatible kernel build and the correct device and KMI match.

Does KernelSU automatically include SUSFS?

No. A KernelSU-capable kernel may omit SUSFS. Look for explicit SUSFS patch documentation and CONFIG_KSU_SUSFS=y, then verify support in the userspace module’s WebUI.

Can I install SUSFS for KernelSU as a normal module?

You can install the userspace SUSFS4KSU module through a compatible manager, but it will work only when the running kernel already contains matching SUSFS support. A module cannot add missing kernel patches.

Can I use SUSFS with a Magisk-patched boot image?

Not as a substitute for a SUSFS-patched KernelSU kernel. Magisk’s boot-image changes do not add SUSFS kernel code, and combining root frameworks can cause conflicts. Return to a known stock baseline before following a maintainer-supported KernelSU installation path.

Will SUSFS make every banking app work?

No. Apps can inspect bootloader state, Play Integrity verdicts, filesystem artefacts and other signals. Results vary by app version, device and configuration, and no method should be presented as defeating a specific bank’s checks.

What should I do if /proc/config.gz does not exist?

Find the configuration used to compile the exact running kernel through its maintainer or published source. Missing /proc/config.gz may only mean that runtime configuration export is disabled.

What is the safest recovery plan?

Keep matching stock images before modifying the phone, know how to enter the bootloader or manufacturer recovery mode, and document the original slot and build. If stability or app compatibility deteriorates, restore the stock images and remove root using the framework’s documented process.