Related
4EXT Recovery Classic v2.2.7 RC5 | TAR BACKUPS | Convert FS | Romname -> Backupname
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
Quick note about themes:
Available themes as of Oct/17:
Themes by GuestK00388
Themes by Apaquette420
Themes by Whiskey103
Themes by Amresh
Themes by Apaquette420
Themes by CWhitney24
Themes by DaMyth
Themes by Blindndumb
To uninstall any "flashed theme" and to revert to your own custom settings you had before flashing, just use this Theme Uninstaller in recovery.
It will clear any theme you might have flashed and revert to your own custom settings you had before flashing that theme!
THANKS:
All credits and my deepest respect go to Koush for his extremely great code!
Without him 4EXT Recovery wouldn't have been possible!
Biggest thanks possible go to Sebastiaan15 for his brilliant ideas and who spent whole weeks testing my buggy code with his Desire
Without you I could never have made it!!!
So BIG THANKS to SEBASTIAAN15 and KOUSH for his hard work with CWMR !!!
Many credits to the Desire S community ( especially to loveboatcaptain - LBC Mod Android Development and Marylandcookie ) for testing, very nice ideas, feature suggestions and helping to get the code running on the Desire S!
Special big thanks to RAVENNA from android-hilfe.de board for hours of testing for the Desire!
BIG Thanks to Hussainmushahid who helped me a lot spending much of time with solving a bug I could not reproduce on my device.
And many thanks to all users who reported and helped to identify problems ( can't any longer list all of you here since the list has grown too large )!
Even more thanks to people who 've bought me some beer YOU ROCK!! ZEEKIZ, A USER, PHILOS64, STEVEATHOME, PREACHER65, BEN_PYETT, ULTRA DROID, PTR_HAMILTON, BEANBEAN50, SEBASTIAAN15 and LOVEBOATCAPTAIN
v2.2.6 RC4 Released: Oct/01
Rare Superuser problem when tar backups were enabled (disabled by default) was fixed.
Converting partitions between ext3 and ext4 without data loss now correctly calculates the space needed to successfully complete the operation
New option: check and optionally repair the file system on your sdcard (fat32)
Removed duplicate format cache option inside the format menu (wipe cache does the same)
When formatting fat32 it will now save your 4ext.prop settings and restore them afterwards
Changed partitioning of the sdcard to not use LBA mode for new fat32 partitions as requested by Ghiki
Added new size option (128mb) to the partitioning menu per request
Parted is no longer used to format fat32 in the partition menu
-> This solves a bug where sometimes the creation of the fat32 file system failed and produces better quality results
4EXT Recovery themes should now stay when formatting /system or flashing new roms
New option: format /sdcard fat32
New 4EXT Recovery Control API because I'm forced to drop "extendedcommand" (see App for the reason why)
enables file names and directories to include spaces for installations
calculates needed space to complete a full or advanced backup at the beginning of the backup.
This ensures that you are not left with a non working backup.
Size for recovery greatly reduced
New 4EXT Recovery Control Features
Please see www.4ext.net for more.
Fix permissions
Calculate real values for the space needed to create a new full or advanced backup
Advanced Backups: While you are selecting / deselecting partitions, it will display and update the currently needed space to complete that custom backup set.
As an example, the following would be possible to do in just one session:
Restore a backup, set to create a backup / advanced backup before the restore,
format all partitions with a file system of your choice before the restore process starts,
flash additional zip files afterwards, fix permissions and select to stay inside recovery or to reboot automatically once all actions are complete.
Features: Use 4EXT Recovery Control or Recovery Updater for complete Changelogs and Known issues!
not all features may be relevant for all devices
Displays additional information:
Identifies your current rom and displays its name
Current filesystems on your partitions
Free space remaining of all of your volumes
Current battery charge level
Backup | Restore:
Correctly calculates free space needed to complete a backup ( version > 2.2.6 RC4 )
Tar backups (can be switched on or off)
Complete CWMR5 compatibility
All Backups you create will be named after your currently installed Rom for easier identification.
Never unwillingly get "downgraded" to EXT3 again
Always restores backups using the file systems you HAD on your partitions at the time of creation!
-> all partitions formatted with ext4 at that time, will be restored to ext4. The same is true for ext3.
You can manually change any existing Backup to ext4 or ext3
-> so that after a restore, all partitions and up with the file system you wanted!
Advanced Backup: backup only a single partition
Convert any of your partitions to EXT4 or EXT3 without data loss.
Formatting:
When you wipe or format it will always use the same file system you currently have.
-> but you can change that
When you format ext4 it will always create an aligned file system
Correctly identifies unformatted sd-ext partitions
-> if it finds one it displays a warning and suggests you may format them by visiting the 4EXT menu
Filesystem check and repair option in advanced menu
Partitioning:
Alignment check of your partitions
Full support for up to 2 sd-ext partitions + swap (Backup/restore/format/convert, fsck, et.c.)
(RE-) Partition your sdcard for sd-ext without removing your fat32 partition.
All partitions created with 4EXTRecovery will be perfectly aligned to 4k
Installing:
Integrated md5sum checking option
Themes:
Customize all colours used throughout recovery
Use your own icons, background images, progress bars.. more to come.
Assign different backgrounds to different menu categories (version >= 2.1.2)
Create a flashable zip for others to flash your theme.
Menus:
Most popular menu items rearranged
Format menu
Power Menu + option to reboot into bootloader
Less "No's" in confirmation dialogues
Changed Advanced Restore: first select what you want to restore, then select the backup
-> Useful for restoring from "Advanced Backups"
4ext.prop:
Configuration file on your sdcard where you can set options to be used by 4EXTRecovery
Change all settings conveniently with 4EXT Recovery Control
Many more options to come
Share your settings / themes by packing your config into a flashable theme
Other stuff:
USB Storage Autostart (must be switched on)
Mount usb storage exposes all partitions on your sdcard to the os (not just fat32)
-> you could even partition your sdcard from your PC while connected via USB
Switch haptic feedback on/off
You don't need to reboot recovery if you transferred a file to show up in the install menu.
-> This bug affected only some users with either CWMR or previous versions of 4EXT.
Button backlights (Desire S, Desire HD and Incredible S only)
Download:
All downloads are now available through 4EXT Recovery Updater. It's free, no ads, no tracking, no nothing, don't worry
.. and of course via 4EXT Recovery Control
This ensures that your downloads are ok by automatically verifying md5sums and that known issues and changelogs are easily accessible
It also notifies you when there are any new critical bugs found
Recovery images will be uploaded for download soon too, but they can also be acquired easily by using Updater or Control.
You can for example just download a recovery.zip containing the image. The download will be automatically verified for correct md5sums!
4EXT Recovery Control
Free version: Recovery Updater
Fully featured version: 4EXT Recovery Control
For a list of its many features, visit www.4ext.net
Some examples :
Flash as many zip files you want in one go
Automatically calculate and display the md5sums of all zip files you are going to flash
Check your backups' health to ensure they will restore later when you need them, by verifying their md5sums!
Optionally, but highly not recommended:
If md5sums don't match but you REALLY NEED that backup BADLY, you might want to restore it anyway.
You can you this app to fix the md5sums of a given backup to "forcefully" restore it!
Calculate real values for the space needed to create a new full or advanced backup
Advanced Backups: While you are selecting / deselecting partitions, it will display and update the currently needed space to complete that custom backup set.
Identifies and adds your romname so you don't need to type so much when chosing a meaningful name for your backup
As an example, the following is possible to do in just one session:
Restore a backup, set to create a backup / advanced backup before the restore,
format all partitions with a file system of your choice before the restore process starts,
flash additional zip files afterwards, fix permissions and select to stay inside recovery or to reboot automatically once all actions are complete.
Much, much more! See www.4ext.net
Recovery theming
Uninstall and Install themes with live preview and the option to change their colours without the need to reboot into recovery.
Change all colours with live preview and a nice colour picker.
updated because of thanks which was really badly needed.
madmaxx82 said:
updated because of thanks which was really badly needed.
Click to expand...
Click to collapse
Strange thing. My ROM 1.0.2 with full EXT4 wont boot as long as this recovery was not flashed.
mike1986. said:
Strange thing. My ROM 1.0.2 with full EXT4 wont boot as long as this recovery was not flashed.
Click to expand...
Click to collapse
Yes, it doesn't work with m-deejay's rom either without that recovery.
But I don't find that so strange.. when you format ext4 in your updater script and later in the script mount the partition ext4, it wouldn't be possible, since the kernel couldn't mount a ext4 partition..
But with m-deejay's kernel as "recovery kernel" it works
When could we test your rom?
madmaxx82 said:
Yes, it doesn't work with m-deejay's rom either without that recovery.
But I don't find that so strange.. when you format ext4 in your updater script and later in the script mount the partition ext4, it wouldn't be possible, since the kernel couldn't mount a ext4 partition..
But with m-deejay's kernel as "recovery kernel" it works
When could we test your rom?
Click to expand...
Click to collapse
Any minute I guess
mike1986. said:
Any minute I guess
Click to expand...
Click to collapse
Great!! Very excited
Updated, please update!
Im a bit confused now...
Can you flash Android Revolution HD 1.0.1 ROM that needs EXT4 support with this?
I thought that you need ClockworkMod Recovery 3.2.0.0 and not 3.0.2.6 that comes with Rom Manager v4.3.0.1.
Have i understod this corect that "3.2.0.0_EXT4_unofficial_revB.zip" works with Rom Manager v4.3.0.1?
I ask because in another thread the say that Rom Manager will never work with EXT4 CMR.
jkolner said:
Im a bit confused now...
Can you flash Android Revolution HD 1.0.1 ROM that needs EXT4 support with this?
I thought that you need ClockworkMod Recovery 3.2.0.0 and not 3.0.2.6 that comes with Rom Manager v4.3.0.1.
Click to expand...
Click to collapse
You need 3.2.0.0 EXT4 rev.b recovery from this thread in order to flash my ROM
jkolner said:
Im a bit confused now...
Can you flash Android Revolution HD 1.0.1 ROM that needs EXT4 support with this?
I thought that you need ClockworkMod Recovery 3.2.0.0 and not 3.0.2.6 that comes with Rom Manager v4.3.0.1.
Click to expand...
Click to collapse
Sorry
The attached file on the bottom of the post is the official recovery in case someone wants / needs to revert back and cannot boot into his system to use rom manager.
The 3.2.0.0 with Ext4 is at the top of the post
Updating now... just out of curiosity, what is the update for?
madmaxx82 said:
Sorry
The attached file on the bottom of the post is the official recovery in case someone wants / needs to revert back and cannot boot into his system to use rom manager.
The 3.2.0.0 with Ext4 is at the top of the post
Click to expand...
Click to collapse
No - it's me that are sorry, because i should have figured that out my self!
Thanks madmaxx82 for your great work and quick respons ;-)
l0st.prophet said:
Updating now... just out of curiosity, what is the update for?
Click to expand...
Click to collapse
Previously I wanted to be able to restore an ext3 nandroid with this recovery version, but this resulted in recovery formatting /data and /cache Ext3 too (when invoked by the user through the menu. Formatting ext4 through updatescripts when installing roms worked fine).
But because many people use that feature it would mess things up if they wiped when they had an EXT4 rom installed.
This version is now EXT4 only.. so you can wipe, format, backup/restore any ext4 rom. But it should be incompatible with ext3 backups/roms.. I'll test it once again, but I don't think it will work.. so you'd need to revert to the official clockworkmod recovery when you decided you wanted to restore a nandroid from an EXT3 rom...
jkolner said:
No - it's me that are sorry, because i should have figured that out my self!
Thanks madmaxx82 for your great work and quick respons ;-)
Click to expand...
Click to collapse
Thank you, but there isn't really much you could thank me about.
All thanks go to koush and m-deejay for the kernel.. compiling and altering a file is something everyone can do
madmaxx82 said:
This version is now EXT4 only.. so you can wipe, format, backup/restore any ext4 rom. But it should be incompatible with ext3 backups/roms.. I'll test it once again, but I don't think it will work.. so you'd need to revert to the official clockworkmod recovery when you decided you wanted to restore a nandroid from an EXT3 rom...
Click to expand...
Click to collapse
Although I don't understand that..
if it#s just a dd if=bla.img of=/dev/bla it shouldn't matter at all and the recovery shouldn't even be aware which fs it is... strange.. testing again now, maybe something else didn't work when trying first.
madmaxx82 said:
Although I don't understand that..
if it#s just a dd if=bla.img of=/dev/bla it shouldn't matter at all and the recovery shouldn't even be aware which fs it is... strange.. testing again now, maybe something else didn't work when trying first.
Click to expand...
Click to collapse
hahaha, don't know what went wrong the first time..
Ok, confirmed it doesn't matter.. but now the problem would be if someone reverted back to an ext3 rom and then later would use the wipe function.. testing that now.. my guess is that recovery would format them ext4 now which would be NOT good, to say the least
I might be off base here, but doesn't the update script of the ROM chose the fs in the format, so it doesn't matter what the wipe does, the update script changes it anyway?
l0st.prophet said:
I might be off base here, but doesn't the update script of the ROM chose the fs in the format, so it doesn't matter what the wipe does, the update script changes it anyway?
Click to expand...
Click to collapse
Yes, but if the user decided to manually wipe using this modified recovery after installing an ext3 rom..
madmaxx82 said:
Yes, but if the user decided to manually wipe using this modified recovery after installing an ext3 rom..
Click to expand...
Click to collapse
Okay this works!
I guess it's because ext3 is partially forward compatible to ext4 when ext4's extents feature isn't used..
From Wiki:
"The ext3 file system is partially forward compatible with ext4, that is, an ext4 filesystem can be mounted as an ext3 partition (using "ext3" as the filesystem type when mounting). However, if the ext4 partition uses extents (a major new feature of ext4), then the ability to mount the file system as ext3 is lost."
So, as it seems, I haven't found any bugs yet, you can do anything with it..
Updating first post
Updated to using stable ClockworkMod Recovery 3.0.2.8 since Mike1986 reported that there might be issues with sd ext on 3.2.0.0
Free Memory to > 1Gb!
How to Increase your Internal Memory Size with very low effort!
NOTICE: This method works both on Rooted and NOT Rooted Phones!
You simply need to meet three easy requirements:
Stock Firmware installed on the Phone (custom ROMS not supported ...They don't need to!)
A microSD with two primary formatted partitions inside (the former 'to FAT32' and the latter 'to EXT4' filesystems)
Ready to Flash to your Galaxy Next via Odin
NOTICE: The following Black Box Howto is explained deep inside in the next post of this Thread (short explanation) and in This Thread from outside: Internal Memory to +1Gb! and related ones (long explanation / Italian Language)
HOW TO
1) Download Tass.ops file for Odin!
2) Type this number on your phone keyboard:
*#1234#
and keep note of the PDA code of the Firmware installed.
3) Download boot image ready for Odin and suitable for your firmware:
All modded images are inside my Google Drive; actually we find:
Code:
[b][url=https://docs.google.com/folder/d/0B3qe_9NlA1D_QVlKXy01bjZPbVE/edit]Memory Hack Google Drive Archive[/url][/b]
[b][size=3]Galaxy MINI/NEXT/POP[/size][/b]
S5570AIKQ3 S5570BGKS3 S5570BGKT2
S5570BVKQ4 S5570BVKT1 S5570DDKA7
S5570DDKQ7 S5570DXKPD S5570DXKT6
S5570JPKQ8 S5570JPKS1 S5570JPKT2
S5570JVKQ3 S5570JVKT1 S5570MJKS2
S5570XIKQC S5570XWKE3 S5570XWKQG
S5570XWKS2 S5570XWKS7 S5570XWKT7
S5570XWKTH S5570XWKTN S5570XWKTS
S5570XWKTU S5570XXKPF S5570XXKPI
S5570XXKPK S5570XXKS1 S5570XXKS4
S5570ZSKPC
-----------
S5570bVJKPB
-----------
S5570LWMKP9 S5570LWMKPJ S5570LWMKPO
[b][size=3]Galaxy MINI/NEXT/POP[/size][/b]
[b]Froyo[/b]
S5570DXKB1 S5570XIKFI S5570XWKC1
[b][size=3]Galaxy GIO[/size][/b]
S5660AIKT4 S5660DXKT8 S5660JPKT7
S5660XXKPA S5660XXKTF S5660XXKTI
S5660XXKTK S5660XXKTO
-----------
S5660MUGKG3
[b][size=3]Galaxy FIT[/size][/b]
S5670DDKB1 S5670DDKT3 S5670DXKPB
S5670DXKT4 S5670JPKQ7 S5670XWKQA
S5670XWKTI S5670XXKPQ S5670XXKPU
-----------
S5670LUBKP6 S5670LUBKPI
[b][size=3]Galaxy ACE[/size][/b]
S5830BOKS3 S5830DDKQ5 S5830DDKQ8
S5830DXKPB S5830DXKPD S5830DXKT5
S5830XWKPY S5830XWKS2 S5830XWKS9
S5830XWKT7 S5830XWKTM S5830XWKTQ
S5830XXKPH S5830XXKPP
your firmware not listed? ...take a look into Google Drive first, then let me know if you don't find anything!
4) Flash the downloaded archive with Odin
Example image follows:
{
"lightbox_close": "Close",
"lightbox_next": "Next",
"lightbox_previous": "Previous",
"lightbox_error": "The requested content cannot be loaded. Please try again later.",
"lightbox_start_slideshow": "Start slideshow",
"lightbox_stop_slideshow": "Stop slideshow",
"lightbox_full_screen": "Full screen",
"lightbox_thumbnails": "Thumbnails",
"lightbox_download": "Download",
"lightbox_share": "Share",
"lightbox_zoom": "Zoom",
"lightbox_new_window": "New window",
"lightbox_toggle_sidebar": "Toggle sidebar"
}
5) THAT'S ALL FOLKS!
- - -
How does it Work:
Scenario 1:
I switch on the Phone, without a MicroSD slotted in or with a microSD with a single FAT32 partition (broken or damaged microSD also suite this scenario...); GingerBread boots as usual!
No Difference!
Scenario 2:
I switch on The Phone with a microSD slotted in (with the second partition formatted as EXT4 filesystem but still EMPTY); Ginger boots acting as if
/data
is completely moved outside to microSD but just WIPED (not true obviously, and the original /data is safe inside the phone), so it resettle it from beginning...
NOTICE:
...If your second partition is 1Gb wide...
...your new Internal Memory will be 1Gb wide...
Scenario 3:
I switch on the Phone with the second partition of the microsd (EXT4) up and running (already resettled up for use and with my userdata on it); Ginger simply boots with
/data
moved outside to microSD with your userdata there and tons of apps just installed from the market...
Example Image of my New Internal Memory Size follows
- - -
NOTICES & ADVICES:
If I want to remove the microSD from the slot, FIRST I NEED TO SWITCH OFF THE PHONE!
When I install apps from the Market, Ginger Misunderstands the actual new Internal Memory SIZE and puts the apk files to External Storage anyway! I simply need to move them "to the phone" via "Settings menu" immediately after!
When I switch on the Phone without the microSD, I boot using the original /data inside the phone, actually loosing all the apps installed onto the external one untill next boot with SDcard; and, of course, loosing my sms stored there and others personal userdata too.
Unfortunately this boot image heavy conflicts with Link2SD (great app anyway!), so you must choose one: This Boot image or Link2SD... not both... sorry!
Don't You Like the boot image just installed and You want to revert without flashing the full firmware to the Phone?
The original images, ready for Odin, are stored into my Google Drive too, inside BASE subfolders!
- - - - - - - - - - - - - - - - -
THREAD ADDONS
CHECK FILESYSTEM FOR ERRORS
On post n. 43 you can find an Android Application useful to check the 2nd partition filesystem for errors once a month...
EXT4 Checkup Tool 1.0 RC3
P.S. Only for rooted phones!
Click to expand...
Click to collapse
HOW TO
From post n. 52 I explain exactly What I do deep Inside and Step by Step...
Click to expand...
Click to collapse
ADDED PHONE MODELS
In post n. 56 I added boot images modded for Galaxy FIT (S5670), Galaxy ACE (S5830) and Galaxy GIO (S5660)!
Click to expand...
Click to collapse
ALL IN ONE WONDER AUTOSCRIPT
In post n. 78 I added a Linux Script "All in one" to mod your boot Image on your own simply with a double-click!
Click to expand...
Click to collapse
MEMORY AND OVERCLOCK KERNEL
In post n. 148 you find modded images with OC Kernel inside
P.S. Only for rooted phones with CWM or Custom Recovery!
Click to expand...
Click to collapse
Patched Boot Image "Deep Inside"
As I stated in the previous Post, I skip the Long Explanation of this How to (Italian Threads online anyway) and briefly describe What I did!
1) Split Boot.img
I splitted boot.img into it's two main parts: The Kernel and the Ramdisk.
2) Edit ramdisk
2.1) Strip Samsung Kernel Modules
I figured out that Samsung modules used for rfs filesystem are compiled with all the debug symbols inside, so I stripped them saving more than 3Mb into the ramdisk!
NOTICE: The boot.img must not exceed 8Mb Size or I cannot flash it! BEWARE!
2.2) Add Ext4 kernel Modules
I compiled the jbd2.ko and ext4.ko modules for the attached Kernel and put them into /lib/modules inside the ramdisk:
Code:
gandalf $ ls -l ./ramdisk/lib/modules/
totale 1304
-rw-r--r-- 1 root root 236116 11 dic 08.24 [b]ext4.ko[/b]
-rw-r--r-- 1 root root 363932 11 dic 08.24 fsr.ko
-rw-r--r-- 1 root root 211200 11 dic 08.24 fsr_stl.ko
-rw-r--r-- 1 root root 58176 11 dic 08.24 [b]jbd2.ko[/b]
-rw-r--r-- 1 root root 260568 11 dic 08.24 rfs_fat.ko
-rw-r--r-- 1 root root 90968 11 dic 08.24 rfs_glue.ko
-rw-r--r-- 1 root root 99532 11 dic 08.24 sec_param.ko
gandalf $
2.3) Patch init.rc file
I patched the init.rc file into the ramdisk to load these modules into the kernel immediately after the first boot stage of the firmware:
Code:
# insmod fsr/rfs modules
insmod /lib/modules/fsr.ko
insmod /lib/modules/fsr_stl.ko
insmod /lib/modules/rfs_glue.ko
insmod /lib/modules/rfs_fat.ko
insmod /lib/modules/sec_param.ko
[color=red]insmod /lib/modules/jbd2.ko[/color]
[color=red]insmod /lib/modules/ext4.ko[/color]
2.4) Add busybox
I added a copy of busybox into /sbin.
I'll need it to mount ext4 filesystems on microSD later on.
Code:
gandalf $ ls -l ./ramdisk/sbin/
totale 2088
-rwxr-x--- 1 root root 117948 11 dic 08.18 adbd
-rw[color=red][b]s[/b][/color]r-xr-x 1 root root 2016700 11 dic 08.21 [b]busybox[/b]
lrwxrwxrwx 1 root root 7 11 dic 08.18 ueventd -> ../init
(i686) gandalf ~ (i686) $
2.5) Patch init.rc again
I changed the mount command for /data!
Original code:
Code:
# Mounting of system/userdata is moved to 'on emmc' and 'on nand' sections
# We chown/chmod /data again so because mount is run as root + defaults
[color=red][b]mount rfs /dev/stl13 /data nosuid nodev check=no[/b][/color]
chown system system /data
chmod 0771 /data
Patched code:
Code:
# Mounting of system/userdata is moved to 'on emmc' and 'on nand' sections
# We chown/chmod /data again so because mount is run as root + defaults
[color=red][b]exec /sbin/busybox sh /init.data.sh[/b][/color]
chown system system /data
chmod 0771 /data
2.6) add init.data.sh file
I added an external shell file, used to mount microsd /data avoiding the Android Init Language used by init.rc.
Code:
gandalf $ cat ./ramdisk/init.data.sh
#!/sbin/busybox sh
/sbin/busybox mount -o nosuid,nodev -t ext4 /dev/block/mmcblk0p2 /data || /sbin/busybox mount -o nosuid,nodev -t rfs /dev/stl13 /data
gandalf $
3) Repack ramdisk and kernel into boot.img
I used the AOSP mkbootimg tool to repack alltoghether.
4) Prepare Odin Archive ready for flash
I created a PDA Archive with only boot.img inside.
A command sequence could be, for example:
Code:
tar -H ustar -c boot.img > CODE_S5570XWKS7_boot.tar
md5sum CODE_S5570XWKS7_boot.tar >> CODE_S5570XWKS7_boot.tar
mv CODE_S5570XWKS7_boot.tar CODE_S5570XWKS7_boot.tar.md5
That's All!
Enjoy!
Wonderful
now i am using this: http://forum.xda-developers.com/showthread.php?p=18561098
i have s5570jpks1 in pda
phone:s5570xwks2
csc:s5570ojpks1
it's arabic firmware with 2.3.5
help me please
what pda i should use?
Increase Performance? Oh Yes!
denzel09 said:
...now i am using this: http://forum.xda-developers.com/showthread.php?p=18561098
Click to expand...
Click to collapse
Great Script! Really Interesting!
Good Idea to mix /data outside with some programs still onboard, looking to performance...
At a first glance I like a lot this command:
Code:
busybox mount -t ext4 -o noauto_da_alloc,data=ordered,commit=15,barrier=1,nouser_xattr,errors=continue,noatime,nodiratime,nosuid,nodev /dev/block/mmcblk0p2 /data;
I achieve the same safe result while data=ordered and barrier=1 are defaults for ext4 mount command and because I compiled ext4 kernel modules with the extended attributes disabled (nouser_xattr).
I surely agree with noatime and nodiratime due to microsd lifecycle troubleshootings, but never set noauto_da_alloc...
...after some readings I figured out that it should be a MUST Option for SSD...
While working of this bunch of code
Code:
#-- SDCard Speed Fix
if [ -e /sys/devices/virtual/bdi/179:0/read_ahead_kb ]
then
/system/xbin/echo "8192" > /sys/devices/virtual/bdi/179:0/read_ahead_kb;
fi;
I surely upgrade AS SOON AS POSSIBLE the attached boot images to gain performance without loosing stability..
Thanks a Lot!
P.S. Great Idea Again; thanks to Amarullz too.
Actually, anyway, I moved the whole GingerBread outside... I have /data, /system and /cache alltoghether into my microSD...
...that is: "free to experiment! No need to halt and reflash on errors"...
midomad said:
i have s5570jpks1 in pda...
Click to expand...
Click to collapse
I'll take a look. Please Hold on...
Doc_cheilvenerdi.org said:
I surely upgrade AS SOON AS POSSIBLE the attached boot images to gain performance without loosing stability..
Click to expand...
Click to collapse
Please do it ASAP, thanks
Doc_cheilvenerdi.org said:
...
I surely agree with noatime and nodiratime due to microsd lifecycle troubleshootings, but never set noauto_da_alloc...
...after some readings I figured out that it should be a MUST Option for SSD...
While working of this bunch of code
Code:
#-- SDCard Speed Fix
if [ -e /sys/devices/virtual/bdi/179:0/read_ahead_kb ]
then
/system/xbin/echo "8192" > /sys/devices/virtual/bdi/179:0/read_ahead_kb;
fi;
....
P.S. Great Idea Again; thanks to Amarullz too.
Actually, anyway, I moved the whole GingerBread outside... I have /data, /system and /cache alltoghether into my microSD...
...that is: "free to experiment! No need to halt and reflash on errors"...
Click to expand...
Click to collapse
Wow, 8 MB ? Is that really useful ? I read somewhere that 3 MB is optimum, 4 MB is slightly waste. 8MB ? Then again I might be wrong, never tried 8MB myself.
It's a good thing you come up with this doc. I read at stepph's thread how you MOVED /system to MicroSD but somehow I forgot to ask. Now you mentioned it here. Is it safe ? No i/o bottleneck / noticeable lag ? I know we'll need a really fast and reliable MicroSD card. What's yours doc ?
---------------------------------
Sent from my Samsung Galaxy Mini GT-S5570 via xda-dev app
CyanogenMod 7.2.0-RC4-KANG by squadzone
Doc,
Now this just came across my mind. With /system and /data in MicroSD, does this mean we can MULTIBOOT ?
Let's say I partitioned my sdcard into 5 : 1st one is FAT32 and the other 5 is ext4. I modified boot.img from (let's say) CM7 and stock GB. On CM7's init.rc i put /system and /data into partition 2&3. On stock GB's init.rc i put them into partition 4&5. Partition 6 is used for /cache. I flashed stock with modded boot.img, play around first. Then I flashed CM7 with modded boot.img and played around. Now each time I want to switch ROM, all I have to do is flash the appropriate boot.img using CWM. This boot.img will determine which partition will be used for /system and /data.
Could it work doc ?
---------------------------------
Sent from my Samsung Galaxy Mini GT-S5570 via xda-dev app
CyanogenMod 7.2.0-RC4-KANG by squadzone
Read Ahead...
distan7 said:
Wow, 8 MB ? Is that really useful? I read somewhere that 3 MB is optimum, 4 MB is slightly waste. 8MB? Then again I might be wrong, never tried 8MB myself...
Click to expand...
Click to collapse
Antutu Benchmark Total Result on my Stock ROM with a 4Gb SD Class 4 said about 1650...
After moving (without tuning filesystems...) Antutu Said about 1450...
After Amarullz reading I remounted my filesystem from the shell this way:
Code:
# busybox mount -o remount,nosuid,nodev,noatime,nodiratime,errors=continue,nouser_xattr /cache (ext2 filesystem)
# busybox mount -o remount,ro,noatime,nodiratime,nouser_xattr,barrier=1,data=ordered,noauto_da_alloc /system (ext4)
# busybox mount -o remount,noatime,nodiratime,nouser_xattr,barrier=1,data=ordered,noauto_da_alloc /data (ext4)
#
Left commit=15 backwards, but I'll put it in the new init.rc of patched boot images... I also set barrier, data order and extended attributes, even if defaults...
and Antutu said about 1550...
Actually I'm trying on the fly this tweak
Code:
# busybox echo "[b]8192[/b]" > /sys/devices/virtual/bdi/179:0/read_ahead_kb
#
While googling for optimum value...
And Antutu said about 1600
Now I'm trying to stress the system with heavy loads from/to SDCard...
...Anyway I cannot say anything yet about Battery charge..
van8x10 said:
Please do it ASAP, thanks
Click to expand...
Click to collapse
...Boot images are ready to be shared with these patches on, but I need to test them one by one... I think to be Ready within tomorrow night...
midomad said:
i have s5570jpks1 in pda...
Click to expand...
Click to collapse
Found and patched 2.3.5 fimware S5570JPKS1 with these tweaks too... scheduled to be tested within tomorrow night too...
distan7 said:
...I read at stepph's thread how you MOVED /system to MicroSD but somehow I forgot to ask. Now you mentioned it here. Is it safe ? No i/o bottleneck / noticeable lag ? I know we'll need a really fast and reliable MicroSD card. What's yours doc?
Click to expand...
Click to collapse
It is safe... Up and running very heavy since last month...
Bottlenecks and lags occurr when I stress /data writing and /system reading while /cache is working... sometimes happens...
As I said somewhere else, if You like to play with your phone dont do it! but...
...if you like (for example) to test firmwares or play around deep inside the system without flashing anything and resuming from errors whenever you want... I call it "a Must Option"
I don't have a fast SD card (now on 4Gb class 4 and very old sailor...) so I cannot compare lags and performance for now with faster memories...
distan7 said:
...With /system and /data in MicroSD, does this mean we can MULTIBOOT ?
Let's say I partitioned my sdcard into 5 : 1st one is FAT32 and the other 5 is ext4. I modified boot.img from (let's say) CM7 and stock GB. On CM7's init.rc i put /system and /data into partition 2&3. On stock GB's init.rc i put them into partition 4&5. Partition 6 is used for /cache. I flashed stock with modded boot.img, play around first. Then I flashed CM7 with modded boot.img and played around. Now each time I want to switch ROM, all I have to do is flash the appropriate boot.img using CWM. This boot.img will determine which partition will be used for /system and /data...
Click to expand...
Click to collapse
I'm working on this in my spare time... Actually - without flashing anything - I cannot change kernel from one boot to another one, but via init.rc I could start following something written somewhere on /cache or /sdcard...I could - for example - shutdown CM7 saying that I want to boot (next time) to Stock GB and viceversa...
I'm not a True Developer (Long time ago I said "Hello World" to somebody but I don't know if I will be able to do it) but I'm trying to start the system asking to th euser what to do during the boot stage...(Hard Task for me, but why not...)
Doc_cheilvenerdi.org said:
Antutu Benchmark Total Result on my Stock ROM with a 4Gb SD Class 4 said about 1650...
After moving (without tuning filesystems...) Antutu Said about 1450...
After Amarullz reading I remounted my filesystem from the shell this way:
Code:
# busybox mount -o remount,nosuid,nodev,noatime,nodiratime,errors=continue,nouser_xattr /cache (ext2 filesystem)
# busybox mount -o remount,ro,noatime,nodiratime,nouser_xattr,barrier=1,data=ordered,noauto_da_alloc /system (ext4)
# busybox mount -o remount,noatime,nodiratime,nouser_xattr,barrier=1,data=ordered,noauto_da_alloc /data (ext4)
#
Left commit=15 backwards, but I'll put it in the new init.rc of patched boot images... I also set barrier, data order and extended attributes, even if defaults...
and Antutu said about 1550...
Actually I'm trying on the fly this tweak
Code:
# busybox echo "[b]8192[/b]" > /sys/devices/virtual/bdi/179:0/read_ahead_kb
#
While googling for optimum value...
And Antutu said about 1600
Now I'm trying to stress the system with heavy loads from/to SDCard...
...Anyway I cannot say anything yet about Battery charge..
...Boot images are ready to be shared with these patches on, but I need to test them one by one... I think to be Ready within tomorrow night...
Found and patched 2.3.5 fimware S5570JPKS1 with these tweaks too... scheduled to be tested within tomorrow night too...
It is safe... Up and running very heavy since last month...
Bottlenecks and lags occurr when I stress /data writing and /system reading while /cache is working... sometimes happens...
As I said somewhere else, if You like to play with your phone dont do it! but...
...if you like (for example) to test firmwares or play around deep inside the system without flashing anything and resuming from errors whenever you want... I call it "a Must Option"
I don't have a fast SD card (now on 4Gb class 4 and very old sailor...) so I cannot compare lags and performance for now with faster memories...
I'm working on this in my spare time... Actually - without flashing anything - I cannot change kernel from one boot to another one, but via init.rc I could start following something written somewhere on /cache or /sdcard...I could - for example - shutdown CM7 saying that I want to boot (next time) to Stock GB and viceversa...
I'm not a True Developer (Long time ago I said "Hello World" to somebody but I don't know if I will be able to do it) but I'm trying to start the system asking to th euser what to do during the boot stage...(Hard Task for me, but why not...)
Click to expand...
Click to collapse
thanks a lot bro i can't wait for you're boot img
Upgrade Complete!
Upgrade completed and new boot images uploaded.
Also added S5570JPKS1 to the list!
init.data.sh changed to
Code:
#!/sbin/busybox sh
if /sbin/busybox [ -e /sys/devices/virtual/bdi/179:0/read_ahead_kb ]
then
/sbin/busybox echo "[b]3072[/b]" > /sys/devices/virtual/bdi/179:0/read_ahead_kb
fi;
/sbin/busybox mount -o [b]noauto_da_alloc,data=ordered,commit=15,barrier=1,nouser_xattr,errors=continue,noatime,nodiratime[/b],nosuid,nodev -t ext4 /dev/block/mmcblk0p2 /data || /sbin/busybox mount -o nosuid,nodev -t rfs /dev/stl13 /data
Enjoy again!
P.S. +10% Performance!
Doc_cheilvenerdi.org said:
Upgrade completed and new boot images uploaded.
Also added S5570JPKS1 to the list!
init.data.sh changed to
Code:
#!/sbin/busybox sh
if /sbin/busybox [ -e /sys/devices/virtual/bdi/179:0/read_ahead_kb ]
then
/sbin/busybox echo "[b]3072[/b]" > /sys/devices/virtual/bdi/179:0/read_ahead_kb
fi;
/sbin/busybox mount -o [b]noauto_da_alloc,data=ordered,commit=15,barrier=1,nouser_xattr,errors=continue,noatime,nodiratime[/b],nosuid,nodev -t ext4 /dev/block/mmcblk0p2 /data || /sbin/busybox mount -o nosuid,nodev -t rfs /dev/stl13 /data
Enjoy again!
P.S. +10% Performance!
Click to expand...
Click to collapse
it's a little slowly but working like a charm
you're a life saver
Some apps run very slowly, especially import contacts from SD (file .vcf)!
(My Rom is the GingerBread Europe 2.3.6 PDA=S5570JVKT1)
Nice. Some interesting stuffs are really coming out from our forum I will give these mount option a shot.
I will try to convert /system and /cache to ext2 and leave /data as ext4 as system is mounted as r/o as default and cache can be formatted anytime.
I recommend you not to flash boot image for the ROM 2.3.6 PDA=S5570JVKT1. I've come back the original boot image!
van8x10 said:
I recommend you not to flash boot image for the ROM 2.3.6 PDA=S5570JVKT1. I've come back the original boot image!
Click to expand...
Click to collapse
Why? You must explain reasons ...
denzel09 said:
Why? You must explain reasons ...
Click to expand...
Click to collapse
Simply for me, some apps run very slowly:
- It took me ~1 hour to import contacts from vcf file on SD card
- When I was testing the Expense Manager App, My Phone Shutdown for unknown reason (not reboot), luckily not yet bricked
- I think It is not safe for me, then wait for a new version from Doc!
hey can u pls tell me how to do it?or can u pls do it for samsung galaxy ace?
Beta Testing...
van8x10 said:
Some apps run very slowly, especially import contacts from SD (file .vcf)!
(My Rom is the GingerBread Europe 2.3.6 PDA=S5570JVKT1)
Click to expand...
Click to collapse
How I Test all the boot images before sharing them
When I power on the phone the hardware bootstrap passing soon after the control to the (using PC terminology) BIOS (Basic Input OutPut System)... a sort of mini system used to poweron all the peripherals inside and related to the phone... (In my Galaxy Next - briefly - I find something similar in the code sequence mibib-qcsbl-oemsbl-amss-arm11boot)...
...Immediately after, the BIOS loads into memory the Kernel in a fixed position and an initial ramdisk (in a fixed position too) and leave control to the kernel...
...the kernel setup the ramdisk and use the second mini system inside to complete the boot stage...
...Finally the kernel - using commands in the ramdisk - give control to the real system - GingerBread.
Actually the Bios releases control to the kernel calling a routine starting always from a fixed point hardcoded in itself and the Kernel launch the system (wherever it is) looking in the init files inside the ramdsik...
While slightly upgrading GingerBread from 2.3.0 to 2.3.* the mid part of the full boot sequence (kernel + ramdisk) need only two things to work properly:
Kernel compiled with the first assembly code starting from the fixed position hardcoded in the Bios
init files in the ramdisk showing where the filesystem and its data are...
Finally: All boot.img of GingerBread flavours meet these prerequisites... so I can easily use anyone of them with my system (or any other minor version of Ginger) while my BIOS call the kernel and it is in the right place and the init files exit to the filesystem where it really is...
I simply flash one of the shared boot images and test it three times:
power on with micorSD outside (system boot as usual)
power on with microSD inside and /data empty (the system fill it with all what is needed)
power on with microSD already full of apps, userdata and cache
I check mount points, SD read ahead, browse something on Internet, Market...
...and Finally I feel comfortable with the image cooked...
...I can share It!
Why didn't I said that you can use any of the shared boot images
If I simply call the boot image (for example)
CODE_S5570DOC01_boot.tar.md5
probably several end users (not heavy skilled with Linux, boot, Android, etc...) could be scared to use it...
... so I decided to provide an image for any of the "most wanted versions" now on the network using the attached kernel (anyway slightly different each other) with the same name of the Stock Version...
How I handle Errors reported from end users
van8x10 said:
Simply for me, some apps run very slowly:
- It took me ~1 hour to import contacts from vcf file on SD card
- When I was testing the Expense Manager App, My Phone Shutdown for unknown reason (not reboot), luckily not yet bricked
- I think It is not safe for me, then wait for a new version from Doc!
Click to expand...
Click to collapse
With my Wind boot.image first, and then with the JVTK1 one, I did what follows:
First Test
I exported my contacts to SD twice (about 2 minutes every time)
I imported it four times from SD without overwriting existing ones (about 1 minute to 2 minute at last) growing it to 400 entries
I exported and Imported them again (2 +2 minutes)
Test made with both the boot images - same result
Second Test
I own Titanium Backup PRO so I performed a backup of 98 apps (about 200Mb mixed from /system and from outside /data) to SD (4-5 minutes)
I repeated 3 times forcing the full operation (always about 5 minutes)
I Verified the backups towards original apps (3-4 minutes) (Found 2 errors related to WiFi in both boot images)
I restored 25 apps (this time only the ones stored on the outside /data - left untouched /system); I needed 10-12 minutes to reinstall them while dr web light antivirus was underneath scanning them. (Market crashed once in JKVT1 boot image)
Third Test
Called friends by Phone,
Sent some SMS to them,
Whatsapped them too,
Browsed xda-developers forum with Opera Mobile and Tapatalk.
Fourth Test
Don't do it!
I started "via emulator terminal" to dump a 100Mb wide file copying from /dev/zero...
while writing to SD I removed it crashing the system...
All fine after reboot... but (I'll soon post about what I'm saying) I suggest to use tools like fsck for errors out of journals...
Last Test
I own a Very old SD (1Gb) at the end of its lifecycle...
Every time I use it, bad blocks appear... timing readouts... freezing PC ports where connected...
...so I consider it a very bad hardware...
...but very useful for extreme tests of hardware/software endurance...
I made this test only with JVKT1 anyway...
I prepared the 2 partitions in it on my Linux PC (system froze twice then I was able to write partion table and format them)...
...Power On the phone with SD inside...
...adb shell and ddms connected to follow the de-wipe operation from PC..
...needed 40 minutes to complete it...
...frustrating...
...the System ended up and running anyway...
Conclusions
I think that the problem noticed should be investigated outside the boot stage of Ginger JVKT1 image...
How I cook the boot images
The images to deal with are growing up (just preparing XXKPI) so I prepared a Batch Farm used to do the dirty job avoiding human errors...
...Obviously I check pre and post by Hand...
...Test on My Next...
...Share...
Once the Script will be STANDALONE FUNCTIONALE I'll share it too!
van8x10 said:
...luckily not yet bricked ...
Click to expand...
Click to collapse
No luck needed here...
Studying Brick deep inside, while the Flash operation doesn't touch the first BIOS code (mibib, ecc...), if I don't make mistakes with Tass.ops or images too big I cannot really Brick while flashing...
...obviously I can always kill definitely my system with a wrong root command...
...All situations that I can resolve at last using Odin again...
parasmi said:
Nice. Some interesting stuffs are really coming out from our forum I will give these mount option a shot.
I will try to convert /system and /cache to ext2 and leave /data as ext4 as system is mounted as r/o as default and cache can be formatted anytime.
Click to expand...
Click to collapse
Good Hint! Why do I need to journal a filesystem read only... I think I can deal with it occasionaly while readwriting something to it anyway!
THANKS!
when i want to use my phone on start up: keep rebooting many times and after that it works
any idea DOC?
MIUI: http://www.mediafire.com/?oqvzpc61x3s5w44
GApps: http://www.mediafire.com/?1c2br6sw6330lwn
These flashable zips and corresponding procedure are intended for intermediate to advanced users, i.e. those who have 1) unlocked their Atrix, 2) partitioned their SD card for dual boot, and 3) have a working knowledge of ClockWorkMod (CWM) Recovery and how to install and configure dual boot. If you are not in this category or would simply like a refresher, you can review some of my other threads on this topic, namely:
Dual Boot threads:
http://forum.xda-developers.com/showthread.php?t=1651356
http://forum.xda-developers.com/showthread.php?t=1642185
http://forum.xda-developers.com/showthread.php?t=1645344
Please understand this MIUI port is not a “dual boot flashable zip” (DBFZ); rather it is a single boot flashable zip of MIUI ported to SD card. However it should preserve your existing primary ROM (ROM1) along with /cache and /data, and thus is actually more versatile than DBFZ which gives you two ROMs that you may not even want.
I strongly recommend that after flashing MIUI, you first reboot to MIUI before flashing GApps.
To reboot to ROM1 after installing MIUI, you could fastboot flash a ROM1 boot image (easiest and fastest way), or configure dual boot as described here ( http://forum.xda-developers.com/showthread.php?t=1645344 ) . I have often found it convenient to simply extract the /Boot directory of an existing DBFZ and customize from there by inserting the boot images of my choice.
If you presently have dual boot and need to wipe the /cache and /data partitions of your second ROM (ROM2) before installing MIUI, then CWM-flash these zips:
Wipe /cache: http://www.mediafire.com/?mc881zjhl9oqr0q
Wipe /data: http://www.mediafire.com/?4k4fey6gxe1nbn0
Now you may be wondering... How do I backup an existing ROM2 since stock recovery tools cannot backup an SD card-based ROM? Here is one way:
Boot phone to CWM 5.0.2.0, connect it to ADB-enabled computer and enter:
Code:
adb devices (make sure device is listed)
adb shell (should get # sign, indicating “root” on Android)
umount /cache (since internal memory /cache is mounted by default)
mount /sdcard
mkdir /sdcard/ROM2-backup
cat /dev/block/mmcblk1p2 /sdcard/ROM2-backup/system.img
cat /dev/block/mmcblk1p3 /sdcard/ROM2-backup/cache.img
cat /dev/block/mmcblk1p4 /sdcard/ROM2-backup/data.img
Standard disclaimers apply. In short, I am not responsible for any harm you or your phone may incur by using any or all of this material.
Many thanks to stevendeb25 (MIUI ported to Atrix), www.angeeks.com (GApps), the CM/Photon/Atrix/Android dev teams and to Koush (CWM Recovery).
yeah....downloading...
tks mate,tks very much,u make my wish come true and every one here who love miui,is there any way i can help u 'cause i dont have visa to donate for u
Sent from my MB860 using Tapatalk 2
mafiarock93 said:
tks mate,tks very much,u make my wish come true and every one here who love miui,is there any way i can help u 'cause i dont have visa to donate for u
Sent from my MB860 using Tapatalk 2
Click to expand...
Click to collapse
Thank you... I am so glad to know that you and your friends can benefit in some way from this little project.
If you have PayPal, you can click the "Donate to me" button, and it takes you to my PayPal donation site. I would probably use the funds to buy a faster SD for experimentation.
Take care.
/cache folder - 541 MB free space
/dalvik-cache - 400 MB something (approx. 120 apps, CM13 snapshot, Helium v27 kernel, opengapps pico installed)
What I did:
1) Moved /data/dalvik-cache folder to /cache
2) CHMOD /cache/dalvik-cache folders and files like original as in /data/dalvik-cache. I did it twice using ES Explorer and then terminal in recovery with superuser access so that it doesn't get back to original.
3) Boot in Recovery -> Terminal
Code:
su
busybox chown 1000.1000 /cache/dalvik-cache
ln -s /cache/dalvik-cache /data/dalvik-cache
sync
Now, after reboot, phone either gets stuck in bootloop or "preparing to start".
Other things I tried:
"To get it working just wipe dalvik cache in cwm, it will re-create directory in /data."
- This didn't work for me. System was unable to create folders in /cache on boot.
Possible Reasons and Solutions:
1) There is an init file which "forcefully" moves dalvik-cache back to /data.
2) The cache directory NEEDS 655 permissions otherwise you'll be stuck in a boot loop or everything will force close.
3) The permissions are reset on reboot.
4) The only way to really do it is to chmod during boot, you'll need init.d capability for that.
These are the things I could collect. Anybody please let me know how to fix this?
Tried init method
kkumar326 said:
/cache folder - 541 MB free space
/dalvik-cache - 400 MB something (approx. 120 apps, CM13 snapshot, Helium v27 kernel, opengapps pico installed)
What I did:
1) Moved /data/dalvik-cache folder to /cache
2) CHMOD /cache/dalvik-cache folders and files like original as in /data/dalvik-cache. I did it twice using ES Explorer and then terminal in recovery with superuser access so that it doesn't get back to original.
3) Boot in Recovery -> Terminal
Code:
su
busybox chown 1000.1000 /cache/dalvik-cache
ln -s /cache/dalvik-cache /data/dalvik-cache
sync
Now, after reboot, phone either gets stuck in bootloop or "preparing to start".
Other things I tried:
"To get it working just wipe dalvik cache in cwm, it will re-create directory in /data."
- This didn't work for me. System was unable to create folders in /cache on boot.
Possible Reasons and Solutions:
1) There is an init file which "forcefully" moves dalvik-cache back to /data.
2) The cache directory NEEDS 655 permissions otherwise you'll be stuck in a boot loop or everything will force close.
3) The permissions are reset on reboot.
4) The only way to really do it is to chmod during boot, you'll need init.d capability for that.
These are the things I could collect. Anybody please let me know how to fix this?
Click to expand...
Click to collapse
I tried init edit, busybox commands and manual edit to change cache folder's chmod but it goes back to default. This is the root cause because without restart it's working normal. After restart only it's stuck because chmod is changing back to default. Any solutions to keep it edited?
@Tomoms Hey, just to let you know I tried few more things:
1) Extracted boot.img from CM13 ROM and changed "chmod 775 /cache", "chown system system /cache" and added, changed few more things for dalvik-cache in /cache as in /data/dalvik-cache. Recompiled boot.img and flashed it with ROM.
2) Result: /cache folder finally changed to 755 with system system control. Got dalvik-cache folder in /cache, same as in /data folder. I linked dalvik-cache from /data /dalvik-cache and it still didn't work.
This is really strange. I've been trying these tweaks for last 4-5 days and it still isn't working. I think /cache folder is clearing itself on starting of device. Though, I did't find any such thing in boot.img.
kkumar326 said:
@Tomoms Hey, just to let you know I tried few more things:
1) Extracted boot.img from CM13 ROM and changed "chmod 775 /cache", "chown system system /cache" and added, changed few more things for dalvik-cache in /cache as in /data/dalvik-cache. Recompiled boot.img and flashed it with ROM.
2) Result: /cache folder finally changed to 755 with system system control. Got dalvik-cache folder in /cache, same as in /data folder. I linked dalvik-cache from /data /dalvik-cache and it still didn't work.
This is really strange. I've been trying these tweaks for last 4-5 days and it still isn't working. I think /cache folder is clearing itself on starting of device. Though, I did't find any such thing in boot.img.
Click to expand...
Click to collapse
Hey, there's definitely something in the init files that move the dalvik cache to /data at boot. I've found it and I can change it for you using a flashable zip. Wait for my next PM.
Hey.
Yes our 8960 devices have quite a big cache, most newer devices no longer have such a cache.
We already talked about remapping the dalvik-cache to the /cache partition with a symlink,
as it's handled by init.rc to create an actual folder & could be changed to link cache.
However, though it can seem like a good idea, it would anyhow end up with a filled cache partition,
when users have a lot of apps it will fill quite fast, I already have 200-300MB with my daily apps,
heavy gamers and apps installer will end up with a stuck situation & it would introduce new issues.
Handling a dual target to fill cache, then data, and to handle this all
would add additional complexity, load and potential issues.
Also that cache is used through the recoveries for updates & stuff so free space needed in it.
Things evolved quite a lot since 4.3 with ART .
You could do it manually, but every update would need to be patched & all..
Can anybody explain why isn't there a wipe system option in the twrp in advanced wipe section...
In earlier devices that I've used ,the wipe system option has always been there.
Or is this happening only in the nebrassy recovery for sweet?
just a query!
Same question.. Can an expert answer this? Thanks
In my opinion normally it's not needed and for newbie it's dangerous
- I'm no expert at all, but missing option for wipe /system is not there for a reason (on my previous surya device (when it was launched) the first builds of recoveries had option to wipe /system, but people find out very quickly that wipe /system on super partition is not a good idea, very few ended with bricked devices, after that wipe /system was removed from recoveries)
- on A9 /system had its own partition and very simply put - it was easy to manipulate, situation changed with A10 (A11), when /system become like virtual partition (along with /vendor, /product and whatever manufacturer of the phone decided to put there) or directory if you like in super partition and its RO by default (unless flashing to it, you can't manipulate it directly on file system level - every wipe option in recovery means you simple delete some files here and there and you can't delete files on Read Only virtual partition)
- problem is much more complicated and I'm explaining it as I understand it - I can be wrong on detail, but this is roughly the situation
- if you're active tester and/or flashaholic who likes to test ROMs as they are released it is a good idea to flash (before you flash new custom ROM) either recovery version of latest MIUI available for your device (or maybe Xiomi.eu ROM based on that) - inclueded installation scripts will clean your super partition to the certain level - so you can for example flash stubborn ROM, that refused boot so far, etc. - its not wipe and I agree - clean slate is always better, than breadcrumbs of the previous flashes left here and there, but here we are...
- sure - direct control over /system part of super partition would be nice - and I hope that one day TWRP or OFOX devs will tame that "super" beast and return wipe /system when it will be safe for us to use it as before...