Stuck at the "Google" screen after flashing

[powellnorma]

Using FKM instead worked fine. Others seem to have the same problem:

https://forum.xda-developers.com/t/kernel-blu_spark-r171-a13-jan-2023.4182455/post-87337427
https://forum.xda-developers.com/t/kernel-blu_spark-r171-a13-jan-2023.4182455/post-87940883

[capntrips]

I looked at the log posted in one of your links and didn't see anything obvious.

I don't have a Pixel 4a, so it will be hard for me to test. Does it happen every time, or is it intermittent?

From a glance at the kernel zip, boot is the only partition modified. Would you be willing to post a dump of the stock partition and the modified one after flashing both with Kernel Flasher and FKM? I'm not sure why the latter two would be different, since the actual write should be handled by AK3 in both cases, but it might be a good first step.

[powellnorma]

So the following includes the stock boot partition and the stock-rooted one. I am flashing the custom kernel based on the latter. I have included the resulting boot.img from 'stock-rooted -> custom' via FKM and KernelFlasher.

Link: https://wormhole.app/D3Q8J#le7SnR_yQmni1Ds3zJMiMQ

What I additionally noticed was that after flashing the custom Kernel with KernelFlasher, the KernelFlasher app crashes and can't be opened again! .. Even when clearing its cache + local storage.

Does it happen every time, or is it intermittent?

I think it happens everytime, but I can't say that for sure.
The bootloop itself can only be fixed by flashing an older boot.img via fastboot

[powellnorma]

the KernelFlasher app crashes and can't be opened again

Once I flash the (working) backup of stock-rooted manually via dd, KernelFlasher opens again just fine

[capntrips]

Thanks for the files. I've got them downloaded and will take a peek at them shortly.

the KernelFlasher app crashes and can't be opened again

It sounds like it's flashing a bad image to boot and can't read that image on startup. Does it open to a error screen, or is it a hard crash?

Once the issue with flashing goes away, the inability to open the app should as well, but if you'll provide a logcat during the crash, I can try to catch the specific issue and at least display a useful error message.

If you reflash in KernelFlasher to get the crash logcat, the flash log from FKM when you revert might also be useful.

[capntrips]

I'm able to unpack the KernelFlasher flashed image, but magiskboot throws bad cpio header when attempting to test or extract the ramdisk. That same error is sprinkled through your AK3 log as well.

I'm curious if you can can copy, unpack, and extract the files if performed directly from the terminal. You can test it with the following commands:

cd /data/user/0/com.github.capntrips.kernelflasher/files
rm -rf akhome
mkdir akhome
cd akhome
dd if=/dev/block/by-name/boot_b of=boot.img
/data/adb/magisk/magiskboot unpack boot.img
/data/adb/magisk/magiskboot cpio ramdisk.cpio sha1

If for some reason it doesn't work there, can you also try in /data/local/tmp as well?

Edit: Also, what is the output of mount | grep -E ' /data |/data/user|/data/local'?

[powellnorma]

Thank you for investigating!

Does it open to a error screen, or is it a hard crash?

A hard crash, I will attach the logcat in the .zip

the flash log from FKM when you revert might also be useful

I have attached the FKM log from 'stock-root -> custom'

I'm curious if you can can copy, unpack, and extract the files if performed directly from the terminal.

stock-rooted -> yes
KernelFlasher -> no (bad cpio header)
FKM -> yes

what is the output of mount | grep -E ' /data |/data/user|/data/local'?

/dev/block/dm-36 on /data type f2fs (rw,lazytime,seclabel,nosuid,nodev,noatime,background_gc=on,discard,no_heap,user_xattr,inline_xattr,acl,inline_data,inline_dentry,flush_merge,extent_cache,mode=adaptive,active_logs=6,reserve_root=32768,resuid=0,resgid=1065,alloc_mode=default,checkpoint_merge,fsync_mode=nobarrier,discard_unit=block)
/dev/block/dm-36 on /data/user/0 type f2fs (rw,lazytime,seclabel,nosuid,nodev,noatime,background_gc=on,discard,no_heap,user_xattr,inline_xattr,acl,inline_data,inline_dentry,flush_merge,extent_cache,mode=adaptive,active_logs=6,reserve_root=32768,resuid=0,resgid=1065,alloc_mode=default,checkpoint_merge,fsync_mode=nobarrier,discard_unit=block)

Link: https://wormhole.app/ZnXNL#956g75dPB_QWUvvMszEgiQ

[capntrips]

