I was tired last night and so focused on disabling dm-verity that I didn't stop to think about the contents of the boot image I was flashing. Of course it could never work, because it still had the original DTB. I woke up this morning and immediately realised my mistake.Yep you're correct the patched boot was intended to disable dm-verity, however it won't work because of the dtb issue.
Unless the dtb can be patched no modifications are possible.
Upon checking the stock and repacked dtb the headers are indeed different which I guess is why it won't boot.
Thanks for the new build of TWRP. Unfortunately, it still fails to mount odm and still complains that /system is busy. Whatever is being mounted as /system isn't really /system, though. It contains only 8 Mb of data.So I have taken a different tack and hex edited the dtb to preserve the header. Now I have done this two different ways as I don't know which will be successful, if any.
Have also recompiled TWRP with fixes for mounting the partitions with errors and fixed some errors in the forced encryption patch.
Just to note, the encryption patch modifies the vendor partition which means dm-verity will be triggered. This is fine as long as the patched dtb boots and does it's job and disables dm-verity!
df -h on the device reveals that /dev/block/sda20 is being used for /data, /sdcard, /system and /system_image.
Similarly, /cache and /efs both share sda23. /vendor is the only one that is uniquely assigned, getting sda21. That can't be right, can it?
I have spent the morning playing with the 2 new boot images. Using Odin, I performed a fresh stock firmware installation prior to each installation. Odin was also used to install the boot images Sadly, both result in Verification Failed when Android comes up, so I never get as far as testing the encryption patch.
After the verification failure of the second image, I decided to reboot to TWRP and walk through the various screens and their functions in order to produce a meaningful log for you. I untarred boot.img from the boot1 image and flashed that, following immediately wish a format of DATA. The screen froze (the progress animation at the bottom of the screen seized) and the system rebooted. This was the reboot phenomenon I spoke of yesterday.
Back in TWRP, I grabbed a last_kmsg for you, but I don't know if it contains any clues as to why the system rebooted. This is only the second time I have triggered a reboot by formatting DATA.
I tried exactly the same thing again: flashed boot.img and then immediately formatted DATA. This time, no reboot. It seems to occur only the first time DATA is formatted after receiving a verification error when booting into Android.
Next, I tried mounting all of the file systems.
Next, I did a back-up of boot and system. That seemed to work fine.
Next, I did a simple wipe of DATA. Again, this caused an immediate reboot, but this time the device's vibration came on and stayed on until the Samsung splash screen came up.
Back in TWRP, I produced a second last_kmsg for you.
I tried another simple wipe of DATA, this time with no reboot. I followed it with a format of DATA. Again, no reboot.
If those sda devices are genuinely wrongly assigned, then that would explain all of the weirdness, I guess.
I'm attaching a log this time. I meant to do this last night, but I fell asleep on the couch. The dmesg portion is too big for XDA, so you can download it here.
This device is starting to irritate me. It doesn't have a hard Home button, so rebooting into Download mode requires one to first go through Recovery. Even turning the machine off is impossible through TWRP. Shutdowns always reboot, no matter how they're attempted. I have to reinstall stock firmware just to be able to turn it off.
Anyway, thanks for your persistence. This device is a tricky one.
22.7 KB Views: 12
22.7 KB Views: 7
30.7 KB Views: 18