For discussion of Alpine Linux development and developer support

13 2

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

Isaac Dunham
Details
Message ID
<20140914201702.GA513@muslin>
Sender timestamp
1410725823
DKIM signature
missing
Download raw message
Hello,
Posting from a different distro, since I can't boot Alpine.

I've got a bit of a problem with the latest linux-vanilla kernel.
Yesterday I did an update and upgrade, and today I'm getting an
initramfs shell whenever I boot.
I have /dev/sda14 as root, formatted as ext2.
I can mount it from another distro, as ext2.

When I try mounting /dev/sda14 on /sysroot without specifying fstype,
I get this errormessage:
mount: cannot mount /dev/sda14 on /sysroot: no such file or directory
and there are no new messages in dmesg.

If I specify -t ext2 (or ext3 or ext4), I get 
mount: cannot mount /dev/sda14 on /sysroot: no such device
and dmesg has a large number of complaints about symbol version mismatches
in the filesystem driver (ext2 or ext3 or ext4).

Any ideas how to fix it?

Thanks,
Isaac Dunham


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---

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

Isaac Dunham
Details
Message ID
<20140914210508.GA1775@newbook>
In-Reply-To
<20140914201702.GA513@muslin> (view parent)
Sender timestamp
1410728708
DKIM signature
missing
Download raw message
On Sun, Sep 14, 2014 at 01:17:02PM -0700, Isaac Dunham wrote:
> Hello,
> Posting from a different distro, since I can't boot Alpine.
> 
> I've got a bit of a problem with the latest linux-vanilla kernel.
> Yesterday I did an update and upgrade, and today I'm getting an
> initramfs shell whenever I boot.
> I have /dev/sda14 as root, formatted as ext2.
> I can mount it from another distro, as ext2.
> 
> When I try mounting /dev/sda14 on /sysroot without specifying fstype,
> I get this errormessage:
> mount: cannot mount /dev/sda14 on /sysroot: no such file or directory
> and there are no new messages in dmesg.
> 
> If I specify -t ext2 (or ext3 or ext4), I get 
> mount: cannot mount /dev/sda14 on /sysroot: no such device
> and dmesg has a large number of complaints about symbol version mismatches
> in the filesystem driver (ext2 or ext3 or ext4).
> 
> Any ideas how to fix it?

apk fix linux-vanilla
solved it.

No idea what caused this, though.

Thanks,
Isaac Dunham


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---

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

Natanael Copa
Details
Message ID
<20140915113105.182f422b@ncopa-desktop.alpinelinux.org>
In-Reply-To
<20140914210508.GA1775@newbook> (view parent)
Sender timestamp
1410773465
DKIM signature
missing
Download raw message
On Sun, 14 Sep 2014 14:05:08 -0700
Isaac Dunham <ibid.ag@gmail.com> wrote:

> On Sun, Sep 14, 2014 at 01:17:02PM -0700, Isaac Dunham wrote:
> > Hello,
> > Posting from a different distro, since I can't boot Alpine.
> > 
> > I've got a bit of a problem with the latest linux-vanilla kernel.
> > Yesterday I did an update and upgrade, and today I'm getting an
> > initramfs shell whenever I boot.
> > I have /dev/sda14 as root, formatted as ext2.
> > I can mount it from another distro, as ext2.
> > 
> > When I try mounting /dev/sda14 on /sysroot without specifying fstype,
> > I get this errormessage:
> > mount: cannot mount /dev/sda14 on /sysroot: no such file or directory
> > and there are no new messages in dmesg.
> > 
> > If I specify -t ext2 (or ext3 or ext4), I get 
> > mount: cannot mount /dev/sda14 on /sysroot: no such device
> > and dmesg has a large number of complaints about symbol version mismatches
> > in the filesystem driver (ext2 or ext3 or ext4).
> > 
> > Any ideas how to fix it?
> 
> apk fix linux-vanilla
> solved it.
> 
> No idea what caused this, though.

i think update-extlinux or mkinitfs trigger failed for some reason so
the initramfs image got broken. I have no idea why though.

