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

newer
[arch-general] How can I delete my...

older
Re: [arch-general] Kernel modules...

Peter Nabbefeld

22 Jul 2018 22 Jul '18

12:27 p.m.

Hello, I've updated my installation yesterday, also doing an update of the Linux kernel to 4.17.8. When starting this morning, kernel modules rejected to load, so I even couldn't access the internet. I've downgraded Linux now to 4.17.2, but still have some problems (probably because I only downgraded the kernel itself). I cannot find the error message from the service again, sorry, so I cannot tell You, it had to do with some security parameter not set. According to the description of kernel downgrading in the wiki, I should have downgraded linux-headers, too, but these are not in my package cache - are they included in the kernel package now? How can I find out, which other kernel modules need to be downgraded? Kind regards Peter

Show replies by date

Peter Nabbefeld

22 Jul 22 Jul

1:25 p.m.

Am 22.07.2018 um 11:27 schrieb Peter Nabbefeld:

...

Hello,

I've updated my installation yesterday, also doing an update of the Linux kernel to 4.17.8. When starting this morning, kernel modules rejected to load, so I even couldn't access the internet.

I've downgraded Linux now to 4.17.2, but still have some problems (probably because I only downgraded the kernel itself).

I cannot find the error message from the service again, sorry, so I cannot tell You, it had to do with some security parameter not set.

According to the description of kernel downgrading in the wiki, I should have downgraded linux-headers, too, but these are not in my package cache - are they included in the kernel package now?

How can I find out, which other kernel modules need to be downgraded?

Kind regards

Peter

AFAIR, it was sth. starting with "crypt_"

Ralph Corderoy

1:40 p.m.

Hi Peter,

...

I cannot find the error message from the service again, sorry, so I cannot tell You, it had to do with some security parameter not set.

It might be in journalctl(1)'s output.

...

According to the description of kernel downgrading in the wiki, I should have downgraded linux-headers, too, but these are not in my package cache - are they included in the kernel package now?

No. It's still a package. https://www.archlinux.org/packages/core/x86_64/linux-headers/ $ pacman -Slq | egrep '^linux($|-)' linux linux-api-headers linux-atm linux-docs linux-firmware linux-headers linux-lts linux-lts-docs linux-lts-headers linux-hardened linux-hardened-docs linux-hardened-headers linux-zen linux-zen-docs linux-zen-headers linux-tools-meta $ If your cache no longer has old packages, you can use the online Archive. https://wiki.archlinux.org/index.php/Downgrading_packages#Arch_Linux_Archive -- Cheers, Ralph. https://plus.google.com/+RalphCorderoy

Ralf Mardorf

2:19 p.m.

On Sun, 22 Jul 2018 11:40:07 +0100, Ralph Corderoy wrote:

...

If your cache no longer has old packages, you can use the online Archive. https://wiki.archlinux.org/index.php/Downgrading_packages#Arch_Linux_Archive

"Bash script for downgrading one or more packages to a version in your cache or the A.L.A." https://aur.archlinux.org/packages/downgrade/

Peter Nabbefeld

2:36 p.m.

Am 22.07.2018 um 13:19 schrieb Ralf Mardorf:

...

On Sun, 22 Jul 2018 11:40:07 +0100, Ralph Corderoy wrote:

...
If your cache no longer has old packages, you can use the online Archive. https://wiki.archlinux.org/index.php/Downgrading_packages#Arch_Linux_Archive "Bash script for downgrading one or more packages to a version in your cache or the A.L.A."

https://aur.archlinux.org/packages/downgrade/

Thank You, Ralf! Without loading any kernel modules, I didn't have access to the internet, so the A.L.A. wouldn't have worked. But I'll read about it, most interesting will be if I can downgrade "just the rest" of the kernel, as 4.17.8 is not working for me. BTW, I'm usually not working with tar.xz files and the list option doesn't work as expected - what's the equivalent to "unzip -l" and "unzip -c"? I'd like to look at 4.17.8's config.gz to check which parameter is probably missing. Kind regards Peter

Ralph Corderoy

3:34 p.m.

Hi Peter,

...

BTW, I'm usually not working with tar.xz files and the list option doesn't work as expected

It works as we expect. You need to show precisely what you did. Search for `list' in tar(1) and you'll find `--list'. Most users do `tar tvf foo.tar.xz' for a verbose listing. -- Cheers, Ralph. https://plus.google.com/+RalphCorderoy

Peter Nabbefeld

4:30 p.m.

Am 22.07.2018 um 14:34 schrieb Ralph Corderoy:

...

Hi Peter,

...
BTW, I'm usually not working with tar.xz files and the list option doesn't work as expected It works as we expect. You need to show precisely what you did. Search for `list' in tar(1) and you'll find `--list'. Most users do `tar tvf foo.tar.xz' for a verbose listing.

