[Bug] Pixel 11 Pro (grizzly), Android 17, kernel 6.12.69: patch reports success but device fails to boot — `cant find arm64 relocation table`

从 kptools relocation-table 和 kallsyms 的处理开始，使用报告中的 stock kernel image 以及建议的 -d、-f 和 -l 命令。将 Pixel 11 Pro GKI 6.12.69 kernel 的结果与 patch log 进行比较，然后验证修正后的 patch 是否能通过 fastboot boot 成功启动，并且不再报告未解析的 core symbols。

Summary

On a Google Pixel 11 Pro (grizzly) running stock Android 17 (CD1A.260714.001.A9, kernel 6.12.69), APatch Manager patches the stock boot.img and reports patch_rc=0 / Successfully Patched!. The resulting image does not boot: the Google logo appears, the device then reboots into Android Recovery with Cannot load Android system.

The patch log shows that kptools cannot locate the arm64 relocation table and falls back to approximated kallsyms offsets. Several core symbols are not resolved. I suspect this is the root cause, but I have not verified it.

Related: #161 (same cant find arm64 relocation table message, Redmi Note 7 / 4.19), #158 (same pattern of no symbol warnings followed by a successful patch that does not boot). Both are much older non-GKI kernels; filing separately as this is a GKI 6.12 case.

Environment

Item	Value
Device	Google Pixel 11 Pro (grizzly)
Android	17 (API 37)
Build	google/grizzly/grizzly:17/CD1A.260714.001.A9/15938155:user/release-keys
Kernel	6.12.69-android16-6-g5c5f2fea42dd-ab15835541-4k
Toolchain	clang 19.0.1 (Android 14043575, +pgo, +bolt, +lto, +mlgo, based on r536225), LLD 19.0.1
Kernel build date	#1 SMP PREEMPT Fri Jul 10 21:44:24 UTC 2026
Page size	4 KB (kernel page_shift: 12)
GKI	is_gki: true
SELinux	Enforcing
APatch Manager	11224 (9a63e0f, HEAD build)
kpimg	0.13.3, compiled 15:13:08 Aug 5 2026, config android,release
Bootloader	unlocked, active slot b

Source boot.img extracted from the official factory image
grizzly-cd1a.260714.001.a9-factory-86fb8151.zip
SHA-256: 2fcadd36db141ddf0bcc1eb67e03047066db94eb3bd0932620bed4122a301289

Steps to reproduce

1. Flash the stock factory image CD1A.260714.001.A9 (full flash-all.sh, including wipe).
2. Boot the device to the home screen and complete setup offline. Enable USB debugging.
3. Verify: adb shell getprop ro.build.fingerprint → .../CD1A.260714.001.A9/...
4. Extract boot.img from image-grizzly-cd1a.260714.001.a9.zip and push it to the device.
5. Install APatch Manager 11224 and patch the image using automatic patching, with a custom SuperKey.
6. Pull the resulting image and boot it without writing to flash:
   fastboot boot apatch_patched_11224_0.13.3_dsmf.img

Expected behaviour

Device boots; APatch Manager reports an active kernel patch; su works.

Actual behaviour

Google logo appears for a few seconds, then the device reboots into Android Recovery:

Android Recovery
google/grizzly/grizzly
17/CD1A.260714.001.A9/15938155
user/release-keys

Cannot load Android system. Your data may be corrupt. If you continue to get
this message, you may need to perform a factory data reset and erase all user
data stored on this device.

init_boot was never patched or flashed, and the failure reproduces via fastboot boot, so no partition was modified during the reproduction above.

Patch log (relevant excerpts)

Invocation, as shown by the Manager:

./kptools -p -i kernel.ori -S  -k kpimg -o kernel

Kernel identification (looks correct):

[+] kernel image_size: 0x02825a00
[+] kernel uefi header: true
[+] kernel load_offset: 0x00000000
[+] kernel kernel_size: 0x028e0000
[+] kernel page_shift: 12
[+] is_gki: true
[+] disabled PL_MAP for kernel version > 6.12.23
[+] linux_banner offset: 0x12e011a
[+] linux_banner offset: 0x152cc90
[+] kernel version major: 6, minor: 12, patch: 69
[+] endian: little

Relocation table not found — kptools falls back to approximation:

[?] cant find arm64 relocation table
[+] arm64 relocation kernel_va: 0xffffffffffffffff
[?] try kallsyms_offsets first for 64-bit relative-base kernel
[+] approximate kallsyms_offsets range: [0x0172fc18, 0x017b08ac) count: 0x00020325
[+] kallsyms_token_table offset: 0x0172f688
[+] kallsyms_num_syms offset: 0x0152cdd8, value: 0x00020324
[+] kallsyms_offsets offset: 0x0172fc18

Unresolved symbols:

[?] no symbol: printk
[?] no symbol: printk
[?] no symbol: memblock_alloc: memblock_virt_alloc_try_nid
[?] no symbol: memblock_phys_alloc_try_nid: memblock_virt_alloc_try_nid
[?] no symbol: __cfi_slowpath
[?] no symbol: __cfi_slowpath_diag

Patch nevertheless reports success:

+ patch_rc=0
[+] patch done: kernel
- Repacking boot image
[+] Header Version: 4, Page Size: 4096, fmt_size: 0
[+] Compressing new Kernel with LZ4 Legacy...
[+] Found AVB footer in rest data. 0xb40000795e21ee40
[+] Repack completed: new-boot.img
- Successfully Patched!

The patched image is 67108864 bytes, identical in size to the stock boot.img.

Additional observations

• Same symptom on the previous build CD1A.260618.001.A7 with the same Manager version. In that attempt the image was flashed rather than fastboot booted, which required reflashing the stock boot.img to recover.
• Only boot was ever targeted; init_boot was never touched.
• On this device, KernelSU (LKM mode), Magisk and ReSukiSU are reported working by other users, so the kernel itself appears to be rootable by non-patching approaches. This looks specific to KernelPatch's binary patching path.
• disabled PL_MAP for kernel version > 6.12.23 suggests KernelPatch already has a guard for kernels in this range; 6.12.69 is well past that threshold.

Hypothesis (unverified)

With the relocation table missing, kallsyms offsets are approximated rather than resolved, so hooks may be placed at incorrect addresses. That would explain a kernel that starts (logo appears) and then dies before userspace comes up. I have no serial console on this device and cannot confirm this from a panic log.

Happy to run additional kptools commands (-d, -f, -l) against the stock kernel image and attach the output, or to test a patched build, if that helps.