-nc


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---

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

Isaac Dunham
Details
Message ID
<20140915193509.GA545@muslin>
In-Reply-To
<20140915113105.182f422b@ncopa-desktop.alpinelinux.org> (view parent)
Sender timestamp
1410809709
DKIM signature
missing
Download raw message
On Mon, Sep 15, 2014 at 11:31:05AM +0200, Natanael Copa wrote:
> On Sun, 14 Sep 2014 14:05:08 -0700
> Isaac Dunham <ibid.ag@gmail.com> wrote:
> 
> > On Sun, Sep 14, 2014 at 01:17:02PM -0700, Isaac Dunham wrote:
> > > Hello,
> > > Posting from a different distro, since I can't boot Alpine.
> > > 
> > > I've got a bit of a problem with the latest linux-vanilla kernel.
> > > Yesterday I did an update and upgrade, and today I'm getting an
> > > initramfs shell whenever I boot.
> > > I have /dev/sda14 as root, formatted as ext2.
> > > I can mount it from another distro, as ext2.
> > > 
> > > When I try mounting /dev/sda14 on /sysroot without specifying fstype,
> > > I get this errormessage:
> > > mount: cannot mount /dev/sda14 on /sysroot: no such file or directory
> > > and there are no new messages in dmesg.
> > > 
> > > If I specify -t ext2 (or ext3 or ext4), I get 
> > > mount: cannot mount /dev/sda14 on /sysroot: no such device
> > > and dmesg has a large number of complaints about symbol version mismatches
> > > in the filesystem driver (ext2 or ext3 or ext4).
> > > 
> > > Any ideas how to fix it?
> > 
> > apk fix linux-vanilla
> > solved it.
> > 
> > No idea what caused this, though.
> 
> i think update-extlinux or mkinitfs trigger failed for some reason so
> the initramfs image got broken. I have no idea why though.

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.

I am using grub1 (installed on /dev/sda8) to boot; the consistent naming
of Alpine kernels means that I can use a static entry.
grub continues to work fine with my other installs, and has not been
updated.

Could someone else test whether in Qemu, the latest linux-vanilla has
any such issues (after module loading, does
dmesg |grep symbol
show any errors?)

Thanks,
Isaac Dunham


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---

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

Isaac Dunham
Details
Message ID
<20140916045715.GA1781@newbook>
In-Reply-To
<20140915193509.GA545@muslin> (view parent)
Sender timestamp
1410843436
DKIM signature
missing
Download raw message
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.

Thanks,
Isaac Dunham


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---

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

Isaac Dunham
Details
Message ID
<20140916234219.GA1783@newbook>
In-Reply-To
<20140916045715.GA1781@newbook> (view parent)
Sender timestamp
1410910939
DKIM signature
missing
Download raw message
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.

Thanks,
Isaac Dunham


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---

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

Isaac Dunham
Details
Message ID
<20140917154445.GA1783@newbook>
In-Reply-To
<20140917160613.45155c68@ncopa-desktop.alpinelinux.org> (view parent)
Sender timestamp
1410968686
DKIM signature
missing
Download raw message
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@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:
> 
> @@ -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.)

Thanks,
Isaac Dunham



---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---

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

Natanael Copa
Details
Message ID
<20140917160613.45155c68@ncopa-desktop.alpinelinux.org>
In-Reply-To
<20140916234219.GA1783@newbook> (view parent)
Sender timestamp
1410962773
DKIM signature
missing
Download raw message
On Tue, 16 Sep 2014 16:42:19 -0700
Isaac Dunham <ibid.ag@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:

@@ -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).

-nc

> 
> Thanks,
> Isaac Dunham



---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---

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

Isaac Dunham
Details
Message ID
<20140918160414.GA25585@newbook>
In-Reply-To
<20140918165327.709c57f5@ncopa-desktop.alpinelinux.org> (view parent)
Sender timestamp
1411056255
DKIM signature
missing
Download raw message
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@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@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:
> > > 
> > > @@ -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@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---

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