Thank You! Just didn't expect I could directly use the tar command - looked for sth. complicated to first use unxz ...

Ralf Mardorf

4:24 p.m.

On Sun, 22 Jul 2018 13:26:10 +0200, Peter Nabbefeld wrote:

...

Are these headers used for compilation of modules only, or do they add some more value to the running linux system, too?

Hi, the headers are only required, if you want to build something. On Sun, 22 Jul 2018 13:36:54 +0200, Peter Nabbefeld wrote:

...

BTW, I'm usually not working with tar.xz files and the list option doesn't work as expected - what's the equivalent to "unzip -l" and "unzip -c"? I'd like to look at 4.17.8's config.gz to check which parameter is probably missing.

Listing and extracting files from a package using tar: $ mkdir linux-headers-4.17.8-1 && cd linux-headers-4.17.8-1 $ cp /var/cache/pacman/pkg/linux-headers-4.17.8-1-x86_64.pkg.tar.xz . $ tar --help | grep '\-list ' -t, --list list the contents of an archive $ tar -tf linux-headers-4.17.8-1-x86_64.pkg.tar.xz | head .MTREE .BUILDINFO .PKGINFO usr/ usr/lib/ usr/lib/modules/ usr/lib/modules/4.17.8-1-ARCH/ usr/lib/modules/4.17.8-1-ARCH/build/ usr/lib/modules/4.17.8-1-ARCH/build/.config usr/lib/modules/4.17.8-1-ARCH/build/.tmp_versions/ $ ls -p linux-headers-4.17.8-1-x86_64.pkg.tar.xz $ tar -xf linux-headers-4.17.8-1-x86_64.pkg.tar.xz $ ls -p linux-headers-4.17.8-1-x86_64.pkg.tar.xz usr/ The file in the header package is named .config, not config.gz. To display the config of a running kernel run $ zcat /proc/config.gz Your request isn't clear. On Sun, 22 Jul 2018 11:27:04 +0200, you wrote:

...

I've updated my installation yesterday, also doing an update of the Linux kernel to 4.17.8. When starting this morning, kernel modules rejected to load, so I even couldn't access the internet.

You could boot and log in? Is something missing if you run 'lsmod'? Where and when do you get what message?

...

I've downgraded Linux now to 4.17.2, but still have some problems (probably because I only downgraded the kernel itself).

I cannot find the error message from the service again, sorry, so I cannot tell You, it had to do with some security parameter not set.

From what service?

...

According to the description of kernel downgrading in the wiki, I should have downgraded linux-headers, too, but these are not in my package cache - are they included in the kernel package now?

How can I find out, which other kernel modules need to be downgraded?

The headers are needed, if e.g. dkms needs to build modules. What's output do you get from 'dkms status'? Mine is $ dkms status vboxhost, 5.2.16, 4.14.34-rt27-1-rt-pussytoes, x86_64: installed vboxhost, 5.2.16, 4.16.15-rt7-1-rt, x86_64: installed vboxhost, 5.2.16, 4.16.18-rt10-1-rt-securityink, x86_64: installed vboxhost, 5.2.16, 4.16.18-rt9-1-rt-cornflower, x86_64: installed vboxhost, 5.2.16, 4.17.8-1-ARCH, x86_64: installed If you try to load missing modules, what output do you get? For example $ sudo modprobe -av vboxdrv vboxnetadp vboxnetflt vboxpci insmod /lib/modules/4.16.18-rt10-1-rt-securityink/kernel/misc/vboxdrv.ko insmod /lib/modules/4.16.18-rt10-1-rt-securityink/kernel/misc/vboxnetadp.ko insmod /lib/modules/4.16.18-rt10-1-rt-securityink/kernel/misc/vboxnetflt.ko insmod /lib/modules/4.16.18-rt10-1-rt-securityink/kernel/misc/vboxpci.ko Since you can email, you have access to the Internet, consider to read Wikis such as https://wiki.archlinux.org/index.php/Kernel_module , also consider to read man pages and/or '--help' provided by commands.

Peter Nabbefeld

2:26 p.m.

Am 22.07.2018 um 12:40 schrieb Ralph Corderoy:

...

Hi Peter,

...
I cannot find the error message from the service again, sorry, so I cannot tell You, it had to do with some security parameter not set. It might be in journalctl(1)'s output.

Sorry, cannot find that. :-/

...

...
According to the description of kernel downgrading in the wiki, I should have downgraded linux-headers, too, but these are not in my package cache - are they included in the kernel package now? No. It's still a package. https://www.archlinux.org/packages/core/x86_64/linux-headers/

$ pacman -Slq | egrep '^linux($|-)' linux linux-api-headers linux-atm linux-docs linux-firmware linux-headers linux-lts linux-lts-docs linux-lts-headers linux-hardened linux-hardened-docs linux-hardened-headers linux-zen linux-zen-docs linux-zen-headers linux-tools-meta $

If your cache no longer has old packages, you can use the online Archive. https://wiki.archlinux.org/index.php/Downgrading_packages#Arch_Linux_Archive

Thank You, Ralph! I now wonder where the linux-headers are cached, as they're not in /var/cache/pacman/pkg, and I've checked they're installed in version 4.17.8 (so probably may cause problems). Are these headers used for compilation of modules only, or do they add some more value to the running linux system, too? Kind regards Peter

Ralph Corderoy

3:40 p.m.

...

Hi Peter,

...

...
...
I cannot find the error message from the service again, sorry, so I cannot tell You, it had to do with some security parameter not set.

It might be in journalctl(1)'s output.

Sorry, cannot find that. :-/

You have no `journalctl' command, or using it doesn't help find the error message? `journalctl -S 2018-07-20' would show all messages starting from that date, for example. https://wiki.archlinux.org/index.php/Systemd#Journal

...

...
If your cache no longer has old packages, you can use the online Archive. https://wiki.archlinux.org/index.php/Downgrading_packages#Arch_Linux_Archive

Thank You, Ralph! I now wonder where the linux-headers are cached

It's a cache so they don't have to still exist in there, especially if you've done something to clean it at some point. See when you had dealings with that package with `grep linux-headers /var/log/pacman.log'.

...

they're not in /var/cache/pacman/pkg

Are there any other `CacheDir' configured in /etc/pacman.conf ?

...

Are these headers used for compilation of modules only, or do they add some more value to the running linux system, too?

Just the former, I think, but could be wrong. https://wiki.archlinux.org/index.php/Compile_kernel_module I've never had it installed, but then I haven't built a kernel module on this system, nor do I have https://wiki.archlinux.org/index.php/Dynamic_Kernel_Module_Support -- Cheers, Ralph. https://plus.google.com/+RalphCorderoy

Peter Nabbefeld

4:18 p.m.

Am 22.07.2018 um 14:40 schrieb Ralph Corderoy:

...

...
Hi Peter,

...
...
I cannot find the error message from the service again, sorry, so I cannot tell You, it had to do with some security parameter not set. It might be in journalctl(1)'s output. Sorry, cannot find that. :-/ You have no `journalctl' command, or using it doesn't help find the error message? `journalctl -S 2018-07-20' would show all messages starting from that date, for example. https://wiki.archlinux.org/index.php/Systemd#Journal

Seems I tried some wrong search string (using grep), now I found the following: Jul 22 09:41:48 tuchola systemd-modules-load[330]: Failed to lookup alias 'crypto_user': Function not implemented

...

...
...
If your cache no longer has old packages, you can use the online Archive. https://wiki.archlinux.org/index.php/Downgrading_packages#Arch_Linux_Archive Thank You, Ralph! I now wonder where the linux-headers are cached It's a cache so they don't have to still exist in there, especially if you've done something to clean it at some point. See when you had dealings with that package with `grep linux-headers /var/log/pacman.log'.

Nope. Only "[PACMAN] Running 'pacman -U linux-4.17.2-1-x86_64.pkg.tar.xz linux-headers-4.17.2-1-x86_64.pkg.tar.xz'".

...

...
they're not in /var/cache/pacman/pkg Are there any other `CacheDir' configured in /etc/pacman.conf ?

No.

...

...
Are these headers used for compilation of modules only, or do they add some more value to the running linux system, too? Just the former, I think, but could be wrong. https://wiki.archlinux.org/index.php/Compile_kernel_module I've never had it installed, but then I haven't built a kernel module on this system, nor do I have https://wiki.archlinux.org/index.php/Dynamic_Kernel_Module_Support

So this won't hurt until I recompile some module. Don't have DKMS support, either.

Ralph Corderoy

4:55 p.m.

Hi Peter,

...

Jul 22 09:41:48 tuchola systemd-modules-load[330]: Failed to lookup alias 'crypto_user': Function not implemented

