[Android Q&A, Help & Troubleshooting] dsulliii:
____________________________

Hey pscherry78, As far as my understanding flies, there's two methods...

Since this is an ".img" file, you can only use the "dd" command from a shell for this.

In order to install zip from sdcard, the file has to be a ".zip", which this one is not. The "dd" command does not change it to a zip.

For a good idea of what "dd" is all about, you should search the Internet for it. It's foundation is is describing data at such a low level that you don't need to filter copying it through system utilities. In effect, it will overwrite an entire partition with complete disregard to what an operating system would normally validate. You'll find that many of the Internet sources like to warn you that dd could stand for "Data Destroyer" although that is not at all what it is... but it DOES do that. Just think of it as a copy utility for this. A copy utility whose power supersedes any operating system or database utility. It behaves outside of and above everything else in a system making it horribly dangerous if misused.

dd can define the data that is being copied, and in most uses, its parameters are indeed used for that purpose. But a straight-across copy says "if=" and "of=" meaning "input file" and "output file". For this, the NAND block where we want the data to go is the "of=" and the disk image that we want to put there is the "if=". This particular usage copies a disk image from our ".img" file directly to the partition with complete disregard to everything else. It does not create a ".zip" file or anything else. It simply copies the disk image.

I hope this helped somewhat. The whole ".zip" file method is a whole other process, and it is not interchangeable with the one we ended up choosing. (If I understand properly).

---------- Post added at 08:06 AM ---------- Previous post was at 08:00 AM ----------

:D

_______________

Oh golly gee, comstar, I LOVE it! Thanks for elaborating. This made my morning!

I don't deserve that honor... I'm just a tinkerer. It's great though. Then again maybe it COULD be appropriate to put my initials after BLuFeNiX's because I'd definitely love following that skill and becoming as great as what was exhibited here. Very talented skill-set there, yep.

:D

---------- Post added at 08:51 AM ---------- Previous post was at 08:06 AM ----------

Okay, this SHOULD be in a different thread. So if there's a moderator here who does feel that way, I will not be offended if somebody moves things around. The reason why I'm adding it onto THIS thread is because it's in this thread that I posted the ROM that may be the cause of the problem.

BLuFeNiX, I don't know if you can help with this or not. But DANGER regarding using the ROM that I suggested above that actually DOES flash in the Azpen A700 using LiveSuit. I believe that it messed up the partitions. What I discovered is that whether I copy NANDD directly using dd or if I use the Uberizer to unpack the tgz file [EITHER way], I run out of space in NANDD. The effect was that /system/xbin does not get created. That means that you can't do anything that affects system at all. You can't even copy /system/sbin/busybox to /system/. There are no bytes left on NANDD at all.

So I looked at /proc/partitions -- and to my horror....

| major minor #blocks name

|

| 93 0 26384 nanda

| 93 8 16384 nandb

| 93 16 32768 nandc

| 93 24 524288 nandd

| 93 32 1228800 nande

| 93 40 16384 nandf

| 93 48 32768 nandg

| 93 56 262144 nandh

| 93 64 262144 nandi

| 93 72 1448176 nandj

| 179 0 31166976 mmcblk0

| 179 1 31165952 mmcblk0p1

Whereas the one on reddit shows:

| major minor #blocks name

|

| 93 0 16384 nanda

| 93 8 16384 nandb

| 93 16 32768 nandc

| 93 24 573440 nandd

| 93 32 1228800 nande

| 93 40 16384 nandf

| 93 48 32768 nandg

| 93 56 327680 nandh

| 93 64 262144 nandi

| 93 72 1343488 nandj

| 179 0 7561216 mmcblk0

| 179 1 7557120 mmcblk0p1

So /bootloader (NANDA) is now unnecessarily larger?

And /env (NANDB) and /boot (NANDC) are the same.

But /system (NANDD) is definitely smaller now. BIG PROBLEM.

Then /data (NANDE), /misc (NANDF) and /recovery (NANDG) are the same.

But then /cache (NANDH) is smaller again. And I forgot to point out to you that my "dd" to nandH did indeed fail as well. (Bad "me"). Since it was just "cache", I thought nothing of it and formatted it anyway.

NANDI and NANDJ also ended up smaller.

I did a quick look to see if there is a newbie-approach way to resize these partitions, but they all seemed to be in definitions within ROM creations. I am actually becoming a tinkerer, starting here, in the hopes to be able to do JUST that, but I am in NO way there yet -- not even started. I'm just thrilled to be able to get started by being a set of eyes on your project.

CAN... my partitions be fixed? I went ahead and reflashed the ICS ROM since I seem to be locked into it now. (I wasn't aware of that last night because I didn't play around with the JellyBean enough to discover that /system was maxed out and deficient of key files.

I will keep on looking... but I'm quite sure that if I want to brick this thing for REAL, then tinkering with partitions without having the slightest clue what you're doing is definitely the way to do it. I'm not capable of recovering for a REAL brick... no knowledge or skill in this partitioning or creating your own ROM thing yet at all.

Do you think that maybe you can suggest a cure for it.

OH -- and as I introduced this post for any others who would follow my suggestion regarding the ICS ROM that I quoted above: DON'T DO IT unless you're willing to lose the original partitioning! (Thus losing the ability to put the stock JellyBean back on correctly).

-- David :rolleyes: