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

Ryan Wong notifications at github.com
Tue Jun 12 06:26:48 UTC 2018


The installation of a rpm package named "libjpeg62-1.5.2-r0.0.core2_64.rpm" failed with the following log.

```
error: unpacking of archive failed on file /usr/lib64/libjpeg.so.62;5b1f5f5a: cpio: utime failed - Resource temporarily unavailable
error: libjpeg62-1:1.5.2-r0.0.core2_64: install failed
```

I suspected that it is NFS rootfs that causes the error so I tried using rpm to install that package with NFS rootfs and standard rootfs. When using NFS, an error appeared but with standard rootfs it's all right.

I used strace to trace the return code of every function in rpm. And I found the following information in strace log.
```
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)
```

It indicates that there are some problem with utime in rpm installation procedure. And I found the rpm tool uses utime in function fsmUtime in lib/fsm.c.

I added some code to debug and I found the rpm uses lutimes, which means the system supports HAVE_LUTIMES. And the perror also shows an error code "ESTALE".

I searched it and found this error code is returned by NFS server. On NFS FAQ website(http://nfs.sourceforge.net/#faq_c10), I found 5 situations which cause this error, and the fifth one may suits my situation.

**5.The exported file system doesn't support permanent inode numbers. Exporting FAT file systems via NFS is problematic for this reason. This problem can be avoided by exporting only local filesystems which have good NFS support. See question C6 for more information.**

I tried to use touch to modify the time stamp but it did not work. If this is true, we should relax the restriction of utime when using NFS rootfs. So I added some code to check the filesystem type and if it is NFS, the code does not care so much for the result of utime.

I tested the new rpm package. The problem is fixed and I have not found any bug of it. But even the latest rpm source code does not change these code. So I want to know if this kind of modification makes sense?

RPM version:
```
RPM version 4.13.90
```

My NFS export config:
```
/nfsroot (rw,no_root_squash,no_subtree_check,async,insecure)
```

NFS client config:
```
root=/dev/nfs nfsroot=10.0.2.2:/nfsroot,nfsvers=3,port=3063,udp,mountport=3062 rw highres=off  console=ttyS0 mem=256M ip=dhcp vga=0 uvesafb.mode_option=640x480-32 oprofile.timer=1 uvesafb.task_timeout=-1
```

```
diff --git a/lib/fsm.c b/lib/fsm.c
index dcfce82..3fdd7df 100644
--- a/lib/fsm.c
+++ b/lib/fsm.c
@@ -10,6 +10,8 @@
 #if WITH_CAP
 #include <sys/capability.h>
 #endif
+#include <sys/vfs.h>
+#include <linux/magic.h>

 #include <rpm/rpmte.h>
 #include <rpm/rpmts.h>
@@ -604,6 +606,9 @@ static int fsmUtime(const char *path, mode_t mode, time_t mtime)
        { .tv_sec = mtime, .tv_usec = 0 },
        { .tv_sec = mtime, .tv_usec = 0 },
     };
+    struct statfs fs;
+
+    statfs(path, &fs);

 #if HAVE_LUTIMES
     rc = lutimes(path, stamps);
@@ -616,8 +621,9 @@ static int fsmUtime(const char *path, mode_t mode, time_t mtime)
        rpmlog(RPMLOG_DEBUG, " %8s (%s, 0x%x) %s\n", __func__,
               path, (unsigned)mtime, (rc < 0 ? strerror(errno) : ""));
     if (rc < 0)        rc = RPMERR_UTIME_FAILED;
-    /* ...but utime error is not critical for directories */
-    if (rc && S_ISDIR(mode))
+
+    /* ...but utime error is not critical for directories and nfs fs */
+    if (rc && (S_ISDIR(mode) || fs.f_type == NFS_SUPER_MAGIC))
        rc = 0;
     return rc;
 }
```

-- 
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rpm.org/pipermail/rpm-maint/attachments/20180611/d1c647eb/attachment-0001.html>


More information about the Rpm-maint mailing list