What's in /usr/lib/modules-load.d ? Is there something pulling in `crypto_user'? What package owns that file? `pacman -Qo foo'.

...

Nope. Only "[PACMAN] Running 'pacman -U linux-4.17.2-1-x86_64.pkg.tar.xz linux-headers-4.17.2-1-x86_64.pkg.tar.xz'".

So that's you manually installing linux-headers just now, and it looks like it wasn't installed before.

...

So this won't hurt until I recompile some module

Sounds like it. -- Cheers, Ralph. https://plus.google.com/+RalphCorderoy

Peter Nabbefeld

5:03 p.m.

Hi Ralph, Am 22.07.2018 um 15:55 schrieb Ralph Corderoy:

...

Hi Peter,

...
Jul 22 09:41:48 tuchola systemd-modules-load[330]: Failed to lookup alias 'crypto_user': Function not implemented What's in /usr/lib/modules-load.d ?

Only bluez.conf

...

Is there something pulling in `crypto_user'? What package owns that file? `pacman -Qo foo'.

...
Nope. Only "[PACMAN] Running 'pacman -U linux-4.17.2-1-x86_64.pkg.tar.xz linux-headers-4.17.2-1-x86_64.pkg.tar.xz'". So that's you manually installing linux-headers just now, and it looks like it wasn't installed before.

The curious issue here is, linux-headers is installed, but the package hasn't been put into the cache, so I've currently still linux-headers 4.17.8 installed, though the kernel has been downgraded to 4.17.2.

...

...
So this won't hurt until I recompile some module Sounds like it.

Ralph Corderoy

5:10 p.m.

Hi Peter,

...

...
...
alias 'crypto_user': Function not implemented

What's in /usr/lib/modules-load.d ?

Only bluez.conf

OK, and...

...

...
Is there something pulling in `crypto_user'?

...what's in the file? And...

...

...
What package owns that file? `pacman -Qo foo'.

I think therein lies your answer.

...

...
...
Nope. Only "[PACMAN] Running 'pacman -U linux-4.17.2-1-x86_64.pkg.tar.xz linux-headers-4.17.2-1-x86_64.pkg.tar.xz'".

So that's you manually installing linux-headers just now, and it looks like it wasn't installed before.

The curious issue here is, linux-headers is installed, but the package hasn't been put into the cache

Because you obtained it directly and upgrade from it with `-U'. The cache is of packages sync'd with `-S'.

...

I've currently still linux-headers 4.17.8 installed, though the kernel has been downgraded to 4.17.2.

`pacman -Qi linux-headers' should show `Required by' as `None'. Remove it with `sudo -i pacman -R linux-headers'. -- Cheers, Ralph. https://plus.google.com/+RalphCorderoy

Ralf Mardorf

5:27 p.m.

On Sun, 22 Jul 2018 15:10:30 +0100, Ralph Corderoy wrote:

...

...
The curious issue here is, linux-headers is installed, but the package hasn't been put into the cache

Because you obtained it directly and upgrade from it with `-U'. The cache is of packages sync'd with `-S'.

The package is not for packages that are already stored on your machine, but actually it is for packages installed by the -U option, too, if you install by using an URL instead of a path on your machine. However, I was mistaken regarding the signature and -Sc. $ ls -hl /var/cache/pacman/pkg/agg* ls: cannot access '/var/cache/pacman/pkg/agg*': No such file or directory $ sudo pacman -U https://ind.mirror.pkgbuild.com/community/os/x86_64/agg-2.5-9-x86_64.pkg.tar... [snip] $ ls -hl /var/cache/pacman/pkg/agg* -rw-r--r-- 1 root root 257K Jun 16 23:12 /var/cache/pacman/pkg/agg-2.5-9-x86_64.pkg.tar.xz -rw-r--r-- 1 root root 310 Jun 16 23:13 /var/cache/pacman/pkg/agg-2.5-9-x86_64.pkg.tar.xz.sig $ sudo pacman -R agg [snip] $ sudo pacman -Sc [snip] $ ls -hl /var/cache/pacman/pkg/agg* ls: cannot access '/var/cache/pacman/pkg/agg*': No such file or directory

Peter Nabbefeld

5:32 p.m.

Am 22.07.2018 um 16:10 schrieb Ralph Corderoy:

...

Hi Peter,

...
...
...
alias 'crypto_user': Function not implemented What's in /usr/lib/modules-load.d ? Only bluez.conf OK, and...

...
...
Is there something pulling in `crypto_user'? ...what's in the file?

Strange to me: Just the entry "crypto_user" - I'd usually expect some more config ... ;-)

...

And...

...
...
What package owns that file? `pacman -Qo foo'. /usr/lib/modules-load.d/bluez.conf is contained in bluez 5.50-3

...

I think therein lies your answer.

...
...
...
Nope. Only "[PACMAN] Running 'pacman -U linux-4.17.2-1-x86_64.pkg.tar.xz linux-headers-4.17.2-1-x86_64.pkg.tar.xz'". So that's you manually installing linux-headers just now, and it looks like it wasn't installed before. The curious issue here is, linux-headers is installed, but the package hasn't been put into the cache Because you obtained it directly and upgrade from it with `-U'. The cache is of packages sync'd with `-S'.

No. Usually I'm always using "pacman -Syu". I couldn't obtain any package manually, because I couldn't access the internet, when I couldn't load kernel modules.

...

...
I've currently still linux-headers 4.17.8 installed, though the kernel has been downgraded to 4.17.2. `pacman -Qi linux-headers' should show `Required by' as `None'.

It shows: "Error: Package 'linux-headers' not found"

...

Remove it with `sudo -i pacman -R linux-headers'.

