Related
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?
Hi everyone!
I just got CM7 (latest stable release) installed on on external sdhc card. I have wifi issues with CM7 (and looking around the forums tells me that CM7 can be finicky with certain routers) so I would love to be able to use Nook's stock ROM (4.1.4) when I am having issues.
But, when I am on NC ROM, I don't see anything except the small boot partition on the SD and when I am on CM7, I don't get access to this boot partition. I am wondering if there is a way to either create another partition or make the currently existing partitions accessible on both ROMS so that I can share data between them.
I am a n00b without any Android experience so thanks in advance for your patient responses.
Please use the Q&A Forum for questions &
Read the Forum Rules Ref Posting
Thanks ✟
Moving to Q&A
andrandom said:
Hi everyone!
I just got CM7 (latest stable release) installed on on external sdhc card. I have wifi issues with CM7 (and looking around the forums tells me that CM7 can be finicky with certain routers) so I would love to be able to use Nook's stock ROM (4.1.4) when I am having issues.
But, when I am on NC ROM, I don't see anything except the small boot partition on the SD and when I am on CM7, I don't get access to this boot partition. I am wondering if there is a way to either create another partition or make the currently existing partitions accessible on both ROMS so that I can share data between them.
I am a n00b without any Android experience so thanks in advance for your patient responses.
Click to expand...
Click to collapse
Look in my signature for a link to my tips thread. I explain there how to make the SD media partition available to both ROMs (item B3).
leapinlar said:
Look in my signature for a link to my tips thread. I explain there how to make the SD media partition available to both ROMs (item B3).
Click to expand...
Click to collapse
*That's* the one I wanted to point them to.
leapinlar said:
Look in my signature for a link to my tips thread. I explain there how to make the SD media partition available to both ROMs (item B3).
Click to expand...
Click to collapse
Thanks.
Do you mean step #3 in Section B? I could edit it without running your script too, can't I?
andrandom said:
Thanks.
Do you mean step #3 in Section B? I could edit it without running your script too, can't I?
Click to expand...
Click to collapse
If whatever you have on emmc is rooted, you can manually edit it. If you have unrooted stock, then you need to flash the zip since without root you cannot edit those files manually. And I did mean item B3. Each item is a different topic, they are not steps. One topic does not depend on another. Just do B3 and no others if you want.
Yes, item B3. My mistake...
I should be able to do flash the zip from my current CM7 SD card's boot partition, shouldn't I?
So I put the update-stockemmc-vold-fstab-modified-for-partition4.zip file in the boot partition of the SD card, rebooted to Recovery mode and then booted to NC's stock ROM. NC is still using the tiny boot partition on the SD card as my external storage instead of the much larger CM7 partition. This was the same partition that was under 'My Files / Memory card' before I flashed so nothing has changed. I did this twice to double-check.
Am I doing this wrong?
andrandom said:
Yes, item B3. My mistake...
I should be able to do flash the zip from my current CM7 SD card's boot partition, shouldn't I?
So I put the update-stockemmc-vold-fstab-modified-for-partition4.zip file in the boot partition of the SD card, rebooted to Recovery mode and then booted to NC's stock ROM. NC is still using the tiny boot partition on the SD card as my external storage instead of the much larger CM7 partition. This was the same partition that was under 'My Files / Memory card' before I flashed so nothing has changed. I did this twice to double-check.
Am I doing this wrong?
Click to expand...
Click to collapse
Yes you are doing it wrong. You need to flash that file with a CWM card, not put in the boot partition of your SD. And since you did that, you need to re-flash your latest ROM on SD to correct your mistake. (I will edit my instructions to make it a little clearer that you use CWM to flash that file.)
I got NC stock ROM to see my SD card partition by following item A10. That is most excellent and thanks again!
Unfortunately, I no longer see the boot partition when I attach NC to my computer whether NC is running off stock ROM or CM7. My guess is that this is due to my failed attempt to flash from my CM7 SD card yesterday. Am I right?
I thought I could reverse that by copying the update-stockemmc-vold-fstab-return-to-stock.zip file to CM7's boot (and then booting to the recovery mode) but that seemed to have nothing.
If I understand your previous message correctly, I should re-do my entire SD card but... I have already spent a few hours downloading and customizing the Android apps. Is there a way to preserve all that before Win32diskimager destroys the contents of the SD card?
Is there a way to manually mount the /etc folder from a unix prompt and alter the file?
Does it even matter if I don't see boot while I attach NC to a computer? Are there any caveats to 'let it be'?
Questions, questions and more questions...
That leads me to the obvious question, is there a book that explains Android to someone who is not interested in programming it but wants to understand the architecture and design of the OS (and custom ROMs)?
Thanks for being patient with all these n00b questions.
andrandom said:
I got NC stock ROM to see my SD card partition by following item A10. That is most excellent and thanks again!
Unfortunately, I no longer see the boot partition when I attach NC to my computer whether NC is running off stock ROM or CM7. My guess is that this is due to my failed attempt to flash from my CM7 SD card yesterday. Am I right?
I thought I could reverse that by copying the update-stockemmc-vold-fstab-return-to-stock.zip file to CM7's boot (and then booting to the recovery mode) but that seemed to have nothing.
If I understand your previous message correctly, I should re-do my entire SD card but... I have already spent a few hours downloading and customizing the Android apps. Is there a way to preserve all that before Win32diskimager destroys the contents of the SD card?
Is there a way to manually mount the /etc folder from a unix prompt and alter the file?
Does it even matter if I don't see boot while I attach NC to a computer? Are there any caveats to 'let it be'?
Questions, questions and more questions...
That leads me to the obvious question, is there a book that explains Android to someone who is not interested in programming it but wants to understand the architecture and design of the OS (and custom ROMs)?
Thanks for being patient with all these n00b questions.
Click to expand...
Click to collapse
You do not need or want to re-set up the whole SD installation. Just put the same CM7 zip file back in the boot partition and boot to SD recovery. It will put the correct vold.fstab back on the SD. You will not lose any settings or apps you have already set up. (And putting the return to stock zip there was also the wrong thing to do. The vold.fstab for stock and CM7 are different. But don't worry, it will fix that too.)
You are not supposed to see the boot partition on the PC when you plug the nook in with the cable. You are only supposed to see 'emmc' and 'sdcard'. Under the original setup, your stock system thought the boot partition was 'sdcard' and that was why you saw it on your PC. Since you modified stock to see partition 4 as 'sdcard', partition 4 is what the PC sees, not the boot partition.
Most people have to physically take the card out of the nook and put it in the PC to see the boot partition on the PC. If you don't want to do that, use my script in item B4. But since you are on CM7, you will not be adding many things to the boot partition to install with SD recovery in the future. So it is probably best to leave things be.
And I don't know of any books to help you.
Sent from my Nook Color running ICS and Tapatalk
That is excellent news!
A bit of playing around with Astro tells me that I was wrong about seeing the 'CM7 SDCARD' partition when I was on CM7 ROM. I am only seeing the boot. Anyway, I am going to flash the CM7 ROM again and I am hoping it would fix everything.
Also, yes, I can see the boot partition when I put the SD card directly on my computer but I was also able to see it when I hooked up the NC to my computer via USB before I did my unintended tweaks but... I'll survive.
I'll be back after I flash. (Famous last words??)
Mission accomplished!
Thanks again for all your help.
For future reference after you alter stock's fstab... all you have to do is:
mkdir /sdcard/boot (only have to do this one time)
mount /dev/block/mmcblk1p1 /sdcard/boot (do this every time you want to put something on the boot partition)
put anything you want on boot partition in /sdcard/boot
DizzyDen said:
For future reference after you alter stock's fstab... all you have to do is:
mkdir /sdcard/boot (only have to do this one time)
mount /dev/block/mmcblk1p1 /sdcard/boot (do this every time you want to put something on the boot partition)
put anything you want on boot partition in /sdcard/boot
Click to expand...
Click to collapse
Yes, there is one big advantage to using that method. I think it allows the boot partition to be seen not only on the nook, but also on the PC when you plug in the usb.
leapinlar said:
Yes, there is one big advantage to using that method. I think it allows the boot partition to be seen not only on the nook, but also on the PC when you plug in the usb.
Click to expand...
Click to collapse
We could probably come up with a symlink to /dev/block/mmcblk1p1 to /sdcard/boot and avoid having to mount it everytime as well.
DizzyDen said:
We could probably come up with a symlink to /dev/block/mmcblk1p1 to /sdcard/boot and avoid having to mount it everytime as well.
Click to expand...
Click to collapse
Thank you Dizz, your suggestion got me to thinking and I was able to come up with an init.d bash script that does the trick. I just temporarily mounted sdcard and created the sdcard/boot directory and the mounted the boot partition to it, then unmounted sdcard so it could be mounted again by the system later in the boot sequence.
The only problem is now sdcard will not mount on the PC using UMS mass storage. Must be because of having a second mount within the mount. But it does mount with MTP. But that may be acceptable. I will test some more, including using Goo Manager tomorrow.
EDIT (6-21): Goo Manager works. But I think I have figured out why sdcard is not mounting in UMS. Once it is mounted in my script and the boot partition mounted under it, it cannot be unmounted. And since it cannot be unmounted, it cannot be mounted later by the system as vold. If it cannot be mounted as vold, it does not show in UMS. For now I think I will leave it as I have it in Rev 2 of my script (symlinking to the root directory with full r/w permissions). If people want to see the boot partition on the PC, just use my modified for CM9 NookColorUMS available in my tips thread.
Sent from my Nook Color running ICS and Tapatalk
Help!
When CM7 is running, my computer is no longer mounting any of the partitions when I connect NC to my computer via the USB cable.
If the NC stock ROM is running, my computer mounts all three partitions (MyNook..., boot and CM7SDcard) but calibre is not recognizing the external partitions for transfers.
Further, when I boot to my NC stock ROM, I am no longer seeing my SD card's contents in the NC's library.
This may have something to do with the fact that NC stock ROM seemed to have updated itself to 4.1.3.
Should I re-run the scripts again or am I missing something else?
When it was updated to 1.4.3, you lost the emmc mods. Just re-flash my zip with the CWM SD. You may have lost CWM on emmc too.
On CM7, you have to select the turn on storage button after you plug it in. It is not automatic like stock. Pull up the notification area and touch the turn on button.
Darn, I forgot about that 'USB' option under notifications. Enabling it allows me to find the partitions. I will run your scripts again when I find a spare mUSB card.
Thanks again for your help!
I changed the Android ID on my Nook Color (with Titanium Backup Pro) and now it is boot-looping, at the point where the arrow head moves around in a circle. It is running CM7, but I'm sure the rom is at least a year old. I think it has CWM recovery. How do I get to recovery and what should I do?
[edit] I found this thread and will see if there is something I can use.[/edit]
I pulled the microSDHD from the device and I can read the boot partition on my PC. Before I attempt repair, I want to copy a few data files from the SDCard's data partition, but I do not see it. How do I mount the SDcard partition so that I can copy the files? I know how to do this once I can successfully boot to the Android desktop, but not without the desktop.
I looked through verygreen's SDCard installation instructions here and I can execute boot into recovery, but that just looks for update files and shuts down. I did not get a menu to allow me to mount the data partition via USB for the PC to read or for any options at all.
I have a bootable SDCard (verygreen's) and removed it to boot from emmc. That works, so the problem is on the microSDHC. When I insert the microSDHC (8GB) card in the card reader on my PC, I see the first three partitions are healthy and the last (5.9GB) is not. The only partition that I can assign a drive letter to is the first partition, Boot. Is there any repair I can do to that forth partition?
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.
I am not responsible for any damage that might happen to you, your phone, your sdcard your dog and so on, you are responsible for your own actions.
This is a Linux guide, asking about how to on windows will get no replies as I don't use windows.
First thing you need is a micro sdcard class 10, size up to you, in this guide I am using a 32 bit.
You need a micro sdcard reader.
insert the micro sdcard into your reader, insert reader into computer.
Open gparted
find your micro sdcard, delete entire contents format as fat32.
now make two partitions ext4 size up to you.
in this guide I made first one 1GB and other one 6GB
you should now have 3 partitions ALL 3 must be primary
1 fat32
2 ext4
when finished partitioning sdcard, remove from computer place in phone.
reboot into recovery
open micro sdcard on your computer
create a folder on your micro sdcard
call the folder dual_boot copy below file to this folder
https://www.androidfilehost.com/?fid=745425885120701124
your folder should look like this.
Install > dual_boot
Now all you see in this folder is lineage-p6601-Sdcard.zip
look to lower right of twrp you see install image click it.
now you see all the files.
select twrp_sdcard_recovery.img
next you are given 3 choices Boot, Recovery, System image.
choose recovery
swipe to confirm
back
back
back
reboot recovery
now before you continue
mount system
adb shell
busybox df -h
/dev/block/mmcblk1p3 5.8G 12.0M 5.5G 0% /data
/dev/block/mmcblk1p2 975.9M 1.3M 907.4M 0% /system
if you don't see similar to above don't continue
what above shows is data and system both empty and mounted to sdcard.
if you have above you can continue if not repeat steps until you do.
unmount system
install > dual_boot > lineage-p6601-Sdcard.zip
you should see detected filesystem ext4 for /dev/block/mmcblk1p2
let install finish
reboot system
once you see the word android
adb shell
df -h
you should see similar
/dev/block/mmcblk1p2 992M 638M 353M 65% /system
/dev/block/mmcblk1p3 5.7G 43M 5.7G 1% /data
let boot finish
download gapps place on your micro sdcard
once booted, setup, reboot to recovery and install gapps.
reboot system
the above is to setup dual boot, once setup is complete, to switch between OS, boot into recovery
navigate to dual boot
look to lower right of twrp you see install image click it.
choose which boot.img you want to use
next you are given 3 choices Boot, Recovery, System image.
choose boot
swipe to confirm
reboot system
phone_boot.img is the current OS you have on your phone, in my case v17 if you are running something other than v17, use it's boot.img instead, rename to phone_boot.img and replace the one you downloaded from this guide.
to boot to sdcard select sdcard_boot.img
if you just reboot, whatever the current boot.img that you flashed on your phone will be what OS it boots into, the OS is only changed if you flash another boot.img
if you need to backup rom on your phone you would need to flash twrp_phone_recovery.img else you can only backup sdcard OS.
Notice you will see BELOW!!!! on LineageOS
DO NOT TAP TO FIX!!!!!
DO NOT TAP TO FIX!!!!!
DO NOT TAP TO FIX!!!!!
On phone you will see this.
DO NOT TOUCH IT!!!!!
DO NOT TOUCH IT!!!!!
DO NOT TOUCH IT!!!!!
Note first time switching between OS, may take sometime as each OS, is adjusting to new sdcard.
After that should be just like a normal boot.
I have dual booted every device I own for years, never had a problem.
The OS, doesn't care where it's installed works great, no matter if on phone or sdcard.
can i swipe the notification of sd corrupt and new sd? or is persistent?
Alex19Gam said:
can i swipe the notification of sd corrupt and new sd? or is persistent?
Click to expand...
Click to collapse
I wouldn't.
Sent from my Life Max using Tapatalk