btrfs module dependencies broken in 3.14?

btrfs module dependencies broken in 3.14?

[Roman Mamedov]

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

Hello,

Not sure if this has been reported somewhere closer to Btrfs development, and
not just in Debian... Anyways, just now I (also) hit this bug when upgrading my
kernel from 3.12.21 to 3.14.5 on one machine (but not on a number of others):

  https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=747929

I use btrfs as my root FS, and the error early in the initramfs stage, is
along the lines of:

> FATAL: Error inserting btrfs...: Unknown symbol in 
> module, or unknown parameter (see dmesg)

(noting in dmesg).

The workaround has been detailed back in 2010:
https://lists.debian.org/debian-user/2010/06/msg02060.html

After adding "crc32c" into /etc/initramfs-tools/modules (for forced inclusion
into the initramfs) and regenerating the initramfs image, the btrfs module
started loading fine.

Interesting why this problem from 2010 has resurfaced in 3.14, with 3.12
working normally. Also why not every machine with a similar setup is affected
(I have several hosts with btrfs root, although both hardware and software
configurations are not identical but quite diverse), but as I said just one
for me.

-- 
With respect,
Roman

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: btrfs module dependencies broken in 3.14?

[Filipe David Manana]

On Fri, Jun 6, 2014 at 3:40 PM, Roman Mamedov <rm@romanrm.net> wrote:
> Hello,
>
> Not sure if this has been reported somewhere closer to Btrfs development, and
> not just in Debian... Anyways, just now I (also) hit this bug when upgrading my
> kernel from 3.12.21 to 3.14.5 on one machine (but not on a number of others):
>
>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=747929
>
> I use btrfs as my root FS, and the error early in the initramfs stage, is
> along the lines of:
>
>> FATAL: Error inserting btrfs...: Unknown symbol in
>> module, or unknown parameter (see dmesg)
>
> (noting in dmesg).
>
> The workaround has been detailed back in 2010:
> https://lists.debian.org/debian-user/2010/06/msg02060.html
>
> After adding "crc32c" into /etc/initramfs-tools/modules (for forced inclusion
> into the initramfs) and regenerating the initramfs image, the btrfs module
> started loading fine.
>
> Interesting why this problem from 2010 has resurfaced in 3.14, with 3.12
> working normally. Also why not every machine with a similar setup is affected
> (I have several hosts with btrfs root, although both hardware and software
> configurations are not identical but quite diverse), but as I said just one
> for me.

Hi Roman,

This thread might help:  http://www.spinics.net/lists/linux-btrfs/msg32187.html
Since WorMzy went through similar problem(s), he might provide more
recommendations.


>
> --
> With respect,
> Roman



-- 
Filipe David Manana,

"Reasonable men adapt themselves to the world.
 Unreasonable men adapt the world to themselves.
 That's why all progress depends on unreasonable men."

Re: btrfs module dependencies broken in 3.14?

[WorMzy Tykashi]

On 6 June 2014 16:41, Filipe David Manana <fdmanana@gmail.com> wrote:
> On Fri, Jun 6, 2014 at 3:40 PM, Roman Mamedov <rm@romanrm.net> wrote:
>> Hello,
>>
>> Not sure if this has been reported somewhere closer to Btrfs development, and
>> not just in Debian... Anyways, just now I (also) hit this bug when upgrading my
>> kernel from 3.12.21 to 3.14.5 on one machine (but not on a number of others):
>>
>>   https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=747929
>>
>> I use btrfs as my root FS, and the error early in the initramfs stage, is
>> along the lines of:
>>
>>> FATAL: Error inserting btrfs...: Unknown symbol in
>>> module, or unknown parameter (see dmesg)
>>
>> (noting in dmesg).
>>
>> The workaround has been detailed back in 2010:
>> https://lists.debian.org/debian-user/2010/06/msg02060.html
>>
>> After adding "crc32c" into /etc/initramfs-tools/modules (for forced inclusion
>> into the initramfs) and regenerating the initramfs image, the btrfs module
>> started loading fine.
>>
>> Interesting why this problem from 2010 has resurfaced in 3.14, with 3.12
>> working normally. Also why not every machine with a similar setup is affected
>> (I have several hosts with btrfs root, although both hardware and software
>> configurations are not identical but quite diverse), but as I said just one
>> for me.
>
> Hi Roman,
>
> This thread might help:  http://www.spinics.net/lists/linux-btrfs/msg32187.html
> Since WorMzy went through similar problem(s), he might provide more
> recommendations.
>
>
>>
>> --
>> With respect,
>> Roman
>
>
>
> --
> Filipe David Manana,
>
> "Reasonable men adapt themselves to the world.
>  Unreasonable men adapt the world to themselves.
>  That's why all progress depends on unreasonable men."

