• After 15+ years, we've made a big change: Android Forums is now Early Bird Club. Learn more here.

[Verizon] Still Stuicking @ Boot Animation - LogCat.

What jumps out at you between those two SA? I think it could be a factor that JB is formatting all of /system whereas ICS rom does not.

Well, I suspect what you're going to say:

ICS snippet:

format("ext4", "EMMC", "/dev/block/platform/omap/omap_hsmmc.0/by-name/system", "0");
mount("ext4", "EMMC", "/dev/block/platform/omap/omap_hsmmc.0/by-name/system", "/system");

vs.

JB snippet:

format("ext4", "EMMC", "/dev/block/platform/omap/omap_hsmmc.0/by-name/system", "0", "/system");
mount("ext4", "EMMC", "/dev/block/platform/omap/omap_hsmmc.0/by-name/system", "/system");

is the difference in the JB format command, right?

edit: you ninja'd an edit on me while I was looking at the pastebins ;) :).
 
You're going to have to lead this horse to water. Where do I find the init.rc file?

edit: Lulz. Nvm, that's what I get for doing this stuff from work. Incoming.

edit2: i have several of them. you want just the init.rc or the others too. also have goldfish, trace, tuna, tuna.usb, .usb...all .rc files.
 
You're going to have to lead this horse to water. Where do I find the init.rc file?

Oh, sorry, they're right there in the root (/) directory on your phone:

Code:
C:\Users\Scary Alien>[B][COLOR="Blue"]adb shell[/COLOR][/B]
shell@android:/ $ [COLOR="blue"][B]su[/B][/COLOR]
su
shell@android:/ # [COLOR="blue"][B]ls -a -l[/B][/COLOR]
ls -a -l
drwxr-xr-x root   root        2012-09-12 23:58 acct
drwxrwx--- system cache       2012-09-13 22:00 cache
-rwxr-x--- root   root 240612 1969-12-31 19:00 charger
dr-x------ root   root        2012-09-12 23:58 config
lrwxrwxrwx root   root        2012-09-12 23:58 d -> /sys/kernel/debug
drwxrwx--x system system      2012-09-12 23:58 data
-rw-r--r-- root   root    116 1969-12-31 19:00 default.prop
drwxr-xr-x root   root        2012-09-12 23:58 dev
lrwxrwxrwx root   root        2012-09-12 23:58 etc -> /system/etc
drwxrwxr-x radio  radio       1999-12-31 19:00 factory
-rwxr-x--- root   root  98676 1969-12-31 19:00 init
[COLOR="Blue"]-rwxr-x--- root   root   2344 1969-12-31 19:00 init.goldfish.rc
-rwxr-x--- root   root   1324 1969-12-31 19:00 init.omap4pandaboard.rc
-rwxr-x--- root   root  17105 1969-12-31 19:00 init.rc
-rwxr-x--- root   root   6989 1969-12-31 19:00 init.tuna.rc
-rwxr-x--- root   root   3532 1969-12-31 19:00 init.tuna.usb.rc[/COLOR]
drwxrwxr-x root   system      2012-09-12 23:58 mnt
dr-xr-xr-x root   root        1969-12-31 19:00 proc
drwxr-xr-x root   root        1969-12-31 19:00 res
drwx------ root   root        2012-04-13 14:34 root
drwxr-x--- root   root        1969-12-31 19:00 sbin
lrwxrwxrwx root   root        2012-09-12 23:58 sdcard -> /mnt/sdcard
drwxr-xr-x root   root        2012-09-12 23:58 sys
drwxr-xr-x root   root        2012-09-12 23:50 system
[COLOR="Blue"]-rw-r--r-- root   root    272 1969-12-31 19:00 ueventd.goldfish.rc
-rw-r--r-- root   root   3825 1969-12-31 19:00 ueventd.rc
-rw-r--r-- root   root   1656 1969-12-31 19:00 ueventd.tuna.rc[/COLOR]
lrwxrwxrwx root   root        2012-09-12 23:58 vendor -> /system/vendor
shell@android:/ #

Oh, and I've never looked at the ueventd.*rc files, but if you can snag those, too, that would be great! :)
 
I'm at work and I'm not sure if I'll get this done before heading home. If not, I'll continue when I get home and get them posted to pastebin and linked in a single thread.

No hurry, my friend! It's no big deal.

