udev auto-mount not doing fsck

udev auto-mount not doing fsck

[Brian Hutchinson]

Hi,

I have a custom board that has a eUSB NAND attached (its a little circuit
board with a header Micron e230).

With the udev-extraconf package installed, udev looks like it automatically
mounts my device via the automount.rules (calling mount.sh) on boot.

I'd like udev to fsck this device before it auto mounts it.  Should I just
make or modify a udev rule to get this behavior or is there already another
package out there I'm missing that already has rules to do this that I can
use?  Don't want to reinvent the wheel if I'm just missing something.

The eUSB NAND has an ext4 filesystem on it but I'm starting to see some
corruption ... possibly from the journal getting messed up from too many
improper shutdowns etc.

Regards,

Brian

<http://layers.openembedded.org/layerindex/recipe/629/>

Re: udev auto-mount not doing fsck

[Brian Hutchinson]

OK an update.  I decided to stub the automount.rules for the moment to try
and get things working the old way and I'm seeing some curious behavior.
The target is running Yocto 1.5 so it is a fairly recent distro.

I made an entry in /etc/fstab for my eUSB with the sixth column set to 2.
On reboot fsck doesn't run.  Hmmm, curious.  I still see the:

EXT4-fs (sda1): warning: maximal mount count reached, running e2fsck is
recommended
EXT4-fs (sda1): mounted filesystem with ordered data mode. Opts: (null)

... messages at boot.

So I do touch /forcefsck and reboot.   Same result.
shutdown -rF ... same result.

I can't figure out why none of these methods is checking my eUSB drive.

Regards,

Brian



On Wed, Apr 9, 2014 at 4:53 PM, Brian Hutchinson <b.hutchman@gmail.com>wrote:

> Hi,
>
> I have a custom board that has a eUSB NAND attached (its a little circuit
> board with a header Micron e230).
>
> With the udev-extraconf package installed, udev looks like it
> automatically mounts my device via the automount.rules (calling mount.sh)
> on boot.
>
> I'd like udev to fsck this device before it auto mounts it.  Should I
> just make or modify a udev rule to get this behavior or is there already
> another package out there I'm missing that already has rules to do this
> that I can use?  Don't want to reinvent the wheel if I'm just missing
> something.
>
> The eUSB NAND has an ext4 filesystem on it but I'm starting to see some
> corruption ... possibly from the journal getting messed up from too many
> improper shutdowns etc.
>
> Regards,
>
> Brian
>
> <http://layers.openembedded.org/layerindex/recipe/629/>
>

Re: udev auto-mount not doing fsck

[Koen Kooi]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Brian Hutchinson schreef op 10-04-14 15:10:
> OK an update.  I decided to stub the automount.rules for the moment to
> try and get things working the old way and I'm seeing some curious
> behavior. The target is running Yocto 1.5 so it is a fairly recent
> distro.
> 
> I made an entry in /etc/fstab for my eUSB with the sixth column set to
> 2. On reboot fsck doesn't run.  Hmmm, curious.  I still see the:
> 
> EXT4-fs (sda1): warning: maximal mount count reached, running e2fsck is 
> recommended EXT4-fs (sda1): mounted filesystem with ordered data mode.
> Opts: (null)
> 
> ... messages at boot.
> 
> So I do touch /forcefsck and reboot.   Same result. shutdown -rF ... same
> result.
> 
> I can't figure out why none of these methods is checking my eUSB drive.

To ask the obvious question: is fsck.ext{2,3,4} present on your system?

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.5 (Darwin)
Comment: GPGTools - http://gpgtools.org

iD8DBQFTRq9RMkyGM64RGpERAoV7AJ41jAQXvVid86l2Ntdeb7eR91H19wCcDx2I
y+BA/pyMjlOg2C+S8p5/lHM=
=36Lo
-----END PGP SIGNATURE-----

Re: udev auto-mount not doing fsck

[Brian Hutchinson]

On Thu, Apr 10, 2014 at 10:48 AM, Koen Kooi <koen@dominion.thruhere.net>wrote:

> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Brian Hutchinson schreef op 10-04-14 15:10:
> > OK an update.  I decided to stub the automount.rules for the moment to
> > try and get things working the old way and I'm seeing some curious
> > behavior. The target is running Yocto 1.5 so it is a fairly recent
> > distro.
> >
> > I made an entry in /etc/fstab for my eUSB with the sixth column set to
> > 2. On reboot fsck doesn't run.  Hmmm, curious.  I still see the:
> >
> > EXT4-fs (sda1): warning: maximal mount count reached, running e2fsck is
> > recommended EXT4-fs (sda1): mounted filesystem with ordered data mode.
> > Opts: (null)
> >
> > ... messages at boot.
> >
> > So I do touch /forcefsck and reboot.   Same result. shutdown -rF ... same
> > result.
> >
> > I can't figure out why none of these methods is checking my eUSB drive.
>
> To ask the obvious question: is fsck.ext{2,3,4} present on your system?
>
>
Hey Koen,

Yes, I have the complete e2fsprogs package in the rootfs so I have e2fsck
etc.

I just did some tests where I modified the existing mount.sh to run fsck
first (which busybox passes through and calls the real e2fsck) an so using
udev rules with some ENV{ID_} type commands to identify my eUSB and then
call my "special" mount script via RUN appears to work so I guess I'll have
to continue going that route .... which is in keeping with the new udev way
of doing things.

I was just kind of puzzled as to why the older methods didn't work ... not
that I have ran into this kind of thing before.  Usually I'm using a raw
NOR or NAND and with a filesystem that deals with the FTL ... this is my
first time using a mass storage device that handles all the ECC, leveling
etc. behind the scenes and pretends to be a disk.

Regards,

Brian

Re: udev auto-mount not doing fsck

[Denys Dmytriyenko]

On Thu, Apr 10, 2014 at 11:12:22AM -0400, Brian Hutchinson wrote:
> On Thu, Apr 10, 2014 at 10:48 AM, Koen Kooi <koen@dominion.thruhere.net>wrote:
> 
> > -----BEGIN PGP SIGNED MESSAGE-----
> > Hash: SHA1
> >
> > Brian Hutchinson schreef op 10-04-14 15:10:
> > > OK an update.  I decided to stub the automount.rules for the moment to
> > > try and get things working the old way and I'm seeing some curious
> > > behavior. The target is running Yocto 1.5 so it is a fairly recent
> > > distro.
> > >
> > > I made an entry in /etc/fstab for my eUSB with the sixth column set to
> > > 2. On reboot fsck doesn't run.  Hmmm, curious.  I still see the:
> > >
> > > EXT4-fs (sda1): warning: maximal mount count reached, running e2fsck is
> > > recommended EXT4-fs (sda1): mounted filesystem with ordered data mode.
> > > Opts: (null)
> > >
> > > ... messages at boot.
> > >
> > > So I do touch /forcefsck and reboot.   Same result. shutdown -rF ... same
> > > result.
> > >
> > > I can't figure out why none of these methods is checking my eUSB drive.
> >
> > To ask the obvious question: is fsck.ext{2,3,4} present on your system?
> >
> >
> Hey Koen,
> 
> Yes, I have the complete e2fsprogs package in the rootfs so I have e2fsck
> etc.
> 
> I just did some tests where I modified the existing mount.sh to run fsck
> first (which busybox passes through and calls the real e2fsck) an so using
> udev rules with some ENV{ID_} type commands to identify my eUSB and then
> call my "special" mount script via RUN appears to work so I guess I'll have
> to continue going that route .... which is in keeping with the new udev way
> of doing things.
> 
> I was just kind of puzzled as to why the older methods didn't work ... not
> that I have ran into this kind of thing before.  Usually I'm using a raw
> NOR or NAND and with a filesystem that deals with the FTL ... this is my
> first time using a mass storage device that handles all the ECC, leveling
> etc. behind the scenes and pretends to be a disk.

Brian,

Be careful, with your eUSB storage device cold-plugged (available on boot) 
you may run into a race condition, if you initially mount your rootfs in 
read-only mode and then re-mount in read-write mode during boot. One of the 
proposed solutions:

