Looks like somewhere around CWM 4 is when the switch to tar was made. It has better the speed along with the ability to back up and restore the correct filesystem. Sounds like the progress thing was added somewhere around then as well.
[ Found here: https[colon]//plus.google[dot]com/103583939320326217147/posts/G4VQuCpR25y Sorry, can't make outside links yet. ]
Looking at a kernel zip, it uses dd to put the blob in /dev/block/mmcblk0p4, which is also where the recovery goes... I clearly need to learn more about what's going on here when flashing a kernel or recovery to the same thing and what the function of the blob is.
Looking in the nandroid backuip system tar though, it grabs the /system/lib/modules folder which some kernel zips add to, so the nandroid is backing that up. I'm not sure if nandroid, at least in its current state, is able to back up or restore the kernel itself because of the whole blob thing?
Hmm, perhaps I should make a feature list instead of just saying look at the Xoom release thread!
Hey - thanks for looking this over. I think that right now using your git code that produces cache.*, data.* , and system.*, and looking at the code, that it appears that it figures out whether boot is encrypted and decides to use a blob or not, and in tf101 case, it does. It appears to make one in data.*.tar which I'll yank apart and look for it in. I may be getting some runtime parameter guessed wrong so maybe not data. The other versions of v5.*.* seem to create their own boot.img which either is a blob write or not depending on the same criteria.
I thought it would be pretty useful, since I've used this feature on other cwm's to be able to restore only a kernel from some backup using advanced restore so am trying to see if can be implemented here but a lot to learn for sure.
I think the entire thing would be much easier if I knew how to create a logfile of the backups and restores at the cwm level. It looks like there are nearly enough "debug writes" so that with the addition of a couple more it would be useful. Without knowing what was passed to these many functions, the thing becomes too much guesswork. I might try to ask you a question or so via message if you don't mind.
One thing that got me curious was trying to answer to Q&A questions about non-booting restores. Made me wonder if the kernel was even being restored via what is being backed up and restored by 3.x right now. Yeah, I can see the /system/lib/modules is handled but that would make matter even worse without the blob restore. What I've noticed doing this myself has be inconclusive so far. If I had a good kernel that matched the modules both to start with before restore and after then everything worked fine. If not, then it didn't. If I then flashed a kernel, then all was well. More to it than is easy to see for sure.
Anyway, thanks - Mick
EDIT: I booted my linux box and copied over the backup made with your version of cwm (which backs up the same stuff as the 3.x only to .tar files), and there is no sign of the kernel being backed up at all. It is not in data.*.tar , nor system.*.tar, or cache.*.tar, and that is all there is.
This gives me a lot less faith in counting on cwm as a backup of any real use until this if figured out. Yeah, it backs up 99.9% of the stuff and makes it easy to restore, but after you're done, you'll need to either have had the same or similar kernel you had before so that the modules fit it, or else you'll have to burn a kernel immediately if you're to boot.
Anyway, I'll look around at how the code is doing this, and see why we can't use all the blob and boot tools that are around to create a 'boot.*.tar' archive along with the others that just blows a blob out to block m*4 and gets this done.
It seems like a big oversight, and I'm not 100% sure it's correct, but I'm close to sure. It definitely isn't in my archives so I think this is on the right track.
Last edited:
