btrfs module dependencies broken in 3.14?
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:
Quoted 2 lines
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.
Signature · 2 lines
With respect, Roman
Quoted 23 lines · Roman Mamedov
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:
Quoted 2 lines
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.htmlAfter adding "crc32c" into
/etc/initramfs-tools/modules(for forced inclusion into the initramfs) and regenerating the initramfs image, the btrfs module started loading fine.
Quoted 5 lines
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.
Quoted 4 lines
--
With respect,
Roman
Signature · 5 lines
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."
Quoted 44 lines · Filipe David Manana
Quoted 23 lines · Roman Mamedov
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:
Quoted 2 lines
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.htmlAfter adding "crc32c" into
/etc/initramfs-tools/modules(for forced inclusion into the initramfs) and regenerating the initramfs image, the btrfs module started loading fine.Quoted 5 lines
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.Quoted 4 lines
--
With respect,
Roman
Quoted 6 lines
--
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
Quoted 6 lines · On Fri, 6 Jun 2014 19:31:37 +0100 WorMzy Tykashi <[email protected]>…
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.
Signature · 2 lines
With respect, Roman
Quoted 11 lines · Roman Mamedov
Quoted 6 lines · On Fri, 6 Jun 2014 19:31:37 +0100 WorMzy Tykashi <[email protected]>…
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 <[email protected]> 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 <[email protected]>, Kent Liu <[email protected]> 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 <[email protected]> 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.
Quoted 5 lines
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.
Quoted 4 lines
--
With respect,
Roman
Cheers,
WorMzy