[ROM] B&N 1.4.1 upgrade through CWM [Dual Boot/Single Boot Compatible] - Nook Color Android Development

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).

Related

Honeycomb on eMMC (updated download file to the correct one)

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.

[ROM] Flashable eMMC dual boot ROMs (Froyo, Honeycomb, Eclair, CM7)

I've created a few flashable zip files to ease the eMMC dual boot setup. You can flash them using Clock Work Recovery.
Warning: Only specially packaged flashable dual boot ROMs like the ones I packaged below will flash to dual boot partition. Other flashable zips will overwrite your default boot.
Seems there is a problem flashing the zips from CWM on SD. See this post for a workaround, or use CWM on eMMC.
Just a word on booting into recovery. With the dual boot u-boot.bin, I have changed the button combo to VOL UP + VOL DOWN for recovery. So if you want to go to recovery, remember this is the key combo you need to hit. Not Power + n.
1. Prepare dual boot - http://dl.dropbox.com/u/20480343/prep-dualboot-0.1.zip
Flash this zip file will setup the dual boot partitions. If your NC is already setup using my previous dual boot script, there is no need to flash this again.
Note 1 - This does a resize of your /media partition. You data on /media should be intact. If you want to be safe, backup your /media before flashing.
Note 2 - /media partition will be resized to about 3.9 GB. If your existing data on /media is more that 3.9GB, you won't be able to flash this.
2. Remove dual boot - http://dl.dropbox.com/u/20480343/remove-dualboot-0.1.zip
If you want to revert to stock, simply flash this file.
3. Dual boot ROMs
Now the dual boot ROMs. These will be flashed to the dual boot partitions (partition 9 and 10) on eMMC. Hold 'n' button while powering up to boot into dual boot ROM.
My modified u-boot.bin based on B&N 1.2 source - Seems previous version is having compatibility issues with 2.6.32 kernel. This is updated base on B&N 1.2 source. Flash using CWM. It only overwrites the u-boot.bin on boot partition. Boot message should show "(multi)U-Boot v0.3 loading..." after flashing this zip.
Flashable dual boot Nookie Froyo v0.6.8
Flashable dual boot Honeycomb Preview v04
Flashable dual boot HC v04 with gapps - credit goes to pauljohnson75
Flashable dalingrin's 1.1GHz OC kernel for dual boot HC - credit goes to dalingrin for the oc kernel, and pauljohnson75 for creating the dual boot flashable
Flashable zip to move your stock Eclair to dual boot partition v02 - This is not really a ROM strictly speaking. To avoid infringing B&N IP, no file from stock ROM is included in this zip. Scripts in this zip simply copies your stock ROM partitions and make the necessary adjustment to ramdisk. After flashing this, you will have an identical ROM setup on your dual boot partition. You are free to do whatever to your default ROM. For example, you can flash other ROMs to overwrite your default ROM. You will still be able to boot into stock eclair by holding 'n' button. Only thing to note is if the other ROMs you flash overwrites u-boot.bin, you will lose the dual boot capability.
Flashable dual boot CM7 nightly (cm_encore_full-22)
Note 1 - You can flash this using CWM 3.0.0.5. Newer version of CWM not required.
Note 2 - This will convert secondary /system and /data partitions to ext4. They will not be compatible with other dual boot ROMs any more. You need to flash remove-dualboot-0.1.zip, then prep-dualboot-0.1.zip, before flashing other dual boot ROMs.
Note 3 - This will wipe your dualboot data partition.
Link not longer working
unknown.soul has packaged dalingrin's OC kernels for dual boot. Get them below. thanks unknown.soul
Eclair
Froyo
CM7
Honeycomb
Also gapps
Google Apps
Credits
cicada for Nookie Froyo. My update scripts are also based on his NF flashable.
deeper-blue for Honeycomb.
cm7 dev team for porting CM7 to NC
other xda developers who have contributed to NC community.
Holy Crap! How am I supposed to get any REAL work done today?
This is crazy awesome. I'm downloading everything right now. i will let you know how it goes.
Thank you!!!
Wow, this makes dual booting so much easier! thanks man!!
For real though, I have a deadline today and you come along and release this! You sir are awesome!!! Gonna flash it right now and then hopefully I can get some work done.
I see CM7 was just released. Would I be able to flash this to my dual boot partition?
racks11479 said:
For real though, I have a deadline today and you come along and release this! You sir are awesome!!! Gonna flash it right now and then hopefully I can get some work done.
I see CM7 was just released. Would I be able to flash this to my dual boot partition?
Click to expand...
Click to collapse
Normal flashables will flash to default partitions. That will overwrite your default boot OS. I have to package these flashable zips specifically to flash to dual boot partition. They are not compatible.
rookie1 said:
Normal flashables will flash to default partitions. That will overwrite your default boot OS. I have to package these flashable zips specifically to flash to dual boot partition. They are not compatible.
Click to expand...
Click to collapse
Yeah, I'd figured as much.... was hoping and wishing that under some miracle way it would have been possible. Thank you again for your hard work on this. It's pretty much made my day.
This is awesome downloading now. Are these just the base Roms or do they include any of the Google apps?
No gapps included.
get it here http://forum.xda-developers.com/showthread.php?t=917660
Is it possible to overclock this? If so, how?
racks11479 said:
No gapps included.
get it here http://forum.xda-developers.com/showthread.php?t=917660
Is it possible to overclock this? If so, how?
Click to expand...
Click to collapse
how does one push gapps and oc kernel in context of dual bootsetup?
rookie1 said:
I've created a few flashable zip files to ease the eMMC dual boot setup. You can flash them using Clock Work Recovery.
Click to expand...
Click to collapse
If I want to use this but keep oc 1100 for both froyo and eclair how do i do that. also if I want to install gapps on the froyo part of dual boot what mount commands do i need to push it to right place in adb?
Canadoc said:
If I want to use this but keep oc 1100 for both froyo and eclair how do i do that. also if I want to install gapps on the froyo part of dual boot what mount commands do i need to push it to right place in adb?
Click to expand...
Click to collapse
Not sure about the overclocking. I would really like to know how as well.
But with gapps. I didn't use adb. I just placed the unzipped gapps folder on my sdcard and installed it through terminal emulator in dev tools on my nook.
su
mount -o remount,rw /system
cp -r /sdcard/gapps/system/* /system
exit
Thats about it!
racks11479 said:
Not sure about the overclocking. I would really like to know how as well.
But with gapps. I didn't use adb. I just placed the unzipped gapps folder on my sdcard and installed it through terminal emulator in dev tools on my nook.
su
mount -o remount,rw /system
cp -r /sdcard/gapps/system/* /system
exit
Thats about it!
Click to expand...
Click to collapse
thanks will try this
what type of quadrant scores u getting on 800?
Just ran a quadrant of 969.
racks11479 said:
Not sure about the overclocking. I would really like to know how as well.
But with gapps. I didn't use adb. I just placed the unzipped gapps folder on my sdcard and installed it through terminal emulator in dev tools on my nook.
su
mount -o remount,rw /system
cp -r /sdcard/gapps/system/* /system
exit
Thats about it!
Click to expand...
Click to collapse
Can we access sdcard from either booted rom?
I flashed the NF one, and yes I'm able to mount and access my sdcard
Did anyone have any problems installing? I followed the instructions and I can get Nook Honey to boot but Nookie Froyo gets stuck at the Android_ screen, before the OS actually starts loading. I've tried reverting back to stock and starting over, and still no luck. Any suggestions would be greatly appreciated.
Awesome
Not sure how I did this but I didn't do a wipe or any formats before I installed all three zips. I installed all three at once from inside clockwork. Anyway my nookie froyo that I had setup perfect is still there just like I left it inculding the overclocked kernel. And if I hold down the n key and boot it boots right into Honeycomb not sure how I did this but its awesome. Thanks rookie1, now I just need to get gapps onto Honeycomb.
For oc kernels remember the file name is uFImg for the second boot. For those of you pushing an OC kernel to the alternate boot.
pauljohnson75 said:
Not sure how I did this but I didn't do a wipe or any formats before I installed all three zips. I installed all three at once from inside clockwork. Anyway my nookie froyo that I had setup perfect is still there just like I left it inculding the overclocked kernel. And if I hold down the n key and boot it boots right into Honeycomb not sure how I did this but its awesome. Thanks rookie1, now I just need to get gapps onto Honeycomb.
Click to expand...
Click to collapse
Why did you flash all 3 zips? You can only install one ROM on the new partition. I believe that this doesn't touch your original setup at all. It only flashes the rom on the new partition that was created.
Ok if someone can please help.
I have dual boot set up with eclair as stock boot and my n boot gives me froyo.
used titanium backup and have my froyo mostly back up and running though some apps caused soft reboots during the reinstall from TB.
Froyo seems to be running fine with what is installed so far. Flash is workig but since only getting quadrants in the 900-960 range it is kinda choppy. Was hoping there was a way to get the oc kernel onto the froyo boot as it is still present on the original eclair boot. The only real advantage for me of Froyo is that it should be faster and flash. But since it is not overclocked.....
Any ideas how to get the froyo oc kernel to the right place?

stock sw overwriting /system/bin?

I'm noticing that changes I make to /system/bin get undone upon reboot on stock 5589 software.
My particular change is the wpa_supplicant ad hoc fix.
I used terminal to rename the old file to wpa_supplicant.back and put my new file in.
It works fine, I can connect to ad-hoc wifi fine, until I reboot. After reboot, the backup is gone, and the old file is back to it's original spot (breaking wifi).
I'm using temporary root under z4root if that makes a difference.
Anyone have any ideas, is there some type of "system restore" functionality in 5589 that refreshes system/bin upon startup?
Any workarounds if I want to remain on stock?
ml_boston said:
I used terminal to rename the old file to wpa_supplicant.back and put my new file in.
Click to expand...
Click to collapse
You shouldn't replace binaries while they're being used. Install CWM and use it to do the switch. Make sure you remount /system read-only afterwards.
The file wasn't in use, as I was able to run adhoc wifi (meaning the replace worked) until I rebooted.
I think I found the problem, from this link:
There is also another important file you should know about. In /system/recovery.img there is a full copy of everything that is loaded on mtd1. This file is automatically flashed onto mtd1 every time you shut down. That means two things: 1. Any changes you make directly to /dev/mtd/mtd1 get blown away on reboot and 2. If you want to change /dev/mtd/mtd1 you're probably better off just sticking the image in /system/recovery.img and rebooting. When creating your own custom update.zip files (especially when adapting the stock images), you can get tripped up if you forget to replace /system/recovery.img and it ends up overwriting /dev/mtd/mtd1 unbeknownst to you. Watch out.
Click to expand...
Click to collapse
So I've got to learn how to build an img file with my one swapped file. Or perhaps (will try soon and post back), deleting the recovery.img file will also do the job.
ml_boston said:
The file wasn't in use, as I was able to run adhoc wifi (meaning the replace worked) until I rebooted.
Click to expand...
Click to collapse
Unless the wifi was switched off or put into airplane mode or something like that as the default state, I assure you that the wpa_supplicant binary would've been in use. It's how modern Unixes work.
I think I found the problem, from this link:
Click to expand...
Click to collapse
Most of the specific details in that link a) either isn't relevant to your specific problem and/or b) does not apply to the gTab and the ROMs that run on it. For example, in the quote you pulled:
There is also another important file you should know about. In /system/recovery.img there is a full copy of everything that is loaded on mtd1. This file is automatically flashed onto mtd1 every time you shut down. That means two things: 1. Any changes you make directly to /dev/mtd/mtd1 get blown away on reboot and 2. If you want to change /dev/mtd/mtd1 you're probably better off just sticking the image in /system/recovery.img and rebooting. When creating your own custom update.zip files (especially when adapting the stock images), you can get tripped up if you forget to replace /system/recovery.img and it ends up overwriting /dev/mtd/mtd1 unbeknownst to you. Watch out.
Click to expand...
Click to collapse
Here,
1. There is no /system/recovery.img file on the stock ROM.
2. The quote talks about restoring "recovery"--not "system". Plus, those 2 partitions have radically different sizes (16 MB max for "recovery" and 200MB max for stock "system"). Think about what would happen to the boot times if a 200MB image had to be restored on every boot.
So, my advice is unchanged. Install CWM temporarily, then use it to switch the binary, and finally, sync and unmount /system before rebooting out of CWM. You can always restore the stock recovery using the recovery.img file in the 5699 update zip file from within CWM.

[EXPLOIT] Modify System Files w/o Flashing Boot Partition

Exploit: Modify System Files w/o Flashing Boot Partition​
Background
One of the serious inconveniences of the stock Nook Tablet firmware is the inability to copy & paste in text fields. I hacked together a solution (see this thread) that requires replacing the file /system/framework/framework.jar. However, when I did replaced that file, my tablet no longer boots.
It turns out that there are two files in the ramdisk that specify (what I assume to be) checksums of system files: /manifest00 and /manifest01. B&N has added a "feature" to the /init process that checks if system files on disk match the checksums in /manifest00 and /manifest01, and will crash the system if it finds a discrepancy, resulting in a boot loop.
/manifest00 and /manifest01 cover essentially all of the system files that one would be interested to modify, including my /system/framework/framework.jar. It is possible to get around this by using a ramdisk that has an empty /manifest00 and /manifest01, because /init only checks files with a checksum listed in /manifest00 and /manifest01, and will happily ignore everything else. But this would require me to flash a new boot partition, and since the NT has a locked bootloader, I would have to use bauwks's 2nduboot or Cyanoboot.
In essence, B & N is quite clever:
1. To modify system files (/system), you need to modify the boot partition (/manifest00 and /manifest01).
2. To modify the boot partition, you need to modify the boot loader.
3. The bootloader is locked.
Of course, with bauwks's 2nduboot hack, 3 is no longer an obstacle, but I would still rather not flash and damage my boot partition, having almost bricked my tablet once by doing so.
Exploit
I studied the /manifest00 and /manifest01 in the 1.4.2 ROM on my NT 8GB and compared them with /init.rc and /init.omap4430.rc, and discovered that /init.omap4430.rc starts /system/bin/uim-sysfs with root permissions at boot, but /system/bin/uim-sysfs does not actually exist. In addition, /system/bin/uim-sysfs is not in /manifest00 or /manifest01, and is thus not verified by /init.
Upon further testing, /system/bin/uim-sysfs is run after /init checks the checksums of system files, which means that /system/bin/uim-sysfs can modify /system as it wishes, with the caveat that it must restore its modifications before a reboot lest /init catches it at it.
So I placed a shell script at /system/bin/uim-sysfs that replaces /system/framework/framework.jar with my custom build, restarts the zygote process, and restores the stock /system/framework/framework.jar. I'm now able to use copy & paste on my Nook Tablet
If anyone's interested, you can check out the uim-sysfs script I'm using for the copy & paste hack in the linked file in this thread.
Interesting and very useful for stock users. Well done!
~ Veronica
Stop it, BN. Stop it.
/init.omap4430.rc starts /system/bin/uim-sysfs with root permissions at boot, but /system/bin/uim-sysfs does not actually exist!
Click to expand...
Click to collapse
Interesting find. What is BN thinking with this manifest checking stuff. BN, just stop it. Seriously. Stop it.
Stop it, BN.
FWIW, uim-sysfs is the no-longer-used userspace side of the "shared transport" wireless daemon stuff (the other side is called "kim" in the kernel) that's used for bluetooth, FM, and gps on the 1271... it's used in CM7/CM9 (backported from 2.6.35 to 2.6.32) for nookcolor to make bluetooth work.
BN likely just modified TI's stock init.omap3.rc and left lines like the uim service as-is. Running this non-existent file as root is kinda a "security" hole, IMO, assuming the manifest verification was supposed to be some kind of security. Remove this, there will doubtlessly be other examples of the same thing.
All that said, is this script, which is replacing system files on-the-fly any more "safe" than just replacing the boot partition in the first place? Add CyanoBoot, shift current boot.img contents 512 bytes. Done.
Nice discovery tho.
fattire said:
All that said, is this script, which is replacing system files on-the-fly any more "safe" than just replacing the boot partition in the first place? Add CyanoBoot, shift current boot.img contents 512 bytes. Done.
Click to expand...
Click to collapse
Well, the only real difference for me is what happens when you screw something up. When I screwed up /system, I could always use the "8 failed reboots" method to go back to stock /system. When I screwed up my boot partition, I almost bricked my tablet and there was no way of getting back to the factory restore interface.
In addition, it's also really, really easy for development because we'd be working with simple files, not images. For my copy & paste hack, I was editing /system/bin/uim-sysfs directly on the tablet using a text editor. Boot images are much harder to work with.
The last advantage is that it's a lot less intrusive. There's no scary flashing going on here; just drop a file in /system/bin/ and you're set.
care to share the files?
jichuan89 said:
Exploit: Modify System Files w/o Flashing Boot Partition​
Background
One of the serious inconveniences of the stock Nook Tablet firmware is the inability to copy & paste in text fields. I hacked together a solution (will post details later) that requires replacing the file /system/framework/framework.jar. However, when I did replaced that file, my tablet no longer boots.
It turns out that there are two files in the ramdisk that specify (what I assume to be) checksums of system files: /manifest00 and /manifest01. B&N has added a "feature" to the /init process that checks if system files on disk match the checksums in /manifest00 and /manifest01, and will crash the system if it finds a discrepancy, resulting in a boot loop.
/manifest00 and /manifest01 cover essentially all of the system files that one would be interested to modify, including my /system/framework/framework.jar. It is possible to get around this by using a ramdisk that has an empty /manifest00 and /manifest01, because /init only checks files with a checksum listed in /manifest00 and /manifest01, and will happily ignore everything else. But this would require me to flash a new boot partition, and since the NT has a locked bootloader, I would have to use bauwks's 2nduboot or Cyanoboot.
In essence, B & N is quite clever:
1. To modify system files (/system), you need to modify the boot partition (/manifest00 and /manifest01).
2. To modify the boot partition, you need to modify the boot loader.
3. The bootloader is locked.
Of course, with bauwks's 2nduboot hack, 3 is no longer an obstacle, but I would still rather not flash and damage my boot partition.
Exploit
I studied the /manifest00 and /manifest01 in the 1.4.2 ROM on my NT 8GB and compared them with /init.rc and /init.omap4430.rc, and discovered that /init.omap4430.rc starts /system/bin/uim-sysfs with root permissions at boot, but /system/bin/uim-sysfs does not actually exist. In addition, /system/bin/uim-sysfs is not in /manifest00 or /manifest01, and is thus not verified by /init.
Upon further testing, /system/bin/uim-sysfs is run after /init checks the checksums of system files, which means that /system/bin/uim-sysfs can modify /system as it wishes, with the caveat that it must restore its modifications before a reboot lest /init catches it at it.
So I placed a shell script at /system/bin/uim-sysfs that replaces /system/framework/framework.jar with my custom build, restarts the zygote process, and restores the stock /system/framework/framework.jar. I'm now able to use copy & paste on my Nook Tablet
Click to expand...
Click to collapse
would be nice if you can share some files
MikeCh said:
would be nice if you can share some files
Click to expand...
Click to collapse
If you're interested in copy & paste, I've now posted instructions at http://forum.xda-developers.com/showthread.php?t=1534757
jichuan89 said:
Well, the only real difference for me is what happens when you screw something up. When I screwed up /system, I could always use the "8 failed reboots" method to go back to stock /system. When I screwed up my boot partition, I almost bricked my tablet and there was no way of getting back to the factory restore interface.
Click to expand...
Click to collapse
Well, "bricking" in the classic sense of creating a permanently damaged system is a bit difficult-- you can always boot from SD card and reflash from CWM, right?
In addition, it's also really, really easy for development because we'd be working with simple files, not images. For my copy & paste hack, I was editing /system/bin/uim-sysfs directly on the tablet using a text editor. Boot images are much harder to work with.
Click to expand...
Click to collapse
do you mean for the developer or end user?
The last advantage is that it's a lot less intrusive. There's no scary flashing going on here; just drop a file in /system/bin/ and you're set.
Click to expand...
Click to collapse
but aren't you still moving framework files around "on the fly"?
Well, in any event it was a good observation that can be used for all kinds of purposes-- rooting, running background processes, etc. You could even drop a cwm recovery binary in there to instantly turn stock into cwm I bet...
fattire said:
Well, "bricking" in the classic sense of creating a permanently damaged system is a bit difficult-- you can always boot from SD card and reflash from CWM, right?
Click to expand...
Click to collapse
True.
fattire said:
do you mean for the developer or end user?
Click to expand...
Click to collapse
I guess that's personal preference more than anything else. Please disregard.
fattire said:
but aren't you still moving framework files around "on the fly"?
Click to expand...
Click to collapse
Yes - but the process is automated by the script in uim-sysfs. From the user's perspective it's just copying a file to /system/bin say using ES File Explorer, rather than burning an image to an SD card and booting from it which appears to scare/confuse a lot of people. Also they wouldn't need a computer or a card reader or a spare SD card or a USB cable or any special software on their computer.

[GUIDE][Lollipop]Dual Boot CM and/or Stock OS

This guide is show you how to install second OS in SDCard, so you can have two complete separate OS (each have their own /system, /data and /cache), this will be useful if you want to try out a new ROM or a new version, like CM or latest Stock build etc. I have pre-build 2 ROMs in this guide. and list the instructions of how to do it in post #2.
The whole method is just an implementation of @SHM (Modding.MyMind) guide that inside the post here, so all the credit goes to him:
http://forum.xda-developers.com/showpost.php?p=62460895&postcount=325
Highlight of the steps:
1. Partition a SDCard (32GB or bigger) to have 3 ext4 partitions after regular FAT32 partition
2. Flash two customized flashable zip in twrp so that:
boot image flashed to /dev/block/mmcblk0p18 (regular boot partition)
system image flashed to /dev/block/mmcblk1p2 (sdcard)
The boot image contains the fstab file, it has been updated to use partitions on sdcard as the /system, /data and /cache for the 2nd OS.
And of course, the flashable zip has updater script changed so that, it will flash they system image to correct partition on SDCard.
Note / Limitation:
1) After boot to 2nd OS on the SDCard, theoretically, while you are in Android OS, everything should work. The speed/performance may differ depends on the SDCard read/write speed.
2) TWRP, except flash the zip to install the customized system image to SDCard, all other function will not work for the 2nd OS, The backup/restore function is still working on the primary OS /system, /data etc.
3) Boot partition (/dev/block/mmcblk0p18), this partition will decide which OS it will boot, and the boot image should corresponded to your OS system partition. So if you flashed above boot image for 2nd OS, it will find /system on SDCard and boot it. And if you flashed (or restore) your primary OS boot image, then it will boot to your primary OS /system.
Things you need before you start:
1. MT2L03 with Lollipop installed, TWRP installed, and have a backup of your primary OS (at least /system, and /boot partitions)
2. An empty SDCard that is 32GB or bigger, strongly recommend class 10 or faster. (16GB will work, then you don't have much external space left)
Steps to install 2nd OS to sdcard:
(Note, I will call the empty SDCard as sdcard#2, and your current sdcard in the phone as sdcard#1.)
1. Make a backup of your current OS using twrp, include at least /system and /boot, to your sdcard#1.
2. Install the PartitionWizard (files location below) on windows, and put the empty SDCard#2 to computer sdcard reader.
3. Launch Partition Wizard, and carefully re-partition your SDCard#2 to following:
(pls refer to xda wiki about the usage: http://forum.xda-developers.com/wiki/SD_card_partitioning )
1st Partition: FAT32 primary size: (Total size minus 15000MB), for example, for 64GB(60000MB) card, choose 45000MB
2nd: ext4 primary size: 1800MB (/system for 2nd OS)
3rd: ext4 primary size: 12500MB (/data for 2nd OS)
4rd: ext4 primary size: rest space, should be great than 200MB (/cache for 2nd OS)
Since partition 2/3/4 total size is 14320MB, thus the 1st partition size is (Total size minus 15000MB)
4. Apply the change, this will take some time (like 20 to 30min).
5. Once sdcard#2 is re-partitioned and formatted, unplug and re-plug sdcard#2 to windows again. Right click the sdcard drive letter, and click "Open" to open the FAT32 partition. ( I found double click the drive letter will give error if the FAT32 is bigger than 32GB, but right click and open works)
Copy two flashable zip (file location below) to the sdcard#2.
6. Reject the sdcard#2, and remove it from windows machine.
7. In Mate2 phone, go to settings, storage, and un-mount your current SDCard#1, after it is unmounted, take out the sdcard#1 and put it to a save place. Do not mess the two sdcards!!
8. Put in the sdcard#2 to the phone, and reboot to TWRP.
9. Install the two zip you download in step 5 from sdcard#2. Reboot.
How to go back to your primary OS:
a. Put in sdcard#1 to the phone, boot into TWRP, restore your /boot partition from the backup you took in above step 1. then reboot.
How to switch to the 2nd OS on the sdcard again:
a. Put in sdcard#2 to the phone, boot into TWRP, flash the "MT2L03_xxx_BootOnly.zip" you downloaded in step 5.
Files to download:
PartitionWizard in above step 2:
http://tinyurl.com/q62m68x
location: under Lollipop/SD_Partition_Tools
FileName: pwfree91.exe
This tools is mentioned in XDA wiki: http://forum.xda-developers.com/wiki/SD_card_partitioning
You can use any tool you know to do the re-partition, above tools is what I used and it works.
Customized flashable in zip in above step 5:
http://tinyurl.com/q62m68x
location: under Lollipop/OS_on_SDCards
FileName:
If you want install B309 as 2nd OS, please download "MT2L03_B309_DBoot_BootOnly.zip" and "MT2L03_B309_DBoot_SystemWithRoot.zip"
If you want install CM12 as 2nd OS, please download "MT2L03_CM12_0820_DBoot_BootOnly.zip" and "MT2L03_CM12_0820_DBoot_SystemWithRoot.zip". (Please note the GApp is already included in the zip)
Attached two screenshot of the partition tool, one for 32GB, one for 64GB. Please note though the pic showing in GB, but when config the size, please use MB to make sure the partition size is accurate and big enough.
//reserved
I am not sure how many people is interested in dual boot, so for now, I have pre-built B309 and CM12 only.
In order to build a customize ROM for installing in SDCard, as detailed in SHM original post, two steps are required:
1) For Mate2, after split the original boot image, and unpack the ramdisk, only need following cmd to update the fstab:
cd ramdisk
sed -i 's/platform\/msm_sdcc.1\/by-name\/system/mmcblk1p2/g' fstab.qcom
sed -i 's/platform\/msm_sdcc.1\/by-name\/userdata/mmcblk1p3/g' fstab.qcom
sed -i 's/platform\/msm_sdcc.1\/by-name\/cache/mmcblk1p4/g' fstab.qcom
Then repack it back to boot2.img. Please note the un/repack boot image tool need support DTB section.
2) Then in the updater script of /META-INF/com/google/android/updater-script, install system.img to /dev/block/mmcblk1p2, and still install the new boot2.img to /dev/block/mmcblk0p18.
@SHM, Unfortunately, many tools mentioned in original post, the Aparted tool, and the android binary mkbootimg etc all have problem running under Lollipop, so for now, I am doing all the ROM modification under linux.
Lol. You just had to do it. Lol awesome work. And you picked up on that fast. Thanks Xordos.
Our divices supposedly only support up to a 64 gb SD card. I wonder if since we would partition the SD if it would accept a 128GB card and see it as two x 64GB's
MikeyLee said:
Our divices supposedly only support up to a 64 gb SD card. I wonder if since we would partition the SD if it would accept a 128GB card and see it as two x 64GB's
Click to expand...
Click to collapse
I think if huawei mention 64gb probably because they didn't have 128gb to test when they release the phone. 128gb has nothing special compare with 64gb card. But I could be wrong since I don't have 128gb.
For general use, no need to partition 128gb card unless you want to do something like this thread.
@xordos, no worries. Many things were broken because of Lollipop using a new linker file that checks if the binary is PIE or not. If it is not PIE or if it's not Statically compiled then it won't work on Lollipop. The linker file can be modified though to ignore this check and thus allow them to work regardless. This too could also resolve some issues with other apps not wanting to work on Lollipop . Modifying the linker file is relatively simple but this is off topic so I shall end it here.
Great work. Knew you would be able to get it done. Cheers!
Sent from my C525c using Tapatalk
SHM said:
@xordos, no worries. Many things were broken because of Lollipop using a new linker file that checks if the binary is PIE or not. If it is not PIE or if it's not Statically compiled then it won't work on Lollipop. The linker file can be modified though to ignore this check and thus allow them to work regardless. This too could also resolve some issues with other apps not wanting to work on Lollipop . Modifying the linker file is relatively simple but this is off topic so I shall end it here.
Great work. Knew you would be able to get it done. Cheers!
Sent from my C525c using Tapatalk
Click to expand...
Click to collapse
yup, exactly PIE problem.
So this is pretty cool that no need to worry about /data mixed up by different rom. but open the back cover is a little bit pain and my main sdcard is almost full so I am thinking to use otg cable. So i am wondering if we have grub-like boot image to have boot menu, or, the root is not ramdisk, but a file system, so we can modify the fstab after mount it. I know, maybe I ask too much, android is not design like linux.
xordos said:
yup, exactly PIE problem.
So this is pretty cool that no need to worry about /data mixed up by different rom. but open the back cover is a little bit pain and my main sdcard is almost full so I am thinking to use otg cable. So i am wondering if we have grub-like boot image to have boot menu, or, the root is not ramdisk, but a file system, so we can modify the fstab after mount it. I know, maybe I ask too much, android is not design like linux.
Click to expand...
Click to collapse
Yea, it's pretty nice. You can even modify the TWRP recovery for use with making backups and restoring to each Rom specific to their partition. Look at TWRP Unified and check out it's script inside the ramdisk. Modify the script to check some stuff and tell it which fstab to use . This way when you jump back and forth between roms just by the boot.img you flash TWRP will automatically recognize the change upon it booting up and target the partitions properly when you make a backup/restore. Put some thought into all of this and I am sure you could take this thread a bit further.
There are projects out there that are designed for multibooting on android devices but you would need to port one of them.
Sent from my C525c using Tapatalk
Just an update that the AParted app works for Lollipop now. Tested it out on my external sd tonight by resizing my fat partition without losing any of my contents and adding additional partitions with multiple filesystem's such as f2fs and ext4. Quick and effective .
Sent from my Ascend Mate 2 using Tapatalk
I have a HUGE GIFT that I am about to share for all you mate2 fans out there. Dual Booting just got taken to another level. Think of it as Multi Booting . Here are two screenshots to share as teasers. I have it working for our device and its a beast!
Sent from my Ascend Mate 2 using Tapatalk
SHM said:
I have a HUGE GIFT that I am about to share for all you mate2 fans out there. Dual Booting just got taken to another level. Think of it as Multi Booting . Here are two screenshots to share as teasers. I have it working for our device and its a beast!
Sent from my Ascend Mate 2 using Tapatalk
Click to expand...
Click to collapse
Can't waiting.
MT2-User said:
Can't waiting.
Click to expand...
Click to collapse
More teasers. These pics show that its possible to install roms without the need for TWRP. Will be sharing this very soon. I'm running CM, PAC, and Carbon right now.
Sent from my Ascend Mate 2 using Tapatalk
SHM said:
More teasers. These pics show that its possible to install roms without the need for TWRP. Will be sharing this very soon. I'm running CM, PAC, and Carbon right now.
Sent from my Ascend Mate 2 using Tapatalk
Click to expand...
Click to collapse
You run all three (or four including stock one)?
MT2-User said:
You run all three (or four including stock one)?
Click to expand...
Click to collapse
Yes. I can install the roms using either the system, data, and/or cache partition however I don't recommend cache because it's size is way too small for our device. Can even choose to install them on your external sd. I can install and run as many roms as I like as long as I have space for the new ROM. The app even makes it possible to install new builds to the proper ROM without touching your primary ROM or any other ROM other than what its told to target. More info will be shared when I open a thread on it. In short, you just download the ROM, then patch the ROM.zip using the app. You then flash that patched zip which in turns will modify the boot.img to give it dualboot support. You can patch zips for SuperSU, gapps and so forth so you may install them to a specific ROM. Its legit bro.
Sent from my Ascend Mate 2 using Tapatalk
SHM said:
Yes. I can install the roms using either the system, data, and/or cache partition however I don't recommend cache because it's size is way too small for our device. Can even choose to install them on your external sd. I can install and run as many roms as I like as long as I have space for the new ROM. The app even makes it possible to install new builds to the proper ROM without touching your primary ROM or any other ROM other than what its told to target. More info will be shared when I open a thread on it. In short, you just download the ROM, then patch the ROM.zip using the app. You then flash that patched zip which in turns will modify the boot.img to give it dualboot support. You can patch zips for SuperSU, gapps and so forth so you may install them to a specific ROM. Its legit bro.
Sent from my Ascend Mate 2 using Tapatalk
Click to expand...
Click to collapse
Could they or some of them share Data?
MT2-User said:
Could they or some of them share Data?
Click to expand...
Click to collapse
Not at the moment. You would have to reinstall your user apps again. You can backup your apps on your primary rom using something like Titanium backup and then restore them on the other ROM.
Sent from my Ascend Mate 2 using Tapatalk
SHM said:
Not at the moment. You would have to reinstall your user apps again. You can backup your apps on your primary rom using something like Titanium backup and then restore them on the other ROM.
Sent from my Ascend Mate 2 using Tapatalk
Click to expand...
Click to collapse
oh ic
MT2-User said:
oh ic
Click to expand...
Click to collapse
The app implements this feature but I'm working it out if that makes you feel better lol.
Sent from my Ascend Mate 2 using Tapatalk
Damn nice work SHM.. Congrats. And thanks!
Moody66 said:
Damn nice work SHM.. Congrats. And thanks!
Click to expand...
Click to collapse
I have it working %100 now. Its 3:35 am where I am at so time for bed. Sharing apps works as well between roms.
Sent from my Ascend Mate 2 using Tapatalk

Categories

Resources