vfat filesystem "fix" breaks rpm kernel install on ia64

[Doug Chapman]

A recent kernel change has change the behavior of chmod on fat
filesystems:

commit 19c561a60ffe52df88dd63de0bff480ca094efe4
Author: Jan Engelhardt <jengelh(a)computergmbh.de&gt;
Date:   Wed Feb 6 01:36:08 2008 -0800

    fs/fat/: refine chmod checks


After this change rpm installs of kernels fail on ia64.  This is because
efi systems use vfat for the boot filesystem.  RPM installs fail because
cpio gets a error on chmod (before this kernel change it would fail
silently).

My suggestion was to have anaconda set the "quiet" option (which makes
chmod failures silent) for /boot/efi in fstab however they disagree (see
BZ 435319).

So, it seems like the options are: revert the patch (probably not a good
idea) make "quiet" the default for fat filesystems, or, convince
anaconda to add "quiet" to the fstab.  Or, hopefully someone else has a
better idea.

thanks,

- Doug

[Doug Chapman]

On Thu, 2008-02-28 at 16:03 -0500, Doug Chapman wrote:
>  A recent kernel change has change the behavior of chmod on fat
>  filesystems:
>  
>  commit 19c561a60ffe52df88dd63de0bff480ca094efe4
>  Author: Jan Engelhardt <jengelh(a)computergmbh.de&gt;
>  Date:   Wed Feb 6 01:36:08 2008 -0800
>  
>      fs/fat/: refine chmod checks
>  
>  
>  After this change rpm installs of kernels fail on ia64.  This is because
>  efi systems use vfat for the boot filesystem.  RPM installs fail because
>  cpio gets a error on chmod (before this kernel change it would fail
>  silently).
>  
>  My suggestion was to have anaconda set the "quiet" option (which makes
>  chmod failures silent) for /boot/efi in fstab however they disagree (see
>  BZ 435319).
>  
>  So, it seems like the options are: revert the patch (probably not a good
>  idea) make "quiet" the default for fat filesystems, or, convince
>  anaconda to add "quiet" to the fstab.  Or, hopefully someone else has a
>  better idea.
>  
>  thanks,
>  
>  - Doug
>   
Actually I came up with what I think is a cleaner fix for this.  Since
the default file permission on files on vfat are 755 anyway if the
kernel is mode 755 rpm doesn't complain.

Anybody have thoughts on this specfile change?  I build this as a
scratch build on our ia64 koji server and it installs cleanly.

- Doug

