From: Duncan <1i5t5.duncan@cox.net>
To: linux-btrfs@vger.kernel.org
Subject: Re: Can anyone boot a system using btrfs root with linux 3.14 or newer?
Date: Fri, 25 Apr 2014 07:02:21 +0000 (UTC) [thread overview]
Message-ID: <pan$282b2$5991d930$3e5bf99$a27adcf2@cox.net> (raw)
In-Reply-To: 5359A77C.70209@fb.com
Chris Mason posted on Thu, 24 Apr 2014 20:08:28 -0400 as excerpted:
> On 04/24/2014 08:04 PM, Chris Murphy wrote:
>> So I don't think the order is it. The biggest difference I'm seeing
>> between the 3.13.11 and 3.14.1 dmesg's provided:
>>
>> 3.13.11:
>> [ 1.861740] bio: create slab <bio-1> at 1 [ 1.863389] Btrfs
>> loaded
>>
>> 3.14.1:
>> [ 3.949312] bio: create slab <bio-1> at 1 [ 3.950942] Btrfs
>> loaded
>>
>> It's happening much later, and it's right at this point VFS complains:
>> [ 4.182603] VFS: Cannot open root device "sda2" or
>> unknown-block(8,2): error -38
>>
>> The 8,2 message is consistent with the kernel not knowing what file
>> system sda2 is. Seems like it's saying "I see sda2, I know you want to
>> use it as root, but I don't know what's there - *poof*" and it panics.
That's what I'm thinking too...
>> I vaguely recall there recently being btrfs boot problems with the
>> module compiled in…
>>
> Yes, it was with the crc code. I noticed he has compression on and I'm
> wondering if we're hitting a similar ordering problem with the zlib
> init.
Everyone: I didn't think of this earlier, when I first saw the thread,
but coming home and catching up after work, I think my subconscious must
have been working on it all day, and even before I read this message, I
was wondering if it might be another variant of that CRC32 problem. I
was impatiently going thru the messages to see if someone mentioned it
before I started another subthread on it... and here it is. =:^
But both crc32 and crc32c are loaded at about the same point in both
kernels, before the filesystem tries to load, so that can't be it.
But your zlib theory looks like a good candidate, Chris (Mason), and my
sysadmin's intuition is behaving like a Geiger counter at Fukishima ATM,
so I think we're on the right track! =:^)
> The best way to know for sure is to please try with an initrd. If that
> does work we'll know it's an init ordering problem and we can track it
> down from there.
Indeed, altho as I know from experience, reading/writing that is a lot
easier than actually setting up an initr*, if you've not used one in a
decade and haven't the foggiest how to create one. (Being a gentooer
here, I ended up following a recommendation from an only semi-related
gentoo discussion, and setting up dracut for my initr* when I needed one
to support a multi-device btrfs rootfs. Wasn't too hard, but I did need
to set aside some undisturbed time to study up on it and get it
configured and working. Since this thread's about a single-device btrfs
rootfs, he got away without one until now, but...)
Meanwhile, if an initr* bypasses the issue, the fact that I'm running a
multi-device btrfs root here, and thus an initr*, would explain why I
hadn't run into the problem, here... There goes that Geiger counter
again!
--
Duncan - List replies preferred. No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master." Richard Stallman
next prev parent reply other threads:[~2014-04-25 7:02 UTC|newest]
Thread overview: 39+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-04-23 17:30 Can anyone boot a system using btrfs root with linux 3.14 or newer? Пламен Петров
2014-04-23 18:33 ` Swâmi Petaramesh
2014-04-23 18:54 ` Marc MERLIN
2014-04-23 19:02 ` Hugo Mills
2014-04-23 19:06 ` Пламен Петров
2014-04-23 19:15 ` Marc MERLIN
2014-04-23 19:37 ` Пламен Петров
2014-04-23 20:58 ` Marc MERLIN
2014-04-23 21:54 ` Пламен Петров
2014-04-23 22:03 ` Marc MERLIN
2014-04-23 22:20 ` Пламен Петров
2014-04-23 22:40 ` Chris Murphy
2014-04-23 22:43 ` Hugo Mills
2014-04-23 22:50 ` Marc MERLIN
2014-04-23 22:53 ` Hugo Mills
2014-04-23 22:41 ` Hugo Mills
2014-04-24 12:34 ` Chris Mason
2014-04-24 12:36 ` Chris Mason
2014-04-24 17:08 ` Пламен Петров
2014-04-24 17:19 ` Пламен Петров
2014-04-24 17:33 ` Marc MERLIN
2014-04-24 17:44 ` Пламен Петров
2014-04-24 18:51 ` Пламен Петров
2014-04-24 19:31 ` Marc MERLIN
2014-04-24 20:26 ` Пламен Петров
2014-04-24 21:47 ` Chris Murphy
2014-04-24 21:06 ` Chris Murphy
2014-04-24 21:23 ` Пламен Петров
[not found] ` <000c01cf600b$b01f6cf0$105e46d0$@petrovi.no-ip.info>
2014-04-24 23:07 ` Marc MERLIN
2014-04-25 0:04 ` Chris Murphy
2014-04-25 0:08 ` Chris Mason
2014-04-25 5:04 ` Пламен Петров
2014-04-25 7:02 ` Duncan [this message]
2014-04-25 5:03 ` Пламен Петров
2014-04-23 19:06 ` Kai Krakow
2014-04-23 20:25 ` Calvin Walton
2014-04-23 22:34 ` Chris Murphy
2014-04-24 3:23 ` Chris Murphy
2014-04-24 6:27 ` Fajar A. Nugraha
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='pan$282b2$5991d930$3e5bf99$a27adcf2@cox.net' \
--to=1i5t5.duncan@cox.net \
--cc=linux-btrfs@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox