Fix: I was able to flash the CWM recovery.img with nvflash, update Prime with CWM, and re-flash lilstevie's recovery to gain back Ubuntu-booting support.
Do a full backup with nvflash (instructions here)
Flash CWM recovery.img (attached) to the recovery partition with nvflash.
Code:
sudo ./nvflash --bct transformer.bct --setbct --configfile flash.cfg --bl bootloader.bin --odmdata 0x300d8011 --sbk 0x1682CCD8 0x8A1A43EA 0xA532EEB6 0xECFE1D98 --sync
sudo ./nvflash --resume --download 5 recovery.img
Use CWM to flash any update ZIPs (I updated Prime v1.7 to v1.8.2-->v1.8.4)
Restore the Ubuntu-booting recovery partition (05_SOS_raw.img) from the backup in step #1
Code:
sudo ./nvflash --bct transformer.bct --setbct --configfile flash.cfg --bl bootloader.bin --odmdata 0x300d8011 --sbk 0x1682CCD8 0x8A1A43EA 0xA532EEB6 0xECFE1D98 --sync
sudo ./nvflash --resume --download 5 05_SOS_raw.img
Original Question [Solved]:I have my Transformer dual booting Prime v1.7 (primary) and lilstevie's eMMC-loaded Ubuntu (recovery). I'd like to update Prime to v1.8.x, but I don't believe I'm able to boot CWM Recovery, as Ubuntu's taking up that space.
I'm about to go down the path of figuring out how to back up all of my partitions (easy), remove Ubuntu in-place (hard), update and backup Prime (easy), and flash it all back with Ubuntu again (medium).
Is there a better way to do this (such as actually being able to boot CWM Recovery), or does anyone have any advice with the above plans?
Welp, I'm impatient, so I'm going to give this a shot. My plan is to flash CWM in recovery.img form via nvflash, use it to update to Prime v1.8.4 (and maybe a new kernel), back everything back up again, and flash back lilstevie's recovery image. I'll post results.
I've wondered how you would do that myself, you could ask in the Ubuntu thread because a lot of those people probably had the same question
Mission accomplished. I've updated to Prime v1.8.4 without blowing away my Ubuntu partition. I'll update the main post. I'll probably start a thread in the Dev forums to compile information about messing around with nvflash.
thank you!
I used this method to upgrade from prime 2.5 to 2.7
The new flashpack updated 6 hours ago includes a mode that dumps the recovery partition, uploads CWM to recovery, so you can do the update with it. Then flash the kernel that was in recovery back once you are done
So you still have to have ubuntu in the recovery partition?
Is there no way to have the Prime Recovery partition AND have ubuntu AND have android?
Right now Im having a problem where I can't boot into Android at all, only Linux, even though I had the same configuration as you (Android Default, Ubuntu in recovery). This problem started after I installed the ROM Manager off the Android Market.
technological said:
So you still have to have ubuntu in the recovery partition?
Is there no way to have the Prime Recovery partition AND have ubuntu AND have android?
Right now Im having a problem where I can't boot into Android at all, only Linux, even though I had the same configuration as you (Android Default, Ubuntu in recovery). This problem started after I installed the ROM Manager off the Android Market.
Click to expand...
Click to collapse
The way I understand it is this: you can currently only have one "kernel" in the recovery partition at one time. Examples are:
Stock Recovery
CWM Recovery
Ubuntu Kernel
Option 1
If you want to switch between Android and Ubuntu, but don't care about CWM, you should put the Ubuntu kernel in the Recovery partition. I used to do this, but since I've been updating my Android OS (Revolution HD) frequently, I'm about to switch to the next option.
Option 2
If you'd like to keep CWM Recovery, but also be able to move between Android and Ubuntu frequently, keep CWM Recovery in the Recovery partition, and store two ZIP files on your MicroSD card:
Android Kernel ZIP
Ubuntu Kernel ZIP
Running either of these ZIPs from CWM Recovery will install that kernel blob to the default OS partition. Thus, upon reboot, it will boot that particular OS. If you want to boot the other OS, load CWM Recovery, flash that ZIP, and the new default OS will be changed.
rickatnight11 said:
The way I understand it is this: you can currently only have one "kernel" in the recovery partition at one time. Examples are:
Stock Recovery
CWM Recovery
Ubuntu Kernel
Option 1
If you want to switch between Android and Ubuntu, but don't care about CWM, you should put the Ubuntu kernel in the Recovery partition. I used to do this, but since I've been updating my Android OS (Revolution HD) frequently, I'm about to switch to the next option.
Option 2
If you'd like to keep CWM Recovery, but also be able to move between Android and Ubuntu frequently, keep CWM Recovery in the Recovery partition, and store two ZIP files on your MicroSD card:
Android Kernel ZIP
Ubuntu Kernel ZIP
Running either of these ZIPs from CWM Recovery will install that kernel blob to the default OS partition. Thus, upon reboot, it will boot that particular OS. If you want to boot the other OS, load CWM Recovery, flash that ZIP, and the new default OS will be changed.
Click to expand...
Click to collapse
Oh. K. So there is no sacrificed functionality in doing this? Do you get slower boot times?
technological said:
Oh. K. So there is no sacrificed functionality in doing this? Also, I've found the explanations of ClockWork Recovery to be even less noob friendly than everything else on this site. I dont understand what it is, nor how to get it, and I've been reading through this site for weeks.
Click to expand...
Click to collapse
CWM Recovery is a piece of software (I believe it's a very light build of Linux), written by Koush, intended to provide OS recovery features such as:
Backups
Restores
USB Access
Since the hardware is different for every device, installation and booting of CWM is different for every device. In the Transformer's case, CWM is written to the Recovery partition, overwriting the stock Recovery tool. (This tool only restores your Android partition to stock and applies OTA updates. If you're using CWM, chances are you're flashing your own ROMs, so this functionality is replaced by CWM features.) You boot into the CWM Recovery just like you would the stock Recovery, by holding Pwr+VolDown and then releasing and pressing VolUp, when prompted.
When you boot into any OS, that OS can essentially do whatever it wants to the hardware on the device, provided adequate tools and drivers are included in the OS. Since it's not smart to mess with the OS that's currently loaded, it makes sense to boot to another system before messing with Android. Thus, applying updates, wiping, backing up, or flashing new ROMS is done from CWM.
The last tip, which may help you understand everything, is an overview of how ALL operating systems work. The kernel IS the operating system. When your computer/phone/tablet boot, it always loads a kernel into memory. This kernel includes all of the drivers and applications needed to load the entire OS into memory. It also includes a reference to which partitions the rest of the data should be loaded from.
As an example, when Android boots, it boots the kernel, which loads all of the low-level linux drivers and modules. This includes the driver to access the internal flash. At that point it can access the partitions it's been programmed to "know" about, and load the rest of the OS from them.
CWM itself is doing the same thing. When you use the key combination to load the Recovery, your Transformer is loading the CWM Kernel, rather than the Android Kernel. The CWM Kernel contains (I suspect) a very watered down version of the Linux kernel, which it uses to boot the tiny Recovery application you are presented with. It has the drivers and modules needed to access the screen, the internal flash, the keyboard, etc, which allows you to perform all of those tasks.
Lastly, Ubuntu works the same way. Regardless of how you have it set up, you eventually trigger the Transformer to boot the Ubuntu Linux Kernel. This loads all of the drivers and modules, and then pulls the remaining portions of the OS from the correct partition.
So dont you lose all your data whenever you change OSes?
As far as I can tell, you keep CWM in recovery, then reflash the main every time you want to change to and from Ubuntu/Android. So don't you lose data every time you do this?
technological said:
So dont you lose all your data whenever you change OSes?
As far as I can tell, you keep CWM in recovery, then reflash the main every time you want to change to and from Ubuntu/Android. So don't you lose data every time you do this?
Click to expand...
Click to collapse
Correct. All you're doing is flashing the kernel partition, which is separate from the system and data partitions on both OSes.
Related
Recently I got Wind Optimus 2x (p999). Before I change anything, I want to create a full backup in case of warranty. Searching forum and google for couple of days I found several different "stock" recovery images. But all of them have different size/date/etc.. So I want to make my own recovery image.
My idea is make stock recovery image (via dd or nvflash), replace recovery with cwm, make backup, flash custom ROM. If i need to go back - do in reverse order .
1. From what I found, using
dd of=/path_to_store/myimage.img if=/dev/block/mmcblk0p7
should produce required image, but size is about 1.6M, while all other recovery images have size 3-5M
Am I doing something wrong?
2. I cannot find anywhere information about correct use of nvflash utility. Some shell scripts have bunch of parameters to write image into phone, but there is no info about how to read data from phone and create image..
Any help please?
I am sorry if I don't understand your questions but, I will try nonetheless. It seems you do not understand what nv flash or cwm do. Nv flash is how you CORRECTLY install a version of the clockworkmod recovery. Once installed, you choose the back up option to copy your system image. This recovery has the ability to do anything that has to do with rom flashing. Also is does it all simply by choosing what you want to do. There's no ADB or entering commands. Just look for TGA_gunnmans one click nv recovery flasher, this is all the info you will need.
Sent from the fastest g2x in the world
well, not exactly correct. nvflash is "low level" (means it accesses EPROM on hardware level) flash utility. It's designed to write data into EPROM. In most cases such utility can be used to read data as well (for backup purposes). That is why I am trying to find more information about nvflash and how to use it.
dd us *nix utility which works on higher than nvflash level, but lower than cp (copy).
By the time cwr is installed, the phone is different from factory - one of partitions is replaced. I am trying to backup this partition before replacement.
cy_mpak said:
well, not exactly correct. nvflash is "low level" (means it accesses EPROM on hardware level) flash utility. It's designed to write data into EPROM. In most cases such utility can be used to read data as well (for backup purposes). That is why I am trying to find more information about nvflash and how to use it.
dd us *nix utility which works on higher than nvflash level, but lower than cp (copy).
By the time cwr is installed, the phone is different from factory - one of partitions is replaced. I am trying to backup this partition before replacement.
Click to expand...
Click to collapse
There are stock recoveries available! Look in the optional files section.
http://forum.xda-developers.com/showthread.php?t=1054492"
After some more research and experiments I have found that recovery partition on G2x is mmcblk0p5.
Thanks to all who answered my questions directly or indirectly
Hi,
Backround:
My approach is to fullfil a full memory acquisition of an GSG i9000 (but thats not really relevant). The acquisition should be as forensic as possible by legal term. I approach is to apply as less changes as possible. So there is no option to turn on the device, root it and install ROM Manager or equal...
My Idea was to flash the Recovery Mode with CWM. After that I fullfil the acquisition with dd. (I could place the dd and su binaries to /sdcard/ext_sdcard and mount it with executable rights)
Problem and Approach
The bootloader of the device is not acceable, so I can't use fastboot to flash the recovery mode. Instead I have to use the Heimdall Suite over the download mode.
The Test/CrashDummy Device: is also a SGS-i9000, which had CWM 3.x allready installed. I flashed the recovery partition with an 2.5.x CMW image. However this didn't work out, v3.x was still booting when going to recovery mode. I did it many times, but it didn't help.
Then I read that the recovery mode-kernel is in the original linux/android kernel zImage. So I flashed it the kernel partition with Heimdall, which worked out for the recovery mode, but not for the Android OS itself..., was hanging on boot-bricked.
The second approach, flashing the original kernel, is the thing I would like to avoid generally.
The Question
Many users reported in forums that flashing recovery mode did it, my expirience showed the oposite. I also seed blog posts which told the /recovery is holding only the backup of the kernel partition.
What is or has to be flashed for a custom recovery mode eg CWM?
The Android kernel partition or only the recovery partition? Where is the recovery mode is actually stored?
I am really interested in the technical background, but can't find any documentation either on the official side nor in forums/wikis. Any links would be also helpful!
I looked at the PIT, is there a need to adjust the pit when the size of kernel images changes? Only the start address is relevant?
Also would be interested in the overall situation, am I missing something, logical flaws in the mentioned constelation?
Is there a way to pull the kernel image over the download mode, not only flash it? Maybe even other partitions, e.g. the whole flash?
Did somebody tried to read yourself in into the Odin protocol besides Glass Echidna, I started read the source of Heimdall. It's clean code but without documentation...
thanks in advance
ps: I spared time to search all the links of the flashimages, but I always used the official sources(HPs of the MODs) when it was possible.
EDIT: I found the link where the authors tells recovery is only a backup partition: vincent.bernat.im/en/blog/2011-android-samsung-galaxy-s.html
I made a mistake by trying to get through the rooting/rom-ing process in a hurry. The result is that i'm stuck on cm boot logo.
1. I installed cwm 5.5.0.4 custom recovery through this guide.
2. Made a nandroid and copied it to pc, sd card, external sd card.
3. Flashed cm-10.1-noname>gapps>tablet ui>wipe cache>wipe dalvik>reboot. (source, version:cm-10.1-20130827-UNOFFICIAL-tf101.zip )
4. Stuck on boot screen.
I'm guessing I should have used twrp rather than cwm.
The trouble is that cwm 5.5.0.4 seemingly doesnt have external sd card support, and having tried to flash cm, it means that the stock nandroid i made probably got moved elsewhere as no backups are found when i try to recover.
Is there a way out of this mess?
Ah, you are not totally painted into a corner. Just climb up the wall and across the ceiling!
There are 2 ways out: ADB or APX.
To use ADB, whilst booted to CWM, connect your USB cord to your computer. Update using the Naked Drivers 0.72 for the unknown device, or ADB device. It will probably show an MTP device as well, leave that alone.
Once you think you have the driver working, you will need ADB. I have a copy of the files in my dropbox so you don't need the whole android SDK.
https://dl.dropboxusercontent.com/u/34321735/adb.zip
Unzip them to the c:\adb folder.
Command prompt and run the following:
Code:
c:
cd c:\adb
adb devices
You should see a device followed by RECOVERY.
Once this is working, find the file you want to move to the tablet to flash (I would recommend TWRP 2.6.3.9 unless you plan on flashing Android Revolution HD) and move this file to c:\adb. I will call it flash.zip for the purposes of this.
Next, go back to your command prompt and type the following:
Code:
adb push flash.zip /sdcard/
Once this is completed you should see the flash.zip on the tablet in CWM so you can install it.
If you do install TWRP, be sure to do a NORMAL reboot (even if it is to a bootlooped OS) so the installation completes. Once you get to the ROM boot screen (pas the Eee Pad logo screens) you can boot back to recovery.
Method 2 - APX
I have a guide for using APX and EasyFlasher here: http://www.transformerforums.com/fo...nt/31927-frederucos-guide-root-rom-tf101.html
You can either use one of my repacked versions (linked in that thread) to install TWRP (has not been updated for the latest TWRP yet, but it is only a few versions old). If you want the latest, put it on a microSD and flash it after updating to the Easyflasher version.
Or you can download the stock ROM from the Asus Support site, place the .zip file as is in the asusupdate folder within EasyFlasher folder structure and then click the unbrick option.
Thank you Sir for the lightning quick response
Will try the apx method first and will let you know how it goes.
Just a quick question though if i may:
cwm is just a personal preference for me so is there an updated cwm easyflasher and will it do the cm 10.1 install better than 5.5.0.4?
(the last time i was adventurous with a recovery, philz raped my cat and shaved my mom. i know it was just a senseless crime! something about having to manually backup /preload/ or end up with broken nandroid)
jbonetwo said:
Thank you Sir for the lightning quick response
Will try the apx method first and will let you know how it goes.
Just a quick question though if i may:
cwm is just a personal preference for me so is there an updated cwm easyflasher and will it do the cm 10.1 install better than 5.5.0.4?
(the last time i was adventurous with a recovery, philz raped my cat and shaved my mom. i know it was just a senseless crime! something about having to manually backup /preload/ or end up with broken nandroid)
Click to expand...
Click to collapse
If you are going to venture into the JellyBean 4.2/4.3 ROMs, I would HIGHLY recommend using TWRP. It is by far superior to CWM, and no one is supporting CWM for the TF101 as far as I know. 4.2 introduced a new file structure for multi-users and updates do not flash properly if using an older recovery. You end up with your /sdcard/ folder in the /sdcard/0/ (and an additional 0 for each new ROM update flashed).
TWRP is far more intuitive IMO (all wipes are in one simple menu), and @sidneyk has added (in addition to internal and microSD support) dock USB and SD card support. TWRP has a terminal emulator and lots of other nice features over CWM.
Well thats got me puzzled.
Installed TWRP 2.6.3.0 using APX.method
Reflashed cm-10.1-20130721-UNOFFICIAL-tf101.zip >
gapps_4.2.2_CM10.1_TF101_20130324_stock_camera >
cm-10.1-20130721-UNOFFICIAL-tf101-tabletUIpatch >
wipe cache/dalvik >
reboot
And I'm still stuck on cm loading screen. Unless it takes more than 10 minutes for first boot I'm stumped...
P.S. Any way of reusing the CWM made stock nandroid with TWRP?
P.P.S. You're right TWRP is MUCH better. Gonna convert all of my devices for sure.
solved!
flashed cm then rebooted - worked!
flashed cm and gapps then rebooted - still works!
flashed cm>gapps>tablet ui - still working!
all with wiped cache/dalvik
apparently it doesnt like all of them being flashed at the same time for first installs :S
So in looking around I have not found any answer to my question. Why is everything to flash on the shield a .img instead of building zip files you can flash directly from recovery? I have been messing with android for quite a long time and know how to flash .img, fastboot, adb, ect. But dl'd and flashing a zip is far easier.
Any answers?
thanks.
*I think* that base factory images (.img files.) are meant to be flashed via fastboot, since they have a direct relationship with device specific partitions. Imagine a bit to bit flash, like a Ghost/Acronis image?!?
As for .zip files, they are installed via recoveries (CWM, TWRP, etc), because you just want to add/replace files in the / partition.
And with our Shield, until now, all OTAs are full system images, not updates.
I hope that I've explained this properly, if not please someone correct me
http://en.wikipedia.org/wiki/Fastboot#Fastboot
anthonws said:
*I think* that base factory images (.img files.) are meant to be flashed via fastboot, since they have a direct relationship with device specific partitions. Imagine a bit to bit flash, like a Ghost/Acronis image?!?
As for .zip files, they are installed via recoveries (CWM, TWRP, etc), because you just want to add/replace files in the / partition.
And with our Shield, until now, all OTAs are full system images, not updates.
I hope that I've explained this properly, if not please someone correct me
http://en.wikipedia.org/wiki/Fastboot#Fastboot
Click to expand...
Click to collapse
Not all ota are full system images, ota 65 and 67 are simple delta updates.
BTW, the main reason of .img files for images is because this can't depend on the recovery. How do you flash a recovery .zip file without a recovery?
You need to have a .img file that can be flashed via fastboot, it is VERY much "bricked" proff that a flashable zip
Thanks for the explanations. I realize some things need to be done via fastboot like unlocking or flashing a recovery for the first time.
I guess I have become spoiled by xda and the simplicity of modification that is available today. Far cry from hacking htcs back in the day.
thx -jason
Both answers are correct - it all depends on which software (on the device) is used to flash, and what format it accepts.
With Tegra devices you have at least 3 ways to flash stuff, from lowest to highest level:
- nvflash/tegrarcm mode. This is a very small firmware that is burnt in ROM and is thus always available no matter how hard you screw your device. It can run small programs (typically, a flasher) that are sent through USB. Problem is, for Tegra4 it will only accept signed binaries, which makes it useless for modders.
- bootloader/fastboot. The bootloader supports the fastboot protocol, which can flash .img files. The bootloader is written in flash memory so your bootloader partition must be in good shape.
- recovery/zip files. The recovery is a Linux image, so this means it is a full-blown system of its own right. Because of this it can support more format, including .zip archives with a script to describe how the archive should be installed.
So in the boot chain, you have 3 anchors from which you can flash images: boot rom (always available but unusable to us) -> bootloader -> recovery. The fact the boot rom cannot be used without a signed image (which is not available publicly) means that screwing your bootloader is sufficient to permanently brick your device.
Recovery images are more convenient since they are in .zip format and can for some be device-independent (e.g. superSU recovery images are flashed the same on every single device out there), contrary to the bootloader which can be different for every device. But they require a working recovery, which is not always granted - so for actual recovery, fastboot images are also useful.
That's why I love XDA
You're never alone!
Thanks for the additional info to all
Anthonws
Hello all,
I really need, for a commercial project, to flash a great number (>100) of Galaxy Camera 2 (EK-GC200() device, all with the same firmware, rooted and modified as I need.
I have to flash boot.img (modified by me) and system.img (rooted).
I have now to root the camera, then start the system, enable developer options, enable adb debug and at the end flash a new boot.img, and the system.img itself (adb shell, dd ...).
This is time consuming, and error prone.
I'm sure the boot.img & system.img are correct, cause I can flash them without error (and they work fine) with dd from the internal emulated sdcard.
I can see two viable alternatives:
1. A custom recovery, from where I could make a nandroid backup, which I can use later on to update all the rest of the cameras.
But:
I tried to port the EK-GC100 cwm recovery, I've been able to boot it up, but the touchscreen is unusable and I got a lot of error coming from the file system.
Please help me! Any suggestion, half project, everything is really appreciated!
2. To create an Odin package, using the .img files I can optain with dd from a ready camera.
But:
I tried all I can do to build a Odin package, but every time I got an error (Odin Fail) when I try to flash system.img.
I tried to build a package containing recovery.img + boot.img, and that works.
I tried to build a package containing only system.img, and it doesn't work, every time I got a Fail from Odin.
I tried manual compression (tar + md5sum on Linux), and automated scripts you can find on XDA, both under Linux and Windows.
Why is system.img impossible to flash?
What am I missing?
Thank you in advance.
Ciao,
Giovanni