http://thread.gmane.org/gmane.comp.handhelds.openembedded.core/50124

-- 
Denys

Re: udev auto-mount not doing fsck

[Brian Hutchinson]

On Thu, Apr 10, 2014 at 12:56 PM, Denys Dmytriyenko <denis@denix.org> wrote:

> Brian,
>
> Be careful, with your eUSB storage device cold-plugged (available on boot)
> you may run into a race condition, if you initially mount your rootfs in
> read-only mode and then re-mount in read-write mode during boot. One of the
> proposed solutions:
>
> http://thread.gmane.org/gmane.comp.handhelds.openembedded.core/50124
>
> --
> Denys
> --
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-devel
>

At the moment the rootfs is rw in NOR.  In the future I plan for it to be
squashfs (ro) with a union overlay that is rw ubifs for persistent stuff.
This is to help protect the rootfs from getting corrupted or accidentally
hosed up during an update etc.

So I could see where the race condition you mentioned could happen maybe in
that case but I'm not quite following (yet) how it could happen currently
in rw mode.  I guess you're saying there is a point where the rootfs could
be ro and so the udev rule has no mount point to hang the eUSB on ... If
I'm picking up what you're laying down ('if' being the key word :) )

This eUSB is intended to stay on the board at all times and not be hot
plugged ... but it is socketed (but board is buried in an enclosure) so it
could be replaced if needed by a technician.

I'll study that patch you mentioned more when I get some time (in SCRUM
meeting at the time ... joy).

Regards,

Brian

Re: udev auto-mount not doing fsck

[Brian Hutchinson]

On Thu, Apr 10, 2014 at 2:00 PM, Brian Hutchinson <b.hutchman@gmail.com>wrote:

> On Thu, Apr 10, 2014 at 12:56 PM, Denys Dmytriyenko <denis@denix.org>wrote:
>
>> Brian,
>>
>> Be careful, with your eUSB storage device cold-plugged (available on boot)
>> you may run into a race condition, if you initially mount your rootfs in
>> read-only mode and then re-mount in read-write mode during boot. One of
>> the
>> proposed solutions:
>>
>> http://thread.gmane.org/gmane.comp.handhelds.openembedded.core/50124
>>
>> --
>> Denys
>> --
>> _______________________________________________
>> Openembedded-devel mailing list
>> Openembedded-devel@lists.openembedded.org
>> http://lists.openembedded.org/mailman/listinfo/openembedded-devel
>>
>
> At the moment the rootfs is rw in NOR.  In the future I plan for it to be
> squashfs (ro) with a union overlay that is rw ubifs for persistent stuff.
> This is to help protect the rootfs from getting corrupted or accidentally
> hosed up during an update etc.
>
> So I could see where the race condition you mentioned could happen maybe
> in that case but I'm not quite following (yet) how it could happen
> currently in rw mode.  I guess you're saying there is a point where the
> rootfs could be ro and so the udev rule has no mount point to hang the eUSB
> on ... If I'm picking up what you're laying down ('if' being the key word
> :) )
>
> This eUSB is intended to stay on the board at all times and not be hot
> plugged ... but it is socketed (but board is buried in an enclosure) so it
> could be replaced if needed by a technician.
>
> I'll study that patch you mentioned more when I get some time (in SCRUM
> meeting at the time ... joy).
>
> Regards,
>
> Brian
>
>
Hi Denys,

OK, I see what you are talking about now.  In my /etc/fstab I do have sixth
column of root set to 1 so if I'm understanding things right
/etc/rcS.d/S10checkroot.sh could be off checking root mounted ro while udev
sees my eUSB and is in the process of doing RUN mount.sh and trying to
mount /media/sda1 (in my case) before rootfs is remounted back rw.

Ah, I also see that /forcefsck only checks root ... for some reason I was
thinking it would cause fsck to look at fstab and scan all filesystems in
order of sixth column but that doesn't appear to be the case ... so that
answers one of my questions.

