[Verizon] Still Stuicking @ Boot Animation - LogCat.

[gapi]

Believe me boys and girls I have tried every way in and out, front and backwards and finally got a logcat file.

Maybe one of you can see the mess I have and tell me how to clean it up.

Thanks

 

[iowabowtech]

what's with all those data/dalvik-cache errors? If you're able to boot in any way shape or form gapi, use root explorer to see if you are truly missing that folder.

Also, can you give a synapsis of what the problem is and what all you've tried again (sorry, i know you've told the story many times).

 

[gapi]

what's with all those data/dalvik-cache errors? If you're able to boot in any way shape or form gapi, use root explorer to see if you are truly missing that folder.

Also, can you give a synapsis of what the problem is and what all you've tried again (sorry, i know you've told the story many times).

I have tried every wipe method, flash, recovery, JB ROM, and some off the wall mad hatter methods. ADB, Wugs, you name it. Finally I run a log.

 

[jova33]

Go back to stock?

 

[iowabowtech]

If memory serves, you have no problem flashing anything ICS? And this only happens on JB right or no?

 

[iowabowtech]

What's interesting to me is all the supposed missing directories. Almost points toward a mounting issue. I think it'd be interesting to see what's actually showing up in a shell. Without a booting phone, you'll want to do this from inside recovery gapi. Here is my file structure and permissions, how do yours compare paying special attention to /data and /system?

Boot into recovery, then don't select any options. With phone plugged into pc run:

adb shell
ls -l

 

[gapi]

If memory serves, you have no problem flashing anything ICS? And this only happens on JB right or no?

Yes I can flash any ISC ROM. And my Logcat for them is a whole different animal.

What's interesting to me is all the supposed missing directories. Almost points toward a mounting issue. I think it'd be interesting to see what's actually showing up in a shell. Without a booting phone, you'll want to do this from inside recovery gapi. Here is my file structure and permissions, how do yours compare paying special attention to /data and /system?

Boot into recovery, then don't select any options. With phone plugged into pc run:

adb shell
ls -l

This?


C:\android-sdk-windows\platform-tools>adb devices
List of devices attached
014682870Cxxxxxx recovery


C:\android-sdk-windows\platform-tools>adb shell
ls -l~ #
ls -l
drwxr-xr-x 2 root root 0 Sep 5 21:11 boot
drwxrwx--x 4 system cache 4096 Sep 5 21:04 cache
-rwxr-x--- 1 root root 245720 Jan 1 1970 charger
drwxr-xr-x 3 root root 0 Sep 5 21:11 data
drwxr-xr-x 2 root root 0 Sep 5 21:11 datadata
-rw-r--r-- 1 root root 2631 Jan 1 1970 default.prop
drwxr-xr-x 11 root root 1640 Sep 5 21:11 dev
drwxr-xr-x 2 root root 0 Sep 5 21:11 emmc
drwxr-xr-x 2 root root 0 Sep 5 21:11 etc
-rwxr-x--- 1 root root 98724 Jan 1 1970 init
-rwxr-x--- 1 root root 1415 Jan 1 1970 init.rc
dr-xr-xr-x 99 root root 0 Jan 1 1970 proc
drwxr-xr-x 3 root root 0 Jan 1 1970 res
drwx------ 2 root root 0 Jul 21 17:46 root
drwxr-x--- 2 root root 0 Jan 1 1970 sbin
drwxr-xr-x 2 root root 0 Sep 5 21:11 sd-ext
lrwxrwxrwx 1 root root 11 Sep 5 21:11 sdcard -> /data/media
drwxr-xr-x 15 root root 0 Sep 5 21:11 sys
drwxr-xr-x 3 root root 0 Jan 1 1970 system
drwxr-xr-x 2 root root 0 Sep 5 21:11 tmp
-rw-r--r-- 1 root root 272 Jan 1 1970 ueventd.goldfish.rc
-rw-r--r-- 1 root root 3825 Jan 1 1970 ueventd.rc
-rw-r--r-- 1 root root 1656 Jan 1 1970 ueventd.tuna.rc
~ #

 

[gapi]

That is the ICS ROM. You want me to do a JB attempt and run it there?

Here is my B38 logcat

 

[iowabowtech]

Yeah, I thought the log you posted in the OP was from a JB install and boot up effort. I'm not saying you should reinstall JB just for this, but if you ever do, I would be interested to see the output from the list command. And wouldn't mind seeing a secondary list from /data as well.

 

[gapi]

Yeah, I thought the log you posted in the OP was from a JB install and boot up effort. I'm not saying you should reinstall JB just for this, but if you ever do, I would be interested to see the output from the list command. And wouldn't mind seeing a secondary list from /data as well.

Here is the results of the command with the JB ROM after flashing and letting it boot loop for 10 minutes, then a battery pull, then into Recovery and the command entered.

Compare the beginning of the 2nd lines. ICS has another W