I should probably try to avoid another late night and try to get some zzz's, so I'm not likely to be able to any serious analysis anyway.

Appreciate your help with this!

Thanks!
 
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...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.

^^Quoting myself from post #13 of this thread as a primer.


init.rc - Pastebin.com

Code:
Line 48: 
mkdir /cache 0771 system cache

Code:
Lines 124-126:
# We chown/chmod /cache again so because mount is run as root + defaults
chown system cache /cache
chmod 0771 /cache

Seems like gapi is having an issue at or before line 126. Not saying there couldn't be problems after that, but something is not working for him to end up with 755 while I get the desired and intended 771.
 
Guys, I'm about to start 3 days of 12 hour shifts, 5AM-5PM and will be listening and answering questions but will not be able to do any full blown flashing until Monday night. Please don't let up.

GAPI

This has been an elusive problem that has been documented on every android related forum on the interwebs. Frankly, it's almost a vendetta at this point. And well...


(that, and I needed some background music while reviewing this code) :p
 
IBT,

I gave the /data partition permission thing a little more thought and I've come to realize that we're probably chasing the wrong rabbit here, or at least not properly identifying the permission issue correctly.

So, the deal is that the /data partition or filesystem that gapi is seeing in custom recovery is simply the directory before the partition / filesystem is mounted.

I'm pretty sure that if gapi repeated his boot loop test and re-entered CWM to bring-up an adb shell, that if he went to the "mounts and storage" submenu and mounted the /data partition, he'd most likely see that the /data partition has the correct permissions (771) and would be owned by system/system as you see being indicated by the init.rc file and how it looks under a normally-boot Android ICS system, too (it does on mine).

So, the things you see while booted-up in ClockworkMod are actually a ramdisk filesystem that's created by the kernel packed into the CWM bootable image file--there are precious few filesystems that are mounted in-common with normal Android in a custom recovery (for good reason: you don't want things changing while performing the various scary options from within a custom recovery).

A confirmation of the above from gapi would be helpful just to see if in-fact we're seeing the JB init.rc being properly executed.

I'll keep thinking about this, but I think we might have to search elsewhere other than a permissions issue and/or the init.rc path.

Cheers!
 
IBT,

I gave the /data partition permission thing a little more thought and I've come to realize that we're probably chasing the wrong rabbit here, or at least not properly identifying the permission issue correctly.

So, the deal is that the /data partition or filesystem that gapi is seeing in custom recovery is simply the directory before the partition / filesystem is mounted.

I'm pretty sure that if gapi repeated his boot loop test and re-entered CWM to bring-up an adb shell, that if he went to the "mounts and storage" submenu and mounted the /data partition, he'd most likely see that the /data partition has the correct permissions (771) and would be owned by system/system as you see being indicated by the init.rc file and how it looks under a normally-boot Android ICS system, too (it does on mine).

So, the things you see while booted-up in ClockworkMod are actually a ramdisk filesystem that's created by the kernel packed into the CWM bootable image file--there are precious few filesystems that are mounted in-common with normal Android in a custom recovery (for good reason: you don't want things changing while performing the various scary options from within a custom recovery).

A confirmation of the above from gapi would be helpful just to see if in-fact we're seeing the JB init.rc being properly executed.

I'll keep thinking about this, but I think we might have to search elsewhere other than a permissions issue and/or the init.rc path.

Cheers!

Definitely agree that data shouldn't be mounted in recovery but in my case anyway, cache was mounted. That's why I had mentioned he should unmount cache prior to running the e2fsck command.

Important tip though...when you get into recovery, use the "mounts and storage" option in clockwork and select the option to unmount cache. e2fsck won't run on a mounted partition so the 2nd command above would fail unless this is done.

The cache partition seems to be the one that gapi is not seeing the correct permissions (maybe it was data also, not sure). I guess I would like to see gapi boot into recovery, go to mounts and storage and see if the cache partition is already mounted or not. If so, unmount it and try the e2fsck commands in post #61. Maybe that'll give us some clues?
 
I think post #61 on your window may be different than mine. I see no commands there........ but if

"ls -l /dev/block/platform/omap/omap_hsmmc.0/by-name/" iswhat you mean....

Cache was mounted, I unmounted and ran the above............

If I need to run something different lemme know.