Hi,

My solution was to write a patch for mkinitcpio (Arch initrd creation
tool) [1] so that it explicitly adds the crc32c module to the initrd
if btrfs is needed. I imagine it wouldn't be difficult to add the same
logic to debian's initrd creation tool. IIRC it already does something
similar in other cases where there's an invisible dependency like
this.

Cheers,

WorMzy

P.S. Apologies if you receive this twice, I foolishly assumed that the
gmail app on my android phone would send a plain text message as plain
text!

[1] https://mailman.archlinux.org/pipermail/arch-projects/2014-March/004093.html

Re: btrfs module dependencies broken in 3.14?

[Roman Mamedov]

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

On Fri, 6 Jun 2014 19:31:37 +0100
WorMzy Tykashi <wormzy.tykashi@gmail.com> wrote:

> My solution was to write a patch for mkinitcpio (Arch initrd creation
> tool) [1] so that it explicitly adds the crc32c module to the initrd
> if btrfs is needed. I imagine it wouldn't be difficult to add the same
> logic to debian's initrd creation tool. IIRC it already does something
> similar in other cases where there's an invisible dependency like
> this.

It was "visible" in 3.13, see the Debian bug link, there are modinfo of the
3.13 and 3.14 modules compared side by side. I wonder is there really no way to
make it show up in the actual module dependencies as before?

To me patching initrd creation tools to special-case "if btrfs then add crc32"
seems to be a really bizarre way of dealing with the issue.

-- 
With respect,
Roman

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: btrfs module dependencies broken in 3.14?

[WorMzy Tykashi]

On 6 June 2014 19:53, Roman Mamedov <rm@romanrm.net> wrote:
> On Fri, 6 Jun 2014 19:31:37 +0100
> WorMzy Tykashi <wormzy.tykashi@gmail.com> wrote:
>
>> My solution was to write a patch for mkinitcpio (Arch initrd creation
>> tool) [1] so that it explicitly adds the crc32c module to the initrd
>> if btrfs is needed. I imagine it wouldn't be difficult to add the same
>> logic to debian's initrd creation tool. IIRC it already does something
>> similar in other cases where there's an invisible dependency like
>> this.
>
> It was "visible" in 3.13, see the Debian bug link, there are modinfo of the

No, it wasn't -- libcrc32c is a different module. This confused me at
first too. :)

$ modinfo libcrc32c
filename:       /lib/modules/3.15.0-rc8-mainline/kernel/lib/libcrc32c.ko.gz
license:        GPL
description:    CRC32c (Castagnoli) calculations
author:         Clay Haapala <chaapala@cisco.com>
depends:
intree:         Y
vermagic:       3.15.0-rc8-mainline SMP preempt mod_unload modversions


$ modinfo crc32c
filename:
/lib/modules/3.15.0-rc8-mainline/kernel/arch/x86/crypto/crc32c-intel.ko.gz
alias:          crc32c-intel
alias:          crc32c
license:        GPL
description:    CRC32c (Castagnoli) optimization using Intel Hardware.
author:         Austin Zhang <austin.zhang@intel.com>, Kent Liu
<kent.liu@intel.com>
alias:          cpu:type:x86,ven*fam*mod*:feature:*0094*
depends:
intree:         Y
vermagic:       3.15.0-rc8-mainline SMP preempt mod_unload modversions
filename:
/lib/modules/3.15.0-rc8-mainline/kernel/crypto/crc32c_generic.ko.gz
softdep:        pre: crc32c
alias:          crc32c
license:        GPL
description:    CRC32c (Castagnoli) calculations wrapper for lib/crc32c
author:         Clay Haapala <chaapala@cisco.com>
depends:
intree:         Y
vermagic:       3.15.0-rc8-mainline SMP preempt mod_unload modversions

Unfortunately, as you can see, libcrc32c doesn't depend on crc32c
either, but this is covered up by initrd generating tools. See my
patch above to see that mkinitcpio already had logic for libcrc32c. My
post that Felipe linked to above has the code snippet that Debian's
initramfs-tools uses to handle this. So before, when btrfs depended on
libcrc32c, initrd creation tools automagically added crc32c as well.

> 3.13 and 3.14 modules compared side by side. I wonder is there really no way to
> make it show up in the actual module dependencies as before?
>
> To me patching initrd creation tools to special-case "if btrfs then add crc32"
> seems to be a really bizarre way of dealing with the issue.

I agree, it's a hacky workaround for a problem that shouldn't exist,
but the only other solution (that I can see) would be to get crc32c to
export a symbol that other modules can depend on. I don't know enough
about kernel modules to say whether this is a good idea or not though.

>
> --
> With respect,
> Roman

Cheers,


WorMzy