Related
A few weeks ago my SD card went bad on me. I have been using Gingershedbread as my ROM and see there are some updates, however, since I don't have an SD card, the "normal" method of loading the zip onto the SD card obviously won't work for me.
My question is: Is there a way to flash a ROM zip from a pc (windows) to my phone without an SD card? I know you can put the zip on the data partition, then use "recovery --update_package=DATA:rom.zip" (through adb), however, when trying to copy the rom I get a message saying that there is no space left.
As of now, the only thing I know of is to do a full wipe and factory reset, then push the ROM zip to my phone, but I don't necessarily want to do this every time.
I have also tried fastboot and using mkyaffs2image to create a system.img from the ROM's system folder in the zip file, but I am not doing something right.
I run "mkyaffs2image c:\rom\system\ c:\system.img"
then with my phone in fastboot, I "fastboot flash system c:\system.img"
and "fastboot flash boot c:\rom\boot.img".
I restart the phone in recovery mode, load gapps and xtrCache, but then it reboots, sits on black screen for a few seconds, then reboots into recovery.
I have tried erasing system and boot first, but that didn't seem to help.
I first tried just flashing system.img, but that didn't work.
Not sure what I am doing wrong. Is there a way to take a ROM zip and create a system.img and boot.img that can be flashed through fastboot without an SD card? OR, is it possible to flash a ROM zip without transferring the file to my phone first? Any help would be appreciated.
I don't think that there is an answer to your question which is both complete and also short.
So, here goes with the long answer.
First, a yaffs2 image file (e.g. system.img) is not compressed, so it is quite large - for things like the HTC factory/stock ROMs, it can be bigger than the cache partition. I don't know if the cache partition is actually used when you push things with fastboot, but experimentally, I have run into the problem that when attempting to do a
Code:
fastboot flash system my-yaffs2-system.img
fastboot gives you get an error about being out of room.
Second, and more importantly, the file modes (permissions) and user:group ownership of files in the /system mount point are extremely critical to proper operation of Android. If you have files sitting on a Windoze machine filesystem (either FAT32 or NTFS), all this information will be lost even before you create your "yaffs2" image file. (Not only that, but all symbolic links will be missing, too). This is why you observe that ROM files have instructions in their "update-script" (or "updater-script") command files for setting file & directory ownership, file permission modes, creating symlinks, et cetera.
Third - even if you use a linux OS to unpack yaffs2 images, and run as root when you are doing so, a lot of the "unyaffs" programs that are lying around do not even bother to extract things like user:group ownership or file modes - so you are basically screwed as soon as you unpack a yaffs2 image file on a PC, no matter whether it is Windows or Linux/Unix/OS-X.
Fourth, I am not sure that it is even a good idea in the first place to be "flashing" yaffs2 images. The "fastboot flash" command merely writes whatever you pass to it as a long linear blob of bytes, and there is no evidence to suggest that the yaffs formatting used in the archive is the same formatting used by the kernel. When "Nandroid" runs to restore a system.img or data.img file onto the phone, it does not write the image as a linear blob of bytes: it actually mounts the filesystem in question, cleans it up with a "rm -rf *" command, and then manually unpacks the yaffs2 image file into the mounted file system, one file at a time. (Fortunately in this case, it actually restores things like symlinks, file permissions, and file/directory user:group ownership information). This insures that the low-level yaffs2 formatting is *identical* to what the kernel expects, because it is the kernel that creates it.
There is a solution, but it is tedious enough that you really ought to ask the question, "Why don't I go out and buy a replacement SD card for 10 bucks instead of wasting a huge amount of time?"
Here's the solution:
You mount /system, clean it up manually, use adb to push the files recursively from wherever you have them stored on your PC, and then afterwards you run a custom (signed) installer .zip file which has been modified so that it only contains the "symlink" and permission-setting commands - you delete the "format" and "extract" commands from that command file, since you have manually put all the files into /system. Either that or you manually adjust the permissions and user:group ownership information by hand.
Obviously, since you don't have an /sdcard any longer, you will need to put this flashable, custom .zip file in /cache, and then create a one-line command file at /cache/recovery/command that points at the flashable .zip file in /cache. (This is the way the the OTAs work, and also how ROM Manager is able to customize the recovery when it boots).
Is this a lot of work? Yeah, you betcha.
It seems like running down to wally world to get a cheap SD card might be a little more fun.
Thanks for the info. I figured getting a new SD would be the best solution.
I knew about the symlink and file permission stuff and was trying to flash a system img then run a zip to ser that info., but couldn't get it to work. Sounds like using fastboot might be a bad idea.
For now I think I will just have to find a rom and stick with it for a while.
I am nearing an upgrade for a new phone and looking at the Thunderbolt, which comes with an SD so I don't want to buy one just yet.
Thanks for your help.
Sent from my ERIS GSBv2.1 using XDA App
kgunnIT said:
then run a zip to ser that info., but couldn't get it to work.
Click to expand...
Click to collapse
If you know how to sign ROMs, it's really not a hard hack to launch an installer of the type you mention.
And, now that I've just said that, I think I have another, simpler, idea.
But first:
[SIZE=+2]How To Launch a (smallish) .zip-based Flash That's Not On the SD Card.[/SIZE]
All of the recoveries - both the stock and custom recoveries - look for a "command" file when they first start up.
It literally is named "command", i.e.: /cache/recovery/command
... and it is a simple text file with as few as one line(s) in it.
Here is an example from the most recent OTA of the contents of /cache/recovery/command:
Code:
--update_package=CACHE:8e3b63f96149.OTA_Desire_C_Verizon_WWE_2.37.605.4_2.36.605.1_release.zip
basically, it's just a single line with the following format:
--update_package=CACHE:filename.zip
So, if you are trying to get an installer to run without an SD card, you would:
1) Boot to Amon_RA
2) Wipe the cache if necessary (wipe -> wipe data/factory reset also clears /cache)
3) Push your zip file to cache:
Code:
adb push mycustominstall.zip /cache/
4) Create a command file (say, named "command.txt") with the contents:
Code:
--update_package=CACHE:mycustominstall.zip
5) Push it to the phone:
Code:
adb push command.txt /cache/recovery/command
6) reboot directly back into recovery with
Code:
adb shell reboot recovery
When the recovery boots up again, it will immediately start unpacking your "mycustominstall.zip" file.
After I thought this all the way through, I realized, though: a lot of the ROM files are only about 100 MB, and cache is about 128 Mb, so
.... wait for it .....
... wait for it ....
it might be a worthwhile experiment to just push an untouched ROM file right to cache and then use that ROM file's name in your "command" file.
So long as /sbin/recovery does not unpack files to /cache (I can't remember if it does this or not!), you could use original ROM files -- just what you wanted originally. If it unpacks things to cache, though, it will only get part way through the install and fail.
It's worth a shot; if it fails, you'll have a mess that is no worse to clean up than what you've presently got. (If it fails, to be on the safe side it might be wise to go in using adb and clean things up in /cache a little bit so that the next recovery boot has some wiggle room in /cache - e.g. "adb shell rm -rf /cache/*" )
bftb0
bftb0 said:
If you know how to sign ROMs, it's really not a hard hack to launch an installer of the type you mention.
And, now that I've just said that, I think I have another, simpler, idea.
But first:
[SIZE=+2]How To Launch a (smallish) .zip-based Flash That's Not On the SD Card.[/SIZE]
All of the recoveries - both the stock and custom recoveries - look for a "command" file when they first start up.
It literally is named "command", i.e.: /cache/recovery/command
... and it is a simple text file with as few as one line(s) in it.
Here is an example from the most recent OTA of the contents of /cache/recovery/command:
Code:
--update_package=CACHE:8e3b63f96149.OTA_Desire_C_Verizon_WWE_2.37.605.4_2.36.605.1_release.zip
basically, it's just a single line with the following format:
--update_package=CACHE:filename.zip
So, if you are trying to get an installer to run without an SD card, you would:
1) Boot to Amon_RA
2) Wipe the cache if necessary (wipe -> wipe data/factory reset also clears /cache)
3) Push your zip file to cache:
Code:
adb push mycustominstall.zip /cache/
4) Create a command file (say, named "command.txt") with the contents:
Code:
--update_package=CACHE:mycustominstall.zip
5) Push it to the phone:
Code:
adb push command.txt /cache/recovery/command
6) reboot directly back into recovery with
Code:
adb shell reboot recovery
When the recovery boots up again, it will immediately start unpacking your "mycustominstall.zip" file.
After I thought this all the way through, I realized, though: a lot of the ROM files are only about 100 MB, and cache is about 128 Mb, so
.... wait for it .....
... wait for it ....
it might be a worthwhile experiment to just push an untouched ROM file right to cache and then use that ROM file's name in your "command" file.
So long as /sbin/recovery does not unpack files to /cache (I can't remember if it does this or not!), you could use original ROM files -- just what you wanted originally. If it unpacks things to cache, though, it will only get part way through the install and fail.
It's worth a shot; if it fails, you'll have a mess that is no worse to clean up than what you've presently got. (If it fails, to be on the safe side it might be wise to go in using adb and clean things up in /cache a little bit so that the next recovery boot has some wiggle room in /cache - e.g. "adb shell rm -rf /cache/*" )
bftb0
Click to expand...
Click to collapse
You always find the one thousand and ONETH way to skin a cat. Hehehehe...
Thankyou so much for this this alowed me to flash a rom on my phone which can't detect any sd cards and i stupidly wiped it before relising the sd card wasnt being detected!
sum_guy55 said:
Thankyou so much for this this alowed me to flash a rom on my phone which can't detect any sd cards and i stupidly wiped it before relising the sd card wasnt being detected!
Click to expand...
Click to collapse
very good, sum_guy55!
At least all that typing wasn' t in vain.
Out of curiosity, how big was the ROM file you used?
bftb0
Been meaning to post this:
Thanks for your posts roirraW "edor" ehT and bftb0 for posting this. I also was able to clear the cache and push the ROM and update.
However, I have xtrCMCache2cache on my phone, so the dalvik-cache was moved from /data/ to /cache/. After doing a wipe of dalvik-cache from Amon recovery, the folder in /cache/ was not emptied out. I went ahead and cleaned it manually, which freed up enough space to push the ROM.
Is this behavior expected using cache2cache and wiping dalvik-cache from recovery? I guess it would be since the dalvik-cache was moved.
Anyway, after clearing the dalvik folder, I was able to push GSBv2.4 to my phone, as well as gapps and xtrCMCache2cache, a total of almost 80 MB. Rebooted and all was well.
Thanks again for your help.
kgunnIT said:
Been meaning to post this:
Thanks for your posts roirraW "edor" ehT and bftb0 for posting this. I also was able to clear the cache and push the ROM and update.
However, I have xtrCMCache2cache on my phone, so the dalvik-cache was moved from /data/ to /cache/. After doing a wipe of dalvik-cache from Amon recovery, the folder in /cache/ was not emptied out. I went ahead and cleaned it manually, which freed up enough space to push the ROM.
Is this behavior expected using cache2cache and wiping dalvik-cache from recovery? I guess it would be since the dalvik-cache was moved.
Anyway, after clearing the dalvik folder, I was able to push GSBv2.4 to my phone, as well as gapps and xtrCMCache2cache, a total of almost 80 MB. Rebooted and all was well.
Thanks again for your help.
Click to expand...
Click to collapse
It was all bftb0. Interesting, I had once asked if cache was definitely wiped from Amon after it was moved. The consensus was that it should. I shall be anticipating some light shed on this.
Sent from my Gingerbread Eris via Tapatalk
Well, Amon_RA has no idea whether you are using cache2cache; I suppose we would need to look at the code to figure out how it behaves.
If it mounts /data and then does something like
rm -rf /data/dalvik-cache
there is a chance that the symbolic link is not followed, which would explain what kgunnIT observed.
Normally, if you are flashing a new ROM in a full-wipe fashion, the " wipe data/factory reset" menu option clears both /data and /cache, so in that case it is irrelevant that the "wipe dalvik-cache" is a no-op.
If you are overflashing, it's not obvious that you need to wipe the dalvik-cache... at least for the market apps normally stored in /data/app, although it seems like it would be a good idea to do so, as the system apps could be changing.
Note that even when cache2cache is not in use, the Amon_RA menu item "wipe dalvik-cache" never works as intended for froyo & gingerbread ROMs - the system apps have their dalvik-cache stored in /cache, and this never gets touched by Amon_RA with that menu operation.
BTW... for what it's worth, the ClockworkMod recoveryhas a menu entry for wiping only the cache.
bftb0
bftb0 said:
BTW... for what it's worth, the ClockworkMod recoveryhas a menu entry for wiping only the cache.
bftb0
Click to expand...
Click to collapse
Does ClockworkMod recovery work ok on the Droid Eris? I was going to load it on, but saw some people posting that it bricked their phones, so now I am skeptical. I will do more research and see if this is something I want to do. Thanks for your insight.
kgunnIT said:
Does ClockworkMod recovery work ok on the Droid Eris? I was going to load it on, but saw some people posting that it bricked their phones, so now I am skeptical. I will do more research and see if this is something I want to do. Thanks for your insight.
Click to expand...
Click to collapse
There is a version of Amon_RA (the trackball-optional version) that also allows you to format cache. You can find out more about it here: http://androidforums.com/eris-all-t...2-custom-recovery-trackball-not-required.html
That said, if you have ROM Manager, you can have Clockwork Recovery start as a stub within Amon_RA just from ROM Manager (the first option copies a file called update.zip to the root of your SD card, and the second, "Reboot into Recovery", starts Amon_RA with a script to flash update.zip, which starts Clockwork.) In fact, once update.zip is on the SD card, you can start Amon_RA as you always do, go to the Flash a zip from SD card menu, choose update .zip, and it will start Clockwork, if you want to do it that way. However, the drawback to this is that you can't go back to Amon_RA without shutting down the phone and then restarting in Recovery again, so I just find it easier to use the trackball-optional version of Amon_RA.
I think every person who has bricked their Eris while running Clockwork was running Clockwork Recovery as their main recovery image, and not in the way that I described in the last paragraph. (Though don't hold me to that ...)
kgunnIT said:
Does ClockworkMod recovery work ok on the Droid Eris? I was going to load it on, but saw some people posting that it bricked their phones, so now I am skeptical. I will do more research and see if this is something I want to do. Thanks for your insight.
Click to expand...
Click to collapse
I've been using it through ROM Manager since last August or so, I use it all the time.
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).
Hello you DualBooters and Triplebooters out there!
SDCacheMount for SD-Roms
Well, this idea came to me because many users of my triple-boot SD were getting tired of the rebuilding of system-cache when every time they had to switch between roms. What I have here is a small script that will install to /system/etc/init.d The script will run at boot time and create a 100mb .img file to be used for /cache. This way each rom will have its own dedicated /cache partition so to say. This will also benefit anybody that dualboots (eg. EMMC / SD-Rom). I've prepped two different versions. One for my triplebooters out there and the other for anyone running a rom off an SD card.
Things to note:
-This will dd a 100mb .img file to your /sdcard partition of your sd-rom on first boot. What this means is that before the system progresses any further the img file needs to be created so that the /system can use it as the /cache partition.
-It will sit at a black screen for up to 1 minute possibly. So please be patient!!!
-The dd'ing of the .img only happens on first boot. So once the cache .img is created. Boot time will be normal on successive boots.
-Make sure you have enough space on the /sdcard partition of your sd-rom.
-So for Dualbooters you will need at least 100mb free
-For Triplebooters you will need at least 200mb free
-Now you can switch between EMMC roms and SD roms without having to wait for /cache to rebuild every single time.
DOWNLOAD:
DUALBOOTERS ( EMMC / SD )
**You should be able to flash this from a standard CWM Recovery or rename the .zip file to begin with "update-" for Verygreens method.**
SDCacheMount_DualBooters.zip
Click to expand...
Click to collapse
TRIPLEBOOTERS ( EMMC / DUALBOOT-SD )
**You should only use the CWM Recovery that is included with my Dualboot-SD**
SDCacheMount_TripleBooters.zip
Click to expand...
Click to collapse
Big thanks to:
DizzyDen for helping me out with the script
Shumash for troubleshooting it for me
Inportb for some guidance
HacDan for his sense of humor
Hope this helps a few of you Nookers out there!
Thanks,
Racks
Reserved?!
Great job! gonna have a try on this
So the main advantage of this script is smaller booting time?
And this is the case when you switch Roms only between emmc and sd or also 2 different roms from same sd?
Unleashed from my Nook Color at 1.2G
RASTAVIPER said:
So the main advantage of this script is smaller booting time?
And this is the case when you switch Roms only between emmc and sd or also 2 different roms from same sd?
Unleashed from my Nook Color at 1.2G
Click to expand...
Click to collapse
The advantage of the script is that each AOSP will have its own dedicated cache and not all be utilizing the same space for all the cache.
RASTAVIPER said:
So the main advantage of this script is smaller booting time?
And this is the case when you switch Roms only between emmc and sd or also 2 different roms from same sd?
Unleashed from my Nook Color at 1.2G
Click to expand...
Click to collapse
The most obvious effect is that booting between the various ROM's is seamless (except for the minimal wait at the blank screen) and fast. It makes switching between the AOSP's very easy. The less obvious, behind the scenes effect is as Dizzy describes.
It should be noted that if you flash an updated or newer ROM, you will also need to reflash the SDcacheMount.zip.
shumash said:
The most obvious effect is that booting between the various ROM's is seamless (except for the minimal wait at the blank screen) and fast. It makes switching between the AOSP's very easy. The less obvious, behind the scenes effect is as Dizzy describes.
It should be noted that if you flash an updated or newer ROM, you will also need to reflash the SDcacheMount.zip.
Click to expand...
Click to collapse
Yes correct, thank you. I'll make note of that in the OP. Also note that once the .img cache is created, although you have to reflash the SDCacheMount after flashing a new rom. It won't have to create a new .img. The script will detect if one exist already and if so, proceed to boot. But if you don't flash the SDCacheMount right after flashing the new ROM. /cache will default back to /emmc
-Racks
CWM 5.8.0.9 for Huawei MediaPad
WARNING !!! DON'T FORMAT AND DON'T WIPE PARTITIONS USING THESE CWM !
I don't know how much this CWM version improves over the existing one by segler11.
However these build were more aimed at compiling and testing the new kernel sources.
I have tested compiling with both arm-eabi-4.4.0 and arm-eabi-4.4.3 with success on Ubuntu 10.04.
This is experimental, however with the new kernel sources it will just be a matter of time.
I have compiled the kernel included in this CWM recovery image but I didn't recompile the complete image.
I took as base Pyramid CWM 5.8.0.9 and I replaced the files from those found on a stock C232B005 kernel.
As the default build configuration I have used the /proc/config.gz of a C232B005 running kernel.
I have tested this CWM to be able to backup these partitions (I have not tested "restore" yet, just checked the tar archives):
boot.img - 12.582.912 (match 12Mb)
recovery.img - 16.777.216 (match 16Mb)
data.ext4.tar
cache.ext4.tar
system.ext4.tar
custom.ext4.tar
as you can see my hand tweaks to "recovery" require the name of "cust" partition to be "custom" instead but I believe this is a no issue while you backup and restore with the same CWM. Suggestions welcome.
BUGS:
data & time on archives are wrong
mount USB storage does not work
adb not enabled in recovery mode
Formats and Wipes do not work don't use them
The "busybox hwclock" applet doesn't work to set the hardware clock of our device.
The "adb shell" is not active while in CWM recovery, I don't know why and this was my objective so if you have suggestion please help.
As usual flash both "recovery" and "recovery2" partitions using "fastboot" and one of the attached CWM recovery:
Code:
fastboot flash recovery recovery-5.8.0.9-HWMOD-eabi-4.4.3.img
fastboot flash recovery2 recovery-5.8.0.9-HWMOD-eabi-4.4.3.img
fastboot reboot
WARNING !!! DON'T FORMAT AND DON'T WIPE PARTITIONS USING THESE CWM !
.:HWMOD:.
.
Reserved CWM HWMOD
This version seemed to work better for me.Tnx dude!
john9 said:
This version seemed to work better for me.Tnx dude!
Click to expand...
Click to collapse
Thank you for trying it.
Remember to absolutely avoid formatting or wiping partitions.
If you need to format/wipe do it ONLY after reinstalling the original "recovery.img" in both "recovery" and "recovery2" partitions and then reset the device from:
"Settings -> Backup and reset -> Factory reset"
ATTENTION !!! You can safely do a wipe or factory reset only after reinstalling the original recovery image.
Sorry for insisting but I don't want to create problems on users devices and I know those operations will create problems.
.:HWMOD:.
Just a note: I used your 4.4.3 version to try making a nandroid backup last night. Good news and bad news.
This morning I inspected the result using the app Nandroid Browser.
Good: Your CWM does successfully backup /data/data. The other CWM that had been posted here did not do so properly.
Bad: Your CWM also backs up the entire internal SD storage contents inside the folder /data/share. It is customary *not* to include this in a nandroid backup because a) you don't want to inflate the file size unnecessarily, and b) you don't want to overwrite the internal SD on a restore.
Idea: After you fix it, and until you manage to get ADB over USB working, maybe you could add a menu option to make a separate backup archive of internal SD to external SD. This would allow a route to save the internal storage if the device becomes unbootable and requires a data wipe.
cmstlist said:
Just a note: I used your 4.4.3 version to try making a nandroid backup last night. Good news and bad news.
This morning I inspected the result using the app Nandroid Browser.
Good: Your CWM does successfully backup /data/data. The other CWM that had been posted here did not do so properly.
Bad: Your CWM also backs up the entire internal SD storage contents inside the folder /data/share. It is customary *not* to include this in a nandroid backup because a) you don't want to inflate the file size unnecessarily, and b) you don't want to overwrite the internal SD on a restore.
Idea: After you fix it, and until you manage to get ADB over USB working, maybe you could add a menu option to make a separate backup archive of internal SD to external SD. This would allow a route to save the internal storage if the device becomes unbootable and requires a data wipe.
Click to expand...
Click to collapse
Thank you for trying it. I wanted to compile/test a kernel with new sources in a CWM.
Yes, in our device the internal memory "/mnt/sdcard" is also mapped under "/data/share".
Unfortunately I don't have the skills (yet) to build a complete recovery image from scratch,
so what I did was just compiling the kernel part of the recovery image, using the new sources.
Then I simply hex tweaked the "recovery" executable of a 5.8.0.9 Pyramid CWM (HTC Sensation).
So, in conclusion, I have no control over what is copied during the backup process of those partitions.
Though I could control which partition is processed by removing them from "fstab", but there is no gain into it.
We will have to wait somebody with the specific knowledge, or maybe I will have some time to learn once I return from holidays.
.:HWMOD:.
Today i have builded bootable CWM 5.5.0.4 from sources, so now we can adjust all what we need
after_silence said:
Today i have builded bootable CWM 5.5.0.4 from sources, so now we can adjust all what we need
Click to expand...
Click to collapse
well done
HI, can anyone share buckup from working device created by CWM.?
Thanks to all.
Hi,
Is it possible to flash update zips from this CWM recovery (like Beats Audio which is in flashable zip format)?
I don't want to use it for backup-recovery.
...and how about doing wipe cache and wipe dalvik cache?
.dredd. said:
Hi,
Is it possible to flash update zips from this CWM recovery (like Beats Audio which is in flashable zip format)?
I don't want to use it for backup-recovery.
...and how about doing wipe cache and wipe dalvik cache?
Click to expand...
Click to collapse
Haven't tried installing a ".zip" archive from CWM but it should work.
Avoid "wiping" and/or "formatting" partitions, they will be messed up.
hwmod said:
Haven't tried installing a ".zip" archive from CWM but it should work.
Avoid "wiping" and/or "formatting" partitions, they will be messed up.
Click to expand...
Click to collapse
The main reason for use of CWM would be to have the possibility of flashing update zips from CWM... but I am afraid of messing up my device... to understand: no problem if I have to reflash the rom but I would not want to cause mistake which could be repaired only by service.
fastboot is always available if something goes wrong and if you flash cwm you wont be able to install official roms because cwm will overwrite stock recovery
so i was stupid and wiped data and cache - then remembered that it said not to - how do i fix this paperweight? i tried fastbooting all the usual partitions (system, boot, userdata, cache, etc) but still nothing - i can get to fastboot but i cant flash any dload updates. any suggestions are greatly appreciated.
flash stock recovery (2 files) from zipped rom via fastboot and then you should be able to flash stock rom
flashed three different stock recoveries to recovery and recovery2 - still only get the media pad logo twice (flashed androidani intl rom before bricking) cant boot to recovery - think the partition table is screwed. is there a way to create partitions from fastboot, and if so, still would be nice to know the names of the partitions to flash as referenced in tmo stock thread.
byt3b0mb said:
flashed three different stock recoveries to recovery and recovery2 - still only get the media pad logo twice (flashed androidani intl rom before bricking) cant boot to recovery - think the partition table is screwed. is there a way to create partitions from fastboot, and if so, still would be nice to know the names of the partitions to flash as referenced in tmo stock thread.
Click to expand...
Click to collapse
The time needed to reformat and rewrite all the firmware partitions (the first time) will be between 10-15 minutes.
Be patient and give enough time to the device to execute all the needed processes.
When the device finally boot it need to completely regenerate dalvik-cache (the first time).
So try again as instructed above, rewrite "BOTH" partitions named "recovery" and "recovery2", both using the same "recovery.img" file found in the latest stock Huawei firmware.
Now extract the stock Huawei firmware archive on your PC and copy the "dload" folder on an empty formatted SDCard, then insert the SDCard in the MediaPad reboot it and wait until success or failure message.
If you wiped partitions you will have to wait more time (20-30m). It may be that after waiting a while a message about "Encryption not possible" could appear, just say no to encryption and let it reset the device.
It already happened to some of us so hope you are also able to recover your tablet.
thanks i will give it a shot - while it is rewriting partitions, should it be on the huawei logo? or should i see the android / gears turning?
byt3b0mb said:
thanks i will give it a shot - while it is rewriting partitions, should it be on the huawei logo? or should i see the android / gears turning?
Click to expand...
Click to collapse
First time restoration takes time on both moments during the 1st Huawei log and even during animation.
Trying to recover a partition that was wiped takes much longer for the OS to show the error.
When I tried wiping "data" and rebooted the device I recall I went for a long walk and when I returned the device was showing the "Encryption failure / Reset" message (about half an hour later).
So I can only suggest that when you retry you wait at least that amount of time (30 min.) with charger connected, whatever happens leave it alone until it display or ask you do something. Let me know if it works when you have tried.
Download links do not work for me. Can you upload in mediafire please?
Hello! I just tried installing a different version of GApps (Open GApps) over my current one (the one linked from the cyanogenmod wiki) and it says it couldn't perform the operation because another version was already installed and that I needed to format the /system partition. This triggered a bunch of questions (what's on the /system partition? will I lose my user-installed apps if I format it? Can I do it safely?).
I found some of the answers and read the source of the cyanogenmod updater-script. I learned that there's a backuptool.sh which looks like it will copy /system/addon.d to /tmp/addon.d and also execute some sh scripts with particular names (pre-backup, post-backup...). This is what I can understand and I'd like to know more.
Can someone write (or link to it if it's already been written) a step by step of what happens from the moment I click on 'install zip' and choose my cyanogenmod zip (or another ROM, if there aren't too many differences) from clockworkmod (or another recovery)?
Also what happens when I install GApps? And what if they were already installed? Where will they be installed (/system/priv-app?)? What happens if I flash GApps with Gmail and then update it via Google Play Store?
Something like (these are not actual steps):
- select install zip from recovery
- ROMs will check for existing /system and warn the user about X
- Y script will backup stuff from this directory to that directory
- directory Z is never touched and the user may safely store stuff there to be kept across ROM updates
etc.
I'd be willing to write some sort of summary once I gather enough information.
One of the questions I'd like to know the answer is about installing different GApps by formatting /system (what will I lose? do I need to format /system, then reflash the ROM, then flash the new GApps?)
Thank you!