mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Russell King - ARM Linux <linux@arm.linux.org.uk>
To: Christoph Lameter <cl@linux.com>
Cc: Michal Marek <mmarek@suse.cz>,
	Vince Weaver <vincent.weaver@maine.edu>,
	linux-kernel@vger.kernel.org, Jason Cooper <jason@lakedaemon.net>,
	Grant Likely <grant.likely@linaro.org>,
	Rob Herring <robh+dt@kernel.org>
Subject: Re: [bisected] broken make-kpkg kernel build in 3.15-rc1
Date: Tue, 15 Apr 2014 19:26:53 +0100	[thread overview]
Message-ID: <20140415182653.GR24070@n2100.arm.linux.org.uk> (raw)
In-Reply-To: <alpine.DEB.2.10.1404151221360.26992@gentwo.org>

On Tue, Apr 15, 2014 at 12:22:51PM -0500, Christoph Lameter wrote:
> On Tue, 15 Apr 2014, Michal Marek wrote:
> 
> > > The problem is that the kernel build process should not write to anything
> > > in the /etc/apt directory.
> >
> > Again: make install starts /sbin/installkernel and the rest is the job
> > of this script. Which means you need to debug Debian's
> > /sbin/installkernel why it suddenly wants to modify files in /etc/apt.
> 
> Why then does reverting the patch fix the issue?
> 
> Something in the patch causes install process to not divert correctly to
> the install directory. It tries to go to the / directory instead.

Right, so the thing to do is to run a build with the commit applied,
without any -j arguments and V=1, logging the output (so that predictable
output can be generated).

Then run the same thing with the commit reverted, again logging it.  Then
diff the two and see what's different.

I, too, can't see anything in that commit which would cause this regression.

Looking at arch/x86/boot/install.sh, it contains these lines:

if [ -x ~/bin/${INSTALLKERNEL} ]; then exec ~/bin/${INSTALLKERNEL} "$@"; fi
if [ -x /sbin/${INSTALLKERNEL} ]; then exec /sbin/${INSTALLKERNEL} "$@"; fi

which will have the effect of running /sbin/installkernel.

The Ubuntu /sbin/installkernel (which I assume is closely related to
Debian's version) installs the kernel in the specified directory
(indicated by $dir in the script), and then does this:

run-parts --verbose --exit-on-error --arg="$ver" --arg="$dir/$img_dest-$ver" \
  /etc/kernel/postinst.d

which has the effect of running all hooks in /etc/kernel/postinst.d.
One such hook is /etc/kernel/postinst.d/apt-auto-removal, which does
this:

eval $(apt-config shell APT_CONF_D Dir::Etc::parts/d)
test -n "${APT_CONF_D}" || APT_CONF_D="/etc/apt/apt.conf.d"
config_file=${APT_CONF_D}/01autoremove-kernels
...
cat > "$config_file".dpkg-new <<EOF
// File autogenerated by $0, do not edit
APT
{
...
};
EOF
mv "$config_file".dpkg-new "$config_file"

Now, the only additional thing that could affect any of debian's scripts
is the addition of INSTALL_DTBS_PATH in the enfironment.  So, I've tested
running "apt-config shell APT_CONF_D Dir::Etc::parts/d" with that set, and
it has no effect here.

So... like I say above, I think we need to see a diff between two build
attempts, one with the commit in place, and one without.

-- 
FTTC broadband for 0.8mile line: now at 9.7Mbps down 460kbps up... slowly
improving, and getting towards what was expected from it.

  reply	other threads:[~2014-04-15 18:27 UTC|newest]

Thread overview: 15+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-04-15 13:43 Vince Weaver
2014-04-15 15:03 ` Michal Marek
2014-04-15 16:49   ` Christoph Lameter
2014-04-15 16:57     ` Michal Marek
2014-04-15 17:22       ` Christoph Lameter
2014-04-15 18:26         ` Russell King - ARM Linux [this message]
2014-04-15 19:10           ` Vince Weaver
2014-04-15 19:28             ` Vince Weaver
2014-04-15 19:30             ` Vince Weaver
2014-04-15 19:31               ` Russell King - ARM Linux
2014-04-15 19:39                 ` Vince Weaver
2014-04-15 19:43                   ` Russell King - ARM Linux
2014-04-15 19:56                     ` Christoph Lameter
2014-04-15 19:37               ` Vince Weaver
2014-04-15 19:47             ` Christoph Lameter

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=20140415182653.GR24070@n2100.arm.linux.org.uk \
    --to=linux@arm.linux.org.uk \
    --cc=cl@linux.com \
    --cc=grant.likely@linaro.org \
    --cc=jason@lakedaemon.net \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mmarek@suse.cz \
    --cc=robh+dt@kernel.org \
    --cc=vincent.weaver@maine.edu \
    /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

all inboxes | Powered by JetHome®