| View previous topic :: View next topic |
| Author |
Message |
Sikorsky42
n00b
Joined: 27 Aug 2020
Posts: 16
Location: USA
|
 Posted: Wed Jan 31, 2024 11:08 pm Post subject: Docker missing CGROUP_DPF, but SDDM fails to start with it. |
 |
|
I am running into a bit of an issue. After upgrading to kernel 6.6.16 from 6.1.67 docker containers won't start.
Docker config check says I am missing CGROUP_DPF. Enabling CGROUP_DPF, and its dependancy DPF_SYSCALL, results in dispaly manager not starting anymore. Anyone seen something similar? |
|
| Back to top |
|
 |
Sikorsky42
n00b
Joined: 27 Aug 2020
Posts: 16
Location: USA
|
| Posted: Fri Feb 02, 2024 2:33 am Post subject: |
|
|
I have tried various combinations of BPF_SYSCALL and related opitons.
In call cases, the display manager fails to start.
In addition, with BPF_SYSCALL and CGROUP_BPF disabled, the docker service starts, but no containers can start. Trying to start a container yields:
| Code: |
Error response from daemon: failed to create task for container: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: error during container init: error setting cgroup config for procHooks process: bpf_prog_query(BPF_CGROUP_DEVICE) failed: function not implemented: unknown
Error: failed to start containers: portainer
|
Having BPF_SYSCALL and CGROUP_BPF enabled results in the docker service crashing, instead of starting and not being able to start containers.
I have also tried installing dev-libs/libbpf in case that could help, but it did not. |
|
| Back to top |
|
|
Hu
Administrator
Joined: 06 Mar 2007
Posts: 23101
|
| Posted: Fri Feb 02, 2024 3:44 pm Post subject: |
|
|
| I think if you need help, you should provide the specific error messages from the case when BPF=Y, BPF_SYSCALL=Y, and CGROUP_BPF=y. You wrote that both docker and SDDM crash in those cases, but did not provide details of how they crash, so we can only guess as to what is wrong with them. |
|
| Back to top |
|
|
Sikorsky42
n00b
Joined: 27 Aug 2020
Posts: 16
Location: USA
|
| Posted: Fri Feb 02, 2024 7:01 pm Post subject: |
|
|
Where would I get those logs?
Would it be in /var/log/rc.log ? I am using OpenRC. |
|
| Back to top |
|
|
Hu
Administrator
Joined: 06 Mar 2007
Posts: 23101
|
| Posted: Fri Feb 02, 2024 9:43 pm Post subject: |
|
|
| I use neither of those, so I cannot say. You wrote previously that they crash. What do you see that makes you say that they crashed? Share that output as a starting point. |
|
| Back to top |
|
|
Sikorsky42
n00b
Joined: 27 Aug 2020
Posts: 16
Location: USA
|
| Posted: Sat Feb 03, 2024 12:00 am Post subject: |
|
|
For docker:
`rc-service docker status` returns "crashed" as the status.
For display-manager
`rc-service display-manager status` returns "started" but it is not, in fact, started, as I don't have a graphical environment. |
|
| Back to top |
|
|
spica
Guru
Joined: 04 Jun 2021
Posts: 340
|
| Posted: Sat Feb 03, 2024 3:31 am Post subject: |
|
|
| Sikorsky42 wrote: | | Enabling CGROUP_DPF, and its dependancy DPF_SYSCALL, results in dispaly manager not starting anymore. Anyone seen something similar? |
The kernel configuration does not include an option for CGROUP_DPF. However, it is evident that CGROUP_BPF is not directly related to the video card. It's possible that enabling CGROUP_BPF (DPF?) may have unintentionally triggered the disabling of a component associated with the video card. If you activated an option through menuconfig, keep in mind that all dependencies are typically handled automatically. Manually altering the .config file to address dependencies is not advisable.
| Sikorsky42 wrote: | | Code: | Error response from daemon: failed to create task for container: failed to create shim task: OCI runtime create failed: runc create failed: unable to start container process: error during container init: error setting cgroup config for procHooks process: bpf_prog_query(BPF_CGROUP_DEVICE) failed: function not implemented: unknown
Error: failed to start containers: portainer |
|
This error means CGROUP_BPF is not enabled. |
|
| Back to top |
|
|
Sikorsky42
n00b
Joined: 27 Aug 2020
Posts: 16
Location: USA
|
| Posted: Sat Feb 03, 2024 11:50 am Post subject: |
|
|
Yes, I was getting that error when CGROUP_BPF was disabled.
Sorry about the typo DPF -> BPF.
I have gotten it working again. Here's how in case anyone else runs across this:
1. I tried using sys-kernel/gentoo-kernel-bin, which worked after remembering to run emerge @module_rebuild with the new kernel selected via eselect kernel set #
2. Knowing the distribution kernel works, I decided to copy much of its relevant config via (neo)vim diff mode.
nvim -d /usr/src/linux-6.6.13-gentoo{,-dist}/.config
I searched for all mentions of BPF
If the option was set to Y in the dist kernel, I copied that, jdiciously.
I saw some possibly relatd blocks of options set to M in the dist kernel. Since it, I believe, doesn't hurt to enable modules I added those too.
I then compiled the kernel, and made sure to run emerge @module_reduilb again.
It then worked.
Thank you everyone!
As a sidenote, installing the dist kernel required USE sys-kernel/installkernel dracut.
This has now caused `make install` when run on my mpiled kernel now run dracut to create an initramfs as well. This was odd, but I ran with it, although I usually use `genkernel initramfs` to make my initramfs. Dracut seems to have cut it in my simple needs case though. |
|
| Back to top |
|
|
Nowa
Developer
Joined: 25 Jun 2014
Posts: 478
Location: Nijmegen
|
| Posted: Sat Feb 03, 2024 12:44 pm Post subject: |
|
|
| Sikorsky42 wrote: | As a sidenote, installing the dist kernel required USE sys-kernel/installkernel dracut.
This has now caused `make install` when run on my mpiled kernel now run dracut to create an initramfs as well. This was odd, but I ran with it, although I usually use `genkernel initramfs` to make my initramfs. Dracut seems to have cut it in my simple needs case though. |
Just to add, it is possible to bypass the installed dracut plugin:
For systems that have USE=-systemd on sys-kernel/installkernel:
| Code: | | INSTALLKERNEL_INITRD_GENERATOR=none make install |
For systems that have USE=systemd on sys-kernel/installkernel:
| Code: | | echo "initrd_generator=none" >> /etc/kernel/install.conf && make install |
_________________
OS: Gentoo 6.10.12-gentoo-dist, ~amd64, 23.0/desktop/plasma/systemd
MB: MSI Z370-A PRO
CPU: Intel Core i9-9900KS
GPU: Intel Arc A770 16GB & Intel UHD Graphics 630
SSD: Samsung 970 EVO Plus 2 TB
RAM: Crucial Ballistix 32GB DDR4-2400 |
|
| Back to top |
|
|
Hu
Administrator
Joined: 06 Mar 2007
Posts: 23101
|
| Posted: Sat Feb 03, 2024 4:17 pm Post subject: |
|
|
| Sikorsky42 wrote: | | 2. Knowing the distribution kernel works, I decided to copy much of its relevant config via (neo)vim diff mode. |
Directly editing kernel configuration is generally discouraged, because you can easily create an incoherent configuration, and the kernel build process does not guarantee to handle incoherent configurations nicely. For the particular way you did it, I think it is unlikely that you created something incoherent. The most common error would be enabling a symbol without enabling the supporting code that symbol needs.
The safer, but less convenient, alternative would be to use the diff to decide what to enable, but to use menuconfig to enable the symbols you decide to activate, so that it can handle symbol dependencies for you. |
|
| Back to top |
|
|
Sikorsky42
n00b
Joined: 27 Aug 2020
Posts: 16
Location: USA
|
| Posted: Sat Feb 03, 2024 11:47 pm Post subject: |
|
|
I ran `make configcheck` after editing .config manually.
I didn't even know it would work, I just guessed it was a command actually. |
|
| Back to top |
|
|
|
Kernel & Hardware
