Develop Bugs

stupid dev questions

so...i'm behide the curve on on this hero stuff (being a rom cook for the s200 i'm not complete clueless...but thats winmo)
Anyway i'm playing around and would love an answer on these from one of the resident dev's on here
1. i took boot.img from the RUU rom.zip of wwe 2.73.405.61, took the system.img, did the magic to create an update.zip, which seems to flash fine from a recovery rom BUT on reboot it's stuck on the Hero boot screen/logo, any clue as to where to look/debug (yes I did the wipe etc. etc. it must be something about the update.zip / boot.img i'm missing)
2. i assume there is still no way to re-sign the a changed RUU rom.zip ?
Thanks for your time !

1: extract the system with unyaffs
2: zip the contents of the extracted system
3: sign the resulting zip (androsign or whatever)
boot into recovery
4: copy over to sdcard
5: copy over boot.img also to sdcard
6: cat /dev/zero > /dev/mtd/mtd2
or
dd if=/dev/zero of=/dev/mtd/mtd2
whichever you prefer
7: flash_image boot /sdcard/boot.img
8: flash your update.zip or whatever you called it
9: wipe system (format DATA: & CACHE
OR
flash_image system system.img (might not work)

adwinp said:
1: extract the system with unyaffs
2: zip the contents of the extracted system
3: sign the resulting zip (androsign or whatever)
boot into recovery
4: copy over to sdcard
5: copy over boot.img also to sdcard
6: cat /dev/zero > /dev/mtd/mtd2
or
dd if=/dev/zero of=/dev/mtd/mtd2
whichever you prefer
7: flash_image boot /sdcard/boot.img
8: flash your update.zip or whatever you called it
9: wipe system (format DATA: & CACHE
OR
flash_image system system.img (might not work)
Click to expand...
Click to collapse
Thanks, i got that far, but rolling the whole thing (so boot.img + extracted system.img) into update.zip and flashing that from a recovery image is where it goes all tits up and doesn't boot, even tried without any changes and just taking the boot.img and system.img from a offical htc rom and creating an update.zip
so i must be doing something wrong but can't put my finger where it goes wrong.
anycase, i'll keep trying
thx

1: Did you sign your update.zip?
2: An update.zip usually contains an update script; did you write one too?
This is why I suggested you flash manually.

adwinp said:
1: Did you sign your update.zip?
2: An update.zip usually contains an update script; did you write one too?
This is why I suggested you flash manually.
Click to expand...
Click to collapse
both answers yes
still digging, but it could be that "something" in the update script isn't working, however i've copied one from a working rom, with the same results...
going through the script now....i'm sure it's something stupid and i'll smack my head later, but for now no go......thanks for your tips and time !
Edit:
is there something special you need to do with the boot.img if you just copy (unzip thats it) from a rom.zip and put it in the update.zip ??

Jesterz said:
Edit:
is there something special you need to do with the boot.img if you just copy (unzip thats it) from a rom.zip and put it in the update.zip ??
Click to expand...
Click to collapse
Either you push it to sdcard and
#flash_image boot /sdcard/boot.img
or
in the update.zip:
META-INF\com\google\android\update-script
where META-INF is a folder in the root, and update-script is a text file without file extension; its contents should be:
show_progress 0.1 0
write_raw_image PACKAGE:boot.img BOOT:
show_progress 0.1 10
So, the contents should be:
\META-INF\
com\
google\
android\update-script
\boot.img
zip all that into update.zip, and sign the zip.

[DEV Idea] Magldr/CLK all-in-one rom (somewhat obsolete..)

Work posted here, it is tested working by me
http://www.neopeek.com/viewtopic.php?f=24&t=7366
Just make sure to copy all files needed by CLK (ppp, ril wrapper, init.d scripts, etc) from tytung's kernel patches

This would be awesome if pulled off

MAGLDR 1.2 and below only support Yaffs boot partition type.
MAGLDR 1.3 supports Yaffs and Raw boot partition types.
And cLK only supports Raw boot partition type.
However every MAGLDR ROM uses Yaffs boot partition, that's why we need to separate two types of ROMs.
In fact, I ever released a RAW boot partition ROM (NexusHD2-Gingerbread_V2.6T_WiFi-Calling_update_20110418.zip) in WiFi Calling development thread that suits for cLK and MAGLDR at the same time.
It uses PPP as the default data connection, but we can switch to more stable RMNET if using MAGLDR.

e334 said:
Finding out that the only difference between a magldr and a clk rom is the format of /boot (initrd.gz/zImage vs Boot.IMG), files in /etc/ppp and some scripts in /etc/init.d, I've decided to try to combine everything all together so developers would not need to upload 2 seperate versions of a rom in order to suit both CLK and MagLDR users...
The basic principle is this:
-updater-script checks /mnt/sdcard for a file called "clk.txt" or "magldr.txt" (that is created by the user) and then if it find "clk.txt", it unpacks files needed for clk compatibility and flashes boot.img but if it finds "magldr.txt", it copies the /boot folder to the /boot partition and nothing else is changed (assuming the rom was built for magldr ONLY compatibility at first).
So extra files that will be needed for the rom to be both clk/magldr compatible would be as listed:
/system/etc/.clk.tar.gz
(Contents of .clk.tar.gz are basically the same as the CLK patch by tytung except with 2 extra file, which are /system/ppp and /system/init.d/01modules)
-You will need to delete old modules script, if present in the rom, in order to it to work correctly (complete contents listed below.. vvv)
Code:
Content of .clk.tar.gz are as follows (it unpacks to /system)
-.clk.tar.gz
-/system/ppp (so module script can find it and load proper module)
-/system/etc/ppp/
-resolv.conf
-ppp-gprs.pid
-pap-secrets
-options.smd
-options
-ip-up-vpn
-ip-up
-ip-down
-chap-secrets
-active
-/system/etc/init.d/
-97ppp
-02htcleo
-01modules
Boot files, you place both the /boot version and the boot.img version in a folder called /boot in the root of the rom
-/boot/initrd.gz
-/boot/zImage
-/boot.img
Last but not least, you will need to modify the updater-script (I avoided making an extra script to make the process cleaner)
In updater-script, you will need to remove the lines that flashes boot.img or copies boot to /boot partition and add this:
Code:
#decide clk or magldr
if -f /mnt/sdcard/clk.txt
then
#boot.img needed
ui_print("Writing Boot.img");
package_extract_file("boot/boot.img","/tmp/boot.img");
write_raw_image("/tmp/boot.img", "boot");
delete("/tmp/boot.img");
#ppp files also needed
run_program("/sbin/sh","-c",
concat("busybox gzip -dc ",
"/system/etc/.clk.tar.gz > ",
"/system/"));
else
#boot folder needed
if -f /mnt/sdcard/magldr.txt
then
ui_print("Writing Boot");
format("MTD", "boot");
mount("MTD", "boot", "/boot");
package_extract_dir("boot/boot","/boot");
unmount("/boot");
endif;
(might have left out [ ] somewhere.. please correct me if I did)
Credits:
-Tytung
-EZterry (find him in the G1 Section)
-Neopeek
To Do:
-Eliminate the process needed for the user to create a clk.txt or magldr.txt by using differences between clk/magldr..
Please review the scripting, report if you get any 'error 6' when flashing, and I am open to suggestions!
Below is attached the .clk.tar.gz (zipped in a folder because attachments won't allow me to upload tar.gz files... )
Click to expand...
Click to collapse
there are already a few ROMs that use similar approach (including mine):
the base ROm is for MAGLDR and there is easy patch to make that a cLK ROM - so for that there is small update package...so basically I need to develop one version and leave cLK patch unchanged (until there is kernel change in the ROM)...

e334 said:
Finding out that the only difference between a magldr and a clk rom is the format of /boot (initrd.gz/zImage vs Boot.IMG), files in /etc/ppp and some scripts in /etc/init.d, I've decided to try to combine everything all together so developers would not need to upload 2 seperate versions of a rom in order to suit both CLK and MagLDR users...
The basic principle is this:
-updater-script checks /mnt/sdcard for a file called "clk.txt" or "magldr.txt" (that is created by the user) and then if it find "clk.txt", it unpacks files needed for clk compatibility and flashes boot.img but if it finds "magldr.txt", it copies the /boot folder to the /boot partition and nothing else is changed (assuming the rom was built for magldr ONLY compatibility at first).
So extra files that will be needed for the rom to be both clk/magldr compatible would be as listed:
/system/etc/.clk.tar.gz
(Contents of .clk.tar.gz are basically the same as the CLK patch by tytung except with 2 extra file, which are /system/ppp and /system/init.d/01modules)
-You will need to delete old modules script, if present in the rom, in order to it to work correctly (complete contents listed below.. vvv)
Code:
Content of .clk.tar.gz are as follows (it unpacks to /system)
-.clk.tar.gz
-/system/ppp (so module script can find it and load proper module)
-/system/etc/ppp/
-resolv.conf
-ppp-gprs.pid
-pap-secrets
-options.smd
-options
-ip-up-vpn
-ip-up
-ip-down
-chap-secrets
-active
-/system/etc/init.d/
-97ppp
-02htcleo
-01modules
Boot files, you place both the /boot version and the boot.img version in a folder called /boot in the root of the rom
-/boot/initrd.gz
-/boot/zImage
-/boot.img
Last but not least, you will need to modify the updater-script (I avoided making an extra script to make the process cleaner)
In updater-script, you will need to remove the lines that flashes boot.img or copies boot to /boot partition and add this:
Code:
#decide clk or magldr
if -f /mnt/sdcard/clk.txt
then
#boot.img needed
ui_print("Writing Boot.img");
package_extract_file("boot/boot.img","/tmp/boot.img");
write_raw_image("/tmp/boot.img", "boot");
delete("/tmp/boot.img");
#ppp files also needed
run_program("/sbin/sh","-c",
concat("busybox gzip -dc ",
"/system/etc/.clk.tar.gz > ",
"/system/"));
else
#boot folder needed
if -f /mnt/sdcard/magldr.txt
then
ui_print("Writing Boot");
format("MTD", "boot");
mount("MTD", "boot", "/boot");
package_extract_dir("boot/boot","/boot");
unmount("/boot");
endif;
(might have left out [ ] somewhere.. please correct me if I did)
Credits:
-Tytung
-EZterry (find him in the G1 Section)
-Neopeek
To Do:
-Eliminate the process needed for the user to create a clk.txt or magldr.txt by using differences between clk/magldr..
Please review the scripting, report if you get any 'error 6' when flashing, and I am open to suggestions!
Below is attached the .clk.tar.gz (zipped in a folder because attachments won't allow me to upload tar.gz files... )
Click to expand...
Click to collapse
That is pointless IMHO, the commands you mentioned are linux shell commands mixed with recovery script which is of no use. As for single ROM issue, its been a long story short, any magldr rom can be run on clk using fastboot binary and some ppp files. hence what i would do is, supply a ppp conversion package for my rom including the cache remount script for CWM to work with clk. and since the user is using clk, he is knowledgeable enough on how to use fastboot (Even though commands are given on page of every such rom ie. AngelDeath's releases)

Oh, I guess that is the end of the "script" then. I did not know magldr supported raw type because of all the roms I've downloaded, it was either yaffs or had raw boot. Mods, please lock the thread out let it die..

ext4 extraction from system.sin issues

Hi,
As you probably know, ext4 image can be extracted from system.sin but cannot be mounted. When trying to mount it, it fails with :
[ 1476.821582] EXT4-fs (loop0): bad geometry: block count 262144 exceeds size of device (144631 blocks)
I open this thread just to share what I did around the issue and maybe have some helpful quotes about it
Here is what I did (under linux)
# First create an zero filled file. Size is system partition size (262144 blocks of 4096 each)
dd if=/dev/zero of=/home/xperia/virtualfs bs=4096 count=262144
# Attach file to loopback
sudo losetup /dev/loop0 /home/xperia/virtualfs
# Format it with same features as system partition on phone
sudo mkfs.ext4 -O has_journal,^ext_attr,^dir_index,^flex_bg,^huge_file,resize_inode,filetype,extent,sparse_super,large_file,^uninit_bg,^dir_nlink,^extra_isize -v /dev/loop0
# Write extracted system.sin.ext4 extracted image to loopback
sudo dd if=system.sin.ext4 of=/dev/loop0
# Mount filesystem
sudo mount /dev/loop0 /mnt
It can be mounted and I can have folder structure but I can't work with files. Editing default.prop gives me a non readable file.
But we can go a step ahead as we can now mount the image.
Still some issues have to be worked out.

The poit is, why we cant mount system.img on ICS but we can on GB?
maybe someone can contact with sony t oask
im extracting the .sin to .img like always but its impossible to mount.. what are you using to extract the .sin to a .ext4?
BTW, thanks for the info, i've been trying to modify system.img since ICS appeared.
EDIT: of, ext4 can be extracte with flashtool ~.~
maybe we need to read something from system.partinfo

Yakandu said:
The poit is, why we cant mount system.img on ICS but we can on GB?
maybe someone can contact with sony t oask
im extracting the .sin to .img like always but its impossible to mount.. what are you using to extract the .sin to a .ext4?
BTW, thanks for the info, i've been trying to modify system.img since ICS appeared.
EDIT: of, ext4 can be extracte with flashtool ~.~
maybe we need to read something from system.partinfo
Click to expand...
Click to collapse
Yes Flashtool can extract image from system.sin.
partinfo is partition information used by loader in flashmode to identify where to flash image on phone. (Something like start nand address of system partition)

so, any ideas why ext4 cant be mounted? maybe its encrypted or something..

Sorry for double post, i found a solution
Flash the system through a .ftf with flashtools
Flash a custom kernel with recovery (or the nozomi recovery)
Backup nandroid
We get a system.ext4.tar ··· move it to your developement folder
Create a folder (mkdir system)
Enter nautilus with root acces
Extract system files to the created folder
Modify whatever you want
Make a flashable system.img with: "./mkuserimg.sh -s /system ./system.img ext4 ./temp 1024M"
AND ITS WORKING!

Yakandu said:
Sorry for double post, i found a solution
Flash the system through a .ftf with flashtools
Flash a custom kernel with recovery (or the nozomi recovery)
Backup nandroid
We get a system.ext4.tar ··· move it to your developement folder
Create a folder (mkdir system)
Enter nautilus with root acces
Extract system files to the created folder
Modify whatever you want
Make a flashable system.img with: "./mkuserimg.sh -s /system ./system.img ext4 ./temp 1024M"
AND ITS WORKING!
Click to expand...
Click to collapse
This solution is already known
But my goal is to be able to mod a system partition without having to flash it before. And more, understand why extracted system image cannot be mounted and how to work this out

oh, ok xD
i didnt know that solution, its new for me

Yakandu said:
Sorry for double post, i found a solution
Flash the system through a .ftf with flashtools
Flash a custom kernel with recovery (or the nozomi recovery)
Backup nandroid
We get a system.ext4.tar ··· move it to your developement folder
Create a folder (mkdir system)
Enter nautilus with root acces
Extract system files to the created folder
Modify whatever you want
Make a flashable system.img with: "./mkuserimg.sh -s /system ./system.img ext4 ./temp 1024M"
AND ITS WORKING!
Click to expand...
Click to collapse
Have you already tried flashing this img on your device? I have already tried this solution twice but didn't succeed (@Spectre51 that's why I haven't replied your PM yet). system.img was succesfully created but I got boot loop when I flashed it on my device.

Hi Androxyde,
I figured it out, basically we have to dig further in sin format as new ext4 sins skips part of the file. See my thread for more details.
PS: Thanks for flashtool, it's a great tool!
LeTama

letama said:
Hi Androxyde,
I figured it out, basically we have to dig further in sin format as new ext4 sins skips part of the file. See my thread for more details.
PS: Thanks for flashtool, it's a great tool!
LeTama
Click to expand...
Click to collapse
:good:

[Recovery][Script] TWRP and CWM recoveries for ANY custom ROM

For now, you can use Recovery-in-FOTA images! It is better solution, but if it doesn't work for you, you can still use this script.
I am proud to present you recovery script for installing TWRP or CWM recovery on any custom ROM.
Usage:
Download zip with prefered recovery, place it to your sd-card or to internal memory and flash it via your current recovery. Yes, it is very simple. Note: if you want to install it on CM12, which comes with CM recovery, flash it right after flashing ROM or kernel (if kernel doesn't contain working recovery).
Everything is doing on your own risk, so i am not responsible if your device gets bricked or if your cat gets pregnant.
How it works?
Package contains recovery ramdisk, binaries for unpacking and repacking boot image and shell script. Script copies you current boot image (boot.img), runs binary for unpacking it, extracts files from ramdisk, replaces recovery-ramdisk.cpio (which is you recovery) with one in zip, then script packs ramdisk and boot image with already replaced file and flashes new boot.
Thanks to:
@FindYanot for helping with script and linux commands (half of work is done by him)
@Noel Macwan for base for this script (I used his script and binaries for replacing zImage as base for mine, you can find his works here)
@JustArchi for compiling TWRP 2.8.3.0 for our device in ArchiDroid 3.0.1.1
So, the choice is yours.

Download
Download it now and use whenever you want.
PhilZ zip is broken and it recovery is too buggy on new kernels, so don't download it. Choose TWRP or CWM, they work good.
Download from ftp >>>

Reserved

CWM works
I tested CWM script on last fxp build CM12 ROM, it works

PhilZ recovery availabe now!
Download
Choose PhilZ-recovery.zip

FindYanot said:
PhilZ recovery availabe now!
Download
Choose PhilZ-recovery.zip
Click to expand...
Click to collapse
PhilZ is broken, CWM and TWRP worked. log in attachment

Remorcer said:
PhilZ is broken, CWM and TWRP worked. log in attachment
Click to expand...
Click to collapse
I'll try to fix it soon, thanks for report and logcat.

I fixed PhilZ zip, but recovery by itself has screen split bug, so I didn't upload fixed version, we'll remove it until someone fixes it.

How do i install it?

strianugraha said:
How do i install it?
Click to expand...
Click to collapse
Flash via recovery.

sd-ext support in twrp
I know you can access sd-ext card via terminal command or via adb but no problem to add it to GUI
Here is change to ramdisk-recovery.cpio for sd-ext support in twrp:
Code:
--- etc/twrp.fstab.old
+++ etc/twrp.fstab
@@ -6,3 +6,4 @@
/data ext4 /dev/block/platform/msm_sdcc.1/by-name/userdata length=-16384
/external_sd vfat /dev/block/mmcblk1p1 /dev/block/mmcblk1 flags=display="Micro SDcard";storage;wipeingui;removable
/usb-otg vfat /dev/block/sda1 /dev/block/sda flags=display="USB OTG";storage;wipeingui;removable
+/sd-ext auto /dev/block/mmcblk1p2 flags=display="SD-Ext";storage;wipeingui;removable

Does it work on sony Xperia z3 operating cm12?

LeonidasTurk said:
Does it work on sony Xperia z3 operating cm12?
Click to expand...
Click to collapse
I replied you in private messages, just give me boot.img's with CWM and TWRP recoveries from any custom (not based on stock) ROM.

hi guys.i downloading both recovery but after i want install in recovery of cm, error and say E/: can not install.how to install this recovery on beta3 cm12?

xp7 said:
hi guys.i downloading both recovery but after i want install in recovery of cm, error and say E/: can not install.how to install this recovery on beta3 cm12?
Click to expand...
Click to collapse
CM Recovery doesn't flash zip's, use repacked kernel. BTW, I will post recovery-in-FOTA images soon (it is strange that no one made these for our device). It is better then recovery-in-boot images, because it stays untouched after kernel flashing.

jkkk88 said:
I know you can access sd-ext card via terminal command or via adb but no problem to add it to GUI
Here is change to ramdisk-recovery.cpio for sd-ext support in twrp:
Code:
--- etc/twrp.fstab.old
+++ etc/twrp.fstab
@@ -6,3 +6,4 @@
/data ext4 /dev/block/platform/msm_sdcc.1/by-name/userdata length=-16384
/external_sd vfat /dev/block/mmcblk1p1 /dev/block/mmcblk1 flags=display="Micro SDcard";storage;wipeingui;removable
/usb-otg vfat /dev/block/sda1 /dev/block/sda flags=display="USB OTG";storage;wipeingui;removable
+/sd-ext auto /dev/block/mmcblk1p2 flags=display="SD-Ext";storage;wipeingui;removable
Click to expand...
Click to collapse
I will look for this if will have enough time.

2All
There is some better solution than this script. Read this thread for more info.

cucumber09 said:
I will look for this if will have enough time.
Click to expand...
Click to collapse
Here you have it for CWM.
Code:
--- etc/recovery.fstab.old
+++ etc/recovery.fstab
@@ -10,6 +10,7 @@
/dev/block/platform/msm_sdcc.1/by-name/system /system ext4 ro,barrier=1 wait
/dev/block/platform/msm_sdcc.1/by-name/userdata /data ext4 nosuid,nodev,barrier=1,noauto_da_alloc wait,check,en
/dev/block/platform/msm_sdcc.1/by-name/cache /cache ext4 nosuid,nodev,barrier=1 wait,c
+/dev/block/mmcblk1p2 /sd-ext auto defaults recoveryonly
/devices/platform/msm_sdcc.3/mmc_host/mmc1 auto auto defaults wait,voldmanaged=sdcard1:auto
And illustration for twrp...

What is difference b/w ur threads script and fota man?

imdkiller said:
What is difference b/w ur threads script and fota man?
Click to expand...
Click to collapse
Script repacks your kernel with new recovery. You need to flash it after every update. Recovery-FOTA replaces your FOTAKernel image without touching your kernel, so you need to flash it just once.

Oreo: fstab.qcom in ramdisk

After extracting the ramdisk from the stock boot image of OSS5.0 / Android O 8.0 for Oneplus3, I noticed that fstab.qcom file is no longer there in the ramdisk. Until OSS4.5.1 / Android N 7.1 this file was present and could be edited to set the flag for data partition to encryptable and to also remove the verity flag ...both of which I found to be very useful.
Appreciate if someone can please help me understand what has changed in the Android O 8.0 and what would be the method to achieve the above?

Looking at https://forum.xda-developers.com/oneplus-3t/how-to/disable-dm-verity-force-encryption-op3t-t3688748 and https://forum.xda-developers.com/attachment.php?attachmentid=4302571&d=1507993390, it appears that the fstab.qcom file has moved to /system/vendor/etc/fstab.qcom in Oreo in keeping with Android O / 8.0 specifications. Changing that file means modifying the system partition, which I don't mind as I like to modify the hosts file as the barest minimum change even in my daily use device. But still wondering if the same can be achieved by Magisk and how. Appreciate if someone can help me understand this.

Today's learning:
1. Android O kernel specifications include early mounting of some partitions and Oneplus 3 specifies the system partition in its device tree blobs (dtb).
2. These dtb are part of (...appended to) the real kernel image and not on a separate partition / blob.
3. There are 13 dtb appended to Oneplus 3 kernel and each of them has an entry relevant to fstab which mounts system with the verify flag.
4. Again, in keeping with Android O specifications, fstab.qcom (...now located in the /vendor/etc/ directory) does not include a line for the system partition (...commented out) as mounting the system partition is already taken care of through the dtb in the kernel.
5. That means system modifications cannot be done until the dtb are cleaned of verify flag .... or perhaps the whole of the code mounting the system partition in dtb is deleted and then fstab.qcom is restored in the ramdisk.
Haven't yet tried this and it will be helpful if someone more knowledgeable can confirm that these are the steps to be done to modify the system partition.

@rk2612 great findings and write up!
Just saw your post at magisk beta thread. I'm facing same problem on xperia device with Oreo, and I think we need to change the flag as you stated there.
I've already tried flashing magisk, but dm-verity is still being triggered and phone falls in a bootloop after it reboots.
I'd like to try this method out on my xperia, but I don't know how to convert dtb into dts, and vice versa. Any help on this would be great! Thanks in advance!!

serajr said:
@rk2612...
I've already tried flashing magisk, but dm-verity is still being triggered and phone falls in a bootloop after it reboots.
I'd like to try this method out on my xperia, but I don't know how to convert dtb into dts, and vice versa. ...
Click to expand...
Click to collapse
Have you tried patching with Magisk Beta v1456? That seems to take care of the verity flag in the dtb of OnePlus 3.
On Ubuntu, you can install dtc (device tree compiler ...Refer http://manpages.ubuntu.com/manpages/xenial/man1/dtc.1.html ) to handle conversion from dtb to dts or vice versa.

rk2612 said:
Have you tried patching with Magisk Beta v1456? That seems to take care of the verity flag in the dtb of OnePlus 3.
On Ubuntu, you can install dtc (device tree compiler ...Refer http://manpages.ubuntu.com/manpages/xenial/man1/dtc.1.html ) to handle conversion from dtb to dts or vice versa.
Click to expand...
Click to collapse
Thank you bro!
Yes, I had, latest beta v1456!
Gonna try it out and report back here later!!

serajr said:
...
I'd like to try this method out on my xperia, ....
Click to expand...
Click to collapse
serajr said:
Thank you bro!
Yes, I had, latest beta v1456!
Gonna try it out and report back here later!!
Click to expand...
Click to collapse
According to https://github.com/topjohnwu/Magisk/blob/master/scripts/boot_patch.sh (...line 93 onwards) Sony devices may not be handled well by Magisk.

rk2612 said:
According to https://github.com/topjohnwu/Magisk/blob/master/scripts/boot_patch.sh (...line 93 onwards) Sony devices may not be handled well by Magisk.
Click to expand...
Click to collapse
Bro, this is an known issue for all xperia users. Always before we flash magisk (os SuperSU), we do need to convert xperia stock kernel (elf format) to boot.img (aosp format), and fastboot it!
And for the records, this is exactly what I've found with dtc:
Code:
firmware {
android {
compatible = "android,firmware";
fstab {
compatible = "android,fstab";
vendor {
compatible = "android,vendor";
dev = "/dev/block/platform/soc/7464900.sdhci/by-name/vendor";
type = "ext4";
mnt_flags = "ro,barrier=1,discard";
fsmgr_flags = "wait";
status = "disabled";
};
system {
compatible = "android,system";
dev = "/dev/block/platform/soc/7464900.sdhci/by-name/system";
type = "ext4";
mnt_flags = "ro,barrier=1,discard";
fsmgr_flags = "wait[B][COLOR="Red"],verify[/COLOR][/B]";
status = "ok";
};
};
};
};
Removed ,verify and conveted back to dtb. Gonna test it out (report you back later)!
Thank you!

i have a one plus 5T and i dont see an DTB files in the boot.img
can someone post a walk through on how to do this manually without magisk or supersu?
i know i can modify the fstab in system/vendor/etc
but what are the dtb files exactly? and where are they located / how are they extracted?

virtyx said:
i have a one plus 5T and i dont see an DTB files in the boot.img
can someone post a walk through on how to do this manually without magisk or supersu?
i know i can modify the fstab in system/vendor/etc
but what are the dtb files exactly? and where are they located / how are they extracted?
Click to expand...
Click to collapse
DTB are Device Tree Blobs / Binary and not files. These are appended to the kernel in the boot.img.
On Ubuntu, you can install dtc (device tree compiler ...Refer http://manpages.ubuntu.com/manpages/...an1/dtc.1.html ) to handle conversion from dtb to dts or vice versa.
You can also hex edit the boot.img and delete the text ",verify" at each instance it is found. Or use Linux command line to do that if you're familiar with that.
Sorry, don't have the spare time right now to write a detailed walk through. Maybe this weekend.

rk2612 said:
DTB are Device Tree Blobs / Binary and not files. These are appended to the kernel in the boot.img.
On Ubuntu, you can install dtc (device tree compiler ...Refer http://manpages.ubuntu.com/manpages/...an1/dtc.1.html ) to handle conversion from dtb to dts or vice versa.
You can also hex edit the boot.img and delete the text ",verify" at each instance it is found. Or use Linux command line to do that if you're familiar with that.
Sorry, don't have the spare time right now to write a detailed walk through. Maybe this weekend.
Click to expand...
Click to collapse
thank you
is it possible to extracat the DTB files on a windows machine?
i know after OS install the fstab is located at /system/etc/vendor which we can edit before first boot
but id prefer to edit the DTB files in the boot, and add mounting flags for each partition.

virtyx said:
thank you
is it possible to extracat the DTB files on a windows machine?
i know after OS install the fstab is located at /system/etc/vendor which we can edit before first boot
but id prefer to edit the DTB files in the boot, and add mounting flags for each partition.
Click to expand...
Click to collapse
I didn't look around for a windows tool to extract DTBs.
In Oreo, fstab file contains the mount points for all other partitions except /system and you can edit the fstab file as in previous android versions. The only partition which is mounted early through the DTBs is /system and you will see that the /system mount entry in fstab is commented out as that is not needed.
To mount /system with verity disabled, you will need to remove the flag "verify" from the DTBs. I'm attaching a text version of one of the 13 DTBs contained in OnePlus 3's boot image as an example. You will notice the following code
Code:
fsmgr_flags = "wait,verify"
...and you need to remove ",verify" to make it
Code:
fsmgr_flags = "wait"
To remove ",verify" from the DTBs, you can either:
1. Hex edit the boot image but this will leave the verity key in the ramdisk (...may work but I haven't tried).
2. (a) Unpack the boot image; (b) hex edit the kernel (to which dtbs are appended) and remove ",verify"; (c) extract ramdisk and remove verity.key; (d) repack ramdisk; and (e) repack the boot image: should work
3. (a) Unpack the boot image, (b) extract the dtb appended to kernel / zImage; (c) convert the dtb to dts (text format); (d) text edit the dts to remove ",verify"; (e) then reconvert dts to dtb; (f) append all the modified dtbs to the kernel; and finally (g) repack the boot image (...also remove the verity.key from the ramdisk before repacking the boot image): this would be the cleanest approach but more cumbersome.
Tools needed on Ubuntu machine with Python installed:
1. Unpack and repack boot image: use unpackbootimg and mkbootimg scripts (Python) from lineageos code: https://github.com/LineageOS/android_system_core/tree/cm-14.1/mkbootimg
2. Extract kernel and dtbs using python script: https://github.com/PabloCastellano/extract-dtb
3. Convert dtb to dts and back: use Ubuntu package dtc: http://manpages.ubuntu.com/manpages/xenial/man1/dtc.1.html

rk2612 said:
I didn't look around for a windows tool to extract DTBs.
In Oreo, fstab file contains the mount points for all other partitions except /system and you can edit the fstab file as in previous android versions. The only partition which is mounted early through the DTBs is /system and you will see that the /system mount entry in fstab is commented out as that is not needed.
To mount /system with verity disabled, you will need to remove the flag "verify" from the DTBs. I'm attaching a text version of one of the 13 DTBs contained in OnePlus 3's boot image as an example. You will notice the following code
Code:
fsmgr_flags = "wait,verify"
...and you need to remove ",verify" to make it
Code:
fsmgr_flags = "wait"
To remove ",verify" from the DTBs, you can either:
1. Hex edit the boot image but this will leave the verity key in the ramdisk (...may work but I haven't tried).
2. (a) Unpack the boot image; (b) hex edit the kernel (to which dtbs are appended) and remove ",verify"; (c) extract ramdisk and remove verity.key; (d) repack ramdisk; and (e) repack the boot image: should work
3. (a) Unpack the boot image, (b) extract the dtb appended to kernel / zImage; (c) convert the dtb to dts (text format); (d) text edit the dts to remove ",verify"; (e) then reconvert dts to dtb; (f) append all the modified dtbs to the kernel; and finally (g) repack the boot image (...also remove the verity.key from the ramdisk before repacking the boot image): this would be the cleanest approach but more cumbersome.
Tools needed on Ubuntu machine with Python installed:
1. Unpack and repack boot image: use unpackbootimg and mkbootimg scripts (Python) from lineageos code: https://github.com/LineageOS/android_system_core/tree/cm-14.1/mkbootimg
2. Extract kernel and dtbs using python script: https://github.com/PabloCastellano/extract-dtb
3. Convert dtb to dts and back: use Ubuntu package dtc: http://manpages.ubuntu.com/manpages/xenial/man1/dtc.1.html
Click to expand...
Click to collapse
ah i see
i guess i should really dual boot this machine haha
i found the mounting options in hex editor for the boot.img (/system and /vendor, i think 13 instances of both)
also the verity.key can be delete when unpacking the boot.img and repacking it with no verity.key.
thank you, i think im able to modify it on a windows machine, ill try it out as soon as a stable oreo comes out for the 1+5T

I already have the dtb edited. how can I add them back to the zImage or the boot.img?
Thank you very much

kenet said:
I already have the dtb edited. how can I add them back to the zImage or the boot.img?
Thank you very much
Click to expand...
Click to collapse
Actually the appending should be done like
Code:
cat zImage [I][U]<DTB_FILE_NAME>[/U][/I].dtb > zImage-dtb
So you can get a zImage with dtb