4.19.325-nomount-support

Full Changelog: https://github.com/DevHamid/LKGeek_sdm660/blob/build-susfs-nomount/README.md#-change-log

Variant :

• NoMount Support
• Magic Mount Support

Choose only one who work best for u. If u choose NoMount, dont install Magic Mount module. Also otherwise same.

4.19.325-Remastered

Changelog :
Upstream to latest ReSukiSU driver 4.2.rc
Upstream SUSFS to 2.2.0 by JackA1ltman
README.md for more.

Notes:
I'm only forking and upstream.
I'm not change base. Credit for who maintain it. Check credit.

Full Changelog: https://github.com/DevHamid/LKGeek_sdm660/commits/working-susfs-inline-full

4.19.325-remastered-hotfix

CHANGELOG - su / ksud fix for SUSFS Inline Hook mode

Issue:
Root and SUSFS both work correctly (manager shows "Working", SUSFS
v2.2.0 fully functional), but no su command is available on the
device. ksud daemon does not appear in the process list after boot.
Confirmed this is specific to CONFIG_KSU_SUSFS ("SUSFS Inline Hook")
mode - the same kernel built with CONFIG_KSU_MANUAL_HOOK does not
have this problem.

Diagnosis:

• ksud install (run during flash) correctly deploys binaries to
  /data/adb/ksu/bin/ (busybox, resetprop, sus_su, etc.)
• Kernel-level init.rc auto-injection confirmed firing via dmesg
  (KernelSU: read init.rc, rc_count: 340)
• ksud post-fs-data confirmed running successfully at boot (exit
  status 0) when manually triggered
• ksud services / boot-completed stages never fire or never
  complete daemon setup - persistent ksud process never starts
• Manually running ksud debug su DOES successfully grant a real
  root shell, confirming the kernel driver / root-granting hook
  itself works correctly
• Tried adding custom init.rc triggers (legacy FDE-style, then
  zygote-start) to manually kick the daemon into starting - legacy
  triggers were safe but ineffective (device is FBE, not FDE, so
  those triggers never fire); zygote-start trigger caused a boot
  loop and was reverted
• Tested with zero custom init.rc modification at all (kernel's
  native injection only) - su still did not appear

Conclusion:
This is an upstream ReSukiSU bug specific to SUSFS Inline Hook mode
on non-GKI/built-in kernel builds - the daemon's automatic su
binary/symlink deployment does not complete, even though the
underlying root-granting mechanism is fully functional. Not fixable
from this repo's side (drivers/kernelsu/ is fetched fresh from
ReSukiSU upstream on every build, never committed here).

Fix implemented (workaround, not upstream fix):
Added a su wrapper script to the AnyKernel3 flashable zip. During
flash, the zip mounts /system read-write and copies a small script
to /system/bin/su:

#!/system/bin/sh
exec /data/adb/ksu/bin/ksud debug su "$@"

This routes any call to su through ksud's own working debug-su
mechanism, restoring normal su functionality without depending on
the daemon's broken auto-deployment. All mount/copy operations in
the flash script are non-fatal (fall back safely with || true) so a
failure here can never block or break the kernel flash itself.

Result:
su now works normally after flashing and rebooting - no manual
Termux setup, no per-user workaround needed. Verified working on a
fresh Termux session with a plain su call.

Status:
Workaround only. Root cause still present in ReSukiSU's SUSFS
Inline Hook implementation. Reported upstream:
github.com/ReSukiSU/ReSukiSU/issues

• write and fix by Claude Ai..

THIS IS STILL NOT FIX UNDERLYING SU ISSUE, BUT ATLEAST WORKS FOR NOW.

Full Changelog: working-susfs-inline-full...Hotfix-for-su