Bug 435319 - /boot/efi on ia64 needs to be mounted with quiet option
/boot/efi on ia64 needs to be mounted with quiet option
Status: CLOSED NEXTRELEASE
Product: Fedora
Classification: Fedora
Component: kernel (Show other bugs)
rawhide
ia64 Linux
high Severity high
: ---
: ---
Assigned To: Kernel Maintainer List
Fedora Extras Quality Assurance
:
Depends On:
Blocks: fedora-ia64
  Show dependency treegraph
 
Reported: 2008-02-28 12:45 EST by Doug Chapman
Modified: 2008-03-05 16:06 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-03-05 16:06:15 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Doug Chapman 2008-02-28 12:45:00 EST
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@computergmbh.de>
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:
Comment 1 Jeremy Katz 2008-02-28 13:20:25 EST
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.
Comment 2 Chuck Ebbert 2008-02-28 19:01:55 EST
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...
Comment 3 Doug Chapman 2008-02-28 19:44:46 EST
(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.

Comment 4 Doug Chapman 2008-02-29 13:04:41 EST
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.

Comment 5 Doug Chapman 2008-03-05 16:06:15 EST
Fix committed to the kernel specfile.

Note You need to log in before you can comment on or make changes to this bug.