Booting Android from sd card on Dream/G1 - Android Software Development

Hi all,
Here are my findings about how to boot android from an SD card, useful for example to test development Android builds without messing your phone. This procedure was inspired by legacy GNU/Linux boot process and then should work on most hardware with a flashable recovery.
########################################
I can't stress enough the fact that this procedure is targeted to experienced user. A good knowledge of linux/android booting process is more than required. This procedure is not meant to be useful to most people given its limitations (no recovery mode, rebuild of boot.img required)
########################################
I won't propose a step by step tutorial as it's better to understand how to do it and adapt the procedure to each need.
Two modifications are required:
1. Declare to mount sd card partitions instead of internal flash volumes. This has to be done in the init.rc script.
For example:
mount yaffs2 [email protected] /system
mount yaffs2 [email protected] /system ro remount
with
mount ext2 /dev/block/mmcblk0p6 /system
2. For some reasons, in the boot process, sd card partitions generally show up later than the mount actions, so it is generally necessary to add a timer in init binary to give to to the kernel to detect sd card partitions before mounting them (adding a sleep(5) after the "A N D R O I D" text in init.c is enough).
Build your special boot.img embedding those two modifications and flash it on the recovery volume of your phone. Now, booting into recovery will launch the system on your sd.
Regards,

I would like to report success on booting the G1 from a system located on sd card (cyanogenmod 4.2.7.1). I will describe the procedure step by steps when every thing is okay.
There is just an issue that you might have encountered during cyanogenmod ROM cooking, all wireless connexions (wifi, BT, GSM) do not work. The same system on flash if okay. I made a diff on boot log messages and the only notable difference is this error :
E/MemoryHeapBase( 83): error opening /dev/pmem_gpu0: Permission denied
E/MemoryHeapBase( 83): error opening /dev/pmem_gpu1: Permission denied
E/MemoryHeapBase( 83): error opening /dev/hw3d: Permission denied
I tried to chmod 0555 /dev/pmem* with no success.... Any idea ?

Although I finally managed to have a usable system, this work is still experimental. Please fell free to test and report success, failures here so I can improve the thing.
Let's see how we can boot a copy of cyanogen ROM 4.2.7.1 located on sd card. The main purpose is to test future ROMs (eclair ?) without messing up your phone...
DISCLAIMER : This procedure is targeted to experienced user. I am not responsible if you loose your data, your phone or your Mom !
Prerequisites are :
- adb and fastboot operationnal on your host computer
- Boot image file boot.img :
http://www28.zippyshare.com/v/19654421/file.html
- files data.cpio.gz, system.cpio.gz (data.cpio.gz and system.cpio.gz are unmodified images of a fresh install of cyanogen ROM that fit the modified boot.img) from :
http://www15.zippyshare.com/v/57489279/file.html
http://www15.zippyshare.com/v/13077582/file.html
1.
Create 3 partitions on sd card. The first one (vfat) is to store your music, videos etc. The second and the third will hold /data and /system. Result shoul look like this :
# fdisk /dev/block/mmcblk0
Command (m for help): p
Disk /dev/block/mmcblk0: 1977 MB, 1977614336 bytes
64 heads, 63 sectors/track, 957 cylinders
Units = cylinders of 4032 * 512 = 2064384 bytes
Device Boot Start End Blocks Id System
/dev/block/mmcblk0p1 1 864 1741792+ c Win95 FAT32 (LBA)
/dev/block/mmcblk0p2 865 903 78624 83 Linux
/dev/block/mmcblk0p3 904 957 108864 83 Linux
Command (m for help):
2.
Copy data.cpio and system.cpio on the first partition of your sd card.
3.
Connect to your device with adb :
adb shell
4.
Mount mmcblk0p2 on temporary folder and extract user.cpio.gz archive :
mkdir /dev/tmp
mount /dev/block/mmcblk0p2 /dev/tmp
cd /dev/tmp
gunzip -c /sdcard/data.cpio.gz | cpio -i
cd /
umount /dev/tmp
5.
Mount mmcblk0p3 on temporary folder and extract system.cpio.gz archive :
mount /dev/block/mmcblk0p3 /dev/tmp
cd /dev/tmp
gunzip -c /sdcard/system.cpio.gz | cpio -i
cd /
umount /dev/tmp
6.
Reboot the phone in bootloader :
adb reboot bootloader
7.
Boot the phone with custom boot image :
unzip boot.img.zip
fastboot boot boot.img
Reports are welcome !

I haven't tried this, but great idea. Well done.
Maybe a nice additional idea would be a boot-menu style idea. Eg, detect OS on mem card and display a menu of "Internal" or "SD Card"?

I'm on it but as it will imply flashing people's phone, I need more testing and suggestions from experienced hackers. I only own my G1 for 5 days...

I acytually just started a thread about this in the Dream development subforum!
Some suggestions:
-Use a recovery image to boot the ROM on the sd card (look at modifying the CM recovery image) if this is possible. This way, you can boot from sd card when you want to, by booting into recovery image, without interfering with the flashed rom at all. No worries that flashin a new rom will require a reflash of your bootloader. Also, you can use the ROM installed in flash after a reboot without any hassle, which would be very useful when testing a ROM from the SD if it doesn't work very well and you need a working phone.
-Have the /data and /system-partition as folders on the 4th partition on the SD card, or as logical volumes on a primary one. Why?
Well, many people have their sd-cards set up with fat, extX, swap in that order. The partition layout you have described here simply isn't compatible with that, and will require a separate SD card just for this testing (which everyone might not have).
I must say, I think this is a GREAT idea! I so often want to test a few ROMS, but often they don't get the test-time they deserve because I need to swicth back to my working environment for job/uni the day after. This would be a great way to test a ROM thoroughly. And also it would be the best way to give a ROM a quick testdrive. switchroming back and forth is, for all its simplicity, hassle.

Using the recovery is the only way I found at the moment to boot from the sd card and was about to extend cm recovery with a dedicated menu Nevertheless, there will be a limitation with that: it will not be possible to use a different kernel for the system on sd as it will have to use the kernel of the recovery... Anyway, many custom roms around here use cm kernel (even those I saw with eclair) so it is not so problematic I think (tested Eugene373 AOSP20 yesterday). Anyway, it is possible to adapt the recovery with a test kernel...
I think I found a workaround for sd partitionning scheme pb, using bind mounts but I have not tested already. I will work on it this WE.

