There are reasons why the official ISOs are still at 6.12 LTS series. Will check at the PR when I find time.
I don’t know the reasoning behind… why it has been added in the first place - I merely reacted upon the information.
Whether it will be my MR or it will be a removal of the snippet - I will leave that to be decided by @philm and @romangg
Well, modules should only been added when they are actual modules. We should check upstream why it was added once.
Some more information: [Solved] 6.14.1-arch1-1: module crc32c_intel error / Kernel & Hardware / Arch Linux Forums
So we should rather look for the kernel version or if that module exists as a module.
At @linux-aarhus, solution from upstream is Making sure you're not a bot!
I think we should keep the kernel version check but combine it with btrfs usecase only for lower than 6.13.
If you say so… I can modify the MR to do just that
Should be like that: Handle if crc32c or crc32c_intel should be used based on kernel version (0fd501fa) · Commits · Applications / calamares · GitLab
1 Like
A bit off-topic here, but given that we are now using btrfs by default on new installs, is there any reason why btrfs support is built as a loadable kernel module instead of statically linked into the kernel binary?
For that matter, I notice that ext4 is also built as a module, rather than statically linked into the kernel.
[nx-74205:/dev/pts/3][/home/aragorn]
[aragorn] > zgrep -E 'BTRFS|EXT4' /proc/config.gz
CONFIG_EXT4_FS=m
CONFIG_EXT4_USE_FOR_EXT2=y
CONFIG_EXT4_FS_POSIX_ACL=y
CONFIG_EXT4_FS_SECURITY=y
# CONFIG_EXT4_DEBUG is not set
CONFIG_BTRFS_FS=m
CONFIG_BTRFS_FS_POSIX_ACL=y
# CONFIG_BTRFS_FS_RUN_SANITY_TESTS is not set
# CONFIG_BTRFS_DEBUG is not set
# CONFIG_BTRFS_ASSERT is not set
# CONFIG_BTRFS_FS_REF_VERIFY is not set
[nx-74205:/dev/pts/3][/home/aragorn]
[aragorn] >
Mind you, I’m just curious about the logic behind this decision. Back when I was still building my own kernels, I always statically linked the filesystem drivers I needed — I was using xfs back in the day — into the kernel binary itself, because it makes more sense if that’s what you’re going to be using anyway.
(Sorry for the off-topic, folks, but @philm will only need one post to reply to this, and he can even blend it in with a reply to someone else. Should this off-topic result in a longer exchange, then we’ll certainly split it off.)
1 Like
None of the above is a reply to the original poster, that says because of the age of the community editions they no longer work.
Age has nothing to do with it.
The issue comes from the fact that crc32c has changed with kernel 6.13.
It does only affect community editions because they are built using kernel 6.14 as opposed to the official versions which uses kernel 6.12.
2 Likes
@linux-aarhus Perfect! Thanks for the effort!
But note:
$ modinfo crc32c
name: crc32c_generic
filename: (builtin)
alias: crypto-crc32c-generic
alias: crc32c-generic
alias: crypto-crc32c
alias: crc32c
license: GPL
file: crypto/crc32c_generic
description: CRC32c (Castagnoli) calculations wrapper for lib/crc32c
author: Clay Haapala <chaapala@cisco.com>
It is built-in, therefore baked into the kernel and not a module.
I don’t see a reason why you should explicitly set crc32c, since it is NOT a module here, but part of the kernel.
2 Likes
Then perhaps remake the community one’s?
I think community ISO’s should be built with the latest LTS Kernel’s and not the latest ones which only last a few months?
1 Like
You might best address these points by speaking with the maintainers of the respective Manjaro community editions, individually.
Regards.
1 Like
That was done already: [community] publish 25.0.3 (a21e4393) · Commits · WEB / iso-info · GitLab
1 Like