FATAL: Could not load modules.dep

LXC
1

Hi there!
On host - debian 10.5 (4.19.0-10-amd64 #1 SMP Debian 4.19.132-1 (2020-07-24)), lxc 3.0.3
On container - centos 6.10

Try to add an iptables rule inside container:

# iptables -I INPUT -p udp -m udp --dport 80:81 -m string --string "OLOLO" --algo bm -j DROP
FATAL: Could not load /lib/modules/4.19.0-10-amd64/modules.dep: No such file or directory

# depmod -ae
WARNING: Couldn't open directory /lib/modules/4.19.0-10-amd64: No such file or directory
FATAL: Could not open /lib/modules/4.19.0-10-amd64/modules.dep.temp for writing: No such file or directory

# ls -lah /lib/modules/
total 16K
dr-xr-xr-x 4 root root 4.0K Nov 27 10:57 .
dr-xr-xr-x 8 root root 4.0K Nov 27 10:57 ..
drwxr-xr-x 3 root root 4.0K Feb  3  2014 2.6.32-279.14.1.el6.x86_64
drwxr-xr-x 7 root root 4.0K Nov 27 10:57 2.6.32-754.35.1.el6.x86_64

Well, any ideas? :slight_smile:

2

You need to make sure to preload any module needed in the container on the host.
Containers can’t load kernel modules.

Running the same rule on the host, then deleting it should cause whatever needs loading to get loaded, it should then work inside the container.

3

Hey, @stgraber nice to see you! :slight_smile:
Nope, unfortunately it has no effect. And there is more: I have a centos 7 container on the same host, and there is no same problem. I think the problem is only with centos6 teamplate.

4

I wonder if it’s just the tool being confused because /lib/modules exists in your container? Normally containers don’t have kernel packages installed and may be missing the path altogether, which may or may not be helping iptables handle this.

5

It exists cuz i have some dependencies by kernel, but it is no matter, the problem is on clean container, look:

root@host# iptables -I INPUT -p udp -m udp --dport 1234:1236 -m string --string "OLOLO" --algo bm -j DROP
root@host# iptables -nvL
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 DROP       udp  --  *      *       0.0.0.0/0            0.0.0.0/0            udp dpts:1234:1236 STRING match  "OLOLO" ALGO name bm TO 65535

root@host# lxc-create -t download -n test1 -B loop --fssize 5G --fstype ext4 -- -d centos -r 6 -a amd64
Setting up the GPG keyring
Downloading the image index
Downloading the rootfs
Downloading the metadata
The image cache is now ready
Unpacking the rootfs

---
You just created a Centos 6 x86_64 (20201130_07:08) container.

root@host# lxc-start test1
root@host# lxc-attach test1
[root@test1 /]# iptables -I INPUT -p udp -m udp --dport 1234:1236 -m string --string "OLOLO" --algo bm -j DROP
FATAL: Could not load /lib/modules/4.19.0-10-amd64/modules.dep: No such file or directory

[root@test1 /]# ls -lah /lib/modules/
total 8.0K
dr-xr-xr-x 2 root root 4.0K Sep 23  2011 .
dr-xr-xr-x 7 root root 4.0K Nov 30 02:15 ..

[root@test1 /]# iptables -nvL
Chain INPUT (policy ACCEPT 0 packets, 0 bytes)
 pkts bytes target     prot opt in     out     source               destination         
    0     0 DROP       udp  --  *      *       0.0.0.0/0            0.0.0.0/0           udp dpts:1234:1236 FATAL: Could not load /lib/modules/4.19.0-10-amd64/modules.dep: No such file or directory
STRING match "OLOLO" ALGO name bm TO 65535

as i said - the problem is with centos 6 template, isn’t it?

6

Feels like the problem is with CentOS 6 more than with the template, it’s most likely the version of iptables in CentOS 6 being a bit too picky in this case.

7

i dunno, maybe it is, but on openvz or virtual (kvm), phys server with centos 6 i haven’t the problem …

8

Both physical and OpenVZ will have kernels that are much more in sync with what CentOS6 shipped with, so more likely to make its iptables detect an existing module and move on.

You could try strace on that iptables call to see if you can’t figure out what module it’s trying to load.