Skip to content

Theettam Kernel 2.0 — peridot 6.1.175 (4 root flavors)

Choose a tag to compare

View all tags
@Mohithash Mohithash released this 17 Jul 04:20
· 9 commits to peridot-6.1.175 since this release
v2.0
40f891b
Theettam Kernel 2.0 — peridot — GKI 6.1.175

GKI
SUSFS
Flavors
Sched
Boot

The first LTS bump past 6.1.173 for peridot — a real 3-way merge of ACK android14-6.1-lts.

⬇ 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)

Use the manager matching your flavor. AnyKernel3 flashes the Image only — stock vendor_dlkm is kept.

Tip

All four flavors are boot-tested on-device. Still: back up boot.img and vendor_boot.img,
and keep fastboot recovery ready.

🩹 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.

✨ What's new since 1.9-vali
🐧 6.1.173 → 6.1.175 Full ACK android14-6.1-lts merge — 1010 commits, 838 files auto-merged, 6 conflicts resolved toward the device side
⚡ BORE Burst-Oriented Response Enhancer — sysctl kernel.sched_bore=0 disables it at runtime
💾 ADIOS Adaptive Deadline I/O Scheduler, now the default
✅ Zero regressions All 827 defconfig symbols, all 10 SUSFS options on every flavor, and the AnyKernel3 flasher (12/12 files byte-identical) carried over from 1.9-vali. The only deltas are additions.
🔍 Version reporting — unchanged from 1.9-vali
Layer Effect
CONFIG_LOCALVERSION reports 6.1.175-android14-11-ga3b9c44908dd-ab13320413 — stock GKI form
CONFIG_UNAME_OVERRIDE com.google.android.gms is served 6.1.118-android14-11-ga3b9c44908dd-ab13320413
SUSFS spoof_uname manager-configurable spoofing on top

uname -r returning the real version to your shell is correct — the GMS override is targeted by caller cmdline.

🔍 Testing status — all four boot-confirmed
Flavor On 6.1.175
KernelSU-Next v3.3.0 ✅ boot-tested
KernelSU-Next + SUSFS v2.2.0 ✅ boot-tested
SukiSU-Ultra + SUSFS v2.2.0 + KPM ✅ boot-tested
ReSukiSU + SUSFS v2.2.0 ✅ boot-tested
6.1.175 + BORE + ADIOS base (no root) ✅ boot-tested

The base was boot-tested on its own before any root went near it, so BORE and ADIOS were
cleared as variables independently of the root ports.

The driver pins, the SUSFS pin (8199bb65, v2.2.0) and the integration scripts are
byte-identical to the 1.9-vali builds, and none of the eleven fs/ files SUSFS touches
differ between 173 and 175 — the port carried over untouched. Only the base moved.

🙏 Credits

Built on GuidixX/kernel_xiaomi_sm8635 — device support and
most of the tuning come from there. BORE and ADIOS by Masahito Suzuki (firelzrd). SUSFS by
simonpunk. Root engines by their respective projects. ACK android14-6.1-lts by Google.

Fallback: v1.9-vali (6.1.173) remains available and boot-proven.

Assets 6
Loading