Trouble with make-install from a NFS mount

Trouble with make-install from a NFS mount

[Gregory Haskins]

[-- Attachment #1: Type: text/plain, Size: 5015 bytes --]

Hi All,
  I've been struggling trying to find the cause of a regression in
30-rc1 (compared to 2.6.29) where I am no longer able to make-install a
kernel via an NFS mounted home directory.

Historically I do all of my kernel development/building on one machine
and then I have a bunch of test machines that are NIS/NFS clients of
that machine that have the same /home mounted.  When I am ready to
deploy a kernel, I log into that machine and su to root to simply "make
modules_install && make install" the kernel.  This has always worked
until recently.  I started getting this message:

  INSTALL sound/usb/caiaq/snd-usb-caiaq.ko
  INSTALL sound/usb/snd-usb-audio.ko
  INSTALL sound/usb/snd-usb-lib.ko
  INSTALL sound/usb/usx2y/snd-usb-usx2y.ko
  DEPMOD  2.6.30-rc1-vbus
rm: cannot remove `include/config/kernel.release': Permission denied
make: *** [include/config/kernel.release] Error 1

I understand what is going on w.r.t. the root shell having permisssion
problems modifying data on an NFS mount.  However, this _used_ to work
so I started investigating for what I thought would be a minor change to
kbuild that I could patch.  At first I simply just hacked the makefile
to make the kernel.release stuff use the "-" to ignore the error.  This
did manage to get me past the initial problem, but then I immediately
ran into more problems related to the generation of version.h and
version.h.tmp as well. 

Looking into this, I couldnt track down where the "filechk" magic was
coming from (any hints from the kbuild gurus?).  So I thought that I
would try to bisect the issue.  However, that failed to produce a bad
commit for reasons that I do not quite understand either.  Here is the
git-bisect log:

git bisect start
# good: [8e0ee43bc2c3e19db56a4adaa9a9b04ce885cd84] Linux 2.6.29
git bisect good 8e0ee43bc2c3e19db56a4adaa9a9b04ce885cd84
# bad: [b21597d0268983f8f9e8b563494f75490403e948] Merge branch
'for-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/security-testing-2.6
git bisect bad b21597d0268983f8f9e8b563494f75490403e948
# good: [7f6adeaf2d8800b66c5dd6c2cf2622dfdd68bd31] V4L/DVB (10730):
v4l-dvb: cleanup obsolete references to v4l1 headers.
git bisect good 7f6adeaf2d8800b66c5dd6c2cf2622dfdd68bd31
# good: [18222f98223a00537bcf29ba74c8d5fdb3ae1fb8] Staging: comedi: add
ssv_dnp driver
git bisect good 18222f98223a00537bcf29ba74c8d5fdb3ae1fb8
# bad: [32fb6c17566ec66de87324a834c7776f40e35e78] Merge branch 'release'
of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6
git bisect bad 32fb6c17566ec66de87324a834c7776f40e35e78
# bad: [714f83d5d9f7c785f622259dad1f4fad12d64664] Merge branch
'tracing-for-linus' of
git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip
git bisect bad 714f83d5d9f7c785f622259dad1f4fad12d64664
# good: [6404434525bb9f8f2239998f30fd7c93f2efa5b3] tracing/syscalls:
various cleanups
git bisect good 6404434525bb9f8f2239998f30fd7c93f2efa5b3
# bad: [0a053e8c71d666daf30da2d407147b1293923d8b] Merge branch
'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/drzeus/mmc
git bisect bad 0a053e8c71d666daf30da2d407147b1293923d8b
# bad: [811158b147a503fbdf9773224004ffd32002d1fe] Merge branch
'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/trivial
git bisect bad 811158b147a503fbdf9773224004ffd32002d1fe
# bad: [b983471794e568fd71fa767da77a62ba517c3e63] Merge
git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-unstable
git bisect bad b983471794e568fd71fa767da77a62ba517c3e63
# bad: [9140db04ef185f934acf2b1b15b3dd5e6a6bfc22] ocfs2: recover orphans
in offline slots during recovery and mount
git bisect bad 9140db04ef185f934acf2b1b15b3dd5e6a6bfc22
# bad: [feb473a6e8bd19297d0f3bb377b25055c0228c0a] ocfs2: Optimize inode
group allocation by recording last used group.
git bisect bad feb473a6e8bd19297d0f3bb377b25055c0228c0a
# bad: [e7c17e43090afe558c40bfb66637744c27bd2aeb] ocfs2: Introduce dir
free space list
git bisect bad e7c17e43090afe558c40bfb66637744c27bd2aeb
# bad: [59b526a30722f29e5dba6210a6e0fc34e3149b94] ocfs2: Remove debugfs
file local_alloc_stats
git bisect bad 59b526a30722f29e5dba6210a6e0fc34e3149b94
# bad: [96a6c64b5354b804b3ccfd1b31306565a01ebcb1] ocfs2: Move struct
recovery_map to a header file
git bisect bad 96a6c64b5354b804b3ccfd1b31306565a01ebcb1
# bad: [87d3d3f3931f3e0fca44fbb5c06ad45fc4dca9bc] ocfs2/hb: Expose the
list of heartbeating nodes via debugfs
git bisect bad 87d3d3f3931f3e0fca44fbb5c06ad45fc4dca9bc

What I dont really understand is that this (I thought) was supposed to
look for where the behavior first appeared between v2.6.29..HEAD, but
some points along the way were actually before v2.6.29 was cut.  I don't
really know what went wrong, but if it matters I am running git 1.6.2.

At this point, I am stuck.  Perhaps there is a better methodology to
deploying the kernels that I should employ, but I am not sure which to
use yet.  Any help appreciated!

-Greg


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 266 bytes --]

Re: Trouble with make-install from a NFS mount

[Randy Dunlap]

Gregory Haskins wrote:
> Hi All,
>   I've been struggling trying to find the cause of a regression in
> 30-rc1 (compared to 2.6.29) where I am no longer able to make-install a
> kernel via an NFS mounted home directory.
> 
> Historically I do all of my kernel development/building on one machine
> and then I have a bunch of test machines that are NIS/NFS clients of
> that machine that have the same /home mounted.  When I am ready to
> deploy a kernel, I log into that machine and su to root to simply "make
> modules_install && make install" the kernel.  This has always worked
> until recently.  I started getting this message:
> 
>   INSTALL sound/usb/caiaq/snd-usb-caiaq.ko
>   INSTALL sound/usb/snd-usb-audio.ko
>   INSTALL sound/usb/snd-usb-lib.ko
>   INSTALL sound/usb/usx2y/snd-usb-usx2y.ko
>   DEPMOD  2.6.30-rc1-vbus
> rm: cannot remove `include/config/kernel.release': Permission denied
> make: *** [include/config/kernel.release] Error 1
> 
> I understand what is going on w.r.t. the root shell having permisssion
> problems modifying data on an NFS mount.  However, this _used_ to work
> so I started investigating for what I thought would be a minor change to
> kbuild that I could patch.  At first I simply just hacked the makefile
> to make the kernel.release stuff use the "-" to ignore the error.  This
> did manage to get me past the initial problem, but then I immediately
> ran into more problems related to the generation of version.h and
> version.h.tmp as well. 
> 
> Looking into this, I couldnt track down where the "filechk" magic was
> coming from (any hints from the kbuild gurus?).  So I thought that I
> would try to bisect the issue.  However, that failed to produce a bad
> commit for reasons that I do not quite understand either.  Here is the
> git-bisect log:
> 
> git bisect start
> # good: [8e0ee43bc2c3e19db56a4adaa9a9b04ce885cd84] Linux 2.6.29
> git bisect good 8e0ee43bc2c3e19db56a4adaa9a9b04ce885cd84
> # bad: [b21597d0268983f8f9e8b563494f75490403e948] Merge branch
> 'for-linus' of
> git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/security-testing-2.6
> git bisect bad b21597d0268983f8f9e8b563494f75490403e948
> # good: [7f6adeaf2d8800b66c5dd6c2cf2622dfdd68bd31] V4L/DVB (10730):
> v4l-dvb: cleanup obsolete references to v4l1 headers.
> git bisect good 7f6adeaf2d8800b66c5dd6c2cf2622dfdd68bd31
> # good: [18222f98223a00537bcf29ba74c8d5fdb3ae1fb8] Staging: comedi: add
> ssv_dnp driver
> git bisect good 18222f98223a00537bcf29ba74c8d5fdb3ae1fb8
> # bad: [32fb6c17566ec66de87324a834c7776f40e35e78] Merge branch 'release'
> of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6
> git bisect bad 32fb6c17566ec66de87324a834c7776f40e35e78
> # bad: [714f83d5d9f7c785f622259dad1f4fad12d64664] Merge branch
> 'tracing-for-linus' of
> git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip
> git bisect bad 714f83d5d9f7c785f622259dad1f4fad12d64664
> # good: [6404434525bb9f8f2239998f30fd7c93f2efa5b3] tracing/syscalls:
> various cleanups
> git bisect good 6404434525bb9f8f2239998f30fd7c93f2efa5b3
> # bad: [0a053e8c71d666daf30da2d407147b1293923d8b] Merge branch
> 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/drzeus/mmc
> git bisect bad 0a053e8c71d666daf30da2d407147b1293923d8b
> # bad: [811158b147a503fbdf9773224004ffd32002d1fe] Merge branch
> 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/trivial
> git bisect bad 811158b147a503fbdf9773224004ffd32002d1fe
> # bad: [b983471794e568fd71fa767da77a62ba517c3e63] Merge
> git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-unstable
> git bisect bad b983471794e568fd71fa767da77a62ba517c3e63
> # bad: [9140db04ef185f934acf2b1b15b3dd5e6a6bfc22] ocfs2: recover orphans
> in offline slots during recovery and mount
> git bisect bad 9140db04ef185f934acf2b1b15b3dd5e6a6bfc22
> # bad: [feb473a6e8bd19297d0f3bb377b25055c0228c0a] ocfs2: Optimize inode
> group allocation by recording last used group.
> git bisect bad feb473a6e8bd19297d0f3bb377b25055c0228c0a
> # bad: [e7c17e43090afe558c40bfb66637744c27bd2aeb] ocfs2: Introduce dir
> free space list
> git bisect bad e7c17e43090afe558c40bfb66637744c27bd2aeb
> # bad: [59b526a30722f29e5dba6210a6e0fc34e3149b94] ocfs2: Remove debugfs
> file local_alloc_stats
> git bisect bad 59b526a30722f29e5dba6210a6e0fc34e3149b94
> # bad: [96a6c64b5354b804b3ccfd1b31306565a01ebcb1] ocfs2: Move struct
> recovery_map to a header file
> git bisect bad 96a6c64b5354b804b3ccfd1b31306565a01ebcb1
> # bad: [87d3d3f3931f3e0fca44fbb5c06ad45fc4dca9bc] ocfs2/hb: Expose the
> list of heartbeating nodes via debugfs
> git bisect bad 87d3d3f3931f3e0fca44fbb5c06ad45fc4dca9bc
> 
> What I dont really understand is that this (I thought) was supposed to
> look for where the behavior first appeared between v2.6.29..HEAD, but
> some points along the way were actually before v2.6.29 was cut.  I don't
> really know what went wrong, but if it matters I am running git 1.6.2.
> 
> At this point, I am stuck.  Perhaps there is a better methodology to
> deploying the kernels that I should employ, but I am not sure which to
> use yet.  Any help appreciated!


See this patch, already applied/merged:

Gitweb:     http://git.kernel.org/linus/556b0f58bbcdc96ba8ed67001b4e57c50198da89
Commit:     556b0f58bbcdc96ba8ed67001b4e57c50198da89
Parent:     8e320d02718d2872d52ef88a69a493e420494269
Author:     David Woodhouse <David.Woodhouse@intel.com>
AuthorDate: Sat Jan 10 14:53:15 2009 +0000
Committer:  David Woodhouse <David.Woodhouse@intel.com>
CommitDate: Mon Apr 6 14:27:17 2009 -0700

    Revert "fix modules_install via NFS"
    
    This reverts commit 8b249b6856f16f09b0e5b79ce5f4d435e439b9d6.
    
    This 'fix' is not necessary; we just need to undo the damage caused
    accidentally by Igor/Mauro in 4b29631db33292d416dc395c56122ea865e7635c
    ("V4L/DVB (9533): cx88: Add support for TurboSight TBS8910 DVB-S PCI card")
    
    Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>


-- 
~Randy

Re: Trouble with make-install from a NFS mount

[Gregory Haskins]

[-- Attachment #1: Type: text/plain, Size: 7487 bytes --]

Randy Dunlap wrote:
> Gregory Haskins wrote:
>   
>> Hi All,
>>   I've been struggling trying to find the cause of a regression in
>> 30-rc1 (compared to 2.6.29) where I am no longer able to make-install a
>> kernel via an NFS mounted home directory.
>>
>> Historically I do all of my kernel development/building on one machine
>> and then I have a bunch of test machines that are NIS/NFS clients of
>> that machine that have the same /home mounted.  When I am ready to
>> deploy a kernel, I log into that machine and su to root to simply "make
>> modules_install && make install" the kernel.  This has always worked
>> until recently.  I started getting this message:
>>
>>   INSTALL sound/usb/caiaq/snd-usb-caiaq.ko
>>   INSTALL sound/usb/snd-usb-audio.ko
>>   INSTALL sound/usb/snd-usb-lib.ko
>>   INSTALL sound/usb/usx2y/snd-usb-usx2y.ko
>>   DEPMOD  2.6.30-rc1-vbus
>> rm: cannot remove `include/config/kernel.release': Permission denied
>> make: *** [include/config/kernel.release] Error 1
>>
>> I understand what is going on w.r.t. the root shell having permisssion
>> problems modifying data on an NFS mount.  However, this _used_ to work
>> so I started investigating for what I thought would be a minor change to
>> kbuild that I could patch.  At first I simply just hacked the makefile
>> to make the kernel.release stuff use the "-" to ignore the error.  This
>> did manage to get me past the initial problem, but then I immediately
>> ran into more problems related to the generation of version.h and
>> version.h.tmp as well. 
>>
>> Looking into this, I couldnt track down where the "filechk" magic was
>> coming from (any hints from the kbuild gurus?).  So I thought that I
>> would try to bisect the issue.  However, that failed to produce a bad
>> commit for reasons that I do not quite understand either.  Here is the
>> git-bisect log:
>>
>> git bisect start
>> # good: [8e0ee43bc2c3e19db56a4adaa9a9b04ce885cd84] Linux 2.6.29
>> git bisect good 8e0ee43bc2c3e19db56a4adaa9a9b04ce885cd84
>> # bad: [b21597d0268983f8f9e8b563494f75490403e948] Merge branch
>> 'for-linus' of
>> git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/security-testing-2.6
>> git bisect bad b21597d0268983f8f9e8b563494f75490403e948
>> # good: [7f6adeaf2d8800b66c5dd6c2cf2622dfdd68bd31] V4L/DVB (10730):
>> v4l-dvb: cleanup obsolete references to v4l1 headers.
>> git bisect good 7f6adeaf2d8800b66c5dd6c2cf2622dfdd68bd31
>> # good: [18222f98223a00537bcf29ba74c8d5fdb3ae1fb8] Staging: comedi: add
>> ssv_dnp driver
>> git bisect good 18222f98223a00537bcf29ba74c8d5fdb3ae1fb8
>> # bad: [32fb6c17566ec66de87324a834c7776f40e35e78] Merge branch 'release'
>> of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6
>> git bisect bad 32fb6c17566ec66de87324a834c7776f40e35e78
>> # bad: [714f83d5d9f7c785f622259dad1f4fad12d64664] Merge branch
>> 'tracing-for-linus' of
>> git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip
>> git bisect bad 714f83d5d9f7c785f622259dad1f4fad12d64664
>> # good: [6404434525bb9f8f2239998f30fd7c93f2efa5b3] tracing/syscalls:
>> various cleanups
>> git bisect good 6404434525bb9f8f2239998f30fd7c93f2efa5b3
>> # bad: [0a053e8c71d666daf30da2d407147b1293923d8b] Merge branch
>> 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/drzeus/mmc
>> git bisect bad 0a053e8c71d666daf30da2d407147b1293923d8b
>> # bad: [811158b147a503fbdf9773224004ffd32002d1fe] Merge branch
>> 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/trivial
>> git bisect bad 811158b147a503fbdf9773224004ffd32002d1fe
>> # bad: [b983471794e568fd71fa767da77a62ba517c3e63] Merge
>> git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-unstable
>> git bisect bad b983471794e568fd71fa767da77a62ba517c3e63
>> # bad: [9140db04ef185f934acf2b1b15b3dd5e6a6bfc22] ocfs2: recover orphans
>> in offline slots during recovery and mount
>> git bisect bad 9140db04ef185f934acf2b1b15b3dd5e6a6bfc22
>> # bad: [feb473a6e8bd19297d0f3bb377b25055c0228c0a] ocfs2: Optimize inode
>> group allocation by recording last used group.
>> git bisect bad feb473a6e8bd19297d0f3bb377b25055c0228c0a
>> # bad: [e7c17e43090afe558c40bfb66637744c27bd2aeb] ocfs2: Introduce dir
>> free space list
>> git bisect bad e7c17e43090afe558c40bfb66637744c27bd2aeb
>> # bad: [59b526a30722f29e5dba6210a6e0fc34e3149b94] ocfs2: Remove debugfs
>> file local_alloc_stats
>> git bisect bad 59b526a30722f29e5dba6210a6e0fc34e3149b94
>> # bad: [96a6c64b5354b804b3ccfd1b31306565a01ebcb1] ocfs2: Move struct
>> recovery_map to a header file
>> git bisect bad 96a6c64b5354b804b3ccfd1b31306565a01ebcb1
>> # bad: [87d3d3f3931f3e0fca44fbb5c06ad45fc4dca9bc] ocfs2/hb: Expose the
>> list of heartbeating nodes via debugfs
>> git bisect bad 87d3d3f3931f3e0fca44fbb5c06ad45fc4dca9bc
>>
>> What I dont really understand is that this (I thought) was supposed to
>> look for where the behavior first appeared between v2.6.29..HEAD, but
>> some points along the way were actually before v2.6.29 was cut.  I don't
>> really know what went wrong, but if it matters I am running git 1.6.2.
>>
>> At this point, I am stuck.  Perhaps there is a better methodology to
>> deploying the kernels that I should employ, but I am not sure which to
>> use yet.  Any help appreciated!
>>     
>
>
> See this patch, already applied/merged:
>
> Gitweb:     http://git.kernel.org/linus/556b0f58bbcdc96ba8ed67001b4e57c50198da89
> Commit:     556b0f58bbcdc96ba8ed67001b4e57c50198da89
> Parent:     8e320d02718d2872d52ef88a69a493e420494269
> Author:     David Woodhouse <David.Woodhouse@intel.com>
> AuthorDate: Sat Jan 10 14:53:15 2009 +0000
> Committer:  David Woodhouse <David.Woodhouse@intel.com>
> CommitDate: Mon Apr 6 14:27:17 2009 -0700
>
>     Revert "fix modules_install via NFS"
>     
>     This reverts commit 8b249b6856f16f09b0e5b79ce5f4d435e439b9d6.
>     
>     This 'fix' is not necessary; we just need to undo the damage caused
>     accidentally by Igor/Mauro in 4b29631db33292d416dc395c56122ea865e7635c
>     ("V4L/DVB (9533): cx88: Add support for TurboSight TBS8910 DVB-S PCI card")
>     
>     Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
>
>
>   
Thanks Randy.  I was running on 0882e8dd3aad33eca41696d463bb896e6c8817eb
so I had these patches all applied.  I think you were trying to tell me
that perhaps a similar fix could be found among these patches, but I was
unfortunately not able to find any and this is still broken for me.

As a work-around, I wrote the following script to push my kernels out
over ssh, instead of pulling them in by nfs.  FWIW, i'll post it here as
others have privately told me they are having this same bug in
make-install affect them as well.

#!/bin/bash

#
# deploykernel - push a kernel to a remote ssh machine
#
# Author: Gregory Haskins <ghaskins@novell.com>
#

set -e

if [ -z $1 ]; then
    echo "usage: $0 <remote>"
    exit -1
fi

tmp=$(mktemp -d)
rel=$(cat include/config/kernel.release)

echo "Generating module image"
make modules_install INSTALL_MOD_PATH=$tmp

echo "Transferring modules"
(cd $tmp; tar -c *) | ssh root@$1 'cd /; tar -xv'

rm -rf $tmp

echo "Transferring kernel"
tmp=$(ssh root@$1 'mktemp -d')

scp ./arch/x86/boot/bzImage root@$1:$tmp
scp ./System.map root@$1:$tmp

echo "Installing kernel"
ssh root@$1 "cd $tmp; /sbin/installkernel $rel bzImage System.map; rm
-rf $tmp"



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 266 bytes --]

Re: Trouble with make-install from a NFS mount

[Randy Dunlap]

Gregory Haskins wrote:
> Randy Dunlap wrote:
>> Gregory Haskins wrote:
>>   
>>> Hi All,
>>>   I've been struggling trying to find the cause of a regression in
>>> 30-rc1 (compared to 2.6.29) where I am no longer able to make-install a
>>> kernel via an NFS mounted home directory.
>>>
>>> Historically I do all of my kernel development/building on one machine
>>> and then I have a bunch of test machines that are NIS/NFS clients of
>>> that machine that have the same /home mounted.  When I am ready to
>>> deploy a kernel, I log into that machine and su to root to simply "make
>>> modules_install && make install" the kernel.  This has always worked
>>> until recently.  I started getting this message:
>>>
>>>   INSTALL sound/usb/caiaq/snd-usb-caiaq.ko
>>>   INSTALL sound/usb/snd-usb-audio.ko
>>>   INSTALL sound/usb/snd-usb-lib.ko
>>>   INSTALL sound/usb/usx2y/snd-usb-usx2y.ko
>>>   DEPMOD  2.6.30-rc1-vbus
>>> rm: cannot remove `include/config/kernel.release': Permission denied
>>> make: *** [include/config/kernel.release] Error 1
>>>
>>> I understand what is going on w.r.t. the root shell having permisssion
>>> problems modifying data on an NFS mount.  However, this _used_ to work
>>> so I started investigating for what I thought would be a minor change to
>>> kbuild that I could patch.  At first I simply just hacked the makefile
>>> to make the kernel.release stuff use the "-" to ignore the error.  This
>>> did manage to get me past the initial problem, but then I immediately
>>> ran into more problems related to the generation of version.h and
>>> version.h.tmp as well. 
>>>
>>> Looking into this, I couldnt track down where the "filechk" magic was
>>> coming from (any hints from the kbuild gurus?).  So I thought that I

filechk is defined in scripts/Kbuild.include .

>>> would try to bisect the issue.  However, that failed to produce a bad
>>> commit for reasons that I do not quite understand either.  Here is the
>>> git-bisect log:
>>>
>>> git bisect start
>>> # good: [8e0ee43bc2c3e19db56a4adaa9a9b04ce885cd84] Linux 2.6.29
>>> git bisect good 8e0ee43bc2c3e19db56a4adaa9a9b04ce885cd84
>>> # bad: [b21597d0268983f8f9e8b563494f75490403e948] Merge branch
>>> 'for-linus' of
>>> git://git.kernel.org/pub/scm/linux/kernel/git/jmorris/security-testing-2.6
>>> git bisect bad b21597d0268983f8f9e8b563494f75490403e948
>>> # good: [7f6adeaf2d8800b66c5dd6c2cf2622dfdd68bd31] V4L/DVB (10730):
>>> v4l-dvb: cleanup obsolete references to v4l1 headers.
>>> git bisect good 7f6adeaf2d8800b66c5dd6c2cf2622dfdd68bd31
>>> # good: [18222f98223a00537bcf29ba74c8d5fdb3ae1fb8] Staging: comedi: add
>>> ssv_dnp driver
>>> git bisect good 18222f98223a00537bcf29ba74c8d5fdb3ae1fb8
>>> # bad: [32fb6c17566ec66de87324a834c7776f40e35e78] Merge branch 'release'
>>> of git://git.kernel.org/pub/scm/linux/kernel/git/lenb/linux-acpi-2.6
>>> git bisect bad 32fb6c17566ec66de87324a834c7776f40e35e78
>>> # bad: [714f83d5d9f7c785f622259dad1f4fad12d64664] Merge branch
>>> 'tracing-for-linus' of
>>> git://git.kernel.org/pub/scm/linux/kernel/git/tip/linux-2.6-tip
>>> git bisect bad 714f83d5d9f7c785f622259dad1f4fad12d64664
>>> # good: [6404434525bb9f8f2239998f30fd7c93f2efa5b3] tracing/syscalls:
>>> various cleanups
>>> git bisect good 6404434525bb9f8f2239998f30fd7c93f2efa5b3
>>> # bad: [0a053e8c71d666daf30da2d407147b1293923d8b] Merge branch
>>> 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/drzeus/mmc
>>> git bisect bad 0a053e8c71d666daf30da2d407147b1293923d8b
>>> # bad: [811158b147a503fbdf9773224004ffd32002d1fe] Merge branch
>>> 'for-linus' of git://git.kernel.org/pub/scm/linux/kernel/git/jikos/trivial
>>> git bisect bad 811158b147a503fbdf9773224004ffd32002d1fe
>>> # bad: [b983471794e568fd71fa767da77a62ba517c3e63] Merge
>>> git://git.kernel.org/pub/scm/linux/kernel/git/mason/btrfs-unstable
>>> git bisect bad b983471794e568fd71fa767da77a62ba517c3e63
>>> # bad: [9140db04ef185f934acf2b1b15b3dd5e6a6bfc22] ocfs2: recover orphans
>>> in offline slots during recovery and mount
>>> git bisect bad 9140db04ef185f934acf2b1b15b3dd5e6a6bfc22
>>> # bad: [feb473a6e8bd19297d0f3bb377b25055c0228c0a] ocfs2: Optimize inode
>>> group allocation by recording last used group.
>>> git bisect bad feb473a6e8bd19297d0f3bb377b25055c0228c0a
>>> # bad: [e7c17e43090afe558c40bfb66637744c27bd2aeb] ocfs2: Introduce dir
>>> free space list
>>> git bisect bad e7c17e43090afe558c40bfb66637744c27bd2aeb
>>> # bad: [59b526a30722f29e5dba6210a6e0fc34e3149b94] ocfs2: Remove debugfs
>>> file local_alloc_stats
>>> git bisect bad 59b526a30722f29e5dba6210a6e0fc34e3149b94
>>> # bad: [96a6c64b5354b804b3ccfd1b31306565a01ebcb1] ocfs2: Move struct
>>> recovery_map to a header file
>>> git bisect bad 96a6c64b5354b804b3ccfd1b31306565a01ebcb1
>>> # bad: [87d3d3f3931f3e0fca44fbb5c06ad45fc4dca9bc] ocfs2/hb: Expose the
>>> list of heartbeating nodes via debugfs
>>> git bisect bad 87d3d3f3931f3e0fca44fbb5c06ad45fc4dca9bc
>>>
>>> What I dont really understand is that this (I thought) was supposed to
>>> look for where the behavior first appeared between v2.6.29..HEAD, but
>>> some points along the way were actually before v2.6.29 was cut.  I don't
>>> really know what went wrong, but if it matters I am running git 1.6.2.
>>>
>>> At this point, I am stuck.  Perhaps there is a better methodology to
>>> deploying the kernels that I should employ, but I am not sure which to
>>> use yet.  Any help appreciated!
>>>     
>>
>> See this patch, already applied/merged:
>>
>> Gitweb:     http://git.kernel.org/linus/556b0f58bbcdc96ba8ed67001b4e57c50198da89
>> Commit:     556b0f58bbcdc96ba8ed67001b4e57c50198da89
>> Parent:     8e320d02718d2872d52ef88a69a493e420494269
>> Author:     David Woodhouse <David.Woodhouse@intel.com>
>> AuthorDate: Sat Jan 10 14:53:15 2009 +0000
>> Committer:  David Woodhouse <David.Woodhouse@intel.com>
>> CommitDate: Mon Apr 6 14:27:17 2009 -0700
>>
>>     Revert "fix modules_install via NFS"
>>     
>>     This reverts commit 8b249b6856f16f09b0e5b79ce5f4d435e439b9d6.
>>     
>>     This 'fix' is not necessary; we just need to undo the damage caused
>>     accidentally by Igor/Mauro in 4b29631db33292d416dc395c56122ea865e7635c
>>     ("V4L/DVB (9533): cx88: Add support for TurboSight TBS8910 DVB-S PCI card")
>>     
>>     Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
>>
>>
>>   
> Thanks Randy.  I was running on 0882e8dd3aad33eca41696d463bb896e6c8817eb
> so I had these patches all applied.  I think you were trying to tell me
> that perhaps a similar fix could be found among these patches, but I was
> unfortunately not able to find any and this is still broken for me.

No, I wasn't trying to say that.  Your very first paragraph said
"regression in 30-rc1" and David's patch fixes that problem.

So is there still some other problem in linus-current?

> As a work-around, I wrote the following script to push my kernels out
> over ssh, instead of pulling them in by nfs.  FWIW, i'll post it here as
> others have privately told me they are having this same bug in
> make-install affect them as well.
> 
> #!/bin/bash
> 
> #
> # deploykernel - push a kernel to a remote ssh machine
> #
> # Author: Gregory Haskins <ghaskins@novell.com>
> #
> 
> set -e
> 
> if [ -z $1 ]; then
>     echo "usage: $0 <remote>"
>     exit -1
> fi
> 
> tmp=$(mktemp -d)
> rel=$(cat include/config/kernel.release)
> 
> echo "Generating module image"
> make modules_install INSTALL_MOD_PATH=$tmp
> 
> echo "Transferring modules"
> (cd $tmp; tar -c *) | ssh root@$1 'cd /; tar -xv'
> 
> rm -rf $tmp
> 
> echo "Transferring kernel"
> tmp=$(ssh root@$1 'mktemp -d')
> 
> scp ./arch/x86/boot/bzImage root@$1:$tmp
> scp ./System.map root@$1:$tmp
> 
> echo "Installing kernel"
> ssh root@$1 "cd $tmp; /sbin/installkernel $rel bzImage System.map; rm
> -rf $tmp"


-- 
~Randy

Re: Trouble with make-install from a NFS mount

[Gregory Haskins]

[-- Attachment #1: Type: text/plain, Size: 3046 bytes --]

Randy Dunlap wrote:
> Gregory Haskins wrote:
>   
>> Randy Dunlap wrote:
>>     
>>> Gregory Haskins wrote:
>>>   
>>>       
>>>>
>>>> Looking into this, I couldnt track down where the "filechk" magic was
>>>> coming from (any hints from the kbuild gurus?).  So I thought that I
>>>>         
>
> filechk is defined in scripts/Kbuild.include .
>
>   

ah, thx.

>>>
>>> See this patch, already applied/merged:
>>>
>>> Gitweb:     http://git.kernel.org/linus/556b0f58bbcdc96ba8ed67001b4e57c50198da89
>>> Commit:     556b0f58bbcdc96ba8ed67001b4e57c50198da89
>>> Parent:     8e320d02718d2872d52ef88a69a493e420494269
>>> Author:     David Woodhouse <David.Woodhouse@intel.com>
>>> AuthorDate: Sat Jan 10 14:53:15 2009 +0000
>>> Committer:  David Woodhouse <David.Woodhouse@intel.com>
>>> CommitDate: Mon Apr 6 14:27:17 2009 -0700
>>>
>>>     Revert "fix modules_install via NFS"
>>>     
>>>     This reverts commit 8b249b6856f16f09b0e5b79ce5f4d435e439b9d6.
>>>     
>>>     This 'fix' is not necessary; we just need to undo the damage caused
>>>     accidentally by Igor/Mauro in 4b29631db33292d416dc395c56122ea865e7635c
>>>     ("V4L/DVB (9533): cx88: Add support for TurboSight TBS8910 DVB-S PCI card")
>>>     
>>>     Signed-off-by: David Woodhouse <David.Woodhouse@intel.com>
>>>
>>>
>>>   
>>>       
>> Thanks Randy.  I was running on 0882e8dd3aad33eca41696d463bb896e6c8817eb
>> so I had these patches all applied.  I think you were trying to tell me
>> that perhaps a similar fix could be found among these patches, but I was
>> unfortunately not able to find any and this is still broken for me.
>>     
>
> No, I wasn't trying to say that. 
Ah, sorry for the confusion.

>  Your very first paragraph said
> "regression in 30-rc1" and David's patch fixes that problem.
>
> So is there still some other problem in linus-current?
>
>   
Yes, this is still broken in current, though I think its a slightly
different problem than the one David addressed.  I think he addressed
"make modules_install", whereas I see the issue with "make install".

The problem seems to be that 30-rcX thinks that there are dependencies
to update (such as include/config/kernel.release and version.h.tmp)
during a make-install operation.  Since I am on a root-squashed NFS
mount, these files cannot be updated and thus the install fails. 
Previous trees prior to linux-current (at least up to 2.6.29) did not
try to update these files so the install would succeed.

FWIW, I ran the make with -d, and at least part of the reason for the
dep-failure was the FORCE psuedo dependency against kernel.release and
version.h.  However, I didn't find that FORCE was a recent addition to
the Makefile so I am not sure why the behavior suddenly changed.

I can try things to debug this for anyone who is interested in sending
me suggestions.  However, I am currently unblocked by the issue since I
added the posted "push" script to my workflow, so this is not critical
to me anymore.

-Greg


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 266 bytes --]

Re: Trouble with make-install from a NFS mount

[Sam Ravnborg]

> 
> The problem seems to be that 30-rcX thinks that there are dependencies
> to update (such as include/config/kernel.release and version.h.tmp)
> during a make-install operation.  Since I am on a root-squashed NFS
> mount, these files cannot be updated and thus the install fails. 
> Previous trees prior to linux-current (at least up to 2.6.29) did not
> try to update these files so the install would succeed.

It is because arch/x86/Makefile has
a dependency on vmlinux for the install target.

I know hpa has had a fix for it but it is not applied.
I recall there was a trivial bug in the first version.

	Sam

Re: Trouble with make-install from a NFS mount

[H. Peter Anvin]

Sam Ravnborg wrote:
>> The problem seems to be that 30-rcX thinks that there are dependencies
>> to update (such as include/config/kernel.release and version.h.tmp)
>> during a make-install operation.  Since I am on a root-squashed NFS
>> mount, these files cannot be updated and thus the install fails. 
>> Previous trees prior to linux-current (at least up to 2.6.29) did not
>> try to update these files so the install would succeed.
> 
> It is because arch/x86/Makefile has
> a dependency on vmlinux for the install target.
> 
> I know hpa has had a fix for it but it is not applied.
> I recall there was a trivial bug in the first version.
> 

OK, do we have a consensus that this is desirable?  I was somewhat 
confused if it was desired or considered user error.

I'll clean up the patch and add it in the former case.

	-hpa

Re: Trouble with make-install from a NFS mount

[Sam Ravnborg]

On Wed, Apr 15, 2009 at 02:29:13PM -0700, H. Peter Anvin wrote:
> Sam Ravnborg wrote:
> >>The problem seems to be that 30-rcX thinks that there are dependencies
> >>to update (such as include/config/kernel.release and version.h.tmp)
> >>during a make-install operation.  Since I am on a root-squashed NFS
> >>mount, these files cannot be updated and thus the install fails. 
> >>Previous trees prior to linux-current (at least up to 2.6.29) did not
> >>try to update these files so the install would succeed.
> >
> >It is because arch/x86/Makefile has
> >a dependency on vmlinux for the install target.
> >
> >I know hpa has had a fix for it but it is not applied.
> >I recall there was a trivial bug in the first version.
> >
> 
> OK, do we have a consensus that this is desirable?  I was somewhat 
> confused if it was desired or considered user error.

It is desireable - so please go ahead and fix the patch.

Thanks,
	Sam

[tip:x86/urgent] x86, kbuild: make "make install" not depend on vmlinux

[tip-bot for H. Peter Anvin]

Commit-ID:  e56cb7f5e74af194585be4a2a6fc55a88f5be3ad
Gitweb:     http://git.kernel.org/tip/e56cb7f5e74af194585be4a2a6fc55a88f5be3ad
Author:     H. Peter Anvin <hpa@zytor.com>
AuthorDate: Fri, 17 Apr 2009 10:46:37 -0700
Committer:  H. Peter Anvin <hpa@zytor.com>
CommitDate: Fri, 17 Apr 2009 10:46:37 -0700

x86, kbuild: make "make install" not depend on vmlinux

It is common to use "make install" in restricted environments which
differ from the one which was actually used to build the kernel.  In
such environments it is highly undesirable to trigger a rebuild of any
part of the system.  Worse, the rebuild may be spurious, triggered by
differences in the environment.

Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Cc: Sam Ravnborg <sam@ravnborg.org>
LKML-Reference: <20090415234642.GA28531@uranus.ravnborg.org>


---
 arch/x86/Makefile |    6 +++++-
 1 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/arch/x86/Makefile b/arch/x86/Makefile
index f05d8c9..8c86b72 100644
--- a/arch/x86/Makefile
+++ b/arch/x86/Makefile
@@ -153,7 +153,7 @@ endif
 
 boot := arch/x86/boot
 
-BOOT_TARGETS = bzlilo bzdisk fdimage fdimage144 fdimage288 isoimage install
+BOOT_TARGETS = bzlilo bzdisk fdimage fdimage144 fdimage288 isoimage
 
 PHONY += bzImage $(BOOT_TARGETS)
 
@@ -171,6 +171,10 @@ bzImage: vmlinux
 $(BOOT_TARGETS): vmlinux
 	$(Q)$(MAKE) $(build)=$(boot) $@
 
+PHONY += install
+install:
+	$(Q)$(MAKE) $(build)=$(boot) $@
+
 PHONY += vdso_install
 vdso_install:
 	$(Q)$(MAKE) $(build)=arch/x86/vdso $@

[tip:x86/urgent] x86, kbuild: make "make install" not depend on vmlinux

[tip-bot for H. Peter Anvin]

Commit-ID:  1648e4f805063137b55b869666e936ffd4419cdf
Gitweb:     http://git.kernel.org/tip/1648e4f805063137b55b869666e936ffd4419cdf
Author:     H. Peter Anvin <hpa@zytor.com>
AuthorDate: Fri, 17 Apr 2009 10:46:37 -0700
Committer:  Ingo Molnar <mingo@elte.hu>
CommitDate: Fri, 17 Apr 2009 22:43:12 +0200

x86, kbuild: make "make install" not depend on vmlinux

It is common to use "make install" in restricted environments which
differ from the one which was actually used to build the kernel.  In
such environments it is highly undesirable to trigger a rebuild of any
part of the system.  Worse, the rebuild may be spurious, triggered by
differences in the environment.

Signed-off-by: H. Peter Anvin <hpa@zytor.com>
Cc: Sam Ravnborg <sam@ravnborg.org>
LKML-Reference: <20090415234642.GA28531@uranus.ravnborg.org>


---
 arch/x86/Makefile |    6 +++++-
 1 files changed, 5 insertions(+), 1 deletions(-)

diff --git a/arch/x86/Makefile b/arch/x86/Makefile
index f05d8c9..8c86b72 100644
--- a/arch/x86/Makefile
+++ b/arch/x86/Makefile
@@ -153,7 +153,7 @@ endif
 
 boot := arch/x86/boot
 
-BOOT_TARGETS = bzlilo bzdisk fdimage fdimage144 fdimage288 isoimage install
+BOOT_TARGETS = bzlilo bzdisk fdimage fdimage144 fdimage288 isoimage
 
 PHONY += bzImage $(BOOT_TARGETS)
 
@@ -171,6 +171,10 @@ bzImage: vmlinux
 $(BOOT_TARGETS): vmlinux
 	$(Q)$(MAKE) $(build)=$(boot) $@
 
+PHONY += install
+install:
+	$(Q)$(MAKE) $(build)=$(boot) $@
+
 PHONY += vdso_install
 vdso_install:
 	$(Q)$(MAKE) $(build)=arch/x86/vdso $@