Discussion:
Kernel modules not loaded after Linux update
(too old to reply)
Peter Nabbefeld
2018-07-22 09:27:04 UTC
Permalink
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
Peter Nabbefeld
2018-07-22 10:25:47 UTC
Permalink
Post by 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
2018-07-22 10:40:07 UTC
Permalink
Hi Peter,
Post by Peter Nabbefeld
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.
Post by Peter Nabbefeld
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
2018-07-22 11:19:37 UTC
Permalink
Post by Ralph Corderoy
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
2018-07-22 11:36:54 UTC
Permalink
Post by Ralf Mardorf
Post by Ralph Corderoy
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
2018-07-22 12:34:13 UTC
Permalink
Hi Peter,
Post by Peter Nabbefeld
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
2018-07-22 13:30:12 UTC
Permalink
Post by Ralph Corderoy
Hi Peter,
Post by Peter Nabbefeld
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
2018-07-22 13:24:07 UTC
Permalink
Post by Ralph Corderoy
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.
Post by Ralph Corderoy
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.
Post by Ralph Corderoy
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?
Post by Ralph Corderoy
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?
Post by Ralph Corderoy
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
2018-07-22 11:26:10 UTC
Permalink
Post by Ralph Corderoy
Hi Peter,
Post by Peter Nabbefeld
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.  :-/
Post by Ralph Corderoy
Post by Peter Nabbefeld
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
2018-07-22 12:40:51 UTC
Permalink
Post by Ralph Corderoy
Hi Peter,
Post by Ralph Corderoy
Post by Peter Nabbefeld
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
Post by Ralph Corderoy
Post by Ralph Corderoy
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'.
Post by Ralph Corderoy
they're not in /var/cache/pacman/pkg
Are there any other `CacheDir' configured in /etc/pacman.conf ?
Post by Ralph Corderoy
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
2018-07-22 13:18:38 UTC
Permalink
Post by Ralph Corderoy
Post by Ralph Corderoy
Hi Peter,
Post by Ralph Corderoy
Post by Peter Nabbefeld
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
Post by Ralph Corderoy
Post by Ralph Corderoy
Post by Ralph Corderoy
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'".
Post by Ralph Corderoy
Post by Ralph Corderoy
they're not in /var/cache/pacman/pkg
Are there any other `CacheDir' configured in /etc/pacman.conf ?
No.
Post by Ralph Corderoy
Post by Ralph Corderoy
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
2018-07-22 13:55:13 UTC
Permalink
Hi Peter,
Post by Peter Nabbefeld
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'.
Post by Peter Nabbefeld
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.
Post by Peter Nabbefeld
So this won't hurt until I recompile some module
Sounds like it.
--
Cheers, Ralph.
https://plus.google.com/+RalphCorderoy
Peter Nabbefeld
2018-07-22 14:03:20 UTC
Permalink
Hi Ralph,
Post by Ralph Corderoy
Hi Peter,
Post by Peter Nabbefeld
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
Post by Ralph Corderoy
Is there something pulling in `crypto_user'?
What package owns that file? `pacman -Qo foo'.
Post by Peter Nabbefeld
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.
Post by Ralph Corderoy
Post by Peter Nabbefeld
So this won't hurt until I recompile some module
Sounds like it.
Ralph Corderoy
2018-07-22 14:10:30 UTC
Permalink
Hi Peter,
Post by Peter Nabbefeld
Post by Ralph Corderoy
Post by Peter Nabbefeld
alias 'crypto_user': Function not implemented
What's in /usr/lib/modules-load.d ?
Only bluez.conf
OK, and...
Post by Peter Nabbefeld
Post by Ralph Corderoy
Is there something pulling in `crypto_user'?
...what's in the file? And...
Post by Peter Nabbefeld
Post by Ralph Corderoy
What package owns that file? `pacman -Qo foo'.
I think therein lies your answer.
Post by Peter Nabbefeld
Post by Ralph Corderoy
Post by Peter Nabbefeld
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'.
Post by Peter Nabbefeld
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
2018-07-22 14:27:29 UTC
Permalink
Post by Ralph Corderoy
Post by Peter Nabbefeld
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.xz
[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
2018-07-22 14:32:49 UTC
Permalink
Post by Ralph Corderoy
Hi Peter,
Post by Peter Nabbefeld
Post by Ralph Corderoy
Post by Peter Nabbefeld
alias 'crypto_user': Function not implemented
What's in /usr/lib/modules-load.d ?
Only bluez.conf
OK, and...
Post by Peter Nabbefeld
Post by Ralph Corderoy
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 ... ;-)
Post by Ralph Corderoy
And...
Post by Peter Nabbefeld
Post by Ralph Corderoy
What package owns that file? `pacman -Qo foo'.
/usr/lib/modules-load.d/bluez.conf is contained in bluez 5.50-3
Post by Ralph Corderoy
I think therein lies your answer.
Post by Peter Nabbefeld
Post by Ralph Corderoy
Post by Peter Nabbefeld
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.
Post by Ralph Corderoy
Post by Peter Nabbefeld
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"
Post by Ralph Corderoy
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
2018-07-22 15:07:10 UTC
Permalink
Post by Peter Nabbefeld
Post by Ralph Corderoy
`pacman -Qi linux-headers' should show `Required by' as `None'.
It shows: "Error: Package 'linux-headers' not found"
Post by Ralph Corderoy
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
Post by Peter Nabbefeld
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
2018-07-22 21:18:39 UTC
Permalink
Post by 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 via arch-general
2018-07-23 00:25:33 UTC
Permalink
Post by Peter Nabbefeld
- 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
2018-07-23 06:47:51 UTC
Permalink
Post by Peter Nabbefeld
Post by 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).
- 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)
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
2018-07-23 07:59:52 UTC
Permalink
Post by Peter Nabbefeld
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
2018-07-23 08:27:45 UTC
Permalink
Post by Ralf Mardorf
Post by Peter Nabbefeld
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
2018-07-23 08:43:27 UTC
Permalink
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 via arch-general
2018-07-23 08:53:59 UTC
Permalink
Post by Ralf Mardorf
[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=49c8ef6d52ed6dacbca5a731ebe253bfb44e0ea9
Ralf Mardorf
2018-07-23 09:04:54 UTC
Permalink
Post by Levente Polyak via arch-general
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=49c8ef6d52ed6dacbca5a731ebe253bfb44e0ea9
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
2018-07-23 09:25:00 UTC
Permalink
Post by Levente Polyak via arch-general
Post by Ralf Mardorf
[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=49c8ef6d52ed6dacbca5a731ebe253bfb44e0ea9
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
Post by Levente Polyak via arch-general
4.17.6.
Regards
Peter

Ralf Mardorf
2018-07-23 08:58:00 UTC
Permalink
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
2018-07-23 09:22:17 UTC
Permalink
Post by Ralf Mardorf
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
2018-07-23 08:23:30 UTC
Permalink
Hi Peter,
Post by Peter Nabbefeld
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/ |
Post by Peter Nabbefeld
egrep -o '\<linux-[0-9]+\.[0-9]+' |
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
2018-07-23 08:44:58 UTC
Permalink
Post by Ralph Corderoy
Hi Peter,
Post by Peter Nabbefeld
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/ |
Post by Peter Nabbefeld
egrep -o '\<linux-[0-9]+\.[0-9]+' |
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
2018-07-22 14:12:53 UTC
Permalink
Post by Peter Nabbefeld
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
2018-07-22 14:18:44 UTC
Permalink
Post by Ralph Corderoy
Hi Peter,
Post by Peter Nabbefeld
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'.
Post by Peter Nabbefeld
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.
Post by Peter Nabbefeld
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
---
Post by Ralph Corderoy
# Linux/x86 4.17.8-1 Kernel Configuration
6295c6295
< CONFIG_SND_SOC_INTEL_BYT_CHT_NOCODEC_MACH=m
---
Post by Ralph Corderoy
# CONFIG_SND_SOC_INTEL_BYT_CHT_NOCODEC_MACH is not set
6818c6818
< # CONFIG_USB_SERIAL_DEBUG is not set
---
Post by Ralph Corderoy
CONFIG_USB_SERIAL_DEBUG=m
7386d7385
< CONFIG_CHARLCD=m
7398a7398
Post by Ralph Corderoy
CONFIG_CHARLCD=m
9331d9330
< CONFIG_CRYPTO_SALSA20_X86_64=m
Doug Newgard via arch-general
2018-07-23 00:17:51 UTC
Permalink
On Sun, 22 Jul 2018 11:27:04 +0200
Post by 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
Through this entire thread, I didn't see if you ever checked `uname -a` with the
new kernel installed and rebooting.
Loading...