[poky] Warning - don't use eCryptFS
Bruce Ashfield
bruce.ashfield at gmail.com
Tue Nov 30 08:05:02 PST 2010
On Tue, Nov 30, 2010 at 10:05 AM, Paul Eggleton
<paul.eggleton at linux.intel.com> wrote:
> Hi all,
>
> FYI I recently had some fairly serious problems with poky and the "encrypted home directory" function in Ubuntu, which uses eCryptFS. Problems I experienced included:
On a similar note, I've had plenty of experience with ocfs2 and it
not working with git. Some limited debugging a few months ago
showed it to be missing support for some extended file system
attributes. Very opaque build errors will result if you have this as
your host filesystem.
The reason that this is significant is that the kernel is build directly
out of a git repository, and during the clone and checkout, it
typically fails under ocfs2.
I haven't observed this recently, but this email reminded me that
I should at least float the warning.
Cheers,
Bruce
>
> * pseudo-native failing to write an sstate package ("file name too long" - apparently eCryptFS is limited to ~140 characters due to design limitations)
>
> * ncurses-native failing at do_install (some kind of interference with libtool that caused it to write an invalid path to the libncurses.la file, I didn't track down the exact cause as it went away when I stopped using eCryptFS. Might be indirectly related to the name length limitation.)
>
> Scott, could you please add a warning to the documentation not to use eCryptFS with poky? In particular, it should not be used to store TMPDIR and SSTATE_DIR.
>
> I'll follow up soon with a patch that will do a sanity check on the file name length limit - this will catch any other weird file systems that might cause these kinds of issues.
>
> Cheers,
> Paul
> _______________________________________________
> poky mailing list
> poky at yoctoproject.org
> https://lists.yoctoproject.org/listinfo/poky
>
--
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"
More information about the poky
mailing list