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
| ||
|
Date: Tue, 15 Apr 2014 15:37:03 -0400 (EDT) From: Vince Weaver <vincent.weaver@...ne.edu> To: Vince Weaver <vincent.weaver@...ne.edu> cc: Russell King - ARM Linux <linux@....linux.org.uk>, Christoph Lameter <cl@...ux.com>, Michal Marek <mmarek@...e.cz>, linux-kernel@...r.kernel.org, Jason Cooper <jason@...edaemon.net>, Grant Likely <grant.likely@...aro.org>, Rob Herring <robh+dt@...nel.org>, srivasta@...ian.org Subject: Re: [bisected] broken make-kpkg kernel build in 3.15-rc1 On Tue, 15 Apr 2014, Vince Weaver wrote: > On Tue, 15 Apr 2014, Vince Weaver wrote: > > > On Tue, 15 Apr 2014, Russell King - ARM Linux wrote: > > > > > 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. > > > > OK, I captured the output. No diffs, as of course reverting things > > means one kernel was called 3.15-rc1 and one 3.15-rc1+ which meant more or > > less every line changed. > > > > It seems that on stock 3.15-rc1 (which fails to build) after running > > depmod it kicks into > > > > restore_upstream_debianization > > > > which goes down a path which causes the file permission failures > > > > Wheras 3.15-rc1 with the problem commit reverted this doesn't happen. > > > > This is a really weird bug, I've tried reverting individual hunks of the > > problem commit manually and it is not clear at all to me what is > > triggering this. > > OK, in debian/image.mk we have this: > > ifeq ($(strip $(HAVE_INST_PATH)),) > test ! -f System.map || cp System.map \ > $(TMPTOP)/$(IMAGEDIR)/System.map-$(KERNELRELEASE); > test ! -f System.map || chmod 644 \ > $(TMPTOP)/$(IMAGEDIR)/System.map-$(KERNELRELEASE); > cp $(kimagesrc) $(kimagedest) > else > $(restore_upstream_debianization) > $(MAKE) $(EXTRAV_ARG) INSTALL_MOD_PATH=$(INSTALL_MOD_PATH) \ > INSTALL_FW_PATH=$(INSTALL_MOD_PATH)/lib/firmware/$(KERNELRELEASE) \ > INSTALL_PATH=$(INT_IMAGE_DESTDIR) $(CROSS_ARG) $(KPKG_KBUILD_INSTALL_TARGET) > endif > > > So in the good case it goes down the if, in the bad case down the else. > > > I'm assuming that the ($(strip $(HAVE_INST_PATH)),) is being confused by > the INSTALL_DTBS_PATH introduced by the changeset. > > So I guess that makes this a debian bug? And it looks like this was reported to the list earlier and I somehow missed it :( https://lkml.org/lkml/2014/4/3/333 Vince -- 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/
Powered by blists - more mailing lists