[CLOSED][SCRIPT][LINUX] Mount System as read write (Android 10+)

[lebigmac]

Tried it on my Oneplus 7T Pro with Android 10. It extracted the superimage but failed at writing it back. It returned this error:

error: file_write: write: No space left on device
lpmake E 03-02 21:41:55 76867 76867 images.cpp:468] [liblp]sparse_file_write failed with code: -1
lpmake E 03-02 21:41:55 76867 76867 images.cpp:326] [liblp]Could not open image for partition: product_a

makesysrw: Error! failed to create super_fixed.img file./makesysrw.sh super_image.img  14.21s user 37.28s system 51% cpu 1:40.46 total

Any ideas? Thank you for your great work!

I haven't seen this error before. The good news is you almost reached the very end of the script.
To me it almost looks like your hard drive is full so the lpmake command is throwing an error.
Were all partitions successfully extracted from your super image? It's complaining that it can't find product_a partition.
This definitely needs further investigation...

 

[alecxs]

have modified dumpFile() a little to make script faster and save space on userdata

 

[lebigmac]

have modified dumpFile() a little to make script faster and save space on userdata

lol that's quite the extensive modification compared to the original...
You even changed the version number to 1.02 ! How thoughtful.
Hey if it works for you I'm happy for you
Please keep in mind the new universal version is already in the works that's also going to be compatible with Windows and Mac users.
Alecxs I appreciate your effort but don't waste your time on modding the old version. Come join me and help me create the new version so all Android users (not only the Linux users) can enjoy a system that's read-write-able.

I do agree however that the process of dumping the original super to the computer is a little bit more time consuming than necessary. This is not due to a limitation of the script but rather an Android permission limitation...
You can't adb pull the original super file directly off the phone because if you try it on a stock phone you will get the 'adb cannot run as root on production builds' or 'permission denied' error and therefore the script must first copy the file to internal /sdcard before being able to pull it to the computer.
This is already fixed in the next upcoming version.

 

[uvzen]

The script does't detect root even though I have it.
Device: Xiaomi Redmi Note 9 Pro joyeuse Android 10

 

[lebigmac]

The script does't detect root even though I have it.
Device: Xiaomi Redmi Note 9 Pro joyeuse Android 10

What's the result if you type this in your terminal:

adb shell which su

 

[uvzen]

What's the result if you type this in your terminal:

adb shell which su

 

[uvzen]

In the makesysrw.sh bash script at the very end inside the checkPhoneState() function you can try to skip the root check and force inititate the procedure anyway by replacing this block of text:

        if ( adb shell "which su"&>/dev/null );then
            printf "$app: Root detected. Initiating procedure...\n\n"
            mainProc
        else
            printf "$app: Error! Root NOT detected. Abort\n"
            exit
        fi

simply with this:

        mainProc

I will check it later and let you know because I can't now.

 

[alecxs]

have seen you made a lot of advertising for this. i recommend to ask @munjeni for hosting precompiled binaries under releases tag, so we can always wget/bitsadmin binary depending on host arch, instead of bundling binaries without distributing source code...

also other binaries like simg2img should be installed via package manager if possible, for example on darwin/debian/fedora it is available

brew install -y simg2img
apt-get install -y android-tools-fsutils
yum --disablerepo=updates* install -y android-tools

 

[lebigmac]

@Alecxs. The reason why I made lots of comments about this method is to bring more attention to this technique. My intention was not to spam the forum.
And no I did not invent this method I only found it hidden deep inside the forum after a very long time of searching. It was very well hidden or I just don't know how to navigate the new forum software yet.
I had to go even as far as learning hex editing before finally out of the blue I discovered those threads that helped me to create this script.

