Related
Anyone ever attempted to kang Keymaster Firmware from a different device? I have tried the firmware from bacon, hammerhead, and g3. I have tried with and without the TARGET_KEYMASTER_WAIT_FOR_QSEE flag.
See these commits:
https://github.com/blastagator/cm_d...mmit/a50026b03824e65e852dc975e369f89a6e8e33a6
https://github.com/blastagator/them...mmit/b5951a58a4df5cabc8f928fae2476629cc73b1fa
https://github.com/blastagator/LGG2_Kernel/commit/655b64e43cbcd4550671cadf8bc19b6c495b3190
The result is always the same in dmesg:
Code:
[0][4371: keystore]QSEECOM: qseecom_load_app: App (keymaster) does'nt exist, loading apps for first time
[0][4371: keystore]QSEECOM: qseecom_load_app: scm_call failed resp.result unknown, -12
[0][4371: keystore]QSEECOM: qseecom_ioctl: failed load_app request: -14
This is the only related thing I've found:
http://androidforums.com/threads/beta-4-4-2-stock-kitkat.952314/
Very old and no answer.
I suspect the firmware might be signed to the device type and thus we might be SOL, but I was bored and messing around. Alternatively, perhaps the kernel is missing something. I looked for commits that may be missing from qseecom.c and smc.c, but nothing jumped out at me.
Figured I'd post a dev thread and maybe we can find an answer.
edit: This is my cheat sheet to myself, so far, for how to add hardware crypto to a device:
Code:
Needed commits:
Probable problem: G2 has no keymaster firmware, need to borrow someone else's
See this commit:
https://github.com/blastagator/themuppets_proprietary_vendor_lge/commit/b5951a58a4df5cabc8f928fae2476629cc73b1fa
g2-common/g2-common-vendor-blobs.mk
+ vendor/lge/g2-common/proprietary/vendor/firmware/keymaster/keymaster.b00:system/vendor/firmware/keymaster/keymaster.b00 \
+ vendor/lge/g2-common/proprietary/vendor/firmware/keymaster/keymaster.b01:system/vendor/firmware/keymaster/keymaster.b01 \
+ vendor/lge/g2-common/proprietary/vendor/firmware/keymaster/keymaster.b02:system/vendor/firmware/keymaster/keymaster.b02 \
+ vendor/lge/g2-common/proprietary/vendor/firmware/keymaster/keymaster.b03:system/vendor/firmware/keymaster/keymaster.b03 \
+ vendor/lge/g2-common/proprietary/vendor/firmware/keymaster/keymaster.mdt:system/vendor/firmware/keymaster/keymaster.mdt \
And, actually put the files in that folder, so they get copied.
CRUCIAL: MUST match this name and path!!! (Other things like keymaste.mdt and such are for if the files are in the modem)
Also, symlinks are NOT needed if we put the file into proprietary like this!
Device commit:
https://github.com/blastagator/cm_device_lge_g2-common/commit/a50026b03824e65e852dc975e369f89a6e8e33a6
BoardConfig
+# Encryption / Keymaster
+TARGET_HW_DISK_ENCRYPTION := true
+TARGET_KEYMASTER_WAIT_FOR_QSEE := true
+
NOTE: Not sure about wait_for_qsee --- MAYBE needed????
g2.mk
+# Keystore
+PRODUCT_PACKAGES += \
+ keystore.msm8974
+
Note: The resulting /system image will have TWO keystore files, this is correct
I checked a bacon image to confirm there are supposed to be two. One labeled msm8974 & one labeled default
Probable needed kernel changes:
Config
-# CONFIG_DM_REQ_CRYPT is not set
+CONFIG_DM_REQ_CRYPT=y
-# CONFIG_CRYPTO_DEV_QCRYPTO is not set
+CONFIG_CRYPTO_DEV_QCRYPTO=y
If dm-req-crypt.c doesn't build, need this commit:
https://github.com/blastagator/LGG2_Kernel/commit/50ddb1a013065cefa35151e9ded72aadcd210611
(platform: msm: Fix compile when CONFIG_PFT is not set)
include/linux/pft.h
-static inline int pft_get_key_index(struct inode *inode, u32 *key_index,
+static inline int pft_get_key_index(struct bio *bio, u32 *key_index,
blastagator said:
Anyone ever attempted to kang Keymaster Firmware from a different device?
Click to expand...
Click to collapse
Maybe, you have to add something like this:
https://github.com/CyanogenMod/andr...mmit/595cf776441389d147f4b4e7ec316aa02d74d14e
Rangell11 said:
Maybe, you have to add something like this:
https://github.com/CyanogenMod/andr...mmit/595cf776441389d147f4b4e7ec316aa02d74d14e
Click to expand...
Click to collapse
That is for if the firmware is in the /modem partition. I know it's finding the firmware because if I remove the files the error messages go away and the keystore service crashes without a specific error.
I've also insured permissions 0644 on the files and I've put selinux in permissive to see if that would help, but same errors.
blastagator said:
I've also insured permissions 0644 on the files and I've put selinux in permissive to see if that would help, but same errors.
Click to expand...
Click to collapse
Like this??
http://review.cyanogenmod.org/#/c/155981/
Did you try this?
http://review.cyanogenmod.org/#/c/137146/
PS:
I think our G2 not support TARGET_KEYMASTER_WAIT_FOR_QSEE flag.
http://review.cyanogenmod.org/#/c/102410/
Rangell11 said:
Like this??
http://review.cyanogenmod.org/#/c/155981/
Click to expand...
Click to collapse
After clean boot I used "setenforce 0" to see if it would load after that. (keystore service keeps repeatedly attempting to load in the background and can be seen with 'dmesg'.) Disabling enforcing should have solved any selinux problem, but the same error persisted.
Rangell11 said:
Did you try this?
http://review.cyanogenmod.org/#/c/137146/
Click to expand...
Click to collapse
Keymaster is in the system partition and not the modem partition (for my tests anyway), so this wouldn't be needed. I will say the contact was not 'context=ubject_r:firmware_file:s0', it was listed as a regular system file, however, in permissive mode this should not matter. Maybe I will try another test when I have some time where the ROM is compiled permissive and the files have the correct context.
I don't think it is this issue though, as the keymaster firmware is found and qseecomd is attempting to load it.
Rangell11 said:
PS:
I think our G2 not support TARGET_KEYMASTER_WAIT_FOR_QSEE flag.
http://review.cyanogenmod.org/#/c/102410/
Click to expand...
Click to collapse
Thanks. I did some testing and tried both, no luck with either.
Looks like there are at least a couple updates to scm that I could try:
https://github.com/dorimanx/DORIMANX_LG_STOCK_LP_KERNEL/commits/master/arch/arm/mach-msm/scm.c
https://github.com/dorimanx/DORIMANX_LG_STOCK_LP_KERNEL/commits/master/drivers/misc/qseecom.c
Will try updating kernel when I have some free time.
edit: Pulled in a bunch of kernel changes and compiled the boot image to be permissive:
https://github.com/blastagator/LGG2_Kernel/commits/cm-13.0
Still the same error codes.
Code:
[ 0.480347 / 01-01 00:00:00.473] QSEECOM: qseecom_probe: support_bus_scaling=0x1
[ 0.480356 / 01-01 00:00:00.473] QSEECOM: qseecom_probe: disk-encrypt-pipe-pair=0x2
[ 0.480365 / 01-01 00:00:00.473] QSEECOM: qseecom_probe: file-encrypt-pipe-pair=0x0
[ 0.480374 / 01-01 00:00:00.473] QSEECOM: qseecom_probe: qsee-ce-hw-instance=0x0
[ 0.480382 / 01-01 00:00:00.473] QSEECOM: qseecom_probe: qseecom.appsbl_qseecom_support = 0x0
[ 0.480421 / 01-01 00:00:00.473] QSEECOM: qseecom_probe: secure app region addr=0x7b00000 size=0x500000
[ 3.174366 / 01-13 05:47:06.160] init: Starting service 'qseecomd'...
[ 3.207945 / 01-13 05:47:06.193] init: Starting service 'keystore'...
[ 3.221661 / 01-13 05:47:06.206] warning: `qseecomd' uses 32-bit capabilities (legacy support in use)
[ 3.476387 / 01-01 05:47:06.146] QSEECOM: qseecom_load_app: App (keymaster) does'nt exist, loading apps for first time
[ 3.476494 / 01-01 05:47:06.146] QSEECOM: qseecom_load_app: scm_call failed resp.result unknown, -12
[ 3.476511 / 01-01 05:47:06.146] QSEECOM: qseecom_ioctl: failed load_app request: -14
[ 3.477964 / 01-01 05:47:06.146] init: Service 'keystore' (pid 275) exited with status 1
[ 3.477985 / 01-01 05:47:06.146] init: Service 'keystore' (pid 275) killing any children in process group
The last 5 lines just repeat indefinitely.
.
blastagator said:
After clean boot I used "setenforce 0" to see if it would load after that. (keystore service keeps repeatedly attempting to load in the background and can be seen with 'dmesg'.) Disabling enforcing should have solved any selinux problem, but the same error persisted.
Click to expand...
Click to collapse
Do you know why they did not use this change for our G2?
http://review.cyanogenmod.org/#/c/89419/
http://review.cyanogenmod.org/#/c/89418/
Rangell11 said:
Do you know why they did not use this change for our G2?
http://review.cyanogenmod.org/#/c/89419/
http://review.cyanogenmod.org/#/c/89418/
Click to expand...
Click to collapse
qcrypto is currently disabled, so there wouldn't be a need to apply similar patches to the current kernel, unless HW encryption were figured out.
I added those two commits, but I doubt this is the issue.
@blastagator
I've pushed my keymaster to Github: https://github.com/GalaticStryder/hardware_qcom_keymaster
This is the one we use on bacon and onyx on AOSPA builds.
Backporting 3.10 qseecom isn't needed and probably will break the APIs the blobs were compiled for. I'm gonna test this on nougat as well right now.
I'd actually ask for your help on AOSPA, I've got a semi-working RIL and some other great stuff to play with but I can't get the built-in kernel to boot after flashing, only boots when flashing my kernel externally.
The image is bumped, the mkbootimg was revisited twice but there's no go. I don't want to ship a prebuilt image to workaround this. I've tried CM14 kernel with my GCC 4.9 patches for androidkernel- toolchain and Lambda as well.
GalaticStryder said:
@blastagator
I've pushed my keymaster to Github: https://github.com/GalaticStryder/hardware_qcom_keymaster
This is the one we use on bacon and onyx on AOSPA builds.
Backporting 3.10 qseecom isn't needed and probably will break the APIs the blobs were compiled for. I'm gonna test this on nougat as well right now.
I'd actually ask for your help on AOSPA, I've got a semi-working RIL and some other great stuff to play with but I can't get the built-in kernel to boot after flashing, only boots when flashing my kernel externally.
The image is bumped, the mkbootimg was revisited twice but there's no go. I don't want to ship a prebuilt image to workaround this. I've tried CM14 kernel with my GCC 4.9 patches for androidkernel- toolchain and Lambda as well.
Click to expand...
Click to collapse
Without going too far OT, do you have a thread for the AOSPA you're working on? Curious what manifest you're using.
re: keymaster - I pulled the blobs from Bacon and it looks like the cm-13 nightlies use the latest hardware_qcom_keymaster. I don't think there have really been any big changes to the API. I could be wrong though!
blastagator said:
Without going too far OT, do you have a thread for the AOSPA you're working on? Curious what manifest you're using.
re: keymaster - I pulled the blobs from Bacon and it looks like the cm-13 nightlies use the latest hardware_qcom_keymaster. I don't think there have really been any big changes to the API. I could be wrong though!
Click to expand...
Click to collapse
I'm making progress using everything from CAF and patching the needed parts on demand.
The stuff AOSPA already has in their Github I'm sending to Gerrit: https://gerrit.aospa.co/#/q/status:open
The parts I needed to dive deeper I've forked or created the repos manually: https://github.com/GalaticStryder
My next step is to "decommonize" the power package to be able to hint impulse instead of ondemand and to update MSM8974 code that is two years old.
The only problem I'm facing is that the otapackage seems to flash the boot.img in a bad manner, causing boot certification problem. If I manually flash the boot.img after the otapackage it works like a charm, the problem is somewhere in the boot flashing script part of the ota_from_target_files python script, might be pushing the boot.img using imgdiff and causing the bootloader to refuse due to mismatching certification inside the boot sector. This is my hypothesis but it might be what is happening.
GalaticStryder said:
I'm making progress using everything from CAF and patching the needed parts on demand.
The stuff AOSPA already has in their Github I'm sending to Gerrit: https://gerrit.aospa.co/#/q/status:open
The parts I needed to dive deeper I've forked or created the repos manually: https://github.com/GalaticStryder
My next step is to "decommonize" the power package to be able to hint impulse instead of ondemand and to update MSM8974 code that is two years old.
The only problem I'm facing is that the otapackage seems to flash the boot.img in a bad manner, causing boot certification problem. If I manually flash the boot.img after the otapackage it works like a charm, the problem is somewhere in the boot flashing script part of the ota_from_target_files python script, might be pushing the boot.img using imgdiff and causing the bootloader to refuse due to mismatching certification inside the boot sector. This is my hypothesis but it might be what is happening.
Click to expand...
Click to collapse
Well beyond the scope of my dive into android fun. Wish I could help! What is your ultimate goal? Paranoid Android?
It is also very exciting to see the push of Android stuff into the mainline kernel. Hope for the future!
Realized additional blobs for qseecom:
https://github.com/blastagator/them...mmit/09bc989cdb0db9bc47f7501dbf36be2a155ca168
Also, updated boardconfig since the bacon qseecomd supports TARGET_KEYMASTER_WAIT_FOR_QSEE
https://github.com/blastagator/cm_d...mmit/6ca7cd8835afa57ebec9b47fc56514d87ee95e34
Building now. Not sure if I can test tonight, but fingers crossed, maybe it will work!
No luck. Still the same errors:
Code:
12-31 23:22:39.385 2697 2697 I keystore: Found keymaster0 module Keymaster QCOM HAL, version 3
12-31 23:22:39.385 2697 2697 I SoftKeymaster: system/keymaster/soft_keymaster_device.cpp, Line 122: Creating device
12-31 23:22:39.385 2697 2697 D SoftKeymaster: system/keymaster/soft_keymaster_device.cpp, Line 123: Device address: 0xb6b64000
12-31 23:22:39.386 2697 2697 D QCOMKeyMaster: keymaster app is loaded
12-31 23:22:39.386 2697 2697 D QCOMKeyMaster: keymaster app got loaded at attempt number 0
12-31 23:22:39.386 2697 2697 D QSEECOMAPI: : QSEECom_get_handle sb_length = 0x2000
12-31 23:22:39.386 2697 2697 D QSEECOMAPI: : App is not loaded in QSEE
12-31 23:22:39.392 2697 2697 E QSEECOMAPI: : Error::Load image request failed ret = -1, errno = 14
12-31 23:22:39.392 2697 2697 E QSEECOMAPI: : Error::Loading image failed with ret = -1
12-31 23:22:39.393 2697 2697 D QSEECOMAPI: : QSEECom_get_handle sb_length = 0x2000
12-31 23:22:39.393 2697 2697 D QSEECOMAPI: : App is not loaded in QSEE
12-31 23:22:39.393 2697 2697 E QSEECOMAPI: : Error::Cannot open the file /firmware/image/keymaste.mdt
12-31 23:22:39.393 2697 2697 E QSEECOMAPI: : Error::Loading image failed with ret = -1
12-31 23:22:39.393 2697 2697 E QCOMKeyMaster: Loading keymaster app failed
12-31 23:22:39.393 2697 2697 E keystore: Error opening keystore keymaster0 device.
12-31 23:22:39.393 2697 2697 E keystore: keystore keymaster could not be initialized; exiting
Guessing there is some sort of signature check that is matching the expected device to the keymaster firmware file. Unfortunately qseecomapi and keymaster are closed source, so it is kind of a guessing game...
Code:
/**
* @brief Open a handle to the QSEECom device.
*
* - Load a secure application. The application will be verified that it is
* secure by digital signature verification.
* Allocate memory for sending requests to the QSAPP
*
* Note/Comments:
* There is a one-to-one relation for a HLOS client and a QSAPP;
* meaning that only one app can communicate to a QSAPP at a time.
*
* Please note that there is difference between an application and a listener
* service. A QSAPP must be loaded at the request of the HLOS,
* and all requests are orginated by the HLOS client.
* A listener service on the otherhand is started during start-up by a
* daemon, qseecomd.
*
* A HLOS application may create mutiple handles to the QSAPP
*
* @param[in/out] handle The device handle
* @param[in] fname The directory and filename to load.
* @param[in] sb_size Size of the shared buffer memory for sending requests.
* @return Zero on success, negative on failure. errno will be set on
* error.
*/
int QSEECom_start_app(struct QSEECom_handle **clnt_handle, const char *path,
const char *fname, uint32_t sb_size);
Perhaps something in one of the .prop files could be changed to trick the app into passing a device check, but again, this is all very speculative.
blastagator said:
Anyone ever attempted to kang Keymaster Firmware from a different device? I have tried the firmware from bacon, hammerhead, and g3. I have tried with and without the TARGET_KEYMASTER_WAIT_FOR_QSEE flag.
The result is always the same in dmesg:
Code:
[0][4371: keystore]QSEECOM: qseecom_load_app: App (keymaster) does'nt exist, loading apps for first time
[0][4371: keystore]QSEECOM: qseecom_load_app: scm_call failed resp.result unknown, -12
[0][4371: keystore]QSEECOM: qseecom_ioctl: failed load_app request: -14
Click to expand...
Click to collapse
Hello @blastagator,
were you able to fix that Keymaster Issue , if so mind telling us how ?
Because , iam facing similar issues in YU4711 (jalebi)
sooorajjj said:
Hello @blastagator,
were you able to fix that Keymaster Issue , if so mind telling us how ?
Because , iam facing similar issues in YU4711 (jalebi)
Click to expand...
Click to collapse
No. Tried several things with no luck.
What is a keymaster firmware?
And what is it good for?
wq0913562 said:
What is a keymaster firmware?
And what is it good for?
Click to expand...
Click to collapse
Maybe this config is need for porting firmware from different devices.
wq0913562 said:
What is a keymaster firmware?
And what is it good for?
Click to expand...
Click to collapse
cryerenable said:
Maybe this config is need for porting firmware from different devices.
Click to expand...
Click to collapse
No, it is used to enable hardware backed keystore (i.e. hardware accelerated encryption)
blastagator said:
No, it is used to enable hardware backed keystore (i.e. hardware accelerated encryption)
Click to expand...
Click to collapse
hello
i'm facing a similar problem on my lineage 13 port for the lg stylo 2 plus the qseecomapi is keeping looking for the keymaste.mdt file
E QSEECOMAPI: Error::Cannot open the file /firmware/image/keymaste.mdt errno = 2
E QSEECOMAPI: Error::Loading image failed with ret = -1
Click to expand...
Click to collapse
and our device does not have one do you know how to bybass this, ty.
messi2050 said:
hello
i'm facing a similar problem on my lineage 13 port for the lg stylo 2 plus the qseecomapi is keeping looking for the keymaste.mdt file
and our device does not have one do you know how to bybass this, ty.
Click to expand...
Click to collapse
I got frustrated with it. Only other idea I had was to port all common blobs from similar device and see if that works.
blastagator said:
I got frustrated with it. Only other idea I had was to port all common blobs from similar device and see if that works.
Click to expand...
Click to collapse
Are you still active?
Just found this. Not sure if it can help.
http://bits-please.blogspot.de/2016/06/extracting-qualcomms-keymaster-keys.html
https://android.googlesource.com/platform/hardware/qcom/keymaster/+/master
Maybe I'll give it a try to port keymaster now that we have updated 3.4.113 kernel...
I get this error message:
Error applying update: 20 (ErrorCode::kDownloadStateInitializationError)
Any ideas?
7cherubin said:
I get this error message:
Error applying update: 20 (ErrorCode::kDownloadStateInitializationError)
Any ideas?
Click to expand...
Click to collapse
root and or twrp installed?
2WildFirE said:
root and or twrp installed?
Click to expand...
Click to collapse
Nope.
Never flashed TWRP.
However, I did have root. But I uninstalled it and performed a hard reset.
After that, I also locked the bootloader.
Then try flash matching boot.img after that update again.
? Bootloader isn't needed I update every month with open bootloader
7cherubin said:
I get this error message:
Error applying update: 20 (ErrorCode::kDownloadStateInitializationError)
Any ideas?
Click to expand...
Click to collapse
+1 The same happens to me (stock boot flashed in slot b - september and a -august). No way to update.
Did you guys ever figure it out ? I'm having the exact same problem when trying to flash the November update from Stock Recovery (I tried that because normal OTA errors out). Thanks !
Hi @7cherubin would you send me the post to root TA-1012?
I have the same problem. TA-1004, trying to apply November security update.
After getting the "Installation problem" error message in the update UI, which is not very verbose, I checked the log with adb logcat. The following is what I have found:
Code:
update_engine: [1114/144758:INFO:delta_performer.cc(368)] Applying 8158 operations to partition "system"
update_engine: [1114/144758:ERROR:delta_performer.cc(1065)] The hash of the source data on disk for this operation doesn't match the expected value. This could mean that the delta update payload was targeted for another version, or that the source partition was modified after it was installed, for example, by mounting a filesystem.
The phone's bootloader was unlocked using the official method.
TWRP has been installed, then removed (by flashing the stock boot image to both slots A and B).
The update seems to fail with or without TWRP.
Also, Magisk has been installed, then removed. Same result: update fails with or without Magisk.
Judging by the error message from the log, the problem is somehow related to the system partition and not the boot partition (where the boot image resides, and which would be affected by TWRP and/or Magisk).
The Nokia 8 doesn't seem to have a separate recovery partition, the recovery image is stored also on the boot partition (proof for this being that if you flash stock boot image, you get back the stock recovery).
Temporarily booting an image with fastboot boot <img> also doesn't work on this phone (at least if you are already on 8.1.0 with October security patch), so installing TWRP is only possible by flashing it to one of the boot slots and forcing the phone to boot from that particular slot.
Neither OST 6.0.4 nor OST 6.1.2 is able to flash the phone.
Sorry if this got too long, I am trying to stick in this post all the info that I have learned in the hopes that someone will have an idea how to fix this.
I had the same problem and had to go back to stock. I had only rooted and flashed the boot images, no TWRP. I had messed up at one point though and flashed both slots and that's where I think the problem lies. The boot images seem to be personalized to the device (keys ?) and the OTA checks for that so if you flash one with a prerooted image, then apply Magisk to the other one and ugrade on that one (after temporarily deactivating Magisk) then you're ok. After going back to stock I was able to verify this "theory", well at least it let me do the OTA multiple times.
Can someone post the link yo root TA-1012 ^_^
webvan said:
I had the same problem and had to go back to stock. I had only rooted and flashed the boot images, no TWRP. I had messed up at one point though and flashed both slots and that's where I think the problem lies. The boot images seem to be personalized to the device (keys ?) and the OTA checks for that so if you flash one with a prerooted image, then apply Magisk to the other one and ugrade on that one (after temporarily deactivating Magisk) then you're ok. After going back to stock I was able to verify this "theory", well at least it let me do the OTA multiple times.
Click to expand...
Click to collapse
Here is what I have, Nokia 8 TA-1004:
- on slot A I have Android 8.1.0 with October security patch
- on slot B I have Android 8.1.0 with September security patch
Neither of these would apply the OTA (slot A November patch, slot B October patch).
I got rid of previous root attempts by flashing:
- stock October boot image to slot A
- stock September boot image to slot B
At this point I am back to as stock as possible.
Then I tried to follow your suggestions, flashed:
- prerooted October boot image to slot A
- stock September boot image to slot B
Set the active slot to A.
Reboot.
Install Magisk from MagiskManager to the "other slot", this switches the active slot to B.
Reboot.
Check that Magisk is installed: yes. Check root with RootChecker: there is root.
Uninstall Magisk from MagiskManager with the Restore Images option, this should restore the stock boot image on the active slot, which at this point is B.
Without reboot, try to apply the OTA update to upgrade to November security patch.
Update fails. Here are a few relevant lines from the log (retrieved with adb logcat):
Code:
11-27 16:56:59.961 1107 1107 I update_engine: [1127/165659:INFO:delta_performer.cc(368)] Applying 5 operations to partition "abl"
11-27 16:56:59.965 1107 1107 I update_engine: [1127/165659:INFO:delta_performer.cc(661)] Starting to apply update payload operations
11-27 16:56:59.970 1107 1107 E update_engine: [1127/165659:ERROR:delta_performer.cc(1065)] The hash of the source data on disk for this operation doesn't match the expected value. This could mean that
the delta update payload was targeted for another version, or that the source partition was modified after it was installed, for example, by mounting a filesystem.
11-27 16:56:59.970 1107 1107 E update_engine: [1127/165659:ERROR:delta_performer.cc(1070)] Expected: sha256|hex = 1376DA9AFC602B63352F6611917129A8FEC841070A5A44B657826B25D3BAED0D
11-27 16:56:59.970 1107 1107 E update_engine: [1127/165659:ERROR:delta_performer.cc(1073)] Calculated: sha256|hex = 658502232C3D562E1883E66BB2C4BED4F48E98CB02B983DC43DB6D9B05ABF939
11-27 16:56:59.970 1107 1107 E update_engine: [1127/165659:ERROR:delta_performer.cc(1084)] Operation source (offset:size) in blocks: 1:1,3:1,36:14,51:16
11-27 16:56:59.970 1107 1107 E update_engine: [1127/165659:ERROR:delta_performer.cc(1250)] ValidateSourceHash(source_hasher.raw_hash(), operation, error) failed.
11-27 16:56:59.970 1107 1107 E update_engine: [1127/165659:ERROR:delta_performer.cc(288)] Failed to perform SOURCE_BSDIFF operation 1, which is the operation 1 in partition "abl"
11-27 16:56:59.970 1107 1107 E update_engine: [1127/165659:ERROR:download_action.cc(325)] Error ErrorCode::kDownloadStateInitializationError (20) in DeltaPerformer's Write method when processing the received payload -- Terminating processing
Then I went back to stock boot images again, and tried the whole process the other way around: switching slots.
Stock image on slot A.
Prerooted image on slot B.
The rest of the process is the same as above.
This time I get a different error in the log:
Code:
11-27 17:07:30.788 1050 1050 I update_engine: [1127/170730:INFO:delta_performer.cc(368)] Applying 5 operations to partition "abl"
11-27 17:07:30.794 1050 1050 I update_engine: [1127/170730:INFO:delta_performer.cc(661)] Starting to apply update payload operations
11-27 17:07:30.834 1050 1050 I update_engine: [1127/170730:INFO:delta_performer.cc(368)] Applying 22 operations to partition "bluetooth"
11-27 17:07:30.841 1050 1050 E update_engine: [1127/170730:ERROR:delta_performer.cc(1065)] The hash of the source data on disk for this operation doesn't match the expected value. This could mean that
the delta update payload was targeted for another version, or that the source partition was modified after it was installed, for example, by mounting a filesystem.
11-27 17:07:30.841 1050 1050 E update_engine: [1127/170730:ERROR:delta_performer.cc(1070)] Expected: sha256|hex = 73D9DD6F7FCBA3C7A6900599BB66C5D321C9F77B74808FD1ADEB50DD8CE475D2
11-27 17:07:30.841 1050 1050 E update_engine: [1127/170730:ERROR:delta_performer.cc(1073)] Calculated: sha256|hex = BEFE956EC57F320FA6F96067CCDF81DEF88D227A15D7E5412B2064A941E8E7BF
11-27 17:07:30.841 1050 1050 E update_engine: [1127/170730:ERROR:delta_performer.cc(1084)] Operation source (offset:size) in blocks: 4:1,11:1
11-27 17:07:30.841 1050 1050 E update_engine: [1127/170730:ERROR:delta_performer.cc(1250)] ValidateSourceHash(source_hasher.raw_hash(), operation, error) failed.
11-27 17:07:30.841 1050 1050 E update_engine: [1127/170730:ERROR:delta_performer.cc(288)] Failed to perform SOURCE_BSDIFF operation 11, which is the operation 6 in partition "bluetooth"
11-27 17:07:30.841 1050 1050 E update_engine: [1127/170730:ERROR:download_action.cc(325)] Error ErrorCode::kDownloadStateInitializationError (20) in DeltaPerformer's Write method when processing the received payload -- Terminating processing
As you can see in the first case it is complaining about the "abl" partition, in the second case it is complaining about the "bluetooth" partition.
webvan, what is your phone model? Is it TA-1004? What security patch levels were you working with in your case?
Mine is a TA-1052.
By "go back to stock" I meant fully reflashing the Oreo update with OTLA because like you nothing I tried with the boot images helped. Since I was rooted I did a backup with Titanium so it wasn't too painful.
I managed to update to 5.15d by sideloading using adb the full ROM (5.15) then sideloading 5.15a and 5.15b, I didn't sideload 5.15c I directly sideloaded 5.15d OTA update and it worked!
I have the same problem.
Slot A : stock boot with sp 2019-04 (5150)
Slot B (active): stock boot with sp 2019-05 (515A)
I tried to sideload OTA (515B with sp 2019-06) on slot B, while the "Error applying update: 20 (ErrorCode::kDownloadStateInitializationError)" message appeared.
By checking the log report, it was just after the operations to partition "system" that I had the line "the hash of the source data on disk for this operation doesn't match the expected value."
Anyone has ideas? Thanks in advance.
I have a unlocked TA-1004, rooted with Magisk (running stock recovery). Today I got the notification for the January Security patch.
I restored the boot image with Magisk and proceeded to download and install the OTA, however I'm getting an "Couldn't update - Installation problem" error.
After that I tried reinstalling Magisk, rebooting the phone, restoring the boot image again and retrying the update, it still fails.
Any ideas on what to do? (I didn't want to use a custom recovery solely for keeping the ability to receive further OTA updates, now for whatever reason I can't :S)
TA-1004 here, stock, updated to PIE via beta leak, can't install the update too
yandoo said:
TA-1004 here, stock, updated to PIE via beta leak, can't install the update too
Click to expand...
Click to collapse
I sideloaded the full version (not the beta leak), makes no sense either way tho
I'm having the same issue with a TA1012. Quite fast after downloading the update an error message and "Installationsproblem" in red font.
any solution yet?
ILoveAndroid77 said:
I'm having the same issue with a TA1012. Quite fast after downloading the update an error message and "Installationsproblem" in red font.
any solution yet?
Click to expand...
Click to collapse
I have same issue on my Nokia 8 (TA-1004).
Is Anyone have solution for this?
ADB output shows
01-31 12:40:06.785 1128 1128 E update_engine: [0131/124006.785297:ERROR:delta_performer.cc(990)] The hash of the source data on disk for this operation doesn't match the expected value. This could mean that the delta update payload was targeted for another version, or that the source partition was modified after it was installed, for example, by mounting a filesystem.
01-31 12:40:06.785 1128 1128 E update_engine: [0131/124006.785480:ERROR:delta_performer.cc(995)] Expected: sha256|hex = 945B60FBC44A481C5F003C140ABBEC14F0CE2C8E142E9843BE83F67905453399
01-31 12:40:06.785 1128 1128 E update_engine: [0131/124006.785520:ERROR:delta_performer.cc(998)] Calculated: sha256|hex = CB0DA98B7D9BC6DF8B98A6323A3079588EA975088DBAB0461404E90809FC67F6
01-31 12:40:06.785 1128 1128 E update_engine: [0131/124006.785563:ERROR:delta_performer.cc(1009)] Operation source (offset:size) in blocks: 0:1,2140:877,3018:10099
01-31 12:40:06.785 1128 1128 E update_engine: [0131/124006.785628:ERROR:delta_performer.cc(1191)] ValidateSourceHash(source_hash, operation, source_fd_, error) failed.
01-31 12:40:06.785 1128 1128 E update_engine: [0131/124006.785670:ERROR:delta_performer.cc(298)] Failed to perform BROTLI_BSDIFF operation 27, which is the operation 0 in partition "boot"
01-31 12:40:06.785 1128 1128 E update_engine: [0131/124006.785711:ERROR:download_action.cc(337)] Error ErrorCode::kDownloadStateInitializationError (20) in DeltaPerformer's Write method when processing the received payload -- Terminating processing
Pie (installed via OTA) is on slot B.
On slot A should be the may oreo NB1-488B-0-00WW-B04.nb0. I went back to this with OST and I think the OTA update for pie is not intended to upgrade Oreo May.
Is there a full stock pie image that we could install via OST?
How about your other slot, what's installed there?
1- download this Firmware NB1-488B-0-00WW-B04.qlz Via this link https://bit.ly/2CZS4Z2
2- Flash via NOST https://github.com/StollD/NOST/releases
3- download and flash thes ota update via adb sideload https://bit.ly/2Rs4y0Y
Now you can install January security patch Without any problems
iyadengle said:
1- download this Firmware NB1-488B-0-00WW-B04.qlz Via this link https://bit.ly/2CZS4Z2
Click to expand...
Click to collapse
Does not work - following this link I receive a microsoft sharepoint login site of helmholtzschule. Don't have credentials.
But i think I did this some weeks ago. This should be the full may oreo rom?
iyadengle said:
3- download and flash thes ota update via adb sideload https://bit.ly/2Rs4y0Y
Click to expand...
Click to collapse
Whats this update?
What I did with my phone: install May oreao. after booting and setup it directly went to the pie update.
So i think i have first pie rom on slot B and may on slot A. And may oreo slot A can not be updated with a 76Mb OTA to pie.
If I follow your steps, shouldn't I have the same result as now?
Got a solution for me, described here: https://forum.xda-developers.com/showpost.php?p=78811216&postcount=4
Hi all,
Can anybody please share the twrp backup of bluetooth partition of Moto One Power device having the Pie January 1st Patch? My bluetooth partition got formatted while restoring the twrp backup and restore got failed. Now I'm not able to use the bluetooth. I have got the OTA with face unlock, But thile installing the OTA I started getting bluetooth partition block verification failed saying partition got mounted rw. And while restoring the earlier backup it got formatted :crying:
Got it fixed after a hell lot of research
Hi all,
Finally after searching a lot in net, flashed the bluetooth partition with the img file available in the following site ( Phenotypically ) -> mirrors[dot]lolinet[dot]com[slash]firmware[slash]moto[slash]chef[slash]official[slash]RETIN
The root cause for getting the partition formatted is gettiing the following error, to solve it I tried to restore bluetooth partition and it resulted currupt. Hope it may help somebody who will be get the same issue and stumble upon this page.
I was getting "Update Failed" error in Moto updator. While checking for the logs via adb observed the following error :
Code:
update_engine: [0306/081413.872062:INFO:delta_performer.cc(397)] Applying 8 operations to partition "bluetooth"
update_engine: [0306/081413.885946:ERROR:fec_file_descriptor.cc(30)] No ECC data in the passed file
update_engine: [0306/081413.886903:ERROR:delta_performer.cc(432)] Unable to open ECC source partition bluetooth on slot A, file /dev/block/bootdevice/by-name/bluetooth_a: Success
update_engine: [0306/081413.887044:ERROR:delta_performer.cc(1042)] The hash of the source data on disk for this operation doesn't match the expected value. This could mean that the delta update payload was targeted for another version, or that the source partition was modified after it was installed, for example, by mounting a filesystem.
update_engine: [0306/081413.887251:ERROR:delta_performer.cc(1047)] Expected: sha256|hex = 9F69430D4BED82B26E49AAA81E0F1E823687605099AD61F45A361A96E7BE6FEE
update_engine: [0306/081413.887321:ERROR:delta_performer.cc(1050)] Calculated: sha256|hex = 734059C0A03A2B2E61CBF3302F2982F3811FD243064D434A6CFC0FAEBDBC0E85
update_engine: [0306/081413.887393:ERROR:delta_performer.cc(1061)] Operation source (offset:size) in blocks: 0:1,6:2,34:1,101:30
update_engine: [0306/081413.887487:WARNING:mount_history.cc(66)] Device was remounted R/W 1 times. Last remount happened on 2019-03-05 03:36:34.000 UTC.
update_engine: [0306/081413.887573:ERROR:delta_performer.cc(1340)] source_fd != nullptr failed.
update_engine: [0306/081413.887652:ERROR:delta_performer.cc(301)] Failed to perform BROTLI_BSDIFF operation 4604, which is the operation 0 in partition "bluetooth"
update_engine: [0306/081413.887721:ERROR:download_action.cc(337)] Error ErrorCode::kDownloadStateInitializationError (20) in DeltaPerformer's Write method when processing the received payload -- Terminating processing
update_engine: [0306/081413.888372:INFO:delta_performer.cc(317)] Discarding 301 unused downloaded bytes
update_engine: [0306/081413.894845:INFO:multi_range_http_fetcher.cc(172)] Received transfer terminated.
update_engine: [0306/081413.895113:INFO:multi_range_http_fetcher.cc(124)] TransferEnded w/ code 206
update_engine: [0306/081413.895166:INFO:multi_range_http_fetcher.cc(126)] Terminating.
update_engine: [0306/081413.895224:INFO:action_processor.cc(116)] ActionProcessor: finished DownloadAction with code ErrorCode::kDownloadStateInitializationError
update_engine: [0306/081413.895278:INFO:action_processor.cc(121)] ActionProcessor: Aborting processing due to failure.
Since Moto One Power is having A/B Partition and seemless update support, It looks like the incremental security update was checking for the checksum of the corresponding partition before applying the incremental update. To fix this I flashed the bluetooth and other failing partitions with the apropriate images available in the above shared link.
Hi there, i'm facing the same issue. Can u please tell me which img to flash from stock firmware?
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
PixelExperience for Xiaomi Mi Max 2 [oxygen]
What is this?
Pixel Experience is an AOSP based ROM, with Google apps included and all Pixel goodies (launcher, wallpapers, icons, fonts, bootanimation)
Our mission is to offer the maximum possible stability and security, along with essential and useful features for the proper functioning of the device
Based on Android 13
Whats working?
WIFI
RIL
Mobile data
GPS
Camera
Flashlight
Bluetooth
Fingerprint reader
Microphone
Lights
Sound / vibration
Known issues
-Nothing yet-
DON'T FLASH GAPPS, THEY'RE ALREADY INCLUDED
Download from Pixel Experience website
Donate
Liked our work? Donate to the project!
Translation
Help with project translation
Stay tuned
Our Telegram channel
Our blog
Device support channelAndroid OS version: 13.0.0_r43
Security patch level: May, 2023
Build Author: HalifaxTe55
Device Source code: https://github.com/PixelExperience-Devices
Source code: https://github.com/PixelExperience
ROM Developer: jhenrique09
Flashing Instructions:
- Reboot to recovery (AOSP Recovery)
- Select "Factory reset" --> "Format data/factory" reset
- Go back to main menu and select "Apply update" --> "Apply from ADB"
- Connect your phone to a computer
- Run adb sideload pe_rom.zip
- Reboot to system
Changelog:
Check the changelog on the pixel experience website
===================================
2022/07/07
Changelog:
- Merge July security patch
- Updated aptX blobs
- Kernel upstreamed to 4.9.321
➤ ROM Changelog
2022/07/01
Changelog:
- Switch to enforcing
- Fixed Auto brightness
- Fixed notification LED
- Fixed Instagram videos playback issues
- Fixed Dirac backend
- Fixed Google Recorder
- Fixed IR blaster
- Update DRM to v 1.4
- Update graphics stack (LA.UM.10.6.2.r1-1900-89xx.0)
- Update Vulkan driver latest
- Update vendor security patch level
- Updated XiaomiParts Chinese translation
- Kernel: Merge tag: LA.UM.10.6.2.r1-02200-89xx.0
- Enable LTO Optimize the kernel for better performance
- Enable lz4 compression zram
- Update kernel to 4.9.319
- Turn off VoLTE notifications by default
2022/06/15
Changelog:
- Fixed fast charging
- Optimize dex flags
2022/06/11
Changelog:
- Fixed wifi issues for some users
- Enable userdata partition encryption
2022/06/10
Changelog:
- June Security Patch
- Fixed microphone issues
- Update kernel to 4.9.317
2022/06/03
Changelog:
initial build
When entering the system for the first time, it is stuck in wifi connection and cannot search for any signal
111qqz said:
When entering the system for the first time, it is stuck in wifi connection and cannot search for any signal
Click to expand...
Click to collapse
Umm... works fine for me, and the same is true for your other systems? If you have time, please give me the log.
HalifaxTe55 said:
Umm... works fine for me, and the same is true for your other systems? If you have time, please give me the log.
Click to expand...
Click to collapse
Thanks for your reply. Other Android 12 rom like lineagos 19.1 has also failed to connect to wifi. it seems mac address and ip address are not available. But android 11 rom works fine. Do i need to update some fireware before upgrading to android 12?
I' d love to post my log if you can teach me how to get this log
no wlan0 interface, cannot find it through "ip link"
the log also show that unrecognized iface name wlan0
i'm poor in english
Can you share your modem partition to us?
111qqz said:
When entering the system for the first time, it is stuck in wifi connection and cannot search for any signal
Click to expand...
Click to collapse
me too I have the same problem with both pixel experience and linage roms
xlrlyt said:
no wlan0 interface, cannot find it through "ip link"
the log also show that unrecognized iface name wlan0
i'm poor in english
Click to expand...
Click to collapse
Try the latest version and see if it works.
xlrlyt2 said:
Can you share your modem partition to us?
Click to expand...
Click to collapse
Try wiping system, vendor, cache, dalvik, data.
If it still doesn't work, please send me the relevant logs, I don't think it has anything to do with the modem partition.
Still failed to search wifi in provision or turn wifi on in settings.
06-10 20:39:50.533 605 605 I [email protected]: Wifi HAL started
06-10 20:39:50.538 605 605 W [email protected]: No active wlan interfaces in use! Using default
06-10 20:39:50.538 605 605 E [email protected]: Unknown iface name: wlan0
06-10 20:39:50.538 605 605 E [email protected]: Unknown iface name: wlan0
06-10 20:40:00.973 605 605 E [email protected]: Failed to write wlan fw path param: No such device
06-10 20:40:00.973 605 605 E [email protected]: Failed to change firmware mode
this is part of the log i think the problem in, the log1.txt is the full log
https://gist.github.com/ntkernel/794a55930d08326b57f996448b71668e
xlrlyt2 said:
06-10 20:39:50.533 605 605 I [email protected]: Wifi HAL started
06-10 20:39:50.538 605 605 W [email protected]: No active wlan interfaces in use! Using default
06-10 20:39:50.538 605 605 E [email protected]: Unknown iface name: wlan0
06-10 20:39:50.538 605 605 E [email protected]: Unknown iface name: wlan0
06-10 20:40:00.973 605 605 E [email protected]: Failed to write wlan fw path param: No such device
06-10 20:40:00.973 605 605 E [email protected]: Failed to change firmware mode
this is part of the log i think the problem in, the log1.txt is the full log
https://gist.github.com/ntkernel/794a55930d08326b57f996448b71668e
Click to expand...
Click to collapse
Flash my latest version, this should fix it
[ 14.181320] ueventd: firmware: loading 'wlan/prima/WCNSS_qcom_wlan_nv.bin' for '/devices/platform/soc/a000000.qcom,wcnss-wlan/firmware/wlan!prima!WCNSS_qcom_wlan_nv.bin'
[ 14.183922] ueventd: firmware: could not find firmware for wlan/prima/WCNSS_qcom_wlan_nv.bin
[ 14.183954] ueventd: firmware: attempted /etc/firmware/wlan/prima/WCNSS_qcom_wlan_nv.bin, open failed: No such file or directory
[ 14.183967] ueventd: firmware: attempted /odm/firmware/wlan/prima/WCNSS_qcom_wlan_nv.bin, open failed: No such file or directory
[ 14.183981] ueventd: firmware: attempted /vendor/firmware/wlan/prima/WCNSS_qcom_wlan_nv.bin, open failed: No such file or directory
[ 14.183993] ueventd: firmware: attempted /firmware/image/wlan/prima/WCNSS_qcom_wlan_nv.bin, open failed: No such file or directory
[ 14.184006] ueventd: firmware: attempted /vendor/firmware_mnt/image/wlan/prima/WCNSS_qcom_wlan_nv.bin, open failed: No such file or directory
[ 14.184099] ueventd: loading /devices/platform/soc/a000000.qcom,wcnss-wlan/firmware/wlan!prima!WCNSS_qcom_wlan_nv.bin took 2ms
[ 14.184297] wcnss: wcnss_nvbin_dnld: request_firmware failed for wlan/prima/WCNSS_qcom_wlan_nv.bin (ret = -11)
[ 14.254628] binder: 1307:1307 ioctl 40046210 ffcda460 returned -22
[ 14.254805] binder: 1307:1307 ioctl 40046210 ffcda448 returned -22
kernel log
https://gist.github.com/ntkernel/78e1a3bd90ca4b260c242a2cc08aa5e9
i have flashed the newest version
xlrlyt2 said:
i have flashed the newest version
Click to expand...
Click to collapse
Please go to my channel, I will post something later and you can help me test it.
i have flashed the newest version too. And it still failed to search for any wifi.
I have fix this problem
This might due to the difference between the modem partition(?)
1. flash and reboot to twrp, mount system rw
2. download a miui and extract its system.img
3. copy the /system/etc/firmware folder to your phones ( adb push )
4. (maybe optional) create a soft link for a file name WCNSS_qcom_cfg.ini to /data/misc/WCNSS_qcom_cfg.ini
xlrlyt2 said:
I have fix this problem
1. flash and reboot to twrp, mount system rw
2. download a miui and extract its system.img
3. copy the /system/etc/firmware folder to your phones ( adb push )
4. (maybe optional) create a soft link for a file name WCNSS_qcom_cfg.ini to /data/misc/WCNSS_qcom_cfg.ini
Click to expand...
Click to collapse
which miui should I download?
111qqz said:
which miui should I download?
Click to expand...
Click to collapse
出错了
www.miui.com
find the max2 and download
then use simg2img to convert the system.img to ext4