I didn't get to your zip in time, if you wouldn't mind sharing it again. I'll be out of pocket for two days beginning in the morning, so if it doesn't let you set an expiration beyond that, we may need to wait until I return or use a different file host.

Maybe we can try running the AK3 zip directly, just to rule out something with the environment (assuming the zip is in /sdcard/Download):

cd /data/user/0/com.github.capntrips.kernelflasher/files
rm -rf akhome
mkdir akhome
unzip -p /sdcard/Download/blu_spark_r171-pxl4a_0d9a2328c.zip META-INF/com/google/android/update-binary > akhome/update-binary
AKHOME=$(pwd)/akhome $SHELL ./akhome/update-binary 3 1 /sdcard/Download/blu_spark_r171-pxl4a_0d9a2328c.zip

You may have also included it in the previous zip, but might be interesting to see the logcat during a failed flash, as well.

[powellnorma]

just to rule out something with the environment

When I execute those commands I get:

./akhome/update-binary: line 31: /proc/self/fd/: Is a directory
./akhome/update-binary: line 22: /proc/self/fd/: Is a directory
unzip: couldn't open : I/O error
ls: tools: No such file or directory
./akhome/update-binary: line 22: /proc/self/fd/: Is a directory

New Link: https://send.q1q.wtf/download/db7608ac460bc63c/#ANDNn9RQbjYxdxJgmB4U3w

[capntrips]

Sorry for the delay in getting back to you on this. I just returned home from nearly two weeks on the road yesterday and am still playing a bit of catch up.

Now that I'm home, I have access to a Pixel 6a to run a few tests. I probably forgot a step somewhere with running AK3 directly. I'll have to track down the script I was using before I wrote Kernel Flasher.

[capntrips]

I couldn't immediately find my old version, but I found the script that was the basis for that script that developed into Kernel Flasher. I reworked it to basically the same thing Kernel Flasher does in the background.

flash_ak3.sh.gz

I reduced the latest stock AK3 to just the dump_boot command, which will simply split out and unpack the ramdisk. We'll "flash" this file to verify AK3 works in the same context outside of the app.

UPDATE-AnyKernel3.zip

Once you have those two files, run the following commands:

adb push flash_ak3.sh.gz /data/local/tmp
adb push UPDATE-AnyKernel3.zip /sdcard/Download
adb shell
su
cd /data/local/tmp
gunzip flash_ak3.sh.gz
chmod +x flash_ak3.sh
./flash_ak3.sh

In theory, you should get output similar to this.

Edit: If the above works, it might also be interesting to flash that zip in Kernel Flasher and see if you get any errors.

Note: I tested both the command line and Kernel Flasher operations with success on Pixel 6a and Pixel 7 (on init_boot).

[capntrips]

I realized dump_boot may not pass through any errors, so I added a test and sha1 to the operation. I also dropped the attributes function to silence the output a bit.

UPDATE-AnyKernel3.zip

[powellnorma]

Hey, this seems to work fine, here are the logs I got: logs.zip

[capntrips]

There's obviously no issue with unpacking the image or extracting the ramdisk in Kernel Flasher on your device. It's weird that it has trouble in the write phase. It might be interesting to patch blu_spark_r171-pxl4a_0d9a2328c.zip with the relevant lines from that script, just to confirm it is able to read everything before it tries to flash the image.

blu_spark_r171-1-pxl4a.patch.gz

Assuming you have the above patch and blu_spark_r171-pxl4a_0d9a2328c.zip in your working directory, you should be able to run the following commands:

gunzip -k blu_spark_r171-1-pxl4a.patch.gz
mkdir blu_spark_r171-pxl4a_0d9a2328c
cd blu_spark_r171-pxl4a_0d9a2328c
unzip ../blu_spark_r171-pxl4a_0d9a2328c.zip
patch -p1 < ../blu_spark_r171-1-pxl4a.patch
zip -r9 ../blu_spark_r171-1-pxl4a-debugging.zip * -x .git README.md *placeholder
cd ..
rm -r blu_spark_r171-pxl4a_0d9a2328c
adb push blu_spark_r171-1-pxl4a-debugging.zip /sdcard/Download/

Note: This one will actually flash blu_spark r171 to your device.

I patched blu_spark_r171-pxl4a_0d9a2328c.zip with the below patch and dropped the stock rooted boot.img from the backups you shared with me previously (renamed to block.img to avoid a conflict with AK3) into the zip. I flashed it with Kernel Flasher, and it completed without issue on a Pixel 6a, and the resulting target.img matched almost exactly to the backup you shared with me after flashing with FKM. I would be curious to see if that one completes without error on your device, as well.

