Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 681866 - sys-apps/install-xattr does not enable large file support (LFS)
Summary: sys-apps/install-xattr does not enable large file support (LFS)
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Current packages (show other bugs)
Hardware: All Linux
: Normal normal (vote)
Assignee: Anthony Basile
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: lfs-tracker
  Show dependency tree
 
Reported: 2019-03-27 16:19 UTC by Nick Bowler
Modified: 2019-04-07 14:16 UTC (History)
1 user (show)

See Also:
Package list:
Runtime testing required: ---


Attachments
Add error messages and test case (install-xattr.patch,1.35 KB, patch)
2019-03-28 15:30 UTC, Nick Bowler
Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Nick Bowler 2019-03-27 16:19:04 UTC
Some packages call doexe directly on scripts in $FILESDIR; for example,
sys-devel/gcc does (via toolchain.eclass):

  exeinto "${DATAPATH#${EPREFIX}}"
  doexe "$(prefixify_ro "${FILESDIR}"/fix_libtool_files.sh)" || die
  doexe "${FILESDIR}"/c{89,99} || die

It seems any package which does something similar is failing, giving
this totally unhelpful error message:

 * ERROR: sys-devel/gcc-8.2.0-r6::gentoo failed (install phase):
 *   doexe failed

Looking at my logs, it seems the last time I was able to successfully
install gcc was version 7.3.0 in July 2018.  Not sure what exactly
what broke this in the interim (portage or eclass update?).

After tracking this down to FILESDIR, the problem is consistently
reproduced with a trivial ebuild (instead of waiting several hours for
gcc to compile...), so this seems to be a general problem rather than
something specific to gcc...

(PS: I had just started the 17.0 profile update when hitting this,
so since gcc failed the machine is currently halfway through the
associated CHOST change.  I was hitting this same problem on 13.0
too, with the old CHOST).

  % mkdir -p app-misc/filesdirfail/files
  % echo hello >app-misc/filesdirfail/files/hello
  % cat >app-misc/filesdirfail/filesdirfail-0.ebuild <<'EOF'
EAPI=7
SLOT="0"
S=$WORKDIR
src_install () {
	exeinto /bin
	doexe "$FILESDIR/hello"
}
EOF
  % ebuild app-misc/filesdirfail/filesdirfail-0.ebuild manifest install
>>> Creating Manifest for /srv/home/nbowler/repo/app-misc/filesdirfail
 * checking ebuild checksums ;-) ...                                                                          [ ok ]
 * checking auxfile checksums ;-) ...                                                                         [ ok ]
>>> Unpacking source...
>>> Source unpacked in /var/tmp/portage/app-misc/filesdirfail-0/work
>>> Preparing source in /var/tmp/portage/app-misc/filesdirfail-0/work ...
>>> Source prepared.
>>> Configuring source in /var/tmp/portage/app-misc/filesdirfail-0/work ...
>>> Source configured.
>>> Compiling source in /var/tmp/portage/app-misc/filesdirfail-0/work ...
>>> Source compiled.
>>> Test phase [not enabled]: app-misc/filesdirfail-0

>>> Install filesdirfail-0 into /var/tmp/portage/app-misc/filesdirfail-0/image category app-misc
 * ERROR: app-misc/filesdirfail-0::x-repo failed (install phase):
 *   doexe failed
 * 
 * If you need support, post the output of `emerge --info '=app-misc/filesdirfail-0::x-repo'`,
 * the complete build log and the output of `emerge -pqv '=app-misc/filesdirfail-0::x-repo'`.
 * The complete build log is located at '/var/log/portage/app-misc:filesdirfail-0:20190327-160105.log'.
 * For convenience, a symlink to the build log is located at '/var/tmp/portage/app-misc/filesdirfail-0/temp/build.log'.
 * The ebuild environment file is located at '/var/tmp/portage/app-misc/filesdirfail-0/temp/environment'.
 * Working directory: '/var/tmp/portage/app-misc/filesdirfail-0/work'
 * S: '/var/tmp/portage/app-misc/filesdirfail-0/work'