I still don't know why my eUSB wasn't checked when I stubbed out udev
automount script and instead added it to fstab with a 2 in the sixth column
... I thought that should of worked but it didn't.  It did in fact mount my
eUSB but it did not check it.  The answer to that too is probably in one of
these rcS scripts that I just haven't seen yet.

So the patch you mentioned is making more sense now.

Let me know if I'm tracking now or still off in the weeds.

Regards,

Brian

Re: udev auto-mount not doing fsck

[Denys Dmytriyenko]

On Thu, Apr 10, 2014 at 05:47:02PM -0400, Brian Hutchinson wrote:
> On Thu, Apr 10, 2014 at 2:00 PM, Brian Hutchinson <b.hutchman@gmail.com>wrote:
> 
> > On Thu, Apr 10, 2014 at 12:56 PM, Denys Dmytriyenko <denis@denix.org>wrote:
> >
> >> Brian,
> >>
> >> Be careful, with your eUSB storage device cold-plugged (available on boot)
> >> you may run into a race condition, if you initially mount your rootfs in
> >> read-only mode and then re-mount in read-write mode during boot. One of
> >> the
> >> proposed solutions:
> >>
> >> http://thread.gmane.org/gmane.comp.handhelds.openembedded.core/50124
> >>
> >> --
> >> Denys
> >> --
> >> _______________________________________________
> >> Openembedded-devel mailing list
> >> Openembedded-devel@lists.openembedded.org
> >> http://lists.openembedded.org/mailman/listinfo/openembedded-devel
> >>
> >
> > At the moment the rootfs is rw in NOR.  In the future I plan for it to be
> > squashfs (ro) with a union overlay that is rw ubifs for persistent stuff.
> > This is to help protect the rootfs from getting corrupted or accidentally
> > hosed up during an update etc.
> >
> > So I could see where the race condition you mentioned could happen maybe
> > in that case but I'm not quite following (yet) how it could happen
> > currently in rw mode.  I guess you're saying there is a point where the
> > rootfs could be ro and so the udev rule has no mount point to hang the eUSB
> > on ... If I'm picking up what you're laying down ('if' being the key word
> > :) )
> >
> > This eUSB is intended to stay on the board at all times and not be hot
> > plugged ... but it is socketed (but board is buried in an enclosure) so it
> > could be replaced if needed by a technician.
> >
> > I'll study that patch you mentioned more when I get some time (in SCRUM
> > meeting at the time ... joy).
> >
> > Regards,
> >
> > Brian
> >
> >
> Hi Denys,
> 
> OK, I see what you are talking about now.  In my /etc/fstab I do have sixth
> column of root set to 1 so if I'm understanding things right
> /etc/rcS.d/S10checkroot.sh could be off checking root mounted ro while udev
> sees my eUSB and is in the process of doing RUN mount.sh and trying to
> mount /media/sda1 (in my case) before rootfs is remounted back rw.

Even w/o checking the rootfs, it's common to boot off of read-only FS and then 
remount it r/w slightly later - that's what checkroot.sh initscript is doing.

Unfortunately, udev starts slightly earlier than that and starts enumerating 
peripherals and firing its rules, including the auto-mount one, which can fail 
to create the necessary mount point. We had that happening intermittently, 
hence the proposed solution...


> Ah, I also see that /forcefsck only checks root ... for some reason I was
> thinking it would cause fsck to look at fstab and scan all filesystems in
> order of sixth column but that doesn't appear to be the case ... so that
> answers one of my questions.
> 
> I still don't know why my eUSB wasn't checked when I stubbed out udev
> automount script and instead added it to fstab with a 2 in the sixth column
> ... I thought that should of worked but it didn't.  It did in fact mount my
> eUSB but it did not check it.  The answer to that too is probably in one of
> these rcS scripts that I just haven't seen yet.
> 
> So the patch you mentioned is making more sense now.
> 
> Let me know if I'm tracking now or still off in the weeds.
> 
> Regards,
> 
> Brian
> -- 
> _______________________________________________
> Openembedded-devel mailing list
> Openembedded-devel@lists.openembedded.org
> http://lists.openembedded.org/mailman/listinfo/openembedded-devel