3.7.0 SSH fails to start #5
Description
reported by @GrigoriyMikhalkin
looking at what happens there, it looks like the ifupdown get stuck trying to dhcp eth0.
root@a1271dcfa4b135ae:/etc/network# ip -br add show dev eth0
eth0 UP fe80::783f:a7ff:fed7:97df/64
root@a1271dcfa4b135ae:/etc/network# ifreload -a
error: cmd '/usr/bin/vrf task exec mgmt /sbin/dhclient -pf /run/dhclient.eth0.pid -lf /var/lib/dhcp/dhclient.eth0.leases eth0' failed: returned 1
pf /run/dhclient.eth0.pid -lf /var/lib/dhcp/dhclient.eth0.leases eth0/dhclient -
Cgroup for managing VRF context does not exist.
Has l3mdev cgroup patch been applied to kernel?
If so has it been enabled?
This looks like the VRF support did not exist in upstream kernel and was added via a patch.
I don't have access to 3.7.x system, maybe @GrigoriyMikhalkin you can compare the kernel version and loaded modules? This is how it looks inside ignite:
root@a1271dcfa4b135ae:/etc/network# lsmod
Module Size Used by
vrf 24576 0
bonding 159744 0
bridge 176128 0
stp 16384 1 bridge
llc 16384 2 bridge,stp
kvm_intel 212992 0
kvm 565248 1 kvm_intel
irqbypass 16384 1 kvm
crc32c_intel 24576 0
aesni_intel 200704 0
aes_x86_64 20480 1 aesni_intel
crypto_simd 16384 1 aesni_intel
virtio_net 45056 0
net_failover 20480 1 virtio_net
failover 16384 1 net_failover
cryptd 20480 2 crypto_simd,aesni_intel
glue_helper 16384 1 aesni_intel
input_leds 16384 0
led_class 16384 1 input_leds
autofs4 36864 2
root@a1271dcfa4b135ae:/etc/network# uname -r
4.19.0-cl-1-amd64
The reason for this is most likely that 3.7.0 code is running on a kernel built from 4.3.0.
This is the process I haven't really documented anywhere, probably worth adding a guide for it later. The process of building a kernel image. It's fairly simple -- you need to unpack the /boot/vmlinuz into a vmlinux and get a copy of /lib/modules from an existing CL image. Package it up in an container image, vmlinux goes to /boot/ and /lib/modules go to /lib/modules.
The final step would be to update https://github.com/srl-labs/containerlab/blob/master/nodes/cvx/cvx.go to use a different image kernel depending on the version , similar to how it's done with RAM today.
Do you think you can do this @GrigoriyMikhalkin ? I'll be happy to write up some documentation and makefiles for this.