linux-kernel - Re: [bisected] broken make-kpkg kernel build in 3.15-rc1

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 15 Apr 2014 19:26:53 +0100
From:	Russell King - ARM Linux <linux@....linux.org.uk>
To:	Christoph Lameter <cl@...ux.com>
Cc:	Michal Marek <mmarek@...e.cz>,
	Vince Weaver <vincent.weaver@...ne.edu>,
	linux-kernel@...r.kernel.org, Jason Cooper <jason@...edaemon.net>,
	Grant Likely <grant.likely@...aro.org>,
	Rob Herring <robh+dt@...nel.org>
Subject: Re: [bisected] broken make-kpkg kernel build in 3.15-rc1

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.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/