Invalid boot.img, no ramdisk or kernel found on Xiaomi 14 Android 14

[a447948814]

小米14手机，安卓14，alpha18打开就提示：
Invalid boot.img, no ramdisk orkernel found

[a447948814]

使用网友二次修改的版本可以正常工作，我可以提供给你检查一下：https://taichi.lanzoum.com/inY1C0sxe09a
我希望最新版本可以修复这个问题

[capntrips]

The second revised version of the netizen can work normally, and I can provide it for you to check

I'm guessing something was lost in translation there. As noted in #15, dumps of the relevant partitions would be helpful.

Also the link didn't work for me, though at a glance it just appears to be the app's APK.

I can cooperate with you to solve this problem, but I don't quite understand how to give you the dump file

From here, if you want some additional context:

adb shell
su
cd /data/local/tmp
dd if=/dev/block/by-name/boot_a of=boot_a.img
dd if=/dev/block/by-name/boot_b of=boot_b.img
dd if=/dev/block/by-name/init_boot_a of=init_boot_a.img
dd if=/dev/block/by-name/init_boot_b of=init_boot_b.img
exit
exit
adb pull /data/local/tmp/boot_a.img
adb pull /data/local/tmp/boot_b.img
adb pull /data/local/tmp/init_boot_a.img
adb pull /data/local/tmp/init_boot_b.img

[a447948814]

1、那个apk是中国的技术爱好者基于您的官方版本alpha13作出的修改。
2、看了你的adb代码，您是希望我把boot.img和init_boot.img提供给你吗？是官方系统的原版boot还是我修补后刷入手机的boot？
3、我再次尝试用小米11安卓13安装了您的alpha18软件（他的root使用的是magis26.4+修补boot.img的方式），显示如下（似乎没有识别出已装载的卡槽）

[capntrips]

After reading your adb code, do you want me to provide you with boot.img and init_boot.img？

If you have 4 files, I really only need the init_boot ones, but I need both of them (a and b).

Is it the original boot of the official system or the boot I brushed into my phone after repairing？

I have no way of knowing what you currently have installed on your device. You'll have to tell me.

I assume you made the dumps on the Xiaomi 14 Android 14 and you're still experiencing the issue with Kernel Flasher?

I tried again to install your alpha18 software （ with Xiaomi 11 Android 13. His root used magis26.4+ to repair boot.img ）, showing the following （ does not seem to recognize the loaded Card slot ）

I'm not seeing any obvious issues in your screenshot. Can you elaborate on the issue you're experiencing?

P.S. It would be helpful to me if you would go ahead and translate your responses to English. As-is, if I don't directly quote the translations of your messages in their entirety, I'll have to retranslate them any time I need to go back to review something.

[a447948814]

I will provide you with three files, please keep an eye on their file names.

xiaomi14pro-hyperOS23.11.13.zip

[capntrips]

I'm able to run Kernel Flasher with the official and repair images you provided. To confirm, both of those images are currently flashed on the device, and one is init_boot_a and the other is init_boot_b?

Edit: To potentially save a little back and forth, what I suspect is the device is brand new and the second slot is still completely blank (see here for an example). If that is the case, a simple workaround would be to sideload an OTA to populate the second slot. Alternatively, you can use the test build linked in that post, which will allow Kernel Flasher to run with a bad slot.

[a447948814]

My current problem is that when I open the software, it displays an error and I am unable to proceed with subsequent operations. I am unable to scan the AK3 package.The software is unable to display the normal functional main interface.

[capntrips]

The error is due to being unable to read or process one or both of init_boot_a or init_boot_b. Here and here I asked for dumps of those partitions from your device.

I ran a test with the two init_boot files you provided me, and Kernel Flasher was able to process both the files you provided me. Here I asked you to verify that the two files you provided me are the current init_boot_a or init_boot_b on your device. Is this the case? If not, can you provide me with those two dumps?

[a447948814]

The error is due to being unable to read or process one or both of init_boot_a or init_boot_b. Here and here I asked for dumps of those partitions from your device.

I ran a test with the two init_boot files you provided me, and Kernel Flasher was able to process both the files you provided me. Here I asked you to verify that the two files you provided me are the current init_boot_a or init_boot_b on your device. Is this the case? If not, can you provide me with those two dumps?

The file I provided you is the one I am currently using on my phone. I cannot provide both - A and - B files because there is only one file, either in slot A or slot B. In short, alpha18 cannot read the initboot file in slot A or slot B that I am using. I don't know why.

[a447948814]

I conducted tests and found that：

alpha18-alpha15 ❌ Both prompt for errors
alpha14-alpha13 ✅ Can be used normally

Earlier versions did not test them。

[a447948814]

I will now provide you with the file: boot_ a.img (and attach a screenshot of my interface using alpha14)

boot_a.zip

[capntrips]

I cannot provide both - A and - B files because there is only one file, either in slot A or slot B.

You can retrieve init_boot_a and init_boot_b using adb, as I noted previously:

adb shell
su
dd if=/dev/block/by-name/init_boot_a of=/data/local/tmp/init_boot_a.img
dd if=/dev/block/by-name/init_boot_b of=/data/local/tmp/init_boot_b.img
exit
exit
adb pull /data/local/tmp/init_boot_a.img
adb pull /data/local/tmp/init_boot_b.img

I cannot debug this issue without those dumps.

I conducted tests and found that：

alpha18-alpha15 ❌ Both prompt for errors
alpha14-alpha13 ✅ Can be used normally

There was a bug in alpha13 and alpha14 that erroneously checked the active slot rather than the inactive one.

