Description of Problem: With rpm-4.0.3-1.0[34], glibc-2.2.4cvs and kernel-2.4.10 I see the following problem: [root@enzo:/cvsx/rawhide/BUILD]# rpm -Uvh /cvsx/rawhide/RPMS/ppc/SysVinit-2.78-19.ppc.rpm Preparing... ########################################### [100%] 1:SysVinit error: unpacking of archive failed on file /dev/initctl: cpio: rename failed - Operation not permitted strace shows this: lstat("/dev/initctl;3baf9cae", 0x7fffedb8) = -1 ENOENT (No such file or directory) mknod("/dev/initctl;3baf9cae", S_IFIFO) = 0 ioctl(1, TCGETS, 0x7fffeda8) = 0 rename("/dev/initctl;3baf9cae", "/dev/initctl") = -1 EPERM (Operation not permitted) It seems rpm should create the fifo with S_IFIFO|S_IRUSR|S_IWUSR so the rename wouldn't fail and then set the real mode later on? It's not clear to me which of kernel/glibc/rpm is responsible for this change of behaviour... Version-Release number of selected component (if applicable): rpm-4.0.3-1.0[34] How Reproducible: Every time. Steps to Reproduce: 1. rpm -Uvh /cvsx/rawhide/RPMS/ppc/SysVinit-2.78-19.ppc.rpm 2. 3. Actual Results: Expected Results: Additional Information:
Take the fifo out of the package, there's little reason to include a fifo -- particularly for init -- in a package.
Well, this wasn't my idea, this is how Red Hat is packaging SysVinit probably forever (I guess for rpm -V reasons). As I suspected probably a recent kernel or glibc strictness change is triggering this and I find it disturbing rpm creates something without proper mode (the stored mode in the package is 010600 as can be seen with --dump) and then tries to rename it before fixing up the modes. Franz.
Again, I suggest that depending on rpm's ability to unpack a fifo correctly for a package as important as init is crazy and useless (fifo's are always recreated at daemon startup, which also controls perms). YMMV. Furthermore, I'm not sure that rpm ever did the right thing with FIFO's. Because of the recreation, you'ld hardly notice if the file were unpacked incorrectly. What's new is stricter checks on syscall return codes. Yes, rpm-4.0.3 unpacks into a temp file with appended install transaction id (i.e. ';' followed by time in hex) and then renames into place. This avoids a (minor IMHO, YMMV) race wrto shared libraries that may be opened by name while an install write is in progress. There will be other uses when I get around to finishing a full blown --apply/--commit/--undo scheme for unpacking files.