Natanael Copa
Details
Message ID
<20140918164143.502de515@ncopa-desktop.alpinelinux.org>
In-Reply-To
<20140917154445.GA1783@newbook> (view parent)
Sender timestamp
1411051303
DKIM signature
missing
Download raw message
On Wed, 17 Sep 2014 08:44:46 -0700
Isaac Dunham <ibid.ag@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@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:
> > 
> > @@ -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.)

I think something got mis-compiled for x86. not sure how or why.

The compile itself seems to be ok:
http://bld1.alpinelinux.org/buildlogs/build-edge-x86/main/linux-vanilla/linux-vanilla-3.14.18-r0.log

But I get errors when trying to boot the cdrom in qemu on x86. It boots
but the squashfs is not getting loaded in initramfs causing the modloop
fail to mount.

I wonder if the script that generates the kernel module deps is broken
or maybe depmod or insmod.

-nc


> 
> Thanks,
> Isaac Dunham
> 



---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---

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

Natanael Copa
Details
Message ID
<20140918165327.709c57f5@ncopa-desktop.alpinelinux.org>
In-Reply-To
<20140917154445.GA1783@newbook> (view parent)
Sender timestamp
1411052007
DKIM signature
missing
Download raw message
On Wed, 17 Sep 2014 08:44:46 -0700
Isaac Dunham <ibid.ag@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@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:
> > 
> > @@ -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...


> Thanks,
> Isaac Dunham
> 



---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---

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

Isaac Dunham
Details
Message ID
<20140919141123.GA2020@newbook>
In-Reply-To
<20140919112354.2893501e@ncopa-desktop.alpinelinux.org> (view parent)
Sender timestamp
1411135884
DKIM signature
missing
Download raw message
On Fri, Sep 19, 2014 at 11:23:54AM +0200, Natanael Copa wrote:
> On Thu, 18 Sep 2014 09:04:15 -0700
> Isaac Dunham <ibid.ag@gmail.com> wrote:
> 
> > On Thu, Sep 18, 2014 at 04:53:27PM +0200, Natanael Copa wrote:
> > > 
> > > 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.

Does this occur with kmod (ie, is Busybox being overly simplistic,
or does this flat-out break the kernel?)

I suppose that it should be reported to either kernel.org or Busybox,
depending which it is.

Thanks,
Isaac Dunham



---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---

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

Natanael Copa
Details
Message ID
<20140919112354.2893501e@ncopa-desktop.alpinelinux.org>
In-Reply-To
<20140918160414.GA25585@newbook> (view parent)
Sender timestamp
1411118634
DKIM signature
missing
Download raw message
On Thu, 18 Sep 2014 09:04:15 -0700
Isaac Dunham <ibid.ag@gmail.com> 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 <ibid.ag@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@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:
> > > > 
> > > > @@ -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.

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
---

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

Natanael Copa
Details
Message ID
<20140922113900.095faeb8@ncopa-desktop.alpinelinux.org>
In-Reply-To
<20140919141123.GA2020@newbook> (view parent)
Sender timestamp
1411378740
DKIM signature
missing
Download raw message
On Fri, 19 Sep 2014 07:11:24 -0700
Isaac Dunham <ibid.ag@gmail.com> wrote:

> On Fri, Sep 19, 2014 at 11:23:54AM +0200, Natanael Copa wrote:
> > On Thu, 18 Sep 2014 09:04:15 -0700
> > Isaac Dunham <ibid.ag@gmail.com> wrote:
> > 
> > > On Thu, Sep 18, 2014 at 04:53:27PM +0200, Natanael Copa wrote:
> > > > 
> > > > 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.
> 
> Does this occur with kmod (ie, is Busybox being overly simplistic,
> or does this flat-out break the kernel?)

I didn't have time to test that out.

> I suppose that it should be reported to either kernel.org or Busybox,
> depending which it is.

I suspect it is a bug in kernel actually, but am not sure.

I don't have capacity to follow it up at the moment. sorry :-/

-nc


---
Unsubscribe:  alpine-devel+unsubscribe@lists.alpinelinux.org
Help:         alpine-devel+help@lists.alpinelinux.org
---