Cannot remove. Oops - just looked again at my pacman output - they have never been installed ... obviously I never needed them.

Ralf Mardorf

6:07 p.m.

On Sun, 22 Jul 2018 16:32:49 +0200, Peter Nabbefeld wrote:

...

Am 22.07.2018 um 16:10 schrieb Ralph Corderoy:

...
`pacman -Qi linux-headers' should show `Required by' as `None'.

It shows: "Error: Package 'linux-headers' not found"

...
Remove it with `sudo -i pacman -R linux-headers'.

Cannot remove. Oops - just looked again at my pacman output - they have never been installed ... obviously I never needed them.

If the query already returns that a package isn't installed it makes no sense trying to uninstall it. You probably confused linux-headers with linux-api-headers, since those are required. $ pacman -Qs headers | grep linux local/linux-api-headers 4.16.1-1 local/linux-headers 4.17.8-1 local/linux-rt-cornflower-headers 4.16.18_rt9-1 local/linux-rt-headers 4.16.15_rt7-1 local/linux-rt-pussytoes-headers 4.14.34_rt27-1 local/linux-rt-securityink-headers 4.16.18_rt10-1 $ pactree -r linux-api-headers | head -2 linux-api-headers └─glibc On Sun, 22 Jul 2018 16:27:29 +0200, Ralf Mardorf wrote:

...

The package is not for packages...

It should read that the cache is not for packages... However, this isn't troubleshooting, it's wild disorder. 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.

Peter Nabbefeld

23 Jul 23 Jul

12:18 a.m.

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).

Kind  regards

Peter

Jagannathan Tiruvallur Eachambadi

3:25 a.m.

On 22-07-18 23:18:39 +0200, Peter Nabbefeld wrote:

...

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. In Arch Linux, kernel updates blow away the old modules so you cannot load modules anymore. Downgrading will just revert that situation and it does not need internet: pacman -U /var/cache/pacman/pkg/linux-version.pkg.tar.xz should do it. ProTip: reboot after kernel updates.

TBH this email thread was confusing. -- Regards Jagan PUBKEY: https://j605.tk/pgp

Peter Nabbefeld

9:47 a.m.

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

Ralf Mardorf

10:59 a.m.

On Mon, 23 Jul 2018 08:47:51 +0200, Peter Nabbefeld wrote:

...

CONFIG_CRYPTO_SALSA20_X86_64=m

I don't know if this helps. 4.17.9-1 moved from Staging to Testing and at least the version from Staging contains CONFIG_CRYPTO_SALSA20. $ uname -rm; zgrep SALSA /proc/config.gz 4.17.9-1-ARCH x86_64 CONFIG_CRYPTO_SALSA20=m $ grep SALSA /lib/modules/4.17.9-1-ARCH/build/.config CONFIG_CRYPTO_SALSA20=m However, actually it now also contains CONFIG_CRYPTO_SALSA20_X86_64. $ asp update [snip] $ asp checkout linux-headers [snip] $ grep pkg.e.= linux/trunk/PKGBUILD pkgver=4.17.9 pkgrel=1 $ grep SALSA linux/trunk/config CONFIG_CRYPTO_SALSA20=m CONFIG_CRYPTO_SALSA20_X86_64=m

Peter Nabbefeld

11:27 a.m.

Am 23.07.2018 um 09:59 schrieb Ralf Mardorf:

...

On Mon, 23 Jul 2018 08:47:51 +0200, Peter Nabbefeld wrote:

...
CONFIG_CRYPTO_SALSA20_X86_64=m I don't know if this helps. 4.17.9-1 moved from Staging to Testing and at least the version from Staging contains CONFIG_CRYPTO_SALSA20.

$ uname -rm; zgrep SALSA /proc/config.gz 4.17.9-1-ARCH x86_64 CONFIG_CRYPTO_SALSA20=m $ grep SALSA /lib/modules/4.17.9-1-ARCH/build/.config CONFIG_CRYPTO_SALSA20=m

However, actually it now also contains CONFIG_CRYPTO_SALSA20_X86_64.

$ asp update [snip] $ asp checkout linux-headers [snip] $ grep pkg.e.= linux/trunk/PKGBUILD pkgver=4.17.9 pkgrel=1 $ grep SALSA linux/trunk/config CONFIG_CRYPTO_SALSA20=m CONFIG_CRYPTO_SALSA20_X86_64=m

Thank You, Ralph! Tried to get that file from testing but couldn't find out how. Just activating the repo didn't help, probably I'd have to use some other mirror. It seems, CONFIG_CRYPTO_SALSA20 activates the external API (to be used by modules and/or applications) while CONFIG_CRYPTO_SALSA20_X86_64 provides the implementation, so it *should* help (if this is the stream cipher used by bluez). So waiting for the next update. :) Kind regards Peter

Ralf Mardorf

11:43 a.m.

On Mon, 23 Jul 2018 10:27:45 +0200, Peter Nabbefeld wrote:

...

Tried to get that file from testing but couldn't find out how. Just activating the repo didn't help, probably I'd have to use some other mirror.

Did you run pacman -Syu? If so, then the mirror perhaps isn't already synced, since it just moved from Staging to Testing. You could install it by running sudo pacman -U https://jpn.mirror.pkgbuild.com/testing/os/x86_64/linux{,-headers,-docs}-4.17.9-1-x86_64.pkg.tar.xz but it doesn't solve this issue, see [1].

...

It seems, CONFIG_CRYPTO_SALSA20 activates the external API (to be used by modules and/or applications) while CONFIG_CRYPTO_SALSA20_X86_64 provides the implementation, so it *should* help (if this is the stream cipher used by bluez).

I don't have knowledge about this. [1] 4.17.8 still in Core allegedly also contains it. $ grep pkg.e.= linux/repos/core-x86_64/PKGBUILD pkgver=4.17.8 pkgrel=1 $ grep SALSA linux/repos/core-x86_64/config CONFIG_CRYPTO_SALSA20=m CONFIG_CRYPTO_SALSA20_X86_64=m I uninstalled $ uname -a Linux archlinux 4.17.9-1-ARCH #1 SMP PREEMPT Sun Jul 22 20:23:36 UTC 2018 x86_64 GNU/Linux from Staging and removed it from the cache and then installed it from Testing and rebooted. It remains $ uname -a Linux archlinux 4.17.9-1-ARCH #1 SMP PREEMPT Sun Jul 22 20:23:36 UTC 2018 x86_64 GNU/Linux $ zgrep SALSA /proc/config.gz CONFIG_CRYPTO_SALSA20=m $ grep SALSA /lib/modules/4.17.9-1-ARCH/build/.config CONFIG_CRYPTO_SALSA20=m so it differs from config provided by the asp checkout grep SALSA linux/repos/testing-x86_64/config CONFIG_CRYPTO_SALSA20=m CONFIG_CRYPTO_SALSA20_X86_64=m FWIW $ grep SALSA linux/repos/core-i686/config.i686 CONFIG_CRYPTO_SALSA20=m CONFIG_CRYPTO_SALSA20_586=m

Levente Polyak

11:53 a.m.

On 07/23/2018 10:43 AM, Ralf Mardorf wrote:

...

[1] 4.17.8 still in Core allegedly also contains it.

$ grep pkg.e.= linux/repos/core-x86_64/PKGBUILD pkgver=4.17.8 pkgrel=1 $ grep SALSA linux/repos/core-x86_64/config CONFIG_CRYPTO_SALSA20=m CONFIG_CRYPTO_SALSA20_X86_64=m

I uninstalled

$ uname -a Linux archlinux 4.17.9-1-ARCH #1 SMP PREEMPT Sun Jul 22 20:23:36 UTC 2018 x86_64 GNU/Linux

from Staging and removed it from the cache and then installed it from Testing and rebooted.

It remains

$ uname -a Linux archlinux 4.17.9-1-ARCH #1 SMP PREEMPT Sun Jul 22 20:23:36 UTC 2018 x86_64 GNU/Linux $ zgrep SALSA /proc/config.gz CONFIG_CRYPTO_SALSA20=m $ grep SALSA /lib/modules/4.17.9-1-ARCH/build/.config CONFIG_CRYPTO_SALSA20=m

so it differs from config provided by the asp checkout

grep SALSA linux/repos/testing-x86_64/config CONFIG_CRYPTO_SALSA20=m CONFIG_CRYPTO_SALSA20_X86_64=m

FWIW

$ grep SALSA linux/repos/core-i686/config.i686 CONFIG_CRYPTO_SALSA20=m CONFIG_CRYPTO_SALSA20_586=m

No, it won't come back. The reason for the mismatch is that the config in the checkout is not regularly updated/synced for every minor kernel bump and removed options will remain there while the effective config at the end (which you can observe via config.gz) of cause won't have it. CRYPTO_SALSA20_X86_64 was removed in 4.17.7 https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=...

Ralf Mardorf

12:04 p.m.

On Mon, 2018-07-23 at 10:53 +0200, Levente Polyak wrote:

...

No, it won't come back. The reason for the mismatch is that the config in the checkout is not regularly updated/synced for every minor kernel bump and removed options will remain there while the effective config at the end (which you can observe via config.gz) of cause won't have it.

CRYPTO_SALSA20_X86_64 was removed in 4.17.7

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=...

Levente, thank you for the clarification. Peter, regarding the clarification my mail from 10:58 +0200 is more or less irrelevant. Regards, Ralf

Peter Nabbefeld

12:25 p.m.

Am 23.07.2018 um 10:53 schrieb Levente Polyak via arch-general:

...

On 07/23/2018 10:43 AM, Ralf Mardorf wrote:

...
[1] 4.17.8 still in Core allegedly also contains it.

$ grep pkg.e.= linux/repos/core-x86_64/PKGBUILD pkgver=4.17.8 pkgrel=1 $ grep SALSA linux/repos/core-x86_64/config CONFIG_CRYPTO_SALSA20=m CONFIG_CRYPTO_SALSA20_X86_64=m

I uninstalled

$ uname -a Linux archlinux 4.17.9-1-ARCH #1 SMP PREEMPT Sun Jul 22 20:23:36 UTC 2018 x86_64 GNU/Linux

from Staging and removed it from the cache and then installed it from Testing and rebooted.

It remains

$ uname -a Linux archlinux 4.17.9-1-ARCH #1 SMP PREEMPT Sun Jul 22 20:23:36 UTC 2018 x86_64 GNU/Linux $ zgrep SALSA /proc/config.gz CONFIG_CRYPTO_SALSA20=m $ grep SALSA /lib/modules/4.17.9-1-ARCH/build/.config CONFIG_CRYPTO_SALSA20=m

so it differs from config provided by the asp checkout

grep SALSA linux/repos/testing-x86_64/config CONFIG_CRYPTO_SALSA20=m CONFIG_CRYPTO_SALSA20_X86_64=m

FWIW

$ grep SALSA linux/repos/core-i686/config.i686 CONFIG_CRYPTO_SALSA20=m CONFIG_CRYPTO_SALSA20_586=m

No, it won't come back. The reason for the mismatch is that the config in the checkout is not regularly updated/synced for every minor kernel bump and removed options will remain there while the effective config at the end (which you can observe via config.gz) of cause won't have it.

CRYPTO_SALSA20_X86_64 was removed in 4.17.7

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=...

Okay, thank You. But it seems, bluetooth is depending on that module, so probably it needs a patch, then. :-/ Currently, I'll have to set my installation to not upgrade to a version

...

4.17.6.

Regards Peter

Ralf Mardorf

11:58 a.m.

PS: You wrote that with the downgraded kernel it works again. I don't know in which way CONFIG_CRYPTO_SALSA20=m and CONFIG_CRYPTO_SALSA20_X86_64=m are related to each other, perhaps it's correct that CONFIG_CRYPTO_SALSA20_X86_64 isn't shown by the config of the build kernel. What's the output of uname -rm; zgrep SALSA /proc/config.gz for the downgraded kernel, that works for you?

Peter Nabbefeld

12:22 p.m.

Am 23.07.2018 um 10:58 schrieb Ralf Mardorf:

...

PS:

You wrote that with the downgraded kernel it works again.

I don't know in which way

CONFIG_CRYPTO_SALSA20=m

and

CONFIG_CRYPTO_SALSA20_X86_64=m

are related to each other, perhaps it's correct that CONFIG_CRYPTO_SALSA20_X86_64 isn't shown by the config of the build kernel.

What's the output of

uname -rm; zgrep SALSA /proc/config.gz

for the downgraded kernel, that works for you? $ uname -rm; zgrep SALSA /proc/config.gz 4.17.2-1-ARCH x86_64 CONFIG_CRYPTO_SALSA20=m CONFIG_CRYPTO_SALSA20_X86_64=m

Ralph Corderoy

11:23 a.m.

Hi Peter,

...

Checked .config in linux-headers-4.9-1-x86_64.pkg.tar.xz (latest version I could find in the archive)

Search more carefully. $ seq 9 10 | sort 10 9 $ $ curl -sSg https://archive.archlinux.org/packages/l/linux/ | > egrep -o '\ sort -V | uniq -c | > pr -t3 8 linux-4.3 136 linux-4.8 100 linux-4.13 80 linux-4.4 96 linux-4.9 72 linux-4.14 40 linux-4.5 88 linux-4.10 80 linux-4.15 56 linux-4.6 72 linux-4.11 68 linux-4.16 64 linux-4.7 120 linux-4.12 36 linux-4.17 $ -- Cheers, Ralph. https://plus.google.com/+RalphCorderoy

Peter Nabbefeld

11:44 a.m.

Am 23.07.2018 um 10:23 schrieb Ralph Corderoy:

...

Hi Peter,

...
Checked .config in linux-headers-4.9-1-x86_64.pkg.tar.xz (latest version I could find in the archive) Search more carefully.

$ seq 9 10 | sort 10 9 $ $ curl -sSg https://archive.archlinux.org/packages/l/linux/ | > egrep -o '\ sort -V | uniq -c | > pr -t3 8 linux-4.3 136 linux-4.8 100 linux-4.13 80 linux-4.4 96 linux-4.9 72 linux-4.14 40 linux-4.5 88 linux-4.10 80 linux-4.15 56 linux-4.6 72 linux-4.11 68 linux-4.16 64 linux-4.7 120 linux-4.12 36 linux-4.17 $

Hello Ralph, I tried to get the packages list using "https://archive.org/download/archlinux_pkg_linux-headers", I didn't see any hint that the list would be incomplete or how I could see the rest. However, I only wanted to search the config file for CONFIG_CRYPTO_SALSA20_X86_64, so version wasn't so important I couldn't use it. ;-) Could You add the curl magic to the wiki, please? Next time other users may gain advantage from this. Kind regards Peter

Ralf Mardorf

22 Jul 22 Jul

5:12 p.m.

On Sun, 22 Jul 2018 16:03:20 +0200, Peter Nabbefeld wrote:

...

pacman -U

The curious issue here is, linux-headers is installed, but the package hasn't been put into the cache

If you use 'pacman -U' to install from an Arch repository by using the URL, the package as well as the signature are stored in cache. Note, 'pacman -Sc' would remove the package, but not the signature. If you use 'pacman -U' to install from a directory on your machine, no copy will be stored in cache. This makes sense, since you might install from a cache for local build packages and you unlikely want to cache the same package two times.

Peter Nabbefeld

5:18 p.m.

Am 22.07.2018 um 15:55 schrieb Ralph Corderoy:

...

Hi Peter,

...
Jul 22 09:41:48 tuchola systemd-modules-load[330]: Failed to lookup alias 'crypto_user': Function not implemented What's in /usr/lib/modules-load.d ? Is there something pulling in `crypto_user'? What package owns that file? `pacman -Qo foo'.

