Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le 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`

Aperta
  • Qualcosa non va?
#300 0 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 4 giorni

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
4/5
Tempo stimato
3-5 giorni
Idoneità per principianti
38/100
Tipo di issue
Bug
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
android, c
Ambito
operating-systems, security

Direzione di ricerca

Inizia con la gestione di kptools relocation-table e kallsyms, usando l’immagine del kernel stock indicata e i comandi suggeriti -d, -f e -l. Confronta i risultati per il kernel Pixel 11 Pro GKI 6.12.69 con il log della patch, quindi verifica che la patch corretta si avvii correttamente tramite fastboot boot e non segnali più simboli core irrisolti.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

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.

Lingua principale
C
Stelle
1.6k
Fork
395
Merge medio
3g 15h
PR unite (30g)
9

Preparare l'ambiente

Questo progetto non fornisce container di sviluppo, Dockerfile né guida per i contributori, quindi l'ambiente è a tuo carico: parti dal suo README e consulta la nostra guida al primo contributo per i passaggi generali.

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di bmax121/KernelPatch

Tutte le issue di bmax121/KernelPatch

Issue simili

Altre issue su C

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.