If I remember correctly you can use the command "reboot recovery" from the recovery shell to reboot again into recovery. It could mean that it is possible to choose what (kernel) to boot after the reboot. Even cyanogenmod has made quite a few changes to the kernel since the recovery image came out, and I think it would not be a very good solution to use the same kernel as the recovery image for all ROMs loaded via SD. (Especially the Hero ones won't work at all, I'm afraid.
It could also be possible maybe, to tweak the built-in bootloader into booting form either SD-card or from the internal flash? It already has the possibility to boot different things on different keypresses (home for recovery mode, and camera for fastboot). I have (again) no idea of its capabilities for reading anything off of the sd card, though.

I get your point naguz . I am not satisfied either with the solution of using the recovery kernel to boot the system on sd. I found that it adds quite much complexity to the init process: I tweaked the recovery executable to add an entry to boot from sd but I faced troubles in services startup and pre-init definitions. I think that the solution of using the recovery menu to choose to boot from sd have to be abandoned as it will require heavy additional changes to the init.rc scripts of the second system and will break its advanced features.
The ideal solution (as you suggested) would be to tweak the bootloader to boot natively from the sd card but unfortunately, we do not have the sources of the SPL (tell me if I am wrong) so it is definitely not possible.
The remaining solution is to use the recovery partition to flash the boot image of the second system. I works well, just press the home key and the second system boots ! The drawback is that you do not have recovery any more... Personnaly, I don't find that so problematic as I is still possible to boot a recovery image with fastboot when needed, so I think I will stick to this solution. I somebody have another solution, I am ok to investigate...

Aha, it makes sense that booting the sd directly from recovery mode would mess something up. I would think some of the same problems would be faced when booting the kernel from the recovery partiotion, doesn't it look like a different device to the kernel? Well, if it works, it works.
Regarding the source of the SPL, I have no idea, but I know hyakuro (a (former?) user here) has released a modified one. Trying to get in touch with him
As for the latest method: Is the recovery partiotion big enough to hold both the recovery image AND the kernel? If so, one could maybe have both. Maybe make a new "recovery image" that can either boot from sd or boot recovery image? Just throwing out ideas here.
Personally I don't see the big problem with not having a recovery image, as I would (in a dual-boot scenario) already have another, working install on the flash that I could use if the one booted from sd wasn't good enough. Re-flashing the recovery image could also be done from the working ROM in flash, for those without the SDK tools.
I think, however, that quite a few people will object to not having a recovery image.
Btw, was your latest working test done with one (4th) partition on the sd card for loading the ROM from SD? If so, new instructions please. I'd like to give it a try.

I think that it is technically impossible to boot directly from the sd, even with the sources of the SPL as drivers are required to drive the sd that can not be included in a SPL. It is the same issue on PC with PCMCIA network cards for instance. IPL+SPL has to be seen more or less like a simple BIOS...
The recovery partition size is not a matter her. The problem is the lack of control over what has to be booted as the only action we can make in the SPL is the HOME key to choose a regular boot or a recovery boot (the system on SD here). I think I have a good knowledge now of the boot process and I think we can not got further than that, despitely...
I am now trying to have /data and /system on the same partition, mount them on /mnt and bind mount each directory on /system and /data but with no succes . investigating....

Okay, bind mounting was a dumb idea of mine. The solution is to create an extended partition with 2 logical drives in it, so partitions are:
[1-3] FAT and/or EXTX and/or swap as needed (I have personnaly just one partition here)
4 extended
5 ext2 for /data
6 ext2 for /system
Now its time to bake a boot.img with the kernel of the system on the sd card + the ramdisk. I do not explain how to do that, google knows :
1.
In the ramdisk image, put my modified init program attached hereater
2.
In the init.rc script, change the lines that mount /data and /system :
mount yaffs2 [email protected] /system
mount yaffs2 [email protected] /system ro remount
with
mount ext2 /dev/block/mmcblk0p6 /system
and
mount yaffs2 [email protected] /data nosuid nodev
with
mount ext2 /dev/block/mmcblk0p5 /data
Flash boot.img on the recovery and reboot in recovery... That's all.

Jahrome,
Trying the idea on the HTC has a subtle difference. So I'm curious what change you put in the /init process.
Lets say the image one wants to use is the 'eclair' branch. This branch uses vold, so the block device, such as '/dev/block/mmcblk0p#', does not appear to be created until the vold service is started, which is after the init.rc mount operations. So the mount proposed does not work.
Curious what changes you made to the init process that might give me some ideas of what might be the simplest change. It seems that there is a relatively easy solution, that I don't yet see.
Ideas (or additional questions to clarrify) appreciated...

Hi Dale !
On which HTC are you trying the trick ?
First your trouble is not related to eclair as I successfully booted eclair on my G1 with this trick. You need to add a timeout in init so as it waits for the kernel to detect sd card partitions (need to recompile init, or use my recompiled init).
Vold has nothing to do at this point
Hope this helps

Init Delay for SDisk
Thanks for the reply. That's what I needed, it seems so ungraceful.
I thought vold was enabling something to make the kernel's discovery of the SD partitions. It is "by coincidence" that the log of the vold occured shortly before the adding of the block-device event. My apologies for not recognizing the coincidence of the log entries.
I had hoped the solution was a bit more "graceful", though I can't say what that would be or why a sleep is "ungraceful". I would like a "mount retry for n-seconds" option in the init.rc, that would be slick. Nonetheless I will add in a sleep-spin-check for a few seconds.
For the record, we are discussing the change to:
android-source: .../system/core/init/init.c
code-routine: main()
code-location: Somewhere after the "A N D R O I D" text
code-change: add in a sleep spin-check of some sort
I appreciate the comment that all we need is just a sleep. I think this completes the thread?!

Most interesting...
This is something akin to how I am using my company's Android solution for the Beagle Board...
In that environment, the entire kernel and rootfs are located on a SD/MMC card. The environment variables and boot script are stored in the NAND chip
through a "setenv" command. The U-boot monitor on the hardware defaults to run the boot script unless there is any user interaction. This image can then be converted into a typical distribution that can be flashed and ran without the SD card...
I have wondered about the implementation of this approach on my G1, but I have not had time to test it out. It is good to see that there are others that are interested in this as well...
I will be following this thread and will try to help in any way if I can... meaning if I can get some free time...
If you are interested in our Beagle Board solution, it is open source and can be found by a simple Google search using "Android rowboat"...
L8R...

very easy fix.
rename the /init to /init.android (or whatever you like)
create an init script. have it prompt on boot too boot from sd or internal. symlink the init.rc from /system. That way you only need one boot.img for multiple builds. We've been doing this a really long time on the android on vogue project. My development phone is simple, I hold down the menu button if I want to boot from the sdcard otherwise it boots from the internal.
Oh and don't worry about this.
jahrome said:
log messages and the only notable difference is this error :
E/MemoryHeapBase( 83): error opening /dev/pmem_gpu0: Permission denied
E/MemoryHeapBase( 83): error opening /dev/pmem_gpu1: Permission denied
E/MemoryHeapBase( 83): error opening /dev/hw3d: Permission denied
Click to expand...
Click to collapse
That's just that you don't have HW3D enabled in your kernel. It's important to note that if you're trying to use multiple builds that eclair with 3d and donut use different kernels.

Exactly the vogue and kaiser have been doing this for ages. If you want you can also boot ext2 and squashfs images. It's pretty simple stuff.

Anyone have a backup of the files in post #3? I've been trying this solution with files of my own creation (as in: my own cooked boot.img, and data/system files) but it doesn't seem to get past the G1 boot screen (as in: blank screen.) I've also tried the recovery boot solution however it gives me the same reaction. It leads me to believe the problem lies in my boot file.

ok anyone interested in creating a simple step by step manual? and can someone post the files again please?

Related

[HOWTO] Ideos S7 Froyo Android internal storage increase on stock ROM

Hi all, originally intending to post this tutorial to Ideos S7 Android Development but got a nice greeting from xda-developers.com unallowing newbies to post there
So I just got a brand-new-in-a-box, dead cheap, Ideos S7 tablet -- my first android tablet, and my second android device. I brought my last device about 2 years ago, a G1 that I only kept for a week and sold it afterwards. I was thinking that at that time Android isn't ready yet for replacing my E71.
Back to the Ideos S7, mine is already preloaded with TRZ-mod-0.2 ROM, which is nice. However, I had some issue with wireless network. Whenever I disable my wifi, I would ge trouble activating it as it constantly disabled by itself. Thus, I decided to go back to available stock ROM. Long story short, I've chosen the Froyo 2.2.2 Sweden coded S7V100R001C63B110, and made myself comfortable with repeating Huawei's flashing process.
The firmware seems more stable, and does not have the wireless network activation/deactivation issue. Stock ROM lover anyone
However, the stock ROM doesn't have apps2d+ or whatever that was called, to extend the internal storage. 137MB of free space is really pity for such device. I couldn't run Data2Ext* script successfully, as the default shell /system/bin/sh doesn't seems to support square brackets on scripts conditional parts. Busybox 1.18 supports it, but somehow it would cause all the commands executed in the script to ran by Busybox, causing "applet not found" errors. The other option would be Link2SD, which could probably saved me 10+ hours of hacking. It had its drawback though, the current version on the market expects the extended internal tablet storage partition to reside on the external SD card. Some hacking to mount the internal SD partition works, but not sure whether it would got correctly mounted on boot.
Also, the most important thing: nothing feels better than looking at "Available space" on "Internal tablet storage" of 5.5GB
So here it is, the tutorial for extending the internal storage. Most of the information used are gathered from various sources, and rewritten here for your enjoyment!
REQUIREMENTS:
=========
a) All hardware: Ideos S7 -- should work on Slim as well, data cable, charger, a living being..
b) Rooting -- I've used Gingerbreak from the market
c) Terminal Emulator -- Android Terminal Emulator works fine. Irritating blue background though.
d) Busybox -- 1.18 version is working fine
e) Root explorer -- Optionally used, for easier file editing and copying.
STEPS:
=========
0) Backup your data, as all data in internal storage will be lost!
---------
Well honestly I didn't do this as I got my contacts and mail synced on the internet. My S7 only got 5 days of lifetime so not much data there yet. Sorry no guide on how to do this
1) Partition the internal SD (or external SD card if you intend to do so).
---------
It is recommended to use a good class of memory card when using external SD card for the tablet storage partition.
There's possibly partitioning tools available for the architecture, but I did it with EASUS Partition Master on a Windows system. Mac OS's Disk Utiliy should work as well. Don't worry too much about the partition type, we'll reformat it later with busybox later anyway.
To partition the internal (or external) SD card, connect your data cable to your phone. When the USB connection notification came up, activate the USB storage mode. You don't need to install the Huawei S7 (or adb) drivers.
Fire up your partitioning application, and identify your storage. Delete (or) resize the existing FAT partition. Create another primary partition afterwards, with ext2 filesystem. ext3 and ext4 isn't supported in the stock ROM, so you probably have to either install a kernel module for the ext3,4 or replace your boot.img. Hey but that's not going to be a stock ROM
2) Root the device
---------
Install Gingerbreak from the market. Enable USB debugging in Settings -> Application -> Development, or else it won't work. Run Gingerbreak, root your device! The device will restart after successful process, and you are ready to modify your root filesystem.
3) Prepare the required tools
---------
You'll optionally need busybox to format and edit the files. Copy over the busybox binary file to /system/xbin/. The terminal login path would automatically points there so you can run busybox from anywhere inside the terminal.
4) Prepare the new data directory
---------
Fire up your terminal emulator. You'll need to be logged in as root to do the whole operation mentioned. Thus, type in:
Code:
su
Mount the new partition you've prepared on step (1). For internal SD, it's going to be /dev/block/mmcblk0p2 device, or for external SD, /dev/block/mmcblk1p2. You can also use other shorthand such as /dev/block/vold/179:2. But for simplicity, I'll use mmcblk*p* throughout the tutorial.
Prepare the mount point for your prepared data partition, and mount it. If it's currently mounted, unmount it first.
Code:
umount /dev/block/mmcblk0p2
mkdir /system/sd
You can also format the partition now if you didn't specify the partition type during the partition creation.
Code:
busybox mke2fs -m0 -b4096 /dev/block/mmcblk0p2
Now mount the extended data partition.
Code:
mount -t ext2 /dev/block/mmcblk0p2 /system/sd
We'll still need to be able to access the original data partition now and later, so, prepare the mount point and mount it as well.
Code:
mkdir /system/internal
mount -t yaffs2 /dev/block/mtdblock4 /system/internal
At this stage, you'll need to copy over all files inside the original /data directory to your new sd directory. You'll also need to make sure that the permissions isn't changed during the process. To do this, just tar the entire original data directory to your new one.
Code:
cd /system/internal
busybox tar -cvf /system/sd/old-data.tar *
cd /system/sd
busybox tar -xvf old-data.tar
busybox rm old-data.tar
The initialization for the new data directory mounting in the boot process does not modifies the boot image's init.rc. Thus, it seems that the initialization process is called after the radio initialization. I can't get my GSM to work without this step. We'll need to symbolic-link back the /system/sd/radio directory to the original internal storage /data/radio directory. And remember that on the boot process, we'll need to mount /system/internal *before* /system/sd.
Code:
cd /system/sd
busybox rm -rf radio
ln -s /system/internal/radio /system/sd/radio
After fiddling for several hours, I realized that the date and time settings gets reset on each boot. Fixed by symlinking the /data/date.time back to the internal storage.
Code:
cd /system/sd
busybox rm -rf date.time
ln -s /system/internal/date.time /system/sd/date.time
5) Prepare the boot init script
---------
The Froyo boot process runs init.rc script, which is replaced by the boot.img when system boots. So we can't put our new /data directory mount commands there, unless we extract, unpack, modify, repack the boot.img. Ok so I decided that modifying boot.img will be the last step if I can't get it working without it. There must be an easier way!
Also, there aren't any rc.d, rc3.d, bla bla directory in which we can put our custom initialization script.
Luckily, there is a script that is called from the init.rc script during boot, which is stored on the root filesystem and can be customized. It's called /system/etc/install-recovery.sh. Thus, we'll put the initialization script there. If you already got a /system/etc/install-recovery.sh, you can just add our initialization script in the beginning of the. Alternatively, you can create a separate script to perform init, and call it from your modified /system/etc/install-recovery.sh.
There will be drawback, for example, it seems that the script is called after radio initialization, so we'll need to use the old /data/radio directory from the original /data directory, prepared on step (4).
So now you'll need to create (or copy) the install-recovery.sh script. You can use vi from the busybox, or easier is to just copy and paste the install-recovery.sh script provided in this post. In case you're a vi expert, fire up these commands. Don't forget to remount the root filesystem as rw first!
Code:
busybox vi /system/etc/install-recovery.sh
Write in the install-recovery.sh script:
Code:
#!/system/bin/sh
mount -t yaffs2 /dev/block/mtdblock4 /system/internal
mount -t ext2 /dev/block/mmcblk0p2 /system/sd
mount -o bind /system/sd /data
Don't forget to set executable and readable attribute at least for root user, or else the system can't run the script!
Code:
chmod 755 /system/etc/install-recovery.sh
So now you're ready to reboot the system. Double check the install-recovery.sh script, make sure all commands mounts the partition exactly to where you intend it.
6) Reboot your Ideos S7!
---------
Reboot and enjoy the trendemous increase on your internal tablet storage
WARNING!!! Do not attempt to perform factory data reset while running with /data mounted. It seems that S7 will format the /data partition as yaffs2, not sure as I haven't checked it. But it worth to try to change the install-recovery.sh script to mount the data partition as yaffs2, and then performing factory data reset.
Sorry I can't post either an image or attachment yet
watch_mania said:
Sorry I can't post either an image or attachment yet
Click to expand...
Click to collapse
Btw, if someone with account capable of posting images and files would like to help, I can send the image links and files to your e-mail, so you can post it here
Should've post the title with [HOWTO] prefix. Sorry about the newbie-ish thing
Hey, sure i can post them! I've set up a site for the "Install GNU/Linux" anyway. I'll be looking to follow this howto sometime in the future. Tell ya what tho, i'd have saved 10+ hours hacking had i known gingerbreak was in market also!
threader said:
Hey, sure i can post them! I've set up a site for the "Install GNU/Linux" anyway. I'll be looking to follow this howto sometime in the future. Tell ya what tho, i'd have saved 10+ hours hacking had i known gingerbreak was in market also!
Click to expand...
Click to collapse
Unfortunately I don't own the Ideos anymore
Good luck on your site!
can you make a simple tutorial to us? i need it badly.
Could you help me.... do I have to label the drives as "mmcblk..." because it's not recognizing the directory
---------- Post added at 12:22 PM ---------- Previous post was at 12:21 PM ----------
I'm stuck after entering su in the emulator...please help
Nice guide
work perfectly on S7 slim
i do all the steps using sshdroid and putty so i can use cut&paste from web page
the only think that i've to add is mount syster as readwrite:
mount -o rw,remount -t yaffs2 /dev/block/XXXXXXX /system
Thanks for this guide i will do the same on all my device
i'm triing to increase internal memory on stock rom.
I successfully done on S7 slim (i found i guide writen by watch_mania) but on Vodafone Smart i've some trouble (i use sshdroid and putty).
I do the following step :
1) Partiton the external SD with two filesystem the the first one FAT32 the second one ext2
this is the output of fdisk :
/system/sd # fdisk -l /dev/block/mmcblk0 Disk /dev/block/mmcblk0: 7969 MB, 7969177600 bytes
255 heads, 63 sectors/track, 968 cylinders
Units = cylinders of 16065 * 512 = 8225280 bytes Device Boot Start End Blocks Id System
/dev/block/mmcblk0p1 1 509 4088511 83 Linux
/dev/block/mmcblk0p2 510 968 3686917+ b Win95 FAT32
2) mount system as read-write and create new mount point
mount -o rw,remount -t yaffs2 /dev/block/mtdblock4 /system
mkdir /system/sd
mkdir /system/internal
3) format ext2 partition created at 1)
mke2fs -m0 -b4096 /dev/block/mmcblk0p1
4) mounting the "original" /data on /system/internal and new ext2 partition on /system/sd
mount -t yaffs2 /dev/block/mtdblock6 /system/internal
mount -t ext2 /dev/block/mmcblk0p1 /system/sd
5) copy the content on "original" /data on /system/sd
cd /system/internal
tar -cvf /system/sd/old-data.tar *
cd /system/sd
tar -xvf old-data.tar
rm old-data.tar
6) create boot init script
vi /system/etc/install-recovery.sh
and write inside :
#!/system/bin/sh
mount -t yaffs2 /dev/block/mtdblock6 /system/internal
mount -t ext2 /dev/block/mmcblk0p1 /system/sd
mount -o bind /system/sd /data
Originally in the guide for S7 slim you have to do :
cd /system/sd
rm -rf radio
ln -s /system/internal/radio /system/sd/radio cd /system/sd
rm -rf date.time
ln -s /system/internal/date.time /system/sd/date.time
BUT if i try to do that the device does not recognize the sim.
If i try to don't do that the device loop during boot.
on S7 Slim in /system/internal/radio i found this file :
srwxrwxrwx 1 0 0 2048 Dec 31 06:49 qmux_connect_socket
the same file on vodafone smart is located in /system/internal/local/tmp/
but if i try to link it does not work and the device loop.
Will this also work on altek A14 LEO(an Android 2.1 phone)? It has less than 100MB internal storage, although it built-in dtapps2sd with the newest stock firmware, "/data/data" is still stored in internal storage. Because the version of dtapps2sd in stock firmware is not latest version, no "/data/data" mount on SD-EXT support. And I can't upgrade dtapps2sd myself due to no reflash tool for this phone.
Thank for the niec post, i,ll try it shortly
Increasing Internal Memory
Hi,
Has anyone tried a superb "setinstalllocation-xxx.apk" available in xda-developers.
I have been using it and it is really good. But as mentioned by watch-mania that 139 or 140 MB of available storage is a pity.
Your device must be rooted to use the above apk. You can successfully use gingerbreak available from this excellent forum.
more info
watch_mania said:
Hi all, originally intending to post this tutorial to Ideos S7 Android Development but got a nice greeting from xda-developers.com unallowing newbies to post there
So I just got a brand-new-in-a-box, dead cheap, Ideos S7 tablet -- my first android tablet, and my second android device. I brought my last device about 2 years ago, a G1 that I only kept for a week and sold it afterwards. I was thinking that at that time Android isn't ready yet for replacing my E71.
Back to the Ideos S7, mine is already preloaded with TRZ-mod-0.2 ROM, which is nice. However, I had some issue with wireless network. Whenever I disable my wifi, I would ge trouble activating it as it constantly disabled by itself. Thus, I decided to go back to available stock ROM. Long story short, I've chosen the Froyo 2.2.2 Sweden coded S7V100R001C63B110, and made myself comfortable with repeating Huawei's flashing process.
The firmware seems more stable, and does not have the wireless network activation/deactivation issue. Stock ROM lover anyone
However, the stock ROM doesn't have apps2d+ or whatever that was called, to extend the internal storage. 137MB of free space is really pity for such device. I couldn't run Data2Ext* script successfully, as the default shell /system/bin/sh doesn't seems to support square brackets on scripts conditional parts. Busybox 1.18 supports it, but somehow it would cause all the commands executed in the script to ran by Busybox, causing "applet not found" errors. The other option would be Link2SD, which could probably saved me 10+ hours of hacking. It had its drawback though, the current version on the market expects the extended internal tablet storage partition to reside on the external SD card. Some hacking to mount the internal SD partition works, but not sure whether it would got correctly mounted on boot.
Also, the most important thing: nothing feels better than looking at "Available space" on "Internal tablet storage" of 5.5GB
So here it is, the tutorial for extending the internal storage. Most of the information used are gathered from various sources, and rewritten here for your enjoyment!
REQUIREMENTS:
=========
a) All hardware: Ideos S7 -- should work on Slim as well, data cable, charger, a living being..
b) Rooting -- I've used Gingerbreak from the market
c) Terminal Emulator -- Android Terminal Emulator works fine. Irritating blue background though.
d) Busybox -- 1.18 version is working fine
e) Root explorer -- Optionally used, for easier file editing and copying.
STEPS:
=========
0) Backup your data, as all data in internal storage will be lost!
---------
Well honestly I didn't do this as I got my contacts and mail synced on the internet. My S7 only got 5 days of lifetime so not much data there yet. Sorry no guide on how to do this
1) Partition the internal SD (or external SD card if you intend to do so).
---------
It is recommended to use a good class of memory card when using external SD card for the tablet storage partition.
There's possibly partitioning tools available for the architecture, but I did it with EASUS Partition Master on a Windows system. Mac OS's Disk Utiliy should work as well. Don't worry too much about the partition type, we'll reformat it later with busybox later anyway.
To partition the internal (or external) SD card, connect your data cable to your phone. When the USB connection notification came up, activate the USB storage mode. You don't need to install the Huawei S7 (or adb) drivers.
Fire up your partitioning application, and identify your storage. Delete (or) resize the existing FAT partition. Create another primary partition afterwards, with ext2 filesystem. ext3 and ext4 isn't supported in the stock ROM, so you probably have to either install a kernel module for the ext3,4 or replace your boot.img. Hey but that's not going to be a stock ROM
2) Root the device
---------
Install Gingerbreak from the market. Enable USB debugging in Settings -> Application -> Development, or else it won't work. Run Gingerbreak, root your device! The device will restart after successful process, and you are ready to modify your root filesystem.
3) Prepare the required tools
---------
You'll optionally need busybox to format and edit the files. Copy over the busybox binary file to /system/xbin/. The terminal login path would automatically points there so you can run busybox from anywhere inside the terminal.
4) Prepare the new data directory
---------
Fire up your terminal emulator. You'll need to be logged in as root to do the whole operation mentioned. Thus, type in:
Code:
su
Mount the new partition you've prepared on step (1). For internal SD, it's going to be /dev/block/mmcblk0p2 device, or for external SD, /dev/block/mmcblk1p2. You can also use other shorthand such as /dev/block/vold/179:2. But for simplicity, I'll use mmcblk*p* throughout the tutorial.
Prepare the mount point for your prepared data partition, and mount it. If it's currently mounted, unmount it first.
Code:
umount /dev/block/mmcblk0p2
mkdir /system/sd
You can also format the partition now if you didn't specify the partition type during the partition creation.
Code:
busybox mke2fs -m0 -b4096 /dev/block/mmcblk0p2
Now mount the extended data partition.
Code:
mount -t ext2 /dev/block/mmcblk0p2 /system/sd
We'll still need to be able to access the original data partition now and later, so, prepare the mount point and mount it as well.
Code:
mkdir /system/internal
mount -t yaffs2 /dev/block/mtdblock4 /system/internal
At this stage, you'll need to copy over all files inside the original /data directory to your new sd directory. You'll also need to make sure that the permissions isn't changed during the process. To do this, just tar the entire original data directory to your new one.
Code:
cd /system/internal
busybox tar -cvf /system/sd/old-data.tar *
cd /system/sd
busybox tar -xvf old-data.tar
busybox rm old-data.tar
The initialization for the new data directory mounting in the boot process does not modifies the boot image's init.rc. Thus, it seems that the initialization process is called after the radio initialization. I can't get my GSM to work without this step. We'll need to symbolic-link back the /system/sd/radio directory to the original internal storage /data/radio directory. And remember that on the boot process, we'll need to mount /system/internal *before* /system/sd.
Code:
cd /system/sd
busybox rm -rf radio
ln -s /system/internal/radio /system/sd/radio
After fiddling for several hours, I realized that the date and time settings gets reset on each boot. Fixed by symlinking the /data/date.time back to the internal storage.
Code:
cd /system/sd
busybox rm -rf date.time
ln -s /system/internal/date.time /system/sd/date.time
5) Prepare the boot init script
---------
The Froyo boot process runs init.rc script, which is replaced by the boot.img when system boots. So we can't put our new /data directory mount commands there, unless we extract, unpack, modify, repack the boot.img. Ok so I decided that modifying boot.img will be the last step if I can't get it working without it. There must be an easier way!
Also, there aren't any rc.d, rc3.d, bla bla directory in which we can put our custom initialization script.
Luckily, there is a script that is called from the init.rc script during boot, which is stored on the root filesystem and can be customized. It's called /system/etc/install-recovery.sh. Thus, we'll put the initialization script there. If you already got a /system/etc/install-recovery.sh, you can just add our initialization script in the beginning of the. Alternatively, you can create a separate script to perform init, and call it from your modified /system/etc/install-recovery.sh.
There will be drawback, for example, it seems that the script is called after radio initialization, so we'll need to use the old /data/radio directory from the original /data directory, prepared on step (4).
So now you'll need to create (or copy) the install-recovery.sh script. You can use vi from the busybox, or easier is to just copy and paste the install-recovery.sh script provided in this post. In case you're a vi expert, fire up these commands. Don't forget to remount the root filesystem as rw first!
Code:
busybox vi /system/etc/install-recovery.sh
Write in the install-recovery.sh script:
Code:
#!/system/bin/sh
mount -t yaffs2 /dev/block/mtdblock4 /system/internal
mount -t ext2 /dev/block/mmcblk0p2 /system/sd
mount -o bind /system/sd /data
Don't forget to set executable and readable attribute at least for root user, or else the system can't run the script!
Code:
chmod 755 /system/etc/install-recovery.sh
So now you're ready to reboot the system. Double check the install-recovery.sh script, make sure all commands mounts the partition exactly to where you intend it.
6) Reboot your Ideos S7!
---------
Reboot and enjoy the trendemous increase on your internal tablet storage
WARNING!!! Do not attempt to perform factory data reset while running with /data mounted. It seems that S7 will format the /data partition as yaffs2, not sure as I haven't checked it. But it worth to try to change the install-recovery.sh script to mount the data partition as yaffs2, and then performing factory data reset.
Sorry I can't post either an image or attachment yet
Click to expand...
Click to collapse
can you make a video about how increase the internal memory? i trying but at final step after restart my ideos nothing happens, or screenshots, please i have 4 for weeks looking for a solution about the low memory on my ideos, i install joenilan rom but dont like me the launcher, please and sorry for my bad english.
This is one good tutorial that I missed
Sent from my Ideos S7 using XDA App
HELP
Hi, i followed the steps, and my ideos keep looping at the ideos start screen
is there anything i can do?
zonyman said:
Hi, i followed the steps, and my ideos keep looping at the ideos start screen
is there anything i can do?
Click to expand...
Click to collapse
Reflash with new program,search it ..
My way !
My device : Huawei S7-105
Another way to increse internal memory :
1 flash with stock rom 2.2.2 norvegian
2 flash trizetmod v3
3 with MiniTool Partition Wizard Home Edition i've made 3 partitions on internal memory ( s7-105 using mass storage options )
- 1.2 Gb fat32
- 6 Gb ext4
- 157 Mb swap linux partition
This was one of many attempts to increase memory , and at the end i was happy with that result ! I think that you can make your own partitions , as you wish ! I have seen many movies on youtube .
Most important thing to remember : first you create fat32 partition and make it primary , second is ext4 partition also primary and the last swap partition !
After you create the partitions , reboot in recovery and make a factory reset , and your S7 has 6Gb program memory !!!!!!
Another important thing : I am a newbie in " Android world " , so I do not know how correct is what I did but one thing is certain : I HAVE 5.28 Gb and I got rid of that annoying message LOW MEMORY !!!!!!
I hope I posted in the right place , so i ask an admin to check ! Thx
in summary of this post..
all you have to do is to backup ur current rom via cwm by goodane..
make a 2nd primary partition formatted ext2/ext4 (for ext2 supports 2GB or less.. ext4 for 2GB or higher)
flash trizet's v3 rom
-THE END :good:
Hello guys!
I have a Huawei Ideos S7 Slim too,
Specifications
- Model: Huawei Ideos S7 Slim
- Version: 202u
- Intermal memory: 160 mb
I'm trying to do the steps to increase the internal memory
I don't getting success with the process
I wonder if the process works with the model Huawei Ideos S7 Slim 202u
Thank you

