Summary: | sys-apps/install-xattr does not enable large file support (LFS) | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Nick Bowler <nbowler> |
Component: | Current packages | Assignee: | Anthony Basile <blueness> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | base-system |
Priority: | Normal | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | |||
Bug Blocks: | 471102 | ||
Attachments: | Add error messages and test case |
Description
Nick Bowler
2019-03-27 16:19:04 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... (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. (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. (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. 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.
(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.
>
>
> 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.
|