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

[Bjoern Kaufmann <bjoern.kaufmann.s@gmail.com>]

[-- Attachment #1.1: Type: text/plain, Size: 6001 bytes --]

Just adding this here, as I accidentally clicked the wrong reply button for 
my last answer and thus sent you a private message:

13/03/2024 15:36, Bjoern Kaufmann wrote:
> From bitbake shell after executing kas shell kas.yml inside the docker
> container (on bullseye host VM):
>
> _____
>
> $ ip a
>
> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
> group default qlen 1000
>     link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
>     inet 127.0.0.1/8 scope host lo
>        valid_lft forever preferred_lft forever
> 86: eth0@if87: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc
> noqueue state UP group default
>     link/ether 02:42:ac:11:00:03 brd ff:ff:ff:ff:ff:ff link-netnsid 0
>     inet 172.17.0.3/16 brd 172.17.255.255 scope global eth0
>        valid_lft forever preferred_lft forever
>
> _____
>
> $ bitbake my-recipe
> --- executes recipe tasks ---
> $ cat tmp/work/debian-bullseye
> -amd64/my-recipe/2023.1-r0/temp/log.do_install
>
> DEBUG: Executing shell function do_install
> 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_install finished
>
> _____
>
> $ tmp/work/s2l2-linux-2023-2-amd64/down-package/2023.1-r0/te
mp/run.do_install
>
> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
> group default qlen 1000
>     link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
>     inet 127.0.0.1/8 scope host lo
>        valid_lft forever preferred_lft forever
> 86: eth0@if87: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc
> noqueue state UP group default
>     link/ether 02:42:ac:11:00:03 brd ff:ff:ff:ff:ff:ff link-netnsid 0
>     inet 172.17.0.3/16 brd 172.17.255.255 scope global eth0
>        valid_lft forever preferred_lft forever
>
> _____
>
> As you can see, if do_install is executed by bitbake, it behaves
> differently, at least on that bullseye host system. So bitbake indeed
> seems to do something before executing do_install, even if it's not
> switching into a chroot.
>
> Best regards,
> Bjoern

On Wed, Mar 13, 2024 at 2:55 PM Anton Mikanovich <amikan@ilbers.de> wrote:
Here is one more code you can try:

do_testtask() {
         ip a
}
addtask testtask

So it should be executed by 'bitbake -c testtask my-recipe' inside kas
shell.

This task is free of any recipe/bbclass dependencies and will be the
only task
executed by bitbake. If the output will be correct with it the issue is
probably caused by some other task/recipe execuded before
my-recipe:do_install.
If there will be still no eth0 you can look through python(){} or
python __anonymous(){} sections of your layer because this code is
executed on
parsing stage.

On Wednesday, March 13, 2024 at 11:48:08 AM UTC+1 Anton Mikanovich wrote:

> 07/03/2024 17:33, 'Kaufmann, Bjoern' via isar-users wrote:
> > Hello,
> >
> > I have the following recipe my-recipe_2023.1.bb:
> >
> > inherit dpkg-raw
> >
> > do_install() {
> > ip a
> > }
> >
> > I run a build based on isar "d26660b724b034b602f3889f55a23cd9be2e87bd" 
> (> v0.9, < v0.10-rc1) inside of a docker container "
> ghcr.io/siemens/kas/kas-isar:3.3".
> >
> > _____
> >
> > In the first scenario the build runs inside the docker container on a 
> debian buster VM with 4.19.0-26 kernel. In this scenario the logfile 
> "build/tmp/work/debian-bullseye 
> -amd64/my-recipe/2023.1-r0/temp/log.do_install" looks as follows:
> >
> > DEBUG: Executing shell function do_install
> > 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN 
> group default qlen 1000
> > link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> > inet 127.0.0.1/8 scope host lo
> > valid_lft forever preferred_lft forever
> > 944: eth0@if945: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc 
> noqueue state UP group default
> > link/ether 02:42:ac:11:00:03 brd ff:ff:ff:ff:ff:ff link-netnsid 0
> > inet 172.17.0.3/16 brd 172.17.255.255 scope global eth0
> > valid_lft forever preferred_lft forever
> > DEBUG: Shell function do_install finished
> >
> > _____
> >
> > In the second scenario the exact same build runs inside the docker 
> container on a debian bullseye VM with 5.10.0-28 kernel. In this scenario 
> the logfile "build/tmp/work/debian-bullseye 
> -amd64/my-recipe/2023.1-r0/temp/log.do_install" looks as follows:
> >
> > DEBUG: Executing shell function do_install
> > 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_install finished
> >
> > _____
> >
> >
> > I would like to understand why the same build behaves differently on the 
> two different host systems. Thanks in advance.
> >
> > Best regards,
> > Bjoern
> >
> >
> >
> Hello Bjoern,
>
> The task do_install is performed in original environment without any 
> additional
> chroots. It means there is no need to run Isar to have the same 'ip a' 
> output.
> You can just control network availability inside the container in the 
> same way.
> To check that you can perform 'kas-container shell' and then run 'ip a'.
> We've checked networking on Buster and Bullseye host (but without 
> Proxmox VMs)
> and didn't find any issues. In both cases output looks like:
>
> 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN 
> group default qlen 1000
>     link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
>     inet 127.0.0.1/8 scope host lo
>        valid_lft forever preferred_lft forever
> 9: eth0@if10: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue 
> state UP group default
>     link/ether 02:42:ac:11:00:02 brd ff:ff:ff:ff:ff:ff link-netnsid 0
>     inet 172.17.0.2/16 brd 172.17.255.255 scope global eth0
>        valid_lft forever preferred_lft forever
>
> With the only difference in random eth0 index.
>
>

[-- Attachment #1.2: Type: text/html, Size: 25267 bytes --]