[Q] (MiRaGe-KANG build dualboot) CM7 Bootloop

The card was working fine. I went to turn it on and boot loops on CM7.
Everything else works as expected (native OS 1.4.1 & native recovery
boot fine, menu loads with N key, I can boot the tailored CWMR from that,
CM9 boots fine with both vol keys). Andy just keep skating with CM7 .
I must have done something to the OS for it to fail like that.
Right now, I need to figure out how to get my data off the
card without a running OS to mount the devices.
Ideally, I'd like to extract as much of CM7's user data
as possible. I can't mount /data1 and /system1 to windows
as they are ext4 and p7 (/sdcard) is unreachable
because I have no OS (other than CWMR).
Can I adb pull in recovery? If the partition has to be mounted,
can I adb shell mount it, then download the data?
Can someone tell me the correct /dev files to use for mount
for partition 2 (system1), 3 (data1) & 7 (sdcard).
I've just updated the DualbooSD thread with flashable zips for the latest Mirage as well as ICS.
Try flashing the new Mirage build. It might fix the problems that you are having as it will format /system when installing.
-Racks
no luck.
I'm starting to think maybe there is something in
/sdcard that is causing this issue. I created a clean
16gb card and extended the last partition with
Easyus to fill the card.
One the first boot it got into CM7 fine, after that booted
I connected to USB via the 'magic nook cable' and told
windows to copy / paste the contents of the /sdcard
filesystem to the new /sdcard filesystem.
After that is doesn't boot CM7 (although CM9 boots
fine and can read and write /sdcard)?
Is emmc (the 1gb user space on the internal memory)
shared, could TiBu use that space with CM 7&9? Copy
the TiBu files there using CM9 and recreate a fresh disk
and use that as the source to reinstall apps+data?
When TiBu does backups of system data and
apk+data under these conditions, one would have to manually
select backup directories to avoid cross pollution between 2.3
and 4.0 OSes, right? Or is there a dual boot aware version?
I do have a working Nookie Froyo card, can I use that as a source
for the user APKs+data, then update from market to the current
releases?
To create a current card do I use the img to start, then follow OP
directions, then get the two updates and apply those?
Can you diagram what uSD partitions contain what?
Is recovery all in the uRec??? files (no partition)?
Is recovery adb enabled? adb devices usually
reports
<serial> recovery
and windows see's 1 device
When adb can see the recovery mode device.
What I think:
p1 p /boot
p2 p /system1
p3 p /data1
p4 e extended
p5 l /system2
p6 l /data2
p7 l /sdcard
with /cache /emmc /rom /recovery
seen from emmc memory.
PS:
B&N tech support 2 said that 1.4.1 was based on 2.3.
He also said the 8 boots thing was not needed on nook
color to get to factory reset.
I wish there were tools to mount the p2, p3, p5, p6 & p7
filesystems to windows 7 for backup. I guess I could connect
the card and use dd for win32 but that would probably take
forever to run. I guess the best option is dual boot a linux
distro to get ext? support. All I need is a shell prompt and
the gnu tool set. I tried ext2fsd 0.5.1 but it doesn't seem to
do anything. It says its running, its mount says its successful
but it does not assign a drive letter (even running under an
elevated cmd.exe).
Or that CWMR backup/restore worked properly,
it should be backing up 1, 2, 3, 5 & 6 + the secure
pseudo partitions files to 7. Is adb supposed to be able
to talk to recovery on NC, it does on my HTC Flyer,
HTC Rezound and HTC Incredible1, but they are all
hboot devices, maybe something has to be set
in the bootloader to enable adb? adb & fastboot also
recognize HTC's hboot as a boot-loader.

