Hacktoberfest 2026: những issue maintainer đã đánh dấu cho tháng Mười, đang mở và phù hợp người mới. Xem issue Hacktoberfest

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

Đang mở
  • Có gì không ổn?
#300 0 bình luận 0 reaction 0 người được giao Xem trên GitHub

Maintainer thường phản hồi trong vòng 3 ngày

Chưa có ai nhận issue này.

Đánh giá

Độ khó
4/5
Thời gian dự kiến
3-5 ngày
Mức phù hợp với người mới
38/100
Loại issue
Lỗi
Độ rõ ràng
Khá rõ ràng
Mức độ hoạt động
Sôi nổi
Công nghệ
android, c
Lĩnh vực
operating-systems, security

Hướng nghiên cứu

Bắt đầu với việc xử lý kptools relocation-table và kallsyms, sử dụng stock kernel image được nêu và các lệnh -d, -f và -l được đề xuất. So sánh kết quả đối với kernel Pixel 11 Pro GKI 6.12.69 với patch log, sau đó xác minh rằng patch đã sửa khởi động thành công qua fastboot boot và không còn báo cáo các core symbol chưa được giải quyết.

Do mô hình lập chỉ mục viết ra từ nội dung của issue.

Mô tả

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.

Ngôn ngữ chính
C
Star
1.6k
Fork
395
Merge trung bình
3 ngày 23 giờ
Pull request đã merge (30 ngày)
7

Chuẩn bị môi trường

Dự án này không cung cấp dev container, Dockerfile hay hướng dẫn đóng góp, nên bạn cần tự thiết lập môi trường: hãy bắt đầu từ README và xem hướng dẫn đóng góp lần đầu của chúng tôi để biết các bước chung.

Bắt đầu từ đâu

  1. Đọc hết issue, rồi đọc hướng dẫn đóng góp của dự án.
  2. Bình luận trên issue rằng bạn sẽ nhận — tránh hai người làm cùng một việc.
  3. Fork repository và làm thay đổi trên một nhánh.
  4. Mở pull request có tham chiếu số hiệu của issue.

Issue khác của bmax121/KernelPatch

Tất cả issue của bmax121/KernelPatch

Issue tương tự

Thêm issue về C

Nhận issue mới trong hộp thư của bạn

Bản tóm tắt ngắn những issue GitHub phù hợp với người mới.