[arch-general] Kernel modules not loaded after Linux update

[Peter Nabbefeld]

Am 22.07.2018 um 23:18 schrieb Peter Nabbefeld:
> Am 22.07.2018 um 17:07 schrieb Ralf Mardorf:
>> [...]
>> Could you please summarize what exactly doesn't work?
>>
>> IIUC you can't access the Internet with the computer where you got some
>> messages about missing kernel modules. IIUC you successfully downgrade
>> the kernel. We clarified that the linux-headers package is irrelevant.
>> What happens now, when using the old kernel? Since the issue started
>> after an update, what else did you update? See pacman.log.
> 1. I've run an update including a new Linux kernel (4.17.8).
> 2. After the update, systemd-modules-load.service refused to execute 
> because of the crypto_user problem.
> 3. As a result of the failing modules load service, I couldn't access 
> the internet, and even the mouse didn't work.
> 4. I then only downgraded the kernel to 4.17.2, and now everything 
> seems to work (after first start Xfce4 didn't start correctly, 
> probably some session parameters were badly set because of a 
> previously faling start).
>
> So, the situation is:
> - After update to 4.17.8 Linux failed to load the needed modules.
> - After downgrading *only* the kernel module to 4.17.2 the system is 
> working again.
>
> As obviously bluez is referring to "crypto_user" (which caused 
> systemd-modules-load.service to fail), it may be some bad linking 
> caused the problem (I'm not using DKMS).
>
> I cannot find out, which cryptographic algorithm is used by bluez, but 
> found by a diff compare, that my active config (/proc/config.gz) 
> contains the following line:
> CONFIG_CRYPTO_SALSA20_X86_64=m
> This line is not contained in linux-header-4-17.8 - this may or may 
> not be relevant, I'd need to make one more diff using 
> linux-headers-4.17.2 (probably tomorrow).
>
>
Checked .config in linux-headers-4.9-1-x86_64.pkg.tar.xz (latest version 
I could find in the archive), it also contains 
"CONFIG_CRYPTO_SALSA20_X86_64=m". And I found Salsa20 is a stream 
cipher, so it could be used in bluetooth (but couldn't verify that).

So my problem may result from this line missing in the kernel's build 
configuration (assuming it is using same linux-headers as available in 
the repository).

Kind regards

Peter