[10.0-amd64 host and 9.2-i386 jail] cpio: Can't update time for...

Boris Samorodov bsam at passap.ru
Fri Oct 4 19:48:37 UTC 2013


04.10.2013 22:26, Konstantin Belousov пишет:
> On Fri, Oct 04, 2013 at 09:46:37PM +0400, Boris Samorodov wrote:
>> 02.10.2013 23:12, Konstantin Belousov пишет:
>>> 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.
>>
>> The bad value (for birthtim) came from lstat() syscall.
>>
>> So far it seems to be a bug in time conversion. Pure hosts without
>> jails (both 10 and 9) are not affected. The simple testcase:
>> =====
>> host-amd64% sudo touch /jail/root/afile
>> host-amd64% ./test-utimes /jail/root/afile
>> ---> /jail/root/afile
>> atim: 1380907943.417817881, mtim: 1380907943.417817881, ctim:
>> 1380907943.417817881, birthtim:1380907943.417817881
>> ...
>> jail-i386# ./test-utimes /root/afile
>> ---> /root/afile
>> atim: 1380907943.417817881, mtim: 1380907943.417817881, ctim:
>> 1380907943.417817881, birthtim:417817881.0
>> =====
>>
>> Look at the birthtim results.
>>
>> The testing program just do a stat/lstat (the resulta are the same)
>> and print the resulting values.
> 
> Try this.
> 
> diff --git a/sys/compat/freebsd32/freebsd32.h b/sys/compat/freebsd32/freebsd32.h
> index e6644f6..8376e95 100644
> --- a/sys/compat/freebsd32/freebsd32.h
> +++ b/sys/compat/freebsd32/freebsd32.h
> @@ -175,6 +175,7 @@ struct stat32 {
>  	u_int32_t st_blksize;
>  	u_int32_t st_flags;
>  	u_int32_t st_gen;
> +	int32_t	st_lspare;
>  	struct timespec32 st_birthtim;
>  	unsigned int :(8 / 2) * (16 - (int)sizeof(struct timespec32));
>  	unsigned int :(8 / 2) * (16 - (int)sizeof(struct timespec32));

Yes, that did it! Thank you!

-- 
WBR, Boris Samorodov (bsam)
FreeBSD Committer, http://www.FreeBSD.org The Power To Serve


More information about the freebsd-current mailing list