Re: No network available during task do_install on debian bullseye/5.10 host - but on a debian buster/4.19 host network is available

[Anton Mikanovich <amikan@ilbers.de>]

15/03/2024 11:06, Bjoern Kaufmann wrote:
> I did what you proposed, but there is still no eth0.
> What I also tested and what might be interesting:
>
> def print_ifs():
>     import subprocess
>     import socket
>
>     output = subprocess.check_output("ip a", shell=True)
>     print(f'Output of ip a: "{str(output)}"')
>
>     print(socket.if_nameindex())
>     return ''
>
> do_testtask() {
>     ${@ print_ifs()}
>     ip a
> }
> addtask testtask
>
>
> I executed it inside kas shell by 'bitbake -c testtask my-recipe' 
> again and the log looks as follows:
>
> DEBUG: Executing shell function do_testtask
> Output of ip a: "b'1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc 
> noqueue state UNKNOWN group default qlen 1000\n  link/loopback 
> 00:00:00:00:00:00 brd 00:00:00:00:00:00\n    inet 127.0.0.1/8 scope 
> host lo\n       valid_lft forever preferred_lft forever\n4: eth0@if5: 
> <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP 
> group default \n    link/ether 02:42:ac:11:00:02 brd ff:ff:ff:ff:ff:ff 
> link-netnsid 0\n    inet 172.17.0.2/16 brd 172.17.255.255 scope global 
> eth0\n       valid_lft forever preferred_lft forever\n'"
> [(1, 'lo'), (4, 'eth0')]
> Output of ip a: "b'1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN 
> group default qlen 1000\n    link/loopback 00:00:00:00:00:00 brd 
> 00:00:00:00:00:00\n'"
> [(1, 'lo')]
> 1: lo: <LOOPBACK> mtu 65536 qdisc noop state DOWN group default qlen 1000
>     link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> DEBUG: Shell function do_testtask finished
>
>
> So as you can see
> 1. The python function is printed twice in a row, most probably in two 
> different contexts? I guess you know more about it
> 2. During the first execution of the python function, eth0 interfaces 
> are available
> 3. During the second execution of the python function, no eth0 
> interface is available
>
>
> Also Jan Kiszka told me that to his knowledge the newer bitbake 
> isolates tasks from networks by default. If this is the case it still 
> doesn't really explain the behavior show in the log above and it 
> doesn't explain why this doesn't happen on the buster host VMs.
>
> Best regards,
> Bjoern

Hello Bjoern,

The first print_ifs execution was done during recipe parsing, the second one
was done during task execution.
It happens because you've used inline python call.

For bitbake 2.0+ you can enable network access for your task by setting:
do_testtask[network] = "1"

On my side even without it 'ip a' was showing eth0, but there maybe some 
other
permissions configuration.