I Highly suggest you follow the steps in this post first (http://forum.xda-developers.com/showthread.php?t=920347)
Froyo is completely stable and will give you a back up OS in case anything happens or you want to do something that doesn't work in HC.
Steps:
If anyone knows how to shrink a partition using parted please let me know. This would eliminate steps 2 & 3
QUICK EDIT WARNING: PLEASE READ: THIS IS BASED ON THE DUAL BOOT FROM ROOKIE1. FROM WHAT I KNOW THIS DOES NOT WORK ON 1.1.0 ONLY 1.0.1
(Note: Requires adb)
1 ) Have a working honeycomb v02 sd card (v03 has a custom kernel which causes rotation issues on the eMMC).
2) Install EASEUS (Windows) or gParted (Linux)
(if you need help with this just PM me)
3) Shrink the second partition of the SD card to 400mb
4) Download and extract my zip to your android/platform-tools folder
5) Run Internal.bat
Make sure not to format your sdcard from your nook while using this.
< standard disclaimer - I'm not responsible for whatever damage you did to your NC >
Also, the reason I did not post a clockwork zip or a dd img for system is I'm unsure of the legality of it, if someone else would like to then by all means do so.
PM me for any questions, and I would like to say thanks to samuelhalff, as without his help I never would've gotten it running from internal memory
Also, please make sure you know how to recover your nook color back to stock. Not only if something goes wrong, but since honeycomb isn't fully working yet.
That being said, if you run the dual-boot script first from rookie1 you'll always be able to fall back onto froyo to fix any issues.
----------------------------------------------------------------------------
How this works:
It copies the system partition from honeycomb onto the internal memory.
It then pushes my boot.img to your sd card.
Finally it overwrites your boot.img with mine
(My boot.img contains everything from rookie1's dual boot alongside the needed jar files included on honeycombs boot.img)
Download link:
http://www.multiupload.com/0TTH2OJS3C
Uploading fixed version now
---------------------------------------------------------------------------------------------------------------------------------------------------------------------------
And for those who like doing everything manually. Here is Sam's modified uRamdisk. Make sure its on the bootpartiton alongside the jar files included in deeper-blue's release
Ramdisk: http://www.multiupload.com/90H38OX0S9
Also, the first time it starts up may take a few min. So be patient before trying to restart it
Thanks this will be very useful for myself and others. I'll report back with any issues.
Why must my laptop break today of all days?
Sent from my SPH-D700 using XDA App
marcusant said:
Why must my laptop break today of all days?
Sent from my SPH-D700 using XDA App
Click to expand...
Click to collapse
Sorry to hear that. I would say you could do it without one but you need the modified ramdisk inside my boot.img
Hey maybe i'm doing something wrong but i keep getting this error message:
rm failed for *, no such file or directory
i am not an expert on adb so this may be my fault, just reporting feedback for you.
tgallant21 said:
Hey maybe i'm doing something wrong but i keep getting this error message:
rm failed for *, no such file or directory
i am not an expert on adb so this may be my fault, just reporting feedback for you.
Click to expand...
Click to collapse
its not rm * its "rm * -r" as that is the recursive switch...
MattJ951 said:
I Highly suggest you follow the steps in this post first (http://forum.xda-developers.com/showthread.php?t=920347)
Froyo is completely stable and will give you a back up OS in case anything happens or you want to do something that doesn't work in HC.
Steps:
QUICK EDIT WARNING: PLEASE READ: THIS IS BASED ON THE DUAL BOOT FROM ROOKIE1. FROM WHAT I KNOW THIS DOES NOT WORK ON 1.1.0 ONLY 1.0.1
(Note: Requires adb)
1 ) Have a working honeycomb v02 sd card (v03 has a custom kernel which causes rotation issues on the eMMC).
2) Download and extract my zip to your android/platform-tools folder
3) Run Internal.bat
Make sure not to format your sdcard while using this.
Note: I'm not sure if you need to clear your data partition or not. I did, but it may not be required.
the steps under froyo would be : something similar to this (I dd'd HC data partition to the internal, so i'm not 100% sure of this)
Code:
adb shell
mount -o remount,rw /dev/block/mmcblk1 /
mkdir data_temp
mount /dev/block/mmcblk0p6 data_temp
cd /data_temp [B]MAKE SURE THIS COMMAND WORKS BEFORE CONTINUING[/B]
rm * -rf
exit
< standard disclaimer - I'm not responsible for whatever damage you did to your NC >
Also, the reason I did not post a clockwork zip or a dd img for system is I'm unsure of the legality of it, if someone else would like to then by all means do so.
PM me for any questions, and I would like to say thanks to samuelhalff, as without his help I never would've gotten it running from internal memory
Also, please make sure you know how to recover your nook color back to stock. Not only if something goes wrong, but since honeycomb isn't fully working yet.
That being said, if you run the dual-boot script first from rookie1 you'll always be able to fall back onto froyo to fix any issues.
----------------------------------------------------------------------------
How this works:
It copies the system partition from honeycomb onto the internal memory.
It then pushes my boot.img to your sd card.
Finally it overwrites your boot.img with mine
(My boot.img contains everything from rookie1's dual boot alongside the needed jar files included on honeycombs boot.img)
Click to expand...
Click to collapse
You have verified this working with your boot.img? Mine gets hampered during the boot and locks up... I had the same issue when I was building my ramdisk for this purpose.... I am going to continue to look into this and will post anything I find.
Cheers!
A quick question:
You say not to format the SDCard while using this. Does this mean that there are still some system files on the SDCard after the procedure is done or can I format my card as FAT32 once the whole operation is done?
Ooglez said:
A quick question:
You say not to format the SDCard while using this. Does this mean that there are still some system files on the SDCard after the procedure is done or can I format my card as FAT32 once the whole operation is done?
Click to expand...
Click to collapse
I believe I may have included an incorrect boot.img in my original upload, im reuploading it now.
As for formatting the sd card, i'll clairfy that in the OP. Don't format the sd card from inside the nook. formatting it inside a computer is fine.
MattJ951 said:
How this works:
It copies the system partition from honeycomb onto the internal memory.
It then pushes my boot.img to your sd card.
Finally it overwrites your boot.img with mine
(My boot.img contains everything from rookie1's dual boot <B>alongside the needed jar files included on honeycombs boot.img)</B>
Click to expand...
Click to collapse
I think I see the issue, your dd image is lacking those jar files... I am going to try and add those files to my boot partition and go from there.... Disregard! per the post above this one.......
modembug said:
I think I see the issue, your dd image is lacking those jar files... I am going to try and add those files to my boot partition and go from there.... Disregard! per the post above this one.......
Click to expand...
Click to collapse
The boot.img must be from another project I was working on. It's using the wrong u-boot.bin and is missing the jar files. Updating main post in 20 seconds once it finishes uploading
And its up.
http://www.multiupload.com/KPDAPGYXSI
Also thanks for the feedback.
MattJ951 said:
The boot.img must be from another project I was working on. It's using the wrong u-boot.bin and is missing the jar files. Updating main post in 20 seconds once it finishes uploading
And its up.
http://www.multiupload.com/KPDAPGYXSI
Click to expand...
Click to collapse
Thanks for updating so quickly. I've been waiting to run Honeycomb off of EMMC. I'll let you know how it goes.
MattJ951 said:
The boot.img must be from another project I was working on. It's using the wrong u-boot.bin and is missing the jar files. Updating main post in 20 seconds once it finishes uploading
And its up.
http://www.multiupload.com/KPDAPGYXSI
Also thanks for the feedback.
Click to expand...
Click to collapse
I am getting ready to dd that image over as we speak, i will report back shortly...
No problem, let me know if it works and if it doesn't ill try updating it again. (I personally have it working but I didn't use a script, i entered the commands manually. Also make sure youre using v02 [though note: HC runs faster for some reason if you copy the data partition from v03 and dd it to the internal while running v02's system. v03 has problems with the kernel due to the 90degrees thing deeper added]
MattJ951 said:
No problem, let me know if it works and if it doesn't ill try updating it again. (I personally have it working but I didn't use a script, i entered the commands manually. Also make sure youre using v02 [though note: HC runs faster for some reason if you copy the data partition from v03 and dd it to the internal while running v02's system. v03 has problems with the kernel due to the 90degrees thing deeper added]
Click to expand...
Click to collapse
I am having issues with it locking up on "Android _ " could be due to crap on the data partition from the last boot.img... cleaning it off and trying again. Yeah I took a look at your bat file and just ran things manually... i have issues with unknown bat/sh files lol
UPDATE: okay, so its still locking up... did you dd the data partition or any of that stuff over as well? as of right now, i am running your boot.img and i DD'd the system partition from a working HC-SD, and i removed all files from the internal /data partition....
modembug said:
I am having issues with it locking up on "Android _ " could be due to crap on the data partition from the last boot.img... cleaning it off and trying again. Yeah I took a look at your bat file and just ran things manually... i have issues with unknown bat/sh files lol
Click to expand...
Click to collapse
Let me know if it works. The "Android _" screen originally locked up for me because of the uRamdisk. I'll upload the one Sam sent me which is included in the boot.img but maybe is causing problems for you.
The modified uRamdisk is now in the OP.
Nada, still no dice.... I have all the folders from HC /Boot with your boot files replacing uboot, uramdisk etc.. Still running into the same issue, might need to work busybox into this thing to see what is going on...
UPDATE: going to try dd'ing the /data part over to emmc /data..
modembug said:
Nada, still no dice.... I have all the folders from HC /Boot with your boot files replacing uboot, uramdisk etc.. Still running into the same issue, might need to work busybox into this thing to see what is going on...
UPDATE: going to try dd'ing the /data part over to emmc /data..
Click to expand...
Click to collapse
Thats not the problem. I realized my mistake.
where i wrote
adb shell dd if=/dev/block/mmcblk0p5 of=/dev/block/mmcblk1p1
it should be
adb shell dd if=/dev/block/mmcblk0p5 of=/dev/block/mmcblk1p2
if you run that it should boot correctly.
uploading a fixed version to the OP now
MattJ951 said:
Thats not the problem. I realized my mistake.
where i wrote
adb shell dd if=/dev/block/mmcblk0p5 of=/dev/block/mmcblk1p1
it should be
adb shell dd if=/dev/block/mmcblk0p5 of=/dev/block/mmcblk1p2
if you run that it should boot correctly.
uploading a fixed version to the OP now
Click to expand...
Click to collapse
which is why i run commands manually ;-) yeah I double check prior to DD and i have pushed the correct partition to /system... i have now pushed /data over and still no love... Can you dd your /boot and post it?
modembug said:
which is why i run commands manually ;-) yeah I double check prior to DD and i have pushed the correct partition to /system... i have now pushed /data over and still no love... Can you dd your /boot and post it?
Click to expand...
Click to collapse
That actually is my current /boot inside the 7z. Also i can't think of a reason why it wouldn't work.
I'll format my NookColor and try it to see if I can figure out whats going wrong.
Related
Here are the DD images for Deeper-Blue's Honeycomb v04 build
Just unzip them onto an SD card with CWR (make sure to mount the sd card in CWR) or a Froyo/HC SD build and type
dd if=/sdcard/boot.img of=/dev/block/mmcblk0p1
dd if=/sdcard/system.img of=/dev/block/mmcblk0p5
Credits to Deeper-Blue for the v04 image, and samuelhalff for providing the uRamdisk back for the v02 version.
As always do this at your own risk, I, nor anyone else here is responsible for what you do to your nook.
DOWNLOAD:
http://www.multiupload.com/KA4NKE7J3J
For a flashable CWR zip please see this thread:
http://forum.xda-developers.com/showthread.php?t=947071
If you have any problems please post, and as with the others
DO NOT FORMAT YOUR SD CARD FROM INSIDE YOUR NOOK COLOR
------------------------------------------------------------------------
How it was done (though this time you'll want to run the dual-boot script after flashing the dd images or edit your boot partition manually:
edit for clarification: running the dual-boot script is not required, but if you do want it, run it after this time, not before
http://forum.xda-developers.com/showthread.php?t=943724
edit: Also deleting your data partition may speed things up, but I dont *believe* it is required
MattJ951 said:
How it was done (though this time you'll want to run the dual-boot script after flashing the dd images or edit your boot partition manually:
http://forum.xda-developers.com/showthread.php?t=943724
Click to expand...
Click to collapse
So wait, we have to use the dual boot script to run this on emmc?
RileyGrant said:
So wait, we have to use the dual boot script to run this on emmc?
Click to expand...
Click to collapse
Updated the OP after reading this. It is not required to run the dual-boot script, however if you wish to dual boot froyo alongside honeycomb, then run rookie1's script afterwards, rather than before
Any idea how to get the sd card to mount? Several apps will not work without it? Dropbox, Nook, etc.
You need to fix the volds, you can probably take them from the froyo thread. I highly suggest installing sam's verison btw as it has many more things installed (such as the fixed vold, along with SU permissions)
I had downloaded a version of this file from a post embedded deep inside one of the threads over here (sorry can't find it right now), but upon examination of its contents, I discovered some issues:
1. The checksums on the files in contained in the the original zip file showed that B&N had at least two versions of 1.3.0 update you can download from them, and the zip I got contained an older version so I put in the latest files in there.
2. There were unnecessary files included inside the original zip file, I deleted those, and only included what was needed.
3. There were errors in the script syntax, which I corrected, so that the proper commands are run during the update, and the proper sed substitutions are made during the editing of the unpacked init.rc inside the ramdisk.
What this zip will do is replace any older version of a B&N ROM on the alternate eMMC partitions of a dual booting configurations to the latest versions. This will prevent B&N from pushing the 1.3.0 update to you OTA, and messing up your dual boot setup. Just put the zip on your sdcard, boot into CWM recovery, and apply the zip. I apologize in advance for not giving credit to the original creators of the scripts here.
Note: There have been two different protocols for a dual booting u-boot.bin, with an older one relying on the files u-boot.altimg, and u-boot.altram to specify the names of the secondary boot ramdisk and kernel, and a newer one assuming that they are named uAltRam, and uAltImg respectively. This update conforms to the new u-boot.bin protocol. If you are still using the old one, you will have to get root access to /boot and edit the two files to point to uAltRam and uAltImg.
So if you want try it out, here it is:
http://www.mediafire.com/?gcrpzzc0kdoxcjx
MD5 Sum: 51e24c1e5eff11ba5ea481a63f7404eb
Update
I have now uploaded files for B&N Update 1.4.1.
The first file (MD5 Sum: 4ff1d9764663278c3f51e2e2c9d841a6) is meant to update a pre 1.4.1 Stock B&N ROM on secondary /system through CWM:
https://rapidshare.com/files/52135913/secondary_update_NC_stock_1_4_1.zip
The second file (MD5 Sum: c1506816fbfb8c419fbbc4afe1b12887) is meant to update a pre 1.4.1 Stock B&N ROM on primary /system through CWM without messing with recovery;
https://rapidshare.com/files/869435270/primary_update_NC_stock_1_4_1_keep_CWM.zip
The third file (MD5 Sum: ab1307c55a2c35c91d339c8037ce9a78) is meant to update a pre 1.4.1 Stock B&N ROM on primary /system through CWM, replacing recovery and all:
https://rapidshare.com/files/2059644016/primary_update_NC_stock_1_4_1.zip
None of these files will wipe user apps and data, so if you wish to do that, boot into recovery and wipe from there. [This will work on primary /data partition only]
Please note: If the B&N Stock ROM is rooted, you will lose root upon updating.
Thanks!
This worked beautifully! I flashed it from my sdcard after booting into CWM on my primary partition on emmc.
I'm betting you got the original from jasoraso in this dual boot thread: http://forum.xda-developers.com/showpost.php?p=17122342&postcount=142
What I would love is a straight CWM-flashable 1.3 ROM, to include in my up-to-date (for now) guide for setting up the dual boot, rather than having to set up and move 1.2, then update to 1.3.
That is possible to do by combining three of the steps. You need commands from the scripts from the prepare dual boot zip to resize /media and create the secondary system and data partitions, then the part of the script from the file that copies the contents of /data from primary to secondary and replaces u-boot.bin , and then my file which formats secondary /system and puts 1.3.0 there, and copies the latest kernel and patched ramdisk onto /boot. I can put such a file together, but I wouldn't be able to test it. The Nook belongs to my wife, and and you get the rest of the drift.
PS - You can use my file as is after running prepare dual boot and copy stock to secondary. It is not necessary to update secondary to 1.2 before going to 1.3.
Sent from my SAMSUNG-SGH-I897 using XDA App
rajendra82 said:
That is possible to do by combining three of the steps. You need commands from the scripts from the prepare dual boot zip to resize /media and create the secondary system and data partitions, then the part of the script from the file that copies the contents of /data from primary to secondary and replaces u-boot.bin , and then my file which formats secondary /system and puts 1.3.0 there, and copies the latest kernel and patched ramdisk onto /boot. I can put such a file together, but I wouldn't be able to test it. The Nook belongs to my wife, and and you get the rest of the drift.
Click to expand...
Click to collapse
Wait...what? What I'm talking about is a 1.3 zip made to work with CWM and in no way doctored to account for dual booting, just like the 1.2 zip one would otherwise use.
rajendra82 said:
PS - You can use my file as is after running prepare dual boot and copy stock to secondary. It is not necessary to update secondary to 1.2 before going to 1.3.
Click to expand...
Click to collapse
Have you tested this theory? I found that when I did not register my B&N install while it was on the primary partition, I was unable to boot into it on the secondary partition.
Taosaur said:
Wait...what? What I'm talking about is a 1.3 zip made to work with CWM and in no way doctored to account for dual booting, just like the 1.2 zip one would otherwise use.
Click to expand...
Click to collapse
Are you talking about updating an already rooted 1.0/1.1/1.2 Nook Color. I am sure the scripting to do that is exactly the same as what is in the 1.2 zip file. Just replace the 1.2 files inside the zip with the equivalent files from the 1.3 update. Make sure the portions which install su and busybox are included, and build.prop spoofig is applied. I am not sure it is worth it building such a zip file though. One is better off just applying the B&N update, and then rerooting with manual nooter. What I created was for people that have already doctored the setup for dual booting. In such a case, the B&N update would either fail, or would replace the primary partition instead.
Taosaur said:
Have you tested this theory? I found that when I did not register my B&N install while it was on the primary partition, I was unable to boot into it on the secondary partition.
Click to expand...
Click to collapse
No way to get around having to register the primary partition image first. Once that is done it could be moved to secondary and then updated straight to 1.3 instead of going 1.2 first.
I have a dual boot eMMC NC. I am not sure which setup I use but the last time I updated the CM7 nightly, I lost the dual boot until I installed the u-Boot again. I suspect I have the setup that looks for altFImg. So this is not going to work for me. I have 1.2 rooted which I use only occasionally. I am not even sure what is in 1.3 but I am curious.
yelloguy said:
I have a dual boot eMMC NC. I am not sure which setup I use but the last time I updated the CM7 nightly, I lost the dual boot until I installed the u-Boot again. I suspect I have the setup that looks for altFImg. So this is not going to work for me. I have 1.2 rooted which I use only occasionally. I am not even sure what is in 1.3 but I am curious.
Click to expand...
Click to collapse
All you need to do is boot into CM7, mount /boot as root, and then rename uFImg to uAltImg, uFRam to uAltRam, and then change the text inside u-boot.altimg and u-boot.altram to point to the new names instead of the old ones. This will keep you dual booting under the old u-boot.bin, and even after a new protocol u-boot.bin (like that installed by CM7) gets pushed to your Nook Color. Once you have done that, you can update the secondary to 1.3 using my zip file if you want.
rajendra82 said:
Are you talking about updating an already rooted 1.0/1.1/1.2 Nook Color. I am sure the scripting to do that is exactly the same as what is in the 1.2 zip file. Just replace the 1.2 files inside the zip with the equivalent files from the 1.3 update. Make sure the portions which install su and busybox are included, and build.prop spoofig is applied. I am not sure it is worth it building such a zip file though. One is better off just applying the B&N update, and then rerooting with manual nooter. What I created was for people that have already doctored the setup for dual booting. In such a case, the B&N update would either fail, or would replace the primary partition instead.
Click to expand...
Click to collapse
I wouldn't know what to change and what to leave alone, myself, but I think you're making this more complicated than it needs to be. I'm talking about installing 1.3 using CWM, regardless of how the device is partitioned or what was on the primary partition previously. Like the files in this thread, but 1.3: http://forum.xda-developers.com/showthread.php?t=1050520.
I understand that you were just cleaning up jaso's update-dualboot-to-1.3 file. I used the original and it worked fine, but it would have saved me a couple steps (and would be more useful in a guide for setting up dualboot) to simply install 1.3 rather than 1.2 to the primary partition when setting up. The reason I started with 1.2 is because it is the most current stock ROM available for CWM. What I would like is to avoid a historical re-enactment of stock OS development altogether. A general-purpose, CWM-flashable 1.3 ROM would be broadly useful, but is so far lacking as far as I've seen.
1. Do you envision this to be an uprooted stock 1.3 update ROM (either as primary or the only boot option) ? I just don't see the need for this to be CWM flashable. It is very easy to get there by resetting the device to stock, and then updating the device to 1.3.0 using the B&N file, and restoring dual boot as need be. If one has any older stock ROM running on primary, the B&N update will get them to 1.3 while losing root. There is no need to apply 1.2 update first.
2. Do you envision this to be for already rooted single or primary booting 1.1/1.2 users? There is once again no need to create any file for this. One can simply apply the B&N update, and then rerun manual nooter, and restore dual booting to the secondary.
3. The only users with no clear upgrade path are those who have already moved the B&N ROM to secondary. That's why I fixed up the zip file, and shared it. I am glad the original file worked for you despite the script errors. I can see other setups where it would have failed though.
I am not trying to make this more complicated than it needs to be. The Nook Color is just capable of being set up in so many ways, there isn't simply going to be a single update method that will work in all scenarios.
Sent from my SAMSUNG-SGH-I897 using XDA App
I'm envisioning it as a one step, starting-point-agnostic means of establishing a 1.3 stock install, whether for setting up a dualboot or for any other purpose. Its usefulness is made evident by the three-page thread devoted to CWM-flashable 1.2 images: http://forum.xda-developers.com/showthread.php?t=1050520
Taosaur said:
I'm envisioning it as a one step, starting-point-agnostic means of establishing a 1.3 stock install, whether for setting up a dualboot or for any other purpose. Its usefulness is made evident by the three-page thread devoted to CWM-flashable 1.2 images: http://forum.xda-developers.com/showthread.php?t=1050520
Click to expand...
Click to collapse
Then the best bet is two step process:
1. Wipe device and restore to factory stock.
2. Download B&N 1.3 update file from website and place it on the root of SD card. Let the device recognize it, and apply it.
Once the 1.3 update gets applied, you are free to reroot, install CWM, set up dual booting, or whatever the next step may be.
It is the only method that will work in all circumstance as it involves starting from scratch regardless of setup. If want to preserve any of your current setup, no one step file will work for all circumstances. Some people have the stock firmware rooted, others do not. Some have the stock as the only internal boot, others have it as primary option of a dual booting configuration, while others have it as a secondary option. Some have stock recovery and run CWM off the sdcard when needed and want to update their recovery to the latest stock version, others want to keep the CWM recovery, and not update the recovery. There simply is no way file to cope with all these options.
rajendra82 said:
All you need to do is boot into CM7, mount /boot as root, and then rename uFImg to uAltImg, uFRam to uAltRam, and then change the text inside u-boot.altimg and u-boot.altram to point to the new names instead of the old ones. This will keep you dual booting under the old u-boot.bin, and even after a new protocol u-boot.bin (like that installed by CM7) gets pushed to your Nook Color. Once you have done that, you can update the secondary to 1.3 using my zip file if you want.
Click to expand...
Click to collapse
You lost me at mount
Seriously, I am trying to see if what I have is compatible with your update before I apply the update. I have a couple of useful apps on my CM7 and I have lost the password. I don't want to be stuck without CM7 or start over again. I can live without the 1.3 update though. So I want to make sure I am up to the task of finding and renaming these files if I have to.
With that said, how do I mount the /boot partition? I go into terminal emulator and give the su command. Then I tried mount /boot but that didn't work.
Thanks for your help.
rajendra82 said:
1. Wipe device and restore to factory stock.
Click to expand...
Click to collapse
...the only means of doing so "that will work in all circumstance" and in any way resembles a single step is flashing a stock zip via CWM. Why not use an up-to-date zip? The usefulness of such files is demonstrated by the fact that:
such files exist for past stock versions
those files are in use
files like yours are used to work around the non-existence of up-to-date stock zips
If you're so comfortable working with update files, you very likely could have produced such a file in less time than you've spent rationalizing away the clearly demonstrated need for them. Tell you what, in all likelihood I can just swap a few files from B&N's 1.3 zip into the existing CWM-flashable 1.2 zips, correct? Which files do I replace?
Anyone?
---------- Post added at 02:15 PM ---------- Previous post was at 01:58 PM ----------
yelloguy said:
You lost me at mount
Seriously, I am trying to see if what I have is compatible with your update before I apply the update. I have a couple of useful apps on my CM7 and I have lost the password. I don't want to be stuck without CM7 or start over again. I can live without the 1.3 update though. So I want to make sure I am up to the task of finding and renaming these files if I have to.
With that said, how do I mount the /boot partition? I go into terminal emulator and give the su command. Then I tried mount /boot but that didn't work.
Thanks for your help.
Click to expand...
Click to collapse
I don't know for sure, but wouldn't rajendra's update create properly-named boot files alongside the old, improperly named ones? Wouldn't the multiboot built in to recent CM7 builds then look for and boot from the more recent, properly named files? I can't confirm that's how it would work, but it's what I would expect.
Taosaur said:
I don't know for sure, but wouldn't rajendra's update create properly-named boot files alongside the old, improperly named ones? Wouldn't the multiboot built in to recent CM7 builds then look for and boot from the more recent, properly named files? I can't confirm that's how it would work, but it's what I would expect.
Click to expand...
Click to collapse
Yes they would create properly named boot files. But I suspect my nook looks for improperly named files since I updated my u-boot after the CM7 nightly update.
The fix is simple: to rename the files. But I need to know how before I take the plunge.
yelloguy said:
Yes they would create properly named boot files. But I suspect my nook looks for improperly named files since I updated my u-boot after the CM7 nightly update.
Click to expand...
Click to collapse
Right, but if you run a CM7 update, it would replace your uboot again. I'm not saying do it, just wondering out loud if it would work.
yelloguy said:
Yes they would create properly named boot files. But I suspect my nook looks for improperly named files since I updated my u-boot after the CM7 nightly update.
The fix is simple: to rename the files. But I need to know how before I take the plunge.
Click to expand...
Click to collapse
In order to rename the files, you can do the following:
1. Boot into CM7 (or any other place where you have command line root access)
2. Create a temporary directory at a location where you have read write access.
3. Type su in a terminal session to gain root access and then mount mmcblk0p1 at the temporary location you created using the command:
mount /dev/block/mmcblk0p1 <full path to the directory you created>
4. Now use Astro to go over to the directory you created and mounted mmcblk0p1 into. You should see:
u-boot.bin which is the bootloader
u-boot.bin.stock which is the backup of the old stock bootloader
uImage and uRamdisk which are your primary kernel and ramdisk
uFImg and uFRam which are your secondary kernel and ramdisk (and whose names are mismatching the CM7 bootloader protocol)
u-boot.altimg and u-boot.altram, which are text files per the old bootloader method containing names of uFImg and uFRam
5. Rename uFImg to uAltImg, uFRam to uAltRam. And edit the contents of u-boot.altimg and u-boot.altram to match the new file names.
6. Reboot as usual into primary or secondary.
Now if an CM7 update ever replaces your u-boot.bin, you will not lose dual boot, as you have it set up as uAltImg and uAltRam per the new protocol.
Sent from my SAMSUNG-SGH-I897 using XDA App
---------- Post added at 03:24 PM ---------- Previous post was at 03:06 PM ----------
Taosaur said:
...the only means of doing so "that will work in all circumstance" and in any way resembles a single step is flashing a stock zip via CWM. Why not use an up-to-date zip? The usefulness of such files is demonstrated by the fact that:
such files exist for past stock versions
those files are in use
files like yours are used to work around the non-existence of up-to-date stock zips
If you're so comfortable working with update files, you very likely could have produced such a file in less time than you've spent rationalizing away the clearly demonstrated need for them. Tell you what, in all likelihood I can just swap a few files from B&N's 1.3 zip into the existing CWM-flashable 1.2 zips, correct? Which files do I replace?
Anyone?
Click to expand...
Click to collapse
I am sorry if you think I am rationalizing, but that was not my intention. I just wanted to point out that the files you linked to do not meet your own criteria.
Take for example the file update-nc-stock-1.2-keepcwm-signed.zip that you point to as missing in an up to date 1.3 version. That file will update a Nook Color to 1.2, but will keep CWM recovery. It however will make someone whose Nook Color 1.1 was rooted using autonooter lose root. A person that has been dualbooting to CM7 on secondary will lose that ability as well after applying that update. So unlike what you think, this is not a file to update stock 1.2 update under all circumstances regardless of what the starting point is. It has a specific use (update fro, a pre 1.2 stock primary eMMC boot, no dualboot, CWM recovery installed). Creation of an all situation stock restore file is impossible IMO, and the best you can do is wipe and apply 1.3 B&N stock update. You or I could technically create another equivalent file with update-nc-stock-1.3-keepcwm.zip /system files, kernel, ramdisk, etc., but this file would be subject to the same side effects as the original.
---------- Post added at 03:30 PM ---------- Previous post was at 03:24 PM ----------
Taosaur said:
Right, but if you run a CM7 update, it would replace your uboot again. I'm not saying do it, just wondering out loud if it would work.
Click to expand...
Click to collapse
It would work. If you apply my zip, there will be a uAltImg and uAltRam in /boot (in addition to uFImg and uFRam). If you apply another update that pushes the CM7 bootloader, it will then look for these files with trying to do an alternate boot, and would boot into a unrooted stock 1.3.
rajendra82 said:
In order to rename the files, you can do the following:
1. Boot into CM7 (or any other place where you have command line root access)
2. Create a temporary directory at a location where you have read write access.
3. Type su in a terminal session to gain root access and then mount mmcblk0 at the temporary location you created using the command:
mount /dev/block/mmcblk0 <full path to the directory you created>
Click to expand...
Click to collapse
I get an error:
mounting <paths> failed: Device or resource busy
Any ideas?
yelloguy said:
I get an error:
mounting <paths> failed: Device or resource busy
Any ideas?
Click to expand...
Click to collapse
I see a typo in my command (stupid Swiftkey X). It should be:
mount /dev/block/mmcblk0p1 <some directory>
Also try typing just mount in terminal to see if /dev/block/mmcblk0p1 is already mounted somewhere else.
rajendra82 said:
Take for example the file update-nc-stock-1.2-keepcwm-signed.zip that you point to as missing in an up to date 1.3 version. That file will update a Nook Color to 1.2, but will keep CWM recovery. It however will make someone whose Nook Color 1.1 was rooted using autonooter will lose root. A person that has been dualbooting to CM7 on secondary will lose that ability as well after applying that update. So unlike what you think, this is not a file to update stock 1.2 update under all circumstances regardless of what the starting point is. It has a specific use (update fro, a pre 1.2 stock primary eMMC boot, no dualboot, CWM recovery installed). Creation of an all situation stock restore file is impossible, and the best you can do is wipe and apply 1.3 B&N stock update. You or I could technically create another equivalent file with update-nc-stock-1.3-keepcwm.zip /system files, kernel, ramdisk, etc., but this file would be subject to the same side effects as the original.
Click to expand...
Click to collapse
Riiiiight... it would install stock 1.3 to the device. That's the intended behavior. The point is to avoid the unnecessary step of updating in any process that includes flashing stock to the sole or primary partition. One example of such a process would be a fresh dual boot setup. That it does not update or otherwise rely upon an existing install is the point.
Granted, such a file would not repartition the device, but it would install up-to-date stock in one step regardless of how a device is partitioned (1/5, 2/5, 5/1 or dual boot).
I just received my new 32gb SD card, and am wondering how to ensure that my ext3 partition is also copied over, not just the fat32 files. I have found some other threads regarding this process but I still have some unanswered questions.
FYI, I am using MIUI 1.11.4 on a rooted Acer Liquid E (and malez-recovery, which is based on CM).
1. The general consensus seems to be to do a nandroid backup, partition the new card with gparted, and restore that backup (and obviously copy the fat32 files to my computer and then transfer back). I'd just like someone to tell me I'm correct before I try it.
2. On every single one of the threads I found, it always says to do a nandroid backup. Do they really mean a nandroid+ext backup?! Will the basic nandroid backup do the trick (I don't see how)? I'm concerned about this because I always get errors when I attempt a nandroid+ext backup. I plan to run nandroid-mobile.sh -b -e via adb once my file transfer is complete (stupid slow old sd card + computer), but I'm not confident that it'll work. If it doesn't, what options do I have for accessing the ext3 partition? **UPDATE: I ran nandroid-mobile.sh, and it eventually said "--ext2 specified but unable to mount the ext2 partition". I'm still Googling but I haven't figured out a solution yet. Ideas?
3. Every thread recommends using gparted but provides no justification as to why. Since I am using Windows, the whole process seems over-complicated. Can I not just use the "partition sd card" available through recovery? Why is it better to use gparted?
Thanks for any help you can give a semi-n00b!
skittleys said:
1. The general consensus seems to be to do a nandroid backup, partition the new card with gparted, and restore that backup (and obviously copy the fat32 files to my computer and then transfer back). I'd just like someone to tell me I'm correct before I try it.
2. On every single one of the threads I found, it always says to do a nandroid backup. Do they really mean a nandroid+ext backup?! Will the basic nandroid backup do the trick (I don't see how)? I'm concerned about this because I always get errors when I attempt a nandroid+ext backup. I plan to run nandroid-mobile.sh -b -e via adb once my file transfer is complete (stupid slow old sd card + computer), but I'm not confident that it'll work. If it doesn't, what options do I have for accessing the ext3 partition?
3. Every thread recommends using gparted but provides no justification as to why. Since I am using Windows, the whole process seems over-complicated. Can I not just use the "partition sd card" available through recovery? Why is it better to use gparted?
Thanks for any help you can give a semi-n00b!
Click to expand...
Click to collapse
1. Do that (just do it ; in case anything goes wrong, you can restore the nandroid backup and have your device up and running easily). If you don't create one (make sure you do) you will have a hard time getting your device to work again (and depending on your device, it may not be fixable).
2. Just make a nandroid backup. Some roms have it enabled by default (access to the partition). See here: http://forum.cyanogenmod.com/topic/19160-modhow-to-apps2ext-for-cm7-updated-03312011/.
3. Using GParted is the easiest method (which is why it is recommended): http://gparted.sourceforge.net/.
Theonew said:
3. Using GParted is the easiest method (which is why it is recommended): .
Click to expand...
Click to collapse
Easier than 3 multiple-choice questions in a recovery I've already installed???
Theonew said:
2. Just make a nandroid backup. Some roms have it enabled by default (access to the partition). See here:.
Click to expand...
Click to collapse
I doubt that my ROM does an ext backup by default.... I have now run nandroid-mobile.sh and eventually got the following message: "Warning: --ext2 specified but unable to mount the ext2 partition". I'm still Googling but I haven't yet figured out a solution for this. In the meantime, I have copied /sd-ext to my computer, which might end up being a decent workaround...but I'd still love to know what's going on!
**UPDATE: Something I've noticed...:
If I access the phone after a "normal" reboot, /sd-ext definitely exists (I can see it using simply ls, and also mount and df), but no scripts are available in /sbin.
When I go into recovery, /sbin contains all the scripts (so I can now run nandroid), but /sd-ext doesn't appear!
I've a strong suspicion this is why the partition can't be mounted during the nandroid backup.
So how do I fix this?!
skittleys said:
Easier than 3 multiple-choice questions in a recovery I've already installed???
Click to expand...
Click to collapse
According to others, yes .
skittleys said:
**UPDATE: Something I've noticed...:
If I access the phone after a "normal" reboot, /sd-ext definitely exists (I can see it using simply ls, and also mount and df), but no scripts are available in /sbin.
When I go into recovery, /sbin contains all the scripts (so I can now run nandroid), but /sd-ext doesn't appear!
I've a strong suspicion this is why the partition can't be mounted during the nandroid backup.
So how do I fix this?!
Click to expand...
Click to collapse
You cannot "fix" it. That is one reason but it also really depends on your device. For example: http://www.jayceooi.com/2011/01/12/...tition-on-sd-card-with-clockworkmod-recovery/ - This device is able to do it from recovery and it is easier than the GParted method (at least on that device).
Theonew said:
You cannot "fix" it. That is one reason but it also really depends on your device. For example: - This device is able to do it from recovery and it is easier than the GParted method (at least on that device).
Click to expand...
Click to collapse
I think we're mixing up 2 different issues now.
Forget the partitioning method, I'll just use gparted.
But now there's a major issue: I can't make a nandroid+ext backup. I've used adb to copy everything from my current ext partition and can load it onto the new card's partition, but that might not be an effective solution -- will it break all the symlinks? I'm trying to figure out whether symlinks ultimately store a path (therefore links won't break because the directory structure is still the same) or an address (which will break the links if I'm just copying + pasting). I'm finding conflicting answers.
So now I'm asking about what this error means (why won't it mount), whether the behaviour I described in the "update" above is normal (no sbin in normal mode, no sd-ext in recovery), and what alternatives I have! (Oh, and also my symlinks Qs) Plenty of people using the same recovery have created nandroid+ext backups without problems, and all the posts I'm finding about the issue relate to older versions of AmonRa.
skittleys said:
I think we're mixing up 2 different issues now.
Forget the partitioning method, I'll just use gparted.
But now there's a major issue: I can't make a nandroid+ext backup. I've used adb to copy everything from my current ext partition and can load it onto the new card's partition, but that might not be an effective solution -- will it break all the symlinks? I'm trying to figure out whether symlinks ultimately store a path (therefore links won't break because the directory structure is still the same) or an address (which will break the links if I'm just copying + pasting). I'm finding conflicting answers.
Click to expand...
Click to collapse
It's quite likely that it will break the symlinks (just like .android_secure issues). Are you able to make a nandroid-only backup?
skittleys said:
So now I'm asking about what this error means (why won't it mount), whether the behaviour I described in the "update" above is normal (no sbin in normal mode, no sd-ext in recovery), and what alternatives I have! (Oh, and also my symlinks Qs) Plenty of people using the same recovery have created nandroid+ext backups without problems, and all the posts I'm finding about the issue relate to older versions of AmonRa.
Click to expand...
Click to collapse
What recovery are you using (include version)? It is a known problem for some recovery not being able to have access to the SD-ext partition (e.g. ClockworkMod Recovery 3.0.0.5 on some if not all devices). So you should be able to access the SD-ext partition in recovery, and you should be able to access sbin normally.
Theonew said:
It's quite likely that it will break the symlinks (just like .android_secure issues). Are you able to make a nandroid-only backup?
Click to expand...
Click to collapse
Yes, I can do a nandroid backup of the internal partitions. Also not sure what issues you're referring to. I did some research on symlinks and posted on a linux forum and concluded that it shouldn't break....
Theonew said:
What recovery are you using (include version)? It is a known problem for some recovery not being able to have access to the SD-ext partition (e.g. ClockworkMod Recovery 3.0.0.5 on some if not all devices). So you should be able to access the SD-ext partition in recovery, and you should be able to access sbin normally.
Click to expand...
Click to collapse
(I don't have enough posts to insert URLs) I am using Malez recovery 0.6.1 (current is 0.6.2, nothing in the changelog suggests any relevant fixes though). I've searched extensively and it seems that I'm the only malez user having this problem.
Also, I can access sbin, but its only contents are adbd and ueventd. /sd-ext just plain doesn't show up in recovery mode.
Question: who is the owner of your /system, /sd-ext, and /system/sd partitions?
And a possibly unrelated question: what's the point of running a command through busybox (e.g., busybox ls instead of just ls)?
skittleys said:
Yes, I can do a nandroid backup of the internal partitions. Also not sure what issues you're referring to. I did some research on symlinks and posted on a linux forum and concluded that it shouldn't break....
Click to expand...
Click to collapse
It shouldn't break, but on some roms it does.
skittleys said:
Question: who is the owner of your /system, /sd-ext, and /system/sd partitions?
Click to expand...
Click to collapse
What do you mean?
skittleys said:
And a possibly unrelated question: what's the point of running a command through busybox (e.g., busybox ls instead of just ls)?
Click to expand...
Click to collapse
Busybox adds additional commands that the normal android command system does not have/understand on it's own (It gives you additional LINUX/UNIX based commands). See here: http://busybox.net/about.html.
Theonew said:
What do you mean?
Click to expand...
Click to collapse
When you run ls -l the 3rd and 4th columns show the 'owner' and 'group', respectively. It'll say things like root, system, etc., or maybe 0, 1000, 500, etc.
Theonew said:
Busybox adds additional commands that the normal android command system does not have/understand on it's own (It gives you additional LINUX/UNIX based commands). See here: http://busybox.net/about.html.
Click to expand...
Click to collapse
So there's no point in running a command like ls through busybox, right?
New question:
All that /system/sd contains is a 0-byte file called 'placeholder'. I can't find much info about this, but it sounds like this is intentional. But I know that this is where the ext partition is supposed to mount to. Does yours look like this (in either normal mode or recovery)? (edit: in recovery mode, the placeholder is gone, replaced with another 0-byte file called 'empty')
Also, do you think you could paste the output of mount when run in recovery?
BTW, A2SD seems to work perfectly otherwise. The only oddity I've noticed is that when I run a2sd forcecheck near the end it tries to unmount the partiton and can't.
Code:
[ ] Launching Apps2SD Start Program with forcecheck
[ ] Starting Darktremor Apps2SD in forcecheck mode
[ ] Creating Force Check Flag File...
[ ] Unmounting /dev/block/mmcblk0p2...
umount: can't umount /sd-ext: Device or resource busy
[ ] Rebooting phone...
Ironic that I can't mount it in recovery yet I can't unmount it normally!
Well, I was screwing around and TWRP crashed while I was copying files to /system so needless to say it doesn't boot, however I can get in to the bootloader and recovery, so I was hoping if someone could maybe dd their (preferrably stock but rooted/busybox/etc should be fine as long as there weren't any more extensive mods done.) /system partition at /dev/block/mmcblk0p32 to their SD storage and upload it, so I can dd a working /system in myself from adb shell. Not sure if that'll work but it's worth a try.
The command should be something along the lines of:
dd if=/dev/block/mmcblk0p32 of=/sdcard/system.img
You'll need about 2GB of storage, but it should 7zip down to a few 100MB.
This is a read-only operation. There should be no danger to your phone (however a crash might corrupt your SD storage so maybe do a backup of that if you want to be safe.).
Help would be appreciated.
Also, do this from recovery with the filesystem NOT mounted after a clean shut down.
You can also run ADB sideload in TWRP and push the zip over and have it flash, that's what I had to do. :good:
Sent from my HTC6435LVW using xda app-developers app
I got it working. I don't trust TWRP. It seems to fail on simple things for me or something just locking up completely, so I just followed the updater-script in the FactoryROM installer zip and did it by hand through ADB and all is well now. Phone boots and I even get the recent button to be a menu button.
It would be nice if there was a clean, unmodded /system dump somewhere, though. The RUU is pretty useless for people on mac/linux.
So here you come. To read and perform this tutorial, you obviously need a first hand experience on flashing a ROM and/or kernels. Otherwise this tutorial and my efforts to get you a device with two OSes running might end up giving you a bricked device. So, if you're hearing the terms "flashing" or 'kernels' for the first time and thinking it's kinda good food, then bro, just go and taste those first.
Something's to remind before we gonna dig deep into this tutorial->
1> Noone but you will be responsible for what you end up with.
2> The warranty of your device will be voided after this if it isn't already after rooting. For MI users, the good news is that you can reclaim it by just flashing the fastboot ROM for your device.
Enough lectures. Bro let's get to work.
This you'll be needing =>
1> One working Windows PC(because I doesn't know any replacement of bootimg.exe on any other OS. If you know, then let me).
2> A class 10 memory card ( I recommend 32GB for the spaces)
3> A custom ROM and kernel for your phone(the second os)
4> Any custom CWM based recovery installed.(since TWRP is most popular, I will demonstrate using it. You can use any other you want overall process will be the same)
5> ADB, fastboot and the device drivers (easily found in XDA)
PART 1: MODIFYING THE BOOT
At first, how does your device boots up? What are the partitions called /data and /system? The answer is quite simple. It's your kernel that points out the location from where the OS should be picked up. So for booting into the second OS we need some modifications to it at first.
Search and download bootimg.exe on XDA, I'll post a link later. Create two folders. Name them "Internal OS" and "External OS" respectively. Put the zip file of the OS you're currently using to the first one and the OS you're gonna use on the external storage to the second one. Rename the second OS to originalExternalOS.zip. Extract originalExternalOS.zip. Pick the boot.img file from the root of the extracted folder and move it to a new folder named "boot2". Extract the IMG using bootimg.exe. Navigate to the initrd folder and you will get a file named 'fstab".
Basically it's the file that tells the kernel which partition does the OS resides in.
Open the file in your favourite text editor.
Replace every instance of the first line with the second one:
/dev/block/bootdevice/by-name/system => /dev/block/mmcblk1p2
/dev/block/bootdevice/by-name/userdata => /dev/block/mmcblk1p3
/dev/block/bootdevice/by-name/cache => /dev/block/mmcblk1p4
Save the file without giving any extension to it. Repack it using the same tool. You'll have boot-new.img and boot-old.img. Rename boot-new.img to boot.img and replace the one in the root folder with this. Basically what we're doing here is replacing the old boot.img with the modified one.
For your knowledge, blocks are the partitions of any storage you have on your device. For example, your internal storage is partitioned to near about 30 different blocks each starting with prefix "mmcblk0p". We here just told the kernel to load the OS from the blocks mentioned. We'll be creating these blocks in the external SD card next.
PART 2: PARTITIONING THE SD CARD
Connect your device with the memory card inserted to your PC. If you haven't installed fastboot, ADB, and the drivers, do it now.
READ THE FOLLOWING CAREFULLY
Reboot the device to recovery mode. Type the commands in cmd:
Code:
adb shell
parted
unit MB
print
quit
umount external_sd
Read and store the minimum and maximum capacity of your card. Since different cards will have different capacities I will point it as variable MIN_SIZE and MAX_SIZE. You'll need to calculate and put the values in the commands. Now type the following commands on cmd:
Code:
parted /dev/block/mmcblk1
rm 1
//START_BLOCK = MAX_SIZE - 5000
mkpartfs primary fat32 MIN_SIZE START_BLOCK
//SYS_START = START_BLOCK+1
//SYS_END = SYS_START + 1200
mkpartfs primary ext2 SYS_START SYS_END
//DATA_START = SYS_END+1
//DATA_END = DATA_START + 3500
mkpartfs primary ext2 DATA_START DATA_END
//CACHE_START = DATA_END + 1
mkpartfs primary ext2 CACHE_START MAX_SIZE
//We have partitioned the memory card. Let's format them. Ignore all "Do you wish to continue" question in the next commands as we're already mentioning yes.
mkfs yes 1 fat32
mkfs yes 2 ext2
mkfs yes 3 ext2
mkfs yes 4 ext2
quit
//Now they are almost ready. Just make the newly created blocks readable by the OS.
make_ext4fs /dev/block/mmcblk1p2
make_ext4fs /dev/block/mmcblk1p3
make_ext4fs /dev/block/mmcblk1p4
//Now you get where does the blocks come in the kernel right?
exit
//You've covered up the hardest part. Let's get some coffee and cheeerssss.
PART 3: MODIFYING THE NEW OS
You've left the OS extracted in the "External OS" folder right? It's time to do some magic in it. We're gonna tell the OS to be installed in the blocks we created just like the kernel. But wait, where does the OS know before installing where it should get installed? Well, the answer hides in the updater-script in the folder META-INF > com > google > android. Navigate yourself in it. Open the updater-script file in your favourite editor ( I use notepad++ ) and modify it in the same way as the kernel.
Replace every instance of the first line with the second one:
/dev/block/bootdevice/by-name/system => /dev/block/mmcblk1p2
/dev/block/bootdevice/by-name/userdata => /dev/block/mmcblk1p3
Leave the /dev/block/bootdevice/by-name/boot as it's the fundamental block and we can't replicate it. Don't think for the /cache partition as we've already done that in the boot.img file. Now navigate to the root of the folder where you extracted the External OS. Select all files, add them to a zip file using WinRAR. Name the file to newOS.zip. Open newOs.zip and originalExternalOS.zip with WinRAR and compare them if you find any change in the folder tree. They must and they should be exactly the same. You're 80% done.
PART 4: MODIFYING THE RECOVERY
We often flash many zips including very popular Xposed and other mods to our OS right? They also look for the /system partition. So what are we gonna do? Modifying each of them? Nah. Let's modify where they get which one the /system is. The recovery. Extract the img of the recovery you're using with the same bootimg.exe. Modify exactly the same things. I.e.
Replace every instance of the first line with the second one:
/dev/block/bootdevice/by-name/system => /dev/block/mmcblk1p2
/dev/block/bootdevice/by-name/userdata => /dev/block/mmcblk1p3
/dev/block/bootdevice/by-name/cache => /dev/block/mmcblk1p4
in the following files : initrd/fstab.qcom
initrd/etc/recovery.fstab
initrd/etc/twrp.fstab(For TWRP only)
Save them. Repack. And you got your recovery-new.img and recovery-old.img. Put recovery-new.img and newOS.zip in the same folder. Now wake up, it's time for some action.
PART 5 : INSTALLING THE OS
Open cmd in the folder where newOS.zip resides. Reboot the devixe in fastboot mode. Type the following commands:
Code:
adb push newOS.zip external_sd
fastboot flash recovery recovery-new.img
fastboot boot recovery
Now your device should boot up in recovery mode. To check if everything has gone fine mount system using TWRP. Use twrp's built in file manager and navigate to system folder. It's empty? Yup. You've done a great job. Now flash the newOS.zip using TWRP and your device should boot up in the new OS. To cross check again remove the SD card and try to boot. If you're headed towards recovery or bootloop after that then it's a win. Put the SD card back again and watch the new OS to boot.
PART 6: SWITCHING BETWEEN THE TWO
Extract the boot.img from the "Internal OS" zip file and put it together with recovery-old.img. To check if your old system is untouched type the following commands in fastboot mode:
Code:
fastboot flash recovery recovery-old.img
fastboot flash boot boot.img
fastboot boot system
Your device should take you back to the old one. Surprised? Now let's make a switch between the two. There are two methods.
METHOD 1: USING FLASHIFY
Create two folders in your SD card. Put boot.img and recovery-old.img to one and boot-new.img and recovery-new.img to the other. To switch to the external OS, just flash boot-new.img as boot and recovery-new.img using flashify. Ignore reboot now dialog and reboot directly to the system. To go back, first install flashify in the new OS and flash boot.img and recovery-old.img. Easy right?
METHOD 2: USING ZIPS
I'm gonna tell you that tomorrow as I can write no more today.
More to come....
CREDITS:
justzzshadz from MIUI forum for this revolutionary concept. @iamsubhranil for adding TWRP support and rewriting the tutorial.
Unnecessary
Continuation2
........
reserved
For future posts.
reserved
For future posts
"External" is spelled wrong in the title.
God of War™ said:
"External" is spelled wrong in the title.
Click to expand...
Click to collapse
If you read the whole tutorial, then that just doesn't matter
God of War™ said:
"External" is spelled wrong in the title.
Click to expand...
Click to collapse
Have you tried it?
bootimg.exe
"bootimg.exe on any other OS. If you know, then let me)."
please, send bootimg.exe
tim241 said:
Thanks!!
Click to expand...
Click to collapse
Why you quoted the whole post only to say thanks? That thank you button under the post isn't enough?
tim241 said:
Thanks!!
Click to expand...
Click to collapse
Tried?
fstab not found there is a file named fstab.qcom??????
keerten said:
fstab not found there is a file named fstab.qcom??????
Click to expand...
Click to collapse
Try MultiROM man
iamsubhranil said:
Try MultiROM man
Click to expand...
Click to collapse
Ok Bro
iamsubhranil said:
Try MultiROM man
Click to expand...
Click to collapse
Bro, you are working on EFIDROID. Can you give us update that project
abhianand123 said:
Bro, you are working on EFIDROID. Can you give us update that project
Click to expand...
Click to collapse
I've already told it to some people. The project is currently stun for some complications. Will resume.
Pretty useful. Thanks a lot.
Am I right, that when the memory chip on the motheboard holding /system and /userdata partitions died, I can boot the phone from sdcard using this method? I have HM2014813 variant of Redmi 2.
EDIT: I tried this method but I need to use fastboot boot modified.img to boot my phone. Any ideas how to avoid this step?
tulen_kobi said:
Am I right, that when the memory chip on the motheboard holding /system and /userdata partitions died, I can boot the phone from sdcard using this method? I have HM2014813 variant of Redmi 2.
EDIT: I tried this method but I need to use fastboot boot modified.img to boot my phone. Any ideas how to avoid this step?
Click to expand...
Click to collapse
I too have same problem 0 mb internal stoarage
/sbin/sh: parted: not found
---------- Post added at 03:49 PM ---------- Previous post was at 03:43 PM ----------
warrenlobo said:
I too have same problem 0 mb internal stoarage
/sbin/sh: parted: not found
Click to expand...
Click to collapse
they are missing i guess
warrenlobo said:
I too have same problem 0 mb internal stoarage
/sbin/sh: parted: not found
---------- Post added at 03:49 PM ---------- Previous post was at 03:43 PM ----------
they are missing i guess
Click to expand...
Click to collapse
There is no parted on the device anymore, you need to preparation your sdcard on your computer. Do you use Windows or Linux on your pc?
If Windows try to use: FWUL to partition your sdcard.