Related
Features
- external data.img support.
- update kernel and system files without adb.
- easily update build with update.zip, don't have to re-flash.
- options to set data.img size, lcd density, etc in config file.
To enable external data.img
1. create '.data' folde under sdcard (/sdcard/.data).
2. create 'config.txt' under '.data' directory, add 'data_img=1' into 'config.txt'.
3. copy old data.img to '.data' directory, otherwise a new data.img will be created.
4. boot into Android.
If experiencing issue with 1 and 2, simply copy '.data' from View attachment data.zip to sdcard.
To disable external data.img
- delete 'data_img=1' in config.txt.
- delete config.txt.
To change kernel and modules
1. create 'update' folder under sdcard (/sdcard/update).
2. create 'boot' folder under 'update' directory, put zImage into 'boot'. (reboot is needed after updating)
3. create 'system/lib/modules' under 'update' directory, put bcm4329.ko, tun.ko, etc into 'modules'.
4. boot into Android.
To replace initrd.gz and system files
- same as change kernel and modules.
- put 'initrd.gz' under '/sdcard/update/boot'. (reboot is needed after updating)
- put system files under '/sdcard/update/system'.
To use update.zip
- create an update.sh and compress it with update files to update.zip.
- put update.zip under 'sdcard/update'.
- Try ClockworkMod Recovery for HD2
Downloads
- View attachment leo-initrd-0.1.1.zip
- if you want to test the ramdisk, download this build package. Don't forget to backup your data. (thanks to projection for the kernel)
If you've downloaded LEO-CM6.1.1-NAND-3.zip, to update to 3.1, please download the new initrd file, then try the update method above.
To do
- add desire builds support
- add squashfs support
Changes
0.1.1 - fix a stupid typo, sorry.
0.1 - initial.
About config.txt
Code:
data_img=0
- 0, default, use nand userdata, about 250 MB for cm builds
- 1, enable external data.img support (/sdcard/.data/data.img)
data_size=512
- size of data.img, only work when data.img support enabled and first install
data_sync=1
- 0, fast, default, disable sync option when mount data.img
- 1, safe, enable sync option when mount data.img, use this if experiencing data corruption
lcd_density=240
- size of icons
gps_zone=us
- country code, us, fr, jp, etc
Credit to DarkForces Team and everyone in this thread.
that will be very usefull one.another massive milestone in android-hd2 development.cheers
I'm just downloading RAM DISK build... why You strike it ? shoudn't I install it ?
it is becoming obvious that this will be essential for euro H2 NAND builds being that there is very little phone space to play with, where this would be best cooked into ROMs more detailed instructions for noobs would be good.
This is a great idea and will help with the euro versions of hd2 with limited space.
I wonder what will happen with sync, will we run into data corruption problems as with sd builds?
Can this be made so as the data can be on a seperate ext 3/4 partition in sync and the rest of the sdcard can be mounted / unmounted etc ?
DavidX_07 said:
I'm just downloading RAM DISK build... why You strike it ? shoudn't I install it ?
Click to expand...
Click to collapse
Found a stupid typo... will be back soon.
getting back on the horse Kouno? =P
d/l and will test it later
I need to update from your nandv1
had problems with your nandv2, can't change system/lib to r/w
Time to test nandv3
ikkon said:
getting back on the horse Kouno? =P
d/l and will test it later
I need to update from your nandv1
had problems with your nandv2, can't change system/lib to r/w
Time to test nandv3
Click to expand...
Click to collapse
Please download later since it is not available right now.
The lib and xbin is compressed with squashfs in v2, so you can't edit. That's just for test propose. And squashfs file systems have been removed in v3.
i love your job HD2One.
great idea
Is it become to HD2NAND?
LondonTownGuy said:
Can this be made so as the data can be on a seperate ext 3/4 partition in sync and the rest of the sdcard can be mounted / unmounted etc ?
Click to expand...
Click to collapse
I'm new to Android builds configuration, but after some research it looks like it's possible in theory. Personally I do not understand why everyone is so obsessed in data.img file, while it's linux partition in file, that stored on FAT partition. I think actual linux partition on sd card is more elegant solution.
lcd_density=xxx not changing dpi
DavidX_07 said:
lcd_density=xxx not changing dpi
Click to expand...
Click to collapse
Right, it is a typo issue and fixed in 0.1.1.
Please download the new initrd file, then try the update method, tell me if it works
hey Kouno
I just hope you know that Window users can't name a folder that starts with "."
We can always find a way but just giving you the heads up
Ready to Quadrant v.3.1
Kouno.Takaaki said:
Right, it is a typo issue and fixed in 0.1.1.
Please download the new initrd file, then try the update method, tell me if it works
Click to expand...
Click to collapse
Yup, it works BTW blazing fast, testing more now
ikkon said:
hey Kouno
I just hope you know that Window users can't name a folder that starts with "."
We can always find a way but just giving you the heads up
Click to expand...
Click to collapse
I know, so I've provided data.zip and .data folder in the flash package.
Why I use .data instead of data or data2sd? Just want to keep it hidden.
Using the Ramdisk file, when I first turn on the device.
Code:
# cat /proc/meminfo | grep "MemFree"
cat /proc/meminfo | grep "MemFree"
MemFree: 273232 kB
And 5 minutes later.
Code:
# cat /proc/meminfo | grep "MemFree"
cat /proc/meminfo | grep "MemFree"
MemFree: 25596 kB
Memory gets really low, I wonder why?
EDIT: Could just be me. :s
SystemPanel shows 270MB free ram
shadiku said:
Using the Ramdisk file, when I first turn on the device.
Code:
# cat /proc/meminfo | grep "MemFree"
cat /proc/meminfo | grep "MemFree"
MemFree: 273232 kB
And 5 minutes later.
Code:
# cat /proc/meminfo | grep "MemFree"
cat /proc/meminfo | grep "MemFree"
MemFree: 25596 kB
Memory gets really low, I wonder why?
Click to expand...
Click to collapse
Try 'free' command or check the cached memory size.
updating works fine...
framework-res.apk updated succesfull
Sorry , may i ask a stupid question ?
does it work on MDJ Revolution HD v.2.2 build ?
my English is not good !
Sorry for ask this
Didn't see much on this as I was looking around today, so I decided to post my eventual fix:
After first setting up froyo on my Rhodium 400, I was having alot of issues with the phone running out of memory and crashing, so I ended up adding a swap partition. Below is an easy way to do this and have the swap mounted at boot without having to use an external app like swapper:
NOTE - before doing this I suggest that you copy rootfs.img from your SD card onto your computer, and then copy it back once you're finished. I also suggest you make a backup copy of rootfs (rootfs.img.backup etc) before trying mods like this so you can recover your file system if something goes wrong.
on a linux machine, make a mount point and mount the kernel image as a loop device:
Code:
mkdir /mnt/mounthere
mount -o loop rootfs.img /mnt/mounthere
cd into mount point you created (ie, cd /mnt/mounthere) and list the contents with ls. You'll see something like this:
Code:
acct dbgfs init.cfg mnt shared_prefs
bin default.prop init.etc proc sqlite_stmt_journals
cache dev init.rc res sys
config etc installer sbin system
d init lib scripts tmp
data init.android lost+found sdcard ueventd.rc
you want to open the script init with a text editor like nano and add the following lines just before the line that says exec /init.android:
Code:
modprobe ramzswap
swapon /dev/block/mmcblk0p2
where /dev/block/mmcblk0p2 is a pre-created linux swap partition on your SD card.
Once you're done, simply unmount rootfs.img and copy it back onto the SD card you're using for android
Its a pretty simple solution that I've found to make my own phone much more stable and responsive, and you only have to worry about it once. The downside is that on slower sd cards, the phone may slow to a crawl when installing apps, but hey, it beats the phone locking up and crashing back to windows mobile, right?
This really is not needed if you are running the latest versions of everything (and using XDANDROID). If you are experiencing problems with the full official latest version of everything (all info is in the thread in my sig) make sure you post in the ANDROID section
This guide is based on a guide by Candanga on the i9000 forums, and some commands from supercurio
Please hit thanks on their posts and show them some love for the write up.
-----------------------------------------------------------------------------------------------------------------------
I’ve compiled a quick guide to instruct how to make a copy of the /efs folder. I’ve found in many threads suggestions about backing up this folder but the methods itself are very general. Most of the times they suggest to “root and copy the folder” with Root Explorer or similar, but usually it’s not that easy or it just doesn't work for everyone.
This guide ASUMES you have read this Excellent Guide by Darkstrikerfirst:
H E R E <-- Make sure to read the ADB Guide.
I recommend doing this with a Mobile just taken out of the box or with any Official ROM of its Service Provider. If you have already Flashed your phone with another ROM but its working fine, then you can use that /efs also.
Why the /efs folder?
This is a very sensitive system folder that contains Phone-specific information such as the IMEI (encrypted in the nv_data.bin), wireless devices MAC addresses, product code (also in the nv_data.bin), and much more. Often users trying to change product codes or trying to unlock the mobile will end up corrupting data in this location.
Why back it up?
Well, let’s resume it saying that backing-up this little folder will keep you away from Samsung service centres.
***WARNING: I take no responsibility to any damage caused by the methods cited and/or written here. Their sole purpose is to back-up data and not to alter in any way the integrity of the original files of the mobile***
What you will need:
Rooted SGS II to get permissions as a SU (Super User) and perform the backup
I would suggest learning a little about the terminal commands used (in case you are not familiar with them), as it’s better to know what you are doing rather than typing strings like a little chimp without knowing what they are; if you are a little lazy, then you have a good chance bricking your mobile. <- Busybox Commands(or Google them)
Terminal Emulator by Jack Palevich (available from the market) <-Terminal Emulator or use ADB which is included in the SDK Development Tools
The standard prompt of terminal (adb) is a $ sign. Once you enter “SU” it will become a # Sign.
***NOTE: Make sure to keep an eye on the screen of your SGS II during this process, because it may request SU permissions [currently doesn't on CF-root]; else, you will get an error (just if it’s the first time). In Terminal Emulator you will need to reset the app after granting permissions cause it usually freezes***
*Remember: to use ADB you need to enable USB DEBUGGING under Applications/Development in your SGS II.
Here are 3 methods, I recommend that you do both Clean and RAW.
Basic, unix permissions lost :
Code:
su
busybox cp -a /efs /sdcard/efs/
Clean :
Code:
su
busybox tar zcvf /sdcard/efs/efs-backup.tar.gz /efs
After this, you will end up with the file efs-backup.tar.gz in your INTERNAL SDCARD in sdcard/efs/, which is a “tarball” or a ZIP of the /efs folder. That file is your backup. You can expand it with Winrar.
You can also back up the mmcblk0p1 (where /efs is stored) under /dev/block which can greatly support in recovering your IMEI in case of a screw-up:
RAW :
Code:
su
cat /dev/block/mmcblk0p1 > /sdcard/efs/efs_dev-block-mmcblk0p1.img
Same thing, the target is the INTERNAL SDCARD in sdcard/efs/, so go ahead and copy the file.
+1 just do it....
Can this not be tasked by using a root file explorer and copying efs folder as i have always done .
jje
JJEgan said:
Can this not be tasked by using a root file explorer and copying efs folder as i have always done .
jje
Click to expand...
Click to collapse
From the thread:
I’ve found in many threads suggestions about backing up this folder but the methods itself are very general. Most of the times they suggest to “root and copy the folder” with Root Explorer or similar, but usually it’s not that easy or it just doesn't work for everyone.
Click to expand...
Click to collapse
And just copying the folder won't preserve permissions etc.
JJEgan said:
Can this not be tasked by using a root file explorer and copying efs folder as i have always done .
jje
Click to expand...
Click to collapse
As long as you don't copy it to /sdcard, because it's VFAT and you'll lose the permissions settings on the files. If you copy it to /data or something then that's fine.
bumpity bump
RyanZA said:
As long as you don't copy it to /sdcard, because it's VFAT and you'll lose the permissions settings on the files. If you copy it to /data or something then that's fine.
Click to expand...
Click to collapse
Thanks the SGS 1 EFs i copied was copied to external sd card and then copied off to PC . Did likewise on SGS 2 using Super Manager .
So according to what you are saying that was not going to back up if needed .
jje
JJEgan said:
Thanks the SGS 1 EFs i copied was copied to external sd card and then copied off to PC . Did likewise on SGS 2 using Super Manager .
So according to what you are saying that was not going to back up if needed .
jje
Click to expand...
Click to collapse
It would probably have worked, but it would have made your EFS files readable and writable by any app that tried - not the end of the world since it's unlikely that any apps would try, but you still might as well avoid it if you can. I don't think there are any executables in EFS or anything that this will actually break though.
Thanks i did lose IMEI at one flash on SGS1 but a second flash recovered it .
I do like full backup of original firmware and anything else before playing with phone .
jje
I've done all 3 forms of backup myself. . Clean, raw and basic
thanks for the info. have had close calls previously and having backups would have helped ease the stress
Updated first post
Vodafone Fimrware backup BUKE1
Guys,
Have got a new samsung from Vodafone UK , but the firmware kernel seems a bit different, BUKE1. Is this something now and is the above method correct to backup the entire firmware so that it might be useful for vodafone samsung users. Is there an easy guide to backup the firmware ?
Regards
VJ
Guys can someone give me a bit of advice pleeeease
I followed this guide but am a bit worried i might have messed it up, i'm comfortable with command prompt as i'm a software dev but haven't used linux commands much.
Anyway i used the ADB shell from the Android SDK tools and entered the first command to backup the efs directory to the internal sdcard....
Basic, unix permissions lost :
Code:
su
busybox cp -a /efs /sdcard/efs/
Click to expand...
Click to collapse
And i got a lot of
Code:
cp: can't preserve ownership of 'sdcard/efs/...' : Operation not permitted
messages flashing up?
However i checked to see if the backup had been made and it had? What does this mean?
Next i compressed it using...
Clean :
Code:
su
busybox tar zcvf /sdcard/efs/efs-backup.tar.gz /efs
Click to expand...
Click to collapse
Which seemed to work as i have the file in the place i expect
When i did the next step...
You can also back up the mmcblk0p1 (where /efs is stored) under /dev/block which can support greatly to recover your IMEI in case of a screw-up:
RAW :
Code:
su
cat /dev/block/mmcblk0p1 > /sdcard/efs_dev-block-mmcblk0p1.img
Same thing, the target is the INTERNAL SDCARD in sdcard/efs/, so go ahead and copy the file.
Click to expand...
Click to collapse
It completed really quickly, with no messages telling me it was done but when i checked root explorer i couldn't find /dev/block/mmcblk0p1?
What has it done with it? I have dev/block/ but there is no mmcblk0p1? Although i do have /sdcard/efs_dev-block-mmcblk0p1.img. Should i have both?
From what i understand cat concatenates files and prints them to standard output, so i'm assuming the > is piping the std output to the internal sdcard?
Sorry for the questions but i thought i understood what i was doing but the last step and the "can't preserve ownership of.." messages from the first step threw me
Could someone explain this to me a little ;p
These aren't steps but rather separate methods achieving different things. Don't bother about the first one - it notes unix permissions lost , which is why you are seeing the can't preserve ownership messages. The files still backup but correct r/w permissions do not. You may as well chuck the files really, since you managed the tarball (second instruction). Just grab this and backup to external storage, in case you ever need it.
The raw backup will be under sdcard as you have found - stash this away somewhere safe too. You won't find mmcblk0p1 in root explorer as it is a partition, not a folder.
Thanks for the swift reply simion_levi
These aren't steps but rather separate methods achieving different things. Don't bother about the first one - it notes unix permissions lost , which is why you are seeing the can't preserve ownership messages. The files still backup but correct r/w permissions do not. You may as well chuck the files really, since you managed the tarball (second instruction). Just grab this and backup to external storage, in case you ever need it.
Click to expand...
Click to collapse
Do if i move the tarball to the external drive i can get rid of the sdcard/efs directory i copied to the internal card? The tarball has all the correct permissions?
The raw backup will be under sdcard as you have found - stash this away somewhere safe too. You won't find mmcblk0p1 in root explorer as it is a partition, not a folder.
Click to expand...
Click to collapse
Ok i didn't realise it was a partition, so i've just created an image of the partition that the efs folder resides on? Should i copy this to my external sd card as well?
Cheers brother
No problem! Yes, you've got it - backup the tarball and the partition image to computers, external drives etc so you can recover back to the phone in case of future catastrophe. The sdcard/efs directory can be deleted as the tarball contains exactly the same files (but with correct permissions).
Awesome, will get it done later. Out of interest how do you recover the partition image in the event of a disaster occurring?
Sent from my GT-I9100 using XDA App
One question please, since i stumbled on this one almost by luck.
Is there anything else to save before departing from stock?
Thanks.
Okay, so this guide assumes I already rooted my phone, but as a newbie I am completely in the dark about what does and what does not potentially harm the /efs. I would rather backup EVERYTHING before I flash/change anything, but from what I have read so far I need at least root to do backups.
Would it be safe to flash the Lite'ning Rom v1.1, coming from stock I9100XWKE2/I9100XENKE1/I9100XXKDJ/I9100XWKE2, and then backup mmcblk0p1?
Thanks!
It seems LG Backup Application simply combine files using 'tar' command with -p option and rename it to *.lbf file.
So, is it possible to gain root access by compressing superuser files(apk and binary) with proper permissions?
I can't test it since I don't have ubuntu installed on my computer
p.s First folder(ex /data) has 644 permission, instead 755.
p.s2 Tar format is ustar
Hi guys, today i am here to tell you a method only tested on a galaxy y, but i hope it will work for all. this is a method to change the download location for play store.
WARNING!!!
1. WARRANTY IS NOW VOID.
2. NOT MY PROBLEM IF SOME APP FAIL.
3. PLEASE, PLEASE, PLEASE DO A NANDROID BACKUP BEFORE THIS.
This is a simple code but it needs root for sure. now the necessities are as follows:
1. A complete nandroid backup
2. Root Permissions
3. Any terminal emulator. e.g https://play.google.com/store/apps/details?id=hecticman.jsterm
4. You need to know the default download location and the mount point of sd card( if that is where you want the new download location )
Now let's start.
Just know this that mnt/sdcard will have to be replaced by your sdcard mount point and data/app will have to be replaced by the default download location. i underlined them for easy understanding.
NOT MY PROBLEM IF THIS FAILS AND YOUR PLAY STORE CRASHES. JUST DO A NANDROID RESTORE.
THERE WILL ALREADY BE A $ AT START SO U DON'T HAVE TO PUT IT.
$ su
# mkdir /mnt/sdcard/playstore
# cp -r /data/app/* /mnt/sdcard/playstore
# rm -rf /data/app
# ln -s /mnt/sdcard/playstore /data/app
Click to expand...
Click to collapse
what the code does:
1. Grant super user permissions
2. Make a directory in sdcard named playstore.
3. Copy all items (recursively) from data/app to sdcard/playstore
4.Symlink the new location to fake the original.
Hitting Thanks can help.
and once again PLEASE BACKUP BEFORE THIS AND RESTORE IF NOT SUCCESSFUL.
This is based on the code used by link2sd.
Could you please double check your code fragments?
For me it looks, like you create a directory "playstore", but then copy to a directory "playstore-temp", which will most like not exist at that moment.
The ln you're using can't realy work as long as the /data/app directory is still in place... so you would first need to delete /rename it.
Just my 2¢
thanks dude
DThought said:
Could you please double check your code fragments?
For me it looks, like you create a directory "playstore", but then copy to a directory "playstore-temp", which will most like not exist at that moment.
The ln you're using can't realy work as long as the /data/app directory is still in place... so you would first need to delete /rename it.
Just my 2¢
Click to expand...
Click to collapse
looks like i was drunk making so much mistakes . corrected it.
It's not so simple if you use Link2SD. If you link some apps to sdext partition, some files in /data/app are symlinks which cannont be copied to /mnt/sdcard/playstore as it's FAT32. You have to try to symlink /app/data to folder on sdext partition. Create a folder /data/sdext2/playstore, copy /data/app/* there, delete /data/app and symlink /data/sdext2/playstore as /data/app. Sdext partition uses linux filesystem and all symlinks should work properly. I haven't tested it yet, but will do in a minute.
EDIT:
It doesn't work with Link2SD. Phone hangs on boot. It's probably cause Link2SD app must be directly in internal memory (so in real /data/app, not symlinked). I'll try to symlink /data/data or /data/dalvik-cache to save some internal memory but I doubt it'll work.