Device is corrupt. It can't be trusted

[officefrey]

Pixel 6
oriole-2025032500-1c3df7a-magisk-v28.1.zip

Hello, after trying several times to patch Graphene using your guide, I'm getting "Device is corrupt. It can't be trusted" and phone is stuck on Google logo on botting. I am pretty sure i have followed your guide correctly. What could be wrong? Thank you

[schnatterer]

Hi @officefrey, first time I read of this error.
Did you search the web, to find out what could have caused it?
Did you upgrade from oriole-2025032100-b956048-magisk-v28.1.zip or an earlier version?
bd57bc7 fixed an error particularly for oriole. Maybe there is something else wrong now.

[officefrey]

Thank you for your resposne! I flashed Graphene (oriole-2025032500) via their website, then before locking the bootloader, I followed your steps to patch Graphene. When doing so, the phone won't boot.

Without using the patch, phone boots normally. I did not upgrade from oriole-2025032100-b956048-magisk-v28.1.zip, I stumbled just now on your github, never patched graphene before. Thank you

[schnatterer]

Good, that rules out some things and there is no data loss involved.

I just upgraded my pix6, which worked.

Are you sure you followed all steps, especially these?

fastboot erase avb_custom_key
curl -s https://raw.githubusercontent.com/schnatterer/rooted-graphene/main/avb_pkmd.bin > avb_pkmd.bin
fastboot flash avb_custom_key avb_pkmd.bin

[officefrey]

I think i am, im just copy pasting commands more or less, haha. I can put the logs here if you want to look over them.

**PS C:\Users\velce\Downloads\lineagePixel> fastboot flashall --skip-reboot**
< waiting for any device >
--------------------------------------------
Bootloader Version...: slider-15.2-12893632
Baseband Version.....: g5123b-145971-250103-B-12866815
Serial Number........: 19141FDF6000GY
--------------------------------------------
Checking 'product'                                 OKAY [  0.000s]
Setting current slot to 'a'                        OKAY [  0.095s]
Sending 'boot_a' (65536 KB)                        OKAY [  1.848s]
Writing 'boot_a'                                   OKAY [  0.122s]
Sending 'vbmeta_a' (8 KB)                          OKAY [  0.001s]
Writing 'vbmeta_a'                                 OKAY [  0.002s]
Sending 'vendor_boot_a' (65536 KB)                 OKAY [  1.850s]
Writing 'vendor_boot_a'                            OKAY [  0.113s]
Rebooting into fastboot                            OKAY [  0.000s]
< waiting for any device >
Resizing 'system_a'                                OKAY [  0.011s]
Sending sparse 'system_a' 1/6 (262108 KB)          OKAY [  7.847s]
Writing 'system_a'                                 OKAY [  0.662s]
Sending sparse 'system_a' 2/6 (262128 KB)          OKAY [  7.735s]
Writing 'system_a'                                 OKAY [  0.612s]
Sending sparse 'system_a' 3/6 (262112 KB)          OKAY [  7.756s]
Writing 'system_a'                                 OKAY [  0.642s]
Sending sparse 'system_a' 4/6 (262108 KB)          OKAY [  7.788s]
Writing 'system_a'                                 OKAY [  0.664s]
Sending sparse 'system_a' 5/6 (262128 KB)          OKAY [  7.744s]
Writing 'system_a'                                 OKAY [  0.610s]
Sending sparse 'system_a' 6/6 (162000 KB)          OKAY [  4.810s]
Writing 'system_a'                                 OKAY [  0.426s]
Finished. Total time: 71.349s
**PS C:\Users\velce\Downloads\lineagePixel> fastboot reboot-bootloader**
Rebooting into bootloader                          OKAY [  0.001s]
Finished. Total time: 0.002s
**PS C:\Users\velce\Downloads\lineagePixel> fastboot erase avb_custom_key**
Erasing 'avb_custom_key'                           (bootloader) avb custom key: erase done
OKAY [  0.024s]
Finished. Total time: 0.025s
**PS C:\Users\velce\Downloads\lineagePixel> fastboot flash avb_custom_key avb_pkmd.bin**
Warning: skip copying avb_custom_key image avb footer (avb_custom_key partition size: 0, avb_custom_key image size: 1032).
Sending 'avb_custom_key' (1 KB)                    OKAY [  0.000s]
Writing 'avb_custom_key'                           (bootloader) avb custom key: flash done
OKAY [  0.028s]
Finished. Total time: 0.035s

