Mail archive
alpine-devel

Re: [alpine-devel] Re: Cannot mount root filesystem with latest vanilla kernel

From: Isaac Dunham <ibid.ag_at_gmail.com>
Date: Thu, 18 Sep 2014 09:04:15 -0700

On Thu, Sep 18, 2014 at 04:53:27PM +0200, Natanael Copa wrote:
> On Wed, 17 Sep 2014 08:44:46 -0700
> Isaac Dunham <ibid.ag_at_gmail.com> 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 <ibid.ag_at_gmail.com> 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:
> > >
> > > _at_@ -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.)
<snip>
> 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.

Thanks,
Isaac Dunham



---
Unsubscribe:  alpine-devel+unsubscribe_at_lists.alpinelinux.org
Help:         alpine-devel+help_at_lists.alpinelinux.org
---
Received on Thu Sep 18 2014 - 09:04:15 UTC