C:\android-sdk-windows\platform-tools>adb shell
ls -l~ #
ls -l
drwxr-xr-x 2 root root 0 Jan 1 00:00 boot
drwxr-xr-x 4 root root 4096 Sep 6 2012 cache
-rwxr-x--- 1 root root 245720 Jan 1 1970 charger
drwxr-xr-x 3 root root 0 Jan 1 00:00 data
drwxr-xr-x 2 root root 0 Jan 1 00:00 datadata
-rw-r--r-- 1 root root 2631 Jan 1 1970 default.prop
drwxr-xr-x 11 root root 1640 Jan 1 00:00 dev
drwxr-xr-x 2 root root 0 Jan 1 00:00 emmc
drwxr-xr-x 2 root root 0 Jan 1 00:00 etc
-rwxr-x--- 1 root root 98724 Jan 1 1970 init
-rwxr-x--- 1 root root 1415 Jan 1 1970 init.rc
dr-xr-xr-x 95 root root 0 Jan 1 1970 proc
drwxr-xr-x 3 root root 0 Jan 1 1970 res
drwx------ 2 root root 0 Jul 21 2012 root
drwxr-x--- 2 root root 0 Jan 1 1970 sbin
drwxr-xr-x 2 root root 0 Jan 1 00:00 sd-ext
lrwxrwxrwx 1 root root 11 Jan 1 00:00 sdcard -> /data/media
drwxr-xr-x 15 root root 0 Jan 1 00:00 sys
drwxr-xr-x 3 root root 0 Jan 1 1970 system
drwxr-xr-x 2 root root 0 Jan 1 00:00 tmp
-rw-r--r-- 1 root root 272 Jan 1 1970 ueventd.goldfish.rc
-rw-r--r-- 1 root root 3825 Jan 1 1970 ueventd.rc
-rw-r--r-- 1 root root 1656 Jan 1 1970 ueventd.tuna.rc
~ #

 

[iowabowtech]

What JB rom did you have on the phone for that last post?

 

[gapi]

What JB rom did you have on the phone for that last post?

AOKP Buil1.

 

[iowabowtech]

Ok, so here's my file structure on AOKP v1 in order to compare apples to apples:

To me, it seems interesting that no matter what rom I'm running, I have a /cache permission of 771 (rwxrwx--x)

You have the same permissions as me when running an ICS rom. However, as you noted, your /cache permissions change to 755 (rwxr-xr-x) on a JB rom so you are missing some write functionality. Knowing you've tried several JB roms, I'm assuming the same situation is occuring on all of them. In any event, you and I are now running the exact same rom on the exact same device and for whatever reason, we are experiencing different permissions on the /cache partition which seems quite strange to me.

Need to think about this one a little.

 

[gapi]

Thanks

 

[AndroidKris]

Would it be possible to chmod the /cache partition directly after flashing the rom?

 

[iowabowtech]

Would it be possible to chmod the /cache partition directly after flashing the rom?

Yes, he's able to enter a shell so it can be done.

My main question is why are his permissions different than my own, what could have caused that in an otherwise identical scenario? I know that Scary Alien has been watching this thread and I'm interested to see what insight he may have when time allows.

chmod -R 771 /cache

Is it the answer though? I have no idea.

 

[scary alien]

Hey guys! Yeah, I've been following this thread since I saw it very late last night...like I mentioned in PMs, I didn't have time to respond and today was pretty busy at work .

So, like I mentioned in my first PM to you gapi at the beginning of August, and iowabowtech's analysis, its pretty clean that it's some kind of filesystem issue. That sounds a little silly / obvious if you've looked at the logcats from gapi and from the XDA thread (JB boot loops my phone! - xda-developers) that there's something wonky going on where things aren't being initialized properly in a very early, key step.

Take a peek at the installd.c code posted here:

https://github.com/android/platform_frameworks_base/blob/master/cmds/installd/installd.c

You'll find the same "E/installd( 135): Could not create directories; exiting." error (which is seen in ALL of the logcats that folks with the JB bootloops have submitted) being generated at line 374 as a result of a negative return value from the initialize_directories() call, which does this:

int initialize_directories() {
    // [COLOR="Red"][B]/data/user[/B][/COLOR]
    char *user_data_dir = build_string2(android_data_dir.path, SECONDARY_USER_PREFIX);
    // [COLOR="red"][B]/data/data[/B][/COLOR]
    char *legacy_data_dir = build_string2(android_data_dir.path, PRIMARY_USER_PREFIX);
    // [COLOR="red"][B]/data/user/0[/B][/COLOR]
    char *primary_data_dir = build_string3(android_data_dir.path, SECONDARY_USER_PREFIX,
            "0");
    int ret = -1;
    if (user_data_dir != NULL && primary_data_dir != NULL && legacy_data_dir != NULL) {
        ret = 0;
 [COLOR="red"]       // Make the /data/user directory if necessary
        if (access(user_data_dir, R_OK) < 0) {
            if (mkdir(user_data_dir, 0711) < 0) {
                return -1;
            }
            if (chown(user_data_dir, AID_SYSTEM, AID_SYSTEM) < 0) {
                return -1;
            }
            if (chmod(user_data_dir, 0711) < 0) {
                return -1;
            }
        }[/COLOR]
        // Make the /data/user/0 symlink to /data/data if necessary
        if (access(primary_data_dir, R_OK) < 0) {
              ret = symlink(legacy_data_dir, primary_data_dir);
        }
        free(user_data_dir);
        free(legacy_data_dir);
        free(primary_data_dir);
    }
    return ret;
}

