The problem is that mountd treats EBUSY as a no error condition. When you have mmcblk0p2 mounted and you try to mount mmcblk0, then you get an EBUSY which it then thinks it successfully finished. It prevents the logic to check partitions from kicking in and nothing gets mounted.
Mike Lockwood wrote: > Changing mountd.conf to mount mmcblk0p1 is a fine workaround for your > problem, but won't work as a general solution. In particular, it will > not work with SD cards that have a FAT file system starting at the > first sector (with no partition map at all). > > I think the real problem is somewhere in mountd. Could you enable > mountd logging by turning on ENABLE_LOG_MOUNT and ENABLE_LOG_SERVER in > mountd.h and send me a logcat? Send me a dmesg too. Then I might be > able to figure out a better solution. > > thanks, > Mike > > On Wed, Nov 19, 2008 at 5:48 PM, Jay Freeman (saurik) <[EMAIL PROTECTED]> > wrote: > >> Ok, I've got it!!! I had to change "mmcblk0" to "mmcblk0p1" in >> /etc/mountd.conf. This will probably fix Maxime's problem as well. >> >> I have uploaded this change to Gerrit at: >> http://review.source.android.com/r/7507ee976e1c >> >> For the record, in case this clarifies things, here is complete order of >> events I was experiencing before I made that change: >> >> 1) boot device >> 2) notice that /sdcard mounted fine >> 3) plug in USB cable >> 4) select "mount" from USB notification >> 5) notice that /sdcard correctly unmounted >> 6) unplug USB cable >> 7) /sdcard is immediately remounted >> 8) repeat steps 3-7 a few times to verify sanity >> >> Ok, so far, so good. This is what I expect from an un-messed with device. >> >> 9) plug in USB cable >> 10) mount /dev/block/mmcblk0p2 to /mnt (we now have:) >> /dev/block/mmcblk0p1 /sdcard vfat rw,dirsync,... 0 0 >> /dev/block/mmcblk0p2 /mnt ext2 rw,errors=continue 0 0 >> 11) select "mount" from USB notification >> 12) notice that /sdcard correctly unmounted >> 13) unplug USB cable >> 14) wait and wait and wait... no /sdcard >> >> This is not what I expected, and maid me frowny pants. :( >> >> 15) plug in USB cable (for adb shell) >> 16) unmount /mnt >> 17) unplug USB cable >> 18) still no /sdcard >> >> It was this part I wasn't expecting even going into this e-mail, which made >> me think that maybe I should go seriously scan over the mountd configuration >> to make certain it wasn't broken (and it was). Yay! >> >> Sincerely, >> Jay Freeman (saurik) >> [EMAIL PROTECTED] >> http://www.saurik.com/ >> >> -------------------------------------------------- >> From: "Mike Lockwood" <[EMAIL PROTECTED]> >> Sent: Tuesday, November 18, 2008 4:48 PM >> To: <android-porting@googlegroups.com> >> Subject: [android-porting] Re: Filesystems (yaffs2, jffs2 and nfs) >> >> >>> If you boot from the SD card, do you have the files /dev/block/mmcblk0 >>> and /dev/block/mmcblk0p1? If those files are missing, then mountd >>> will not attempt to mount the SD card. >>> >>> You might want to turn on: >>> >>> #define ENABLE_LOG_MOUNT >>> #define ENABLE_LOG_SERVER >>> >>> in system/core/mountd/mountd.h to enable some extra logcat diagnostics >>> in mountd so you can see what's going on. >>> >>> Mike >>> >>> On Tue, Nov 18, 2008 at 6:52 PM, Jay Freeman (saurik) <[EMAIL PROTECTED]> >>> wrote: >>> >>>> In my experience, using any part of the SD card makes /sdcard not work. >>>> Example: if, after the system has already booted up and /sdcard is >>>> mounted, >>>> I mount a second partition off the SD card, everything is fine until I >>>> next >>>> need /sdcard to mount. Specifically, if I plug in the USB cable it works, >>>> if >>>> I ask the G1 to mount over USB that even works (and /sdcard is >>>> unmounted), >>>> but when I unplug the USB cable nothing happens: I need to unmount my >>>> second >>>> partition to get Android to understand that the card isn't in use >>>> anymore. >>>> Maybe its doing something like checking the number of active usages of >>>> the >>>> base card rather than the one partition it wants or something (or maybe >>>> its >>>> something weird in mountd: I haven't even looked into how /sdcard works >>>> yet). -J >>>> >>>> -------------------------------------------------- >>>> From: "Maxime Petazzoni" <[EMAIL PROTECTED]> >>>> Sent: Tuesday, November 18, 2008 3:00 PM >>>> To: "android-porting" <android-porting@googlegroups.com> >>>> Subject: [android-porting] Re: Filesystems (yaffs2, jffs2 and nfs) >>>> >>>> >>>>> I may have a similar problem here. I'm trying to run Android entirely >>>>> off the SD card (actually, microSD, on the Zoom). I made three >>>>> partitions : >>>>> >>>>> - /dev/mmcblk0p1, vfat, 1G, to be mounted as /sdcard for media data >>>>> - /dev/mmcblk0p2, msdos, 10M, to host the uImage for U-Boot (i could >>>>> have put it on the first partition, but here it's hidden from the >>>>> user) >>>>> - /dev/mmcblk0p3, ext3, 1.99G, to be mounted as the entire Android >>>>> root filesystem >>>>> >>>>> Using the following bootargs : 'console=ttyS2,115200n8 ip=none rw >>>>> rootwait root=/dev/mmcblk0p3 init=/init' and the following bootcmd : >>>>> 'mmcinit;fatload mmc 0:2 0x81600000 uImage;bootm 0x81600000'. The >>>>> system boots and runs fine, but there's nothing mounted in /sdcard. >>>>> >>>>> Did you ever got something similar ? How did you get the sdcard to be >>>>> mounted by Android when not using NFS root ? When booting from NFS >>>>> with the card already inserted, it works and /dev/block/mmcblk0p1 gets >>>>> mounted as /sdcard. >>>>> >>>>> Thanks, >>>>> - Maxime >>>>> >>>>> On Nov 11, 7:15 am, "Misael Lopez" <[EMAIL PROTECTED]> wrote: >>>>> >>>>>>> What I did for that is >>>>>>> to split the sdcard into 2 partitions: fat for user data like music, >>>>>>> videos, etc, and ext3 for the /data partition. >>>>>>> >>>>>> Did you do something else apart from creating/formatting the >>>>>> partitions? I tried the >>>>>> same but Music application never accepted the card (even it the fat >>>>>> partition is >>>>>> mounted manually/automatically), it complained about SD card not >>>>>> mounted. >>>>>> >>>>>> Misa >>>>>> >>>>>> 2008/11/11 Sean McNeil <[EMAIL PROTECTED]>: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>> mvniekerk wrote: >>>>>>> >>>>>>>> Well, I can help you with this much - jffs2 + Android = No Go. It >>>>>>>> will >>>>>>>> >>>>>>> Not true. Android runs perfectly on the Openmoko Freerunner using >>>>>>> JFFS2 >>>>>>> for root and system. You need to qualify your statement as the only >>>>>>> real >>>>>>> partition that needs mmap is the /data partition. What I did for that >>>>>>> is >>>>>>> to split the sdcard into 2 partitions: fat for user data like music, >>>>>>> videos, etc, and ext3 for the /data partition. >>>>>>> >>>>>>>> run a few apps until the actual zygote stuff needs to run. mmap is >>>>>>>> the >>>>>>>> thing that will screw you over - you only get mmap with read only >>>>>>>> jffs2. >>>>>>>> yaffs2 + NOR = No Go. It will fall over and flop. >>>>>>>> UBIFS + NOR + Android = Works well actually. Got it running on our >>>>>>>> iMX31 board with NOR. I'll post some instructions to get UBIFS >>>>>>>> working >>>>>>>> if you need it. UBIFS = JFFS3. It has compression and a lot of other >>>>>>>> cool stuff. It also scales well. >>>>>>>> >>>>>>>> On Nov 10, 4:10 pm, Markus <[EMAIL PROTECTED]> wrote: >>>>>>>> >>>>>>>>> Hi, >>>>>>>>> >>>>>>>>> yes, we might change to a different file system, but actually, >>>>>>>>> Android >>>>>>>>> uses yaffs2 as main file system or at least it seems like this if >>>>>>>>> you >>>>>>>>> hack into its configuration files. To be honest, we do not know, if >>>>>>>>> this problem is caused by the file system or something else as we >>>>>>>>> are >>>>>>>>> able to do file operations in /data/app during the booting process. >>>>>>>>> The kernel panic occurs after Android finished the booting process. >>>>>>>>> So >>>>>>>>> our guess is that Android starts something, that watches the file >>>>>>>>> system (especially /data/app) and that this service is causing our >>>>>>>>> problem. Unfortunately, we could not yet locate, which tool is >>>>>>>>> responsible... any guess, what is started in the end of the booting >>>>>>>>> process, that might cause our problem? >>>>>>>>> >>>>>>>>> Below, a log of the kernel panic. >>>>>>>>> >>>>>>>>> Bye >>>>>>>>> Markus >>>>>>>>> >>>>>>>>> busybox cp ApiDemos.apk test >>>>>>>>> Unable to handle kernel paging request at virtual address 00100104 >>>>>>>>> pgd = c70a4000 >>>>>>>>> [00100104] *pgd=870a2031, *pte=857180dd, *ppte=8571880e >>>>>>>>> Internal error: Oops: 81f [#1] PREEMPT >>>>>>>>> Modules linked in: >>>>>>>>> CPU: 0 Not tainted (2.6.24-140-g68eb4b4 #77) >>>>>>>>> PC is at android_unlock_suspend+0x60/0x170 >>>>>>>>> LR is at android_unlock_suspend+0x34/0x170 >>>>>>>>> pc : [<c01ff8b4>] lr : [<c01ff888>] psr: 60000193 >>>>>>>>> sp : c711bea8 ip : c039bac4 fp : c711bee4 >>>>>>>>> r10: c711a000 r9 : 000001e0 r8 : 60000113 >>>>>>>>> r7 : c7de20a0 r6 : c039babc r5 : c039babc r4 : c7de20e0 >>>>>>>>> r3 : c7c35da8 r2 : 00100100 r1 : 00200200 r0 : c7de20e0 >>>>>>>>> Flags: nZCv IRQs off FIQs on Mode SVC_32 ISA ARM Segment user >>>>>>>>> Control: 00e5387f Table: 870a4000 DAC: 00000015 >>>>>>>>> Process FileObserver (pid: 1675, stack limit = 0xc711a260) >>>>>>>>> Stack: (0xc711bea8 to 0xc711c000) >>>>>>>>> bea0: c710401c c7cfac40 c711bed4 c711bec0 c00603cc >>>>>>>>> c006035c >>>>>>>>> bec0: c73dc3c0 00000000 c73dc3d0 c7de20a0 c73dc3c0 c711a000 >>>>>>>>> c711befc >>>>>>>>> c711bee8 >>>>>>>>> bee0: c00c4f90 c01ff860 c73dc3c0 46a2cba4 c711bf4c c711bf00 >>>>>>>>> c00c57d0 >>>>>>>>> c00c4f30 >>>>>>>>> bf00: c003f92c 46a2cb84 c7cfac70 00000000 c7cfac40 c005b298 >>>>>>>>> c711bf18 >>>>>>>>> c711bf18 >>>>>>>>> bf20: c02bfa58 c7043ea0 46a2cb84 c711bf78 00000200 c0025004 >>>>>>>>> c711a000 >>>>>>>>> 41046fc0 >>>>>>>>> bf40: c711bf74 c711bf50 c00961a4 c00c5634 c711bf74 c711bf60 >>>>>>>>> c7043ea0 >>>>>>>>> fffffff7 >>>>>>>>> bf60: 00000000 00000000 c711bfa4 c711bf78 c00965ec c00960fc >>>>>>>>> 00000000 >>>>>>>>> 00000000 >>>>>>>>> bf80: 001ce0b0 00000001 00000f4c ad352cd8 001cf5b8 00000003 >>>>>>>>> 00000000 >>>>>>>>> c711bfa8 >>>>>>>>> bfa0: c0024e80 c00965b4 00000f4c ad352cd8 0000001e 46a2cb84 >>>>>>>>> 00000200 >>>>>>>>> fd1fafed >>>>>>>>> bfc0: 00000f4c ad352cd8 001cf5b8 00000003 46a2cda0 41046fd4 >>>>>>>>> 41046fc0 >>>>>>>>> 00000001 >>>>>>>>> bfe0: ad353458 46a2cb48 ad3414c9 afe0b50c 00000010 0000001e >>>>>>>>> 00ff00ff >>>>>>>>> 00ff00ff >>>>>>>>> Backtrace: >>>>>>>>> [<c01ff854>] (android_unlock_suspend+0x0/0x170) from [<c00c4f90>] >>>>>>>>> (remove_kevent+0x6c/0x94) >>>>>>>>> [<c00c4f24>] (remove_kevent+0x0/0x94) from [<c00c57d0>] >>>>>>>>> (inotify_read >>>>>>>>> +0x1a8/0x1e4) >>>>>>>>> r4:46a2cba4 >>>>>>>>> [<c00c5628>] (inotify_read+0x0/0x1e4) from [<c00961a4>] (vfs_read >>>>>>>>> +0xb4/0x144) >>>>>>>>> [<c00960f0>] (vfs_read+0x0/0x144) from [<c00965ec>] (sys_read >>>>>>>>> +0x44/0x70) >>>>>>>>> r7:00000000 r6:00000000 r5:fffffff7 r4:c7043ea0 >>>>>>>>> [<c00965a8>] (sys_read+0x0/0x70) from [<c0024e80>] >>>>>>>>> (ret_fast_syscall >>>>>>>>> +0x0/0x2c) >>>>>>>>> r7:00000003 r6:001cf5b8 r5:ad352cd8 r4:00000f4c >>>>>>>>> Code: e5965000 e5812000 e5843000 e59c3000 (e5821004) >>>>>>>>> Kernel panic - not syncing: Fatal exception >>>>>>>>> >>>>>>>>> On 9 Nov., 10:16, mvniekerk <[EMAIL PROTECTED]> wrote: >>>>>>>>> >>>>>>>>>> Your answer lies in UBIFS. There is a port for kernel 2.6.24 up to >>>>>>>>>> 2.6.27. UBIFS is JFFS3 if you like - and it does support mmap. If >>>>>>>>>> your >>>>>>>>>> flash chip is of the NOR-type then YAFFS2 will not work - that is >>>>>>>>>> what >>>>>>>>>> makes UBIFS so sweet! >>>>>>>>>> To set up a UBI volume for UBIFS is bit of a schlep, but once done >>>>>>>>>> it >>>>>>>>>> is a cool piece of equipment. >>>>>>>>>> >>>>>>>>>> On Nov 6, 11:39 pm, Markus <[EMAIL PROTECTED]> wrote: >>>>>>>>>> >>>>>>>>>>> Hi, >>>>>>>>>>> >>>>>>>>>>> it is the init process, that cannot start. The kernel is always >>>>>>>>>>> booting fine and only the Android init process is not able to do >>>>>>>>>>> its >>>>>>>>>>> job. For yaffs2, the booting process stops like >>>>>>>>>>> inhttp://groups.google.com/group/android-porting/browse_thread/thread/d... >>>>>>>>>>> - I'm sorry, that I can't post my own message at the moment, but >>>>>>>>>>> I >>>>>>>>>>> do >>>>>>>>>>> not have access to the hardware right now to flash everything... >>>>>>>>>>> >>>>>>>>>>> Like in the link above, we get the same problem about the magic >>>>>>>>>>> number, while Android tries to load the core.jar file. After 4 >>>>>>>>>>> tries, >>>>>>>>>>> Android resigns and reboots. >>>>>>>>>>> >>>>>>>>>>> bye >>>>>>>>>>> Markus >>>>>>>>>>> >>>>>>>>>>> On 6 Nov., 17:22, "Gergely Kis" <[EMAIL PROTECTED]> wrote: >>>>>>>>>>> >>>>>>>>>>>> Hi, >>>>>>>>>>>> >>>>>>>>>>>> Could you give more information regarding "Android was not able >>>>>>>>>>>> to >>>>>>>>>>>> boot onyaffs2". What were the actual error messages? Did the >>>>>>>>>>>> kernel >>>>>>>>>>>> hang, or the init process? >>>>>>>>>>>> >>>>>>>>>>>> Best Regards, >>>>>>>>>>>> Gergely >>>>>>>>>>>> >>>>>>>>>>>> On Thu, Nov 6, 2008 at 4:18 PM, Markus <[EMAIL PROTECTED]> wrote: >>>>>>>>>>>> >>>>>>>>>>>>> Hi, >>>>>>>>>>>>> >>>>>>>>>>>>> as I wrote in Android Internals, we ported Android to an >>>>>>>>>>>>> i.MX31. >>>>>>>>>>>>> Unfortunately, we have some issues with the file system. >>>>>>>>>>>>> If I use NFS as file system with a modified init.rc config, >>>>>>>>>>>>> everything >>>>>>>>>>>>> seems to work well, but this is no option for us as permanent >>>>>>>>>>>>> file >>>>>>>>>>>>> system, so we decided to useyaffs2as file system. As this did >>>>>>>>>>>>> not >>>>>>>>>>>>> work (Android was not able to boot), we changed to jffs2. jffs2 >>>>>>>>>>>>> boots >>>>>>>>>>>>> fine as long as we use a read-only file system. After booting, >>>>>>>>>>>>> we >>>>>>>>>>>>> can >>>>>>>>>>>>> start many applications, but it seems that those requiring file >>>>>>>>>>>>> write >>>>>>>>>>>>> operations fail to start, e.g. the webbrowser. If we change >>>>>>>>>>>>> init.rc >>>>>>>>>>>>> config to give file-write permissions, Android is not able to >>>>>>>>>>>>> boot >>>>>>>>>>>>> anymore. >>>>>>>>>>>>> >>>>>>>>>>>>> So we have decided to use a mixture ofyaffs2and jffs2, after we >>>>>>>>>>>>> saw >>>>>>>>>>>>> this idea at the armv4 port. The basic idea is, that all mmap >>>>>>>>>>>>> operations are done onyaffs2, as jffs2 does not support them. >>>>>>>>>>>>> At >>>>>>>>>>>>> the >>>>>>>>>>>>> moment, we split the file system to two parts: /data is located >>>>>>>>>>>>> on our >>>>>>>>>>>>> yaffs2partition, everything else on our jffs2 partition. The >>>>>>>>>>>>> system >>>>>>>>>>>>> boots fine and we can run every application. But now, it is >>>>>>>>>>>>> getting >>>>>>>>>>>>> confusing: As soon as Android has finished booting, it is >>>>>>>>>>>>> impossible >>>>>>>>>>>>> to write/delete files in /data/app - if we do, we get a kernel >>>>>>>>>>>>> panic, >>>>>>>>>>>>> which reports FileObserver to fail. This does not happen, if we >>>>>>>>>>>>> do >>>>>>>>>>>>> file accesses before Android has finished its booting process. >>>>>>>>>>>>> >>>>>>>>>>>>> Remembering that we had some cases, in which it was necessary >>>>>>>>>>>>> to >>>>>>>>>>>>> start >>>>>>>>>>>>> the system with strace running in the background (and >>>>>>>>>>>>> discarding >>>>>>>>>>>>> the >>>>>>>>>>>>> log), I booted theyaffs2/jffs2 system with strace in the >>>>>>>>>>>>> background. >>>>>>>>>>>>> Now, I am able to access files in /data/app, I just get >>>>>>>>>>>>> "syscall: >>>>>>>>>>>>> unknown syscall trap 0xe1a00000" reported to my debug console. >>>>>>>>>>>>> In >>>>>>>>>>>>> this >>>>>>>>>>>>> mode, it is also possible to run applications directly from >>>>>>>>>>>>> Eclipse on >>>>>>>>>>>>> the target device. >>>>>>>>>>>>> >>>>>>>>>>>>> So can anybody tell me what is going wrong, if I use >>>>>>>>>>>>> ayaffs2only >>>>>>>>>>>>> file system? And why does strace heal those problems with >>>>>>>>>>>>> ayaffs2/ >>>>>>>>>>>>> jffs2 system? It just makes the system slower... >>>>>>>>>>>>> >>>>>>>>>>>>> bye >>>>>>>>>>>>> Markus >>>>>>>>>>>>> >>> >>> -- >>> Mike Lockwood >>> Google android team >>> >>> > > > > --~--~---------~--~----~------------~-------~--~----~ unsubscribe: [EMAIL PROTECTED] website: http://groups.google.com/group/android-porting -~----------~----~----~----~------~----~------~--~---
