RE: Can anyone boot a system using btrfs root with linux 3.14 or newer?

From: "Пламен Петров" <plamen@petrovi.no-ip.info>
To: "'Marc MERLIN'" <marc@merlins.org>
Cc: <linux-btrfs@vger.kernel.org>
Subject: RE: Can anyone boot a system using btrfs root with linux 3.14 or newer?
Date: Thu, 24 Apr 2014 00:54:57 +0300	[thread overview]
Message-ID: <000001cf5f3e$aaf7a080$00e6e180$@petrovi.no-ip.info> (raw)
In-Reply-To: <20140423205819.GH26949@merlins.org>

[-- Attachment #1: Type: text/plain, Size: 3382 bytes --]

> -----Original Message-----
> From: Marc MERLIN [mailto:marc@merlins.org]
> Sent: Wednesday, April 23, 2014 11:58 PM
> To: Пламен Петров
> Cc: linux-btrfs@vger.kernel.org
> Subject: Re: Can anyone boot a system using btrfs root with linux 3.14 or
> newer?
> 
> On Wed, Apr 23, 2014 at 10:37:44PM +0300, Пламен Петров wrote:
> > > So now, we're kind of guessing. To save us all time, could you
> > > capture a serial console boot from the running 3.13 and then the failing
> 3.14.
> >
> > Well, for the details - see for example here:
> > https://bugzilla.kernel.org/attachment.cgi?id=133111
> > how does a 3.14.1 built the way described earlier fails.
> 
> Thanks, that helps.
> Except, now I'm perplexed.
> 
> It indeed shows btrfs loaded and your block device being detected.
> However it does not show a btrfs mount error.
> 
> I haven't had to debug this in a while, but I'm wondering if you're having a
> block device problem.
> 
> It may help to look up what error -38 translates into for that mount error.

My searches so far failed to return anything useful to solving this problem.

> 
> > And for that matter - see the whole bugzilla bug entry - I went on and
> bisected this, using the linux-stable git tree, and after that landed me on the
> commit that introduces some "shiny new btrfs feature" for 3.14 - I decided
> my git bisection has gone wrong. And because I reported it on April 17-th and
> since then there has been no activity on the bugzilla entry besides me
> updating it - I posted my problem here, for more eyes to see.
> 
> One easier way to debug this would be to create an initrd for 3.13 and 3.14.
> Make sure it works with 3.13 first, then boot 3.14 and see what error you get.
> You'll get an error from mount(8) and not the kernel and you'll be dropped to
> a shell, giving you more debug options.
> 

The initrd way will require some reading up on my part - so will have to wait for tomorrow.

> > > My guess is that if you diff both you'll likely find what went
> > > wrong, but if not you can post here.
> >
> > See the result of "diff config-v3.14.1-mix64 config-v3.13.11-mix64" in the
> attached file.
> 
> diff -u is your friend ;)
> but diff looks reasonable.
> 
> > > As for the btrfs FS format, it has not changed in a way that new
> > > kernels wouldn't be able to mount an FS from a year ago or more.
> >
> > Good to know! Thanks!
> 
> Of course, that doesn't mean you didn't find a bug saying otherwise.
> 
> If you try from an initrd, it'll make it easier to debug. 

I will have to lookup how to do that...

> You don't have to build a
> new kernel or make btrfs a module, just mounting a working initrd and then
> trying this again with userland tools will help debug.
> (alternatively, rescue boot media with your kernel would work too, but that's
> likely more work to build than an initrd)

Not more work - just replaced the kernel on the setup/rescue media with mine and the result is the same - see attached image file.

> Actually, you could also use your VM
> setup to boot another linux image running ext4 as root with your new kernel,
> setup your existing drive as sdb, and try to mount it then.
> 
> Marc
> --

Thanks for the ideas, Marc. It's nice to see someone trying to help!
-----------------
Plamen Petrov

[-- Attachment #2: rescue-media-plus-my-kernel-3.14.1.png --]
[-- Type: image/png, Size: 46112 bytes --]