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.