[schnatterer]

🤔
After that you locked the bootloader and rebooted? And then came the error?

You already had several tries but me graphene worked but after patching it no longer did?

You could try erase the key again (just to be sure)
https://github.com/chenxiaolong/avbroot?tab=readme-ov-file#reverting-to-stock-firmware
And then try it once more, maybe with an older version like 2025032100.
Sorry, just guessing here.

[officefrey]

Will try in a bit, thanks.

Yes, the error comes after trying to boot the phone regardless if bootloader is locked or not

Question: Don't i need the original Graphene 2025032100 version in order to try it? If so, i do not have their old release. I was actually thinking to try an older version but apparently Graphene doesn't keep their previous releases to be downloaded, is that correct?

[schnatterer]

Yes, I've also noticed they don't keep all old versions.
I think the latest and the one before that maybe.
https://releases.grapheneos.org/oriole-install-2025032100.zip is still available at the mo

[officefrey]

Thank you. I just finished flashing the older version and unfortunately its the same outcome...same error 😭

[schnatterer]

As a last resort we might call in @chenxiaolong, the author of avbroot.
Do you have any idea what could cause this issue?

[officefrey]

If it matters, this is my device info. Thanks

[chenxiaolong]

Before locking the bootloader, I'd suggest sideloading the patched OTA from recovery mode twice (with a reboot in between).

The only time I've personally encountered the "Device is corrupt. It can't be trusted" error is when the A and B slots weren't signed by the same key. It doesn't seem to be consistent though--I was never able to intentionally reproduce the problem.

[officefrey]

I have tried that several few times and did not work. I decided to try on my MAC instead of Windows but I cannot flash the patched OTA now, tried everything i found. I am 100% sure I haven't mixed up factory images and OTA

fastboot version 36.0.0-13206524

< waiting for any device >
--------------------------------------------
Bootloader Version...: slider-15.2-12893632
Baseband Version.....: g5123b-145971-250103-B-12866815
Serial Number........: 19141FDF6000GY
--------------------------------------------
Checking 'product'                                 OKAY [  0.000s]
Setting current slot to 'a'                        OKAY [  0.087s]
Sending 'boot_a' (65536 KB)                        OKAY [  1.544s]
Writing 'boot_a'                                   OKAY [  0.121s]
Sending 'vbmeta_a' (8 KB)                          OKAY [  0.001s]
Writing 'vbmeta_a'                                 OKAY [  0.002s]
Sending 'vendor_boot_a' (65536 KB)                 OKAY [  1.516s]
Writing 'vendor_boot_a'                            OKAY [  0.113s]
Rebooting into fastboot                            OKAY [  0.000s]

< waiting for any device >

ERROR: usb_write failed with status e00002ed
fastboot: error: Failed to boot into userspace fastboot; one or more components might be unbootable.

[officefrey]

So after several tries, fastboot is just messed up on mac, i tried several versions,cables,ports it just wont let me flash.

I went back on trying on windows but the phone wont boot after patching regardless what I tried, i probably tried 20 times.

I have a Pixel6a that i can try on, do you happen to have graphene image for Pixel6a that is supported by your patch so i can try on it as well? Thank you

[schnatterer]

Acutally, I do: https://github.com/rooted-graphene/ota/releases/tag/2025032500 - bluejay is pix6a.
Just moved the OTA builds to its own GH organization to be able to support more devices, yesterday. Just in time 🙂

Hope it works on bluejay! You could also try flashing from a linux VM.

[chenxiaolong]

One last thing that might be worth checking is the ID that the bootloader shows when booting:

If avb_custom_key was flashed successfully, that ID should match the SHA256 checksum of the avb_pkmd.bin file. (Note that my picture is for my own key, so yours will be different.)

[FinGu]

Same thing is happening to me for some reason. I had to reinstall due to custota not being able to sideload a new update for some reason

[FinGu]