Portage 2.3.62 (python 3.6.5-final-0, default/linux/arm/17.0/armv7a, gcc-7.3.0, glibc-2.28-r5, 4.14.107-00002-g4ceb9ce2b8d7 armv7l)
=================================================================
System uname: Linux-4.14.107-00002-g4ceb9ce2b8d7-armv7l-ARMv7_Processor_rev_1_-v7l-with-gentoo-2.6
KiB Mem:     4116656 total,   1715568 free
KiB Swap:          0 total,         0 free
Timestamp of repository gentoo: Mon, 25 Mar 2019 00:45:01 +0000
sh dash 0.5.9.1-r3
ld GNU ld (Gentoo 2.30 p5) 2.30.0
app-shells/bash:          4.4_p23-r1::gentoo
dev-lang/perl:            5.26.2::gentoo
dev-lang/python:          2.7.15::gentoo, 3.5.5::gentoo, 3.6.5::gentoo
dev-util/cmake:           3.9.6::gentoo
sys-apps/baselayout:      2.6-r1::gentoo
sys-apps/openrc:          0.38.3-r1::gentoo
sys-apps/sandbox:         2.13::gentoo
sys-devel/autoconf:       2.69-r4::gentoo
sys-devel/automake:       1.15.1-r2::gentoo, 1.16.1-r1::gentoo
sys-devel/binutils:       2.30-r4::gentoo
sys-devel/gcc:            7.3.0-r3::gentoo
sys-devel/gcc-config:     2.0::gentoo
sys-devel/libtool:        2.4.6-r3::gentoo
sys-devel/make:           4.2.1-r4::gentoo
sys-kernel/linux-headers: 4.14-r1::gentoo (virtual/os-headers)
sys-libs/glibc:           2.28-r5::gentoo
Repositories:

gentoo
    location: /srv/repos/gentoo
    sync-type: null
    sync-uri: rsync://rsync.gentoo.org/gentoo-portage
    priority: -1000

gentoo-draconx
    location: /srv/repos/gentoo-draconx
    masters: gentoo

gentoo-fixes
    location: /srv/repos/gentoo-fixes
    masters: gentoo

