X-Original-To: alpine-devel@lists.alpinelinux.org Delivered-To: alpine-devel@mail.alpinelinux.org Received: from ncopa-desktop.alpinelinux.org (3.203.202.84.customer.cdi.no [84.202.203.3]) (using SSLv3 with cipher ECDHE-RSA-AES128-SHA (128/128 bits)) (No client certificate requested) (Authenticated sender: n@tanael.org) by mail.alpinelinux.org (Postfix) with ESMTPSA id 98536DC006B; Fri, 19 Sep 2014 09:23:57 +0000 (UTC) Date: Fri, 19 Sep 2014 11:23:54 +0200 From: Natanael Copa To: Isaac Dunham Cc: alpine-devel@lists.alpinelinux.org Subject: Re: [alpine-devel] Re: Cannot mount root filesystem with latest vanilla kernel Message-ID: <20140919112354.2893501e@ncopa-desktop.alpinelinux.org> In-Reply-To: <20140918160414.GA25585@newbook> References: <20140914201702.GA513@muslin> <20140914210508.GA1775@newbook> <20140915113105.182f422b@ncopa-desktop.alpinelinux.org> <20140915193509.GA545@muslin> <20140916045715.GA1781@newbook> <20140916234219.GA1783@newbook> <20140917160613.45155c68@ncopa-desktop.alpinelinux.org> <20140917154445.GA1783@newbook> <20140918165327.709c57f5@ncopa-desktop.alpinelinux.org> <20140918160414.GA25585@newbook> X-Mailer: Claws Mail 3.10.1 (GTK+ 2.24.23; x86_64-alpine-linux-musl) X-Mailinglist: alpine-devel Precedence: list List-Id: Alpine Development List-Unsubscribe: List-Post: List-Help: List-Subscribe: MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit On Thu, 18 Sep 2014 09:04:15 -0700 Isaac Dunham wrote: > On Thu, Sep 18, 2014 at 04:53:27PM +0200, Natanael Copa wrote: > > On Wed, 17 Sep 2014 08:44:46 -0700 > > Isaac Dunham wrote: > > > > > On Wed, Sep 17, 2014 at 04:06:13PM +0200, Natanael Copa wrote: > > > > On Tue, 16 Sep 2014 16:42:19 -0700 > > > > Isaac Dunham wrote: > > > > > > > > > On Mon, Sep 15, 2014 at 09:57:15PM -0700, Isaac Dunham wrote: > > > > > > On Mon, Sep 15, 2014 at 12:35:09PM -0700, Isaac Dunham wrote: > > > > > > > > > > > > > > Well, ran into more problems: > > > > > > > - on the second boot, the problem reappeared. > > > > > > > - I chrooted in, purged linux-vanilla, exited, umounted the root > > > > > > > partition, ran e2fsck -p (which fixed several isssues with "deleted > > > > > > > inodes"), ran e2fsck -cckv, which reported no bad blocks or other > > > > > > > issues, remounted & chrooted, installed linux-vanilla, ran > > > > > > > apk fix mkinitfs, > > > > > > > exited, umounted, ran sync; sync; sync; > > > > > > > and rebooted to find that the issue was still there. > > > > > > > > > > > > > > Most modules are giving me complaints about missing symbols or bad > > > > > > > symbol versions. > > > > > > > > > > > > Well, I installed the latest from the 3.0 repo, which is to say I > > > > > > downgraded from kernel 3.14.18 (in edge) to 3.14.17, and everything worked. > > > > > > > > > > > > So I'm fairly conviced that there's a bug or miscompile in 3.14.18. > > > > > > > > > > Definitely bug in 3.14.18: > > > > > alpine build of 3.14.17: works > > > > > local build of 3.14.17: works > > > > > alpine build of 3.14.18: does not work > > > > > local build of 3.14.18: does not work > > > > > > > > > > I still don't know what the cause is, though. > > > > > > > > which arch is it? I have 3.14.18 working on my x86_64 laptop. > > > > > > > > The config was modified from 3.14.17 -> .18: > > > > > > > > @@ -484,7 +484,10 @@ CONFIG_SCHED_HRTICK=y > > > > # CONFIG_KEXEC is not set > > > > # CONFIG_CRASH_DUMP is not set > > > > CONFIG_PHYSICAL_START=0x1000000 > > > > -# CONFIG_RELOCATABLE is not set > > > > +CONFIG_RELOCATABLE=y > > > > +CONFIG_RANDOMIZE_BASE=y > > > > +CONFIG_RANDOMIZE_BASE_MAX_OFFSET=0x20000000 > > > > +CONFIG_X86_NEED_RELOCS=y > > > > CONFIG_PHYSICAL_ALIGN=0x1000000 > > > > CONFIG_HOTPLUG_CPU=y > > > > # CONFIG_BOOTPARAM_HOTPLUG_CPU0 is not set > > > > > > > > Mostly due to be similar x86_64, which recently got requirement > > > > of CONFIG_RELOCATABLE for EFI (and it looked like a good thing > > > > to have anyways). > > > > > > > > > > i386 on an Atom N270-based laptop (Aspire One 150). > > > (It uses a weird BIOS that may actually be EFI or similar > > > underneath, but only exposes the BIOS api.) > > > the modules are there but they don't load for some reason. > > > It does not happen with x86_64. > > > > I wonder what is going on. Maybe the CONFIG_RELOCATABLE change > > mentioned above is related? I have no idea... > > I'm suspecting that might be it. > > It's not a bug in the build environment, since the exact same system > could build a working 3.14.17 and a non-working 3.14.18. > That's what the test matrix was about. It is CONFIG_RANDOMIZE_BASE=y that triggers it. I have disabled that again on x86 vanilla kernel (and will do so on grsec kernel too which also seems to be affected) Thanks you for reporting it, for your help finding the cause and for your patience. -nc --- Unsubscribe: alpine-devel+unsubscribe@lists.alpinelinux.org Help: alpine-devel+help@lists.alpinelinux.org ---