Even redoing that whole process and getting it to not show that error ( don't ask me why it was caused in the first place ), i'm stuck in a boot loop

[schnatterer]

Thanks for coming forward with this @FinGu. Do you remember the version you tried to upgrade from?
There were two recent changes that might have cause the failing upgrade.

• 2025030200: Switch from custota signature file version 1 to 2
• 2025021100: Integrate custota as private app, conflicting with custota magisk module unfortunately.

Especially the latter might have something to do with Device is corrupt. What device are you using, also oriole?

I built a version without custota included that you could try (you as well @officefrey):

• https://github.com/rooted-graphene/ota/releases/download/2025032500/oriole-2025032500-7c061ff-magisk-v28.1.zip
• https://github.com/rooted-graphene/ota/releases/download/2025032500/oriole-2025032500-7c061ff-rootless.zip

Please let me know if that also causes Device is corrupt.

[FinGu]

As far as i remember it stopped updating when you released the version that integrates Custota as a private app. I'm using caiman ( Pixel 9 Pro ). Can't try the ota you sent because of that. Thanks for the quick answer!

[schnatterer]

The link above contains some info about troubleshooting for the custota module.

But you have wiped your device by now, right?

Here is the same build for caiman:
https://github.com/rooted-graphene/ota/releases/download/2025032500/caiman-2025032500-7c061ff-magisk-v28.1.zip
https://github.com/rooted-graphene/ota/releases/download/2025032500/caiman-2025032500-7c061ff-rootless.zip

[FinGu]

I have, yeah. Will try that build really soon

[FinGu]

This one worked absolutely fine! No bootloops and no device is corrupt. I'll install custota and hope nothing goes wrong..

[schnatterer]

Interesting find, @FinGu!
If you install custota magisk module it's likely to cause trouble on the next OTA. If you want to avoid it, it's probably best to uninstall the custota magisk module and sideload the next OTA. Then custota should be included as system app.

[schnatterer]

@chenxiaolong it seems that the Device is corrupt. errors (occurring only on (some?) initial installations, not OTA updates) seem to correlate to using the my-avbroot-setup script with the custota, oemunlockonboot modules (and possibly magisk).
Using avbroot directly on the upstream OTA (even with magisk) seems to create OTAs that do not cause this.

Do you have any ideas on why the my-avbroot-setup module patching could result in these kinds of errors?

Edit: Another difference of the builds is avbroot 3.12.0 vs 3.14.0. Could that have changed something?

[chenxiaolong]

I don't really have any idea why this could be happening.

The bootloader shows that error when signature verification fails. There's not really any way the same OTA could verify successfully on some devices, but not others. I'm guessing (but without any evidence) that the issue occurs somewhere in the flashing process.

Does flashing twice with fastboot help at all? (eg. fastboot set_active a + flashall and then again with b)

[chenxiaolong]

To rule out avbroot signing issues, you can also try verifying the signatures using AOSP's avbtool after extracting the OTA (avbroot ota extract -i ota.zip -a -d extracted):

avbtool verify_image --image vbmeta.img

[schnatterer]

@chenxiaolong Thanks for sharing your thoughts!
The log in #93 shows Warning: skip copying avb_custom_key image avb footer (avb_custom_key partition size: 0, avb_custom_key image size: 1032)..
Could that be related?

[chenxiaolong]

Yep, that message is normal and is expected when flashing avb_custom_key with fastboot. fastboot prints this out whenever the partition being flashed is very small (eg. 1032 bytes in this case).

EDIT: Sorry, correction: fastboot prints this out when the reported partition size is smaller than what's being flashed. avb_custom_key is reported as having a size of 0 because it's not a real partition. Flashing avb_custom_key is just changing the bootloader's internal configuration.

[schnatterer]

To rule out avbroot signing issues, you can also try verifying the signatures using AOSP's avbtool after extracting the OTA (avbroot ota extract -i ota.zip -a -d extracted):

avbtool verify_image --image vbmeta.img

It seems to be valid for the OTA.zip of the OP

$ avbroot ota extract -i oriole-2025032500-1c3df7a-magisk-v28.1.zip -a -d extracted
  0.001s  INFO Extracting from the payload: abl, bl1, bl2, bl31, boot, dtbo, gsa, ldfw, modem, pbl, product, pvmfw, system, system_ext, tzsw, vbmeta, vendor, vendor_boot, vendor_dlkm
  4.406s  INFO Successfully extracted images from payload

$ avbtool verify_image --image extracted/vbmeta.img
Verifying image vbmeta.img using embedded public key
vbmeta: Successfully verified SHA256_RSA4096 vbmeta struct in vbmeta.img
boot: Successfully verified sha256 hash of boot.img for image of 21307392 bytes
dtbo: Successfully verified sha256 hash of dtbo.img for image of 2796257 bytes
pvmfw: Successfully verified sha256 hash of pvmfw.img for image of 778240 bytes
vendor_boot: Successfully verified sha256 hash of vendor_boot.img for image of 36978688 bytes
product: Successfully verified sha256 hashtree of product.img for image of 749256704 bytes
system: Successfully verified sha256 hashtree of system.img for image of 1488982016 bytes
system_ext: Successfully verified sha256 hashtree of system_ext.img for image of 417267712 bytes
vendor: Successfully verified sha256 hashtree of vendor.img for image of 579194880 bytes
vendor_dlkm: Successfully verified sha256 hashtree of vendor_dlkm.img for image of 59764736 bytes

In other news, to get closer to the cause of the issue, I created OTAs

• Without modules, created using avbroot 3.14.0
  • husky-2025032500-89b5ec2-magisk-v28.1-minimal.zip
  • husky-2025032500-89b5ec2-rootless-minimal.zip
  • oriole-2025032500-89b5ec2-magisk-v28.1-minimal.zip
  • oriole-2025032500-89b5ec2-rootless-minimal.zip
• With modules, created using avbroot 3.12.0
  • husky-2025032500-89b5ec2-magisk-v28.1.zip
  • husky-2025032500-89b5ec2-rootless.zip
  • oriole-2025032500-89b5ec2-magisk-v28.1.zip
  • oriole-2025032500-89b5ec2-rootless.zip

I'd very much appreciate if one of you @officefrey @FinGu could try them and tell me if one of them fixes the error.

[FinGu]

I've already tried the one without modules and then later sideloaded the normal ( latest update ) with modules in recovery.. as my stuff is working right now i can't really try that out..
What worked for me was flashing this: caiman-2025032500-7c061ff-magisk-v28.1.zip
And then sideloading caiman-2025032500-1c3df7a-magisk-v28.1.zip

[schnatterer]

Thanks, it's good to know a workaround!

I don't have a device at hand myself that I can wipe, so let's hope someone else gives us more clues if the error is caused by the modules to or by the avbroot version.

[chenxiaolong]

Funny enough, I just ran into this after an OTA update (my own build) on my Pixel Tablet:

Happened every boot and the error was bypassable by hitting the power button. (Similar issue to what folks are experiencing, but might not be exactly the same.)

Flashing the same build any number of times did not resolve the error. So I created a second patched OTA with a different set of modules and sideloaded that from recovery. That got rid of the error.

Then I sideloaded the original OTA from recovery mode again and it continues to work.

I don't think there's anything wrong with any of your builds @schnatterer. There's definitely some sort of bootloader bug that some folks are unlucky enough to hit. It wouldn't be the first time the bootloader had weird bugs. The bootloader version than the Pixel 7 series initially shipped with could sometimes (very rarely) fail to verify signatures after a simple reboot, without even flashing anything.

Unfortunately, I have no suggestions for how to work around the problem. In my case, I could flash a different build (same OS version) and then reflash what I originally intended, but I don't know if that always works. I also can't reproduce the problem anymore to do further tests.

[schnatterer]

@chenxiaolong This happening after an OTA update seems challenging for ordinary users. But very good news that it can be bypassed using the power button.
Documenting this might even be enough of a workaround for me 🙂

From what you say, this seems to correspond in some way with modules. Before I started adding modules this seemed not have happened.

This happening to you also, now and for the first time, do you think it is a coincidence?
Or could there be something different in the latest OTAs, the modules or even custota?

[chenxiaolong]

I don't think the modules are the cause because they only affect the system and vendor partitions, which the bootloader isn't capable of reading because it doesn't understand dynamic partitions. In my case, the OTA that triggered the problem was a --rootless one with no modules.

Given that flashing a different OTA and then flashing the original intended OTA again resolves the problem (at least for me), I think it's a coincidence and we're encountering some rare bootloader bug. I can't think of any other reason why the behavior wouldn't be deterministic.

[schnatterer]

Thank you for providing this additional context. Let's hope the power button workaround sticks 🙂