[a447948814]

I cannot debug this issue without those dumps.

Once again, would you like boot_a.img and boot_b.img, or init_boot_a.img and init_boot_b.img?

There was a bug in alpha13 and alpha14 that erroneously checked the active slot rather than the inactive one.

However, alpha13 and alpha14 do indeed work properly on my device.

[capntrips]

init_boot_a and init_boot_b

[a447948814]

init_boot_a and init_boot_b

ok，I am doing，but，I am currently using “kernel su”, which seems to work through boot. img. I thought I wanted to provide you with boot. img，Please wait a moment

[a447948814]

What should I do? It seems that adb is unable to obtain su permission，I am using the root mode of kernel su，
Can I directly extract init_boot.img from the system ROM package?

[capntrips]

What should I do? It seems that adb is unable to obtain su permission，I am using the root mode of kernel su

shennong:/ $ su
/system/bin/sh: su: inaccessible or not found

I don't know anything about KernelSU. From this it seems that it should normally be possible.

[a447948814]

What should I do? It seems that adb is unable to obtain su permission，I am using the root mode of kernel su

shennong:/ $ su
/system/bin/sh: su: inaccessible or not found

I don't know anything about KernelSU. From this it seems that it should normally be possible.

https://kernelsu.org/
Can I directly extract init_boot.img from the ROM package?

[capntrips]

Can I directly extract init_boot.img from the ROM package?

No. The point is that issue is specific to your device. I assume the init_boot images from the zip you previously provided would have uncovered any issues with the image from the ROM package anyway.

I'll repeat my note from above, just in case that can resolve your issue without further debugging:

What I suspect is the device is new and the second slot is still completely blank (see here for an example). If that is the case, a simple workaround would be to sideload an OTA to populate the second slot. Alternatively, you can use the test build linked in that post, which will allow Kernel Flasher to run with a bad slot.

Alternatively, you may be able to dump the init_boot images from each slot with alpha13 or alpha14, but I'm not positive that it will dump the correct image for the inactive slot.

[tiann]

This commit may be helpful: d1623fe

The mod version source is here: main...tiann:KernelFlasher:main

[a447948814]

Can I directly extract init_boot.img from the ROM package?

No. The point is that issue is specific to your device. I assume the init_boot images from the zip you previously provided would have uncovered any issues with the image from the ROM package anyway.

I'll repeat my note from above, just in case that can resolve your issue without further debugging:

What I suspect is the device is new and the second slot is still completely blank (see here for an example). If that is the case, a simple workaround would be to sideload an OTA to populate the second slot. Alternatively, you can use the test build linked in that post, which will allow Kernel Flasher to run with a bad slot.

Alternatively, you may be able to dump the init_boot images from each slot with alpha13 or alpha14, but I'm not positive that it will dump the correct image for the inactive slot.

(I have resolved the permission issue by manually granting the shell program root permission on my phone.)
The following are the init_boot_a and init_boot_b files that I exported using the adb command according to your requirements.
adb to init_boot_A and init_boot_B.zip
(By the way, you can take a look at what Tinann said：#16 (comment), which may be helpful to you，It's a coincidence because he's the Chinese developer I mentioned who modified KernelFlasher to work properly，He is also the author of KernelSU)

[capntrips]

As was the case here init_boot_b is empty. This must be a new device. If you flash a build of your OS to slot B, it should resolve your issue. I'm going to close this issue, but if it persists after you install the OS to slot B, feel free to reopen.

P.S. I'm almost certainly going to have to rework the initialization code of the app at some point, but it won't be in the next few days.

[a447948814]

As was the case here init_boot_b is empty. This must be a new device. If you flash a build of your OS to slot B, it should resolve your issue. I'm going to close this issue, but if it persists after you install the OS to slot B, feel free to reopen.

P.S. I'm almost certainly going to have to rework the initialization code of the app at some point, but it won't be in the next few days.

thankyou，I have updated the OS to another slot B, and before restarting my phone, I need to also flash the AK3 zip file into another slot B. However, according to my recollection, this issue seems to still exist because at this point, slot A becomes empty for your application. It seems that it can only recognize the current card slot in the OS and will never be able to recognize another card slot.（I'm not very sure, let me observe again）This may help you：#16 (comment)

[capntrips]

Flashing to the inactive slot was removed in alpha03. I don't immediately recall what prompted that change, but if it is to be readded at some point in the future, it will be with AK3 functions, rather than resetprop. Both of the changes in that comment were discussed in #11, if you want to review the logic behind why they weren't implemented as-is. If you need that capability in the immediate future, I imagine it is implemented in the build in that fork.

[a447948814]

I am not a technician, I can only provide you with some feedback as much as possible. But I am certain that flashing into an inactive card slot is a very necessary feature, because for A/B devices, whether using a Mask or KSU to obtain root permission, after updating the OS to another card slot and before restarting the device, both the mask and ksu need to be flashed into another card slot before restarting the device. Therefore, we look forward to your ability to address the issues discussed in this discussion in future versions. Thank you!

[a447948814]

I am not a technician, I can only provide you with some feedback as much as possible. But I am certain that flashing into an inactive card slot is a very necessary feature, because for A/B devices, whether using a Mask or KSU to obtain root permission, after updating the OS to another card slot and before restarting the device, both the mask and ksu need to be flashed into another card slot before restarting the device. Therefore, we look forward to your ability to address the issues discussed in this discussion in future versions. Thank you!

It has been confirmed that when updating the system, the OS was installed in the B card slot, while the AK3 was flushed into the B card slot. After restarting the phone, this issue still exists when installing Alpha18.