I just wanted to automate the entire process and make this method available to a wider audience so everyone can enjoy a system that's read-write-able. That's all. If such a script were available back in February it would've saved me lots of trouble and time.
If anything all credits should go to @Brepro1 , @AndyYan and @gabrielfrias also @munjeni for his nice superunpack tool.
My script is basically a carbon copy of the excellent Brepro1 / AndyYan tutorial (links in post #1)

Yes I agree releasing those precompiled binaries in the /tools folder without including the source code is not optimal. I might include a /source folder in the next version. Thanks for the idea.

 

[lebigmac]

I will check it later and let you know because I can't now.

If you look closely at this screenshot you will see what the problem is.
You don't have the adb program in your $PATH environment variable.
So in order to fix this you must add your adb and fastboot to your $PATH environment variable.
That should fix your issue. Good luck!

 

[alecxs]

no need to bundle source code, just links is already sufficient. unfortunately didn't find any useful download source or packages providing Dynamic Partition Tools, leaving you no choice to bundle binaries

edit: found lpunpack at least for linux
https://github.com/AndroidDumps

 

[lebigmac]

@Alecxs there's this:
https://android.googlesource.com/platform/system/extras/+/master/partition_tools/

 

[zgfg]

By putting to GitHub, the source code, changes, (tagged) releases, everything will be easily available and managable, with the possibility for other developers to contribute (branches, pull, merge)

 

[alecxs]

@zgfg maybe you provide build-bot for binaries cross-platform

 

[alecxs]

Still waiting for somebody with lots of experience in compiling AOSP for Android to contact me to collaborate on the upcoming version. Thanks!

what's the purpose of this? do you want to compile binaries for aarch64 and provide flashable zip?

 

[lebigmac]

what's the purpose of this? do you want to compile binaries for aarch64 and provide flashable zip?

You must admit that does sound good doesn't it? Anything to simplify the process and make our lives easier.
Unfortunately due to my limited compiling knowledge and limited resources I've hit a roadblock so I'm waiting for somebody with more compiling experience to contact me. Any volunteers?

The script in its current state and form works great for Linux users but I'm just sad for all the Windows and Mac users who are missing out on a system that's read-write-able and all the endless device customization possibilities that brings with it.

 

[alecxs]

that was also my plan before i read your thread. ask here

 

[lebigmac]

Thanks @Alecxs.
In your modification of the dumpFile function of the script why do you replace the dd command with this?

'cat $superPath 2> /dev/null' > $newPath

Does that pretty much do the same thing as dd ? Is it faster than dd ? Thanks for clarifying.
I always thought dd was the way to dump a file from the phone. It would've never occurred to me to use the cat function for this purpose. I thought that was more for reading text files and stuff.

 

[ronlkh1965]

Hi any idea what is my problem?

partition_3_name = system
attributes = 0x1
first_extent_index = 0x2
num_extents = 0x1
group_index = 0x1
partition_group = qti_dynamic_partitions
extent num_sectors = 0x6c5718 (0xd8ae3000 bytes total)
extent target_type = 0x0
extent target_data = 0x4bf800 (dumping offset = 0x97f00000)
extent target_source = 0x0
Filetype EXT4. EXT4 size = 0xd8ae3000
Dumping system.ext4 ...
....................................................
........................................Error writing 512 bytes!
makesysrw: Please make sure the file exists and try again.

 

[lebigmac]

Hi any idea what is my problem?

partition_3_name = system
attributes = 0x1
first_extent_index = 0x2
num_extents = 0x1
group_index = 0x1
partition_group = qti_dynamic_partitions
extent num_sectors = 0x6c5718 (0xd8ae3000 bytes total)
extent target_type = 0x0
extent target_data = 0x4bf800 (dumping offset = 0x97f00000)
extent target_source = 0x0
Filetype EXT4. EXT4 size = 0xd8ae3000
Dumping system.ext4 ...
....................................................
........................................Error writing 512 bytes!
makesysrw: Please make sure the file exists and try again.

Now that's a new one. Never seen this error before. Your error is happening while the superunpack tool is running. What's happening before partition_3_name = system?
Does the superunpack tool successfully extract the other 2 partitions from your super_original.img file ? vendor.ext4 and product.ext4 ? So it failed at system.ext4 right?

If the super_original.img file was successfully dumped to your computer you could try to run this command manually and post the results here. Thanks

./tools/superunpack super_original.img