Description of problem: I am not sure if this change needs to be in anaconda or in one of the other packages used at install time. I will be happy to provide a patch if someone can point me in the right direction. A recent kernel change now enforces the fact that chmod on vfat partitions fail when it cannot properly handle changes that differ between u, g, and o since it doesn't have that concept. In the past these just failed quietly. After this change rpm is no longer able to install new kernels on ia64: Error unpacking rpm package kernel-2.6.25-0.69.rc3.git1.fc9.ia64 error: unpacking of archive failed on file /boot/efi/EFI/redhat/vmlinuz-2.6.25-0.69.rc3.git1.fc9: cpio: chmod the fix for this is to add the umount option to /etc/fstab for /boot/efi. FYI, the kernel change that triggered this is: commit 19c561a60ffe52df88dd63de0bff480ca094efe4 Author: Jan Engelhardt <jengelh> Date: Wed Feb 6 01:36:08 2008 -0800 fs/fat/: refine chmod checks Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
This is kernel brokenness. We mount filesystems with the defaults. If the defaults are broken, they need to be fixed. Otherwise, users are in for unbearable pain on things like upgrades.
Doug, can you take this to linux-kernel? Breaking programs like cpio that used to work on vfat can't possibly be a good idea...
(In reply to comment #2) > Doug, can you take this to linux-kernel? Breaking programs like cpio that used > to work on vfat can't possibly be a good idea... Actually yeah, I need to report this upstream. I did some additional testing on this and even chmod commands that _should_ work fail after this patch.
More info on this: cpio doesn't actually fail, I did some experimenting and found that even though cpio prints out an error message it _does_ create the file and does not even return a non-zero exit code. Evidently RPM is either seeing the error message from cpio OR it just verifies that the mode is what it expects and if it isn't it removes the files. I discovered that the only modes that work on a fat filesystem are 755 and 555 and after some deliberation I realize that makes sense. So, cpio isn't broken and it _does_ appear the kernel is doing the right thing. I came up with a cleaner solotion of just setting vmlinuz to mode 755 in the spec file when it is built. From the discussion on fedora-kernel-list it sounds like they will take that in. I will verify this once the chmod 755 change it made to the specfile and close then.
Fix committed to the kernel specfile.