ACCEPT_KEYWORDS="arm"
ACCEPT_LICENSE="@FREE"
CBUILD="armv7a-unknown-linux-gnueabihf"
CFLAGS="-O2 -pipe -mcpu=cortex-a12 -mfpu=neon -mfloat-abi=hard"
CHOST="armv7a-unknown-linux-gnueabihf"
CONFIG_PROTECT="/etc /usr/share/gnupg/qualified.txt"
CONFIG_PROTECT_MASK="/etc/ca-certificates.conf /etc/env.d /etc/fonts/fonts.conf /etc/gconf /etc/gentoo-release /etc/revdep-rebuild /etc/sandbox.d /etc/terminfo"
CXXFLAGS="-O2 -pipe -mcpu=cortex-a12 -mfpu=neon -mfloat-abi=hard"
DISTDIR="/srv/repos/gentoo/distfiles"
EMERGE_DEFAULT_OPTS="-j2 --keep-going --dynamic-deps=n --autounmask-write=n --unordered-display --verbose-conflicts --binpkg-respect-use=y --with-bdeps-auto=n"
ENV_UNSET="DBUS_SESSION_BUS_ADDRESS DISPLAY GOBIN PERL5LIB PERL5OPT PERLPREFIX PERL_CORE PERL_MB_OPT PERL_MM_OPT XAUTHORITY XDG_CACHE_HOME XDG_CONFIG_HOME XDG_DATA_HOME XDG_RUNTIME_DIR"
FCFLAGS="-O2 -pipe -march=armv7-a"
FEATURES="assume-digests binpkg-docompress binpkg-dostrip binpkg-logs binpkg-multi-instance config-protect-if-modified distlocks ebuild-locks fixlafiles ipc-sandbox merge-sync multilib-strict network-sandbox news parallel-fetch pid-sandbox preserve-libs protect-owned sandbox sfperms strict unknown-features-warn unmerge-logs unmerge-orphans userfetch userpriv usersandbox usersync xattr"
FFLAGS="-O2 -pipe -march=armv7-a"
GENTOO_MIRRORS="http://distfiles.gentoo.org"
INSTALL_MASK="/usr/share/cursors/xorg-x11/default 	/usr/share/alsa/alsa.conf.d/51-pulseaudio-probe.conf 	/etc/profile.d/qtgui4.sh         /etc/gssproxy/??-*.conf         /etc/portage/*postsync.d 	/usr/share/gtk-doc 	/usr/share/doc"
LANG="en_CA.UTF-8"
LDFLAGS="-Wl,-O1 -Wl,--as-needed"
MAKEOPTS="-j3"
PKGDIR="/var/cache/portage/packages"
PORTAGE_CONFIGROOT="/"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --omit-dir-times --compress --force --whole-file --delete --stats --human-readable --timeout=180 --exclude=/distfiles --exclude=/local --exclude=/packages --exclude=/.git"
PORTAGE_TMPDIR="/var/tmp"
USE="X acl alsa arm armv5te armv6 armv6t2 armvfp berkdb bzip2 cli crypt cxx dri flac fontconfig fortran gdbm harfbuzz iconv icu idn ipv6 jpeg kerberos ncurses neon nls nptl ogg openmp opus pam pcre perl png python readline seccomp ssl svg tcpd threads truetype unicode vim-syntax vorbis xattr xcb xft xinerama zlib" APACHE2_MODULES="authn_core authz_core socache_shmcb unixd actions alias auth_basic authn_alias authn_anon authn_dbm authn_default authn_file authz_dbm authz_default authz_groupfile authz_host authz_owner authz_user autoindex cache cgi cgid dav dav_fs dav_lock deflate dir disk_cache env expires ext_filter file_cache filter headers include info log_config logio mem_cache mime mime_magic negotiation rewrite setenvif speling status unique_id userdir usertrack vhost_alias" CALLIGRA_FEATURES="karbon sheets words" COLLECTD_PLUGINS="df interface irq load memory rrdtool swap syslog" CPU_FLAGS_ARM="edsp neon thumb vfp vfpv3 vfpv4 vfp-d32 v4 v5 v6 v7 thumb2" ELIBC="glibc" GPSD_PROTOCOLS="ashtech aivdm earthmate evermore fv18 garmin garmintxt gpsclock isync itrax mtk3301 nmea ntrip navcom oceanserver oldstyle oncore rtcm104v2 rtcm104v3 sirf skytraq superstar2 timing tsip tripmate tnt ublox ubx" KERNEL="linux" LCD_DEVICES="bayrad cfontz cfontz633 glk hd44780 lb216 lcdm001 mtxorb ncurses text" LIBREOFFICE_EXTENSIONS="presenter-console presenter-minimizer" NETBEANS_MODULES="apisupport cnd groovy gsf harness ide identity j2ee java mobility nb php profiler soa visualweb webcommon websvccommon xml" OFFICE_IMPLEMENTATION="libreoffice" PHP_TARGETS="php5-6 php7-1" POSTGRES_TARGETS="postgres9_5 postgres10" PYTHON_SINGLE_TARGET="python3_6" PYTHON_TARGETS="python2_7 python3_6" RUBY_TARGETS="ruby24" USERLAND="GNU" XTABLES_ADDONS="quota2 psd pknock lscan length2 ipv4options ipset ipp2p iface geoip fuzzy condition tee tarpit sysrq steal rawnat logmark ipmark dhcpmac delude chaos account"
Unset:  CC, CPPFLAGS, CTARGET, CXX, LC_ALL, LINGUAS, PORTAGE_BINHOST, PORTAGE_BUNZIP2_COMMAND, PORTAGE_COMPRESS, PORTAGE_COMPRESS_FLAGS, PORTAGE_RSYNC_EXTRA_OPTS
Comment 1 Nick Bowler 2019-03-27 17:55:40 UTC
Closer inspection reveals that the failing command is this one:

  install -m0755 /var/tmp/portage/app-misc/filesdirfail-0/files/hello /var/tmp/portage/app-misc/filesdirfail-0/image/bin

which (after path lookup) is:

  /usr/lib/portage/python3.6/ebuild-helpers/xattr/install -m0755 /var/tmp/portage/app-misc/filesdirfail-0/files/hello /var/tmp/portage/app-misc/filesdirfail-0/image/bin

And if I run that command explicitly, I get no error messages, the file is copied successfully, but the exit code is 1.  Drilling down further, this script calls:

  /usr/bin/install-xattr -m0755 /var/tmp/portage/app-misc/filesdirfail-0/files/hello /var/tmp/portage/app-misc/filesdirfail-0/image/bin

which appears to be the actual source of the nonzero exit status.  This command likewise prints no error messages, successfully copies the file, but the exit code is 1...
Comment 2 Nick Bowler 2019-03-27 18:48:03 UTC
(In reply to Nick Bowler from comment #1)
> Drilling down further, this script calls:
> 
>   /usr/bin/install-xattr -m0755 /var/tmp/portage/app-misc/filesdirfail-0/files/hello /var/tmp/portage/app-misc/filesdirfail-0/image/bin
> 
> which appears to be the actual source of the nonzero exit status.  This
> command likewise prints no error messages, successfully copies the file, but
> the exit code is 1...

OK, I think I figured this out.  It looks like install-xattr is just busted on
32-bit platforms.  This is the function call which is failing, on line 384 of
install-xattr.c (from version 0.5 of that package):

  for (i = first; i < last; i++) {
    if (stat(argv[i], &s) != 0)
      return EXIT_FAILURE;

    [...]

On this particular file, stat is returning -EOVERFLOW, which means:

  EOVERFLOW
       pathname  or  fd  refers  to a file whose size, inode number, or
       number of blocks cannot be  represented  in,  respectively,  the
       types off_t, ino_t, or blkcnt_t.  This error can occur when, for
       example, an application compiled on a  32-bit  platform  without
       -D_FILE_OFFSET_BITS=64 calls stat() on a file whose size exceeds
       (1<<31)-1 bytes.

And in this case, it is the inode number which is more than 2 billion:

  % stat /var/tmp/portage/app-misc/filesdirfail-0/files/hello
  [...]
  Inode: 61230529624

The solution should be for the install-xattr package to enable large
file support on 32-bit, which means it needs to be compiled with
-D_FILE_OFFSET_BITS=64.

Also it should probably print an error message if this call fails,
instead of silently failing.

Not sure who maintains this utility.
Comment 3 Anthony Basile gentoo-dev 2019-03-28 12:39:51 UTC
(In reply to Nick Bowler from comment #2)

> 
> Not sure who maintains this utility.

I do and you've pretty much nailed the issue for me.  To confirm your solution, can you re-emerge intsall-xattr as follows:

CPPFLAGS="-D_FILE_OFFSET_BITS=64" emerge -1 install-xattr

and see if it fixes the problem.  Probably the easiest solution is to just add

append-cppflags "-D_FILE_OFFSET_BITS=64"

to src_prepare() in the ebuild.  So if you want, you can test that too.
Comment 4 Nick Bowler 2019-03-28 15:26:21 UTC
(In reply to Anthony Basile from comment #3)
> (In reply to Nick Bowler from comment #2)
> Probably the easiest solution is to just add
> 
> append-cppflags "-D_FILE_OFFSET_BITS=64"
> 
> to src_prepare() in the ebuild.  So if you want, you can test that too.

Adding cppflags in the ebuild like this (as expected) works to fix the
installation error in the "filesdirfail" test ebuild.

There do not appear to be any testsuite regressions in the install-xattr utility when built with this flag.

I will rebuild gcc with this change but this will take several hours.
Comment 5 Nick Bowler 2019-03-28 15:30:19 UTC
Created attachment 571050 [details, diff]
Add error messages and test case

Patch against install-xattr-0.5 which adds "stat" error messages.  This
improves the situation dramatically:

  >>> Install filesdirfail-0 into /var/tmp/portage/app-misc/filesdirfail-0/image category app-misc
  install-xattr: failed to stat /var/tmp/portage/app-misc/filesdirfail-0/files/hello: Value too large for defined data type
   * ERROR: app-misc/filesdirfail-0::x-repo failed (install phase):
   *   doexe failed

If I had this it would have been immediately obvious where to start
looking when debugging this problem.

I also added a test case which copies a large file.  We can't control
inode numbers but we _can_ control file size, which in practice gives
the same results.
Comment 6 Anthony Basile gentoo-dev 2019-03-30 10:29:15 UTC
(In reply to Nick Bowler from comment #5)
> Created attachment 571050 [details, diff] [details, diff]
> Add error messages and test case
> 
> Patch against install-xattr-0.5 which adds "stat" error messages.  This
> improves the situation dramatically:
> 
>   >>> Install filesdirfail-0 into
> /var/tmp/portage/app-misc/filesdirfail-0/image category app-misc
>   install-xattr: failed to stat
> /var/tmp/portage/app-misc/filesdirfail-0/files/hello: Value too large for
> defined data type
>    * ERROR: app-misc/filesdirfail-0::x-repo failed (install phase):
>    *   doexe failed
> 
> If I had this it would have been immediately obvious where to start
> looking when debugging this problem.
> 
> I also added a test case which copies a large file.  We can't control
> inode numbers but we _can_ control file size, which in practice gives
> the same results.

Looks good to me:

https://gitweb.gentoo.org/proj/elfix.git/commit/?id=dac123cefa79db06f25b64f8f863b85aa2456342


The fix should be in with install-xattr-0.6:

https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=e69870431d5eaefa896ea4e6b324eade97e7f30e


We need to stabilize install-xattr-0.6.ebuild next.
Comment 7 Anthony Basile gentoo-dev 2019-04-07 14:16:53 UTC
> 
> 
> We need to stabilize install-xattr-0.6.ebuild next.

This bug is fixed, but there are a few more gnats to kill before the next stable release.  Please use 0.6 for now.