Re: [alpine-devel] Re: Cannot mount root filesystem with latest vanilla kernel
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.)
some more debug info:
this is booting vanilla edge iso and entering initramfs:
/ # insmod /lib/modules/3.14.19/kernel/fs/ext2/ext2.ko
insmod: can't insert '/lib/modules/3.14.19/kernel/fs/ext2/ext2.ko': unknown symbol in module, or unknown parameter
/ # modprobe ext2
modprobe: can't load module ext2 (kernel/fs/ext2/ext2.ko): Invalid argument
/ # modprobe squashfs
modprobe: can't load module squashfs (kernel/fs/squashfs/squashfs.ko): Invalid argument
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...
> Isaac Dunham
Received on Thu Sep 18 2014 - 16:53:27 UTC