*** kernel.spec.bad	2008-02-28 19:58:55.000000000 -0500
--- kernel.spec	2008-02-28 21:39:57.000000000 -0500
*************** BuildKernel() {
*** 1301,1306 ****
--- 1301,1310 ----
      $CopyKernel $KernelImage \
      		$RPM_BUILD_ROOT/%{image_install_path}/$InstallName-$KernelVer
  
+ %ifarch ia64
+     chmod 755 $RPM_BUILD_ROOT/%{image_install_path}/$InstallName-$KernelVer
+ %endif
+ 
      mkdir -p $RPM_BUILD_ROOT/lib/modules/$KernelVer
      make -s ARCH=$Arch INSTALL_MOD_PATH=$RPM_BUILD_ROOT modules_install
KERNELRELEASE=$KernelVer
  %ifarch %{vdso_arches}

[Matt Domsch]

On Thu, Feb 28, 2008 at 10:00:32PM -0500, Doug Chapman wrote:
>  Actually I came up with what I think is a cleaner fix for this. 
> Since
>  the default file permission on files on vfat are 755 anyway if the
>  kernel is mode 755 rpm doesn't complain.
>  
>  Anybody have thoughts on this specfile change?  I build this as a
>  scratch build on our ia64 koji server and it installs cleanly.
>  
>  - Doug
>  
>  *** kernel.spec.bad	2008-02-28 19:58:55.000000000 -0500
>  --- kernel.spec	2008-02-28 21:39:57.000000000 -0500
>  *************** BuildKernel() {
>  *** 1301,1306 ****
>  --- 1301,1310 ----
>        $CopyKernel $KernelImage \
>        		$RPM_BUILD_ROOT/%{image_install_path}/$InstallName-$KernelVer
>    
>  + %ifarch ia64
>  +     chmod 755 $RPM_BUILD_ROOT/%{image_install_path}/$InstallName-$KernelVer
>  + %endif
>  + 
>        mkdir -p $RPM_BUILD_ROOT/lib/modules/$KernelVer
>        make -s ARCH=$Arch INSTALL_MOD_PATH=$RPM_BUILD_ROOT modules_install
> KERNELRELEASE=$KernelVer
>    %ifarch %{vdso_arches} 

There are systems with EFI32 and EFI64 out there, that aren't ia64,
but that will likewise be dropping files into a vfat file system.

-- 
Matt Domsch
Linux Technology Strategist, Dell Office of the CTO
linux.dell.com & www.dell.com/linux

[Dave Jones]

On Fri, Feb 29, 2008 at 10:16:00AM -0600, Matt Domsch wrote:
>  On Thu, Feb 28, 2008 at 10:00:32PM -0500, Doug Chapman wrote:
>  > Actually I came up with what I think is a cleaner fix for this.  Since
>  > the default file permission on files on vfat are 755 anyway if the
>  > kernel is mode 755 rpm doesn't complain.
>  > 
>  > Anybody have thoughts on this specfile change?  I build this as a
>  > scratch build on our ia64 koji server and it installs cleanly.
>  > 
>  > - Doug
>  > 
>  > *** kernel.spec.bad	2008-02-28 19:58:55.000000000 -0500
>  > --- kernel.spec	2008-02-28 21:39:57.000000000 -0500
>  > *************** BuildKernel() {
>  > *** 1301,1306 ****
>  > --- 1301,1310 ----
>  >       $CopyKernel $KernelImage \
>  >       		$RPM_BUILD_ROOT/%{image_install_path}/$InstallName-$KernelVer
>  >   
>  > + %ifarch ia64
>  > +     chmod 755 $RPM_BUILD_ROOT/%{image_install_path}/$InstallName-$KernelVer
>  > + %endif
>  > + 
>  >       mkdir -p $RPM_BUILD_ROOT/lib/modules/$KernelVer
>  >       make -s ARCH=$Arch INSTALL_MOD_PATH=$RPM_BUILD_ROOT modules_install
> KERNELRELEASE=$KernelVer
>  >   %ifarch %{vdso_arches}
>  
>  
>  There are systems with EFI32 and EFI64 out there, that aren't ia64,
>  but that will likewise be dropping files into a vfat file system. 
I don't see any problem in unconditionally doing the chmod.  Anyone else?

	Dave

-- 
http://www.codemonkey.org.uk

[Doug Chapman]

On Fri, 2008-02-29 at 11:36 -0500, Dave Jones wrote:
>  On Fri, Feb 29, 2008 at 10:16:00AM -0600, Matt Domsch wrote:
>   > On Thu, Feb 28, 2008 at 10:00:32PM -0500, Doug Chapman wrote:
>   > > Actually I came up with what I think is a cleaner fix for this.  Since
>   > > the default file permission on files on vfat are 755 anyway if the
>   > > kernel is mode 755 rpm doesn't complain.
>   > > 
>   > > Anybody have thoughts on this specfile change?  I build this as a
>   > > scratch build on our ia64 koji server and it installs cleanly.
>   > > 
>   > > - Doug
>   > > 
>   > > *** kernel.spec.bad	2008-02-28 19:58:55.000000000 -0500
>   > > --- kernel.spec	2008-02-28 21:39:57.000000000 -0500
>   > > *************** BuildKernel() {
>   > > *** 1301,1306 ****
>   > > --- 1301,1310 ----
>   > >       $CopyKernel $KernelImage \
>   > >       		$RPM_BUILD_ROOT/%{image_install_path}/$InstallName-$KernelVer
>   > >   
>   > > + %ifarch ia64
>   > > +     chmod 755 $RPM_BUILD_ROOT/%{image_install_path}/$InstallName-$KernelVer
>   > > + %endif
>   > > + 
>   > >       mkdir -p $RPM_BUILD_ROOT/lib/modules/$KernelVer
>   > >       make -s ARCH=$Arch INSTALL_MOD_PATH=$RPM_BUILD_ROOT modules_install
> KERNELRELEASE=$KernelVer
>   > >   %ifarch %{vdso_arches}
>   > 
>   > 
>   > There are systems with EFI32 and EFI64 out there, that aren't ia64,
>   > but that will likewise be dropping files into a vfat file system.
>  
>  I don't see any problem in unconditionally doing the chmod.  Anyone else?
>  
I can't actually think of any reason this would break on other
platforms.  I added the %ifarch ia64 "just in case" because I really
don't want to be "that ia64 guy who breaks everyone else's stuff".

- Doug

[Dave Jones]

On Fri, Feb 29, 2008 at 01:23:02PM -0500, Doug Chapman wrote:
 

>  >  > > +     chmod 755
> $RPM_BUILD_ROOT/%{image_install_path}/$InstallName-$KernelVer
>  >  > 
>  >  > There are systems with EFI32 and EFI64 out there, that aren't ia64,
>  >  > but that will likewise be dropping files into a vfat file system.
>  > 
>  > I don't see any problem in unconditionally doing the chmod.  Anyone else?
>  
>  I can't actually think of any reason this would break on other
>  platforms.  I added the %ifarch ia64 "just in case" because I really
>  don't want to be "that ia64 guy who breaks everyone else's stuff".
I just committed the change to devel.  We'll see tomorrow, but I'll be
really surprised if anything at all cares that the vmlinuz grew an x bit.

	Dave

-- 
http://www.codemonkey.org.uk