| Summary: | sstate install doesn't preserve extended attributes on files | ||
|---|---|---|---|
| Product: | [Build System, Metadata & Runtime] OE-Core | Reporter: | Joshua Lock <joshuagloe> |
| Component: | core | Assignee: | Joshua Lock <joshuagloe> |
| Status: | RESOLVED FIXED | QA Contact: | |
| Severity: | normal | ||
| Priority: | Medium+ | CC: | meta.mr.watcher, meta.watcher, ross.burton, sgw |
| Version: | 2.2 | ||
| Target Milestone: | 2.2 M3 | ||
| Hardware: | x86 | ||
| OS: | Multiple | ||
| Whiteboard: | |||
| OS type for building Yocto: | --- | Type of Regression: | --- |
| Verified: | Documentation change: | No (bug/feature does not impact docs) | |
| Bug Depends on: | 9317, 9929 | ||
| Bug Blocks: | 9858 | ||
|
Description
Joshua Lock
2016-06-30 14:09:02 UTC
Looking at "older" distros in SANITY_TESTED_DISTROS I see that: * Ubuntu 14.04 shipped tar 1.27.1 http://packages.ubuntu.com/trusty/tar * Debian 7 shipped tar 1.26 https://packages.debian.org/wheezy/tar * CentOS 6 shipped tar 1.23 http://mirror.centos.org/centos/6/os/x86_64/Packages/tar-1.23-14.el6.x86_64.rpm * Fedora 21 shipped tar 1.27.1 http://pkgs.fedoraproject.org/cgit/rpms/tar.git/tree/tar.spec?h=f21 Can you also fix image.bbclass to add the attr options to tar there? (and write a test case) (In reply to comment #2) > Can you also fix image.bbclass to add the attr options to tar there? > > (and write a test case) image_types.bbclass -- I'll fix that. I've got WIP some patches that update meta/classes/image_types.bbclass and meta/lib/oe/path.py to preserve extended attributes. Unfortunately on a system with SELinux not disabled (in this case, running in Permissive mode) a tar pipe call in copytree() and copyhardlinktree() fails when expanding the archive with: "Cannot open: Permission denied" If I disable SELinux on the host the build proceeds as usual and the extended attributes in my sstate objects are preserved when their contents are installed. An updated copyhardlinktree() requires a version of pseudo with the xattr semantics for hardlinks fixed -- setting "Depends on" to #9317 After banging my head against the "Cannot open: Permission denied" issue for far too long I took to #selinux on Freenode to seek advice, as the error only occurs when SELinux is enabled yet occurs regardless of whether SELinux is in Permissive or Enforcing mode. After performing various analysis of the involved files, etc we discovered that most files untar fine but that the ones that didn't all had a mode of --r--r--r. This didn't actually help us determine a root cause and the #selinux occupants were suspicious of tar itself. I am in the process of testing with bsdtar instead of gnu tar. With bsdtar this series works without issue, even on SELinux using systems. I'm not sure whether use of bsdtar will be an acceptable change, but I plan to make it conditional on the use of an "xattr" DISTRO_FEATURE before proposing patches for inclusion. Either way this change is blocked by the pseudo 1.8.1 slowdown with xattrs, reverting to pre 1.8.x pseudo isn't an option as they don't support xattrs on hardlinks and we rely on hardlinks during sstate install to minimise the disk impact. I wonder if GNU tar is detecting that selinux is enabled and changing its behaviour in some way. It would be interesting to replicate with just tar outside of OE/pseudo and see if strace shows any difference in behaviour with SELinux in permissive or disabled. Patches submitted to OE-Core to preserve xattr in oe.path.copytree(): http://lists.openembedded.org/pipermail/openembedded-core/2016-August/125933.html Patches merged |