Magisk Ulefone Power 3

Ulefone Power 3 - boot loop

Open noraj opened this issue 2 years ago • 38 comments

For humans

I tried to root this old device using the image patching technique but the phone ended up in a boot loop so I had to reflash the unpatched boot.img.

The phone is freshly reinstalled to stock (last update) official ROM.

As there is no separate vbmeta partition, I always checked Patch vbmeta in boot image option. I tried with both Preserve force encryption checked and unchecked. I did not tried to check Preserve AVB 2.0/dm-verity.

Note: It seems that the image patching technique was reported working back in the days when magisk was v7.5 (not 100% sure).

Device: Ulefone Power 3
Android version: 7.1.1
Android security patch level: May 5, 2018
Kernel version: 4.4.22+release@release32 #2 Fri Nov 24 19:25:19 CST 2017
Build Number: Power_3_G03
Magisk version name: 25.2
Magisk version code: 9b61bdfc (25201) (D)
/proc/mounts logs: https://termbin.com/7t3w
/proc/last_kmsg: https://termbin.com/j5jl
unpatched boot.img: https://www36.zippyshare.com/v/gh1nvCpf/file.html
boot ramdisk: yes
separate vbmeta partition: no
A/B (Seamless) System Updates: no

For MagiskBot

Trying to make MagiskBot happy (past fails #6202 #6203)

Device: Ulefone Power 3 Android version: 7.1.1 Magisk version name: 25.2 Magisk version code: 25201

Aug 20 '22 18:08 noraj

nothing related to magisk could be found from last_kmsg.

Aug 22 '22 04:08 yujincheng08

same on Samsung m21 . had to flash stock boot.img to relive my phone

Aug 22 '22 06:08 H3rcu1es

nothing related to magisk could be found from last_kmsg.

Weird, it's 100% reproducible. I can boot with unpatched image and have a boot loop with the patched one. last_kmsg logs were at the 1st boot after successfully re-flashing the unpatched image. As I can't root, I can't provide /sys/fs/pstore/console-ramoops.

Aug 22 '22 18:08 noraj

Please follow this to capture kernel log? https://github.com/topjohnwu/Magisk/issues/5607#issuecomment-1072347395 and https://github.com/topjohnwu/Magisk/issues/5607#issuecomment-1072389939

Aug 23 '22 06:08 canyie

I have tried to patch this image on my side, just noticed the SAR patch is applied to your kernel while your device uses rootfs, not SAR:

Loading dtbs from [kernel_dtb]
Patch @ 01181197 [736B69705F696E697472616D667300] -> [77616E745F696E697472616D667300]

rootfs / rootfs ro,seclabel 0 0
/dev/block/dm-0 /system ext4 ro,seclabel,relatime,data=ordered 0 0

Have you tried to revert the patched kernel back to the unpatched one and see if it works? If so, this will be a duplicate of #5124.

Aug 24 '22 14:08 canyie

Well, just noticed your device uses MediaTek Helio P23 (MT6763V), and Oppo F5 Youth uses MT6763T 😄 If this build works, this is the same issue as #5124. app-debug.zip

Found the kernel source code of Ulefone Power 3: https://github.com/afaulkner420/android_kernel_ulefone_power_3/blob/master/init/initramfs.c#L609 Looks just like any kernels that boot after patching, not sure why it doesn't boot while the skip_initramfs cmdline argument is actually unused 🤔

Aug 24 '22 15:08 canyie

Have you tried to revert the patched kernel back to the unpatched one and see if it works?

Yes it works, it's what I meant by so I had to reflash the unpatched boot.img..

Well, just noticed your device uses MediaTek Helio P23 (MT6763V)

This is correct, https://www.devicespecifications.com/en/model/64074755

The latested update files are available at Google Drive (it's actually linked from Ulefone support software download page). GQ3056MF1_HCS986A_Ulefone_v40.gz contains the various image files. You'll find the same boot.img as I provided.

Found the kernel source code of Ulefone Power 3: https://github.com/afaulkner420/android_kernel_ulefone_power_3/blob/master/init/initramfs.c#L609

It seems the same person provided an unofficial LineageOS build: https://github.com/afaulkner420/android_device_ulefone_power_3, idk if it can helps as LineageOS often provide custom kernels.

Please follow this to capture kernel log? #5607 (comment)

bugreport-N6F26Q-2022-08-24-20-50-45.zip

and #5607 (comment)

Still needed or I should give a try to https://forum.xda-developers.com/t/ulefone-power-3-twrp-3-2-1-0-root-supersu.3741853/? (there is official release on https://twrp.me/Devices/)

Aug 24 '22 19:08 noraj

Try this build first? https://github.com/topjohnwu/Magisk/files/9417317/app-debug.zip

Aug 25 '22 00:08 canyie

Try this build first? https://github.com/topjohnwu/Magisk/files/9417317/app-debug.zip

Still bootlooping bugreport-N6F26Q-2022-08-30-21-16-13.zip

Aug 30 '22 20:08 noraj

Upload installion log? And use this to grab kernel log? I have commented out the code that patchs the kernel.

Aug 31 '22 08:08 canyie

Upload installion log?

When magisk app is patching the image? there is nothing out the ordinary here.

And use https://github.com/topjohnwu/Magisk/issues/5607#issuecomment-1072389939 to grab kernel log?

There is no official TWRP for my phone.

I have found some unofficial stuff but I don't know what to trust.

The GDrive link here is dead https://forum.xda-developers.com/t/ulefone-power-3-twrp-3-2-1-0-root-supersu.3741853/.
https://www.gizdev.com/root-ulefone-power-3-twrp-recovery/, no comments / feedback
- https://drive.google.com/file/d/1StMXocMlElruSE4Z5mivHCITCLaqeqAt/view
https://forum.xda-developers.com/t/twrp-3-2-1-ulefone-power-3-2018-02-03-by-jemmini.3824426/, the guide looks shady and weird, not many feedback
- https://androidfilehost.com/?w=files&flid=280004

Aug 31 '22 17:08 noraj

When magisk app is patching the image? there is nothing out the ordinary here.

Click the "save" button in the "patching image" page after "Done!" is shown.

Sep 02 '22 09:09 canyie

Oh I see, the saved log file contains more information than on the output console.

magisk_install_log_2022-09-02T21.39.16.log

Sep 02 '22 20:09 noraj

second-ulefone.zip Does this image boot?

Sep 10 '22 05:09 canyie

Does this image boot?

No. bugreport-N6F26Q-2010-01-01-00-02-17.zip

Sep 10 '22 14:09 noraj

I just unpacked and repacked the boot.img, so it's likely some bugs within the unpacking/repacking routine and cause the repacked image to be corrupted. 🤔 I'm not good at image formats, so, @osm0sis, sorry for bothering you, but I think you can give some advise. How do you think about this?

Sep 10 '22 15:09 canyie

Unpacked and repacked with magiskboot? I'll do the same and hex compare.

Sep 10 '22 16:09 osm0sis

Unpacked and repacked with magiskboot?

Yes

Sep 11 '22 00:09 canyie

/adb/magisk/magiskboot repack -n boot.img
Parsing boot image: [boot.img]
HEADER_VER      [0]
KERNEL_SZ       [8578893]
RAMDISK_SZ      [2341375]
SECOND_SZ       [0]
EXTRA_SZ        [0]
OS_VERSION      [7.1.1]
OS_PATCH_LEVEL  [2018-05]
PAGESIZE        [2048]
NAME            [GQ3056MF1_HCS98]
CMDLINE         [bootopt=64S3,32N2,64N2 buildvariant=user]
CHECKSUM        [88d970aff9ab3eb364f8598a359d74f8cf4dd88e000000000000000000000000]
KERNEL_DTB_SZ   [120168]
KERNEL_FMT      [gzip]
RAMDISK_FMT     [gzip]
Repack to boot image: [new-boot.img]
HEADER_VER      [0]
KERNEL_SZ       [8578893]
RAMDISK_SZ      [2341375]
SECOND_SZ       [0]
EXTRA_SZ        [0]
OS_VERSION      [7.1.1]
OS_PATCH_LEVEL  [2018-05]
PAGESIZE        [2048]
NAME            [GQ3056MF1_HCS98]
CMDLINE         [bootopt=64S3,32N2,64N2 buildvariant=user]
CHECKSUM        [88d970aff9ab3eb364f8598a359d74f8cf4dd88e000000000000000000000000]

I did unpack -n then repack -n and the header.id checksums match, but the md5 of the resulting new-boot.img is different from the boot.img. I'll check it out in the hex editor tomorrow. 👍

Sep 11 '22 02:09 osm0sis

Only difference was a signature at the end, which I identified as AVBv1.

Android Image Kitchen - UnpackImg Script
by osm0sis @ xda-developers

Supplied image: boot.img

Setting up work folders . . .

Image type: AOSP

Signature with "AVBv1" type detected.

Splitting image to "split_img/" . . .

ANDROID! magic found at: 0
BOARD_KERNEL_CMDLINE bootopt=64S3,32N2,64N2 buildvariant=user
BOARD_KERNEL_BASE 0x40078000
BOARD_NAME GQ3056MF1_HCS98
BOARD_PAGE_SIZE 2048
BOARD_HASH_TYPE sha1
BOARD_KERNEL_OFFSET 0x00008000
BOARD_RAMDISK_OFFSET 0x14f88000
BOARD_SECOND_OFFSET 0x00e88000
BOARD_TAGS_OFFSET 0x13f88000
BOARD_OS_VERSION 7.1.1
BOARD_OS_PATCH_LEVEL 2018-05
BOARD_HEADER_VERSION 0

Unpacking ramdisk to "ramdisk/" . . .

Compression used: gzip
11189 blocks

Done!

Press any key to continue . . .

Make sense where that was just command-line magiskboot, not the whole script. @noraj can you upload your patched boot.img made through the Magisk app? Want to make sure that all still worked. If it does then it'd be an identical .img, so then it just comes down to the patching process and there would be nothing actually wrong with the .img formatting.

Sep 11 '22 14:09 osm0sis

patched.img.zip

Sep 11 '22 15:09 noraj

patched.img.zip

Oh wow, so the magisk_patched-25200_FV2Q6.img inside is 10KB of completely zeros in hex, so something went very wrong with file creation or with your uploading? I didn't see a patching log for that being created?

Sep 14 '22 00:09 osm0sis

magisk_patched-25201_7aeNi.img ➡️ magisk_install_log_2010-01-05T06.23.31.log (Preserve force encryption)
magisk_patched-25201_Rvnsx.img ➡️ magisk_install_log_2010-01-05T06.24.24.log (Preserve force encryption + Patch vbmeta in boot image)

magisk_install_log_2010-01-05T06.23.31.log magisk_install_log_2010-01-05T06.24.24.log magisk_patched-25201_7aeNi.img.zip magisk_patched-25201_Rvnsx.img.zip

Sep 14 '22 20:09 noraj

Thanks. Yep, those ones look good, properly signed, etc. So it's nothing format-wise that I can see. Just something with magiskinit presumably.

Sep 19 '22 16:09 osm0sis

Re-download the unpatched image and repack it with KEEPVERITY=true KEEPFORCEENCRYPT=true PATCHVBMETAFLAG=true RECOVERYMODE=false

new-boot-n.zip (with -n option)

new-boot-c.zip (with no -n option)

@noraj Can you test if these images boot?

Oct 01 '22 16:10 canyie

new-boot-n.zip (with -n option)

Yes this one boot.

new-boot-c.zip (with no -n option)

This one doesn't work, stuck in bootloop.

Oct 01 '22 20:10 noraj

So the bug seems to be in gzip compression/decompression routine 🤔

Oct 02 '22 04:10 canyie

Extracted the kernel from both images via magiskboot unpack -n, recompressed kernel is 6KB larger than the original one, but I can decompress it so it is a good gzip. Manually decompress via gzip -d and do hex compare, they are the same file 🤔

Perhaps you can try this. I used the gzip command to decompress and compress the kernel and ramdisk.cpio. gzip-boot.zip

$ ./magiskboot unpack -n new-boot-n.img
Parsing boot image: [new-boot-n.img]
HEADER_VER      [0]
KERNEL_SZ       [8578893]
RAMDISK_SZ      [2341375]
SECOND_SZ       [0]
EXTRA_SZ        [0]
OS_VERSION      [7.1.1]
OS_PATCH_LEVEL  [2018-05]
PAGESIZE        [2048]
NAME            [GQ3056MF1_HCS98]
CMDLINE         [bootopt=64S3,32N2,64N2 buildvariant=user]
CHECKSUM        [88d970aff9ab3eb364f8598a359d74f8cf4dd88e000000000000000000000000]
KERNEL_DTB_SZ   [120168]
KERNEL_FMT      [gzip]
RAMDISK_FMT     [gzip]

$ mv kernel kernel.gz
$ gzip -d kernel.gz
$ mv ramdisk.cpio ramdisk.cpio.gz
$ gzip -d ramdisk.cpio.gz
$ gzip -9 kernel
$ gzip -9 ramdisk.cpio
$ mv kernel.gz kernel
$ mv ramdisk.cpio.gz ramdisk.cpio

$ ./magiskboot repack -n new-boot-n.img gzip-boot.img                                                                    <
Parsing boot image: [new-boot-n.img]
HEADER_VER      [0]
KERNEL_SZ       [8578893]
RAMDISK_SZ      [2341375]
SECOND_SZ       [0]
EXTRA_SZ        [0]
OS_VERSION      [7.1.1]
OS_PATCH_LEVEL  [2018-05]
PAGESIZE        [2048]
NAME            [GQ3056MF1_HCS98]
CMDLINE         [bootopt=64S3,32N2,64N2 buildvariant=user]
CHECKSUM        [88d970aff9ab3eb364f8598a359d74f8cf4dd88e000000000000000000000000]
KERNEL_DTB_SZ   [120168]
KERNEL_FMT      [gzip]
RAMDISK_FMT     [gzip]
Repack to boot image: [gzip-boot.img]
HEADER_VER      [0]
KERNEL_SZ       [8585082]
RAMDISK_SZ      [2332044]
SECOND_SZ       [0]
EXTRA_SZ        [0]
OS_VERSION      [7.1.1]
OS_PATCH_LEVEL  [2018-05]
PAGESIZE        [2048]
NAME            [GQ3056MF1_HCS98]
CMDLINE         [bootopt=64S3,32N2,64N2 buildvariant=user]
CHECKSUM        [855a6d4f62423705196208c8519e9113787d0d1c000000000000000000000000]

Oct 02 '22 05:10 canyie

Perhaps you can try this. I used the gzip command to decompress and compress the kernel and ramdisk.cpio. gzip-boot.zip

This one boot-loops.

Oct 09 '22 09:10 noraj

zopfli-boot.zip And how about this? I'm trying Zopfli for better compression rate to see what will happen if the recompressed kernel/ramdisk are not larger.

# ./magiskboot unpack new-boot-n.img
Parsing boot image: [new-boot-n.img]
HEADER_VER      [0]
KERNEL_SZ       [8578893]
RAMDISK_SZ      [2341375]
SECOND_SZ       [0]
EXTRA_SZ        [0]
OS_VERSION      [7.1.1]
OS_PATCH_LEVEL  [2018-05]
PAGESIZE        [2048]
NAME            [GQ3056MF1_HCS98]
CMDLINE         [bootopt=64S3,32N2,64N2 buildvariant=user]
CHECKSUM        [88d970aff9ab3eb364f8598a359d74f8cf4dd88e000000000000000000000000]
KERNEL_DTB_SZ   [120168]
KERNEL_FMT      [gzip]
RAMDISK_FMT     [gzip]
# ./magiskboot repack new-boot-n.img new-boot-zopfli
Parsing boot image: [new-boot-n.img]
HEADER_VER      [0]
KERNEL_SZ       [8578893]
RAMDISK_SZ      [2341375]
SECOND_SZ       [0]
EXTRA_SZ        [0]
OS_VERSION      [7.1.1]
OS_PATCH_LEVEL  [2018-05]
PAGESIZE        [2048]
NAME            [GQ3056MF1_HCS98]
CMDLINE         [bootopt=64S3,32N2,64N2 buildvariant=user]
CHECKSUM        [88d970aff9ab3eb364f8598a359d74f8cf4dd88e000000000000000000000000]
KERNEL_DTB_SZ   [120168]
KERNEL_FMT      [gzip]
RAMDISK_FMT     [gzip]
Repack to boot image: [new-boot-zopfli]
HEADER_VER      [0]
KERNEL_SZ       [8408456]
RAMDISK_SZ      [2302711]
SECOND_SZ       [0]
EXTRA_SZ        [0]
OS_VERSION      [7.1.1]
OS_PATCH_LEVEL  [2018-05]
PAGESIZE        [2048]
NAME            [GQ3056MF1_HCS98]
CMDLINE         [bootopt=64S3,32N2,64N2 buildvariant=user]
CHECKSUM        [a0b1438a6dc892e6a501dfe085787d6b4bccdd5f000000000000000000000000]

Oct 11 '22 14:10 canyie

Magisk Magisk copied to clipboard

Ulefone Power 3 - boot loop

For humans

For MagiskBot

Magisk
Magisk copied to clipboard