From mboxrd@z Thu Jan 1 00:00:00 1970 X-GM-THRID: 7343661073770217472 Date: Thu, 14 Mar 2024 09:50:43 -0700 (PDT) From: Bjoern Kaufmann To: isar-users Message-Id: <86320af4-266d-4040-9f41-6d2d9f267015n@googlegroups.com> In-Reply-To: <0a3ee875-d004-42d4-906b-4e6e847c7cd7@ilbers.de> References: <0a3ee875-d004-42d4-906b-4e6e847c7cd7@ilbers.de> Subject: 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 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="----=_Part_188998_490193149.1710435043779" X-TUID: 3SPo240k/Gpe ------=_Part_188998_490193149.1710435043779 Content-Type: multipart/alternative; boundary="----=_Part_188999_2002853268.1710435043779" ------=_Part_188999_2002853268.1710435043779 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Just adding this here, as I accidentally clicked the wrong reply button for= =20 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: 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: 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: 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: 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: 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=E2=80=AFPM Anton Mikanovich = 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=E2=80=AFAM 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"= =20 > (> 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= =20 > debian buster VM with 4.19.0-26 kernel. In this scenario the logfile=20 > "build/tmp/work/debian-bullseye=20 > -amd64/my-recipe/2023.1-r0/temp/log.do_install" looks as follows: > > > > DEBUG: Executing shell function do_install > > 1: lo: mtu 65536 qdisc noqueue state UNKNOWN=20 > 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: mtu 1500 qdisc=20 > 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=20 > container on a debian bullseye VM with 5.10.0-28 kernel. In this scenario= =20 > the logfile "build/tmp/work/debian-bullseye=20 > -amd64/my-recipe/2023.1-r0/temp/log.do_install" looks as follows: > > > > DEBUG: Executing shell function do_install > > 1: lo: mtu 65536 qdisc noop state DOWN group default qlen 10= 00 > > 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 th= e=20 > two different host systems. Thanks in advance. > > > > Best regards, > > Bjoern > > > > > > > Hello Bjoern, > > The task do_install is performed in original environment without any=20 > additional > chroots. It means there is no need to run Isar to have the same 'ip a'=20 > output. > You can just control network availability inside the container in the=20 > 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=20 > Proxmox VMs) > and didn't find any issues. In both cases output looks like: > > 1: lo: mtu 65536 qdisc noqueue state UNKNOWN=20 > 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: mtu 1500 qdisc noqueue=20 > 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. > > ------=_Part_188999_2002853268.1710435043779 Content-Type: text/html; charset=utf-8 Content-Transfer-Encoding: quoted-printable 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 execut= ing kas shell kas.yml inside the docker
> container (on bullseye host VM):
>
> _____
= >
> $ ip a
>
&g= t; 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOW= N
> group defa= ult qlen 1000
>= ; =C2=A0 =C2=A0 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> =C2=A0 =C2=A0 ine= t=C2=A0127.0.0.1/8=C2=A0= scope host lo
>= ; =C2=A0 =C2=A0 =C2=A0 =C2=A0valid_lft forever preferred_lft forever=
> 86: eth0@if87: <= ;BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc
= > noqueue state UP group default
> =C2=A0 =C2=A0 link/ether = 02:42:ac:11:00:03 brd ff:ff:ff:ff:ff:ff link-netnsid 0
> =C2=A0 =C2=A0 inet=C2=A0<= a href=3D"http://172.17.0.3/16" rel=3D"noreferrer" target=3D"_blank" style= =3D"color: rgb(17, 85, 204); font-family: Arial, Helvetica, sans-serif; fon= t-size: small;">172.17.0.3/16=C2=A0brd 172.17= .255.255 scope global eth0
> =C2=A0 =C2=A0 =C2=A0 =C2=A0valid_lft forever preferred_lft f= orever
>
> _____
>
> $ 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&= gt; mtu 65536 qdisc noop state DOWN group default qlen 1000
> =C2=A0 =C2=A0 link/loopback= 00:00:00:00:00:00 brd 00:00:00:00:00:00
> DEBUG: Shell function do_install finished
>
> _____
>
<= span style=3D"color: rgb(34, 34, 34); font-family: Arial, Helvetica, sans-s= erif; font-size: small;">> $=C2=A0tmp/work/s2l2-linux-2023-2-amd64/down-package/2= 023.1-r0/te>
> 1: l= o: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN
> group default qle= n 1000
> =C2= =A0 =C2=A0 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
> =C2=A0 =C2=A0 inet=C2= =A0127.0.0.1/8=C2=A0scop= e host lo
> = =C2=A0 =C2=A0 =C2=A0 =C2=A0valid_lft forever preferred_lft forever> 86: eth0@if87: <B= ROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc
> noqueue state UP group default
> =C2=A0 =C2=A0 link/ether 02= :42:ac:11:00:03 brd ff:ff:ff:ff:ff:ff link-netnsid 0
> =C2=A0 =C2=A0 inet=C2=A0172.17.0.3/16=C2=A0brd 172.17.25= 5.255 scope global eth0
> =C2=A0 =C2=A0 =C2=A0 =C2=A0valid_lft forever preferred_lft fore= ver
>> _____
>
> As you can see, if do_install is execu= ted by bitbake, it behaves
> differently, at least on that bullseye host system. So bitba= ke indeed
> se= ems to do something before executing do_install, even if it's not> switching into a chro= ot.
>> Best regards,=
> Bjoern
=
On Wed, Mar 13, 2024 at= 2:55=E2=80=AFPM Anton Mikanovich <amikan@ilbers.de> wrote:Here is one more code you = can try:

do_testtask() {
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 ip a
}
addtask testtask

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

This task is fr= ee of any recipe/bbclass dependencies and will be the
only task
executed by bitbake. If the output will be co= rrect with it the issue is
probably caused by some other task/recipe execuded before<= br style=3D"color: rgb(34, 34, 34); font-family: Arial, Helvetica, sans-ser= if; font-size: small;" />my-recipe:do_install.
If there will be st= ill 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=E2= =80=AFAM 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 "d26660b724b034b602f3889f55a23cd9= be2e87bd" (> v0.9, < v0.10-rc1) inside of a docker container &qu= ot;ghcr.io/siemens= /kas/kas-isar:3.3".
>
> _____
>
> In the first scenario the build runs inside the docker container o= n a debian buster VM with 4.19.0-26 kernel. In this scenario the logfile &q= uot;build/tmp/work/debian-bullseye -amd64/my-recipe/2023.1-r0/temp/log.do_i= nstall" 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-netns= id 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 defa= ult 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=20
additional
chroots. It means there is no need to run Isar to have the same 'ip= a'=20
output.
You can just control network availability inside the container in the= =20
same way.
To check that you can perform 'kas-container shell' and then ru= n 'ip a'.
We've checked networking on Buster and Bullseye host (but without= =20
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 UNKNO= WN=20
group default qlen 1000
=C2=A0=C2=A0=C2=A0 link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:= 00
=C2=A0=C2=A0=C2=A0 inet 127.0.0.1/8 scope host lo
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 valid_lft forever preferred_lft f= orever
9: eth0@if10: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc no= queue=20
state UP group default
=C2=A0=C2=A0=C2=A0 link/ether 02:42:ac:11:00:02 brd ff:ff:ff:ff:ff:ff = link-netnsid 0
=C2=A0=C2=A0=C2=A0 inet 172.17.0.2/16 brd 172.17.= 255.255 scope global eth0
=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0=C2=A0 valid_lft forever preferred_lft f= orever

With the only difference in random eth0 index.

------=_Part_188999_2002853268.1710435043779-- ------=_Part_188998_490193149.1710435043779--