blu_spark_r171-2-pxl4a.patch.gz

Assuming you have the above patch, blu_spark_r171-pxl4a_0d9a2328c.zip, and your backups folder all in your working directory, you should be able to run the following commands:

gunzip -k blu_spark_r171-2-pxl4a.patch.gz
mkdir blu_spark_r171-pxl4a_0d9a2328c
cd blu_spark_r171-pxl4a_0d9a2328c
unzip ../blu_spark_r171-pxl4a_0d9a2328c.zip
patch -p1 < ../blu_spark_r171-2-pxl4a.patch
cp ../backups/stock-rooted/boot.img block.img
zip -r9 ../blu_spark_r171-2-pxl4a-debugging.zip * -x .git README.md *placeholder
cd ..
rm -r blu_spark_r171-pxl4a_0d9a2328c
adb push blu_spark_r171-2-pxl4a-debugging.zip /sdcard/Download/

Note: This one will not actually flash anything, as it will create a /data/local/tmp/target.img instead.

If you have any trouble generating the zips, let me know, and maybe I can share them with you directly via DM on XDA or elsewhere. I would rather not host blu_spark test builds publicly, if only to avoid the possibility of someone ending up with them by accident.

Since there were no major changes to the relevant file in blu_spark r172, you can apply those same patches to it instead, if you prefer. I used r171 in my testing just to make it easier to compare against your logs.

Note: The -debugging suffix on the above zips will cause AK3 to write a timestamped debug.tgz to the root of your /sdcard. These might be worth sharing, if you run into any errors while flashing the zips.

Sorry for the wall of text, but hopefully I didn't miss anything. Thanks for your help with debugging this.

[capntrips]

Someone shared a debug.tgz on XDA, so there's no need to run the above test. It looks like the ramdisk gets unpacked and extracted without issue, so something must be going wrong later in the process.

[capntrips]

Since the ramdisk is fine here and here but throws an error here, I'm guessing the issue is here or here. The ramdisk.cpio with the bad cpio header ends up in the debug.tgz because the bad one is copied here.

With the kernel zip and a good boot.img in your /sdcard/Download folder, can you run the following:

adb shell
su
cd /data/local/tmp
mkdir {bin,ramdisk}
cd bin
unzip -j /sdcard/Download/blu_spark_r171-pxl4a_0d9a2328c.zip tools/{busybox,magiskboot}
PATH="$(pwd):$PATH"
busybox --install -s .
cd ..
magiskboot unpack -h /sdcard/Download/boot.img
cd ramdisk
EXTRACT_UNSAFE_SYMLINKS=1 cpio -d -F ../ramdisk.cpio -i
find . | cpio -H newc -o > ../ramdisk-new.cpio
magiskboot cpio ../ramdisk-new.cpio test

I intentionally left out the bits copying the ramdisk files from the kernel zip to isolate it, so if the above works without a bad cpio header error, run the following in the same adb shell:

cd ..
unzip /sdcard/Download/blu_spark_r171-pxl4a_0d9a2328c.zip "ramdisk/*"
cd ramdisk
find . | cpio -H newc -o > ../ramdisk-new2.cpio
magiskboot cpio ../ramdisk-new2.cpio test

You can clean up with:

rm -rf /data/local/tmp/{bin,dtb,header,kernel,ramdisk,ramdisk-new.cpio,ramdisk-new2.cpio,ramdisk.cpio}

Edit: I'm guessing the second set of commands is unnecessary, as a kernel zip for another device with the same issue here doesn't contain that folder.

Edit 2: If it works directly from the command line, here's a zip (patch) to try it in Kernel Flasher:

1-1441129629-debugging.zip

[capntrips]

The issue has been isolated. See here, here, here, here, and here for more info. AK3 uses busybox rather than toybox, but it was affected in the same way and hasn't been patched. It is inconsistent between devices as it was patched in the kernel, and some devices may not have gotten the patch.

The solution was to basically chroot the flashing environment, which works around the issue. FKM and likely EXKM were already doing this or something very similar, which is why they weren't affected.

[capntrips]

A test build with the fix included, v1.0.0-alpha12+tempfs, is on the releases page. I'll close this issue when I merge it into main. Thanks for the report and your help in getting this debugged.

[capntrips]

fixed in c834f5f and released in v1.0.0-alpha14