find_token_table error on LKGeek-perf-devhamid 4.19.325 kernel (Xiaomi Wayne, SDM660) — fails before kallsyms_token_table offset is even found

[DevHamid]

Device: Xiaomi Wayne (SDM660)
ROM: AxionOS GSI
Kernel: LKGeek-perf, custom build, kernel version 4.19.325
Tool used: Tried both standalone KernelPatch (via FolkPatch script) and APatch — same failure in both, since they share the same kptools core.
Kernel banner:
Linux version 4.19.325-LKGeek-perf (lkdenchin@Github-Action) (Android (13174946, +pgo, +bolt, +lto, +mlgo, based on r547379) clang version 20.0.0, LLD 20.0.0 (/mnt/disks/build-disk/src/android/llvm-r547379-release/out/llvm-project/llvm b718bcaf8c198c82f3021447d943401e3ab5bd54)) #1 SMP PREEMPT Wed Apr 22 14:35:22 UTC 2026
Full patch log:

---

FolkPatch Boot Image Patcher

---

• Backing boot.img
• Patching kernel

• ./kptools -p -i kernel.ori -S su -k kpimg -o kernel
  [-] /home/runner/work/KernelPatch/KernelPatch/tools/patch.c:634/patch_update_img(); analyze_kallsym_info error
  [+] kernel image_size: 0x01df3818
  [+] kernel uefi header: false
  [+] kernel load_offset: 0x00000000
  [+] kernel kernel_size: 0x02187000
  [+] kernel page_shift: 12
  [+] new kernel image ...
  [+] is_gki: false
  [+] linux_banner 1: Linux version 4.19.325-LKGeek-perf (lkdenchin@Github-Action) (Android (13174946, +pgo, +bolt, +lto, +mlgo, based on r547379) clang version 20.0.0, LLD 20.0.0 (/mnt/disks/build-disk/src/android/llvm-r547379-release/out/llvm-project/llvm b718bcaf8c198c82f3021447d943401e3ab5bd54)) merge dev #1 SMP PREEMPT Wed Apr 22 14:35:22 UTC 2026
  [+] linux_banner offset: 0x142000f
  [+] kernel version major: 4, minor: 19, patch: 255
  [-] /home/runner/work/KernelPatch/KernelPatch/tools/kallsym.c:129/find_token_table(); find token_table error
• patch_rc=1
• set +x

• Patch kernel error: 1
• Patch process exited with code: 1
  Patch failed.
  What I've checked:
  Failure happens identically via both KernelPatch/FolkPatch and APatch, ruling out a wrapper-script issue.
  Fails at find_token_table() — before kallsyms_token_table offset is even printed, which is earlier than most other reported kallsyms failures in this repo.
  I don't have access to the kernel source or build config for this GSI-paired kernel, so I can't confirm CONFIG_KALLSYMS/CONFIG_KALLSYMS_ALL directly.
  I've attached the raw unpacked kernel binary (via magiskboot unpack boot.img) below in case it helps identify what's different about this build's kallsyms layout.
  Attached: kernel (29.95MB, raw kernel image extracted from boot.img)

kernel.zip

[DevHamid]

Update: confirmed CONFIG_KALLSYMS_ALL=y is genuinely set in the built kernel
I rebuilt the kernel with CONFIG_KALLSYMS=y and CONFIG_KALLSYMS_ALL=y explicitly set in the defconfig, and extracted the embedded ikconfig from the compiled kernel binary (via CONFIG_IKCONFIG_PROC) to verify:
CONFIG_KALLSYMS=y
CONFIG_KALLSYMS_ALL=y
CONFIG_KALLSYMS_BASE_RELATIVE=y

Despite this, kptools still reports:

[?] no linux_banner, CONFIG_KALLSYMS_ALL=n
and fails at:
[-] tools/kallsym.c:829/correct_addresses_or_offsets_by_vectors(); can't locate vectors
Updated patch log:
[+] kallsyms_token_table offset: 0x017f76e0
[+] endian: little
[+] kallsyms_token_index offset: 0x017f7a10
[?] kallsyms_markers elem_size 8 rejected at [2] (val 0x10000000001)
[+] kallsyms_markers range: [0x017ca9d8, 0x017cad98), count: 0x000000ef
[+] kallsyms_names offset: 0x01704d00
[+] arm64 relocation kernel_va: 0xffffff8010000000
[+] arm64 relocation table range: [0x01a2da18, 0x01cba8a8), count: 0x0001b346
[+] apply 0x0001b345 relocation entries
[?] find kallsyms_markers error
[+] try kallsyms_offsets first for 64-bit relative-base kernel
[+] approximate kallsyms_offsets range: [0x016c95d8, 0x01704cec) count: 0x0000edc5
[?] no linux_banner, CONFIG_KALLSYMS_ALL=n
[+] names table vector index: 0x00000013, pid_vnr index: 0x00000557
[-] tools/kallsym.c:829/correct_addresses_or_offsets_by_vectors(); can't locate vectors

This suggests the CONFIG_KALLSYMS_ALL=n detection message is a heuristic/fallback inference rather than an actual read of the kernel's config — since I've confirmed via the embedded ikconfig that ALL=y is genuinely set. My kernel also has CONFIG_KALLSYMS_BASE_RELATIVE=y, and is built with BOLT + LTO + mlgo optimizations (banner: +pgo, +bolt, +lto, +mlgo), which may be interacting with the relative-offset vector-correlation logic in an unexpected way.

my_config.txt

kernel.zip

Happy to provide the updated kernel binary or any additional diagnostics if that'd help narrow this down. Kernel/build details unchanged from my earlier comment (Xiaomi Wayne, SDM660, LKGeek-perf 4.19.325).