public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Randy Dunlap <randy.dunlap@oracle.com>
To: Gregory Haskins <ghaskins@novell.com>
Cc: linux-kernel@vger.kernel.org
Subject: Re: Trouble with make-install from a NFS mount
Date: Tue, 14 Apr 2009 14:36:20 -0700	[thread overview]
Message-ID: <49E501D4.6000605@oracle.com> (raw)
In-Reply-To: <49E500F6.8060401@novell.com>

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

  reply	other threads:[~2009-04-14 21:36 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-04-14 21:32 Trouble with make-install from a NFS mount Gregory Haskins
2009-04-14 21:36 ` Randy Dunlap [this message]
2009-04-15 18:30   ` Gregory Haskins
2009-04-15 20:21     ` Randy Dunlap
2009-04-15 21:13       ` Gregory Haskins
2009-04-15 21:20         ` Sam Ravnborg
2009-04-15 21:29           ` H. Peter Anvin
2009-04-15 23:46             ` Sam Ravnborg
2009-04-17 17:51               ` [tip:x86/urgent] x86, kbuild: make "make install" not depend on vmlinux tip-bot for H. Peter Anvin
2009-04-17 20:46               ` tip-bot for H. Peter Anvin

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=49E501D4.6000605@oracle.com \
    --to=randy.dunlap@oracle.com \
    --cc=ghaskins@novell.com \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox