3

I just got a device running Android 7.1.1 (an BQ Aquaris X5 Plus to be precise). Fine device, and all – unlocking the bootloader was as easy as enabling bootloader unlock in settings, and running fastboot oem unlock. As I like complete backups and other features custom recoveries provide, I flashed . Woked fine, could boot into it – but then, the device no longer boots up into Android itself – it simply gets stuck on the boot screen.

Things I've tried:

  • wiping /cache and /data (via TWRP's advanced wipe)
  • performing a factory reset via TWRP

No dice. What could that be, and how to solve the issue?

1 Answer 1

3

Searching the web gave me a clue: While before Android 7 one could easily flash a custom recovery without fearing side-effects, starting with Android 7 the system enforces DM Verity. That is, at a very early stage in the boot process, the system checks whether any partition was "tampered" with – which in my case meant the /recovery partition. As far as I could figure, in such a case a warning should be shown to the user and asked whether to continue anyway. In my case, there was no such thing.

So what to do to fix it? Actually, it is the boot image requiring a fix – namely, the verify option must be removed from the entries of affected partitions. The following options exist for this:

  • adb disable-verity is mentioned, but it isn't a good solution because it cannot be issued in TWRP and it requires the ROM to be a userdebug build or an engineering build (it doesn't work on user builds).
  • Manually disabling dm-verity in the boot.img describes how to modify the boot image (i.e. change the fstab file removing the verify option). That requires extracting the boot image, modifying it, repacking it, flashing it back. Can be done using SuperR's Kitchen – which is available for Linux, Mac and Windows. Should definitely work, but is quite a bit of work itself.
  • LazyFlasher offers a flashable ZIP (no-verity-opt-encrypt-6.0.zip) which should do the trick. Should be fine for those who want avoid to root their device for one reason or the other. It will disable forced encryption along.
  • Flashing SuperSU did the trick for me: SuperSU detected that DM-Verity was active, extracted the boot image, patched it accordingly, and flashed back the patched version – which then also includes SuperSU itself.

So after flashing SuperSU, the device booted up normally again – issue solved for me. You might chose one of the other approaches (feedback welcome then).

Note that these two (SuperSU and LazyFlasher) are just examples. As iBug correctly points out, "SuperSU is dead" – so you'd better use Magisk, which in this context does the same: flashing itself systemlessly and disabling DM-Verity.

8
  • SuperSU is dead. Flash Magisk instead. It also disables DM-verity.
    – iBug
    Sep 28, 2018 at 15:19
  • Yes, sure. It just had issues on a custom Lineage build on another device. For me this was rather a proof-of-concept check; this weekend I planned to flash Lineage anyway, and that would have booted (unless I really broke something, which I doubted and now proofed). So you'd go Magisk even on Lineage, @iBug? I run it on another device (on a stock ROM), so I'm familiar with it. Still arguing with myself which to pick (SuperSU or Magisk). If it matters: It's LOS 14.1 (Nougat), LOS 15 is not yet ready for "gohan". I'll need Xposed, but that goes with both.
    – Izzy
    Sep 28, 2018 at 16:47
  • I flashed Lineage from 14.1 to 15.1 and I use Magisk all the time. It works perfectly well on Lineage.
    – iBug
    Sep 28, 2018 at 23:13
  • Thanks, @iBug – did that yesterday, looks good so far. Updated my answer accordingly.
    – Izzy
    Sep 30, 2018 at 9:39
  • 1
    Wanted to submit another answer, but seems like this one is comprehensive enough that there could be little room for another one.
    – iBug
    Sep 30, 2018 at 9:42

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .