On Wed, Oct 02, 2013 at 10:18:44PM +0400, Boris Samorodov wrote: > 02.10.2013 21:47, Konstantin Belousov пишет: > > On Wed, Oct 02, 2013 at 09:27:29PM +0400, Boris Samorodov wrote: > >> (CCing to the maintainer) > >> > >> Hi All, > >> > >> I've come across a problem and can't diagnose it. Please give me > >> an advice how to proceed. > >> > >> I have a fresh CURRENT amd64 host with 9.2 (9.1 behaves the same) > >> i386 jail. The command "/usr/bin/find -d <input_dir> | /usr/bin/cpio > >> -dumpl <output_dir>" ends with error with diagnostic "cpio: Can't update > >> time for <a directory>". > >> > >> One can reproduce it by installing at 10-amd64 host poudriere, create > >> a 9-i386 jail and try to build devel/tmake port. Full log is here: > >> http://gw.wart.ru/bulk/91-i386-default/2013-10-02_14h52m08s/logs/errors/tmake-1.13.log > >> > >> I've managed to find out that the command...: > >> ----- > >> # /usr/bin/find -d /wrkdirs/usr/ports/devel/tmake/work/tmake-1.13/lib > >> | /usr/bin/cpio -dumpl /destdir > >> ----- > >> > >> ...fails with diagnostic: "cpio: Can't update time for > >> /destdir/wrkdirs/usr/ports/devel/tmake/work/tmake-1.13/lib". > >> > >> However the following command succeeds (mind the /* after lib): > >> ----- > >> # /usr/bin/find -d /wrkdirs/usr/ports/devel/tmake/work/tmake-1.13/lib/* > >> | /usr/bin/cpio -dumpl /destdir > >> ----- > >> > >> The directory itself seems quite natural: > >> ----- > >> # ls -ldT /wrkdirs/usr/ports/devel/tmake/work/tmake-1.13/lib > >> drwxr-xr-x 53 root wheel 3264 Jan 28 05:21:45 2004 > >> /wrkdirs/usr/ports/devel/tmake/work/tmake-1.13/lib > >> ----- > >> > >> There are no problems at 10-amd64 and 10-i386 jails. > >> > >> I'm out of ideas. Thanks for your help. > > ktrace the failing invocation ? > > The relevant part is here: > ftp://ftp.wart.ru/pub/misc/bsdcpio-error-cant-update-time-kdump.txt So lutimes(2) fails with EINVAL, and in fact futimes(2) failed just before with the timeval array passed from the same address. Most likely, EINVAL comes from the getutimes() check, which verifies that usec values are non-negative and less than 100000. You probably have to debug this by looking at the timeval initialization and understanding where the value come from.
This archive was generated by hypermail 2.4.0 : Wed May 19 2021 - 11:40:42 UTC