Code:
C:\android-sdk-windows\platform-tools>adb shell
~ # ls -l /dev/block/platform/omap/omap_hsmmc.0/by-name/
ls -l /dev/block/platform/omap/omap_hsmmc.0/by-name/ls -l /dev/block/platform/om
ap/omap_hsmmc.0/by-name/
lrwxrwxrwx    1 root     root            20 Sep 19 02:20 boot -> /dev/block/mmcb
lk0p7
lrwxrwxrwx    1 root     root            21 Sep 19 02:20 cache -> /dev/block/mmc
blk0p11
lrwxrwxrwx    1 root     root            20 Sep 19 02:20 dgs -> /dev/block/mmcbl
k0p6
lrwxrwxrwx    1 root     root            20 Sep 19 02:20 efs -> /dev/block/mmcbl
k0p3
lrwxrwxrwx    1 root     root            21 Sep 19 02:20 metadata -> /dev/block/
mmcblk0p13
lrwxrwxrwx    1 root     root            20 Sep 19 02:20 misc -> /dev/block/mmcb
lk0p5
lrwxrwxrwx    1 root     root            20 Sep 19 02:20 param -> /dev/block/mmc
blk0p4
lrwxrwxrwx    1 root     root            20 Sep 19 02:20 radio -> /dev/block/mmc
blk0p9
lrwxrwxrwx    1 root     root            20 Sep 19 02:20 recovery -> /dev/block/
mmcblk0p8
lrwxrwxrwx    1 root     root            20 Sep 19 02:20 sbl -> /dev/block/mmcbl
k0p2
lrwxrwxrwx    1 root     root            21 Sep 19 02:20 system -> /dev/block/mm
cblk0p10
lrwxrwxrwx    1 root     root            21 Sep 19 02:20 userdata -> /dev/block/
mmcblk0p12
lrwxrwxrwx    1 root     root            20 Sep 19 02:20 xloader -> /dev/block/m
mcblk0p1
~ #
 
Sorry, that is my ISC ROM, flashing a JB ROM now, gimme time. Igf I need to run a different command tell me in the mean time.
 
The JB

When I select unmount it changes to mount, but if I do a "Go Back" and return it shows "Unmount" again, just sayin. So I choose unmount cache and let it sit and do the command line.

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


C:\android-sdk-windows\platform-tools>adb shell
~ # ls -l /dev/block/platform/omap/omap_hsmmc.0/by-name/
ls -l /dev/block/platform/omap/omap_hsmmc.0/by-name/


Code:
lrwxrwxrwx    1 root     root            20 Jan  1 00:00 boot -> /dev/block/mmcb
lk0p7
lrwxrwxrwx    1 root     root            21 Jan  1 00:00 cache -> /dev/block/mmc
blk0p11
lrwxrwxrwx    1 root     root            20 Jan  1 00:00 dgs -> /dev/block/mmcbl
k0p6
lrwxrwxrwx    1 root     root            20 Jan  1 00:00 efs -> /dev/block/mmcbl
k0p3
lrwxrwxrwx    1 root     root            21 Jan  1 00:00 metadata -> /dev/block/
mmcblk0p13
lrwxrwxrwx    1 root     root            20 Jan  1 00:00 misc -> /dev/block/mmcb
lk0p5
lrwxrwxrwx    1 root     root            20 Jan  1 00:00 param -> /dev/block/mmc
blk0p4
lrwxrwxrwx    1 root     root            20 Jan  1 00:00 radio -> /dev/block/mmc
blk0p9
lrwxrwxrwx    1 root     root            20 Jan  1 00:00 recovery -> /dev/block/
mmcblk0p8
lrwxrwxrwx    1 root     root            20 Jan  1 00:00 sbl -> /dev/block/mmcbl
k0p2
lrwxrwxrwx    1 root     root            21 Jan  1 00:00 system -> /dev/block/mm
cblk0p10
lrwxrwxrwx    1 root     root            21 Jan  1 00:00 userdata -> /dev/block/
mmcblk0p12
lrwxrwxrwx    1 root     root            20 Jan  1 00:00 xloader -> /dev/block/m
mcblk0p1
~ #
 
I mounted /data and ran "ls -l /dev/block/platform/omap/omap_hsmmc.0/by-name/" and got..........


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


