Related
Sorry for my English! I want to create an image
custom of /system (system.img)to use it and
test with the emulator. To do this I proceeded to:
1) Start Emulator with 128 MB partition size
2) mount / systen write option with mount-o rw, remount-t yaffs2 / dev/block/mtdblock3 /system and chmod 777 /system
3) adb push mkfs.yaffs2.arm in /system
4) go comand mkfs.yaffs2 /system system.img
5) adb pull system.img
6) why system.img is small (44MB?)
7) replace system.img in folder on Platform sdk
8) emulator not run ...
9) why not run ? (stop on test Android_ )
Hi,
I am using make_ext4fs(from system/extra/ext4_utils) to make system.img on host machine and burn this image to pre-built eMMC partition.
The options I used for make_ext4fs is,
make_ext4fs -l 300M -a system system.img /system
I tried with -s option and it just could not be mounted. Anyhow, without -s it mounts ok, but the problem is the file permission gets all screwed up. Before the image was built, the original system folder had files with 777, but after image was built and mounted, all the files are 744. I doubt this has to do with -s option but I am no expert. Does anyone have similar experience like this or know how to fix this permission issue?
Thanks
Search before you post
See
http://forum.xda-developers.com/showthread.php?t=953461
Does anybody know how to generate those fs_config and file_context files for each sub-partition of super.img for the make_ext4fs binary to function properly? Thank you!
So, I read somewhere that what you've thought, might already have been thought by someone else. Dual-Booting the pico, as most people now know it, isn't something new to this device. When I had made this thread here, most of you might have noticed the init.rc tweak in the post 2. The day before I had written the post, I was experimenting with the possibilities of dual booting my phone, and was successfully able to. How? By changing the mount points, simple.
Now, the problem arises... How many boot.img's do you have to derp? And, how many times would you have to keep flashing your boot partition??? So, I figured out something, which I will be discussing in this thread, which allows you to boot any and any ROM if they both use the same kernel. Therefore, you don't have to flash separate boot.img's everytime you need to change between your primary ROM and secondary ROM.
There is a small change in terminologies:
Primary ROM: The ROM in the internal partition of your device. The name itself is pretty explanatory.
Secondary ROM: The ROM on your SD-Card, secondary, as in second or something like that.
Click to expand...
Click to collapse
So, how will this help me?
No need to repeatedly flash your boot partition (though it ain't gonna cause any damage).
Easier switching of ROMs.
Doesn't need SU (super user) permissions.
So, all talk no show?
Code:
You seem to be the typical TDLR; case :laugh:
Again, sorry to interrupt you, but there are a few things you'd need to know. First and foremost, this:
Code:
#include
/*
* Your warranty is/was void the time you chose to unlock your bootloader.
*
* I am not responsible for bricked devices, dead SD cards,
* thermonuclear war, or you getting fired because the alarm app failed. Please
* do some research if you have any concerns about how this works!
* YOU are choosing to make these modifications, and if you point
* the finger at me for messing up your device, I will laugh at you.
*
*/
Note: If this is to work with Sense 4.0/4.1; or with the new PLL2 OC'ing method, appropriate changes will have to be made, which I would be discussing in later posts. As of now, this method works with all AOSP and derived ROMs, excluding Sense, and those with PLL2 OC'ing.
How it works:
So, this is what most people want to know! Here's how. :angel:
When the device boots, the init.rc is run, if I remember correctly. Here lies the trick. What I planned to do was creating a place_holder in the SD-Card, use it as a, well, place_holder, and execute <insert-awesome-script-name.sh at bootup, which is bootsdcard.sh in this case.
When is bootsdcard.sh run?
After the internal /system, /data, and /cache partitions are mounted.
Click to expand...
Click to collapse
What bootsdcard.sh does?
It basically is an if/else command. If exist /sdcard/place_holder, which is /sdcard/.bootsdcard, in this case, BTW, it unmounts the /system, /data, and /cache partitions, and mounts the partitions on the sdcard in the /system, /data, and /cache folder.
Click to expand...
Click to collapse
So, how to do that?
Here's where I was confused. Checking for file existence, in init.rc? Then, I remembered that some init.d scripts run the same way. Searched the init.rc for /etc/init.d, in vain. Finally, found this thread, and opened up the ROM's zip. There was indeed a file named [Isysinit[/I] in /system/bin/sysinit, and it contained commands to run the files in /system/etc/init.d. What's more important is that the exec commands could be executed using exec /something After hours of searching, I found this: http://forum.xda-developers.com/showthread.php?t=1598803&highlight=dual+boot. Cool! The Samsung Galaxy Y has had dual boot before pico, thanks to irfanbagus. Still, it had a lot of bloat, and couldn't be used directly for our device. So, I saw how it worked, and, it was efficient. So, I decided to port it to our device.
Prerequisites:
Patience ~ Learn it, if you don't have it!
Two ROMs that boot with the same kernel
Linux or Notepad++
file-roller or WinRAR
partitioned sdcard, in the order: fat32>sd-data>sd-system>sd-cache
Procedure:
1. Preparing the ROMs
Get any two ROMs' zip files, which run with the same kernel. Decide which ROM you want as secondary, i.e. in the SD-Card. Now, open up the zip of the ROM which you want in the SD-Card and extract the updater-script from its META-INF/com/google/android/ folder and make the following changes:
Delete these lines:
Code:
format("yaffs2", "MTD", "system", "0", "/system");
mount("yaffs2", "MTD", "system", "/system");
Insert these lines:
Code:
run_program("/sbin/busybox", "mount", "-t", "auto", "/dev/block/mmcblk0p3", "/system");
run_program("/sbin/busybox", "rm", "-rf", "/system/*");
If you feel you aren't doing it correct, please post the updater script of the ROM here. I will edit it.
Drag and drop the changed updater script into the same /META-INF/com/google/android folder. Hopefully, it should be updated within the zip.
Copy these two files to your SD-Card using *any* means possible.
2. Flashing the ROMs
Open recovery, and flash the zip for primary ROM.
Reboot recovery.
Go to Mounts and storage (CWM) or under a similar option, and unmount /data, /cache and /system.
Now, flash the zip you've created for secondary ROM.
If you reboot, you should go into the Primary ROM.
3. Installing modified kernel
You can do this using fastboot too!
Download appropriate pre-derped kernels, or provide the boot.img for derping.
Then, it is pretty simple.
Code:
fastboot flash boot <derped-boot>.img
or via Terminal Emulator
Code:
su
flash_image boot /sdcard/<derped-boot>.img
4. Switching ROMs
Primary ROM to Secondary ROM:
As I said, the place holder. It plays an important role. So, if you want to switch to another ROM, just create an empty file in your sdcard named ".bootsdcard" without quotes. You could also do this via terminal emulator using:
Code:
touch /sdcard/.bootsdcard
Secondary ROM to Primary ROM:
Remove the .bootsdcard from your SD-Card, and you will boot the primary ROM. This can also be done using terminal emulator using:
Code:
rm /sdcard/.bootsdcard
P.S. An application for this is being developed by @omerjerk, to make this easier.
Anything else?
Nothing for now Dual booting my phone with CM9 and MiniCM9.
XDA:DevDB Information
Dual Boot ~ the Yin-Yang way!, a Tool/Utility for the HTC Pico (Explorer)
Contributors
thewisenerd
Version Information
Status: Stable
Created 2013-11-16
Last Updated 2013-11-16
Editing the kernel
Procedure
You MUST know how to unpack/repack kernels, and their ramdisks.
If you unpack your kernel, you would find the folder named sbin where you'd unpacked the ramdisk. Place these two files View attachment busybox.7z and View attachment bootsdcard.txt in the folder. Rename them to "busybox" and "bootsdcard.sh" respectively.
Additionally, you will need to create a folder named "tmp" where you've unpacked the ramdisk.
Now, open up init.rc and find the lines:
Code:
on fs
# mount mtd partitions
# Mount /system rw first to give the filesystem a chance to save a checkpoint
mount yaffs2 [email protected] /system
mount yaffs2 [email protected] /system ro remount
mount yaffs2 [email protected] /data nosuid nodev
mount yaffs2 [email protected] /cache nosuid nodev
After these lines, you are most likely to find these lines (or similar lines):
Code:
# once everything is setup, no need to modify /
mount rootfs rootfs / ro remount
Add the following lines to the above:
Code:
chmod 0777 /sbin/busybox
chmod 0777 /sbin/bootsdcard.sh
exec /sbin/busybox sh /sbin/bootsdcard.sh
En total, it should look like this:
on fs
# mount mtd partitions
# Mount /system rw first to give the filesystem a chance to save a checkpoint
mount yaffs2 [email protected] /system
mount yaffs2 [email protected] /system ro remount
mount yaffs2 [email protected] /data nosuid nodev
mount yaffs2 [email protected] /cache nosuid nodev
on post-fs
chmod 0777 /sbin/busybox
chmod 0777 /sbin/bootsdcard.sh
exec /sbin/busybox sh /sbin/bootsdcard.sh
# once everything is setup, no need to modify /
mount rootfs rootfs / ro remount
Click to expand...
Click to collapse
Now, you can repack the ramdisk, and repack the kernel. In most cases, you should be able to flash the kernel with the busybox included. If you are not able to flash the repacked boot.img, please post the boot.img along with thread from which obtained/sources.
P.S. For the curious, this is what bootsdcard.sh looks like:
Code:
#!/sbin/busybox sh
MOUNT="/sbin/busybox mount"
UMOUNT="/sbin/busybox umount"
MKDIR="/sbin/busybox mkdir"
RMDIR="/sbin/busybox rmdir"
TOUCH="/sbin/busybox touch"
$MKDIR /tmp/sdcard
$CHMOD 0770 /dev/block/mmcblk0p1
$MOUNT /dev/block/mmcblk0p1 /tmp/sdcard
if [ -f /tmp/sdcard/.bootsdcard ];
then
$TOUCH /tmp/.bootsdcard
fi
$UMOUNT /tmp/sdcard
$RMDIR /tmp/sdcard
if [ -f /tmp/.bootsdcard ];
then
$UMOUNT /data;
$CHMOD 0770 /dev/block/mmcblk0p2
$MOUNT -t ext3 -o nosuid,nodev /dev/block/mmcblk0p2 /data
$UMOUNT /system
$CHMOD 0770 /dev/block/mmcblk0p3
$MOUNT -t ext3 /dev/block/mmcblk0p3 /system
$MOUNT -t ext3 -o remount,ro /dev/block/mmcblk0p3 /system
$UMOUNT /cache
$CHMOD 0770 /dev/block/mmcblk0p4
$MOUNT -t ext3 /dev/block/mmcblk0p4 /cache
fi
Downloads
CM9 Build 9's boot.img: http://www.mediafire.com/download/bn2krcdgdehpkij/boot.img
Adding support for G-Apps
You'd also need G-Apps for your secondary ROM. Here's how-to:
Open up any G-Apps zip, and extract updater-script from META-INF/com/google/android folder.
Find the following line:
Code:
run_program("/sbin/busybox", "mount", "/system");
Replace it with:
Code:
run_program("/sbin/busybox", "mount", "-t", "auto", "/dev/block/mmcblk0p3", "/system");
That's it! You can flash your modified g-apps for secondary ROM.
Reserved
In case the boot.img doesn't flash after re-packing, it is very likely that there isn't enough space in the boot partition. I will add the procedure, for that case too.
finished post, reviews welcome
another one , good work bro :good:
is it possible to dual boot Thinkingbridge and stock ??
how about memory scripts ? will it work on both primary and secondary roms !!!
legendlee said:
another one , good work bro :good:
is it possible to dual boot Thinkingbridge and stock ??
how about memory scripts ? will it work on both primary and secondary roms !!!
Click to expand...
Click to collapse
Not possible by the Yin-Yang. One prerequisite is that both the ROMs should use the same kernel.
You could try the other method by ayushrox, which involves using separate boot.img's with different mountpoints.
Memory increasing scripts? That's easy, but you'd need four ext3 partitions, and a modified int2ext. Procedure:
format sdcard in following layout:
fat32>sd-data>sd-system>sd-cache>sd-ext.
Open the memory script int2ext, or int2ext+, and change the following:
Use the search and replace function, it would be helpful.
Replace:
Code:
/dev/block/mmcblk0p2
With:
Code:
/dev/block/mmcblk0p5
Thread Closed
There is already a guide thread located HERE for dual booting multiple ROM's. No need for more guides.
Thought id post today on how to set your SELinux to permissive on boot within your boot.img along with some other mods aswell
DISCLAIMER
Make sure you have at least basic knowledge decompiling boot.img & basic understanding of the files contained within, I will not be held responsible if you mess this up, following my instructions to the tee you will have no problems though,
PRE REQUISTES
* MTK extractor or similar program to decompile the boot.img
* Notepad ++
* A copy of your devices boot.img or BOOTIMG.file
* SP flash tool to flash boot.img to device
"alternatively you can add to a flashable zip if you have a custom recovery available for your device using android script generator here on xda-developers"
GUIDE
1. If your boot file is named BOOTIMG.file rename it to boot.img
2. Copy the boot.img to the program folder youll be using to decompile for this guide ill be using MTK extractor as it has a simple gui interface for all the newbs
3. MTK EXTRACTOR ONLY
Open mtk extractor application select the BOOT option from the left, in the bottom left you will see an off switch toggle it to ON
Click start at the top under unpack boot, in the mtk extractor folder will be your boot.img files
4. SETTING THE KERNEL TO PERMISSIVE
( PART 1 )
NOTE
Not all mtk devices are the same some can be set to permissive without the need for all the files using only some and some require all the files it depends on the kernel the device uses the extra files wont make a difference if anything will enforce the state even more
In this tutorial you will be using all the files to set the SELinux contexts to permissive to ensure it is enforced.
PART 1 - STEP 1.
open the INITRD folder then open your default.prop using notepad++
Set the following :
ro.secure=1 >
ro.secure=0
(This renders the boot.img insecure)
ro.selinux=0 >
ro.selinux=1
(NOTE) UBIFS MTK does not have this option
ro.security.perf_harden=1 > ro.security.perf_harden=0
(If you also want insecure adb)
ro.adb.secure=1 >
ro.adb.secure=0
(only newer mtk devices use this ro. Code )
ro.storage_manager.enabled=1 >
ro.storage_manager.enabled=0
Additionally if your device also has a low ram size you should add this to the default prop also to reduce the amount of ram usage while enabling high-end gfx also
# begin ram properties
# for low ram device to return true
ro.config.low_ram=true
# force high-end graphics in low ram mode
persist.sys.force_highendgfx=true
# ram inhaler
ro.HOME_APP_ADJ=1
# end ram properties
Now save and exit the default.prop
PART 1 - STEP 2.
Open your init.rc & init.charging.rc file with notepad++ scroll to the very bottom of the init.rc ( if you have init.target.rc add to this also)
Place this code exactly as shown
# SELinux
on property:/system/bin/setenforce $permissive u:r:kernel:s0
on property:selinux.echo $permissive > /sys/fs/selinux/enforce u:r:kernel:s0
on property:selinux.reload_policy=0
restart ueventd
restart installd
on property:selinux.setsebool debugfs 0
setenforce 0
setprop selinux.reload_policy 0
seclabel u:r:kernel:s0
Now save & exit the init.rc
PART 1 - STEP 3.
Open your fstab/s
To remove DM-Verity if present in your fstab look for the /system line & change to the following
/system ro wait,verify >
/system ro wait
Now look for /data then remove the force encryption of meta-data on data it will look something like this for exapmle
/dev/block/mmcblk0p2 /data ext4 nosuid,nodev,wait,forceencrypt=/dev/block/mmcblk0p3 ext4 /metadata >
/dev/block/mmcblk0p2 /data ext4 nosuid,nodev,wait
To remove encrypted footers from devices which use this instead of DM-Verity, change as follows using the example below,
/[email protected] /data ext4 noatime,nosuid wait,check,encryptable=footer >
/[email protected] /data ext4 noatime,nosuid, wait (check is optional & can be removed also if wanted)
PART 2 - STEP 1
( if you have init.target.rc already no need for this step)
open a new blank page in notepad++
On the first line add
On init
Space out 1 line so your now on line 3
Copy the #SELinux code we placed from init.rc to the new blank page, now save as init.target.rc
Do the above again but this time name it as init.kernel.rc
Now copy theese files to your INITRD folder
PART 2 - STEP 2.
open your init.rc & init.charging.rc once again
Add the following to the import section at the very top of the page,
import /init.kernel.rc
Import/init.target.rc
Save & exit now, your probably wondering why youve added so many files with the same code, on some devices it is necessary as i have found especially on NAND + UBIFS or JFFS2 devices.
PART 2 - STEP 3.
exit the INITRD Folder now open up the bootinfo.txt file
Change from the following
cmdline: >
cmdline: bootopt= androidboot.selinux=permissive
NOTE
FOR MT67**** 32 BIT DEVICES CHANGE FROM
cmdline: bootopt=64S3,32N2,32N2 >
TO
cmdline: bootopt=64S3,32N2,32N2 androidboot.selinux=permissive
FOR MT67**** 64 BIT DEVICES CHANGE FROM
cmdline: bootopt=64S3,32N2,64S3 >
TO
cmdline: bootopt=64S3,32N2,64S3 androidboot.selinux=permissive
Now save & exit the bootinfo.txt
PART 2 - STEP 4
open the cpiolist
Add the following at the bottom or add wherever dosent matter as long as its there
file init.kernel.rc initrd/init.kernel.rc 0750
file init.target.rc initrd/init.target.rc 0750
(Add this option only if you origninally didnt have the init.target.rc file)
Save & exit the cpiolist.
PART 2 - STEP 5
Recompile & flash if you did everything right youve now got an insecure boot.img without dm-verity encryption or data footer enceyption, with insecure adb & SElinux set as permissive,
To make sure its permissive go into settings and about device then scroll to bottom you should now see it,
If you found this useful you know where the thanks button is.
Matty1993 said:
Open your fstab/s
To remove DM-Verity if present in your fstab look for the /system line & change to the following
/system ro wait,verify >
/system ro wait
Now look for /data then remove the force encryption of meta-data on data it will look something like this for exapmle
/dev/block/mmcblk0p2 /data ext4 nosuid,nodev,wait,forceencrypt=/dev/block/mmcblk0p3 ext4 /metadata >
/dev/block/mmcblk0p2 /data ext4 nosuid,nodev,wait
To remove encrypted footers from devices which use this instead of DM-Verity, change as follows using the example below,
/[email protected] /data ext4 noatime,nosuid wait,check,encryptable=footer >
/[email protected] /data ext4 noatime,nosuid, wait (check is optional & can be removed also if wanted)
Click to expand...
Click to collapse
Hi Matty1993,
These are also in dtb of the kernel which I think may cause some issues if not removed. Magisk normally removes it from /system but on newer Android versions 8.0 > 8.1 /vendor is also wait,verify by default.
To edit these yourself you need a good hex editor and replace the ",verify" with zero bytes do not just delete it or type zero's or it will not boot.
I have not seen any forceencrypt in the dtb of the boot.img's I have seen as yet.
bigrammy said:
Hi Matty1993,
These are also in dtb of the kernel which I think may cause some issues if not removed. Magisk normally removes it from /system but on newer Android versions 8.0 > 8.1 /vendor is also wait,verify by default.
To edit these yourself you need a good hex editor and replace the ",verify" with zero bytes do not just delete it or type zero's or it will not boot.
I have not seen any forceencrypt in the dtb of the boot.img's I have seen as yet.
Click to expand...
Click to collapse
Wow i didnt even see this till now i need an assistant or something to organise and mark all my threads because im useless at it haha anyhow maybe could be a vendor related thing then as mine has all the info in dtb of kernel aswell as i was able to remove just "verify" from system and metadata completely and got it to boot.
I also found an easier way to get kernel permissive also as my first older method dosent seem to work with newer mtk models but my newer method works across most mtk platform from mt6572 up to mt6737m
What i did is decompiled my twrp i built for the same phone and copied the busybox applet from /sbin in the initrd then decompiled my boot.img added it to sbin gave it necessary permission of 04555 in the cpiolist whilst i had cpio list open i added below "file init initrd/init 0750"
"file init2 initrd/init2 0750" then went back to the initrd and changed the name of the "init" file to "init2" opened notepad++ to a new page and added the following
#!/sbin/busybox sh
cd/
/sbin/busybox mkdir /tmp
/sbin/busybox mount -t tmpfs tmpfs /tmp
/sbin/busybox mount -t proc proc /proc
/sbin/busybox sed -e 's/printk\.disable_uart\=1/printk\disable_uart\=1 androidboot\.selinux\=permissive/' /proc/cmdline > /tmp/cmdline
/sbin/busybox mount --bind -o -ro /tmp/cmdline /proc/cmdline
/sbin/busybox settings put global captive_portal_detection_enabled 0
/sbin/busybox chmod 755 /init2
/sbin/busybox mv /init2 /init
/bin/su settings put global captive_portal_detection_enabled 0
exec /init
All i did then was save it under the name .init to the bootimg directory then remove the "." from the file name so that it became init.file instead of .INIT format file
After that opened up the bootinfo.txt and added under cmd=bootopt=androidboot.selinux=permissive
Recompiled bootimg and had no dramas so thought id chuck it up here in case anyone else couldnt get there kernel to setenforce 0 through /bin/setenforce or any other way youve tried on these newer mtk models, do remember though results may vary this may or may not work for everyones device, no this will no permanently brick your device doing this if it dosent work you will simply still have an enforcing kernel. Have fun all
Help
tell me how to do selinux = permisive on my firmware and all permissions? Google search does not help. Doogee bl9000 Android 8.1 kernel 4.4.95+ Please help.
waryag said:
tell me how to do selinux = permisive on my firmware and all permissions? Google search does not help. Doogee bl9000 Android 8.1 kernel 4.4.95+ Please help.
Click to expand...
Click to collapse
Hey bud sorry for late reply,
What board make type is it running 6580, 6735/6737 or 6763/6737 depending on which it should be pretty straight forward to get you unlocked and what not as your BL will be by default locked down either way on 6580 or 67xx
I dont recommend you pushing permissive selinux on 8.1 however as this will compromise your security integrity what were you looking to do anyhow regarding permissive selinux,
Rooting or custom recovery ??
Hello all,
My Chinese notwellknown phone model does not have TWRP, but I have made live TWRP/CWM (yes both) backup files:
system.ext4.win (TWRP) and its md5
system.ext4.tar and (CWM) and its md5.
If one day, I have a bootloop and want to restore those file via Bootloader: (Power button & Vol-)
then: fastboot -S 130M flash system system.img
So how do I create a "system.img" from one of the files above (system.ext4.win or system.ext4.tar) ?
A) Before someone sidetrack the topic, I have done MANY TIMES SUCCESSFULLY the command: fastboot -S 130M flash system "stock-system-file.img" with this phone ( .img extracted from stock zip/tar). (* 1)
B) I didn't ask: "Is there other way to restore ?" I asked: How to convert *.ext4.win (twrp) or *.ext4.tar (cwm) files to .img files just like the ones uncompressed from a stock zip/tar.
(*1) Of course there are other ways to restore, like temporarily fastboot boot twrp.img then restore from there or from twrp>adb. But that's not what the question is asking.
........... Thank you everyone ...........
sintoo said:
Hello all,
My Chinese notwellknown phone model does not have TWRP, but I have made live TWRP/CWM (yes both) backup files:
system.ext4.win (TWRP) and its md5
system.ext4.tar and (CWM) and its md5.
If one day, I have a bootloop and want to restore those file via Bootloader: (Power button & Vol-)
then: fastboot -S 130M flash system system.img
So how do I create a "system.img" from one of the files above (system.ext4.win or system.ext4.tar) ?
A) Before someone sidetrack the topic, I have done MANY TIMES SUCCESSFULLY the command: fastboot -S 130M flash system "stock-system-file.img" with this phone ( .img extracted from stock zip/tar). (* 1)
B) I didn't ask: "Is there other way to restore ?" I asked: How to convert *.ext4.win (twrp) or *.ext4.tar (cwm) files to .img files just like the ones uncompressed from a stock zip/tar.
(*1) Of course there are other ways to restore, like temporarily fastboot boot twrp.img then restore from there or from twrp>adb. But that's not what the question is asking.
........... Thank you everyone ...........
Click to expand...
Click to collapse
Here is a thread for converting TWRP/CWM backups into a flashable zip. I know you aren't looking for how to create a flashable zip but the guide instructs how to extract the system.ext4.win and system.ext4.tar to get the system.img from the backup, this is the part that you need.
https://forum.xda-developers.com/showthread.php?t=2746044
Sent from my SM-S767VL using Tapatalk
first, system.img usually can be downloaded somewhere, no need to restore twrp backup for system. don't you think you will find a download? second, if you restore system you may required to restore vendor and boot too. boot.emmc.win can be flashed from fastboot directly, but for vendor you need to convert. the same way. third, system.img can have different formats. you need to know which file system type, partition size, and if it is sparsed image or not. file system type is EXT4 in your case because twrp backup is named system.ext4.win
for "converting" the system.ext4.win* file(s) into system.img you do it in two steps. first you need to create a empty ext4 image file. after the empty disk image is mounted somewhere, you simply unpack the backup files into the mounted disk. so it's not really converting, more like copying.
You need a linux machine for this
so let's begin with partition size
on a working device you can simply check from system or recovery. find the symlink, resolve the symlink for system, get #blocks (=size) for respective block partition, for example mmcblk0p99
for some reason xda blocks code for ls -l (lower case -L there is no space between)
Code:
find /dev/block -name by-name
ls - l /dev/block/platform/bootdevice/by-name
cat /proc/partitions
Note: the above commands need to be run on target android device only. use adb shell or terminal emulator. all other commands below need to be run on host linux pc
if gathering partition size on the device itself is not an option for you, if you have a mediatek chipset you can simply look into scatter file. OTA zip files most likely contain scatter file. if you don't have a scatter file for your ROM version, you can create your own scatter file with WwR MTK
use hex2dec calculator for partition_size: 0x9C800000 = 2625634304 bytes = 2564096 KiB (#blocks)
if you don't have mediatek device i am running out of ideas. you can boot into twrp from fastboot and check, or find a ROM and check the file size hopefully it is not a sparsed image.
Once you know the partition size, now proceed to create a empty file (avoid to do this on fat32 host if size is bigger > 4 GiB)
and format the file to ext4 (or f2fs if needed)
Code:
dd if=/dev/zero of=system.img bs=1 count=0 seek=2625634304
mke2fs -t ext4 system.img
if all went well you can create a mount point on host and mount the empty disk image. the following commands need to be run with root permissions. you can do it from sudo or as root
Code:
mkdir system
sudo -i
cd /home/$SUDO_USER
mount -t ext4 -o loop,rw,noexec,noatime system.img system
you can now unpack the tar files into system. make sure the folder structure remains intact, if the archive contains the folder /system you should unpack to ~ (this will create all files in ~/system) otherwise you need to unpack to ~/system (or cd into ~/system)
for cwm all files need to be concatenated. for twrp do not concatenate each file is a standalone tar archive. if you have android > kitkat 4.4.2+ make sure you use the proper flags for selinux context
Code:
tar --selinux --xattrs --numeric-owner -vxpf system.ext4.win000
tar --selinux --xattrs --numeric-owner -vxpf system.ext4.win001
or
Code:
cat system.ext4.tar000 system.ext4.tar001 | tar --selinux --xattrs --numeric-owner -vxp
the unpacking may produce errors malformed header or something, make sure all files extracted anyway. i have read somewhere better use star instead of tar which can handle twrp files in the right way, unfortunately haven't tested yet
to avoid any problems with permissions you should check/set for system again
Code:
chown -h 1000:1000 system
chmod 0755 system
chcon -h --reference system/bin system
after unpacking just unmount the disk image
Code:
umount system
rmdir system
exit
If you want to create a sparse image you can use the img2simg tool
Code:
sudo apt-get install android-tools-fsutils
img2simg system.img system.smg
This method is just written on the fly especially for your request, everything untested. I really don't know if this file is flashable from fastboot, do it at your own risk!
aIecxs said:
first, system.img usually can be downloaded somewhere, no need to restore twrp backup for system. don't you think you will find a download? second, if you restore system you may required to restore vendor and boot too. boot.emmc.win can be flashed from fastboot directly, but for vendor you need to convert. the same way. third, system.img can have different formats. you need to know which file system type, partition size, and if it is sparsed image or not. file system type is EXT4 in your case because twrp backup is named system.ext4.win
for "converting" the system.ext4.win* file(s) into system.img you do it in two steps. first you need to create a empty ext4 image file. after the empty disk image is mounted somewhere, you simply unpack the backup files into the mounted disk. so it's not really converting, more like copying.
You need a linux machine for this
so let's begin with partition size
on a working device you can simply check from system or recovery. find the symlink, resolve the symlink for system, get #blocks (=size) for respective block partition, for example mmcblk0p99
for some reason xda blocks code for ls -l (lower case -L there is no space between)
Code:
find /dev/block -name by-name
ls - l /dev/block/platform/bootdevice/by-name
cat /proc/partitions
Note: the above commands need to be run on target android device only. use adb shell or terminal emulator. all other commands below need to be run on host linux pc
if gathering partition size on the device itself is not an option for you, if you have a mediatek chipset you can simply look into scatter file. OTA zip files most likely contain scatter file. if you don't have a scatter file for your ROM version, you can create your own scatter file with WwR MTK
use hex2dec calculator for partition_size: 0x9C800000 = 2625634304 bytes = 2564096 KiB (#blocks)
if you don't have mediatek device i am running out of ideas. you can boot into twrp from fastboot and check, or find a ROM and check the file size hopefully it is not a sparsed image.
Once you know the partition size, now proceed to create a empty file (avoid to do this on fat32 host if size is bigger > 4 GiB)
and format the file to ext4 (or f2fs if needed)
Code:
dd if=/dev/zero of=system.img bs=1 count=0 seek=2625634304
mke2fs -t ext4 system.img
if all went well you can create a mount point on host and mount the empty disk image. the following commands need to be run with root permissions. you can do it from sudo or as root
Code:
mkdir system
sudo -i
cd /home/$SUDO_USER
mount -t ext4 -o loop,rw,noexec,noatime system.img system
you can now unpack the tar files into system. make sure the folder structure remains intact, if the archive contains the folder /system you should unpack to ~ (this will create all files in ~/system) otherwise you need to unpack to ~/system (or cd into ~/system)
for cwm all files need to be concatenated. for twrp do not concatenate each file is a standalone tar archive. if you have android > kitkat 4.4.2+ make sure you use the proper flags for selinux context
Code:
tar --selinux --xattrs --numeric-owner -vxpf system.ext4.win000
tar --selinux --xattrs --numeric-owner -vxpf system.ext4.win001
or
Code:
cat system.ext4.tar000 system.ext4.tar001 | tar --selinux --xattrs --numeric-owner -vxp
the unpacking may produce errors malformed header or something, make sure all files extracted anyway. i have read somewhere better use star instead of tar which can handle twrp files in the right way, unfortunately haven't tested yet
to avoid any problems with permissions you should check/set for system again
Code:
chown -h 1000:1000 system
chmod 0755 system
chcon -h --reference system/bin system
after unpacking just unmount the disk image
Code:
umount system
rmdir system
exit
If you want to create a sparse image you can use the img2simg tool
Code:
sudo apt-get install android-tools-fsutils
img2simg system.img system.smg
This method is just written on the fly especially for your request, everything untested. I really don't know if this file is flashable from fastboot, do it at your own risk!
Click to expand...
Click to collapse
Cygwin works as well, it doesn't necessarily "have" to be Linux.
There is a post for using Cygwin as well in the thread that I linked.
More than one way to "skin this cat", so to speak. I'm sure they'll figure it out with the information they've been provided.
Sent from my SM-S767VL using Tapatalk
i don't think so, twrp archive doesn't contain a system.img it only contains folder /system. therefore you can't extract system.img but only the files inside, which have to be extracted in the right way including metadata. the cygwin untar.exe won't handle secontext flag. besides this it is generally bad idea to extract linux files to windows file system. ntfs is case insensitive and not all ascii chars allowed in file names, you will lose all file permissions owner/group and selinux context (except you untar it directly to ext4 image like i said). This might not be important for flashable zip because everything is lost inside a zip anyway (that's why META-INF is needed) but for creating a working ext4 image you must set everything to drw(x)r-(x)r-(x) system system ubject_r:system_file:s0 (i can be wrong always double check for your ROM) things become more complicated when we talking about data.ext4.win or vendor.ext4.win
even if you compile star or gnu tar and all other binaries for windows like mke2fs chcon or so, you won't be able to mount the ext4 disk image r/w in the right way on windows..
anyway thanks for suggesting cygwin, might be a simple alternative for windows freaks. i personally prefer booting live distro from usb stick
aIecxs said:
i don't think so, twrp archive doesn't contain a system.img it only contains folder /system. therefore you can't extract system.img but only the files inside, which have to be extracted in the right way including metadata. the cygwin untar.exe won't handle secontext flag. besides this it is generally bad idea to extract linux files to windows file system. ntfs is case insensitive and not all ascii chars allowed in file names, you will lose all file permissions owner/group and selinux context (except you untar it directly to ext4 image like i said). This might not be important for flashable zip because everything is lost inside a zip anyway (that's why META-INF is needed) but for creating a working ext4 image you must set everything to drw(x)r-(x)r-(x) system system ubject_r:system_file:s0 (i can be wrong always double check for your ROM) things become more complicated when we talking about data.ext4.win or vendor.ext4.win
even if you compile star or gnu tar and all other binaries for windows like mke2fs chcon or so, you won't be able to mount the ext4 disk image r/w in the right way on windows..
anyway thanks for suggesting cygwin, might be a simple alternative for windows freaks. i personally prefer booting live distro from usb stick
Click to expand...
Click to collapse
Yeah, that is true, it should only be the system folder.
Since they must use TWRP/CWM to create the backups, maybe it would have been better to suggest that they should instead, boot into TWRP then connect to adb to use adb shell commands or to use the terminal emulator that is built into TWRP to run a system dump or dd commands to dd a copy of the system.img over to PC.
Or maybe there is a way to mount/run the extracted system folder in terminal then using terminal to dump/dd a .img from that. I don't even know if that is possible(never heard of it, but it's a thought) but it seems to me that if the system.img is what is written to the system partition when flashed and this is what creates the system folder, there "should" be a way to pack the contents of the system folder back into what was originally contained in the system.img. It might miss a few things though, like the kernel for one, the kernel is sometimes part of the system.img but I don't know if that necessarily means that the kernel will be in the system partition/folder when the system.img is flashed. Thus, making it impossible to reverse engineer back into a proper system.img using only the contents of the system folder obtained from a nandroid backup.
A system dump, dd the .img or extract the system.img from the stock firmware file are the way to go, preferably, extracting from the stock firmware file, because that is easier and less risky than using shell, terminal and Linux for the uninitiated.
Sent from my SM-S767VL using Tapatalk
---------- Post added at 03:52 PM ---------- Previous post was at 03:47 PM ----------
aIecxs said:
i don't think so, twrp archive doesn't contain a system.img it only contains folder /system. therefore you can't extract system.img but only the files inside, which have to be extracted in the right way including metadata. the cygwin untar.exe won't handle secontext flag. besides this it is generally bad idea to extract linux files to windows file system. ntfs is case insensitive and not all ascii chars allowed in file names, you will lose all file permissions owner/group and selinux context (except you untar it directly to ext4 image like i said). This might not be important for flashable zip because everything is lost inside a zip anyway (that's why META-INF is needed) but for creating a working ext4 image you must set everything to drw(x)r-(x)r-(x) system system ubject_r:system_file:s0 (i can be wrong always double check for your ROM) things become more complicated when we talking about data.ext4.win or vendor.ext4.win
even if you compile star or gnu tar and all other binaries for windows like mke2fs chcon or so, you won't be able to mount the ext4 disk image r/w in the right way on windows..
anyway thanks for suggesting cygwin, might be a simple alternative for windows freaks. i personally prefer booting live distro from usb stick
Click to expand...
Click to collapse
I use VM, Live USB and dual boot, depending on which system I'm on(I have more than one rig) and depending on what I'm doing. In some cases, using Windows running Linux in VM is handy because some things are easier in Windows and some are easier in Linux, VM allows switching back and forth between Windows and Linux "on the fly" instead of having to move back and forth between two different systems. Another advantage to VM, your actual system is effectively immune to viruses when browsing the web inside the VM, only the OS installed in the VM is vulnerable, if infected, just wipe that OS and reinstall in the VM and you're clean again, your actual system that the VM is running on, never gets effected.
Sent from my SM-S767VL using Tapatalk
yeah i wonder how did create twrp backup without actually having twrp. busybox tar isn't able to do it, at least full tar binary is required. would be better to create backup in desired format from the very beginning. easiest way is adb pull /dev/block/bootdevice/by-name/system system.img (with proper path of course)
aIecxs said:
yeah i wonder how did create twrp backup without actually having twrp. busybox tar isn't able to do it, at least full tar binary is required. would be better to create backup in desired format from the very beginning. easiest way is adb pull /dev/block/bootdevice/by-name/system system.img (with proper path of course)
Click to expand...
Click to collapse
They booted a live temporary session of TWRP without actually flashing it to the recovery partition. I've done the same on an Intel tablet and a couple of RCA tablets. Booting it directly instead of flashing it onto the device doesn't trigger the locked bootloader. The locked bootloader won't allow booting unverified software that has been installed in the device's hardware itself, but it does not block booting unverified software from an external source.
Sent from my SM-S767VL using Tapatalk
After reading other source, someone said the ext4.win are just tar. One only needs to rename them to ext4.win.tar and you uncompress to img.
I guess the truth is more complicated than that because img (from stock, ready to be ODINed/Bootloader Fastboot) are raw images, including zeros. That's the difference.
In the end, if I had to do it again, I would have to dd the whole /mmcblkxxx(system) to a microSD. Yes 16-20Gb takes a much longer time than 2-3Gb (system.ext4.win) but that what <fastboot flash system system.img> requires (raw data and zeros).
sintoo said:
After reading other source, someone said the ext4.win are just tar. One only needs to rename them to ext4.win.tar and you uncompress to img.
Click to expand...
Click to collapse
Thats exactly how it works see post #3
if you add entry with file system type "emmc" in /etc/recovery.fstab TWRP produces flashable disk image system_image.emmc.win* instead of tar archive (which you can probably concatenate into system.img)
Code:
/system_image emmc /dev/block/platform/mtk-msdc.0/by-name/system flags=display="System Image";backup=1;flashimg=1