Solved [chrooted debian] : no networking interface but lo

[didier]

Hi,
I've installed a debian bullseye base system in a chrooted env.

I notice it doesn't have networking while the freeBSD host is eth-wired connected and functional (interface is bge0).

root@debian # ifquery --list
lo

To perform this job, ifquery calls

int getifaddrs(struct ifaddrs **ifap)

.

In the meantime, cat /proc/net/dev :
Inter-| Receive| Transmit
face|bytes packets errs drop fifo frame compressed multicast| bytes packets errs drop fifo colls carrier compressed
eth0: 1280430626 936303 0 0 0 0 0 295 52344898 531008 0 0 0 0 0 0
lo0: 436 6 0 0 0 0 0 0 436 6 0 0 0 0 0 0

What a strange situation.

What's wrong and what to do ?
Does the inconsistency between /proc/net/dev contents and ifquery --list mean a bug in compatibility layer ?
Thanks a lot
Cheers

PS: I've followed https://wiki.freebsd.org/LinuxJails

 

[didier]

The problems seem coming from installing recent libc.
To effectively workaround this :
0. install a fresh debian buster base system with debootstrap.

On chrooted debian as root :

1. in /etc/apt/sources.list, change buster with bullseyes or sid. You can add contrib as source, safely as well.
2. apt update
3. apt upgrade --download-only
4. apt upgrade

Enjoy !

Hoping it helps.

 

[zirias@]

When experimenting with Linux VNET(!) jails in the past, I noticed FreeBSD networking tools taken from /rescue (they are linked statically) work fine inside the jail. Of course it's a bit of a PITA cause some scripts etc of your Linux dist will not work correctly (e.g. there is no ip(8) tool in FreeBSD), so you have to do some fiddling to get it all to work correctly, but it can be done

 

[didier]

Yes, indeed. What does PITA mean ? In my language, it's arabic bread. Seems to be an acronym, does it ?

I've remarked a limitation : getifaddrs() returns EAFNOSUPPORT. I'm crossing the linux compatibility source code of fbsd-13 to understand why.

 

[zirias@]

PITA = pain in the ass

 

[didier]

PITA = pain in the ass

? Spicy ?️

Indeed, I've attempted to run gdb and this is what I obtain :

Reading symbols from ./if...
(gdb) b getifaddrs
Breakpoint 1 at 0x1050
(gdb) run
Starting program: /home/didier/labo/if  
warning: linux_test_for_tracefork: unexpected result from waitpid (11000, status 0x57f)

And the tty hangs : ^C, ^D, ^Z... nothing happens.

Ok, I must give-up.

Nevertheless, at least, I noticed that firefox works well on a chrooted debian sid.

 

[zirias@]

Well, using the networking tools from /rescue, there shouldn't be any linux_* syscalls involved. Those are statically linked FreeBSD binaries and the kernel will treat them as such (using native syscalls)

 

[didier]

Well, using the networking tools from /rescue, there shouldn't be any linux_* syscalls involved. Those are statically linked FreeBSD binaries and the kernel will treat them as such (using native syscalls)

This is not my purpose. I'm testing glibc getifaddrs() in a Debian chrooted environment.

 

[zirias@]

I understood that. It was just an additional hint for everyone running into trouble with Linux networking tools (VNET jails are especially problematic because the jail e.g. has to bring up an interface) that statically linked FreeBSD tools could work as a replacement.