C:\android-sdk-windows\platform-tools>adb shell
~ # ls -l /dev/block/platform/omap/omap_hsmmc.0/by-name/
ls -l /dev/block/platform/omap/omap_hsmmc.0/by-name/
Code:
lrwxrwxrwx    1 root     root            20 Jan  1 00:00 boot -> /dev/block/mmcb
lk0p7
lrwxrwxrwx    1 root     root            21 Jan  1 00:00 cache -> /dev/block/mmc
blk0p11
lrwxrwxrwx    1 root     root            20 Jan  1 00:00 dgs -> /dev/block/mmcbl
k0p6
lrwxrwxrwx    1 root     root            20 Jan  1 00:00 efs -> /dev/block/mmcbl
k0p3
lrwxrwxrwx    1 root     root            21 Jan  1 00:00 metadata -> /dev/block/
mmcblk0p13
lrwxrwxrwx    1 root     root            20 Jan  1 00:00 misc -> /dev/block/mmcb
lk0p5
lrwxrwxrwx    1 root     root            20 Jan  1 00:00 param -> /dev/block/mmc
blk0p4
lrwxrwxrwx    1 root     root            20 Jan  1 00:00 radio -> /dev/block/mmc
blk0p9
lrwxrwxrwx    1 root     root            20 Jan  1 00:00 recovery -> /dev/block/
mmcblk0p8
lrwxrwxrwx    1 root     root            20 Jan  1 00:00 sbl -> /dev/block/mmcbl
k0p2
lrwxrwxrwx    1 root     root            21 Jan  1 00:00 system -> /dev/block/mm
cblk0p10
lrwxrwxrwx    1 root     root            21 Jan  1 00:00 userdata -> /dev/block/
mmcblk0p12
lrwxrwxrwx    1 root     root            20 Jan  1 00:00 xloader -> /dev/block/m
mcblk0p1
~ #
 
Ahhh, my fault. We probably have different settings for # of posts to be displayed per page. :D

I was referring to this one:


iowabowtech-albums-my-pics-picture6770-e2fsck.jpg
 
gapi,

I think we just need the output of the following commands:

# cd /
# ls -a -l
# mount

If you do this before its mounted and after its mounted, it should show use how and if the permissions and ownership changes.

Thanks!

edit: LOL, ninja'd by IBT...forgot he wanted the e2fsck output (good stuff!)
 
With cache mounted

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

Code:
C:\android-sdk-windows\platform-tools>adb shell
~ # cd /
cd /
~ # ls -a -l
ls -a -l
drwxr-xr-x   17 root     root             0 Jan  1 00:05 .
drwxr-xr-x   17 root     root             0 Jan  1 00:05 ..
-rw-rw-rw-    1 root     root             0 Jan  1 00:05 adb
drwxr-xr-x    2 root     root             0 Jan  1 00:00 boot
drwxr-xr-x    4 root     root          4096 Sep 19  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
~ #

This is with unmounted Cache

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

C:\android-sdk-windows\platform-tools>adb shell
~ # cd /
cd /
~ # ls -a -l
ls -a -l
drwxr-xr-x   17 root     root             0 Jan  1 00:05 .
drwxr-xr-x   17 root     root             0 Jan  1 00:05 ..
-rw-rw-rw-    1 root     root             0 Jan  1 00:05 adb
drwxr-xr-x    2 root     root             0 Jan  1 00:00 boot
drwxr-xr-x    2 root     root             0 Jan  1 00:00 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   94 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
~ #

I don't understand when or why to run the mount command. I am not as versed as you guys on this.

I ran the commands, copied and pasted the results. Then closed the command window and changed the mount status on the phone and opened another command window and ran them again.

Sometimes I need some hand holding if I have never ran it before.
 
Check out all the epoch times in there...Jan 1, 1970, 00:00.

Sorry guys, been busy with some "other" things and haven't given this thread the proper attention this evening.

