On Thu, Apr 10, 2014 at 11:12:22AM -0400, Brian Hutchinson wrote: > On Thu, Apr 10, 2014 at 10:48 AM, Koen Kooi <k...@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 -- _______________________________________________ Openembedded-devel mailing list Openembedded-devel@lists.openembedded.org http://lists.openembedded.org/mailman/listinfo/openembedded-devel