From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from bear.ext.ti.com (bear.ext.ti.com [192.94.94.41]) by arago-project.org (Postfix) with ESMTPS id 0CCE05299E for ; Tue, 3 Dec 2013 00:20:07 +0000 (UTC) Received: from dlelxv90.itg.ti.com ([172.17.2.17]) by bear.ext.ti.com (8.13.7/8.13.7) with ESMTP id rB30K6cm024812 for ; Mon, 2 Dec 2013 18:20:06 -0600 Received: from DFLE72.ent.ti.com (dfle72.ent.ti.com [128.247.5.109]) by dlelxv90.itg.ti.com (8.14.3/8.13.8) with ESMTP id rB30K5sM018571 for ; Mon, 2 Dec 2013 18:20:06 -0600 Received: from dflp33.itg.ti.com (10.64.6.16) by DFLE72.ent.ti.com (128.247.5.109) with Microsoft SMTP Server id 14.2.342.3; Mon, 2 Dec 2013 18:20:05 -0600 Received: from [172.22.128.202] (dbdp20.itg.ti.com [172.24.170.38]) by dflp33.itg.ti.com (8.14.3/8.13.8) with ESMTP id rB30K1p7031809; Mon, 2 Dec 2013 18:20:03 -0600 Message-ID: <529D23C8.2080305@ti.com> Date: Mon, 2 Dec 2013 19:20:24 -0500 From: Tom Rini Organization: Texas Instruments User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/17.0 Thunderbird/17.0 MIME-Version: 1.0 To: "Cooper Jr., Franklin" References: <1385135121-14345-1-git-send-email-fcooper@ti.com> <1385135121-14345-5-git-send-email-fcooper@ti.com> <20131122200029.GT420@bill-the-cat> <8F29D6B095ED194EA1980491A5E029710C5C059E@DFLE08.ent.ti.com> <20131123021545.GV420@bill-the-cat>, <20131202213126.GB17528@denix.org> <3EDB709B-9073-4B52-A2D6-827AFBBF658A@ti.com> In-Reply-To: <3EDB709B-9073-4B52-A2D6-827AFBBF658A@ti.com> X-Enigmail-Version: 1.6 X-Mailman-Approved-At: Wed, 11 Dec 2013 18:45:31 +0000 Cc: "meta-arago@arago-project.org" Subject: Re: [PATCH 5/6] mount-sdcard: Update to use new udev entry X-BeenThere: meta-arago@arago-project.org X-Mailman-Version: 2.1.12 Precedence: list List-Id: Arago metadata layer for TI SDKs - OE-Core/Yocto compatible List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Tue, 03 Dec 2013 00:20:07 -0000 Content-Type: text/plain; charset="ISO-8859-1" Content-Transfer-Encoding: 7bit On 12/02/2013 06:23 PM, Cooper Jr., Franklin wrote: > > >> On Dec 2, 2013, at 3:31 PM, "Dmytriyenko, Denys" wrote: >> >>> On Fri, Nov 22, 2013 at 09:15:45PM -0500, Tom Rini wrote: >>>> On Fri, Nov 22, 2013 at 10:27:06PM +0000, Cooper Jr., Franklin wrote: >>>> >>>> >>>>> -----Original Message----- >>>>> From: Tom Rini [mailto:tom.rini@gmail.com] On Behalf Of Rini, Tom >>>>> Sent: Friday, November 22, 2013 2:00 PM >>>>> To: Cooper Jr., Franklin >>>>> Cc: meta-arago@arago-project.org >>>>> Subject: Re: [meta-arago] [PATCH 5/6] mount-sdcard: Update to use new udev >>>>> entry >>>>> >>>>>> On Fri, Nov 22, 2013 at 09:45:20AM -0600, Franklin S. Cooper Jr wrote: >>>>>> >>>>>> * Patch 1c1b695310309ec3526f1b6b415c5e1b74a567e1 added a udev >>>>> entry to >>>>>> automatically mount sd card partition. >>>>>> * For some reason that udev entry isn't automatically ran. >>>>>> * As a workaround manually trigger udev to run twice (not sure why thats >>>>> needed) >>>>>> for the udev rule to run correctly. >>>>>> >>>>>> Signed-off-by: Franklin S. Cooper Jr >>>>> >>>>> This issn't right. Have you added debugging steps to the mount.sh script? >>>>> We're saying, with this change "lets trigger all block devices 3 times", and on the >>>>> 3rd attempt we finally do mount things. I've seen some partitions NOT be auto- >>>>> mounted due to being dirty and needing an fsck prior to mounting them. If we >>>>> need to do this type of change at the end as a "we can't figure out the root >>>>> cause, but we need to release", OK. >>>>> But I don't think we're there yet. Thanks! >> >>>> [Franklin] Just to give an update it looks like fsck is required to be ran >>>> to fix this problem however it wouldn't be safe to run fsck and let it >>>> auto fix the problem since that could cause potential issues. So if fsck >>>> is really the proper solution then I'm not sure that would work for >>>> something that needs to automatically work at bootup. >>> >>> Well, dirty cards shouldn't be auto-mounted. Or there's some option to >>> mount we should be passing to say "no, it's OK". >> >> So, what is the agreement here? I don't think forcing fsck for mounting a card >> is a good idea. I agree with Tom that if the card is dirty (could be corrupted), >> then user intervention is required anyway. >> >> I'm planning on skipping these 2 patches, if nobody objects. > We need to figure this out but feel free to skip the patches. Well, lets step back. Did we confirm that the problem is that it's dirty (in which case, trying to mount it N times should give N failures, not "3rd time is the charm!") or just that fsck'ing one particular card fixed that part of the card that wasn't mounting (but the rest of it was?) or what? -- Tom