...
Nope. Only "[PACMAN] Running 'pacman -U linux-4.17.2-1-x86_64.pkg.tar.xz linux-headers-4.17.2-1-x86_64.pkg.tar.xz'". So that's you manually installing linux-headers just now, and it looks like it wasn't installed before.

...
So this won't hurt until I recompile some module Sounds like it.

A Diff from the kernel config files: diff config-4.17.2 config-4.17.8 3c3 < # Linux/x86 4.17.2-1 Kernel Configuration ---

...

# Linux/x86 4.17.8-1 Kernel Configuration 6295c6295 < CONFIG_SND_SOC_INTEL_BYT_CHT_NOCODEC_MACH=m

...

# CONFIG_SND_SOC_INTEL_BYT_CHT_NOCODEC_MACH is not set 6818c6818 < # CONFIG_USB_SERIAL_DEBUG is not set

...

CONFIG_USB_SERIAL_DEBUG=m 7386d7385 < CONFIG_CHARLCD=m 7398a7398 CONFIG_CHARLCD=m 9331d9330 < CONFIG_CRYPTO_SALSA20_X86_64=m

Doug Newgard

23 Jul 23 Jul

3:17 a.m.

On Sun, 22 Jul 2018 11:27:04 +0200 Peter Nabbefeld wrote:

...

Hello,

I've updated my installation yesterday, also doing an update of the Linux kernel to 4.17.8. When starting this morning, kernel modules rejected to load, so I even couldn't access the internet.

I've downgraded Linux now to 4.17.2, but still have some problems (probably because I only downgraded the kernel itself).

I cannot find the error message from the service again, sorry, so I cannot tell You, it had to do with some security parameter not set.

According to the description of kernel downgrading in the wiki, I should have downgraded linux-headers, too, but these are not in my package cache - are they included in the kernel package now?

How can I find out, which other kernel modules need to be downgraded?

Kind regards

Peter

Through this entire thread, I didn't see if you ever checked `uname -a` with the new kernel installed and rebooting.

2110

Age (days ago)

2111

Last active (days ago)

List overview

Download

32 comments

6 participants

participants (6)

Doug Newgard
Jagannathan Tiruvallur Eachambadi
Levente Polyak
Peter Nabbefeld
Ralf Mardorf
Ralph Corderoy