Skip to content

Theettam Kernel 2.0.1 — peridot 6.1.175

Choose a tag to compare

View all tags
@Mohithash Mohithash released this 17 Jul 05:58
· 9 commits to peridot-6.1.175 since this release
v2.0.1
1f2c32d
Theettam Kernel 2.0.1 — peridot — GKI 6.1.175

GKI
SUSFS
Flavors
Boot

peridot on GKI 6.1.175 — via a real 3-way merge of ACK android14-6.1-lts.
A bugfix release: same features as 2.0, one kernel bug fixed.

⬇ Pick one

Zip Root SUSFS
🪶 KernelSU-Next KernelSU-Next v3.3.0 —
⭐ KernelSU-Next + SUSFS KernelSU-Next v3.3.0 v2.2.0 — start here
🧩 SukiSU Ultra + SUSFS SukiSU-Ultra v2.2.0 + KPM
🧬 ReSukiSU + SUSFS ReSukiSU v2.2.0 (native)

All four are boot-tested on-device. AnyKernel3 flashes the Image only — stock vendor_dlkm is kept.

🧪 5th, experimental: KSUN + SUSFS + DroidSpaces (LXC containers) — not part of the 4 above
Zip Root SUSFS
🧪 KSUN + SUSFS + DroidSpaces KernelSU-Next v3.3.0 v2.2.0

Different config than the four above — needed CONFIG_SYSVIPC for container support, which took two
bootlooped attempts to get right (full story). Boot-tested and a
real Alpine Linux container confirmed running, but on one device, one test session — not the same
track record as the four flavors above. Full release, raw verification log, and known limitations:
droidspaces-v1 →

Tip

Keep a backup of boot.img / vendor_boot.img and fastboot recovery ready, as always.

🩹 Root or modules not mounting?

Most common cause: more than one KernelSU-family manager installed. Each flavor pairs with exactly
one manager, and the kernel crowns a single manager app at boot. With KernelSU-Next, SukiSU and ReSukiSU
managers all installed, the wrong one can end up crowned — root looks half-working and modules stop
mounting.

Try in this order:

  1. Uninstall every manager except the one for your flavor.

    Your zip Install only this manager
    KSUN3.3.0 · KSUN3.3.0-SUSFS2.2.0 KernelSU-Next
    SukiSU-Ultra-SUSFS2.2.0-KPM SukiSU
    ReSukiSU-SUSFS2.2.0 ReSukiSU

  2. Reboot. The manager is crowned during boot, so uninstalling one only takes effect after a restart.

  3. Reflash your flavor's zip — 2.0.1 or 2.0 —
    then reboot. Flashing does not touch /data, so your modules and allowlist survive.

  4. Check the manager matches the kernel. A manager much older or newer than the kernel's driver can
    fail to talk to it. Use the manager build that pairs with your flavor's driver version.

Still stuck? Note your flavor, manager app + version, and whether modules mount at all — that trio is
enough to tell a crowning problem from a real bug.

🐛 Fixed since 2.0

susfs: the ksu/priv_app SIDs resolved before the SELinux policy loaded.

susfs_ksu_resolve_sids() ran from kernelsu_init() — long before policy load, where
security_secctx_to_secid() doesn't fail but returns SECINITSID_KERNEL (1). The resolver discarded the
return code and never checked the value, so both SIDs latched to 1 for the entire boot:

KernelSU: susfs: ksu_sid=1 priv_app_sid=1

Those two SIDs feed exactly one thing: susfs's AVC denial-log spoofing, which disguises ksu-domain
denials as priv_app in the audit log. Pinned at 1, it never matched a real ksu denial (they leaked into
the log) and instead rewrote kernel-domain denials. Now a SID is only latched once it comes back greater
than SECINITSID_KERNEL, with a retry on the supercall path — which only runs post-policy, and is exactly
where a manager enables the spoof.

Scope: the hook sits behind a default-off static key, and none of the actual hiding was affected —
sus_path / sus_mount / sus_kstat go through the driver's own correctly-resolved is_ksu_domain().
2.0 hides correctly; this only matters if you enable avc log spoofing. ReSukiSU was never affected —
its native driver already resolved post-policy.

🔧 Also

  • ReSukiSU c61e643a → aa32736680c9 — two commits, both userspace/ksud, so the Image is unchanged
  • SukiSU now cloned from its canonical home (SukiSU-Ultra/SukiSU-Ultra) rather than via redirect
  • Upstreams are checked automatically on the 5th and 20th — ACK, the device base, all three root drivers, SUSFS
🔍 Everything from 2.0 — unchanged

6.1.175 via ACK android14-6.1-lts (1010 commits, 838 auto-merged, 6 conflicts resolved toward the
device side) · BORE CPU scheduler (sysctl kernel.sched_bore=0 disables at runtime) · ADIOS I/O
scheduler (default) · BBRv3 (default) · stock GKI version string · zero regressions from 1.9-vali
across all 827 defconfig symbols, all 10 SUSFS options, and the AnyKernel3 flasher.

New here? Read Upgrading an Android GKI device kernel to a newer LTS.

Built from 1f2c32d1cf7a · Previous: v2.0 · Fallback: v1.9-vali (6.1.173) · Experimental: DroidSpaces (LXC containers)
Built on GuidixX/kernel_xiaomi_sm8635 · BORE/ADIOS by firelzrd · SUSFS by simonpunk

Assets 6
Loading