[Rpm-maint] [rpm-software-management/rpm] rpm install failed with "cpio: utime failed - Resource temporarily unavailable" (#449)

[Panu Matilainen]

If it's ext4 then did you post an excerpt that talks about filesystems that don't support permanent inodes such as FAT? :) Anyway, with ext4 underneath the story is entirely different.

This seems more like an NFS bug though, it's clearly being told NOT to follow the symlink:

utimensat(AT_FDCWD, "/usr/lib64/libjpeg.so.62;5b111347", [{tv_sec=1527818564, tv_nsec=0} /* 2018-06-01T02:02:44+0000 */, {tv_sec=1527818564, tv_nsec=0} /* 2018-06-01T02:02:44+0000 */], AT_SYMLINK_NOFOLLOW) = -1 ESTALE (Stale file handle)

Thinking about it a bit, utimensat() is a relatively new thing and eg. NFS v3 (never mind v2) wouldn't know anything about it even if our kernel does, but then I'd think it'd be the responsibility of the NFS stack to deal with this.

You say you're getting this with nfsroot, but can you easily test, it'd be interesting to know if it happens with regular NFS client too. And the versions involved - which NFS version, kernel, userland parts.

Finally, I think this should work around the problem:
```
+++ b/lib/fsm.c
@@ -638,6 +638,9 @@ static int fsmUtime(const char *path, mode_t mode, time_t mtime)
 
 #if HAVE_LUTIMES
     rc = lutimes(path, stamps);
+    /* NFS doesn't necessarily support lutimes() even if our kernel does */
+    if (rc == ESTALE && S_ISLINK(mode))
+       rc = 0;
 #else
     if (!S_ISLNK(mode))
        rc = utimes(path, stamps);
```
...but please confirm. And I'd also like to understand the affected versions before considering actually applying such a workaround.

-- 
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/rpm-software-management/rpm/issues/449#issuecomment-396862273
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20180613/037ff235/attachment.html>