I certainly think you are on to something again with this IBT...I believe that this is showing-up like this because the date/timestamp field probably has a value of zero. The "(in milliseconds since the UNIX epoch: January 1, 1970 00:00:00 UTC)" referenced in this thread: android - Posted notifications showing date 'Thu, 1 Jan 1970' after a while - Stack Overflow (that thread is not really relevant to the issue at-hand, but simply had a good explanation of the epoch time handling that I've read about before).

I'll keep searching re. this...
 
Sometimes I need some hand holding if I have never ran it before.

No problem. SA and I were asking for 2 different things. You already did one of them in your last post so thanks. I am asking you to do another and the commands are in the screenshot I reposted:

iowabowtech-albums-my-pics-picture6770-e2fsck.jpg


The arrows I drew in show the commands and you can see the output afterward which is clean on both accounts.

Important tip though...when you get into recovery, use the "mounts and storage" option in clockwork and select the option to unmount cache. e2fsck won't run on a mounted partition so the 2nd command above would fail unless this is done.

I'm not sure if any of the other partitions can be checked in this fashion or if they even contain the proper format for this tool but I've checked data and cache on other devices in this way so I was good with trying those. Not so much on the rest though as I'm out of my comfort zone.

So in a nutshell, boot in to recovery. Go to mounts & storage. Unmount cache. Then run the commands listed in that screenshot which are these:

adb shell
e2fsck -n /dev/block/mmcblk0p12

That should output a few lines. Then run the next command:

e2fsck -n /dev/block/mmcblk0p11

Again, should output a few lines. Now please post that cmd session so we can see what it said. What we are doing here is checking the /data and /cache partitions for bad sectors/blocks. If the above commands do indicate bad blocks, its possible that we may be able to fix them. Remember the old chkdsk (check disk) in Windows? It's basically the same kind of thing we're doing here but we're checking a linux filesystem so the tool (e2fsck) is slightly different. That will give us an idea of the integrity of /data and /cache.
 
Yeah, IBT, you're convincing me more and more what I'm guessing the e2fsck might find: bad blocks.

That might explain the "E/installd( 135): Could not create directories; exiting." error gapi (and others) see early on in their logcat and the weird zero (1970 date values bizarrely reported).

Perhaps the ICS installations don't need or use the blocks in question that JB does (although I think gapi's tried using various versions of JB ROMs out there--which would indicate that its a feature that is common to ALL JB ROMs if gapi is experiencing it consistently).

I'm actually hoping that e2fsck does indeed report some bad blocks since it would give us something to explain this and possibly fix/repair.

:)
 
Perhaps the ICS installations don't need or use the blocks in question that JB does (although I think gapi's tried using various versions of JB ROMs out there--which would indicate that its a feature that is common to ALL JB ROMs if gapi is experiencing it consistently).

Exactly what I was thinking.

I'm actually hoping that e2fsck does indeed report some bad blocks since it would give us something to explain this and possibly fix/repair.

I'm with you all the way.
 
I went to bed on you guys last night. Those 12 hr shifts took a toll. I'll post the request today.

GAPI - Next Time I'll Say Goodnight.
 
Just for clarification sake....

Wiped data/factory reset, cache partition, Dalvik.
JB Boot loader already there.
Flashed AOKP JB1 & GAPPS.
Booted to the looping animation.
Battery pull.
Booted into CWR v6.0.1.0 (Not Touch)

Found Cache already mounted and ran a session and pasted it in.
Closed session and unmounted cache.
Opened new session and pasted the results.

I have a serious $ donation $ for the kind soul who fixes this issue :smokingsomb:

With cache unmounted

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


C:\android-sdk-windows\platform-tools>adb shell
~ # e2fsck -n /dev/block/mmcblk0p12
e2fsck -n /dev/block/mmcblk0p12
e2fsck 1.41.12 (17-May-2010)
/dev/block/mmcblk0p12: clean, 6437/1875968 files, 999996/7493115 blocks
~ # e2fsck -n /dev/block/mmcblk0p11
e2fsck -n /dev/block/mmcblk0p11
e2fsck 1.41.12 (17-May-2010)
/dev/block/mmcblk0p11: clean, 15/27648 files, 3587/110592 blocks
~ #
With Cache mounted


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


C:\android-sdk-windows\platform-tools>adb shell
~ # e2fsck -n /dev/block/mmcblk0p12
e2fsck -n /dev/block/mmcblk0p12
e2fsck 1.41.12 (17-May-2010)
/dev/block/mmcblk0p12: clean, 6437/1875968 files, 999996/7493115 blocks
~ # e2fsck -n /dev/block/mmcblk0p11
e2fsck -n /dev/block/mmcblk0p11
e2fsck 1.41.12 (17-May-2010)
e2fsck: Device or resource busy while trying to open /dev/block/mmcblk0p11
Filesystem mounted or opened exclusively by another program?
~ #


Thanks!
 
Back
Top Bottom