Help missing 13gb data - nexus 7

Okay so i was just doing a bit of file management. I removed a 1.4gb psp iso i had on my nexus 7 and then i checked how much space i had left using storage option in settings. I checked it and it said i had 25gb free when before i removed my file i had only 13gb free. Tried rebooting device and then used es file explorer to see all files. Opened es file explorer and then noticed everything was gone. Only stock items were folders were left eg Android, Download etc. All my msuic and some game data was gone. Opened up asphalt 7 to see if it would still work but it doesnt anymore. Tried opening real racing 3 And it asks me to redownload game data. My widgets are still in homescreen and work and some of the other apps i have still work as well eg plague inc, subway surfer and most of the other ones.
Any idea on how this happened and how i can recover my files? I have a bugsense file as well that was left on my device.
As to recovery of lost files your options are not good. (And if we're talking a non-rooted device, the odds are approximately equal to 0%) Recovery in ext4 filesystems is technically much more challenging than in simple filesystems such as FAT. And this pessimistic outlook presumes that the filesystem is healthy/clean. If the reason for the problem occurring in the first place was a corrupted filesystem, then the odds go from simply bad to pathetically poor.
Sorry, dude... got any Nandroid or TiBu backups stored on your PC?
If you had Putin's top-secret files on your N7 and the CIA got hold of it, the first thing a forensic analyst would do is try to take a raw (block) device dump off of the "cold" device. (If you are still running the N7 with the regular OS the /data partition is being continually written to, and this further reduces the chances of file recovery every second the device is booted).
In the case of an analyst with less resources, this might mean using a custom recovery boot to get the raw device copy; unfortunately, the /data partition is huge - nearly 30 GB - so you would have to mount a extN filesystem via OTG... and doing so thus precludes using adb, so you would need to use a recovery with a touch interface and command-line entry (e.g. TWRP)
# mkdir /mnt/myOTGdisk
# mount -t ext2 -o rw /dev/sda1 /mnt/myOTGdisk/
# dd bs=8196 if=/dev/block/platform/sdhci-tegra.3/by-name/UDA of=/mnt/myOTGdisk/userdata.img
Doing such a thing would allow you to examine that huge image file with forensic file recovery tools from a PC (probably running Linux) as in principle you captured the entire ext4 filesystem.
The thing is, efforts spent in file recovery should be proportional to the value of the files being recovered. I'm not sure if your saved gaming history rises to that occasion. For sure the dude at the CIA won't want to help you with that.
As to the source of your troubles, it's hard to say. With TWRP booted, you can run the "e2fsck" program to see if the /data ext4 filesystem is corrupted, e.g.
# mount | grep /data ( see which mmcblk0 partition is /data, on grouper it is mmcblk0p9 )
# umount /sdcard
# umount /data
# e2fsck -f -n /dev/block/platform/sdhci-tegra.3/by-name/UDA
(For the last command above, you might need to use the block device name /dev/block/mmcblk0p?? instead of the UDA symlink )
If the above command shows that you have a corrupted /data filesystem, I would re-initialize that filesystem ( "fastboot format userdata" ) - note this wipes all userdata including the psuedo-SD card.
Finally, I should point out that some type of hardware failure might have occurred somewhere in that huge 30 GB partition - if that is the case then there will be problems down the road again. If that is the case, the only way to detect this will be a write test which nearly fills that partition, followed by a filesystem sanity check as shown above.
Probably that would need to be done in the recovery rather than in the normal OS, as a nearly full /data filesystem will probably wedge the device.
Phew, I've said enough.
Good luck
I never tire of reading your posts, bftb0, ("...the odds are approximately equal to 0%")...genius.
But don't the CIA have access to Cray, 'Kasparov' DeepBlue beating SuperComputers that could make mincemeat out of the kind of thing your alluding to... in less time than it takes to flash a ROM... or have I been watching too many James Bond movies?
Vaguely rhetorical question - think I already know the answer...
Still... what a great post.
Rgrds,
Ged.
---------- Post added at 01:22 AM ---------- Previous post was at 12:50 AM ----------
Hi, leont1280...
You could try running this ...
Disk Usage - http://play.google.com/store/apps/details?id=com.google.android.diskusage&hl=en
It gives a graphical 'map' or overview of your storage, and you can visually see where everything is (or should be), great for tracking down missing stuff... but as bftb0 has mentioned, it doesn't look promising.
Rgrds,
Ged.
Use astro file manager u can check it out
Sent from my Nexus 7 using Tapatalk 2
Right bftb0 i did what you said in twrp and i recieved the following summary information.
/dev/block/mmcblk0p10: 28133/1835008 files (3.2% non-contiguous) , 1571673/733977
Any idea on what that means?
Also under the mount option in Twrp i can Unmount and mount the System, Data and its Cache. However i cant Mount the SD Card. Should that be a concern?
bftb0 said:
As to recovery of lost files your options are not good. (And if we're talking a non-rooted device, the odds are approximately equal to 0%) Recovery in ext4 filesystems is technically much more challenging than in simple filesystems such as FAT. And this pessimistic outlook presumes that the filesystem is healthy/clean. If the reason for the problem occurring in the first place was a corrupted filesystem, then the odds go from simply bad to pathetically poor.
Sorry, dude... got any Nandroid or TiBu backups stored on your PC?
If you had Putin's top-secret files on your N7 and the CIA got hold of it, the first thing a forensic analyst would do is try to take a raw (block) device dump off of the "cold" device. (If you are still running the N7 with the regular OS the /data partition is being continually written to, and this further reduces the chances of file recovery every second the device is booted).
In the case of an analyst with less resources, this might mean using a custom recovery boot to get the raw device copy; unfortunately, the /data partition is huge - nearly 30 GB - so you would have to mount a extN filesystem via OTG... and doing so thus precludes using adb, so you would need to use a recovery with a touch interface and command-line entry (e.g. TWRP)
# mkdir /mnt/myOTGdisk
# mount -t ext2 -o rw /dev/sda1 /mnt/myOTGdisk/
# dd bs=8196 if=/dev/block/platform/sdhci-tegra.3/by-name/UDA of=/mnt/myOTGdisk/userdata.img
Doing such a thing would allow you to examine that huge image file with forensic file recovery tools from a PC (probably running Linux) as in principle you captured the entire ext4 filesystem.
The thing is, efforts spent in file recovery should be proportional to the value of the files being recovered. I'm not sure if your saved gaming history rises to that occasion. For sure the dude at the CIA won't want to help you with that.
As to the source of your troubles, it's hard to say. With TWRP booted, you can run the "e2fsck" program to see if the /data ext4 filesystem is corrupted, e.g.
# mount | grep /data ( see which mmcblk0 partition is /data, on grouper it is mmcblk0p9 )
# umount /sdcard
# umount /data
# e2fsck -f -n /dev/block/platform/sdhci-tegra.3/by-name/UDA
(For the last command above, you might need to use the block device name /dev/block/mmcblk0p?? instead of the UDA symlink )
If the above command shows that you have a corrupted /data filesystem, I would re-initialize that filesystem ( "fastboot format userdata" ) - note this wipes all userdata including the psuedo-SD card.
Finally, I should point out that some type of hardware failure might have occurred somewhere in that huge 30 GB partition - if that is the case then there will be problems down the road again. If that is the case, the only way to detect this will be a write test which nearly fills that partition, followed by a filesystem sanity check as shown above.
Probably that would need to be done in the recovery rather than in the normal OS, as a nearly full /data filesystem will probably wedge the device.
Phew, I've said enough.
Good luck
Click to expand...
Click to collapse
Right bftb0 i did what you said in twrp and i recieved the following summary information.
/dev/block/mmcblk0p10: 28133/1835008 files (3.2% non-contiguous) , 1571673/733977
Any idea on what that means?
Also under the mount option in Twrp i can Unmount and mount the System, Data and its Cache. However i cant Mount the SD Card. Should that be a concern?
leont1280 said:
Right bftb0 i did what you said in twrp and i recieved the following summary information.
/dev/block/mmcblk0p10: 28133/1835008 files (3.2% non-contiguous) , 1571673/733977
Click to expand...
Click to collapse
Hmmm, mmcblk0p10 - you must have a tilapia (3G N7) device, yes?
If you had any filesystem errors, that e2fsck run would have produced copious reams of output. If a filesystem is clean, it produces only 5 or 6 lines of summary output.
leont1280 said:
Any idea on what that means?
Also under the mount option in Twrp i can Unmount and mount the System, Data and its Cache. However i cant Mount the SD Card. Should that be a concern?
Click to expand...
Click to collapse
I've seen the same business with TWRP and the /sdcard mount - I wouldn't worry about it. (It is not a "normal" mount in the sense of extN or FAT device partition mount - it behaves sort of like a strange symlink where the target directory and descendants all appear to have different file ownership and permissions than what exist in the true (underlying) filesystem. No doubt this is all performed in the kernel... I don't know whether a command-line invocation of "mount" can create this mount point, or whether a specific syscall/ ioctl is needed)
But back to your N7 - the lack of any errors in the filesystem check is good news, but also suggests that your files didn't disappear through a hardware failure. Are you sure you didn't fat-finger things when using the file manager? (I suppose it is possible that the file manager has a bug...)
I didn't look into what tools are available for extN forensic/recovery work. I can guess that the effort would be non-trivial, though.
bftb0 said:
Hmmm, mmcblk0p10 - you must have a tilapia (3G N7) device, yes?
If you had any filesystem errors, that e2fsck run would have produced copious reams of output. If a filesystem is clean, it produces only 5 or 6 lines of summary output.
I've seen the same business with TWRP and the /sdcard mount - I wouldn't worry about it. (It is not a "normal" mount in the sense of extN or FAT device partition mount - it behaves sort of like a strange symlink where the target directory and descendants all appear to have different file ownership and permissions than what exist in the true (underlying) filesystem. No doubt this is all performed in the kernel... I don't know whether a command-line invocation of "mount" can create this mount point, or whether a specific syscall/ ioctl is needed)
But back to your N7 - the lack of any errors in the filesystem check is good news, but also suggests that your files didn't disappear through a hardware failure. Are you sure you didn't fat-finger things when using the file manager? (I suppose it is possible that the file manager has a bug...)
I didn't look into what tools are available for extN forensic/recovery work. I can guess that the effort would be non-trivial, though.
Click to expand...
Click to collapse
Im pretty sure i didnt accidently delete it myself. When i was doing file management i was using my laptop with the N7 3g connected to it via MTP. Once i deleted the iso file the N7 started acting strange. I did notice a bit of lag that was usually out lf the ordinary and when i checked available space left it increased to 25gb rather than saying 13gb
aaah, having the same problem here, i was cleaning my n7 using my laptop, found a strange folder on my sd card, looked inside and it has a back up of some of my deleted files! interesting! i deleted the folder, then i started cheking other folders, like my ebooks, audio books and etc, but all my folders were empty!
so i disconnected my tablet, and after reconnecting, bam, all files gone.

howto: mount external sdcard as sdcard0

So, the Note 8.0 is a nice, fast, expensive device that had a big shortcoming for me: as shipped, the SD card is not useful as a place where application data easily lands - it's only intended for storing music and video files, or those chunks of data you manually target to it.
I fixed it, after a fashion, by mounting the card at boot time as sdcard0, which Samsung normally assigns to the (very limited) internal storage. The internal /data/media pool is treated as the external sdcard and very little installation data defaults to it. Apps2SD is still broken, but quite a lot of things simply default to using /sdcard0 as their preferred storage, which I find helpful.
You have to mount it at start time (init.d), and you have to mount it correctly (bind)
I figured out and set my device up this way by setting init.d scripts I learned about from threads by Ryuinferno (init.d) and mattiadj (rebinding in the Note 2) for this. Translation: none of this is my work, I just sounded out how others had done it and am assembling it here, since I know it will help other Note 8 folks.
I think that the init.d script support is very interesting - there are a lot of ROM tweaks that rely on init.d. You do not need a custom kernel for init.d to work the note 8 - which is nice, since we have no custom kernel
The outcome of this mod is that with an sdcard inserted, I get:
/storage/sdcard0 29.7G 3.68G 26.0G 32768
and
/storage/extSdCard 9.87G 1.78G 8.09G 4096
If I remove the card at boot, I still have apps (installed at /data/data) and the media
pool reverts to normal:
/storage/sdcard0 9.78G 1.78G 7.99G 4096
I wrote none of the scripts I'm using and will be the first to admit that I may have set them up stupidly.
Doing this voids your warranty and gives you pimples and a moon tan. But it does mean your sd card expands your storage and I hope that if there are better ways to do any of this, folks will chime in.
tools needed:
- knowledge of ADB and working ADB
- helps if you know how Unix and windows terminate lines differently, and can get your copy of Notepad++ to help you with the script, if you're trying this from Windows
- a note 8 running the 4.1.2 software - this approach is only tested there
- Kies
- Possibly Odin as a replacement for Kies (untested)
- understanding of how to put your device into recovery mode and trigger the Samsung recovery
- the US stock firmware for your device, for use with Odin (unless waiting on 1+ gig downloads if you screw something up is ok by you - the Kies method works, slooooowly.)
- Framaroot, to root your Note 8 (see the thread by tweebee)
- Busybox installed
Steps:
Install Framaroot
Root your device
Install busybox
Easy part done.
Next, you need to be able to run init.d scripts. At first I thought this might require a custom kernel, until I ran into Ryuinferno's excellent tool for enabling init.d without a custom kernel.
the thread I learned this from is by Ryuinferno at http://forum.xda-developers.com/showthread.php?t=1933849
I used term-init.sh from an ADB command line, but the thread has an APK in it called Uni-Init.apk that I would expect to work.
What you're doing is creating an install-recovery.sh script and telling it to go read /etc/init.d and run scripts there at boot.
Next, you want to create a simple script and drop it into /etc/init.d You can do this with an adb push; if you create the file in windows, though, you need to deal with the line endings correctly. You need the script to be executable and to be owned by root.
The one I'm using is this, from Mattiadj of the Note 2 community
in this thread: http://forum.xda-developers.com/showthread.php?t=2036796:
I call the script 07mount on my device, and a copy is attached to this post.
-----------------------script starts next line
#!/system/bin/sh
#extsd2internalsd is a modification that allows to switch internal sd to external sd
#and viceversa. With this you can use default internal sd only for app storage
#and the external sd to store all apps resource and all others stuff. The resut is a very
#big increase of installable apps on gnote2 and note8
#All credits to Mattiadj of xda forum for the idea and script and to mike1986 for
#the cmw zip. xda thread url
# at http://forum.xda-developers.com/showthread.php?t=2036796:
sleep 10
mount -o remount,rw /
mount -t vfat -o umask=0000 /dev/block/vold/179:17 /storage/sdcard0
sleep 30
mount -o bind /data/media /storage/extSdCard
chmod 777 /mnt/extSdCard
sleep 10
chown 1023:1023 /storage/extSdCard
chown 1000:1000 /storage/sdcard0
------------- end script on blank line above
You need /system remounted read/write, either in your favorite file explorer or via adb shell:
#mount -o rw,remount /system
to put the file in and
#chown root:root
the script itself
Now, put a fat32 formatted card into your sdcard, and reboot. When done, you should be able to see that your data storage has been remapped.
If you ever wanted to install a Samsung update, by the way, you'd need to completely unroot the device. I think the following would probably work:
- remove the su binary
- remove superuser from /system
- remove the busybox binaries
- remove install-recovery.sh from /etc and the /etc/init.d folder
If there was someting in an update you really wanted, you might do better to start by using the Samsung firmware downloaded from samfirmware.com, set your device all the way back to a clean install, then check for the OTA - Samsung does look at modifications and blocks updates to devices with changes to /system. My device is ineligible for OTA at this time.
That said, it appears that using Kies in emergency recovery mode can be used to reset your device to an as-shipped condition (I learned this when an early experiment resulted in my device being weirdly screwed up - bootable, but the network was down for the browser, etc. DNS and ping worked from an ADB prompt, though...)
You can download a copy of the script at http://www.mediafire.com/?2wbm439vlapb6om
I'm gonna try this when I have a full afternoon off as I tend to mess things up the first time I do them. But this will be super useful if I get it working. Hopefully when people start developing custom roms they can build this script in and save us all the trouble :highfive:
Haven't tried it yet, but it sounds like a custom recovery is very, very close. Once that happens, making this into a flashable modification will be trivial.
The very active Note II development is incredibly helpful, because our hardware and software are so similar to theirs.
I know this was something that users on the other Galaxy Note 2 threads were doing, and was wondering if at some point this will be an issue with say JB 4.2.2. I recall that Apps2SD would be an issue later on and wouldn't work, but I never got to that point. For me I am really in need of a 32GB tablet and just can't compromise even with a 64GB microSD card. I don't know why this tablet isn't supporting a 128GB microSD card, that would be awesome.
Upgrading internal storage by blending in sdcard
Just to be clear - this mod does not allow app2sd style migration of apps (in /data/app) to the sdcard.
Rather, it puts /data/media on the sdcard. A lot of apps use /data/media as their default for storage, though, so it's a helpful middle ground. Also, your apps are installed whether or not the sdcard is inserted, which is helpful.
I notice that the update includes a script called
install-recovery.sh - the same script that this method is using.
I have tested replacing a backed up copy of install-recovery and also
appending the command
run-parts /system/etc/init.d/ to the new file.
Using just a script to call run-parts or the stock install-recovery.sh works just fine.
I found a much easier way of doing this.
http://forum.xda-developers.com/showthread.php?t=2276193
hi friends & master
please help me
Is there any way to transfer games and apps to the internal storage with app2sd (moving apps & games in from system Rom to SD card(internal) no memory card)?
my system rom There is almost full
1.44 GB (148 MB free)
internal 12.6 GB (5.8 GB free)
SD card 12.5 GB (5.6 GB free)
I do not need to memory card

[Q&A] MultiSystem for Android

MultiSystem is a powerful tool for locked- and unlocked-bootloader Android devices with many features that at least includes the following:
Keeps stock system partition safe/rooted
Permenant root survival with proper use
MultiROM support via virtual ROMs
Unlimited number of virtual ROMs
Booting options to choose stock, primary, or secondary virtual ROM
Any of the virtual ROMs can work as a recovery replacement
Flashing multiple ROMs at the same time without a reboot
Ability to create/install ROMs on Linux to microSD card
Great performance & battery life on virtual ROMs
Recovery solution to install ROMs or Mods
Easy upgrade to newer versions of Android
Ability to safely apply OTA updates to virtual system
Permissive SELinux and other kernel tweaks
Safe flashing that doesn't trip KNOX flag on Samsung devices
Wrapper script runs via ADB or a Terminal Emulator on device
APK to manage all MultiSystem functions with a nice UI and extra options
Management for the best performance & user experience
Support for all Android devices with microSD card
Portability to almost all devices
Compatibility with all Android versions
Click to expand...
Click to collapse
Q&A​
What is the concept behind MultiSystem?
It runs virtual Android ROMs on microSD, like booting multiple systems on a PC from different partitions/disks. So, your stock system partition is kept safe/rooted. It won't affect performance or anything (might even be better on the virtual system if you've high quality microSD & the device supports its speed). Also, you can freely modify any of the virtual systems & in the worst case, reboot the safe stock system or another working virtual system to recover. So, no root loss or potential damage to the original device partitions.
Click to expand...
Click to collapse
Is it a recovery or an APK tool?
It's a shell script that hijacks system at early boot & force Android to boot from the stock system partition or a virtual system IMG & an APK that manages all booting options, virtual ROMs, and works as a recovery replacement + extra features...
Click to expand...
Click to collapse
Does it work as a recovery replacement?
It IS a POWERFUL recovery replacement. You can do whatever you do in recovery with the APK. HOW? recovery does its magic b/c it doesn't depend on the system & has its own kernel/ramdisk. In MultiSystem, you can boot a virtual ROM from extSD that sure doesn't depend on stock system partition or any of the other virtual ROMs (it does depend on the kernel, which you can't flash on locked devcies anyway). Hence, install, backup, restore, ... & all recovery functions are all possible +++ more features since you're running a full ROM not just a recovery ramdisk like Safestrap.
Bottom Line: I think it's the best & most convenient recovery replacement ever for locked devices & it can also attract unlocked devices for the powerful features, MultiROM, and recovery from within ROM.
Click to expand...
Click to collapse
Can I use FlashFire along with MultiSystem?
Yes. MultiSystem is compatible with FlashFire & fully supports it on stock & virtual ROMs. So, you can use both/any of them for flashing to either a stock or virtual ROM. However, it's recommended to use MultiSystem when flashing to the stock system partition (shouldn't be needed anyway since you can always be safe & flash to your old/new virtual ROMs).
Click to expand...
Click to collapse
Does MultiSystem require FlashFire?
No, MultiSystem doesn't require FlashFire. They're fully combatible though.
Click to expand...
Click to collapse
Would the virtual ROM we install be exactly the one in the stock slot?
In MultiSystem APK, you can create a virtual ROM from stock system, a copy from other virtual ROM, a new IMG, a dev-provided ROM, a flashable .ZIP, ... etc. Literally, your virtual ROMs can be any stock or custom ROM that's compatible with your firmware/kernel.
Click to expand...
Click to collapse
How can it run virtual ROMs from external microSD card?
External MicroSD will be formated into 2 partitions:
exFAT or FAT32 for the 1st partition (your new external storage)
EXT4 for the 2nd partition (your MultiSystem partition)
It'll hijack the system & boot a virtual system from the 2nd partition. The 1st partition will be automatically detected as your extSD.
Click to expand...
Click to collapse
Can I run unrooted virtual ROM for work apps or any other reason?
Yes. You can add unrooted virtual ROM & reboot to it via MultiSystem APK.
Click to expand...
Click to collapse
How do you boot back into a different ROM?
MultiSystem APK manages all functions including ROM activation & reboot to current system, another stock/virtual system, download mode, recovery, ... etc.
Click to expand...
Click to collapse
Will it be OK to still store media like movies/photos/music to extSD?
100% OK; That's my setup a few months ago. 2 virtual ROMs in the SECOND extSD partition in EXT4 format while all personal data are stored on the FIRST extSD partition in exFAT or FAT32 format... TWO COMPLETELY DIFFERET PARTITIONS.
Click to expand...
Click to collapse
How much space are we going to have for virtual ROMs?
The size of the 2nd partition is optional (> 4GB) for your ROMs, but here is an estimated sizes:
1 Virtual ROM Uncompressed = ~2.7 GB ---> ready for running
1 Virtual ROM Compressed = ~1.5 GB ---> for full ROM backups
I'd say better allocate 4 GB for each ROM you plan to run. If you just need one virtual ROM to keep stock system safe, 4 GB 2nd extSD partition is enough; The remaining space is allocated for the 1st extSD partition as your external storage.
For me, I run Linux too from extSD via MultiSystem. So, I've 64 GB extSD card with two partitions 32 GB each.
Click to expand...
Click to collapse
Can I clear up space on an existing SD card and partition it while full or will the entire card need to be wiped and partitioned from scratch?
You need to backup all your files; it'll be wiped & repartitioned.
Click to expand...
Click to collapse
How can I swap microSD cards & be able to run virtual ROMs?
You can swap microSD cards as you wish provided that the device is powered off; don't remove the microSD card when running a virtual ROM. If the new microSD card doesn't include a 2nd parition of available virtual ROMs, the device will boot directly to the stock system.
Click to expand...
Click to collapse
Is there a specific sd card you recommended for this?
I personally have two microSD cards:
SanDisk Extreme Plus 64GB (Up to 80MB/s read speed)
Samsung 64GB PRO (Up to 90MB/s read speed)
You don't have to change your microSD card for MultiSystem; any card you use on your device should work just fine. The need for more speed is relevant when the device supports that speed & if you're going to buy a new card anyway that you may use with a newer device later.
Click to expand...
Click to collapse
Can I copy virtual ROMs to a new microSD card?
Yes. I'll add a feature for swapping microSD cards so that you can backup/restore virtual ROMs from/to the current extSD to/from internal storage as follows:
power off device
use MultiSystem APK to backup your virtual ROMs
insert the new properly formatted microSD,
power on device (it'll boot to stock system)
use MultiSystem APK to restore your virtual ROMs
use MultiSystem APK to activate one of your virtual ROMs
use MultiSystem APK to reboot to any of your ROMs
Click to expand...
Click to collapse
What about other data/cache partitions and internal storage?
Only system img's are in the extSD. All ROMs share all other partitions. This substantially improves the performance & you won't notice any difference between your stock & virtual ROMs. The reason for performance improvement is that EXT4 loop devices are very fast in reading but not in writing. Your system partition is read-only while data (for example) is read write & cache IMGs cause problems like Safestrap issues on ROM slots. Also, you don't have to worry about switching data/settings between ROMs (they're shared), but you just need to regularly backup your important data (which is healthy anyway).
Click to expand...
Click to collapse
Can your elaborate where data is stored?
The userdata partition is also shared; so, you'll have access to all your FULL storage partitions & all apps/data similarly on either stock or virtual ROMs. This also solves the Safestrap issue of having less storage on ROM slots...
Click to expand...
Click to collapse
Will mSDcard incur a significant performance penalty on some devices?
there's no diffrerence between virtual & stock ROMs in terms of performance & battery life. The reason is simple: loop devices associated with the READ-ONLY system IMG mounted from EXT4 partition using a high-quality microSD card IS very fast more than enough.
The read speed is faster than the device can operate anyway + the exact same device should perform on the lowest speed when reading/writing from/to the FAT/FAT32/ExFAT extSD card (where you store your files or even move apps!!!) anyway, which is much slower than the read speed of a loop device mounted from EXT4 partition.
That's why data partition is shared for many reasons, including the poor READ/WRITE performance.
Click to expand...
Click to collapse
If virtual systems are read only, how do we modify them? Do we have to boot to another multisystem rom to modify a virtual rom?
The stock system partition is mounted by default read only & so are the virtual systems. To modify a stock/virtual system, the MultiSystem APK remounts them read/write. You can modify the currently running virtual system, copy it & modify the copy, modify another stock/virtual system.
Click to expand...
Click to collapse
How is a corrupted virtual rom handled? Does it see it's bad and default to stock system?
At early boot, MultiSystem checks for the microSD & active virtual ROM to boot it. There's a boot menu that gives you options to select a stock/virtual system, but it crashes on LP. I'm debugging it, but all functions won't be affected if I removed it. To fail safe, you can remove the microSD card to boot to stock system & restore/repair your virtual ROMs.
UPDATE1: MultiSystem v1.0.1 now allows you to also switch to stock system on boot to repair corrupted virtual IMGs or any other reasons. More options will be added during boot to ultimately select another virtual system if the active IMG is not booting normally (e.g., bootloop after applying a mod or flashing a bad .ZIP).
UPDATE2: Now, on boot, you can choose from two primary/secondary virtual ROM or stock ROM. Flashing multiple ROMs at the same time without a reboot is now possible.
Click to expand...
Click to collapse
How to check if an IMG is corrupted using MultiSystem status?
Code:
Current System IMG: Test_Rom.img
Current System DEV: [B][COLOR="Red"]/dev/block/mmcblk0p23[/COLOR][/B]
When you see "/dev/block/mmcblk0p23"; it's the original system partition; so MultiSystem failed to boot Test_Rom.img, but it should be your current system.
So, the check is simple based on "Current System Device":
/dev/block/mmcblk0p23 = Stock System Partition
/dev/block/loop0 = Virtual System IMG
Note: The block device number (mmcblk0p23) may vary per device & per variant !
Click to expand...
Click to collapse
Does android do any maintenance whatsoever on stored data within /data or external sd? So if I have an app installed on 1 system and not on another system will android see it and clear the data?
No, all storage partitions are shared between ROMs. If you installed an app, it'll be availabe for all of them. Since on locked devcies we're limited to stock manufacturer-based ROMs, this makes the switch between ROMs very convinient (you don't have to worry about your changes/data/setup & storage space on the another ROM; all ROMs share everything except system). However, you should make regular backups in case a virtual ROM (probably with unsafe mods) results in bootloop due to your user data. In this case, it's safe to wipe data & selectively restore apps/data from backup(s). Another advantage of sharing all storage partitions is that your messages/emails/etc received on a virtual ROM are immediated synced (actually shared) to the other ROMs.
Click to expand...
Click to collapse
Will anything like Xposed modify the virtual ROM system IMG as opposed to the stock system IMG?
When you run a Virtual System, everything incldung kernel & apps are hijacked to speak to it as the original system.
Click to expand...
Click to collapse
Can we install AOSP ROMs on locked devices?
You can only install stock/manufacturer-based ROMs on locked devices while unlocked devices can use kexec or flash the required kernel to boot any AOSP/Stock ROMs. I've got a Note 4 Developer Edition & a lot of development is planned to go there (thanks to the unlocked bootloader!) More devices will get supported including unlocked TMO & international variants after adding more features untilizing the unlocked bootloader with kexec'd kernels.
Click to expand...
Click to collapse
Are there limitations to the combinations of ROMs that can be loaded on the "stock" and "virtual" slots? Can you mix KK and LP?
Yes, if they can run on the same kernel. LP won't run on KK kernels & so, you'd have to upgrade the firmware anyway. As for running mixed compatible Android versions, this is possible but your'd have to backup your data before switching ROMs; if it cause no issues, enjoy smooth switch & if it doesn't, do factory reset in recovery & restore your data backup. Backups via MultiSystem are painless.
Click to expand...
Click to collapse
Are applications installed once for each ROM slot that has that applicaiton installed, or can I share a game across ROMs (for instance?)
Everything is shared between ROMs, which is very good for storage & for easy switching. Just make regular backups of your sensitive data.
Click to expand...
Click to collapse
How there are no performance hits while internal storage memory was much faster than any microSD technology?
Read speeds from microSD is very fast compared to write speeds & since virtual ROMs are actually a virtual read-only systems (hence, MultiSystem), they provide a high performance. Moreover, again, read speeds from EXT4 loop devices are higher compared to physical partitions. They're very bad in writing, which we don't need for the read-only "system".
Click to expand...
Click to collapse
Is there a preferred "daily driver" ROM that should be installed in the stock slot?
Uses a stock ODEXED ROM on stock slot for better stability!
Click to expand...
Click to collapse
Is it based off of Safestrap?
Short answer NO. I've been working on MultiSystem & Safestrap for ~7 months. Earlier versions of MultiSystem (called, JasmineREC) was based on Safestrap, but it failed to support newer versions of Android mainly due to TWRP changes in the graphics/UI libraries that cause segmentation fault & the stock kernel framebuffer issues. Then, I decided to find another solution. However, the basic idea of system hijack is powered by Safestrap (or 2nd-init recoveries in general) & all the work done by @Hashcode is GREATLY appreciated.
Click to expand...
Click to collapse
How can it overwrite system files while running?
MultiSystem allows you to install safe mod's or a ROM in full or OTA-like update. It's strongly recommended to install .ZIP files NOT to the current system, b/c some files can not be overwritten while running. So, you can use backup function to copy the current system & install to the new img or any of your other virtual systems. You'll have several options to activate a virtual img & reboot directly to stock system, any virtual img you've activated, quick reboot, Download/bootloader, recovery,... etc.
Click to expand...
Click to collapse
How would I benefit from it if I'm only running Stock ROM or would there be no point for me to install it?
If you run a ROM on stock system, you're vulnerable to root loss unless/untill a new rooting method for LP comes out. MultiSystem gives you the option to run safe-to-mod virtual ROMs + recovery replacement + extra features.
Click to expand...
Click to collapse
Is there a way to convert a normal ROM .ZIP into MultiSystem .IMG?
Create or copy any of your IMGs, activate it & reboot to the active IMG! Then, use FlashFire to flash the ZIP file. However, the updater-script should be safe/compatible. Some devs mount the phyical partition, which will redirect everything to it!!
For example:
Code:
mount(“ext4″, “EMMC”, “/dev/block/mmcblk0p23″, “/system”);
will mount the original system partition; while
Code:
run_program("/sbin/mount", "-t", "auto", "/system");
will mount the current system (stock or virtual). This is recommended/safe.
Click to expand...
Click to collapse
Would a KitKat ROM work with multisystem even though my stock is Lollipop?
Any ROM requires a compatible kernel & modem. So, running KK ROMs requires flashing KK firmware (namely, kernel & modem). This may work with MultiSystem on other devices, especially if the bootlpoader is unlocked. For example, I plan to add features for Note 4 DevED to allow different Android versions (including AOSP, manufacturer-based, & probably Linux systems) by utilizing kernel swapping or execution.
Click to expand...
Click to collapse
When MultiSystem comes out will it be open sourced?
Most probably, haven't decided yet!
Anyway, here's the repository on GitHub: https://github.com/hsbadr/MultiSystem
Click to expand...
Click to collapse
Click to expand...
Click to collapse
Video Tutorials
A quick preview of MultiSystem v1.0 tested on Lollipop for VZW Note 3. The video has been captured on a stable virtual ROM of JasmineROM v5.0.1. It's FULLY compatible with FlashFire on virtual/stock systems. More devices will get supported as well, after required testing.
Facebook: https://www.facebook.com/hsbadr/videos/vb.331488823689599/428178174020663
How to check if you are running a Stock/Virtual System?
There're many ways to check whether you're running a Stock or Virtual system. MultiSystem app should include this simple check at some point. That's important to avoint ruining the Stock system & keep it safe. To make it clear to NOOBZ & anyone who's requesting "another" proof even though I owe hime nothing. Very weird!
Anyway, BusyBox mountpoint applet can print the current block/device mounted to /system mountpoint by running the following command:
Code:
busybox mountpoint -n /system
The stock system is mounts the original system partition:
Code:
[B][COLOR="Red"]/dev/block/mmcblk0p23[/COLOR][/B]
while the virtual system mounts a loop device associated with a system IMG:
Code:
[B][COLOR="Blue"]/dev/block/loop0[/COLOR][/B]
Here're two videos for both stock & virtual systems...
UPDATE:
Now, you could run the following command to print the current system (stock or virtual) and the system device (physical partition or loop device):
Code:
MultiSystem status
Note: The block device number (mmcblk0p23) may vary per device & per variant !
How to repartition microSD card for MultiSystem?
You can use any tool/program for partitioning on Android, Linux, Mac, or Windows. For example, MiniTool Partition Wizard is a good partitioning tool for Windows. So, let's use it for this task. Simply, you need to follow this PDF tutorial (thanks to @carl1961). In sum:
Step 1: delete old partitions on SD card
Step 2: create FAT32 PRIMARY partition
Step 3: create EXT4 PRIMARY partition
Then, apply changes (note that the program UI may get changed in newer versions).
Notes:
This partitioning tutorial doesn't create PRIMARY partitions (it creates logical partitions). So, you need to change "Create As" from "Logical" to "Primary" when creatig a partition.
The sizes of the two partitions are arbitrary depending on number of ROMs you plan to install on the 2nd EXT4 partition.
The 1st partition (check size) is automatically detected as your external storage
In Terminal Emulator or ADB shell, check the existence of the two partitions by running the following command (in red):
Code:
[email protected]:/ # [COLOR="Red"]ls -l /dev/block/platform/msm_sdcc.3/[/COLOR]
drwxr-xr-x root root 2015-05-02 21:08 by-num
lrwxrwxrwx root root 2015-05-02 21:08 mmcblk1 -> /dev/block/mmcblk1
lrwxrwxrwx root root 2015-05-02 21:08 mmcblk1p1 -> [COLOR="Blue"]/dev/block/mmcblk1p1[/COLOR]
lrwxrwxrwx root root 2015-05-02 21:08 mmcblk1p2 -> [COLOR="Blue"]/dev/block/mmcblk1p2[/COLOR]
/dev/block/mmcblk1p1 is mounted by Android as your external storage.
/dev/block/mmcblk1p2 is NOT mounted & will be your MultiSystem partition.
Click to expand...
Click to collapse
How to check microSD card partitions for MultiSystem?
You need to correctly repartition microSD card into two partitions:
exFAT or FAT32 for the 1st partition (your new external storage)
EXT4 for the 2nd partition (your MultiSystem partition)
Use the directions in this post!
You should check your 2nd SD partition in EXT4 format mounted to /MultiSystem:
check that the /MultiSystem directory exists after a reboot
check that the 2nd SD partition (/dev/block/mmcblk1p2) is mounted to /MultiSystem by running the following command in Terminal Emulator or ADB shell:
Code:
mount | grep /MultiSystem
The output should be:
Code:
/dev/block/mmcblk1p2 /MultiSystem ext4 rw,seclabel,relatime,data=ordered 0 0
How to check MultiSystem Installation?
The 1st thing to do after installing MultiSystem is to check the /MultiSystem directory & its contents (it shouldn't be empty!). Then, check usage by running the following commands in Terminal Emulator or ADB shell:
Code:
su
bash
MultiSystem
If it retuns "MultiSystem not found" or permission denied, try to use open MultiSystem app to Update Configurations & try again. If this does't fix it, try the following command:
Code:
/MultiSystem/bin/MultiSystem
This should work if you've MultiSystem binaries installed in (extracted to) /MultiSystem directory. If so, you can create a symlink in /system/xbin as follows:
Code:
mount -o remount,rw /system
ln -sv /MultiSystem/bin/MultiSystem /system/xbin/MultiSystem
Then, test it by running:
Code:
MultiSystem
The last thing before using it is to check the boot options: reboot & monitor the GREEN LED indicator for 3 seconds (change in the app) , which give you the following options:
Volume UP = Primary virtual ROM
Volume DOWN = Secondary virtual ROM
HOME KEY = Stock System
Sure, you should have installed one or more virtual ROMs.
Backup & restore or creating/installing a virtual ROM are easy as copy & paste: all img's will be at
Code:
/MultiSystem/img/system
To backup a virtual/stock system, you have many options:
Use create function to create from stock system
Use copy function to copy the IMG
Copy & paste with a new name
Use FlashFire (fully supported on virtual/stock ROMs)
...
If you've IMG mounting issues, run the following commands:
Code:
mount -o remount,rw /system
busybox ln -sv /proc/self/mounts /system/etc/mtab
If this doesn't help, try mounting from Terminal Emulator or ADB shell after selecting the IMG in MultiSystem app, by running the following command:
Code:
MultiSystem mount virtual
Multisystem Glaxy S4 5.0.1
Great job, they were waiting (I used 4.4.2 Multirom in S4)
I have a question, what would be the way to uninstall Multisystem?
hsbadr said:
The 1st thing to do after installing MultiSystem is to check the /MultiSystem directory & its contents (it shouldn't be empty!). Then, check usage by running the following command in Terminal Emulator or ADB shell:
Code:
MultiSystem
If it retuns "MultiSystem not found" or permission denied, try to use open MultiSystem app to Update Configurations & try again. If this does't fix it, try the following command:
Code:
/MultiSystem/bin/MultiSystem
This should work if you've MultiSystem binaries installed in (extracted to) /MultiSystem directory. If so, you can create a symlink in /system/xbin as follows:
Code:
mount -o remount,rw /system
ln -sv /MultiSystem/bin/MultiSystem /system/xbin/MultiSystem
Then, test it by running:
Code:
MultiSystem
The last thing before using it is to check the boot options: reboot & monitor the GREEN LED indicator for 3 seconds (change in the app) , which give you the following options:
Volume UP = Primary virtual ROM
Volume DOWN = Secondary virtual ROM
HOME KEY = Stock System
Sure, you should have installed one or more virtual ROMs.
Backup & restore or creating/installing a virtual ROM are easy as copy & paste: all img's will be at
Code:
/MultiSystem/img/system
To backup a virtual/stock system, you have many options:
Use create function to create from stock system
Use copy function to copy the IMG
Copy & paste with a new name
Use FlashFire (fully supported on virtual/stock ROMs)
...
If you've IMG mounting issues, run the following commands:
Code:
busybox mount -o remount,rw /system
busybox ln -sv /proc/self/mounts /system/etc/mtab
If this doesn't help, try mounting from Terminal Emulator or ADB shell after selecting the IMG in MultiSystem app, by running the following command:
Code:
MultiSystem mount virtual
Click to expand...
Click to collapse
@hsbadr - I don't have any files in /MultiSystem/bin.... what installs those files? I've opened the apk and clicked "Install" several times, as well as flashed the zip file through flashfire several times. I can't get the Multisystem binary to come up.
screwedbyexisten
---------- Post added at 01:10 AM ---------- Previous post was at 12:48 AM ----------
screwedbyexisten said:
@hsbadr - I don't have any files in /MultiSystem/bin.... what installs those files? I've opened the apk and clicked "Install" several times, as well as flashed the zip file through flashfire several times. I can't get the Multisystem binary to come up.
screwedbyexisten
Click to expand...
Click to collapse
@hsbadr - I went through your install.sh line by line and the point where it gets choked is at the first command that calls busybox:
$BBX mount -o remount,rw rootfs
Which errors with this output:
mount: can't read '/etc/mtab': No such file or directory
EDIT: Solved this problem by doing cat /proc/mounts > /etc/mtab, but now the tar command fails with:
tar: can't open './bin/e2fsck': Input/output error
EDIT 2:
I was continually having I/O errors, so I booted up Ubuntu 14.04 and FULL formatted the ext4 partition.
I then reran the "Install MultiSystem" & "Create Virtual Img" and it appears to be working!:
MultiSystem status
Γöé--------------------------------------------Γöé
Γöé MultiSystem for Android Γöé
Γöé Γöé
Γöé (C) 2014-2015 hsbadr @ xda-developers Γöé
Γöé Hamada S. Badr <[email protected]> Γöé
Γöé--------------------------------------------Γöé
Current System IMG: StockSystem_07-05-2015_074800.img
Current System DEV: /dev/block/loop0
MultiSystem partition is mounted on /MultiSystem!
Log file: /MultiSystem/log/MultiSystem.log
Γöé--------------------------------------------Γöé
Γöé If you'd like to support my work, Γöé
Γöé please donate via PayPal or Google to: Γöé
Γöé Γöé
Γöé Hamada S. Badr <[email protected]> Γöé
Γöé--------------------------------------------Γöé
Now I just need to figure out what I can do with this virtual ROM.
Also I keep getting kicked out of ADB - I have to unplug then replug to get back in. I have attached what I could get from ADB logcat before i got kicked.
will I be able to update my stock rom without interfering MultiSystem?
is it okay if the stock rom is a port, or it should be the stock firmware.?
Wow... Seems a fantastic tool. The shared partitions are a fantastic option!
Right now, I have my external card as this:
1st partition fat32 primary
2nd partition ext4 primary (5,64Gb but only 2,43Gb free).
I'm using Link2SD Plus and the 2nd partition is being used by the app to move the app/data to the external card.
Can I use Link2SD in the same 2nd partition as MultiSystem? Would it be advisable to do so?
Can I create a 3rd partition for MultiSystem? If so, how to point MultiSystem to it as Link2SD seems to be pointed only for the 2nd one.
Is there any app that formats the sdcard partitions within Android?
I've installed the .apk (v 1.3) and flashed the .zip file.
When I click on "Install MultiSystem" nothing occurs (neither a single message ok/error appears).
The same occurs if I try "Create Virtual IMF" from the stock system partition.
Seems it is not operational in my phone. I'm using SlimLP 5.1.1 version.
What am I doing wrong?
P.S. I've read twice everything (official and Q&A) and can't find a solution.
hsbadr said:
Code:
su
bash
MultiSystem
Click to expand...
Click to collapse
This seems to be working.
I've mounted the virtual system and try to reboot into it.
The "Restarting phone" message keeps for more than 10 minutes and the phone does not reboot.
Forcing reboot I got stuck into the Samsung logo (need to enter into recovery and reflash ROM/Kernel/Gapps/Supersu).
Still rocket science to me... :crying:
Technical said:
This seems to be working.
I've mounted the virtual system and try to reboot into it.
The "Restarting phone" message keeps for more than 10 minutes and the phone does not reboot.
Forcing reboot I got stuck into the Samsung logo (need to enter into recovery and reflash ROM/Kernel/Gapps/Supersu).
Still rocket science to me... :crying:
Click to expand...
Click to collapse
If you remove the sdcard, you'll boot normally; it seems that you've a bad IMG. Also, make sure you're on the latest version (currently, 1.3.1)!
hsbadr said:
If you remove the sdcard, you'll boot normally; it seems that you've a bad IMG. Also, make sure you're on the latest version (currently, 1.3.1)!
Click to expand...
Click to collapse
Thanks.
1. I've created the img with the 1.3.1 version that I'm using.
2. I'll try to find how to check the image integrity. By the way, I have 4 images from the stock ROM (Slim 5.1.1). Neither of them works.
Technical said:
Thanks.
1. I've created the img with the 1.3.1 version that I'm using.
2. I'll try to find how to check the image integrity. By the way, I have 4 images from the stock ROM (Slim 5.1.1). Neither of them works.
Click to expand...
Click to collapse
For now, MultiSystem doesn't implement kexec. So, you can't dual boot AOSP & TW ROMs unless you wipe data & flash the required kernel for each ROM.
A video tutorial is coming soon...
hsbadr said:
For now, MultiSystem doesn't implement kexec. So, you can't dual boot AOSP & TW ROMs unless you wipe data & flash the required kernel for each ROM.
A video tutorial is coming soon...
Click to expand...
Click to collapse
I'm not even making to boot the virtual ROM... When I try to flash a zip I got a message: "file:null" when clicking over the .zip file.
I was trying to mount the virtual and flash CM 12.1.
I won't use TW Roms at all.
Technical said:
I'm not even making to boot the virtual ROM... When I try to flash a zip I got a message: "file:null" when clicking over the .zip file.
I was trying to mount the virtual and flash CM 12.1.
I won't use TW Roms at all.
Click to expand...
Click to collapse
Do you see the LED indicator on boot?
Also, check this (it's for other device)!
MultiSystem Video Tutorial
Thanks To: @Tomsgt , aka RootJunky
Don't forget to subscribe & like the video to show appreciation of his great effort & time spent in making the video :highfive::good:
hsbadr said:
Do you see the LED indicator on boot?
Click to expand...
Click to collapse
Yes. If I do nothing, the boot process is kept on bootanimation forever. I've though I was booting in stock ROM. I have to force shutdown.
If I reboot, the green light appears again, then I click on Volume Up, trying to boot the virtual ROM, but I keep seeing the bootanimation too...
hsbadr said:
Also, check this (it's for other device)!
Click to expand...
Click to collapse
Thanks for the explanations. I've partitioned my sdcard again, formated as ext4, primary, I'll try again.
Technical said:
Yes. If I do nothing, the boot process is kept on bootanimation forever. I've though I was booting in stock ROM. I have to force shutdown.
If I reboot, the green light appears again, then I click on Volume Up, trying to boot the virtual ROM, but I keep seeing the bootanimation too...
Thanks for the explanations. I've partitioned my sdcard again, formated as ext4, primary, I'll try again.
Click to expand...
Click to collapse
To boot the stock ROM, double tab the HOME key. It seems you virtual IMG is bad.

Categories

Resources