About broken boot (bootloop) after flashing fork sultan kernel
The issue is not OrangeFox.
What is happening:
AnyKernel rebuilds boot first.
Then it rebuilds vendor_kernel_boot.
Some forked installers forget to remove the kernel image after step 1, so AnyKernel picks it up again for vendor_kernel_boot.
As a result, vendor_kernel_boot gets packed with kernel + dtb + ramdisk when it should not, and the image can become invalid.
Why OrangeFox is not the cause:
OrangeFox is only running the installer script. The failure comes from installer logic and packing behavior in that AnyKernel flow, not from recovery itself.
Now that OrangeFox on our devices is fully functional (including decryption), this bug will become visible to more users.
Why it can look random:
Sometimes flashing may appear to succeed if there is enough space in vendor_kernel_boot for kernel + dtb + ramdisk.
That does not mean the installer is correct; it just means the overflow/format issue did not trigger in that specific case.
Practical fix between boot and vendor_kernel_boot steps:
rm -f "$AKHOME/Image.lz4"
or
rm -f "$home/Image.lz4"
boot image installation
block=boot;
is_slot_device=1;
. tools/ak3-core.sh;
split_boot;
flash_boot;
rm -f "$AKHOME/Image.lz4"; # <- add to remove kernel
rm -f "$home/Image.lz4" # <- add to remove kernel
vendor_kernel_boot installation (for dtb)
block=vendor_kernel_boot;
is_slot_device=1;
reset_ak;
split_boot;
flash_boot;
Important clarification:
This issue is not present in official Sultan releases.
It is mostly seen in some KSU forks and custom repacks using different AnyKernel behavior.
Examples:
WildKSU Sultan uses AnyKernel base 20241217
Official Sultan zip uses 20231020
So please be careful with third-party AnyKernel-based kernel installers.
If this problem continues after final OrangeFox polishing, I will add a forced compatibility patch layer for AnyKernel zip installs on our side to protect end users.
Please report this to affected fork maintainers so they fix their installer scripts.
About broken boot (bootloop) after flashing fork sultan kernel
The issue is not OrangeFox.
What is happening:
AnyKernel rebuilds boot first.
Then it rebuilds vendor_kernel_boot.
Some forked installers forget to remove the kernel image after step 1, so AnyKernel picks it up again for vendor_kernel_boot.
As a result, vendor_kernel_boot gets packed with kernel + dtb + ramdisk when it should not, and the image can become invalid.
Why OrangeFox is not the cause:
OrangeFox is only running the installer script. The failure comes from installer logic and packing behavior in that AnyKernel flow, not from recovery itself.
Now that OrangeFox on our devices is fully functional (including decryption), this bug will become visible to more users.
Why it can look random:
Sometimes flashing may appear to succeed if there is enough space in vendor_kernel_boot for kernel + dtb + ramdisk.
That does not mean the installer is correct; it just means the overflow/format issue did not trigger in that specific case.
Practical fix between boot and vendor_kernel_boot steps:
rm -f "$AKHOME/Image.lz4"
or
rm -f "$home/Image.lz4"
boot image installation
block=boot;
is_slot_device=1;
. tools/ak3-core.sh;
split_boot;
flash_boot;
rm -f "$AKHOME/Image.lz4"; # <- add to remove kernel
rm -f "$home/Image.lz4" # <- add to remove kernel
vendor_kernel_boot installation (for dtb)
block=vendor_kernel_boot;
is_slot_device=1;
reset_ak;
split_boot;
flash_boot;
Important clarification:
This issue is not present in official Sultan releases.
It is mostly seen in some KSU forks and custom repacks using different AnyKernel behavior.
Examples:
WildKSU Sultan uses AnyKernel base 20241217
Official Sultan zip uses 20231020
So please be careful with third-party AnyKernel-based kernel installers.
If this problem continues after final OrangeFox polishing, I will add a forced compatibility patch layer for AnyKernel zip installs on our side to protect end users.
Please report this to affected fork maintainers so they fix their installer scripts.