As you can see, /data is seemingly indeed the focus of this and access to and subdirectory creation are functions that must succeed in order for this function to have been a success (and is certainly the linchpin of many (many) things that follow in the boot/startup process.

Now, as to why this could be happening is still a big mystery. Like I relayed to gapi in my PMs early last month and that I've posted elsewhere, I had an inkling that it might be something related / similar to something I experienced first-hand:

- when I got my N7 (which has JB), I decided to root it before even doing a proper / standard first boot (i.e., after first power-on). So, I unlocked the bootloader, soft-booted CWM, and tried to push the su.zip over to /data/media (/sdcard) and then flash it. The problem was that /data/media didn't yet exist (oh, I also got several errors that you don't normally see when you start-up CWM). Anyway, I ended-up pushing and installing the su binary manually using /cache since I couldn't flash it like normal in CWM (I was really just being stubborn, LOL).

- I then did its first proper, normal boot into Android and saw that subsequent invocations of CWM worked like they always do and we expect

- my lesson from this: a first boot of Android is necessary to allow him to pre-create and initialize the filesystems that you expect to be there

- caveats from this: other folks have reported rooting their devices before doing the first boot without encountering these issues; I suppose that this is possible or their device had actually already been booted once before the did this (dunno for sure); or there's something else going on that I don't understand

Now, I still haven't had time to install JB on my GNex yet (and won't have time this weekend), but I wonder if it's a subtle difference in how folks are installing and/or booting-up their JB installs that is getting their filesystems properly created (and secured)?

I'll stop here and let you guys digest the above.

Thanks!

 

[gapi]

Thanks,

Now I'm beginning to think when Verizon rolls out JB it will not take. FYI I did not do a Root first boot.

Mercy!

 

[scary alien]

Thanks,

Now I'm beginning to think when Verizon rolls out JB it will not take. FYI I did not do a Root first boot.

Mercy!

Oh, I didn't mean to imply that was what you did...it was just an observation about how I think the boot / initialization process might work (or not) and what type of things might be causing your particular issue.

By the way, your bootloader is unlocked, correct?

I know that's an obvious question but since you can flash things with CWM while the bootloader is locked, I thought I'd ask (in case there are some aspects of the JB install that require an unlocked bootloader (I think you have to have flashed the JB version of the bootloader, right (done with fastbot))).

 

[iowabowtech]

So do you think the real crux of the failure then is occurring at lines 339-341? Failure to make directory for user data? And why does it work on 98% of phones but not on a few, that's what's so darn troubling?

So basically we're looking at code edits. :vroam:

 

[scary alien]

So do you think the real crux of the failure then is occurring at lines 339-341? Failure to make directory for user data? And why does it work on 98% of phones but not on a few, that's what's so darn troubling?

So basically we're looking at code edits. :vroam:

Oh, no, I'm guessing that the issue / problem happens before installd is called. The filesystems and mount points are created / done in the init process, so that's the likely culprit.

Don't know if anyone's gotten a kernel dev involved in looking at this problem--I'm betting they'd certainly be able to narrow the focus at least.

 

[gapi]

I sent a request for help to Imoseyon, the Lean Kernel DEV. I hope he responds.

 

[scary alien]

I sent a request for help to Imoseyon, the Lean Kernel DEV. I hope he responds.

Nice!

That the kernel I previously had flashed when I was using AOKP (before my bricking and new device). I love his philosophy for his kernels .

At the very least, he might be able to point us in the direction of a ROM dev maybe if its not something that he thinks is kernel related.

 

[jova33]

You bricked a nexus? How?

 

[scary alien]

You bricked a nexus? How?

Powered it down, wouldn't turn back on.



I tried six ways from Sunday to resurrect it...wasn't doing anything to it.

I shut it down because I was going to reboot it in fastboot mode to read the information off of the screen (was about to help someone with the information I was going to read-off).

Did the shutdown, it asked for confirmation, it kind of froze / pixelated what was remaining on the screen (it never finished shutting down). I did a battery pull and tried to restart.

Nothing. No response at all. Tried a different battery, etc. Zilch.

VZW sent me a replacement under warranty. I was pretty stunned and stumped.