RFT/FYI: docker/containerd/runc uprevs pushed to master

RFT/FYI: docker/containerd/runc uprevs pushed to master

[Bruce Ashfield]

Hi all,

After spending a few days de-tangling the moby/docker/runc/containerd
and oe-core go infrastructure changes, I was able to run
docker/runc/containerd through a system/stress test and everything
seems to be working.

There were a few regressions that I worked through, as well as
build/packaging changes, but I'm no longer seeing any issues and all
the patches/functionality have been carried forward.

One thing of note is that the docker and open containers containerd
split/fork is no longer an issue, so I've modified the default to be
the opencontainers variant. Similarly, the docker and opencontainers
runc are very similar. I've kept both variants of both recipes for
now, since I'd like to track things for a bit longer before declaring
the split unnecessary.

Also for those that care, I created a reference docker-ce recipe that
tracks the docker-ce repo versus the components themselves.  Right now
it is reference only, since it needs a bit more work, but I wanted to
get it out there, in case someone really cares about docker-ce (I
don't really, but someone might!).

Summary: I just pushed the following changes to master:

  d7d310ae4113 meta-virt: prefer containerd-opencontainers
  935e3d969ef1 containerd: uprev to v1.0.2
  f5fbfa8ac4db docker-ce: introduce reference recipe/build
  a5074cecf18f docker: uprev to 18.03.0
  e3d960f4fcd9 runc: uprev to 1.0.0-rc5

If anyone sees regressions, build or architecture issues .. report
them to me (and the list) and we'll get them fixed up.

Cheers,

Bruce

-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"

Re: RFT/FYI: docker/containerd/runc uprevs pushed to master

[Shakthi Pradeep (tpradeep)]

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

Hello Bruce,



Timing is Perfect !!!



I am currently trying to get Docker CE to work with Yocto. I could include the Docker executable in ISO but when I run it I get some errors.


When I boot the image looks like Docker service start is failing due to missing kernel modules. Please refer attached screenshot and below error log.

* docker.service - Docker Application Container Engine
   Loaded: loaded (/lib/systemd/system/docker.service; enabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since Tue 2018-04-03 13:17:51 UTC; 17min ago
     Docs: https://docs.docker.com
  Process: 317 ExecStart=/usr/bin/dockerd -H fd:// (code=exited, status=1/FAILURE)
Main PID: 317 (code=exited, status=1/FAILURE)

Apr 03 13:17:51 intel-x86-64 dockerd[317]: time="2018-04-03T13:17:51.035178755Z" level=warning msg="Running modprobe xt_conntrack failed with message: `modprobe: WARNING: Module xt_conntrack not found in directory /lib/modules/4.8.24-WR9.0.0.10_standard`, error: exit status 1"
Apr 03 13:17:51 intel-x86-64 dockerd[317]: time="2018-04-03T13:17:51.040727372Z" level=info msg="Firewalld running: false"
Apr 03 13:17:51 intel-x86-64 dockerd[317]: time="2018-04-03T13:17:51.170575344Z" level=warning msg="Could not load necessary modules for IPSEC rules: Running modprobe xfrm_user failed with message: `modprobe: WARNING: Module xfrm_user not found in directory /lib/modules/4.8.24-WR9.0.0.10_standard`, error: exit status 1"
Apr 03 13:17:51 intel-x86-64 dockerd[317]: time="2018-04-03T13:17:51.172397913Z" level=info msg="Default bridge (docker0) is assigned with an IP address 172.17.0.0/16. Daemon option --bip can be used to set a preferred IP address"
Apr 03 13:17:51 intel-x86-64 dockerd[317]: Error starting daemon: Error initializing network controller: Error creating default "bridge" network: Failed to Setup IP tables: Unable to enable ACCEPT INCOMING rule:  (iptables failed: iptables --wait -I FORWARD -o docker0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT: iptables: No chain/target/match by that name.
Apr 03 13:17:51 intel-x86-64 dockerd[317]:  (exit status 1))
Apr 03 13:17:51 intel-x86-64 systemd[1]: docker.service: Main process exited, code=exited, status=1/FAILURE
Apr 03 13:17:51 intel-x86-64 systemd[1]: Failed to start Docker Application Container Engine.
Apr 03 13:17:51 intel-x86-64 systemd[1]: docker.service: Unit entered failed state.
Apr 03 13:17:51 intel-x86-64 systemd[1]: docker.service: Failed with result 'exit-code'.



Regards,

Shakthi



-----Original Message-----
From: meta-virtualization-bounces@yoctoproject.org [mailto:meta-virtualization-bounces@yoctoproject.org] On Behalf Of Bruce Ashfield
Sent: Wednesday, April 04, 2018 8:44 AM
To: meta-virtualization@yoctoproject.org
Subject: [meta-virtualization] RFT/FYI: docker/containerd/runc uprevs pushed to master



Hi all,



After spending a few days de-tangling the moby/docker/runc/containerd and oe-core go infrastructure changes, I was able to run docker/runc/containerd through a system/stress test and everything seems to be working.



There were a few regressions that I worked through, as well as build/packaging changes, but I'm no longer seeing any issues and all the patches/functionality have been carried forward.



One thing of note is that the docker and open containers containerd split/fork is no longer an issue, so I've modified the default to be the opencontainers variant. Similarly, the docker and opencontainers runc are very similar. I've kept both variants of both recipes for now, since I'd like to track things for a bit longer before declaring the split unnecessary.



Also for those that care, I created a reference docker-ce recipe that tracks the docker-ce repo versus the components themselves.  Right now it is reference only, since it needs a bit more work, but I wanted to get it out there, in case someone really cares about docker-ce (I don't really, but someone might!).



Summary: I just pushed the following changes to master:



  d7d310ae4113 meta-virt: prefer containerd-opencontainers

  935e3d969ef1 containerd: uprev to v1.0.2

  f5fbfa8ac4db docker-ce: introduce reference recipe/build

  a5074cecf18f docker: uprev to 18.03.0

  e3d960f4fcd9 runc: uprev to 1.0.0-rc5



If anyone sees regressions, build or architecture issues .. report them to me (and the list) and we'll get them fixed up.



Cheers,



Bruce



--

"Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end"

--

_______________________________________________

meta-virtualization mailing list

meta-virtualization@yoctoproject.org<mailto:meta-virtualization@yoctoproject.org>

https://lists.yoctoproject.org/listinfo/meta-virtualization

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

[-- Attachment #2: docker.log --]
[-- Type: application/octet-stream, Size: 2151 bytes --]

* docker.service - Docker Application Container Engine
   Loaded: loaded (/lib/systemd/system/docker.service; enabled; vendor preset: enabled)
   Active: failed (Result: exit-code) since Tue 2018-04-03 13:17:51 UTC; 17min ago
     Docs: https://docs.docker.com
  Process: 317 ExecStart=/usr/bin/dockerd -H fd:// (code=exited, status=1/FAILURE)
 Main PID: 317 (code=exited, status=1/FAILURE)

Apr 03 13:17:51 intel-x86-64 dockerd[317]: time="2018-04-03T13:17:51.035178755Z" level=warning msg="Running modprobe xt_conntrack failed with message: `modprobe: WARNING: Module xt_conntrack not found in directory /lib/modules/4.8.24-WR9.0.0.10_standard`, error: exit status 1"
Apr 03 13:17:51 intel-x86-64 dockerd[317]: time="2018-04-03T13:17:51.040727372Z" level=info msg="Firewalld running: false"
Apr 03 13:17:51 intel-x86-64 dockerd[317]: time="2018-04-03T13:17:51.170575344Z" level=warning msg="Could not load necessary modules for IPSEC rules: Running modprobe xfrm_user failed with message: `modprobe: WARNING: Module xfrm_user not found in directory /lib/modules/4.8.24-WR9.0.0.10_standard`, error: exit status 1"
Apr 03 13:17:51 intel-x86-64 dockerd[317]: time="2018-04-03T13:17:51.172397913Z" level=info msg="Default bridge (docker0) is assigned with an IP address 172.17.0.0/16. Daemon option --bip can be used to set a preferred IP address"
Apr 03 13:17:51 intel-x86-64 dockerd[317]: Error starting daemon: Error initializing network controller: Error creating default "bridge" network: Failed to Setup IP tables: Unable to enable ACCEPT INCOMING rule:  (iptables failed: iptables --wait -I FORWARD -o docker0 -m conntrack --ctstate RELATED,ESTABLISHED -j ACCEPT: iptables: No chain/target/match by that name.
Apr 03 13:17:51 intel-x86-64 dockerd[317]:  (exit status 1))
Apr 03 13:17:51 intel-x86-64 systemd[1]: docker.service: Main process exited, code=exited, status=1/FAILURE
Apr 03 13:17:51 intel-x86-64 systemd[1]: Failed to start Docker Application Container Engine.
Apr 03 13:17:51 intel-x86-64 systemd[1]: docker.service: Unit entered failed state.
Apr 03 13:17:51 intel-x86-64 systemd[1]: docker.service: Failed with result 'exit-code'.

[-- Attachment #3: Docker 1.png --]
[-- Type: image/png, Size: 13224 bytes --]

[-- Attachment #4: Docker 2.png --]
[-- Type: image/png, Size: 7220 bytes --]

Re: RFT/FYI: docker/containerd/runc uprevs pushed to master

[Bruce Ashfield]

On Wed, Apr 4, 2018 at 12:57 AM, Shakthi Pradeep (tpradeep)
<tpradeep@cisco.com> wrote:
> Hello Bruce,
>
>
>
> Timing is Perfect !!!
>
>
>
> I am currently trying to get Docker CE to work with Yocto. I could include
> the Docker executable in ISO but when I run it I get some errors.
>
>
>
> When I boot the image looks like Docker service start is failing due to
> missing kernel modules. Please refer attached screenshot and below error
> log.

Do you have a bbappend for your 4.8 kernel that adds the docker configuration
fragments ?

That's the most likely reason for the issues.

I was able to run a whole suite of tests against 4.12, 4.14 and 4.15 so those
kernels + fragments are known to work.

Bruce

>
>
>
> * docker.service - Docker Application Container Engine
>
>    Loaded: loaded (/lib/systemd/system/docker.service; enabled; vendor
> preset: enabled)
>
>    Active: failed (Result: exit-code) since Tue 2018-04-03 13:17:51 UTC;
> 17min ago
>
>      Docs: https://docs.docker.com
>
>   Process: 317 ExecStart=/usr/bin/dockerd -H fd:// (code=exited,
> status=1/FAILURE)
>
> Main PID: 317 (code=exited, status=1/FAILURE)
>
>
>
> Apr 03 13:17:51 intel-x86-64 dockerd[317]:
> time="2018-04-03T13:17:51.035178755Z" level=warning msg="Running modprobe
> xt_conntrack failed with message: `modprobe: WARNING: Module xt_conntrack
> not found in directory /lib/modules/4.8.24-WR9.0.0.10_standard`, error: exit
> status 1"
>
> Apr 03 13:17:51 intel-x86-64 dockerd[317]:
> time="2018-04-03T13:17:51.040727372Z" level=info msg="Firewalld running:
> false"
>
> Apr 03 13:17:51 intel-x86-64 dockerd[317]:
> time="2018-04-03T13:17:51.170575344Z" level=warning msg="Could not load
> necessary modules for IPSEC rules: Running modprobe xfrm_user failed with
> message: `modprobe: WARNING: Module xfrm_user not found in directory
> /lib/modules/4.8.24-WR9.0.0.10_standard`, error: exit status 1"
>
> Apr 03 13:17:51 intel-x86-64 dockerd[317]:
> time="2018-04-03T13:17:51.172397913Z" level=info msg="Default bridge
> (docker0) is assigned with an IP address 172.17.0.0/16. Daemon option --bip
> can be used to set a preferred IP address"
>
> Apr 03 13:17:51 intel-x86-64 dockerd[317]: Error starting daemon: Error
> initializing network controller: Error creating default "bridge" network:
> Failed to Setup IP tables: Unable to enable ACCEPT INCOMING rule:  (iptables
> failed: iptables --wait -I FORWARD -o docker0 -m conntrack --ctstate
> RELATED,ESTABLISHED -j ACCEPT: iptables: No chain/target/match by that name.
>
> Apr 03 13:17:51 intel-x86-64 dockerd[317]:  (exit status 1))
>
> Apr 03 13:17:51 intel-x86-64 systemd[1]: docker.service: Main process
> exited, code=exited, status=1/FAILURE
>
> Apr 03 13:17:51 intel-x86-64 systemd[1]: Failed to start Docker Application
> Container Engine.
>
> Apr 03 13:17:51 intel-x86-64 systemd[1]: docker.service: Unit entered failed
> state.
>
> Apr 03 13:17:51 intel-x86-64 systemd[1]: docker.service: Failed with result
> 'exit-code'.
>
>
>
> Regards,
>
> Shakthi
>
>
>
> -----Original Message-----
> From: meta-virtualization-bounces@yoctoproject.org
> [mailto:meta-virtualization-bounces@yoctoproject.org] On Behalf Of Bruce
> Ashfield
> Sent: Wednesday, April 04, 2018 8:44 AM
> To: meta-virtualization@yoctoproject.org
> Subject: [meta-virtualization] RFT/FYI: docker/containerd/runc uprevs pushed
> to master
>
>
>
> Hi all,
>
>
>
> After spending a few days de-tangling the moby/docker/runc/containerd and
> oe-core go infrastructure changes, I was able to run docker/runc/containerd
> through a system/stress test and everything seems to be working.
>
>
>
> There were a few regressions that I worked through, as well as
> build/packaging changes, but I'm no longer seeing any issues and all the
> patches/functionality have been carried forward.
>
>
>
> One thing of note is that the docker and open containers containerd
> split/fork is no longer an issue, so I've modified the default to be the
> opencontainers variant. Similarly, the docker and opencontainers runc are
> very similar. I've kept both variants of both recipes for now, since I'd
> like to track things for a bit longer before declaring the split
> unnecessary.
>
>
>
> Also for those that care, I created a reference docker-ce recipe that tracks
> the docker-ce repo versus the components themselves.  Right now it is
> reference only, since it needs a bit more work, but I wanted to get it out
> there, in case someone really cares about docker-ce (I don't really, but
> someone might!).
>
>
>
> Summary: I just pushed the following changes to master:
>
>
>
>   d7d310ae4113 meta-virt: prefer containerd-opencontainers
>
>   935e3d969ef1 containerd: uprev to v1.0.2
>
>   f5fbfa8ac4db docker-ce: introduce reference recipe/build
>
>   a5074cecf18f docker: uprev to 18.03.0
>
>   e3d960f4fcd9 runc: uprev to 1.0.0-rc5
>
>
>
> If anyone sees regressions, build or architecture issues .. report them to
> me (and the list) and we'll get them fixed up.
>
>
>
> Cheers,
>
>
>
> Bruce
>
>
>
> --
>
> "Thou shalt not follow the NULL pointer, for chaos and madness await thee at
> its end"
>
> --
>
> _______________________________________________
>
> meta-virtualization mailing list
>
> meta-virtualization@yoctoproject.org
>
> https://lists.yoctoproject.org/listinfo/meta-virtualization



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"

Re: RFT/FYI: docker/containerd/runc uprevs pushed to master

[Shakthi Pradeep (tpradeep)]

Hello Bruce,

Yes I was missing the bbappend for kernel config. Got it working after I wrote the mail to you.

Are your changes committed to git repo? Is it in the master branch of Yocto?

Regards,
Shakthi

-----Original Message-----
From: Bruce Ashfield [mailto:bruce.ashfield@gmail.com] 
Sent: Wednesday, April 04, 2018 5:57 PM
To: Shakthi Pradeep (tpradeep) <tpradeep@cisco.com>
Cc: meta-virtualization@yoctoproject.org
Subject: Re: [meta-virtualization] RFT/FYI: docker/containerd/runc uprevs pushed to master

On Wed, Apr 4, 2018 at 12:57 AM, Shakthi Pradeep (tpradeep) <tpradeep@cisco.com> wrote:
> Hello Bruce,
>
>
>
> Timing is Perfect !!!
>
>
>
> I am currently trying to get Docker CE to work with Yocto. I could 
> include the Docker executable in ISO but when I run it I get some errors.
>
>
>
> When I boot the image looks like Docker service start is failing due 
> to missing kernel modules. Please refer attached screenshot and below 
> error log.

Do you have a bbappend for your 4.8 kernel that adds the docker configuration fragments ?

That's the most likely reason for the issues.

I was able to run a whole suite of tests against 4.12, 4.14 and 4.15 so those kernels + fragments are known to work.

Bruce

>
>
>
> * docker.service - Docker Application Container Engine
>
>    Loaded: loaded (/lib/systemd/system/docker.service; enabled; vendor
> preset: enabled)
>
>    Active: failed (Result: exit-code) since Tue 2018-04-03 13:17:51 
> UTC; 17min ago
>
>      Docs: https://docs.docker.com
>
>   Process: 317 ExecStart=/usr/bin/dockerd -H fd:// (code=exited,
> status=1/FAILURE)
>
> Main PID: 317 (code=exited, status=1/FAILURE)
>
>
>
> Apr 03 13:17:51 intel-x86-64 dockerd[317]:
> time="2018-04-03T13:17:51.035178755Z" level=warning msg="Running 
> modprobe xt_conntrack failed with message: `modprobe: WARNING: Module 
> xt_conntrack not found in directory 
> /lib/modules/4.8.24-WR9.0.0.10_standard`, error: exit status 1"
>
> Apr 03 13:17:51 intel-x86-64 dockerd[317]:
> time="2018-04-03T13:17:51.040727372Z" level=info msg="Firewalld running:
> false"
>
> Apr 03 13:17:51 intel-x86-64 dockerd[317]:
> time="2018-04-03T13:17:51.170575344Z" level=warning msg="Could not 
> load necessary modules for IPSEC rules: Running modprobe xfrm_user 
> failed with
> message: `modprobe: WARNING: Module xfrm_user not found in directory 
> /lib/modules/4.8.24-WR9.0.0.10_standard`, error: exit status 1"
>
> Apr 03 13:17:51 intel-x86-64 dockerd[317]:
> time="2018-04-03T13:17:51.172397913Z" level=info msg="Default bridge
> (docker0) is assigned with an IP address 172.17.0.0/16. Daemon option 
> --bip can be used to set a preferred IP address"
>
> Apr 03 13:17:51 intel-x86-64 dockerd[317]: Error starting daemon: 
> Error initializing network controller: Error creating default "bridge" network:
> Failed to Setup IP tables: Unable to enable ACCEPT INCOMING rule:  
> (iptables
> failed: iptables --wait -I FORWARD -o docker0 -m conntrack --ctstate 
> RELATED,ESTABLISHED -j ACCEPT: iptables: No chain/target/match by that name.
>
> Apr 03 13:17:51 intel-x86-64 dockerd[317]:  (exit status 1))
>
> Apr 03 13:17:51 intel-x86-64 systemd[1]: docker.service: Main process 
> exited, code=exited, status=1/FAILURE
>
> Apr 03 13:17:51 intel-x86-64 systemd[1]: Failed to start Docker 
> Application Container Engine.
>
> Apr 03 13:17:51 intel-x86-64 systemd[1]: docker.service: Unit entered 
> failed state.
>
> Apr 03 13:17:51 intel-x86-64 systemd[1]: docker.service: Failed with 
> result 'exit-code'.
>
>
>
> Regards,
>
> Shakthi
>
>
>
> -----Original Message-----
> From: meta-virtualization-bounces@yoctoproject.org
> [mailto:meta-virtualization-bounces@yoctoproject.org] On Behalf Of 
> Bruce Ashfield
> Sent: Wednesday, April 04, 2018 8:44 AM
> To: meta-virtualization@yoctoproject.org
> Subject: [meta-virtualization] RFT/FYI: docker/containerd/runc uprevs 
> pushed to master
>
>
>
> Hi all,
>
>
>
> After spending a few days de-tangling the moby/docker/runc/containerd 
> and oe-core go infrastructure changes, I was able to run 
> docker/runc/containerd through a system/stress test and everything seems to be working.
>
>
>
> There were a few regressions that I worked through, as well as 
> build/packaging changes, but I'm no longer seeing any issues and all 
> the patches/functionality have been carried forward.
>
>
>
> One thing of note is that the docker and open containers containerd 
> split/fork is no longer an issue, so I've modified the default to be 
> the opencontainers variant. Similarly, the docker and opencontainers 
> runc are very similar. I've kept both variants of both recipes for 
> now, since I'd like to track things for a bit longer before declaring 
> the split unnecessary.
>
>
>
> Also for those that care, I created a reference docker-ce recipe that 
> tracks the docker-ce repo versus the components themselves.  Right now 
> it is reference only, since it needs a bit more work, but I wanted to 
> get it out there, in case someone really cares about docker-ce (I 
> don't really, but someone might!).
>
>
>
> Summary: I just pushed the following changes to master:
>
>
>
>   d7d310ae4113 meta-virt: prefer containerd-opencontainers
>
>   935e3d969ef1 containerd: uprev to v1.0.2
>
>   f5fbfa8ac4db docker-ce: introduce reference recipe/build
>
>   a5074cecf18f docker: uprev to 18.03.0
>
>   e3d960f4fcd9 runc: uprev to 1.0.0-rc5
>
>
>
> If anyone sees regressions, build or architecture issues .. report 
> them to me (and the list) and we'll get them fixed up.
>
>
>
> Cheers,
>
>
>
> Bruce
>
>
>
> --
>
> "Thou shalt not follow the NULL pointer, for chaos and madness await 
> thee at its end"
>
> --
>
> _______________________________________________
>
> meta-virtualization mailing list
>
> meta-virtualization@yoctoproject.org
>
> https://lists.yoctoproject.org/listinfo/meta-virtualization



--
"Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end"

Re: RFT/FYI: docker/containerd/runc uprevs pushed to master

[Bruce Ashfield]

Excellent news.

Yes, everything is in master of meta-virtualization now. That way it
will have time to soak a bit before the upcoming release.

Cheers,

Bruce

On Wed, Apr 4, 2018 at 8:32 AM, Shakthi Pradeep (tpradeep)
<tpradeep@cisco.com> wrote:
> Hello Bruce,
>
> Yes I was missing the bbappend for kernel config. Got it working after I wrote the mail to you.
>
> Are your changes committed to git repo? Is it in the master branch of Yocto?
>
> Regards,
> Shakthi
>
> -----Original Message-----
> From: Bruce Ashfield [mailto:bruce.ashfield@gmail.com]
> Sent: Wednesday, April 04, 2018 5:57 PM
> To: Shakthi Pradeep (tpradeep) <tpradeep@cisco.com>
> Cc: meta-virtualization@yoctoproject.org
> Subject: Re: [meta-virtualization] RFT/FYI: docker/containerd/runc uprevs pushed to master
>
> On Wed, Apr 4, 2018 at 12:57 AM, Shakthi Pradeep (tpradeep) <tpradeep@cisco.com> wrote:
>> Hello Bruce,
>>
>>
>>
>> Timing is Perfect !!!
>>
>>
>>
>> I am currently trying to get Docker CE to work with Yocto. I could
>> include the Docker executable in ISO but when I run it I get some errors.
>>
>>
>>
>> When I boot the image looks like Docker service start is failing due
>> to missing kernel modules. Please refer attached screenshot and below
>> error log.
>
> Do you have a bbappend for your 4.8 kernel that adds the docker configuration fragments ?
>
> That's the most likely reason for the issues.
>
> I was able to run a whole suite of tests against 4.12, 4.14 and 4.15 so those kernels + fragments are known to work.
>
> Bruce
>
>>
>>
>>
>> * docker.service - Docker Application Container Engine
>>
>>    Loaded: loaded (/lib/systemd/system/docker.service; enabled; vendor
>> preset: enabled)
>>
>>    Active: failed (Result: exit-code) since Tue 2018-04-03 13:17:51
>> UTC; 17min ago
>>
>>      Docs: https://docs.docker.com
>>
>>   Process: 317 ExecStart=/usr/bin/dockerd -H fd:// (code=exited,
>> status=1/FAILURE)
>>
>> Main PID: 317 (code=exited, status=1/FAILURE)
>>
>>
>>
>> Apr 03 13:17:51 intel-x86-64 dockerd[317]:
>> time="2018-04-03T13:17:51.035178755Z" level=warning msg="Running
>> modprobe xt_conntrack failed with message: `modprobe: WARNING: Module
>> xt_conntrack not found in directory
>> /lib/modules/4.8.24-WR9.0.0.10_standard`, error: exit status 1"
>>
>> Apr 03 13:17:51 intel-x86-64 dockerd[317]:
>> time="2018-04-03T13:17:51.040727372Z" level=info msg="Firewalld running:
>> false"
>>
>> Apr 03 13:17:51 intel-x86-64 dockerd[317]:
>> time="2018-04-03T13:17:51.170575344Z" level=warning msg="Could not
>> load necessary modules for IPSEC rules: Running modprobe xfrm_user
>> failed with
>> message: `modprobe: WARNING: Module xfrm_user not found in directory
>> /lib/modules/4.8.24-WR9.0.0.10_standard`, error: exit status 1"
>>
>> Apr 03 13:17:51 intel-x86-64 dockerd[317]:
>> time="2018-04-03T13:17:51.172397913Z" level=info msg="Default bridge
>> (docker0) is assigned with an IP address 172.17.0.0/16. Daemon option
>> --bip can be used to set a preferred IP address"
>>
>> Apr 03 13:17:51 intel-x86-64 dockerd[317]: Error starting daemon:
>> Error initializing network controller: Error creating default "bridge" network:
>> Failed to Setup IP tables: Unable to enable ACCEPT INCOMING rule:
>> (iptables
>> failed: iptables --wait -I FORWARD -o docker0 -m conntrack --ctstate
>> RELATED,ESTABLISHED -j ACCEPT: iptables: No chain/target/match by that name.
>>
>> Apr 03 13:17:51 intel-x86-64 dockerd[317]:  (exit status 1))
>>
>> Apr 03 13:17:51 intel-x86-64 systemd[1]: docker.service: Main process
>> exited, code=exited, status=1/FAILURE
>>
>> Apr 03 13:17:51 intel-x86-64 systemd[1]: Failed to start Docker
>> Application Container Engine.
>>
>> Apr 03 13:17:51 intel-x86-64 systemd[1]: docker.service: Unit entered
>> failed state.
>>
>> Apr 03 13:17:51 intel-x86-64 systemd[1]: docker.service: Failed with
>> result 'exit-code'.
>>
>>
>>
>> Regards,
>>
>> Shakthi
>>
>>
>>
>> -----Original Message-----
>> From: meta-virtualization-bounces@yoctoproject.org
>> [mailto:meta-virtualization-bounces@yoctoproject.org] On Behalf Of
>> Bruce Ashfield
>> Sent: Wednesday, April 04, 2018 8:44 AM
>> To: meta-virtualization@yoctoproject.org
>> Subject: [meta-virtualization] RFT/FYI: docker/containerd/runc uprevs
>> pushed to master
>>
>>
>>
>> Hi all,
>>
>>
>>
>> After spending a few days de-tangling the moby/docker/runc/containerd
>> and oe-core go infrastructure changes, I was able to run
>> docker/runc/containerd through a system/stress test and everything seems to be working.
>>
>>
>>
>> There were a few regressions that I worked through, as well as
>> build/packaging changes, but I'm no longer seeing any issues and all
>> the patches/functionality have been carried forward.
>>
>>
>>
>> One thing of note is that the docker and open containers containerd
>> split/fork is no longer an issue, so I've modified the default to be
>> the opencontainers variant. Similarly, the docker and opencontainers
>> runc are very similar. I've kept both variants of both recipes for
>> now, since I'd like to track things for a bit longer before declaring
>> the split unnecessary.
>>
>>
>>
>> Also for those that care, I created a reference docker-ce recipe that
>> tracks the docker-ce repo versus the components themselves.  Right now
>> it is reference only, since it needs a bit more work, but I wanted to
>> get it out there, in case someone really cares about docker-ce (I
>> don't really, but someone might!).
>>
>>
>>
>> Summary: I just pushed the following changes to master:
>>
>>
>>
>>   d7d310ae4113 meta-virt: prefer containerd-opencontainers
>>
>>   935e3d969ef1 containerd: uprev to v1.0.2
>>
>>   f5fbfa8ac4db docker-ce: introduce reference recipe/build
>>
>>   a5074cecf18f docker: uprev to 18.03.0
>>
>>   e3d960f4fcd9 runc: uprev to 1.0.0-rc5
>>
>>
>>
>> If anyone sees regressions, build or architecture issues .. report
>> them to me (and the list) and we'll get them fixed up.
>>
>>
>>
>> Cheers,
>>
>>
>>
>> Bruce
>>
>>
>>
>> --
>>
>> "Thou shalt not follow the NULL pointer, for chaos and madness await
>> thee at its end"
>>
>> --
>>
>> _______________________________________________
>>
>> meta-virtualization mailing list
>>
>> meta-virtualization@yoctoproject.org
>>
>> https://lists.yoctoproject.org/listinfo/meta-virtualization
>
>
>
> --
> "Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end"



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"

Re: RFT/FYI: docker/containerd/runc uprevs pushed to master

[Shakthi Pradeep (tpradeep)]

Hello Bruce,

Which version of Docker are you running.

I just noticed I am running Docker 1.13.1 which is too old.

How do I migrate to latest version of Docker & also corresponding dependencies.

Regards,
Shakthi 

-----Original Message-----
From: Bruce Ashfield [mailto:bruce.ashfield@gmail.com] 
Sent: Wednesday, April 04, 2018 6:45 PM
To: Shakthi Pradeep (tpradeep) <tpradeep@cisco.com>
Cc: meta-virtualization@yoctoproject.org
Subject: Re: [meta-virtualization] RFT/FYI: docker/containerd/runc uprevs pushed to master

Excellent news.

Yes, everything is in master of meta-virtualization now. That way it will have time to soak a bit before the upcoming release.

Cheers,

Bruce

On Wed, Apr 4, 2018 at 8:32 AM, Shakthi Pradeep (tpradeep) <tpradeep@cisco.com> wrote:
> Hello Bruce,
>
> Yes I was missing the bbappend for kernel config. Got it working after I wrote the mail to you.
>
> Are your changes committed to git repo? Is it in the master branch of Yocto?
>
> Regards,
> Shakthi
>
> -----Original Message-----
> From: Bruce Ashfield [mailto:bruce.ashfield@gmail.com]
> Sent: Wednesday, April 04, 2018 5:57 PM
> To: Shakthi Pradeep (tpradeep) <tpradeep@cisco.com>
> Cc: meta-virtualization@yoctoproject.org
> Subject: Re: [meta-virtualization] RFT/FYI: docker/containerd/runc 
> uprevs pushed to master
>
> On Wed, Apr 4, 2018 at 12:57 AM, Shakthi Pradeep (tpradeep) <tpradeep@cisco.com> wrote:
>> Hello Bruce,
>>
>>
>>
>> Timing is Perfect !!!
>>
>>
>>
>> I am currently trying to get Docker CE to work with Yocto. I could 
>> include the Docker executable in ISO but when I run it I get some errors.
>>
>>
>>
>> When I boot the image looks like Docker service start is failing due 
>> to missing kernel modules. Please refer attached screenshot and below 
>> error log.
>
> Do you have a bbappend for your 4.8 kernel that adds the docker configuration fragments ?
>
> That's the most likely reason for the issues.
>
> I was able to run a whole suite of tests against 4.12, 4.14 and 4.15 so those kernels + fragments are known to work.
>
> Bruce
>
>>
>>
>>
>> * docker.service - Docker Application Container Engine
>>
>>    Loaded: loaded (/lib/systemd/system/docker.service; enabled; 
>> vendor
>> preset: enabled)
>>
>>    Active: failed (Result: exit-code) since Tue 2018-04-03 13:17:51 
>> UTC; 17min ago
>>
>>      Docs: https://docs.docker.com
>>
>>   Process: 317 ExecStart=/usr/bin/dockerd -H fd:// (code=exited,
>> status=1/FAILURE)
>>
>> Main PID: 317 (code=exited, status=1/FAILURE)
>>
>>
>>
>> Apr 03 13:17:51 intel-x86-64 dockerd[317]:
>> time="2018-04-03T13:17:51.035178755Z" level=warning msg="Running 
>> modprobe xt_conntrack failed with message: `modprobe: WARNING: Module 
>> xt_conntrack not found in directory 
>> /lib/modules/4.8.24-WR9.0.0.10_standard`, error: exit status 1"
>>
>> Apr 03 13:17:51 intel-x86-64 dockerd[317]:
>> time="2018-04-03T13:17:51.040727372Z" level=info msg="Firewalld running:
>> false"
>>
>> Apr 03 13:17:51 intel-x86-64 dockerd[317]:
>> time="2018-04-03T13:17:51.170575344Z" level=warning msg="Could not 
>> load necessary modules for IPSEC rules: Running modprobe xfrm_user 
>> failed with
>> message: `modprobe: WARNING: Module xfrm_user not found in directory 
>> /lib/modules/4.8.24-WR9.0.0.10_standard`, error: exit status 1"
>>
>> Apr 03 13:17:51 intel-x86-64 dockerd[317]:
>> time="2018-04-03T13:17:51.172397913Z" level=info msg="Default bridge
>> (docker0) is assigned with an IP address 172.17.0.0/16. Daemon option 
>> --bip can be used to set a preferred IP address"
>>
>> Apr 03 13:17:51 intel-x86-64 dockerd[317]: Error starting daemon:
>> Error initializing network controller: Error creating default "bridge" network:
>> Failed to Setup IP tables: Unable to enable ACCEPT INCOMING rule:
>> (iptables
>> failed: iptables --wait -I FORWARD -o docker0 -m conntrack --ctstate 
>> RELATED,ESTABLISHED -j ACCEPT: iptables: No chain/target/match by that name.
>>
>> Apr 03 13:17:51 intel-x86-64 dockerd[317]:  (exit status 1))
>>
>> Apr 03 13:17:51 intel-x86-64 systemd[1]: docker.service: Main process 
>> exited, code=exited, status=1/FAILURE
>>
>> Apr 03 13:17:51 intel-x86-64 systemd[1]: Failed to start Docker 
>> Application Container Engine.
>>
>> Apr 03 13:17:51 intel-x86-64 systemd[1]: docker.service: Unit entered 
>> failed state.
>>
>> Apr 03 13:17:51 intel-x86-64 systemd[1]: docker.service: Failed with 
>> result 'exit-code'.
>>
>>
>>
>> Regards,
>>
>> Shakthi
>>
>>
>>
>> -----Original Message-----
>> From: meta-virtualization-bounces@yoctoproject.org
>> [mailto:meta-virtualization-bounces@yoctoproject.org] On Behalf Of 
>> Bruce Ashfield
>> Sent: Wednesday, April 04, 2018 8:44 AM
>> To: meta-virtualization@yoctoproject.org
>> Subject: [meta-virtualization] RFT/FYI: docker/containerd/runc uprevs 
>> pushed to master
>>
>>
>>
>> Hi all,
>>
>>
>>
>> After spending a few days de-tangling the moby/docker/runc/containerd 
>> and oe-core go infrastructure changes, I was able to run 
>> docker/runc/containerd through a system/stress test and everything seems to be working.
>>
>>
>>
>> There were a few regressions that I worked through, as well as 
>> build/packaging changes, but I'm no longer seeing any issues and all 
>> the patches/functionality have been carried forward.
>>
>>
>>
>> One thing of note is that the docker and open containers containerd 
>> split/fork is no longer an issue, so I've modified the default to be 
>> the opencontainers variant. Similarly, the docker and opencontainers 
>> runc are very similar. I've kept both variants of both recipes for 
>> now, since I'd like to track things for a bit longer before declaring 
>> the split unnecessary.
>>
>>
>>
>> Also for those that care, I created a reference docker-ce recipe that 
>> tracks the docker-ce repo versus the components themselves.  Right 
>> now it is reference only, since it needs a bit more work, but I 
>> wanted to get it out there, in case someone really cares about 
>> docker-ce (I don't really, but someone might!).
>>
>>
>>
>> Summary: I just pushed the following changes to master:
>>
>>
>>
>>   d7d310ae4113 meta-virt: prefer containerd-opencontainers
>>
>>   935e3d969ef1 containerd: uprev to v1.0.2
>>
>>   f5fbfa8ac4db docker-ce: introduce reference recipe/build
>>
>>   a5074cecf18f docker: uprev to 18.03.0
>>
>>   e3d960f4fcd9 runc: uprev to 1.0.0-rc5
>>
>>
>>
>> If anyone sees regressions, build or architecture issues .. report 
>> them to me (and the list) and we'll get them fixed up.
>>
>>
>>
>> Cheers,
>>
>>
>>
>> Bruce
>>
>>
>>
>> --
>>
>> "Thou shalt not follow the NULL pointer, for chaos and madness await 
>> thee at its end"
>>
>> --
>>
>> _______________________________________________
>>
>> meta-virtualization mailing list
>>
>> meta-virtualization@yoctoproject.org
>>
>> https://lists.yoctoproject.org/listinfo/meta-virtualization
>
>
>
> --
> "Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end"



--
"Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end"

Re: RFT/FYI: docker/containerd/runc uprevs pushed to master

[Bruce Ashfield]

root@cube-server:~# docker --version
Docker version 18.03.0, build 0f1bb353423e

If you are building meta-virt master, the update should happen
automatically since the PV of the updated recipe is higher than the
old one. All the dependencies will follow after that.

Bruce

On Thu, Apr 5, 2018 at 9:02 AM, Shakthi Pradeep (tpradeep)
<tpradeep@cisco.com> wrote:
> Hello Bruce,
>
> Which version of Docker are you running.
>
> I just noticed I am running Docker 1.13.1 which is too old.
>
> How do I migrate to latest version of Docker & also corresponding dependencies.
>
> Regards,
> Shakthi
>
> -----Original Message-----
> From: Bruce Ashfield [mailto:bruce.ashfield@gmail.com]
> Sent: Wednesday, April 04, 2018 6:45 PM
> To: Shakthi Pradeep (tpradeep) <tpradeep@cisco.com>
> Cc: meta-virtualization@yoctoproject.org
> Subject: Re: [meta-virtualization] RFT/FYI: docker/containerd/runc uprevs pushed to master
>
> Excellent news.
>
> Yes, everything is in master of meta-virtualization now. That way it will have time to soak a bit before the upcoming release.
>
> Cheers,
>
> Bruce
>
> On Wed, Apr 4, 2018 at 8:32 AM, Shakthi Pradeep (tpradeep) <tpradeep@cisco.com> wrote:
>> Hello Bruce,
>>
>> Yes I was missing the bbappend for kernel config. Got it working after I wrote the mail to you.
>>
>> Are your changes committed to git repo? Is it in the master branch of Yocto?
>>
>> Regards,
>> Shakthi
>>
>> -----Original Message-----
>> From: Bruce Ashfield [mailto:bruce.ashfield@gmail.com]
>> Sent: Wednesday, April 04, 2018 5:57 PM
>> To: Shakthi Pradeep (tpradeep) <tpradeep@cisco.com>
>> Cc: meta-virtualization@yoctoproject.org
>> Subject: Re: [meta-virtualization] RFT/FYI: docker/containerd/runc
>> uprevs pushed to master
>>
>> On Wed, Apr 4, 2018 at 12:57 AM, Shakthi Pradeep (tpradeep) <tpradeep@cisco.com> wrote:
>>> Hello Bruce,
>>>
>>>
>>>
>>> Timing is Perfect !!!
>>>
>>>
>>>
>>> I am currently trying to get Docker CE to work with Yocto. I could
>>> include the Docker executable in ISO but when I run it I get some errors.
>>>
>>>
>>>
>>> When I boot the image looks like Docker service start is failing due
>>> to missing kernel modules. Please refer attached screenshot and below
>>> error log.
>>
>> Do you have a bbappend for your 4.8 kernel that adds the docker configuration fragments ?
>>
>> That's the most likely reason for the issues.
>>
>> I was able to run a whole suite of tests against 4.12, 4.14 and 4.15 so those kernels + fragments are known to work.
>>
>> Bruce
>>
>>>
>>>
>>>
>>> * docker.service - Docker Application Container Engine
>>>
>>>    Loaded: loaded (/lib/systemd/system/docker.service; enabled;
>>> vendor
>>> preset: enabled)
>>>
>>>    Active: failed (Result: exit-code) since Tue 2018-04-03 13:17:51
>>> UTC; 17min ago
>>>
>>>      Docs: https://docs.docker.com
>>>
>>>   Process: 317 ExecStart=/usr/bin/dockerd -H fd:// (code=exited,
>>> status=1/FAILURE)
>>>
>>> Main PID: 317 (code=exited, status=1/FAILURE)
>>>
>>>
>>>
>>> Apr 03 13:17:51 intel-x86-64 dockerd[317]:
>>> time="2018-04-03T13:17:51.035178755Z" level=warning msg="Running
>>> modprobe xt_conntrack failed with message: `modprobe: WARNING: Module
>>> xt_conntrack not found in directory
>>> /lib/modules/4.8.24-WR9.0.0.10_standard`, error: exit status 1"
>>>
>>> Apr 03 13:17:51 intel-x86-64 dockerd[317]:
>>> time="2018-04-03T13:17:51.040727372Z" level=info msg="Firewalld running:
>>> false"
>>>
>>> Apr 03 13:17:51 intel-x86-64 dockerd[317]:
>>> time="2018-04-03T13:17:51.170575344Z" level=warning msg="Could not
>>> load necessary modules for IPSEC rules: Running modprobe xfrm_user
>>> failed with
>>> message: `modprobe: WARNING: Module xfrm_user not found in directory
>>> /lib/modules/4.8.24-WR9.0.0.10_standard`, error: exit status 1"
>>>
>>> Apr 03 13:17:51 intel-x86-64 dockerd[317]:
>>> time="2018-04-03T13:17:51.172397913Z" level=info msg="Default bridge
>>> (docker0) is assigned with an IP address 172.17.0.0/16. Daemon option
>>> --bip can be used to set a preferred IP address"
>>>
>>> Apr 03 13:17:51 intel-x86-64 dockerd[317]: Error starting daemon:
>>> Error initializing network controller: Error creating default "bridge" network:
>>> Failed to Setup IP tables: Unable to enable ACCEPT INCOMING rule:
>>> (iptables
>>> failed: iptables --wait -I FORWARD -o docker0 -m conntrack --ctstate
>>> RELATED,ESTABLISHED -j ACCEPT: iptables: No chain/target/match by that name.
>>>
>>> Apr 03 13:17:51 intel-x86-64 dockerd[317]:  (exit status 1))
>>>
>>> Apr 03 13:17:51 intel-x86-64 systemd[1]: docker.service: Main process
>>> exited, code=exited, status=1/FAILURE
>>>
>>> Apr 03 13:17:51 intel-x86-64 systemd[1]: Failed to start Docker
>>> Application Container Engine.
>>>
>>> Apr 03 13:17:51 intel-x86-64 systemd[1]: docker.service: Unit entered
>>> failed state.
>>>
>>> Apr 03 13:17:51 intel-x86-64 systemd[1]: docker.service: Failed with
>>> result 'exit-code'.
>>>
>>>
>>>
>>> Regards,
>>>
>>> Shakthi
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: meta-virtualization-bounces@yoctoproject.org
>>> [mailto:meta-virtualization-bounces@yoctoproject.org] On Behalf Of
>>> Bruce Ashfield
>>> Sent: Wednesday, April 04, 2018 8:44 AM
>>> To: meta-virtualization@yoctoproject.org
>>> Subject: [meta-virtualization] RFT/FYI: docker/containerd/runc uprevs
>>> pushed to master
>>>
>>>
>>>
>>> Hi all,
>>>
>>>
>>>
>>> After spending a few days de-tangling the moby/docker/runc/containerd
>>> and oe-core go infrastructure changes, I was able to run
>>> docker/runc/containerd through a system/stress test and everything seems to be working.
>>>
>>>
>>>
>>> There were a few regressions that I worked through, as well as
>>> build/packaging changes, but I'm no longer seeing any issues and all
>>> the patches/functionality have been carried forward.
>>>
>>>
>>>
>>> One thing of note is that the docker and open containers containerd
>>> split/fork is no longer an issue, so I've modified the default to be
>>> the opencontainers variant. Similarly, the docker and opencontainers
>>> runc are very similar. I've kept both variants of both recipes for
>>> now, since I'd like to track things for a bit longer before declaring
>>> the split unnecessary.
>>>
>>>
>>>
>>> Also for those that care, I created a reference docker-ce recipe that
>>> tracks the docker-ce repo versus the components themselves.  Right
>>> now it is reference only, since it needs a bit more work, but I
>>> wanted to get it out there, in case someone really cares about
>>> docker-ce (I don't really, but someone might!).
>>>
>>>
>>>
>>> Summary: I just pushed the following changes to master:
>>>
>>>
>>>
>>>   d7d310ae4113 meta-virt: prefer containerd-opencontainers
>>>
>>>   935e3d969ef1 containerd: uprev to v1.0.2
>>>
>>>   f5fbfa8ac4db docker-ce: introduce reference recipe/build
>>>
>>>   a5074cecf18f docker: uprev to 18.03.0
>>>
>>>   e3d960f4fcd9 runc: uprev to 1.0.0-rc5
>>>
>>>
>>>
>>> If anyone sees regressions, build or architecture issues .. report
>>> them to me (and the list) and we'll get them fixed up.
>>>
>>>
>>>
>>> Cheers,
>>>
>>>
>>>
>>> Bruce
>>>
>>>
>>>
>>> --
>>>
>>> "Thou shalt not follow the NULL pointer, for chaos and madness await
>>> thee at its end"
>>>
>>> --
>>>
>>> _______________________________________________
>>>
>>> meta-virtualization mailing list
>>>
>>> meta-virtualization@yoctoproject.org
>>>
>>> https://lists.yoctoproject.org/listinfo/meta-virtualization
>>
>>
>>
>> --
>> "Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end"
>
>
>
> --
> "Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end"



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"

Re: RFT/FYI: docker/containerd/runc uprevs pushed to master

[Shakthi Pradeep (tpradeep)]

Hello Bruce,

I am actually working on a repo from Third Party. So here things are little outdated.

I found some info from http://git.yoctoproject.org

I am currently using Docker 1.13.0 which was committed on 2017-01-20

http://git.yoctoproject.org/cgit/cgit.cgi/meta-virtualization/commit/recipes-containers/docker?id=0b631bf01487d3d1be0c91ea7749168fb3c47dcb

I need to migrate to 18.03.0 which you committed 3 days ago 

http://git.yoctoproject.org/cgit/cgit.cgi/meta-virtualization/commit/recipes-containers/docker?id=a5074cecf18faea1a325c8ac9220d2df41250af5

If I take recipe from above commit and update my workspace, will all the dependencies migrate to latest automatically? 

Regards,
Shakthi

-----Original Message-----
From: Bruce Ashfield [mailto:bruce.ashfield@gmail.com] 
Sent: Thursday, April 05, 2018 6:46 PM
To: Shakthi Pradeep (tpradeep) <tpradeep@cisco.com>
Cc: meta-virtualization@yoctoproject.org
Subject: Re: [meta-virtualization] RFT/FYI: docker/containerd/runc uprevs pushed to master

root@cube-server:~# docker --version
Docker version 18.03.0, build 0f1bb353423e

If you are building meta-virt master, the update should happen automatically since the PV of the updated recipe is higher than the old one. All the dependencies will follow after that.

Bruce

On Thu, Apr 5, 2018 at 9:02 AM, Shakthi Pradeep (tpradeep) <tpradeep@cisco.com> wrote:
> Hello Bruce,
>
> Which version of Docker are you running.
>
> I just noticed I am running Docker 1.13.1 which is too old.
>
> How do I migrate to latest version of Docker & also corresponding dependencies.
>
> Regards,
> Shakthi
>
> -----Original Message-----
> From: Bruce Ashfield [mailto:bruce.ashfield@gmail.com]
> Sent: Wednesday, April 04, 2018 6:45 PM
> To: Shakthi Pradeep (tpradeep) <tpradeep@cisco.com>
> Cc: meta-virtualization@yoctoproject.org
> Subject: Re: [meta-virtualization] RFT/FYI: docker/containerd/runc 
> uprevs pushed to master
>
> Excellent news.
>
> Yes, everything is in master of meta-virtualization now. That way it will have time to soak a bit before the upcoming release.
>
> Cheers,
>
> Bruce
>
> On Wed, Apr 4, 2018 at 8:32 AM, Shakthi Pradeep (tpradeep) <tpradeep@cisco.com> wrote:
>> Hello Bruce,
>>
>> Yes I was missing the bbappend for kernel config. Got it working after I wrote the mail to you.
>>
>> Are your changes committed to git repo? Is it in the master branch of Yocto?
>>
>> Regards,
>> Shakthi
>>
>> -----Original Message-----
>> From: Bruce Ashfield [mailto:bruce.ashfield@gmail.com]
>> Sent: Wednesday, April 04, 2018 5:57 PM
>> To: Shakthi Pradeep (tpradeep) <tpradeep@cisco.com>
>> Cc: meta-virtualization@yoctoproject.org
>> Subject: Re: [meta-virtualization] RFT/FYI: docker/containerd/runc 
>> uprevs pushed to master
>>
>> On Wed, Apr 4, 2018 at 12:57 AM, Shakthi Pradeep (tpradeep) <tpradeep@cisco.com> wrote:
>>> Hello Bruce,
>>>
>>>
>>>
>>> Timing is Perfect !!!
>>>
>>>
>>>
>>> I am currently trying to get Docker CE to work with Yocto. I could 
>>> include the Docker executable in ISO but when I run it I get some errors.
>>>
>>>
>>>
>>> When I boot the image looks like Docker service start is failing due 
>>> to missing kernel modules. Please refer attached screenshot and 
>>> below error log.
>>
>> Do you have a bbappend for your 4.8 kernel that adds the docker configuration fragments ?
>>
>> That's the most likely reason for the issues.
>>
>> I was able to run a whole suite of tests against 4.12, 4.14 and 4.15 so those kernels + fragments are known to work.
>>
>> Bruce
>>
>>>
>>>
>>>
>>> * docker.service - Docker Application Container Engine
>>>
>>>    Loaded: loaded (/lib/systemd/system/docker.service; enabled; 
>>> vendor
>>> preset: enabled)
>>>
>>>    Active: failed (Result: exit-code) since Tue 2018-04-03 13:17:51 
>>> UTC; 17min ago
>>>
>>>      Docs: https://docs.docker.com
>>>
>>>   Process: 317 ExecStart=/usr/bin/dockerd -H fd:// (code=exited,
>>> status=1/FAILURE)
>>>
>>> Main PID: 317 (code=exited, status=1/FAILURE)
>>>
>>>
>>>
>>> Apr 03 13:17:51 intel-x86-64 dockerd[317]:
>>> time="2018-04-03T13:17:51.035178755Z" level=warning msg="Running 
>>> modprobe xt_conntrack failed with message: `modprobe: WARNING: 
>>> Module xt_conntrack not found in directory 
>>> /lib/modules/4.8.24-WR9.0.0.10_standard`, error: exit status 1"
>>>
>>> Apr 03 13:17:51 intel-x86-64 dockerd[317]:
>>> time="2018-04-03T13:17:51.040727372Z" level=info msg="Firewalld running:
>>> false"
>>>
>>> Apr 03 13:17:51 intel-x86-64 dockerd[317]:
>>> time="2018-04-03T13:17:51.170575344Z" level=warning msg="Could not 
>>> load necessary modules for IPSEC rules: Running modprobe xfrm_user 
>>> failed with
>>> message: `modprobe: WARNING: Module xfrm_user not found in directory 
>>> /lib/modules/4.8.24-WR9.0.0.10_standard`, error: exit status 1"
>>>
>>> Apr 03 13:17:51 intel-x86-64 dockerd[317]:
>>> time="2018-04-03T13:17:51.172397913Z" level=info msg="Default bridge
>>> (docker0) is assigned with an IP address 172.17.0.0/16. Daemon 
>>> option --bip can be used to set a preferred IP address"
>>>
>>> Apr 03 13:17:51 intel-x86-64 dockerd[317]: Error starting daemon:
>>> Error initializing network controller: Error creating default "bridge" network:
>>> Failed to Setup IP tables: Unable to enable ACCEPT INCOMING rule:
>>> (iptables
>>> failed: iptables --wait -I FORWARD -o docker0 -m conntrack --ctstate 
>>> RELATED,ESTABLISHED -j ACCEPT: iptables: No chain/target/match by that name.
>>>
>>> Apr 03 13:17:51 intel-x86-64 dockerd[317]:  (exit status 1))
>>>
>>> Apr 03 13:17:51 intel-x86-64 systemd[1]: docker.service: Main 
>>> process exited, code=exited, status=1/FAILURE
>>>
>>> Apr 03 13:17:51 intel-x86-64 systemd[1]: Failed to start Docker 
>>> Application Container Engine.
>>>
>>> Apr 03 13:17:51 intel-x86-64 systemd[1]: docker.service: Unit 
>>> entered failed state.
>>>
>>> Apr 03 13:17:51 intel-x86-64 systemd[1]: docker.service: Failed with 
>>> result 'exit-code'.
>>>
>>>
>>>
>>> Regards,
>>>
>>> Shakthi
>>>
>>>
>>>
>>> -----Original Message-----
>>> From: meta-virtualization-bounces@yoctoproject.org
>>> [mailto:meta-virtualization-bounces@yoctoproject.org] On Behalf Of 
>>> Bruce Ashfield
>>> Sent: Wednesday, April 04, 2018 8:44 AM
>>> To: meta-virtualization@yoctoproject.org
>>> Subject: [meta-virtualization] RFT/FYI: docker/containerd/runc 
>>> uprevs pushed to master
>>>
>>>
>>>
>>> Hi all,
>>>
>>>
>>>
>>> After spending a few days de-tangling the 
>>> moby/docker/runc/containerd and oe-core go infrastructure changes, I 
>>> was able to run docker/runc/containerd through a system/stress test and everything seems to be working.
>>>
>>>
>>>
>>> There were a few regressions that I worked through, as well as 
>>> build/packaging changes, but I'm no longer seeing any issues and all 
>>> the patches/functionality have been carried forward.
>>>
>>>
>>>
>>> One thing of note is that the docker and open containers containerd 
>>> split/fork is no longer an issue, so I've modified the default to be 
>>> the opencontainers variant. Similarly, the docker and opencontainers 
>>> runc are very similar. I've kept both variants of both recipes for 
>>> now, since I'd like to track things for a bit longer before 
>>> declaring the split unnecessary.
>>>
>>>
>>>
>>> Also for those that care, I created a reference docker-ce recipe 
>>> that tracks the docker-ce repo versus the components themselves.  
>>> Right now it is reference only, since it needs a bit more work, but 
>>> I wanted to get it out there, in case someone really cares about 
>>> docker-ce (I don't really, but someone might!).
>>>
>>>
>>>
>>> Summary: I just pushed the following changes to master:
>>>
>>>
>>>
>>>   d7d310ae4113 meta-virt: prefer containerd-opencontainers
>>>
>>>   935e3d969ef1 containerd: uprev to v1.0.2
>>>
>>>   f5fbfa8ac4db docker-ce: introduce reference recipe/build
>>>
>>>   a5074cecf18f docker: uprev to 18.03.0
>>>
>>>   e3d960f4fcd9 runc: uprev to 1.0.0-rc5
>>>
>>>
>>>
>>> If anyone sees regressions, build or architecture issues .. report 
>>> them to me (and the list) and we'll get them fixed up.
>>>
>>>
>>>
>>> Cheers,
>>>
>>>
>>>
>>> Bruce
>>>
>>>
>>>
>>> --
>>>
>>> "Thou shalt not follow the NULL pointer, for chaos and madness await 
>>> thee at its end"
>>>
>>> --
>>>
>>> _______________________________________________
>>>
>>> meta-virtualization mailing list
>>>
>>> meta-virtualization@yoctoproject.org
>>>
>>> https://lists.yoctoproject.org/listinfo/meta-virtualization
>>
>>
>>
>> --
>> "Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end"
>
>
>
> --
> "Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end"



--
"Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end"

Re: RFT/FYI: docker/containerd/runc uprevs pushed to master

[Bruce Ashfield]

On Thu, Apr 5, 2018 at 9:32 AM, Shakthi Pradeep (tpradeep)
<tpradeep@cisco.com> wrote:
> Hello Bruce,
>
> I am actually working on a repo from Third Party. So here things are little outdated.
>
> I found some info from http://git.yoctoproject.org
>
> I am currently using Docker 1.13.0 which was committed on 2017-01-20
>
> http://git.yoctoproject.org/cgit/cgit.cgi/meta-virtualization/commit/recipes-containers/docker?id=0b631bf01487d3d1be0c91ea7749168fb3c47dcb
>
> I need to migrate to 18.03.0 which you committed 3 days ago
>
> http://git.yoctoproject.org/cgit/cgit.cgi/meta-virtualization/commit/recipes-containers/docker?id=a5074cecf18faea1a325c8ac9220d2df41250af5
>
> If I take recipe from above commit and update my workspace, will all the dependencies migrate to latest automatically?

Nope. You'd need to pull in all the updates that I recently pushed for
the dependencies, or you'll end up with runtime errors.
Also note, that due to the different go versions and build
infrastructure in oe-core, there's no guarantee that those new recipes
will build properly on an older baseline.

Bruce

>
> Regards,
> Shakthi
>
> -----Original Message-----
> From: Bruce Ashfield [mailto:bruce.ashfield@gmail.com]
> Sent: Thursday, April 05, 2018 6:46 PM
> To: Shakthi Pradeep (tpradeep) <tpradeep@cisco.com>
> Cc: meta-virtualization@yoctoproject.org
> Subject: Re: [meta-virtualization] RFT/FYI: docker/containerd/runc uprevs pushed to master
>
> root@cube-server:~# docker --version
> Docker version 18.03.0, build 0f1bb353423e
>
> If you are building meta-virt master, the update should happen automatically since the PV of the updated recipe is higher than the old one. All the dependencies will follow after that.
>
> Bruce
>
> On Thu, Apr 5, 2018 at 9:02 AM, Shakthi Pradeep (tpradeep) <tpradeep@cisco.com> wrote:
>> Hello Bruce,
>>
>> Which version of Docker are you running.
>>
>> I just noticed I am running Docker 1.13.1 which is too old.
>>
>> How do I migrate to latest version of Docker & also corresponding dependencies.
>>
>> Regards,
>> Shakthi
>>
>> -----Original Message-----
>> From: Bruce Ashfield [mailto:bruce.ashfield@gmail.com]
>> Sent: Wednesday, April 04, 2018 6:45 PM
>> To: Shakthi Pradeep (tpradeep) <tpradeep@cisco.com>
>> Cc: meta-virtualization@yoctoproject.org
>> Subject: Re: [meta-virtualization] RFT/FYI: docker/containerd/runc
>> uprevs pushed to master
>>
>> Excellent news.
>>
>> Yes, everything is in master of meta-virtualization now. That way it will have time to soak a bit before the upcoming release.
>>
>> Cheers,
>>
>> Bruce
>>
>> On Wed, Apr 4, 2018 at 8:32 AM, Shakthi Pradeep (tpradeep) <tpradeep@cisco.com> wrote:
>>> Hello Bruce,
>>>
>>> Yes I was missing the bbappend for kernel config. Got it working after I wrote the mail to you.
>>>
>>> Are your changes committed to git repo? Is it in the master branch of Yocto?
>>>
>>> Regards,
>>> Shakthi
>>>
>>> -----Original Message-----
>>> From: Bruce Ashfield [mailto:bruce.ashfield@gmail.com]
>>> Sent: Wednesday, April 04, 2018 5:57 PM
>>> To: Shakthi Pradeep (tpradeep) <tpradeep@cisco.com>
>>> Cc: meta-virtualization@yoctoproject.org
>>> Subject: Re: [meta-virtualization] RFT/FYI: docker/containerd/runc
>>> uprevs pushed to master
>>>
>>> On Wed, Apr 4, 2018 at 12:57 AM, Shakthi Pradeep (tpradeep) <tpradeep@cisco.com> wrote:
>>>> Hello Bruce,
>>>>
>>>>
>>>>
>>>> Timing is Perfect !!!
>>>>
>>>>
>>>>
>>>> I am currently trying to get Docker CE to work with Yocto. I could
>>>> include the Docker executable in ISO but when I run it I get some errors.
>>>>
>>>>
>>>>
>>>> When I boot the image looks like Docker service start is failing due
>>>> to missing kernel modules. Please refer attached screenshot and
>>>> below error log.
>>>
>>> Do you have a bbappend for your 4.8 kernel that adds the docker configuration fragments ?
>>>
>>> That's the most likely reason for the issues.
>>>
>>> I was able to run a whole suite of tests against 4.12, 4.14 and 4.15 so those kernels + fragments are known to work.
>>>
>>> Bruce
>>>
>>>>
>>>>
>>>>
>>>> * docker.service - Docker Application Container Engine
>>>>
>>>>    Loaded: loaded (/lib/systemd/system/docker.service; enabled;
>>>> vendor
>>>> preset: enabled)
>>>>
>>>>    Active: failed (Result: exit-code) since Tue 2018-04-03 13:17:51
>>>> UTC; 17min ago
>>>>
>>>>      Docs: https://docs.docker.com
>>>>
>>>>   Process: 317 ExecStart=/usr/bin/dockerd -H fd:// (code=exited,
>>>> status=1/FAILURE)
>>>>
>>>> Main PID: 317 (code=exited, status=1/FAILURE)
>>>>
>>>>
>>>>
>>>> Apr 03 13:17:51 intel-x86-64 dockerd[317]:
>>>> time="2018-04-03T13:17:51.035178755Z" level=warning msg="Running
>>>> modprobe xt_conntrack failed with message: `modprobe: WARNING:
>>>> Module xt_conntrack not found in directory
>>>> /lib/modules/4.8.24-WR9.0.0.10_standard`, error: exit status 1"
>>>>
>>>> Apr 03 13:17:51 intel-x86-64 dockerd[317]:
>>>> time="2018-04-03T13:17:51.040727372Z" level=info msg="Firewalld running:
>>>> false"
>>>>
>>>> Apr 03 13:17:51 intel-x86-64 dockerd[317]:
>>>> time="2018-04-03T13:17:51.170575344Z" level=warning msg="Could not
>>>> load necessary modules for IPSEC rules: Running modprobe xfrm_user
>>>> failed with
>>>> message: `modprobe: WARNING: Module xfrm_user not found in directory
>>>> /lib/modules/4.8.24-WR9.0.0.10_standard`, error: exit status 1"
>>>>
>>>> Apr 03 13:17:51 intel-x86-64 dockerd[317]:
>>>> time="2018-04-03T13:17:51.172397913Z" level=info msg="Default bridge
>>>> (docker0) is assigned with an IP address 172.17.0.0/16. Daemon
>>>> option --bip can be used to set a preferred IP address"
>>>>
>>>> Apr 03 13:17:51 intel-x86-64 dockerd[317]: Error starting daemon:
>>>> Error initializing network controller: Error creating default "bridge" network:
>>>> Failed to Setup IP tables: Unable to enable ACCEPT INCOMING rule:
>>>> (iptables
>>>> failed: iptables --wait -I FORWARD -o docker0 -m conntrack --ctstate
>>>> RELATED,ESTABLISHED -j ACCEPT: iptables: No chain/target/match by that name.
>>>>
>>>> Apr 03 13:17:51 intel-x86-64 dockerd[317]:  (exit status 1))
>>>>
>>>> Apr 03 13:17:51 intel-x86-64 systemd[1]: docker.service: Main
>>>> process exited, code=exited, status=1/FAILURE
>>>>
>>>> Apr 03 13:17:51 intel-x86-64 systemd[1]: Failed to start Docker
>>>> Application Container Engine.
>>>>
>>>> Apr 03 13:17:51 intel-x86-64 systemd[1]: docker.service: Unit
>>>> entered failed state.
>>>>
>>>> Apr 03 13:17:51 intel-x86-64 systemd[1]: docker.service: Failed with
>>>> result 'exit-code'.
>>>>
>>>>
>>>>
>>>> Regards,
>>>>
>>>> Shakthi
>>>>
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: meta-virtualization-bounces@yoctoproject.org
>>>> [mailto:meta-virtualization-bounces@yoctoproject.org] On Behalf Of
>>>> Bruce Ashfield
>>>> Sent: Wednesday, April 04, 2018 8:44 AM
>>>> To: meta-virtualization@yoctoproject.org
>>>> Subject: [meta-virtualization] RFT/FYI: docker/containerd/runc
>>>> uprevs pushed to master
>>>>
>>>>
>>>>
>>>> Hi all,
>>>>
>>>>
>>>>
>>>> After spending a few days de-tangling the
>>>> moby/docker/runc/containerd and oe-core go infrastructure changes, I
>>>> was able to run docker/runc/containerd through a system/stress test and everything seems to be working.
>>>>
>>>>
>>>>
>>>> There were a few regressions that I worked through, as well as
>>>> build/packaging changes, but I'm no longer seeing any issues and all
>>>> the patches/functionality have been carried forward.
>>>>
>>>>
>>>>
>>>> One thing of note is that the docker and open containers containerd
>>>> split/fork is no longer an issue, so I've modified the default to be
>>>> the opencontainers variant. Similarly, the docker and opencontainers
>>>> runc are very similar. I've kept both variants of both recipes for
>>>> now, since I'd like to track things for a bit longer before
>>>> declaring the split unnecessary.
>>>>
>>>>
>>>>
>>>> Also for those that care, I created a reference docker-ce recipe
>>>> that tracks the docker-ce repo versus the components themselves.
>>>> Right now it is reference only, since it needs a bit more work, but
>>>> I wanted to get it out there, in case someone really cares about
>>>> docker-ce (I don't really, but someone might!).
>>>>
>>>>
>>>>
>>>> Summary: I just pushed the following changes to master:
>>>>
>>>>
>>>>
>>>>   d7d310ae4113 meta-virt: prefer containerd-opencontainers
>>>>
>>>>   935e3d969ef1 containerd: uprev to v1.0.2
>>>>
>>>>   f5fbfa8ac4db docker-ce: introduce reference recipe/build
>>>>
>>>>   a5074cecf18f docker: uprev to 18.03.0
>>>>
>>>>   e3d960f4fcd9 runc: uprev to 1.0.0-rc5
>>>>
>>>>
>>>>
>>>> If anyone sees regressions, build or architecture issues .. report
>>>> them to me (and the list) and we'll get them fixed up.
>>>>
>>>>
>>>>
>>>> Cheers,
>>>>
>>>>
>>>>
>>>> Bruce
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> "Thou shalt not follow the NULL pointer, for chaos and madness await
>>>> thee at its end"
>>>>
>>>> --
>>>>
>>>> _______________________________________________
>>>>
>>>> meta-virtualization mailing list
>>>>
>>>> meta-virtualization@yoctoproject.org
>>>>
>>>> https://lists.yoctoproject.org/listinfo/meta-virtualization
>>>
>>>
>>>
>>> --
>>> "Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end"
>>
>>
>>
>> --
>> "Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end"
>
>
>
> --
> "Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end"



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"

Re: RFT/FYI: docker/containerd/runc uprevs pushed to master

[Shakthi Pradeep (tpradeep)]

Hello Bruce,

I pulled master branch from git://git.yoctoproject.org/poky but build fails

When I run "bitbake core-image-full-cmdline" or "bitbake core-image-minimal" I get following error

ERROR: Task (/nobackup/tpradeep/playground/yocto/poky/meta/recipes-kernel/linux-libc-headers/linux-libc-headers_4.15.7.bb:do_install) failed with exit code '1'
ERROR: Task (/nobackup/tpradeep/playground/yocto/poky/meta/recipes-devtools/autoconf-archive/autoconf-archive_2016.09.16.bb:do_install) failed with exit code '1'

Any idea why?

Regards,
Shakthi

-----Original Message-----
From: Bruce Ashfield [mailto:bruce.ashfield@gmail.com] 
Sent: Thursday, April 05, 2018 7:44 PM
To: Shakthi Pradeep (tpradeep) <tpradeep@cisco.com>
Cc: meta-virtualization@yoctoproject.org
Subject: Re: [meta-virtualization] RFT/FYI: docker/containerd/runc uprevs pushed to master

On Thu, Apr 5, 2018 at 9:32 AM, Shakthi Pradeep (tpradeep) <tpradeep@cisco.com> wrote:
> Hello Bruce,
>
> I am actually working on a repo from Third Party. So here things are little outdated.
>
> I found some info from http://git.yoctoproject.org
>
> I am currently using Docker 1.13.0 which was committed on 2017-01-20
>
> http://git.yoctoproject.org/cgit/cgit.cgi/meta-virtualization/commit/r
> ecipes-containers/docker?id=0b631bf01487d3d1be0c91ea7749168fb3c47dcb
>
> I need to migrate to 18.03.0 which you committed 3 days ago
>
> http://git.yoctoproject.org/cgit/cgit.cgi/meta-virtualization/commit/r
> ecipes-containers/docker?id=a5074cecf18faea1a325c8ac9220d2df41250af5
>
> If I take recipe from above commit and update my workspace, will all the dependencies migrate to latest automatically?

Nope. You'd need to pull in all the updates that I recently pushed for the dependencies, or you'll end up with runtime errors.
Also note, that due to the different go versions and build infrastructure in oe-core, there's no guarantee that those new recipes will build properly on an older baseline.

Bruce

>
> Regards,
> Shakthi
>
> -----Original Message-----
> From: Bruce Ashfield [mailto:bruce.ashfield@gmail.com]
> Sent: Thursday, April 05, 2018 6:46 PM
> To: Shakthi Pradeep (tpradeep) <tpradeep@cisco.com>
> Cc: meta-virtualization@yoctoproject.org
> Subject: Re: [meta-virtualization] RFT/FYI: docker/containerd/runc 
> uprevs pushed to master
>
> root@cube-server:~# docker --version
> Docker version 18.03.0, build 0f1bb353423e
>
> If you are building meta-virt master, the update should happen automatically since the PV of the updated recipe is higher than the old one. All the dependencies will follow after that.
>
> Bruce
>
> On Thu, Apr 5, 2018 at 9:02 AM, Shakthi Pradeep (tpradeep) <tpradeep@cisco.com> wrote:
>> Hello Bruce,
>>
>> Which version of Docker are you running.
>>
>> I just noticed I am running Docker 1.13.1 which is too old.
>>
>> How do I migrate to latest version of Docker & also corresponding dependencies.
>>
>> Regards,
>> Shakthi
>>
>> -----Original Message-----
>> From: Bruce Ashfield [mailto:bruce.ashfield@gmail.com]
>> Sent: Wednesday, April 04, 2018 6:45 PM
>> To: Shakthi Pradeep (tpradeep) <tpradeep@cisco.com>
>> Cc: meta-virtualization@yoctoproject.org
>> Subject: Re: [meta-virtualization] RFT/FYI: docker/containerd/runc 
>> uprevs pushed to master
>>
>> Excellent news.
>>
>> Yes, everything is in master of meta-virtualization now. That way it will have time to soak a bit before the upcoming release.
>>
>> Cheers,
>>
>> Bruce
>>
>> On Wed, Apr 4, 2018 at 8:32 AM, Shakthi Pradeep (tpradeep) <tpradeep@cisco.com> wrote:
>>> Hello Bruce,
>>>
>>> Yes I was missing the bbappend for kernel config. Got it working after I wrote the mail to you.
>>>
>>> Are your changes committed to git repo? Is it in the master branch of Yocto?
>>>
>>> Regards,
>>> Shakthi
>>>
>>> -----Original Message-----
>>> From: Bruce Ashfield [mailto:bruce.ashfield@gmail.com]
>>> Sent: Wednesday, April 04, 2018 5:57 PM
>>> To: Shakthi Pradeep (tpradeep) <tpradeep@cisco.com>
>>> Cc: meta-virtualization@yoctoproject.org
>>> Subject: Re: [meta-virtualization] RFT/FYI: docker/containerd/runc 
>>> uprevs pushed to master
>>>
>>> On Wed, Apr 4, 2018 at 12:57 AM, Shakthi Pradeep (tpradeep) <tpradeep@cisco.com> wrote:
>>>> Hello Bruce,
>>>>
>>>>
>>>>
>>>> Timing is Perfect !!!
>>>>
>>>>
>>>>
>>>> I am currently trying to get Docker CE to work with Yocto. I could 
>>>> include the Docker executable in ISO but when I run it I get some errors.
>>>>
>>>>
>>>>
>>>> When I boot the image looks like Docker service start is failing 
>>>> due to missing kernel modules. Please refer attached screenshot and 
>>>> below error log.
>>>
>>> Do you have a bbappend for your 4.8 kernel that adds the docker configuration fragments ?
>>>
>>> That's the most likely reason for the issues.
>>>
>>> I was able to run a whole suite of tests against 4.12, 4.14 and 4.15 so those kernels + fragments are known to work.
>>>
>>> Bruce
>>>
>>>>
>>>>
>>>>
>>>> * docker.service - Docker Application Container Engine
>>>>
>>>>    Loaded: loaded (/lib/systemd/system/docker.service; enabled; 
>>>> vendor
>>>> preset: enabled)
>>>>
>>>>    Active: failed (Result: exit-code) since Tue 2018-04-03 13:17:51 
>>>> UTC; 17min ago
>>>>
>>>>      Docs: https://docs.docker.com
>>>>
>>>>   Process: 317 ExecStart=/usr/bin/dockerd -H fd:// (code=exited,
>>>> status=1/FAILURE)
>>>>
>>>> Main PID: 317 (code=exited, status=1/FAILURE)
>>>>
>>>>
>>>>
>>>> Apr 03 13:17:51 intel-x86-64 dockerd[317]:
>>>> time="2018-04-03T13:17:51.035178755Z" level=warning msg="Running 
>>>> modprobe xt_conntrack failed with message: `modprobe: WARNING:
>>>> Module xt_conntrack not found in directory 
>>>> /lib/modules/4.8.24-WR9.0.0.10_standard`, error: exit status 1"
>>>>
>>>> Apr 03 13:17:51 intel-x86-64 dockerd[317]:
>>>> time="2018-04-03T13:17:51.040727372Z" level=info msg="Firewalld running:
>>>> false"
>>>>
>>>> Apr 03 13:17:51 intel-x86-64 dockerd[317]:
>>>> time="2018-04-03T13:17:51.170575344Z" level=warning msg="Could not 
>>>> load necessary modules for IPSEC rules: Running modprobe xfrm_user 
>>>> failed with
>>>> message: `modprobe: WARNING: Module xfrm_user not found in 
>>>> directory /lib/modules/4.8.24-WR9.0.0.10_standard`, error: exit status 1"
>>>>
>>>> Apr 03 13:17:51 intel-x86-64 dockerd[317]:
>>>> time="2018-04-03T13:17:51.172397913Z" level=info msg="Default 
>>>> bridge
>>>> (docker0) is assigned with an IP address 172.17.0.0/16. Daemon 
>>>> option --bip can be used to set a preferred IP address"
>>>>
>>>> Apr 03 13:17:51 intel-x86-64 dockerd[317]: Error starting daemon:
>>>> Error initializing network controller: Error creating default "bridge" network:
>>>> Failed to Setup IP tables: Unable to enable ACCEPT INCOMING rule:
>>>> (iptables
>>>> failed: iptables --wait -I FORWARD -o docker0 -m conntrack 
>>>> --ctstate RELATED,ESTABLISHED -j ACCEPT: iptables: No chain/target/match by that name.
>>>>
>>>> Apr 03 13:17:51 intel-x86-64 dockerd[317]:  (exit status 1))
>>>>
>>>> Apr 03 13:17:51 intel-x86-64 systemd[1]: docker.service: Main 
>>>> process exited, code=exited, status=1/FAILURE
>>>>
>>>> Apr 03 13:17:51 intel-x86-64 systemd[1]: Failed to start Docker 
>>>> Application Container Engine.
>>>>
>>>> Apr 03 13:17:51 intel-x86-64 systemd[1]: docker.service: Unit 
>>>> entered failed state.
>>>>
>>>> Apr 03 13:17:51 intel-x86-64 systemd[1]: docker.service: Failed 
>>>> with result 'exit-code'.
>>>>
>>>>
>>>>
>>>> Regards,
>>>>
>>>> Shakthi
>>>>
>>>>
>>>>
>>>> -----Original Message-----
>>>> From: meta-virtualization-bounces@yoctoproject.org
>>>> [mailto:meta-virtualization-bounces@yoctoproject.org] On Behalf Of 
>>>> Bruce Ashfield
>>>> Sent: Wednesday, April 04, 2018 8:44 AM
>>>> To: meta-virtualization@yoctoproject.org
>>>> Subject: [meta-virtualization] RFT/FYI: docker/containerd/runc 
>>>> uprevs pushed to master
>>>>
>>>>
>>>>
>>>> Hi all,
>>>>
>>>>
>>>>
>>>> After spending a few days de-tangling the 
>>>> moby/docker/runc/containerd and oe-core go infrastructure changes, 
>>>> I was able to run docker/runc/containerd through a system/stress test and everything seems to be working.
>>>>
>>>>
>>>>
>>>> There were a few regressions that I worked through, as well as 
>>>> build/packaging changes, but I'm no longer seeing any issues and 
>>>> all the patches/functionality have been carried forward.
>>>>
>>>>
>>>>
>>>> One thing of note is that the docker and open containers containerd 
>>>> split/fork is no longer an issue, so I've modified the default to 
>>>> be the opencontainers variant. Similarly, the docker and 
>>>> opencontainers runc are very similar. I've kept both variants of 
>>>> both recipes for now, since I'd like to track things for a bit 
>>>> longer before declaring the split unnecessary.
>>>>
>>>>
>>>>
>>>> Also for those that care, I created a reference docker-ce recipe 
>>>> that tracks the docker-ce repo versus the components themselves.
>>>> Right now it is reference only, since it needs a bit more work, but 
>>>> I wanted to get it out there, in case someone really cares about 
>>>> docker-ce (I don't really, but someone might!).
>>>>
>>>>
>>>>
>>>> Summary: I just pushed the following changes to master:
>>>>
>>>>
>>>>
>>>>   d7d310ae4113 meta-virt: prefer containerd-opencontainers
>>>>
>>>>   935e3d969ef1 containerd: uprev to v1.0.2
>>>>
>>>>   f5fbfa8ac4db docker-ce: introduce reference recipe/build
>>>>
>>>>   a5074cecf18f docker: uprev to 18.03.0
>>>>
>>>>   e3d960f4fcd9 runc: uprev to 1.0.0-rc5
>>>>
>>>>
>>>>
>>>> If anyone sees regressions, build or architecture issues .. report 
>>>> them to me (and the list) and we'll get them fixed up.
>>>>
>>>>
>>>>
>>>> Cheers,
>>>>
>>>>
>>>>
>>>> Bruce
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> "Thou shalt not follow the NULL pointer, for chaos and madness 
>>>> await thee at its end"
>>>>
>>>> --
>>>>
>>>> _______________________________________________
>>>>
>>>> meta-virtualization mailing list
>>>>
>>>> meta-virtualization@yoctoproject.org
>>>>
>>>> https://lists.yoctoproject.org/listinfo/meta-virtualization
>>>
>>>
>>>
>>> --
>>> "Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end"
>>
>>
>>
>> --
>> "Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end"
>
>
>
> --
> "Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end"



--
"Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end"

Re: RFT/FYI: docker/containerd/runc uprevs pushed to master

[Bruce Ashfield]

On Thu, Apr 5, 2018 at 11:55 AM, Shakthi Pradeep (tpradeep)
<tpradeep@cisco.com> wrote:
> Hello Bruce,
>
> I pulled master branch from git://git.yoctoproject.org/poky but build fails
>
> When I run "bitbake core-image-full-cmdline" or "bitbake core-image-minimal" I get following error
>
> ERROR: Task (/nobackup/tpradeep/playground/yocto/poky/meta/recipes-kernel/linux-libc-headers/linux-libc-headers_4.15.7.bb:do_install) failed with exit code '1'
> ERROR: Task (/nobackup/tpradeep/playground/yocto/poky/meta/recipes-devtools/autoconf-archive/autoconf-archive_2016.09.16.bb:do_install) failed with exit code '1'
>
> Any idea why?

Nope. But the errors are unrelated to the changes in meta-virt. If the
issue persists, asking on the oe-core list is a better bet.
I'd suggest that you rm -rf tmp, and start the build again.

Bruce

>
> Regards,
> Shakthi
>
> -----Original Message-----
> From: Bruce Ashfield [mailto:bruce.ashfield@gmail.com]
> Sent: Thursday, April 05, 2018 7:44 PM
> To: Shakthi Pradeep (tpradeep) <tpradeep@cisco.com>
> Cc: meta-virtualization@yoctoproject.org
> Subject: Re: [meta-virtualization] RFT/FYI: docker/containerd/runc uprevs pushed to master
>
> On Thu, Apr 5, 2018 at 9:32 AM, Shakthi Pradeep (tpradeep) <tpradeep@cisco.com> wrote:
>> Hello Bruce,
>>
>> I am actually working on a repo from Third Party. So here things are little outdated.
>>
>> I found some info from http://git.yoctoproject.org
>>
>> I am currently using Docker 1.13.0 which was committed on 2017-01-20
>>
>> http://git.yoctoproject.org/cgit/cgit.cgi/meta-virtualization/commit/r
>> ecipes-containers/docker?id=0b631bf01487d3d1be0c91ea7749168fb3c47dcb
>>
>> I need to migrate to 18.03.0 which you committed 3 days ago
>>
>> http://git.yoctoproject.org/cgit/cgit.cgi/meta-virtualization/commit/r
>> ecipes-containers/docker?id=a5074cecf18faea1a325c8ac9220d2df41250af5
>>
>> If I take recipe from above commit and update my workspace, will all the dependencies migrate to latest automatically?
>
> Nope. You'd need to pull in all the updates that I recently pushed for the dependencies, or you'll end up with runtime errors.
> Also note, that due to the different go versions and build infrastructure in oe-core, there's no guarantee that those new recipes will build properly on an older baseline.
>
> Bruce
>
>>
>> Regards,
>> Shakthi
>>
>> -----Original Message-----
>> From: Bruce Ashfield [mailto:bruce.ashfield@gmail.com]
>> Sent: Thursday, April 05, 2018 6:46 PM
>> To: Shakthi Pradeep (tpradeep) <tpradeep@cisco.com>
>> Cc: meta-virtualization@yoctoproject.org
>> Subject: Re: [meta-virtualization] RFT/FYI: docker/containerd/runc
>> uprevs pushed to master
>>
>> root@cube-server:~# docker --version
>> Docker version 18.03.0, build 0f1bb353423e
>>
>> If you are building meta-virt master, the update should happen automatically since the PV of the updated recipe is higher than the old one. All the dependencies will follow after that.
>>
>> Bruce
>>
>> On Thu, Apr 5, 2018 at 9:02 AM, Shakthi Pradeep (tpradeep) <tpradeep@cisco.com> wrote:
>>> Hello Bruce,
>>>
>>> Which version of Docker are you running.
>>>
>>> I just noticed I am running Docker 1.13.1 which is too old.
>>>
>>> How do I migrate to latest version of Docker & also corresponding dependencies.
>>>
>>> Regards,
>>> Shakthi
>>>
>>> -----Original Message-----
>>> From: Bruce Ashfield [mailto:bruce.ashfield@gmail.com]
>>> Sent: Wednesday, April 04, 2018 6:45 PM
>>> To: Shakthi Pradeep (tpradeep) <tpradeep@cisco.com>
>>> Cc: meta-virtualization@yoctoproject.org
>>> Subject: Re: [meta-virtualization] RFT/FYI: docker/containerd/runc
>>> uprevs pushed to master
>>>
>>> Excellent news.
>>>
>>> Yes, everything is in master of meta-virtualization now. That way it will have time to soak a bit before the upcoming release.
>>>
>>> Cheers,
>>>
>>> Bruce
>>>
>>> On Wed, Apr 4, 2018 at 8:32 AM, Shakthi Pradeep (tpradeep) <tpradeep@cisco.com> wrote:
>>>> Hello Bruce,
>>>>
>>>> Yes I was missing the bbappend for kernel config. Got it working after I wrote the mail to you.
>>>>
>>>> Are your changes committed to git repo? Is it in the master branch of Yocto?
>>>>
>>>> Regards,
>>>> Shakthi
>>>>
>>>> -----Original Message-----
>>>> From: Bruce Ashfield [mailto:bruce.ashfield@gmail.com]
>>>> Sent: Wednesday, April 04, 2018 5:57 PM
>>>> To: Shakthi Pradeep (tpradeep) <tpradeep@cisco.com>
>>>> Cc: meta-virtualization@yoctoproject.org
>>>> Subject: Re: [meta-virtualization] RFT/FYI: docker/containerd/runc
>>>> uprevs pushed to master
>>>>
>>>> On Wed, Apr 4, 2018 at 12:57 AM, Shakthi Pradeep (tpradeep) <tpradeep@cisco.com> wrote:
>>>>> Hello Bruce,
>>>>>
>>>>>
>>>>>
>>>>> Timing is Perfect !!!
>>>>>
>>>>>
>>>>>
>>>>> I am currently trying to get Docker CE to work with Yocto. I could
>>>>> include the Docker executable in ISO but when I run it I get some errors.
>>>>>
>>>>>
>>>>>
>>>>> When I boot the image looks like Docker service start is failing
>>>>> due to missing kernel modules. Please refer attached screenshot and
>>>>> below error log.
>>>>
>>>> Do you have a bbappend for your 4.8 kernel that adds the docker configuration fragments ?
>>>>
>>>> That's the most likely reason for the issues.
>>>>
>>>> I was able to run a whole suite of tests against 4.12, 4.14 and 4.15 so those kernels + fragments are known to work.
>>>>
>>>> Bruce
>>>>
>>>>>
>>>>>
>>>>>
>>>>> * docker.service - Docker Application Container Engine
>>>>>
>>>>>    Loaded: loaded (/lib/systemd/system/docker.service; enabled;
>>>>> vendor
>>>>> preset: enabled)
>>>>>
>>>>>    Active: failed (Result: exit-code) since Tue 2018-04-03 13:17:51
>>>>> UTC; 17min ago
>>>>>
>>>>>      Docs: https://docs.docker.com
>>>>>
>>>>>   Process: 317 ExecStart=/usr/bin/dockerd -H fd:// (code=exited,
>>>>> status=1/FAILURE)
>>>>>
>>>>> Main PID: 317 (code=exited, status=1/FAILURE)
>>>>>
>>>>>
>>>>>
>>>>> Apr 03 13:17:51 intel-x86-64 dockerd[317]:
>>>>> time="2018-04-03T13:17:51.035178755Z" level=warning msg="Running
>>>>> modprobe xt_conntrack failed with message: `modprobe: WARNING:
>>>>> Module xt_conntrack not found in directory
>>>>> /lib/modules/4.8.24-WR9.0.0.10_standard`, error: exit status 1"
>>>>>
>>>>> Apr 03 13:17:51 intel-x86-64 dockerd[317]:
>>>>> time="2018-04-03T13:17:51.040727372Z" level=info msg="Firewalld running:
>>>>> false"
>>>>>
>>>>> Apr 03 13:17:51 intel-x86-64 dockerd[317]:
>>>>> time="2018-04-03T13:17:51.170575344Z" level=warning msg="Could not
>>>>> load necessary modules for IPSEC rules: Running modprobe xfrm_user
>>>>> failed with
>>>>> message: `modprobe: WARNING: Module xfrm_user not found in
>>>>> directory /lib/modules/4.8.24-WR9.0.0.10_standard`, error: exit status 1"
>>>>>
>>>>> Apr 03 13:17:51 intel-x86-64 dockerd[317]:
>>>>> time="2018-04-03T13:17:51.172397913Z" level=info msg="Default
>>>>> bridge
>>>>> (docker0) is assigned with an IP address 172.17.0.0/16. Daemon
>>>>> option --bip can be used to set a preferred IP address"
>>>>>
>>>>> Apr 03 13:17:51 intel-x86-64 dockerd[317]: Error starting daemon:
>>>>> Error initializing network controller: Error creating default "bridge" network:
>>>>> Failed to Setup IP tables: Unable to enable ACCEPT INCOMING rule:
>>>>> (iptables
>>>>> failed: iptables --wait -I FORWARD -o docker0 -m conntrack
>>>>> --ctstate RELATED,ESTABLISHED -j ACCEPT: iptables: No chain/target/match by that name.
>>>>>
>>>>> Apr 03 13:17:51 intel-x86-64 dockerd[317]:  (exit status 1))
>>>>>
>>>>> Apr 03 13:17:51 intel-x86-64 systemd[1]: docker.service: Main
>>>>> process exited, code=exited, status=1/FAILURE
>>>>>
>>>>> Apr 03 13:17:51 intel-x86-64 systemd[1]: Failed to start Docker
>>>>> Application Container Engine.
>>>>>
>>>>> Apr 03 13:17:51 intel-x86-64 systemd[1]: docker.service: Unit
>>>>> entered failed state.
>>>>>
>>>>> Apr 03 13:17:51 intel-x86-64 systemd[1]: docker.service: Failed
>>>>> with result 'exit-code'.
>>>>>
>>>>>
>>>>>
>>>>> Regards,
>>>>>
>>>>> Shakthi
>>>>>
>>>>>
>>>>>
>>>>> -----Original Message-----
>>>>> From: meta-virtualization-bounces@yoctoproject.org
>>>>> [mailto:meta-virtualization-bounces@yoctoproject.org] On Behalf Of
>>>>> Bruce Ashfield
>>>>> Sent: Wednesday, April 04, 2018 8:44 AM
>>>>> To: meta-virtualization@yoctoproject.org
>>>>> Subject: [meta-virtualization] RFT/FYI: docker/containerd/runc
>>>>> uprevs pushed to master
>>>>>
>>>>>
>>>>>
>>>>> Hi all,
>>>>>
>>>>>
>>>>>
>>>>> After spending a few days de-tangling the
>>>>> moby/docker/runc/containerd and oe-core go infrastructure changes,
>>>>> I was able to run docker/runc/containerd through a system/stress test and everything seems to be working.
>>>>>
>>>>>
>>>>>
>>>>> There were a few regressions that I worked through, as well as
>>>>> build/packaging changes, but I'm no longer seeing any issues and
>>>>> all the patches/functionality have been carried forward.
>>>>>
>>>>>
>>>>>
>>>>> One thing of note is that the docker and open containers containerd
>>>>> split/fork is no longer an issue, so I've modified the default to
>>>>> be the opencontainers variant. Similarly, the docker and
>>>>> opencontainers runc are very similar. I've kept both variants of
>>>>> both recipes for now, since I'd like to track things for a bit
>>>>> longer before declaring the split unnecessary.
>>>>>
>>>>>
>>>>>
>>>>> Also for those that care, I created a reference docker-ce recipe
>>>>> that tracks the docker-ce repo versus the components themselves.
>>>>> Right now it is reference only, since it needs a bit more work, but
>>>>> I wanted to get it out there, in case someone really cares about
>>>>> docker-ce (I don't really, but someone might!).
>>>>>
>>>>>
>>>>>
>>>>> Summary: I just pushed the following changes to master:
>>>>>
>>>>>
>>>>>
>>>>>   d7d310ae4113 meta-virt: prefer containerd-opencontainers
>>>>>
>>>>>   935e3d969ef1 containerd: uprev to v1.0.2
>>>>>
>>>>>   f5fbfa8ac4db docker-ce: introduce reference recipe/build
>>>>>
>>>>>   a5074cecf18f docker: uprev to 18.03.0
>>>>>
>>>>>   e3d960f4fcd9 runc: uprev to 1.0.0-rc5
>>>>>
>>>>>
>>>>>
>>>>> If anyone sees regressions, build or architecture issues .. report
>>>>> them to me (and the list) and we'll get them fixed up.
>>>>>
>>>>>
>>>>>
>>>>> Cheers,
>>>>>
>>>>>
>>>>>
>>>>> Bruce
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>> "Thou shalt not follow the NULL pointer, for chaos and madness
>>>>> await thee at its end"
>>>>>
>>>>> --
>>>>>
>>>>> _______________________________________________
>>>>>
>>>>> meta-virtualization mailing list
>>>>>
>>>>> meta-virtualization@yoctoproject.org
>>>>>
>>>>> https://lists.yoctoproject.org/listinfo/meta-virtualization
>>>>
>>>>
>>>>
>>>> --
>>>> "Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end"
>>>
>>>
>>>
>>> --
>>> "Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end"
>>
>>
>>
>> --
>> "Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end"
>
>
>
> --
> "Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end"



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"

Re: RFT/FYI: docker/containerd/runc uprevs pushed to master

[Shakthi Pradeep (tpradeep)]

Hello Bruce,

Moved to master branch of Yocto. When I build I am getting below error. What does this mean?

Initialising tasks: 100% |######################################################################################################################################################| Time: 0:00:04
NOTE: Executing SetScene Tasks
NOTE: Executing RunQueue Tasks
WARNING: core-image-full-cmdline-1.0-r0 do_rootfs: Intentionally failing postinstall scriptlets of ['docker'] to defer them to first boot is deprecated. Please place them into pkg_postinst_ontarget_${PN} ().
If deferring to first boot wasn't the intent, then scriptlet failure may mean an issue in the recipe, or a regression elsewhere.
Details of the failure are in /workdir/poky/build/tmp/work/genericx86_64-poky-linux/core-image-full-cmdline/1.0-r0/temp/log.do_rootfs.
WARNING: core-image-full-cmdline-1.0-r0 do_rootfs: [log_check] core-image-full-cmdline: found 2 warning messages in the logfile:
[log_check] warning: %post(docker-18.03.0+git708b068d3095c6a6be939eb2da78c921d2e945e2-r0.core2_64) scriptlet failed, exit status 1
[log_check] WARNING: Intentionally failing postinstall scriptlets of ['docker'] to defer them to first boot is deprecated. Please place them into pkg_postinst_ontarget_${PN} ().

Regards,
Shakthi

On 06/04/18, 1:09 AM, "Bruce Ashfield" <bruce.ashfield@gmail.com> wrote:

    On Thu, Apr 5, 2018 at 11:55 AM, Shakthi Pradeep (tpradeep)
    <tpradeep@cisco.com> wrote:
    > Hello Bruce,
    >
    > I pulled master branch from git://git.yoctoproject.org/poky but build fails
    >
    > When I run "bitbake core-image-full-cmdline" or "bitbake core-image-minimal" I get following error
    >
    > ERROR: Task (/nobackup/tpradeep/playground/yocto/poky/meta/recipes-kernel/linux-libc-headers/linux-libc-headers_4.15.7.bb:do_install) failed with exit code '1'
    > ERROR: Task (/nobackup/tpradeep/playground/yocto/poky/meta/recipes-devtools/autoconf-archive/autoconf-archive_2016.09.16.bb:do_install) failed with exit code '1'
    >
    > Any idea why?
    
    Nope. But the errors are unrelated to the changes in meta-virt. If the
    issue persists, asking on the oe-core list is a better bet.
    I'd suggest that you rm -rf tmp, and start the build again.
    
    Bruce
    
    >
    > Regards,
    > Shakthi
    >
    > -----Original Message-----
    > From: Bruce Ashfield [mailto:bruce.ashfield@gmail.com]
    > Sent: Thursday, April 05, 2018 7:44 PM
    > To: Shakthi Pradeep (tpradeep) <tpradeep@cisco.com>
    > Cc: meta-virtualization@yoctoproject.org
    > Subject: Re: [meta-virtualization] RFT/FYI: docker/containerd/runc uprevs pushed to master
    >
    > On Thu, Apr 5, 2018 at 9:32 AM, Shakthi Pradeep (tpradeep) <tpradeep@cisco.com> wrote:
    >> Hello Bruce,
    >>
    >> I am actually working on a repo from Third Party. So here things are little outdated.
    >>
    >> I found some info from http://git.yoctoproject.org
    >>
    >> I am currently using Docker 1.13.0 which was committed on 2017-01-20
    >>
    >> http://git.yoctoproject.org/cgit/cgit.cgi/meta-virtualization/commit/r
    >> ecipes-containers/docker?id=0b631bf01487d3d1be0c91ea7749168fb3c47dcb
    >>
    >> I need to migrate to 18.03.0 which you committed 3 days ago
    >>
    >> http://git.yoctoproject.org/cgit/cgit.cgi/meta-virtualization/commit/r
    >> ecipes-containers/docker?id=a5074cecf18faea1a325c8ac9220d2df41250af5
    >>
    >> If I take recipe from above commit and update my workspace, will all the dependencies migrate to latest automatically?
    >
    > Nope. You'd need to pull in all the updates that I recently pushed for the dependencies, or you'll end up with runtime errors.
    > Also note, that due to the different go versions and build infrastructure in oe-core, there's no guarantee that those new recipes will build properly on an older baseline.
    >
    > Bruce
    >
    >>
    >> Regards,
    >> Shakthi
    >>
    >> -----Original Message-----
    >> From: Bruce Ashfield [mailto:bruce.ashfield@gmail.com]
    >> Sent: Thursday, April 05, 2018 6:46 PM
    >> To: Shakthi Pradeep (tpradeep) <tpradeep@cisco.com>
    >> Cc: meta-virtualization@yoctoproject.org
    >> Subject: Re: [meta-virtualization] RFT/FYI: docker/containerd/runc
    >> uprevs pushed to master
    >>
    >> root@cube-server:~# docker --version
    >> Docker version 18.03.0, build 0f1bb353423e
    >>
    >> If you are building meta-virt master, the update should happen automatically since the PV of the updated recipe is higher than the old one. All the dependencies will follow after that.
    >>
    >> Bruce
    >>
    >> On Thu, Apr 5, 2018 at 9:02 AM, Shakthi Pradeep (tpradeep) <tpradeep@cisco.com> wrote:
    >>> Hello Bruce,
    >>>
    >>> Which version of Docker are you running.
    >>>
    >>> I just noticed I am running Docker 1.13.1 which is too old.
    >>>
    >>> How do I migrate to latest version of Docker & also corresponding dependencies.
    >>>
    >>> Regards,
    >>> Shakthi
    >>>
    >>> -----Original Message-----
    >>> From: Bruce Ashfield [mailto:bruce.ashfield@gmail.com]
    >>> Sent: Wednesday, April 04, 2018 6:45 PM
    >>> To: Shakthi Pradeep (tpradeep) <tpradeep@cisco.com>
    >>> Cc: meta-virtualization@yoctoproject.org
    >>> Subject: Re: [meta-virtualization] RFT/FYI: docker/containerd/runc
    >>> uprevs pushed to master
    >>>
    >>> Excellent news.
    >>>
    >>> Yes, everything is in master of meta-virtualization now. That way it will have time to soak a bit before the upcoming release.
    >>>
    >>> Cheers,
    >>>
    >>> Bruce
    >>>
    >>> On Wed, Apr 4, 2018 at 8:32 AM, Shakthi Pradeep (tpradeep) <tpradeep@cisco.com> wrote:
    >>>> Hello Bruce,
    >>>>
    >>>> Yes I was missing the bbappend for kernel config. Got it working after I wrote the mail to you.
    >>>>
    >>>> Are your changes committed to git repo? Is it in the master branch of Yocto?
    >>>>
    >>>> Regards,
    >>>> Shakthi
    >>>>
    >>>> -----Original Message-----
    >>>> From: Bruce Ashfield [mailto:bruce.ashfield@gmail.com]
    >>>> Sent: Wednesday, April 04, 2018 5:57 PM
    >>>> To: Shakthi Pradeep (tpradeep) <tpradeep@cisco.com>
    >>>> Cc: meta-virtualization@yoctoproject.org
    >>>> Subject: Re: [meta-virtualization] RFT/FYI: docker/containerd/runc
    >>>> uprevs pushed to master
    >>>>
    >>>> On Wed, Apr 4, 2018 at 12:57 AM, Shakthi Pradeep (tpradeep) <tpradeep@cisco.com> wrote:
    >>>>> Hello Bruce,
    >>>>>
    >>>>>
    >>>>>
    >>>>> Timing is Perfect !!!
    >>>>>
    >>>>>
    >>>>>
    >>>>> I am currently trying to get Docker CE to work with Yocto. I could
    >>>>> include the Docker executable in ISO but when I run it I get some errors.
    >>>>>
    >>>>>
    >>>>>
    >>>>> When I boot the image looks like Docker service start is failing
    >>>>> due to missing kernel modules. Please refer attached screenshot and
    >>>>> below error log.
    >>>>
    >>>> Do you have a bbappend for your 4.8 kernel that adds the docker configuration fragments ?
    >>>>
    >>>> That's the most likely reason for the issues.
    >>>>
    >>>> I was able to run a whole suite of tests against 4.12, 4.14 and 4.15 so those kernels + fragments are known to work.
    >>>>
    >>>> Bruce
    >>>>
    >>>>>
    >>>>>
    >>>>>
    >>>>> * docker.service - Docker Application Container Engine
    >>>>>
    >>>>>    Loaded: loaded (/lib/systemd/system/docker.service; enabled;
    >>>>> vendor
    >>>>> preset: enabled)
    >>>>>
    >>>>>    Active: failed (Result: exit-code) since Tue 2018-04-03 13:17:51
    >>>>> UTC; 17min ago
    >>>>>
    >>>>>      Docs: https://docs.docker.com
    >>>>>
    >>>>>   Process: 317 ExecStart=/usr/bin/dockerd -H fd:// (code=exited,
    >>>>> status=1/FAILURE)
    >>>>>
    >>>>> Main PID: 317 (code=exited, status=1/FAILURE)
    >>>>>
    >>>>>
    >>>>>
    >>>>> Apr 03 13:17:51 intel-x86-64 dockerd[317]:
    >>>>> time="2018-04-03T13:17:51.035178755Z" level=warning msg="Running
    >>>>> modprobe xt_conntrack failed with message: `modprobe: WARNING:
    >>>>> Module xt_conntrack not found in directory
    >>>>> /lib/modules/4.8.24-WR9.0.0.10_standard`, error: exit status 1"
    >>>>>
    >>>>> Apr 03 13:17:51 intel-x86-64 dockerd[317]:
    >>>>> time="2018-04-03T13:17:51.040727372Z" level=info msg="Firewalld running:
    >>>>> false"
    >>>>>
    >>>>> Apr 03 13:17:51 intel-x86-64 dockerd[317]:
    >>>>> time="2018-04-03T13:17:51.170575344Z" level=warning msg="Could not
    >>>>> load necessary modules for IPSEC rules: Running modprobe xfrm_user
    >>>>> failed with
    >>>>> message: `modprobe: WARNING: Module xfrm_user not found in
    >>>>> directory /lib/modules/4.8.24-WR9.0.0.10_standard`, error: exit status 1"
    >>>>>
    >>>>> Apr 03 13:17:51 intel-x86-64 dockerd[317]:
    >>>>> time="2018-04-03T13:17:51.172397913Z" level=info msg="Default
    >>>>> bridge
    >>>>> (docker0) is assigned with an IP address 172.17.0.0/16. Daemon
    >>>>> option --bip can be used to set a preferred IP address"
    >>>>>
    >>>>> Apr 03 13:17:51 intel-x86-64 dockerd[317]: Error starting daemon:
    >>>>> Error initializing network controller: Error creating default "bridge" network:
    >>>>> Failed to Setup IP tables: Unable to enable ACCEPT INCOMING rule:
    >>>>> (iptables
    >>>>> failed: iptables --wait -I FORWARD -o docker0 -m conntrack
    >>>>> --ctstate RELATED,ESTABLISHED -j ACCEPT: iptables: No chain/target/match by that name.
    >>>>>
    >>>>> Apr 03 13:17:51 intel-x86-64 dockerd[317]:  (exit status 1))
    >>>>>
    >>>>> Apr 03 13:17:51 intel-x86-64 systemd[1]: docker.service: Main
    >>>>> process exited, code=exited, status=1/FAILURE
    >>>>>
    >>>>> Apr 03 13:17:51 intel-x86-64 systemd[1]: Failed to start Docker
    >>>>> Application Container Engine.
    >>>>>
    >>>>> Apr 03 13:17:51 intel-x86-64 systemd[1]: docker.service: Unit
    >>>>> entered failed state.
    >>>>>
    >>>>> Apr 03 13:17:51 intel-x86-64 systemd[1]: docker.service: Failed
    >>>>> with result 'exit-code'.
    >>>>>
    >>>>>
    >>>>>
    >>>>> Regards,
    >>>>>
    >>>>> Shakthi
    >>>>>
    >>>>>
    >>>>>
    >>>>> -----Original Message-----
    >>>>> From: meta-virtualization-bounces@yoctoproject.org
    >>>>> [mailto:meta-virtualization-bounces@yoctoproject.org] On Behalf Of
    >>>>> Bruce Ashfield
    >>>>> Sent: Wednesday, April 04, 2018 8:44 AM
    >>>>> To: meta-virtualization@yoctoproject.org
    >>>>> Subject: [meta-virtualization] RFT/FYI: docker/containerd/runc
    >>>>> uprevs pushed to master
    >>>>>
    >>>>>
    >>>>>
    >>>>> Hi all,
    >>>>>
    >>>>>
    >>>>>
    >>>>> After spending a few days de-tangling the
    >>>>> moby/docker/runc/containerd and oe-core go infrastructure changes,
    >>>>> I was able to run docker/runc/containerd through a system/stress test and everything seems to be working.
    >>>>>
    >>>>>
    >>>>>
    >>>>> There were a few regressions that I worked through, as well as
    >>>>> build/packaging changes, but I'm no longer seeing any issues and
    >>>>> all the patches/functionality have been carried forward.
    >>>>>
    >>>>>
    >>>>>
    >>>>> One thing of note is that the docker and open containers containerd
    >>>>> split/fork is no longer an issue, so I've modified the default to
    >>>>> be the opencontainers variant. Similarly, the docker and
    >>>>> opencontainers runc are very similar. I've kept both variants of
    >>>>> both recipes for now, since I'd like to track things for a bit
    >>>>> longer before declaring the split unnecessary.
    >>>>>
    >>>>>
    >>>>>
    >>>>> Also for those that care, I created a reference docker-ce recipe
    >>>>> that tracks the docker-ce repo versus the components themselves.
    >>>>> Right now it is reference only, since it needs a bit more work, but
    >>>>> I wanted to get it out there, in case someone really cares about
    >>>>> docker-ce (I don't really, but someone might!).
    >>>>>
    >>>>>
    >>>>>
    >>>>> Summary: I just pushed the following changes to master:
    >>>>>
    >>>>>
    >>>>>
    >>>>>   d7d310ae4113 meta-virt: prefer containerd-opencontainers
    >>>>>
    >>>>>   935e3d969ef1 containerd: uprev to v1.0.2
    >>>>>
    >>>>>   f5fbfa8ac4db docker-ce: introduce reference recipe/build
    >>>>>
    >>>>>   a5074cecf18f docker: uprev to 18.03.0
    >>>>>
    >>>>>   e3d960f4fcd9 runc: uprev to 1.0.0-rc5
    >>>>>
    >>>>>
    >>>>>
    >>>>> If anyone sees regressions, build or architecture issues .. report
    >>>>> them to me (and the list) and we'll get them fixed up.
    >>>>>
    >>>>>
    >>>>>
    >>>>> Cheers,
    >>>>>
    >>>>>
    >>>>>
    >>>>> Bruce
    >>>>>
    >>>>>
    >>>>>
    >>>>> --
    >>>>>
    >>>>> "Thou shalt not follow the NULL pointer, for chaos and madness
    >>>>> await thee at its end"
    >>>>>
    >>>>> --
    >>>>>
    >>>>> _______________________________________________
    >>>>>
    >>>>> meta-virtualization mailing list
    >>>>>
    >>>>> meta-virtualization@yoctoproject.org
    >>>>>
    >>>>> https://lists.yoctoproject.org/listinfo/meta-virtualization
    >>>>
    >>>>
    >>>>
    >>>> --
    >>>> "Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end"
    >>>
    >>>
    >>>
    >>> --
    >>> "Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end"
    >>
    >>
    >>
    >> --
    >> "Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end"
    >
    >
    >
    > --
    > "Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end"
    
    
    
    -- 
    "Thou shalt not follow the NULL pointer, for chaos and madness await
    thee at its end"
    

Re: RFT/FYI: docker/containerd/runc uprevs pushed to master

[Bruce Ashfield]

On Mon, Apr 9, 2018 at 4:37 AM, Shakthi Pradeep (tpradeep)
<tpradeep@cisco.com> wrote:
> Hello Bruce,
>
> Moved to master branch of Yocto. When I build I am getting below error. What does this mean?

There were changes made to the way that postinstall scripts were run
in the January
timeframe,

i.e.:

 commit 7bc55b29609765904af9f330600229e96cc044cf
Author: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Date:   Mon Jan 29 14:01:32 2018 +0200

    meta/lib/oe/package_manager.py: deprecate 'exit 1' as a way to
defer to first boot

    'exit 1' is not optimal for two reasons:

    1) Code is hard to read; it is not obvious that it means 'defer
what follows to first boot'.
    2) Worse, this hides actual errors in the scriptlets; there is no
difference between scriptlet
    failing because it's intended to be run on target and scriptlet
failing because there's a bug or
    a regression somewhere.

    The new, supported way is to place the code that has to run on
target into pkg_postinst_ontarget(),
    or, if a more fine-tuned control is required, call
'postinst-intercepts defer_to_first_boot' from
    pkg_postinst() to explicitly request deferral to first boot.

    (From OE-Core rev: d12cf56e9ff2a4f13dfbef9290ea5647b52b3f6d)

    Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
    Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

:100644 100644 2a07f0e39ad6... f7e013437c91... M
meta/lib/oe/package_manager.py

commit 6ca669105ff7f405e85142d1aa5375a8430c9606
Author: Alexander Kanavin <alexander.kanavin@linux.intel.com>
Date:   Mon Jan 29 14:01:31 2018 +0200

    package.bbclass: add support for pkg_postinst_ontarget()

    This function is a convenient and more readable shortcut for situations
    when the postinst code always needs to run on target. All commands that
    cannot be executed during cross-install and can only be run on target
    should go into this function. They will only be executed on first boot
    (if package was cross-installed) or immediately during package installation
    on target.

    Plain pkg_postinst() works as before: it is run during cross-install time,
    it can contain a request to defer to first boot, and it is also run
    during package installation on target.

    Also fix the oeqa test for this functionality to use the new function
    where appropriate.

    (From OE-Core rev: 229f4e975fb6957f44b5c56735fd6d58564098d7)

    Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
    Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>

:100644 100644 112aa08c80f8... d4bab6dcc228... M
meta-selftest/recipes-test/postinst/postinst_1.0.bb
:100644 100644 7dc759699f4b... 6a7f35a3e787... M
meta/classes/package.bbclass

-------

But you shouldn't be getting that warning with docker, since it doesn't
have a pkg_postinst_${PN}(), or related element in the recipe.

So something in your build is adding that postinstall action, that isn't
part of the meta-virtualization layer.

Bruce


>
> Initialising tasks: 100% |######################################################################################################################################################| Time: 0:00:04
> NOTE: Executing SetScene Tasks
> NOTE: Executing RunQueue Tasks
> WARNING: core-image-full-cmdline-1.0-r0 do_rootfs: Intentionally failing postinstall scriptlets of ['docker'] to defer them to first boot is deprecated. Please place them into pkg_postinst_ontarget_${PN} ().
> If deferring to first boot wasn't the intent, then scriptlet failure may mean an issue in the recipe, or a regression elsewhere.
> Details of the failure are in /workdir/poky/build/tmp/work/genericx86_64-poky-linux/core-image-full-cmdline/1.0-r0/temp/log.do_rootfs.
> WARNING: core-image-full-cmdline-1.0-r0 do_rootfs: [log_check] core-image-full-cmdline: found 2 warning messages in the logfile:
> [log_check] warning: %post(docker-18.03.0+git708b068d3095c6a6be939eb2da78c921d2e945e2-r0.core2_64) scriptlet failed, exit status 1
> [log_check] WARNING: Intentionally failing postinstall scriptlets of ['docker'] to defer them to first boot is deprecated. Please place them into pkg_postinst_ontarget_${PN} ().
>
> Regards,
> Shakthi
>
> On 06/04/18, 1:09 AM, "Bruce Ashfield" <bruce.ashfield@gmail.com> wrote:
>
>     On Thu, Apr 5, 2018 at 11:55 AM, Shakthi Pradeep (tpradeep)
>     <tpradeep@cisco.com> wrote:
>     > Hello Bruce,
>     >
>     > I pulled master branch from git://git.yoctoproject.org/poky but build fails
>     >
>     > When I run "bitbake core-image-full-cmdline" or "bitbake core-image-minimal" I get following error
>     >
>     > ERROR: Task (/nobackup/tpradeep/playground/yocto/poky/meta/recipes-kernel/linux-libc-headers/linux-libc-headers_4.15.7.bb:do_install) failed with exit code '1'
>     > ERROR: Task (/nobackup/tpradeep/playground/yocto/poky/meta/recipes-devtools/autoconf-archive/autoconf-archive_2016.09.16.bb:do_install) failed with exit code '1'
>     >
>     > Any idea why?
>
>     Nope. But the errors are unrelated to the changes in meta-virt. If the
>     issue persists, asking on the oe-core list is a better bet.
>     I'd suggest that you rm -rf tmp, and start the build again.
>
>     Bruce
>
>     >
>     > Regards,
>     > Shakthi
>     >
>     > -----Original Message-----
>     > From: Bruce Ashfield [mailto:bruce.ashfield@gmail.com]
>     > Sent: Thursday, April 05, 2018 7:44 PM
>     > To: Shakthi Pradeep (tpradeep) <tpradeep@cisco.com>
>     > Cc: meta-virtualization@yoctoproject.org
>     > Subject: Re: [meta-virtualization] RFT/FYI: docker/containerd/runc uprevs pushed to master
>     >
>     > On Thu, Apr 5, 2018 at 9:32 AM, Shakthi Pradeep (tpradeep) <tpradeep@cisco.com> wrote:
>     >> Hello Bruce,
>     >>
>     >> I am actually working on a repo from Third Party. So here things are little outdated.
>     >>
>     >> I found some info from http://git.yoctoproject.org
>     >>
>     >> I am currently using Docker 1.13.0 which was committed on 2017-01-20
>     >>
>     >> http://git.yoctoproject.org/cgit/cgit.cgi/meta-virtualization/commit/r
>     >> ecipes-containers/docker?id=0b631bf01487d3d1be0c91ea7749168fb3c47dcb
>     >>
>     >> I need to migrate to 18.03.0 which you committed 3 days ago
>     >>
>     >> http://git.yoctoproject.org/cgit/cgit.cgi/meta-virtualization/commit/r
>     >> ecipes-containers/docker?id=a5074cecf18faea1a325c8ac9220d2df41250af5
>     >>
>     >> If I take recipe from above commit and update my workspace, will all the dependencies migrate to latest automatically?
>     >
>     > Nope. You'd need to pull in all the updates that I recently pushed for the dependencies, or you'll end up with runtime errors.
>     > Also note, that due to the different go versions and build infrastructure in oe-core, there's no guarantee that those new recipes will build properly on an older baseline.
>     >
>     > Bruce
>     >
>     >>
>     >> Regards,
>     >> Shakthi
>     >>
>     >> -----Original Message-----
>     >> From: Bruce Ashfield [mailto:bruce.ashfield@gmail.com]
>     >> Sent: Thursday, April 05, 2018 6:46 PM
>     >> To: Shakthi Pradeep (tpradeep) <tpradeep@cisco.com>
>     >> Cc: meta-virtualization@yoctoproject.org
>     >> Subject: Re: [meta-virtualization] RFT/FYI: docker/containerd/runc
>     >> uprevs pushed to master
>     >>
>     >> root@cube-server:~# docker --version
>     >> Docker version 18.03.0, build 0f1bb353423e
>     >>
>     >> If you are building meta-virt master, the update should happen automatically since the PV of the updated recipe is higher than the old one. All the dependencies will follow after that.
>     >>
>     >> Bruce
>     >>
>     >> On Thu, Apr 5, 2018 at 9:02 AM, Shakthi Pradeep (tpradeep) <tpradeep@cisco.com> wrote:
>     >>> Hello Bruce,
>     >>>
>     >>> Which version of Docker are you running.
>     >>>
>     >>> I just noticed I am running Docker 1.13.1 which is too old.
>     >>>
>     >>> How do I migrate to latest version of Docker & also corresponding dependencies.
>     >>>
>     >>> Regards,
>     >>> Shakthi
>     >>>
>     >>> -----Original Message-----
>     >>> From: Bruce Ashfield [mailto:bruce.ashfield@gmail.com]
>     >>> Sent: Wednesday, April 04, 2018 6:45 PM
>     >>> To: Shakthi Pradeep (tpradeep) <tpradeep@cisco.com>
>     >>> Cc: meta-virtualization@yoctoproject.org
>     >>> Subject: Re: [meta-virtualization] RFT/FYI: docker/containerd/runc
>     >>> uprevs pushed to master
>     >>>
>     >>> Excellent news.
>     >>>
>     >>> Yes, everything is in master of meta-virtualization now. That way it will have time to soak a bit before the upcoming release.
>     >>>
>     >>> Cheers,
>     >>>
>     >>> Bruce
>     >>>
>     >>> On Wed, Apr 4, 2018 at 8:32 AM, Shakthi Pradeep (tpradeep) <tpradeep@cisco.com> wrote:
>     >>>> Hello Bruce,
>     >>>>
>     >>>> Yes I was missing the bbappend for kernel config. Got it working after I wrote the mail to you.
>     >>>>
>     >>>> Are your changes committed to git repo? Is it in the master branch of Yocto?
>     >>>>
>     >>>> Regards,
>     >>>> Shakthi
>     >>>>
>     >>>> -----Original Message-----
>     >>>> From: Bruce Ashfield [mailto:bruce.ashfield@gmail.com]
>     >>>> Sent: Wednesday, April 04, 2018 5:57 PM
>     >>>> To: Shakthi Pradeep (tpradeep) <tpradeep@cisco.com>
>     >>>> Cc: meta-virtualization@yoctoproject.org
>     >>>> Subject: Re: [meta-virtualization] RFT/FYI: docker/containerd/runc
>     >>>> uprevs pushed to master
>     >>>>
>     >>>> On Wed, Apr 4, 2018 at 12:57 AM, Shakthi Pradeep (tpradeep) <tpradeep@cisco.com> wrote:
>     >>>>> Hello Bruce,
>     >>>>>
>     >>>>>
>     >>>>>
>     >>>>> Timing is Perfect !!!
>     >>>>>
>     >>>>>
>     >>>>>
>     >>>>> I am currently trying to get Docker CE to work with Yocto. I could
>     >>>>> include the Docker executable in ISO but when I run it I get some errors.
>     >>>>>
>     >>>>>
>     >>>>>
>     >>>>> When I boot the image looks like Docker service start is failing
>     >>>>> due to missing kernel modules. Please refer attached screenshot and
>     >>>>> below error log.
>     >>>>
>     >>>> Do you have a bbappend for your 4.8 kernel that adds the docker configuration fragments ?
>     >>>>
>     >>>> That's the most likely reason for the issues.
>     >>>>
>     >>>> I was able to run a whole suite of tests against 4.12, 4.14 and 4.15 so those kernels + fragments are known to work.
>     >>>>
>     >>>> Bruce
>     >>>>
>     >>>>>
>     >>>>>
>     >>>>>
>     >>>>> * docker.service - Docker Application Container Engine
>     >>>>>
>     >>>>>    Loaded: loaded (/lib/systemd/system/docker.service; enabled;
>     >>>>> vendor
>     >>>>> preset: enabled)
>     >>>>>
>     >>>>>    Active: failed (Result: exit-code) since Tue 2018-04-03 13:17:51
>     >>>>> UTC; 17min ago
>     >>>>>
>     >>>>>      Docs: https://docs.docker.com
>     >>>>>
>     >>>>>   Process: 317 ExecStart=/usr/bin/dockerd -H fd:// (code=exited,
>     >>>>> status=1/FAILURE)
>     >>>>>
>     >>>>> Main PID: 317 (code=exited, status=1/FAILURE)
>     >>>>>
>     >>>>>
>     >>>>>
>     >>>>> Apr 03 13:17:51 intel-x86-64 dockerd[317]:
>     >>>>> time="2018-04-03T13:17:51.035178755Z" level=warning msg="Running
>     >>>>> modprobe xt_conntrack failed with message: `modprobe: WARNING:
>     >>>>> Module xt_conntrack not found in directory
>     >>>>> /lib/modules/4.8.24-WR9.0.0.10_standard`, error: exit status 1"
>     >>>>>
>     >>>>> Apr 03 13:17:51 intel-x86-64 dockerd[317]:
>     >>>>> time="2018-04-03T13:17:51.040727372Z" level=info msg="Firewalld running:
>     >>>>> false"
>     >>>>>
>     >>>>> Apr 03 13:17:51 intel-x86-64 dockerd[317]:
>     >>>>> time="2018-04-03T13:17:51.170575344Z" level=warning msg="Could not
>     >>>>> load necessary modules for IPSEC rules: Running modprobe xfrm_user
>     >>>>> failed with
>     >>>>> message: `modprobe: WARNING: Module xfrm_user not found in
>     >>>>> directory /lib/modules/4.8.24-WR9.0.0.10_standard`, error: exit status 1"
>     >>>>>
>     >>>>> Apr 03 13:17:51 intel-x86-64 dockerd[317]:
>     >>>>> time="2018-04-03T13:17:51.172397913Z" level=info msg="Default
>     >>>>> bridge
>     >>>>> (docker0) is assigned with an IP address 172.17.0.0/16. Daemon
>     >>>>> option --bip can be used to set a preferred IP address"
>     >>>>>
>     >>>>> Apr 03 13:17:51 intel-x86-64 dockerd[317]: Error starting daemon:
>     >>>>> Error initializing network controller: Error creating default "bridge" network:
>     >>>>> Failed to Setup IP tables: Unable to enable ACCEPT INCOMING rule:
>     >>>>> (iptables
>     >>>>> failed: iptables --wait -I FORWARD -o docker0 -m conntrack
>     >>>>> --ctstate RELATED,ESTABLISHED -j ACCEPT: iptables: No chain/target/match by that name.
>     >>>>>
>     >>>>> Apr 03 13:17:51 intel-x86-64 dockerd[317]:  (exit status 1))
>     >>>>>
>     >>>>> Apr 03 13:17:51 intel-x86-64 systemd[1]: docker.service: Main
>     >>>>> process exited, code=exited, status=1/FAILURE
>     >>>>>
>     >>>>> Apr 03 13:17:51 intel-x86-64 systemd[1]: Failed to start Docker
>     >>>>> Application Container Engine.
>     >>>>>
>     >>>>> Apr 03 13:17:51 intel-x86-64 systemd[1]: docker.service: Unit
>     >>>>> entered failed state.
>     >>>>>
>     >>>>> Apr 03 13:17:51 intel-x86-64 systemd[1]: docker.service: Failed
>     >>>>> with result 'exit-code'.
>     >>>>>
>     >>>>>
>     >>>>>
>     >>>>> Regards,
>     >>>>>
>     >>>>> Shakthi
>     >>>>>
>     >>>>>
>     >>>>>
>     >>>>> -----Original Message-----
>     >>>>> From: meta-virtualization-bounces@yoctoproject.org
>     >>>>> [mailto:meta-virtualization-bounces@yoctoproject.org] On Behalf Of
>     >>>>> Bruce Ashfield
>     >>>>> Sent: Wednesday, April 04, 2018 8:44 AM
>     >>>>> To: meta-virtualization@yoctoproject.org
>     >>>>> Subject: [meta-virtualization] RFT/FYI: docker/containerd/runc
>     >>>>> uprevs pushed to master
>     >>>>>
>     >>>>>
>     >>>>>
>     >>>>> Hi all,
>     >>>>>
>     >>>>>
>     >>>>>
>     >>>>> After spending a few days de-tangling the
>     >>>>> moby/docker/runc/containerd and oe-core go infrastructure changes,
>     >>>>> I was able to run docker/runc/containerd through a system/stress test and everything seems to be working.
>     >>>>>
>     >>>>>
>     >>>>>
>     >>>>> There were a few regressions that I worked through, as well as
>     >>>>> build/packaging changes, but I'm no longer seeing any issues and
>     >>>>> all the patches/functionality have been carried forward.
>     >>>>>
>     >>>>>
>     >>>>>
>     >>>>> One thing of note is that the docker and open containers containerd
>     >>>>> split/fork is no longer an issue, so I've modified the default to
>     >>>>> be the opencontainers variant. Similarly, the docker and
>     >>>>> opencontainers runc are very similar. I've kept both variants of
>     >>>>> both recipes for now, since I'd like to track things for a bit
>     >>>>> longer before declaring the split unnecessary.
>     >>>>>
>     >>>>>
>     >>>>>
>     >>>>> Also for those that care, I created a reference docker-ce recipe
>     >>>>> that tracks the docker-ce repo versus the components themselves.
>     >>>>> Right now it is reference only, since it needs a bit more work, but
>     >>>>> I wanted to get it out there, in case someone really cares about
>     >>>>> docker-ce (I don't really, but someone might!).
>     >>>>>
>     >>>>>
>     >>>>>
>     >>>>> Summary: I just pushed the following changes to master:
>     >>>>>
>     >>>>>
>     >>>>>
>     >>>>>   d7d310ae4113 meta-virt: prefer containerd-opencontainers
>     >>>>>
>     >>>>>   935e3d969ef1 containerd: uprev to v1.0.2
>     >>>>>
>     >>>>>   f5fbfa8ac4db docker-ce: introduce reference recipe/build
>     >>>>>
>     >>>>>   a5074cecf18f docker: uprev to 18.03.0
>     >>>>>
>     >>>>>   e3d960f4fcd9 runc: uprev to 1.0.0-rc5
>     >>>>>
>     >>>>>
>     >>>>>
>     >>>>> If anyone sees regressions, build or architecture issues .. report
>     >>>>> them to me (and the list) and we'll get them fixed up.
>     >>>>>
>     >>>>>
>     >>>>>
>     >>>>> Cheers,
>     >>>>>
>     >>>>>
>     >>>>>
>     >>>>> Bruce
>     >>>>>
>     >>>>>
>     >>>>>
>     >>>>> --
>     >>>>>
>     >>>>> "Thou shalt not follow the NULL pointer, for chaos and madness
>     >>>>> await thee at its end"
>     >>>>>
>     >>>>> --
>     >>>>>
>     >>>>> _______________________________________________
>     >>>>>
>     >>>>> meta-virtualization mailing list
>     >>>>>
>     >>>>> meta-virtualization@yoctoproject.org
>     >>>>>
>     >>>>> https://lists.yoctoproject.org/listinfo/meta-virtualization
>     >>>>
>     >>>>
>     >>>>
>     >>>> --
>     >>>> "Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end"
>     >>>
>     >>>
>     >>>
>     >>> --
>     >>> "Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end"
>     >>
>     >>
>     >>
>     >> --
>     >> "Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end"
>     >
>     >
>     >
>     > --
>     > "Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end"
>
>
>
>     --
>     "Thou shalt not follow the NULL pointer, for chaos and madness await
>     thee at its end"
>
>



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"

Re: RFT/FYI: docker/containerd/runc uprevs pushed to master

[Shakthi Pradeep (tpradeep)]

Hello Bruce,

I see pkg_postinst_${PN}() are part of below recipes….

TPRADEEP-M-91HW:meta-virtualization tpradeep$ grep -r postinst *
recipes-containers/singularity/singularity_git.bb:pkg_postinst_${PN}() {
recipes-containers/lxc/lxc_2.0.8.bb:pkg_postinst_${PN}() {
recipes-containers/lxc/lxc_2.0.8.bb:pkg_postinst_${PN}-networking() {
recipes-extended/xen/xen.inc:pkg_postinst_${PN}-volatiles() {
recipes-extended/libvirt/libvirt_1.3.5.bb:pkg_postinst_libvirt() {
recipes-networking/openvswitch/openvswitch.inc:# rdeps.  E.g. ovs-pki calls sed in the postinstall.  sed may be
recipes-networking/openvswitch/openvswitch.inc:pkg_postinst_${PN}-pki () {
recipes-networking/openvswitch/openvswitch.inc:pkg_postinst_${PN}-testcontroller () {

Regards,
Shakthi

On 09/04/18, 6:47 PM, "Bruce Ashfield" <bruce.ashfield@gmail.com> wrote:

    On Mon, Apr 9, 2018 at 4:37 AM, Shakthi Pradeep (tpradeep)
    <tpradeep@cisco.com> wrote:
    > Hello Bruce,
    >
    > Moved to master branch of Yocto. When I build I am getting below error. What does this mean?
    
    There were changes made to the way that postinstall scripts were run
    in the January
    timeframe,
    
    i.e.:
    
     commit 7bc55b29609765904af9f330600229e96cc044cf
    Author: Alexander Kanavin <alexander.kanavin@linux.intel.com>
    Date:   Mon Jan 29 14:01:32 2018 +0200
    
        meta/lib/oe/package_manager.py: deprecate 'exit 1' as a way to
    defer to first boot
    
        'exit 1' is not optimal for two reasons:
    
        1) Code is hard to read; it is not obvious that it means 'defer
    what follows to first boot'.
        2) Worse, this hides actual errors in the scriptlets; there is no
    difference between scriptlet
        failing because it's intended to be run on target and scriptlet
    failing because there's a bug or
        a regression somewhere.
    
        The new, supported way is to place the code that has to run on
    target into pkg_postinst_ontarget(),
        or, if a more fine-tuned control is required, call
    'postinst-intercepts defer_to_first_boot' from
        pkg_postinst() to explicitly request deferral to first boot.
    
        (From OE-Core rev: d12cf56e9ff2a4f13dfbef9290ea5647b52b3f6d)
    
        Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
        Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
    
    :100644 100644 2a07f0e39ad6... f7e013437c91... M
    meta/lib/oe/package_manager.py
    
    commit 6ca669105ff7f405e85142d1aa5375a8430c9606
    Author: Alexander Kanavin <alexander.kanavin@linux.intel.com>
    Date:   Mon Jan 29 14:01:31 2018 +0200
    
        package.bbclass: add support for pkg_postinst_ontarget()
    
        This function is a convenient and more readable shortcut for situations
        when the postinst code always needs to run on target. All commands that
        cannot be executed during cross-install and can only be run on target
        should go into this function. They will only be executed on first boot
        (if package was cross-installed) or immediately during package installation
        on target.
    
        Plain pkg_postinst() works as before: it is run during cross-install time,
        it can contain a request to defer to first boot, and it is also run
        during package installation on target.
    
        Also fix the oeqa test for this functionality to use the new function
        where appropriate.
    
        (From OE-Core rev: 229f4e975fb6957f44b5c56735fd6d58564098d7)
    
        Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
        Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
    
    :100644 100644 112aa08c80f8... d4bab6dcc228... M
    meta-selftest/recipes-test/postinst/postinst_1.0.bb
    :100644 100644 7dc759699f4b... 6a7f35a3e787... M
    meta/classes/package.bbclass
    
    -------
    
    But you shouldn't be getting that warning with docker, since it doesn't
    have a pkg_postinst_${PN}(), or related element in the recipe.
    
    So something in your build is adding that postinstall action, that isn't
    part of the meta-virtualization layer.
    
    Bruce
    
    
    >
    > Initialising tasks: 100% |######################################################################################################################################################| Time: 0:00:04
    > NOTE: Executing SetScene Tasks
    > NOTE: Executing RunQueue Tasks
    > WARNING: core-image-full-cmdline-1.0-r0 do_rootfs: Intentionally failing postinstall scriptlets of ['docker'] to defer them to first boot is deprecated. Please place them into pkg_postinst_ontarget_${PN} ().
    > If deferring to first boot wasn't the intent, then scriptlet failure may mean an issue in the recipe, or a regression elsewhere.
    > Details of the failure are in /workdir/poky/build/tmp/work/genericx86_64-poky-linux/core-image-full-cmdline/1.0-r0/temp/log.do_rootfs.
    > WARNING: core-image-full-cmdline-1.0-r0 do_rootfs: [log_check] core-image-full-cmdline: found 2 warning messages in the logfile:
    > [log_check] warning: %post(docker-18.03.0+git708b068d3095c6a6be939eb2da78c921d2e945e2-r0.core2_64) scriptlet failed, exit status 1
    > [log_check] WARNING: Intentionally failing postinstall scriptlets of ['docker'] to defer them to first boot is deprecated. Please place them into pkg_postinst_ontarget_${PN} ().
    >
    > Regards,
    > Shakthi
    >
    > On 06/04/18, 1:09 AM, "Bruce Ashfield" <bruce.ashfield@gmail.com> wrote:
    >
    >     On Thu, Apr 5, 2018 at 11:55 AM, Shakthi Pradeep (tpradeep)
    >     <tpradeep@cisco.com> wrote:
    >     > Hello Bruce,
    >     >
    >     > I pulled master branch from git://git.yoctoproject.org/poky but build fails
    >     >
    >     > When I run "bitbake core-image-full-cmdline" or "bitbake core-image-minimal" I get following error
    >     >
    >     > ERROR: Task (/nobackup/tpradeep/playground/yocto/poky/meta/recipes-kernel/linux-libc-headers/linux-libc-headers_4.15.7.bb:do_install) failed with exit code '1'
    >     > ERROR: Task (/nobackup/tpradeep/playground/yocto/poky/meta/recipes-devtools/autoconf-archive/autoconf-archive_2016.09.16.bb:do_install) failed with exit code '1'
    >     >
    >     > Any idea why?
    >
    >     Nope. But the errors are unrelated to the changes in meta-virt. If the
    >     issue persists, asking on the oe-core list is a better bet.
    >     I'd suggest that you rm -rf tmp, and start the build again.
    >
    >     Bruce
    >
    >     >
    >     > Regards,
    >     > Shakthi
    >     >
    >     > -----Original Message-----
    >     > From: Bruce Ashfield [mailto:bruce.ashfield@gmail.com]
    >     > Sent: Thursday, April 05, 2018 7:44 PM
    >     > To: Shakthi Pradeep (tpradeep) <tpradeep@cisco.com>
    >     > Cc: meta-virtualization@yoctoproject.org
    >     > Subject: Re: [meta-virtualization] RFT/FYI: docker/containerd/runc uprevs pushed to master
    >     >
    >     > On Thu, Apr 5, 2018 at 9:32 AM, Shakthi Pradeep (tpradeep) <tpradeep@cisco.com> wrote:
    >     >> Hello Bruce,
    >     >>
    >     >> I am actually working on a repo from Third Party. So here things are little outdated.
    >     >>
    >     >> I found some info from http://git.yoctoproject.org
    >     >>
    >     >> I am currently using Docker 1.13.0 which was committed on 2017-01-20
    >     >>
    >     >> http://git.yoctoproject.org/cgit/cgit.cgi/meta-virtualization/commit/r
    >     >> ecipes-containers/docker?id=0b631bf01487d3d1be0c91ea7749168fb3c47dcb
    >     >>
    >     >> I need to migrate to 18.03.0 which you committed 3 days ago
    >     >>
    >     >> http://git.yoctoproject.org/cgit/cgit.cgi/meta-virtualization/commit/r
    >     >> ecipes-containers/docker?id=a5074cecf18faea1a325c8ac9220d2df41250af5
    >     >>
    >     >> If I take recipe from above commit and update my workspace, will all the dependencies migrate to latest automatically?
    >     >
    >     > Nope. You'd need to pull in all the updates that I recently pushed for the dependencies, or you'll end up with runtime errors.
    >     > Also note, that due to the different go versions and build infrastructure in oe-core, there's no guarantee that those new recipes will build properly on an older baseline.
    >     >
    >     > Bruce
    >     >
    >     >>
    >     >> Regards,
    >     >> Shakthi
    >     >>
    >     >> -----Original Message-----
    >     >> From: Bruce Ashfield [mailto:bruce.ashfield@gmail.com]
    >     >> Sent: Thursday, April 05, 2018 6:46 PM
    >     >> To: Shakthi Pradeep (tpradeep) <tpradeep@cisco.com>
    >     >> Cc: meta-virtualization@yoctoproject.org
    >     >> Subject: Re: [meta-virtualization] RFT/FYI: docker/containerd/runc
    >     >> uprevs pushed to master
    >     >>
    >     >> root@cube-server:~# docker --version
    >     >> Docker version 18.03.0, build 0f1bb353423e
    >     >>
    >     >> If you are building meta-virt master, the update should happen automatically since the PV of the updated recipe is higher than the old one. All the dependencies will follow after that.
    >     >>
    >     >> Bruce
    >     >>
    >     >> On Thu, Apr 5, 2018 at 9:02 AM, Shakthi Pradeep (tpradeep) <tpradeep@cisco.com> wrote:
    >     >>> Hello Bruce,
    >     >>>
    >     >>> Which version of Docker are you running.
    >     >>>
    >     >>> I just noticed I am running Docker 1.13.1 which is too old.
    >     >>>
    >     >>> How do I migrate to latest version of Docker & also corresponding dependencies.
    >     >>>
    >     >>> Regards,
    >     >>> Shakthi
    >     >>>
    >     >>> -----Original Message-----
    >     >>> From: Bruce Ashfield [mailto:bruce.ashfield@gmail.com]
    >     >>> Sent: Wednesday, April 04, 2018 6:45 PM
    >     >>> To: Shakthi Pradeep (tpradeep) <tpradeep@cisco.com>
    >     >>> Cc: meta-virtualization@yoctoproject.org
    >     >>> Subject: Re: [meta-virtualization] RFT/FYI: docker/containerd/runc
    >     >>> uprevs pushed to master
    >     >>>
    >     >>> Excellent news.
    >     >>>
    >     >>> Yes, everything is in master of meta-virtualization now. That way it will have time to soak a bit before the upcoming release.
    >     >>>
    >     >>> Cheers,
    >     >>>
    >     >>> Bruce
    >     >>>
    >     >>> On Wed, Apr 4, 2018 at 8:32 AM, Shakthi Pradeep (tpradeep) <tpradeep@cisco.com> wrote:
    >     >>>> Hello Bruce,
    >     >>>>
    >     >>>> Yes I was missing the bbappend for kernel config. Got it working after I wrote the mail to you.
    >     >>>>
    >     >>>> Are your changes committed to git repo? Is it in the master branch of Yocto?
    >     >>>>
    >     >>>> Regards,
    >     >>>> Shakthi
    >     >>>>
    >     >>>> -----Original Message-----
    >     >>>> From: Bruce Ashfield [mailto:bruce.ashfield@gmail.com]
    >     >>>> Sent: Wednesday, April 04, 2018 5:57 PM
    >     >>>> To: Shakthi Pradeep (tpradeep) <tpradeep@cisco.com>
    >     >>>> Cc: meta-virtualization@yoctoproject.org
    >     >>>> Subject: Re: [meta-virtualization] RFT/FYI: docker/containerd/runc
    >     >>>> uprevs pushed to master
    >     >>>>
    >     >>>> On Wed, Apr 4, 2018 at 12:57 AM, Shakthi Pradeep (tpradeep) <tpradeep@cisco.com> wrote:
    >     >>>>> Hello Bruce,
    >     >>>>>
    >     >>>>>
    >     >>>>>
    >     >>>>> Timing is Perfect !!!
    >     >>>>>
    >     >>>>>
    >     >>>>>
    >     >>>>> I am currently trying to get Docker CE to work with Yocto. I could
    >     >>>>> include the Docker executable in ISO but when I run it I get some errors.
    >     >>>>>
    >     >>>>>
    >     >>>>>
    >     >>>>> When I boot the image looks like Docker service start is failing
    >     >>>>> due to missing kernel modules. Please refer attached screenshot and
    >     >>>>> below error log.
    >     >>>>
    >     >>>> Do you have a bbappend for your 4.8 kernel that adds the docker configuration fragments ?
    >     >>>>
    >     >>>> That's the most likely reason for the issues.
    >     >>>>
    >     >>>> I was able to run a whole suite of tests against 4.12, 4.14 and 4.15 so those kernels + fragments are known to work.
    >     >>>>
    >     >>>> Bruce
    >     >>>>
    >     >>>>>
    >     >>>>>
    >     >>>>>
    >     >>>>> * docker.service - Docker Application Container Engine
    >     >>>>>
    >     >>>>>    Loaded: loaded (/lib/systemd/system/docker.service; enabled;
    >     >>>>> vendor
    >     >>>>> preset: enabled)
    >     >>>>>
    >     >>>>>    Active: failed (Result: exit-code) since Tue 2018-04-03 13:17:51
    >     >>>>> UTC; 17min ago
    >     >>>>>
    >     >>>>>      Docs: https://docs.docker.com
    >     >>>>>
    >     >>>>>   Process: 317 ExecStart=/usr/bin/dockerd -H fd:// (code=exited,
    >     >>>>> status=1/FAILURE)
    >     >>>>>
    >     >>>>> Main PID: 317 (code=exited, status=1/FAILURE)
    >     >>>>>
    >     >>>>>
    >     >>>>>
    >     >>>>> Apr 03 13:17:51 intel-x86-64 dockerd[317]:
    >     >>>>> time="2018-04-03T13:17:51.035178755Z" level=warning msg="Running
    >     >>>>> modprobe xt_conntrack failed with message: `modprobe: WARNING:
    >     >>>>> Module xt_conntrack not found in directory
    >     >>>>> /lib/modules/4.8.24-WR9.0.0.10_standard`, error: exit status 1"
    >     >>>>>
    >     >>>>> Apr 03 13:17:51 intel-x86-64 dockerd[317]:
    >     >>>>> time="2018-04-03T13:17:51.040727372Z" level=info msg="Firewalld running:
    >     >>>>> false"
    >     >>>>>
    >     >>>>> Apr 03 13:17:51 intel-x86-64 dockerd[317]:
    >     >>>>> time="2018-04-03T13:17:51.170575344Z" level=warning msg="Could not
    >     >>>>> load necessary modules for IPSEC rules: Running modprobe xfrm_user
    >     >>>>> failed with
    >     >>>>> message: `modprobe: WARNING: Module xfrm_user not found in
    >     >>>>> directory /lib/modules/4.8.24-WR9.0.0.10_standard`, error: exit status 1"
    >     >>>>>
    >     >>>>> Apr 03 13:17:51 intel-x86-64 dockerd[317]:
    >     >>>>> time="2018-04-03T13:17:51.172397913Z" level=info msg="Default
    >     >>>>> bridge
    >     >>>>> (docker0) is assigned with an IP address 172.17.0.0/16. Daemon
    >     >>>>> option --bip can be used to set a preferred IP address"
    >     >>>>>
    >     >>>>> Apr 03 13:17:51 intel-x86-64 dockerd[317]: Error starting daemon:
    >     >>>>> Error initializing network controller: Error creating default "bridge" network:
    >     >>>>> Failed to Setup IP tables: Unable to enable ACCEPT INCOMING rule:
    >     >>>>> (iptables
    >     >>>>> failed: iptables --wait -I FORWARD -o docker0 -m conntrack
    >     >>>>> --ctstate RELATED,ESTABLISHED -j ACCEPT: iptables: No chain/target/match by that name.
    >     >>>>>
    >     >>>>> Apr 03 13:17:51 intel-x86-64 dockerd[317]:  (exit status 1))
    >     >>>>>
    >     >>>>> Apr 03 13:17:51 intel-x86-64 systemd[1]: docker.service: Main
    >     >>>>> process exited, code=exited, status=1/FAILURE
    >     >>>>>
    >     >>>>> Apr 03 13:17:51 intel-x86-64 systemd[1]: Failed to start Docker
    >     >>>>> Application Container Engine.
    >     >>>>>
    >     >>>>> Apr 03 13:17:51 intel-x86-64 systemd[1]: docker.service: Unit
    >     >>>>> entered failed state.
    >     >>>>>
    >     >>>>> Apr 03 13:17:51 intel-x86-64 systemd[1]: docker.service: Failed
    >     >>>>> with result 'exit-code'.
    >     >>>>>
    >     >>>>>
    >     >>>>>
    >     >>>>> Regards,
    >     >>>>>
    >     >>>>> Shakthi
    >     >>>>>
    >     >>>>>
    >     >>>>>
    >     >>>>> -----Original Message-----
    >     >>>>> From: meta-virtualization-bounces@yoctoproject.org
    >     >>>>> [mailto:meta-virtualization-bounces@yoctoproject.org] On Behalf Of
    >     >>>>> Bruce Ashfield
    >     >>>>> Sent: Wednesday, April 04, 2018 8:44 AM
    >     >>>>> To: meta-virtualization@yoctoproject.org
    >     >>>>> Subject: [meta-virtualization] RFT/FYI: docker/containerd/runc
    >     >>>>> uprevs pushed to master
    >     >>>>>
    >     >>>>>
    >     >>>>>
    >     >>>>> Hi all,
    >     >>>>>
    >     >>>>>
    >     >>>>>
    >     >>>>> After spending a few days de-tangling the
    >     >>>>> moby/docker/runc/containerd and oe-core go infrastructure changes,
    >     >>>>> I was able to run docker/runc/containerd through a system/stress test and everything seems to be working.
    >     >>>>>
    >     >>>>>
    >     >>>>>
    >     >>>>> There were a few regressions that I worked through, as well as
    >     >>>>> build/packaging changes, but I'm no longer seeing any issues and
    >     >>>>> all the patches/functionality have been carried forward.
    >     >>>>>
    >     >>>>>
    >     >>>>>
    >     >>>>> One thing of note is that the docker and open containers containerd
    >     >>>>> split/fork is no longer an issue, so I've modified the default to
    >     >>>>> be the opencontainers variant. Similarly, the docker and
    >     >>>>> opencontainers runc are very similar. I've kept both variants of
    >     >>>>> both recipes for now, since I'd like to track things for a bit
    >     >>>>> longer before declaring the split unnecessary.
    >     >>>>>
    >     >>>>>
    >     >>>>>
    >     >>>>> Also for those that care, I created a reference docker-ce recipe
    >     >>>>> that tracks the docker-ce repo versus the components themselves.
    >     >>>>> Right now it is reference only, since it needs a bit more work, but
    >     >>>>> I wanted to get it out there, in case someone really cares about
    >     >>>>> docker-ce (I don't really, but someone might!).
    >     >>>>>
    >     >>>>>
    >     >>>>>
    >     >>>>> Summary: I just pushed the following changes to master:
    >     >>>>>
    >     >>>>>
    >     >>>>>
    >     >>>>>   d7d310ae4113 meta-virt: prefer containerd-opencontainers
    >     >>>>>
    >     >>>>>   935e3d969ef1 containerd: uprev to v1.0.2
    >     >>>>>
    >     >>>>>   f5fbfa8ac4db docker-ce: introduce reference recipe/build
    >     >>>>>
    >     >>>>>   a5074cecf18f docker: uprev to 18.03.0
    >     >>>>>
    >     >>>>>   e3d960f4fcd9 runc: uprev to 1.0.0-rc5
    >     >>>>>
    >     >>>>>
    >     >>>>>
    >     >>>>> If anyone sees regressions, build or architecture issues .. report
    >     >>>>> them to me (and the list) and we'll get them fixed up.
    >     >>>>>
    >     >>>>>
    >     >>>>>
    >     >>>>> Cheers,
    >     >>>>>
    >     >>>>>
    >     >>>>>
    >     >>>>> Bruce
    >     >>>>>
    >     >>>>>
    >     >>>>>
    >     >>>>> --
    >     >>>>>
    >     >>>>> "Thou shalt not follow the NULL pointer, for chaos and madness
    >     >>>>> await thee at its end"
    >     >>>>>
    >     >>>>> --
    >     >>>>>
    >     >>>>> _______________________________________________
    >     >>>>>
    >     >>>>> meta-virtualization mailing list
    >     >>>>>
    >     >>>>> meta-virtualization@yoctoproject.org
    >     >>>>>
    >     >>>>> https://lists.yoctoproject.org/listinfo/meta-virtualization
    >     >>>>
    >     >>>>
    >     >>>>
    >     >>>> --
    >     >>>> "Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end"
    >     >>>
    >     >>>
    >     >>>
    >     >>> --
    >     >>> "Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end"
    >     >>
    >     >>
    >     >>
    >     >> --
    >     >> "Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end"
    >     >
    >     >
    >     >
    >     > --
    >     > "Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end"
    >
    >
    >
    >     --
    >     "Thou shalt not follow the NULL pointer, for chaos and madness await
    >     thee at its end"
    >
    >
    
    
    
    -- 
    "Thou shalt not follow the NULL pointer, for chaos and madness await
    thee at its end"
    

Re: RFT/FYI: docker/containerd/runc uprevs pushed to master

[Bruce Ashfield]

Sure, but none of them are docker.

Bruce

On Mon, Apr 9, 2018 at 9:46 AM, Shakthi Pradeep (tpradeep)
<tpradeep@cisco.com> wrote:
> Hello Bruce,
>
> I see pkg_postinst_${PN}() are part of below recipes….
>
> TPRADEEP-M-91HW:meta-virtualization tpradeep$ grep -r postinst *
> recipes-containers/singularity/singularity_git.bb:pkg_postinst_${PN}() {
> recipes-containers/lxc/lxc_2.0.8.bb:pkg_postinst_${PN}() {
> recipes-containers/lxc/lxc_2.0.8.bb:pkg_postinst_${PN}-networking() {
> recipes-extended/xen/xen.inc:pkg_postinst_${PN}-volatiles() {
> recipes-extended/libvirt/libvirt_1.3.5.bb:pkg_postinst_libvirt() {
> recipes-networking/openvswitch/openvswitch.inc:# rdeps.  E.g. ovs-pki calls sed in the postinstall.  sed may be
> recipes-networking/openvswitch/openvswitch.inc:pkg_postinst_${PN}-pki () {
> recipes-networking/openvswitch/openvswitch.inc:pkg_postinst_${PN}-testcontroller () {
>
> Regards,
> Shakthi
>
> On 09/04/18, 6:47 PM, "Bruce Ashfield" <bruce.ashfield@gmail.com> wrote:
>
>     On Mon, Apr 9, 2018 at 4:37 AM, Shakthi Pradeep (tpradeep)
>     <tpradeep@cisco.com> wrote:
>     > Hello Bruce,
>     >
>     > Moved to master branch of Yocto. When I build I am getting below error. What does this mean?
>
>     There were changes made to the way that postinstall scripts were run
>     in the January
>     timeframe,
>
>     i.e.:
>
>      commit 7bc55b29609765904af9f330600229e96cc044cf
>     Author: Alexander Kanavin <alexander.kanavin@linux.intel.com>
>     Date:   Mon Jan 29 14:01:32 2018 +0200
>
>         meta/lib/oe/package_manager.py: deprecate 'exit 1' as a way to
>     defer to first boot
>
>         'exit 1' is not optimal for two reasons:
>
>         1) Code is hard to read; it is not obvious that it means 'defer
>     what follows to first boot'.
>         2) Worse, this hides actual errors in the scriptlets; there is no
>     difference between scriptlet
>         failing because it's intended to be run on target and scriptlet
>     failing because there's a bug or
>         a regression somewhere.
>
>         The new, supported way is to place the code that has to run on
>     target into pkg_postinst_ontarget(),
>         or, if a more fine-tuned control is required, call
>     'postinst-intercepts defer_to_first_boot' from
>         pkg_postinst() to explicitly request deferral to first boot.
>
>         (From OE-Core rev: d12cf56e9ff2a4f13dfbef9290ea5647b52b3f6d)
>
>         Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
>         Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
>
>     :100644 100644 2a07f0e39ad6... f7e013437c91... M
>     meta/lib/oe/package_manager.py
>
>     commit 6ca669105ff7f405e85142d1aa5375a8430c9606
>     Author: Alexander Kanavin <alexander.kanavin@linux.intel.com>
>     Date:   Mon Jan 29 14:01:31 2018 +0200
>
>         package.bbclass: add support for pkg_postinst_ontarget()
>
>         This function is a convenient and more readable shortcut for situations
>         when the postinst code always needs to run on target. All commands that
>         cannot be executed during cross-install and can only be run on target
>         should go into this function. They will only be executed on first boot
>         (if package was cross-installed) or immediately during package installation
>         on target.
>
>         Plain pkg_postinst() works as before: it is run during cross-install time,
>         it can contain a request to defer to first boot, and it is also run
>         during package installation on target.
>
>         Also fix the oeqa test for this functionality to use the new function
>         where appropriate.
>
>         (From OE-Core rev: 229f4e975fb6957f44b5c56735fd6d58564098d7)
>
>         Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
>         Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
>
>     :100644 100644 112aa08c80f8... d4bab6dcc228... M
>     meta-selftest/recipes-test/postinst/postinst_1.0.bb
>     :100644 100644 7dc759699f4b... 6a7f35a3e787... M
>     meta/classes/package.bbclass
>
>     -------
>
>     But you shouldn't be getting that warning with docker, since it doesn't
>     have a pkg_postinst_${PN}(), or related element in the recipe.
>
>     So something in your build is adding that postinstall action, that isn't
>     part of the meta-virtualization layer.
>
>     Bruce
>
>
>     >
>     > Initialising tasks: 100% |######################################################################################################################################################| Time: 0:00:04
>     > NOTE: Executing SetScene Tasks
>     > NOTE: Executing RunQueue Tasks
>     > WARNING: core-image-full-cmdline-1.0-r0 do_rootfs: Intentionally failing postinstall scriptlets of ['docker'] to defer them to first boot is deprecated. Please place them into pkg_postinst_ontarget_${PN} ().
>     > If deferring to first boot wasn't the intent, then scriptlet failure may mean an issue in the recipe, or a regression elsewhere.
>     > Details of the failure are in /workdir/poky/build/tmp/work/genericx86_64-poky-linux/core-image-full-cmdline/1.0-r0/temp/log.do_rootfs.
>     > WARNING: core-image-full-cmdline-1.0-r0 do_rootfs: [log_check] core-image-full-cmdline: found 2 warning messages in the logfile:
>     > [log_check] warning: %post(docker-18.03.0+git708b068d3095c6a6be939eb2da78c921d2e945e2-r0.core2_64) scriptlet failed, exit status 1
>     > [log_check] WARNING: Intentionally failing postinstall scriptlets of ['docker'] to defer them to first boot is deprecated. Please place them into pkg_postinst_ontarget_${PN} ().
>     >
>     > Regards,
>     > Shakthi
>     >
>     > On 06/04/18, 1:09 AM, "Bruce Ashfield" <bruce.ashfield@gmail.com> wrote:
>     >
>     >     On Thu, Apr 5, 2018 at 11:55 AM, Shakthi Pradeep (tpradeep)
>     >     <tpradeep@cisco.com> wrote:
>     >     > Hello Bruce,
>     >     >
>     >     > I pulled master branch from git://git.yoctoproject.org/poky but build fails
>     >     >
>     >     > When I run "bitbake core-image-full-cmdline" or "bitbake core-image-minimal" I get following error
>     >     >
>     >     > ERROR: Task (/nobackup/tpradeep/playground/yocto/poky/meta/recipes-kernel/linux-libc-headers/linux-libc-headers_4.15.7.bb:do_install) failed with exit code '1'
>     >     > ERROR: Task (/nobackup/tpradeep/playground/yocto/poky/meta/recipes-devtools/autoconf-archive/autoconf-archive_2016.09.16.bb:do_install) failed with exit code '1'
>     >     >
>     >     > Any idea why?
>     >
>     >     Nope. But the errors are unrelated to the changes in meta-virt. If the
>     >     issue persists, asking on the oe-core list is a better bet.
>     >     I'd suggest that you rm -rf tmp, and start the build again.
>     >
>     >     Bruce
>     >
>     >     >
>     >     > Regards,
>     >     > Shakthi
>     >     >
>     >     > -----Original Message-----
>     >     > From: Bruce Ashfield [mailto:bruce.ashfield@gmail.com]
>     >     > Sent: Thursday, April 05, 2018 7:44 PM
>     >     > To: Shakthi Pradeep (tpradeep) <tpradeep@cisco.com>
>     >     > Cc: meta-virtualization@yoctoproject.org
>     >     > Subject: Re: [meta-virtualization] RFT/FYI: docker/containerd/runc uprevs pushed to master
>     >     >
>     >     > On Thu, Apr 5, 2018 at 9:32 AM, Shakthi Pradeep (tpradeep) <tpradeep@cisco.com> wrote:
>     >     >> Hello Bruce,
>     >     >>
>     >     >> I am actually working on a repo from Third Party. So here things are little outdated.
>     >     >>
>     >     >> I found some info from http://git.yoctoproject.org
>     >     >>
>     >     >> I am currently using Docker 1.13.0 which was committed on 2017-01-20
>     >     >>
>     >     >> http://git.yoctoproject.org/cgit/cgit.cgi/meta-virtualization/commit/r
>     >     >> ecipes-containers/docker?id=0b631bf01487d3d1be0c91ea7749168fb3c47dcb
>     >     >>
>     >     >> I need to migrate to 18.03.0 which you committed 3 days ago
>     >     >>
>     >     >> http://git.yoctoproject.org/cgit/cgit.cgi/meta-virtualization/commit/r
>     >     >> ecipes-containers/docker?id=a5074cecf18faea1a325c8ac9220d2df41250af5
>     >     >>
>     >     >> If I take recipe from above commit and update my workspace, will all the dependencies migrate to latest automatically?
>     >     >
>     >     > Nope. You'd need to pull in all the updates that I recently pushed for the dependencies, or you'll end up with runtime errors.
>     >     > Also note, that due to the different go versions and build infrastructure in oe-core, there's no guarantee that those new recipes will build properly on an older baseline.
>     >     >
>     >     > Bruce
>     >     >
>     >     >>
>     >     >> Regards,
>     >     >> Shakthi
>     >     >>
>     >     >> -----Original Message-----
>     >     >> From: Bruce Ashfield [mailto:bruce.ashfield@gmail.com]
>     >     >> Sent: Thursday, April 05, 2018 6:46 PM
>     >     >> To: Shakthi Pradeep (tpradeep) <tpradeep@cisco.com>
>     >     >> Cc: meta-virtualization@yoctoproject.org
>     >     >> Subject: Re: [meta-virtualization] RFT/FYI: docker/containerd/runc
>     >     >> uprevs pushed to master
>     >     >>
>     >     >> root@cube-server:~# docker --version
>     >     >> Docker version 18.03.0, build 0f1bb353423e
>     >     >>
>     >     >> If you are building meta-virt master, the update should happen automatically since the PV of the updated recipe is higher than the old one. All the dependencies will follow after that.
>     >     >>
>     >     >> Bruce
>     >     >>
>     >     >> On Thu, Apr 5, 2018 at 9:02 AM, Shakthi Pradeep (tpradeep) <tpradeep@cisco.com> wrote:
>     >     >>> Hello Bruce,
>     >     >>>
>     >     >>> Which version of Docker are you running.
>     >     >>>
>     >     >>> I just noticed I am running Docker 1.13.1 which is too old.
>     >     >>>
>     >     >>> How do I migrate to latest version of Docker & also corresponding dependencies.
>     >     >>>
>     >     >>> Regards,
>     >     >>> Shakthi
>     >     >>>
>     >     >>> -----Original Message-----
>     >     >>> From: Bruce Ashfield [mailto:bruce.ashfield@gmail.com]
>     >     >>> Sent: Wednesday, April 04, 2018 6:45 PM
>     >     >>> To: Shakthi Pradeep (tpradeep) <tpradeep@cisco.com>
>     >     >>> Cc: meta-virtualization@yoctoproject.org
>     >     >>> Subject: Re: [meta-virtualization] RFT/FYI: docker/containerd/runc
>     >     >>> uprevs pushed to master
>     >     >>>
>     >     >>> Excellent news.
>     >     >>>
>     >     >>> Yes, everything is in master of meta-virtualization now. That way it will have time to soak a bit before the upcoming release.
>     >     >>>
>     >     >>> Cheers,
>     >     >>>
>     >     >>> Bruce
>     >     >>>
>     >     >>> On Wed, Apr 4, 2018 at 8:32 AM, Shakthi Pradeep (tpradeep) <tpradeep@cisco.com> wrote:
>     >     >>>> Hello Bruce,
>     >     >>>>
>     >     >>>> Yes I was missing the bbappend for kernel config. Got it working after I wrote the mail to you.
>     >     >>>>
>     >     >>>> Are your changes committed to git repo? Is it in the master branch of Yocto?
>     >     >>>>
>     >     >>>> Regards,
>     >     >>>> Shakthi
>     >     >>>>
>     >     >>>> -----Original Message-----
>     >     >>>> From: Bruce Ashfield [mailto:bruce.ashfield@gmail.com]
>     >     >>>> Sent: Wednesday, April 04, 2018 5:57 PM
>     >     >>>> To: Shakthi Pradeep (tpradeep) <tpradeep@cisco.com>
>     >     >>>> Cc: meta-virtualization@yoctoproject.org
>     >     >>>> Subject: Re: [meta-virtualization] RFT/FYI: docker/containerd/runc
>     >     >>>> uprevs pushed to master
>     >     >>>>
>     >     >>>> On Wed, Apr 4, 2018 at 12:57 AM, Shakthi Pradeep (tpradeep) <tpradeep@cisco.com> wrote:
>     >     >>>>> Hello Bruce,
>     >     >>>>>
>     >     >>>>>
>     >     >>>>>
>     >     >>>>> Timing is Perfect !!!
>     >     >>>>>
>     >     >>>>>
>     >     >>>>>
>     >     >>>>> I am currently trying to get Docker CE to work with Yocto. I could
>     >     >>>>> include the Docker executable in ISO but when I run it I get some errors.
>     >     >>>>>
>     >     >>>>>
>     >     >>>>>
>     >     >>>>> When I boot the image looks like Docker service start is failing
>     >     >>>>> due to missing kernel modules. Please refer attached screenshot and
>     >     >>>>> below error log.
>     >     >>>>
>     >     >>>> Do you have a bbappend for your 4.8 kernel that adds the docker configuration fragments ?
>     >     >>>>
>     >     >>>> That's the most likely reason for the issues.
>     >     >>>>
>     >     >>>> I was able to run a whole suite of tests against 4.12, 4.14 and 4.15 so those kernels + fragments are known to work.
>     >     >>>>
>     >     >>>> Bruce
>     >     >>>>
>     >     >>>>>
>     >     >>>>>
>     >     >>>>>
>     >     >>>>> * docker.service - Docker Application Container Engine
>     >     >>>>>
>     >     >>>>>    Loaded: loaded (/lib/systemd/system/docker.service; enabled;
>     >     >>>>> vendor
>     >     >>>>> preset: enabled)
>     >     >>>>>
>     >     >>>>>    Active: failed (Result: exit-code) since Tue 2018-04-03 13:17:51
>     >     >>>>> UTC; 17min ago
>     >     >>>>>
>     >     >>>>>      Docs: https://docs.docker.com
>     >     >>>>>
>     >     >>>>>   Process: 317 ExecStart=/usr/bin/dockerd -H fd:// (code=exited,
>     >     >>>>> status=1/FAILURE)
>     >     >>>>>
>     >     >>>>> Main PID: 317 (code=exited, status=1/FAILURE)
>     >     >>>>>
>     >     >>>>>
>     >     >>>>>
>     >     >>>>> Apr 03 13:17:51 intel-x86-64 dockerd[317]:
>     >     >>>>> time="2018-04-03T13:17:51.035178755Z" level=warning msg="Running
>     >     >>>>> modprobe xt_conntrack failed with message: `modprobe: WARNING:
>     >     >>>>> Module xt_conntrack not found in directory
>     >     >>>>> /lib/modules/4.8.24-WR9.0.0.10_standard`, error: exit status 1"
>     >     >>>>>
>     >     >>>>> Apr 03 13:17:51 intel-x86-64 dockerd[317]:
>     >     >>>>> time="2018-04-03T13:17:51.040727372Z" level=info msg="Firewalld running:
>     >     >>>>> false"
>     >     >>>>>
>     >     >>>>> Apr 03 13:17:51 intel-x86-64 dockerd[317]:
>     >     >>>>> time="2018-04-03T13:17:51.170575344Z" level=warning msg="Could not
>     >     >>>>> load necessary modules for IPSEC rules: Running modprobe xfrm_user
>     >     >>>>> failed with
>     >     >>>>> message: `modprobe: WARNING: Module xfrm_user not found in
>     >     >>>>> directory /lib/modules/4.8.24-WR9.0.0.10_standard`, error: exit status 1"
>     >     >>>>>
>     >     >>>>> Apr 03 13:17:51 intel-x86-64 dockerd[317]:
>     >     >>>>> time="2018-04-03T13:17:51.172397913Z" level=info msg="Default
>     >     >>>>> bridge
>     >     >>>>> (docker0) is assigned with an IP address 172.17.0.0/16. Daemon
>     >     >>>>> option --bip can be used to set a preferred IP address"
>     >     >>>>>
>     >     >>>>> Apr 03 13:17:51 intel-x86-64 dockerd[317]: Error starting daemon:
>     >     >>>>> Error initializing network controller: Error creating default "bridge" network:
>     >     >>>>> Failed to Setup IP tables: Unable to enable ACCEPT INCOMING rule:
>     >     >>>>> (iptables
>     >     >>>>> failed: iptables --wait -I FORWARD -o docker0 -m conntrack
>     >     >>>>> --ctstate RELATED,ESTABLISHED -j ACCEPT: iptables: No chain/target/match by that name.
>     >     >>>>>
>     >     >>>>> Apr 03 13:17:51 intel-x86-64 dockerd[317]:  (exit status 1))
>     >     >>>>>
>     >     >>>>> Apr 03 13:17:51 intel-x86-64 systemd[1]: docker.service: Main
>     >     >>>>> process exited, code=exited, status=1/FAILURE
>     >     >>>>>
>     >     >>>>> Apr 03 13:17:51 intel-x86-64 systemd[1]: Failed to start Docker
>     >     >>>>> Application Container Engine.
>     >     >>>>>
>     >     >>>>> Apr 03 13:17:51 intel-x86-64 systemd[1]: docker.service: Unit
>     >     >>>>> entered failed state.
>     >     >>>>>
>     >     >>>>> Apr 03 13:17:51 intel-x86-64 systemd[1]: docker.service: Failed
>     >     >>>>> with result 'exit-code'.
>     >     >>>>>
>     >     >>>>>
>     >     >>>>>
>     >     >>>>> Regards,
>     >     >>>>>
>     >     >>>>> Shakthi
>     >     >>>>>
>     >     >>>>>
>     >     >>>>>
>     >     >>>>> -----Original Message-----
>     >     >>>>> From: meta-virtualization-bounces@yoctoproject.org
>     >     >>>>> [mailto:meta-virtualization-bounces@yoctoproject.org] On Behalf Of
>     >     >>>>> Bruce Ashfield
>     >     >>>>> Sent: Wednesday, April 04, 2018 8:44 AM
>     >     >>>>> To: meta-virtualization@yoctoproject.org
>     >     >>>>> Subject: [meta-virtualization] RFT/FYI: docker/containerd/runc
>     >     >>>>> uprevs pushed to master
>     >     >>>>>
>     >     >>>>>
>     >     >>>>>
>     >     >>>>> Hi all,
>     >     >>>>>
>     >     >>>>>
>     >     >>>>>
>     >     >>>>> After spending a few days de-tangling the
>     >     >>>>> moby/docker/runc/containerd and oe-core go infrastructure changes,
>     >     >>>>> I was able to run docker/runc/containerd through a system/stress test and everything seems to be working.
>     >     >>>>>
>     >     >>>>>
>     >     >>>>>
>     >     >>>>> There were a few regressions that I worked through, as well as
>     >     >>>>> build/packaging changes, but I'm no longer seeing any issues and
>     >     >>>>> all the patches/functionality have been carried forward.
>     >     >>>>>
>     >     >>>>>
>     >     >>>>>
>     >     >>>>> One thing of note is that the docker and open containers containerd
>     >     >>>>> split/fork is no longer an issue, so I've modified the default to
>     >     >>>>> be the opencontainers variant. Similarly, the docker and
>     >     >>>>> opencontainers runc are very similar. I've kept both variants of
>     >     >>>>> both recipes for now, since I'd like to track things for a bit
>     >     >>>>> longer before declaring the split unnecessary.
>     >     >>>>>
>     >     >>>>>
>     >     >>>>>
>     >     >>>>> Also for those that care, I created a reference docker-ce recipe
>     >     >>>>> that tracks the docker-ce repo versus the components themselves.
>     >     >>>>> Right now it is reference only, since it needs a bit more work, but
>     >     >>>>> I wanted to get it out there, in case someone really cares about
>     >     >>>>> docker-ce (I don't really, but someone might!).
>     >     >>>>>
>     >     >>>>>
>     >     >>>>>
>     >     >>>>> Summary: I just pushed the following changes to master:
>     >     >>>>>
>     >     >>>>>
>     >     >>>>>
>     >     >>>>>   d7d310ae4113 meta-virt: prefer containerd-opencontainers
>     >     >>>>>
>     >     >>>>>   935e3d969ef1 containerd: uprev to v1.0.2
>     >     >>>>>
>     >     >>>>>   f5fbfa8ac4db docker-ce: introduce reference recipe/build
>     >     >>>>>
>     >     >>>>>   a5074cecf18f docker: uprev to 18.03.0
>     >     >>>>>
>     >     >>>>>   e3d960f4fcd9 runc: uprev to 1.0.0-rc5
>     >     >>>>>
>     >     >>>>>
>     >     >>>>>
>     >     >>>>> If anyone sees regressions, build or architecture issues .. report
>     >     >>>>> them to me (and the list) and we'll get them fixed up.
>     >     >>>>>
>     >     >>>>>
>     >     >>>>>
>     >     >>>>> Cheers,
>     >     >>>>>
>     >     >>>>>
>     >     >>>>>
>     >     >>>>> Bruce
>     >     >>>>>
>     >     >>>>>
>     >     >>>>>
>     >     >>>>> --
>     >     >>>>>
>     >     >>>>> "Thou shalt not follow the NULL pointer, for chaos and madness
>     >     >>>>> await thee at its end"
>     >     >>>>>
>     >     >>>>> --
>     >     >>>>>
>     >     >>>>> _______________________________________________
>     >     >>>>>
>     >     >>>>> meta-virtualization mailing list
>     >     >>>>>
>     >     >>>>> meta-virtualization@yoctoproject.org
>     >     >>>>>
>     >     >>>>> https://lists.yoctoproject.org/listinfo/meta-virtualization
>     >     >>>>
>     >     >>>>
>     >     >>>>
>     >     >>>> --
>     >     >>>> "Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end"
>     >     >>>
>     >     >>>
>     >     >>>
>     >     >>> --
>     >     >>> "Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end"
>     >     >>
>     >     >>
>     >     >>
>     >     >> --
>     >     >> "Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end"
>     >     >
>     >     >
>     >     >
>     >     > --
>     >     > "Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end"
>     >
>     >
>     >
>     >     --
>     >     "Thou shalt not follow the NULL pointer, for chaos and madness await
>     >     thee at its end"
>     >
>     >
>
>
>
>     --
>     "Thou shalt not follow the NULL pointer, for chaos and madness await
>     thee at its end"
>
>



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"

Re: RFT/FYI: docker/containerd/runc uprevs pushed to master

[Shakthi Pradeep (tpradeep)]

Hello Bruce,

Since I am having build issues with master branch I am back to rocko branch.

With rocko branch when I use –p option with Docker, I was getting following error “iptables: No chain/target/match by that name.”

root@genericx86-64:~# docker run -itd --name svo -p 10000:8080 svo supervisord -n
52416b288a255361de6e0e09e78055627d898e44cc6b9839430bb2e48b5c5324
docker: Error response from daemon: driver failed programming external connectivity on endpoint svo (b5a9bed9b9825027ce02fa603b5daa3d4220953404f8d3efbda4ab5f0ac49138):  (iptables failed: iptables --wait -t nat -A DOCKER -p tcp -d 0/0 --dport 10000 -j DNAT --to-destination 172.17.0.2:8080 ! -i docker0: iptables: No chain/target/match by that name.
 (exit status 1)).

This was due to missing LKM, xt_nat & x_tables. With this bundled in the final iso I could solve above problem. Now I am hitting another error

Below is the complete list of modules

root@genericx86-64:/mnt# lsmod
Module                  Size  Used by
xt_tcpudp              16384  0
ipt_MASQUERADE         16384  1
nf_nat_masquerade_ipv4    16384  1 ipt_MASQUERADE
iptable_nat            16384  1
nf_conntrack_ipv4      16384  3
nf_defrag_ipv4         16384  1 nf_conntrack_ipv4
nf_nat_ipv4            16384  1 iptable_nat
iptable_filter         16384  1
ip_tables              24576  2 iptable_filter,iptable_nat
bridge                106496  0
stp                    16384  1 bridge
llc                    16384  2 bridge,stp
xt_nat                 16384  0
nf_nat                 24576  3 xt_nat,nf_nat_masquerade_ipv4,nf_nat_ipv4
xt_conntrack           16384  1
nf_conntrack           86016  7 xt_nat,nf_conntrack_ipv4,ipt_MASQUERADE,nf_nat_masquerade_ipv4,xt_conntrack,nf_nat_ipv4,nf_nat
libcrc32c              16384  2 nf_conntrack,nf_nat
xt_addrtype            16384  2
x_tables               28672  7 xt_nat,ip_tables,iptable_filter,xt_tcpudp,ipt_MASQUERADE,xt_addrtype,xt_conntrack
root@genericx86-64:/mnt#

Regards,
Shakthi

On 09/04/18, 7:49 PM, "Bruce Ashfield" <bruce.ashfield@gmail.com> wrote:

    Sure, but none of them are docker.
    
    Bruce
    
    On Mon, Apr 9, 2018 at 9:46 AM, Shakthi Pradeep (tpradeep)
    <tpradeep@cisco.com> wrote:
    > Hello Bruce,
    >
    > I see pkg_postinst_${PN}() are part of below recipes….
    >
    > TPRADEEP-M-91HW:meta-virtualization tpradeep$ grep -r postinst *
    > recipes-containers/singularity/singularity_git.bb:pkg_postinst_${PN}() {
    > recipes-containers/lxc/lxc_2.0.8.bb:pkg_postinst_${PN}() {
    > recipes-containers/lxc/lxc_2.0.8.bb:pkg_postinst_${PN}-networking() {
    > recipes-extended/xen/xen.inc:pkg_postinst_${PN}-volatiles() {
    > recipes-extended/libvirt/libvirt_1.3.5.bb:pkg_postinst_libvirt() {
    > recipes-networking/openvswitch/openvswitch.inc:# rdeps.  E.g. ovs-pki calls sed in the postinstall.  sed may be
    > recipes-networking/openvswitch/openvswitch.inc:pkg_postinst_${PN}-pki () {
    > recipes-networking/openvswitch/openvswitch.inc:pkg_postinst_${PN}-testcontroller () {
    >
    > Regards,
    > Shakthi
    >
    > On 09/04/18, 6:47 PM, "Bruce Ashfield" <bruce.ashfield@gmail.com> wrote:
    >
    >     On Mon, Apr 9, 2018 at 4:37 AM, Shakthi Pradeep (tpradeep)
    >     <tpradeep@cisco.com> wrote:
    >     > Hello Bruce,
    >     >
    >     > Moved to master branch of Yocto. When I build I am getting below error. What does this mean?
    >
    >     There were changes made to the way that postinstall scripts were run
    >     in the January
    >     timeframe,
    >
    >     i.e.:
    >
    >      commit 7bc55b29609765904af9f330600229e96cc044cf
    >     Author: Alexander Kanavin <alexander.kanavin@linux.intel.com>
    >     Date:   Mon Jan 29 14:01:32 2018 +0200
    >
    >         meta/lib/oe/package_manager.py: deprecate 'exit 1' as a way to
    >     defer to first boot
    >
    >         'exit 1' is not optimal for two reasons:
    >
    >         1) Code is hard to read; it is not obvious that it means 'defer
    >     what follows to first boot'.
    >         2) Worse, this hides actual errors in the scriptlets; there is no
    >     difference between scriptlet
    >         failing because it's intended to be run on target and scriptlet
    >     failing because there's a bug or
    >         a regression somewhere.
    >
    >         The new, supported way is to place the code that has to run on
    >     target into pkg_postinst_ontarget(),
    >         or, if a more fine-tuned control is required, call
    >     'postinst-intercepts defer_to_first_boot' from
    >         pkg_postinst() to explicitly request deferral to first boot.
    >
    >         (From OE-Core rev: d12cf56e9ff2a4f13dfbef9290ea5647b52b3f6d)
    >
    >         Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
    >         Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
    >
    >     :100644 100644 2a07f0e39ad6... f7e013437c91... M
    >     meta/lib/oe/package_manager.py
    >
    >     commit 6ca669105ff7f405e85142d1aa5375a8430c9606
    >     Author: Alexander Kanavin <alexander.kanavin@linux.intel.com>
    >     Date:   Mon Jan 29 14:01:31 2018 +0200
    >
    >         package.bbclass: add support for pkg_postinst_ontarget()
    >
    >         This function is a convenient and more readable shortcut for situations
    >         when the postinst code always needs to run on target. All commands that
    >         cannot be executed during cross-install and can only be run on target
    >         should go into this function. They will only be executed on first boot
    >         (if package was cross-installed) or immediately during package installation
    >         on target.
    >
    >         Plain pkg_postinst() works as before: it is run during cross-install time,
    >         it can contain a request to defer to first boot, and it is also run
    >         during package installation on target.
    >
    >         Also fix the oeqa test for this functionality to use the new function
    >         where appropriate.
    >
    >         (From OE-Core rev: 229f4e975fb6957f44b5c56735fd6d58564098d7)
    >
    >         Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
    >         Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
    >
    >     :100644 100644 112aa08c80f8... d4bab6dcc228... M
    >     meta-selftest/recipes-test/postinst/postinst_1.0.bb
    >     :100644 100644 7dc759699f4b... 6a7f35a3e787... M
    >     meta/classes/package.bbclass
    >
    >     -------
    >
    >     But you shouldn't be getting that warning with docker, since it doesn't
    >     have a pkg_postinst_${PN}(), or related element in the recipe.
    >
    >     So something in your build is adding that postinstall action, that isn't
    >     part of the meta-virtualization layer.
    >
    >     Bruce
    >
    >
    >     >
    >     > Initialising tasks: 100% |######################################################################################################################################################| Time: 0:00:04
    >     > NOTE: Executing SetScene Tasks
    >     > NOTE: Executing RunQueue Tasks
    >     > WARNING: core-image-full-cmdline-1.0-r0 do_rootfs: Intentionally failing postinstall scriptlets of ['docker'] to defer them to first boot is deprecated. Please place them into pkg_postinst_ontarget_${PN} ().
    >     > If deferring to first boot wasn't the intent, then scriptlet failure may mean an issue in the recipe, or a regression elsewhere.
    >     > Details of the failure are in /workdir/poky/build/tmp/work/genericx86_64-poky-linux/core-image-full-cmdline/1.0-r0/temp/log.do_rootfs.
    >     > WARNING: core-image-full-cmdline-1.0-r0 do_rootfs: [log_check] core-image-full-cmdline: found 2 warning messages in the logfile:
    >     > [log_check] warning: %post(docker-18.03.0+git708b068d3095c6a6be939eb2da78c921d2e945e2-r0.core2_64) scriptlet failed, exit status 1
    >     > [log_check] WARNING: Intentionally failing postinstall scriptlets of ['docker'] to defer them to first boot is deprecated. Please place them into pkg_postinst_ontarget_${PN} ().
    >     >
    >     > Regards,
    >     > Shakthi
    >     >
    >     > On 06/04/18, 1:09 AM, "Bruce Ashfield" <bruce.ashfield@gmail.com> wrote:
    >     >
    >     >     On Thu, Apr 5, 2018 at 11:55 AM, Shakthi Pradeep (tpradeep)
    >     >     <tpradeep@cisco.com> wrote:
    >     >     > Hello Bruce,
    >     >     >
    >     >     > I pulled master branch from git://git.yoctoproject.org/poky but build fails
    >     >     >
    >     >     > When I run "bitbake core-image-full-cmdline" or "bitbake core-image-minimal" I get following error
    >     >     >
    >     >     > ERROR: Task (/nobackup/tpradeep/playground/yocto/poky/meta/recipes-kernel/linux-libc-headers/linux-libc-headers_4.15.7.bb:do_install) failed with exit code '1'
    >     >     > ERROR: Task (/nobackup/tpradeep/playground/yocto/poky/meta/recipes-devtools/autoconf-archive/autoconf-archive_2016.09.16.bb:do_install) failed with exit code '1'
    >     >     >
    >     >     > Any idea why?
    >     >
    >     >     Nope. But the errors are unrelated to the changes in meta-virt. If the
    >     >     issue persists, asking on the oe-core list is a better bet.
    >     >     I'd suggest that you rm -rf tmp, and start the build again.
    >     >
    >     >     Bruce
    >     >
    >     >     >
    >     >     > Regards,
    >     >     > Shakthi
    >     >     >
    >     >     > -----Original Message-----
    >     >     > From: Bruce Ashfield [mailto:bruce.ashfield@gmail.com]
    >     >     > Sent: Thursday, April 05, 2018 7:44 PM
    >     >     > To: Shakthi Pradeep (tpradeep) <tpradeep@cisco.com>
    >     >     > Cc: meta-virtualization@yoctoproject.org
    >     >     > Subject: Re: [meta-virtualization] RFT/FYI: docker/containerd/runc uprevs pushed to master
    >     >     >
    >     >     > On Thu, Apr 5, 2018 at 9:32 AM, Shakthi Pradeep (tpradeep) <tpradeep@cisco.com> wrote:
    >     >     >> Hello Bruce,
    >     >     >>
    >     >     >> I am actually working on a repo from Third Party. So here things are little outdated.
    >     >     >>
    >     >     >> I found some info from http://git.yoctoproject.org
    >     >     >>
    >     >     >> I am currently using Docker 1.13.0 which was committed on 2017-01-20
    >     >     >>
    >     >     >> http://git.yoctoproject.org/cgit/cgit.cgi/meta-virtualization/commit/r
    >     >     >> ecipes-containers/docker?id=0b631bf01487d3d1be0c91ea7749168fb3c47dcb
    >     >     >>
    >     >     >> I need to migrate to 18.03.0 which you committed 3 days ago
    >     >     >>
    >     >     >> http://git.yoctoproject.org/cgit/cgit.cgi/meta-virtualization/commit/r
    >     >     >> ecipes-containers/docker?id=a5074cecf18faea1a325c8ac9220d2df41250af5
    >     >     >>
    >     >     >> If I take recipe from above commit and update my workspace, will all the dependencies migrate to latest automatically?
    >     >     >
    >     >     > Nope. You'd need to pull in all the updates that I recently pushed for the dependencies, or you'll end up with runtime errors.
    >     >     > Also note, that due to the different go versions and build infrastructure in oe-core, there's no guarantee that those new recipes will build properly on an older baseline.
    >     >     >
    >     >     > Bruce
    >     >     >
    >     >     >>
    >     >     >> Regards,
    >     >     >> Shakthi
    >     >     >>
    >     >     >> -----Original Message-----
    >     >     >> From: Bruce Ashfield [mailto:bruce.ashfield@gmail.com]
    >     >     >> Sent: Thursday, April 05, 2018 6:46 PM
    >     >     >> To: Shakthi Pradeep (tpradeep) <tpradeep@cisco.com>
    >     >     >> Cc: meta-virtualization@yoctoproject.org
    >     >     >> Subject: Re: [meta-virtualization] RFT/FYI: docker/containerd/runc
    >     >     >> uprevs pushed to master
    >     >     >>
    >     >     >> root@cube-server:~# docker --version
    >     >     >> Docker version 18.03.0, build 0f1bb353423e
    >     >     >>
    >     >     >> If you are building meta-virt master, the update should happen automatically since the PV of the updated recipe is higher than the old one. All the dependencies will follow after that.
    >     >     >>
    >     >     >> Bruce
    >     >     >>
    >     >     >> On Thu, Apr 5, 2018 at 9:02 AM, Shakthi Pradeep (tpradeep) <tpradeep@cisco.com> wrote:
    >     >     >>> Hello Bruce,
    >     >     >>>
    >     >     >>> Which version of Docker are you running.
    >     >     >>>
    >     >     >>> I just noticed I am running Docker 1.13.1 which is too old.
    >     >     >>>
    >     >     >>> How do I migrate to latest version of Docker & also corresponding dependencies.
    >     >     >>>
    >     >     >>> Regards,
    >     >     >>> Shakthi
    >     >     >>>
    >     >     >>> -----Original Message-----
    >     >     >>> From: Bruce Ashfield [mailto:bruce.ashfield@gmail.com]
    >     >     >>> Sent: Wednesday, April 04, 2018 6:45 PM
    >     >     >>> To: Shakthi Pradeep (tpradeep) <tpradeep@cisco.com>
    >     >     >>> Cc: meta-virtualization@yoctoproject.org
    >     >     >>> Subject: Re: [meta-virtualization] RFT/FYI: docker/containerd/runc
    >     >     >>> uprevs pushed to master
    >     >     >>>
    >     >     >>> Excellent news.
    >     >     >>>
    >     >     >>> Yes, everything is in master of meta-virtualization now. That way it will have time to soak a bit before the upcoming release.
    >     >     >>>
    >     >     >>> Cheers,
    >     >     >>>
    >     >     >>> Bruce
    >     >     >>>
    >     >     >>> On Wed, Apr 4, 2018 at 8:32 AM, Shakthi Pradeep (tpradeep) <tpradeep@cisco.com> wrote:
    >     >     >>>> Hello Bruce,
    >     >     >>>>
    >     >     >>>> Yes I was missing the bbappend for kernel config. Got it working after I wrote the mail to you.
    >     >     >>>>
    >     >     >>>> Are your changes committed to git repo? Is it in the master branch of Yocto?
    >     >     >>>>
    >     >     >>>> Regards,
    >     >     >>>> Shakthi
    >     >     >>>>
    >     >     >>>> -----Original Message-----
    >     >     >>>> From: Bruce Ashfield [mailto:bruce.ashfield@gmail.com]
    >     >     >>>> Sent: Wednesday, April 04, 2018 5:57 PM
    >     >     >>>> To: Shakthi Pradeep (tpradeep) <tpradeep@cisco.com>
    >     >     >>>> Cc: meta-virtualization@yoctoproject.org
    >     >     >>>> Subject: Re: [meta-virtualization] RFT/FYI: docker/containerd/runc
    >     >     >>>> uprevs pushed to master
    >     >     >>>>
    >     >     >>>> On Wed, Apr 4, 2018 at 12:57 AM, Shakthi Pradeep (tpradeep) <tpradeep@cisco.com> wrote:
    >     >     >>>>> Hello Bruce,
    >     >     >>>>>
    >     >     >>>>>
    >     >     >>>>>
    >     >     >>>>> Timing is Perfect !!!
    >     >     >>>>>
    >     >     >>>>>
    >     >     >>>>>
    >     >     >>>>> I am currently trying to get Docker CE to work with Yocto. I could
    >     >     >>>>> include the Docker executable in ISO but when I run it I get some errors.
    >     >     >>>>>
    >     >     >>>>>
    >     >     >>>>>
    >     >     >>>>> When I boot the image looks like Docker service start is failing
    >     >     >>>>> due to missing kernel modules. Please refer attached screenshot and
    >     >     >>>>> below error log.
    >     >     >>>>
    >     >     >>>> Do you have a bbappend for your 4.8 kernel that adds the docker configuration fragments ?
    >     >     >>>>
    >     >     >>>> That's the most likely reason for the issues.
    >     >     >>>>
    >     >     >>>> I was able to run a whole suite of tests against 4.12, 4.14 and 4.15 so those kernels + fragments are known to work.
    >     >     >>>>
    >     >     >>>> Bruce
    >     >     >>>>
    >     >     >>>>>
    >     >     >>>>>
    >     >     >>>>>
    >     >     >>>>> * docker.service - Docker Application Container Engine
    >     >     >>>>>
    >     >     >>>>>    Loaded: loaded (/lib/systemd/system/docker.service; enabled;
    >     >     >>>>> vendor
    >     >     >>>>> preset: enabled)
    >     >     >>>>>
    >     >     >>>>>    Active: failed (Result: exit-code) since Tue 2018-04-03 13:17:51
    >     >     >>>>> UTC; 17min ago
    >     >     >>>>>
    >     >     >>>>>      Docs: https://docs.docker.com
    >     >     >>>>>
    >     >     >>>>>   Process: 317 ExecStart=/usr/bin/dockerd -H fd:// (code=exited,
    >     >     >>>>> status=1/FAILURE)
    >     >     >>>>>
    >     >     >>>>> Main PID: 317 (code=exited, status=1/FAILURE)
    >     >     >>>>>
    >     >     >>>>>
    >     >     >>>>>
    >     >     >>>>> Apr 03 13:17:51 intel-x86-64 dockerd[317]:
    >     >     >>>>> time="2018-04-03T13:17:51.035178755Z" level=warning msg="Running
    >     >     >>>>> modprobe xt_conntrack failed with message: `modprobe: WARNING:
    >     >     >>>>> Module xt_conntrack not found in directory
    >     >     >>>>> /lib/modules/4.8.24-WR9.0.0.10_standard`, error: exit status 1"
    >     >     >>>>>
    >     >     >>>>> Apr 03 13:17:51 intel-x86-64 dockerd[317]:
    >     >     >>>>> time="2018-04-03T13:17:51.040727372Z" level=info msg="Firewalld running:
    >     >     >>>>> false"
    >     >     >>>>>
    >     >     >>>>> Apr 03 13:17:51 intel-x86-64 dockerd[317]:
    >     >     >>>>> time="2018-04-03T13:17:51.170575344Z" level=warning msg="Could not
    >     >     >>>>> load necessary modules for IPSEC rules: Running modprobe xfrm_user
    >     >     >>>>> failed with
    >     >     >>>>> message: `modprobe: WARNING: Module xfrm_user not found in
    >     >     >>>>> directory /lib/modules/4.8.24-WR9.0.0.10_standard`, error: exit status 1"
    >     >     >>>>>
    >     >     >>>>> Apr 03 13:17:51 intel-x86-64 dockerd[317]:
    >     >     >>>>> time="2018-04-03T13:17:51.172397913Z" level=info msg="Default
    >     >     >>>>> bridge
    >     >     >>>>> (docker0) is assigned with an IP address 172.17.0.0/16. Daemon
    >     >     >>>>> option --bip can be used to set a preferred IP address"
    >     >     >>>>>
    >     >     >>>>> Apr 03 13:17:51 intel-x86-64 dockerd[317]: Error starting daemon:
    >     >     >>>>> Error initializing network controller: Error creating default "bridge" network:
    >     >     >>>>> Failed to Setup IP tables: Unable to enable ACCEPT INCOMING rule:
    >     >     >>>>> (iptables
    >     >     >>>>> failed: iptables --wait -I FORWARD -o docker0 -m conntrack
    >     >     >>>>> --ctstate RELATED,ESTABLISHED -j ACCEPT: iptables: No chain/target/match by that name.
    >     >     >>>>>
    >     >     >>>>> Apr 03 13:17:51 intel-x86-64 dockerd[317]:  (exit status 1))
    >     >     >>>>>
    >     >     >>>>> Apr 03 13:17:51 intel-x86-64 systemd[1]: docker.service: Main
    >     >     >>>>> process exited, code=exited, status=1/FAILURE
    >     >     >>>>>
    >     >     >>>>> Apr 03 13:17:51 intel-x86-64 systemd[1]: Failed to start Docker
    >     >     >>>>> Application Container Engine.
    >     >     >>>>>
    >     >     >>>>> Apr 03 13:17:51 intel-x86-64 systemd[1]: docker.service: Unit
    >     >     >>>>> entered failed state.
    >     >     >>>>>
    >     >     >>>>> Apr 03 13:17:51 intel-x86-64 systemd[1]: docker.service: Failed
    >     >     >>>>> with result 'exit-code'.
    >     >     >>>>>
    >     >     >>>>>
    >     >     >>>>>
    >     >     >>>>> Regards,
    >     >     >>>>>
    >     >     >>>>> Shakthi
    >     >     >>>>>
    >     >     >>>>>
    >     >     >>>>>
    >     >     >>>>> -----Original Message-----
    >     >     >>>>> From: meta-virtualization-bounces@yoctoproject.org
    >     >     >>>>> [mailto:meta-virtualization-bounces@yoctoproject.org] On Behalf Of
    >     >     >>>>> Bruce Ashfield
    >     >     >>>>> Sent: Wednesday, April 04, 2018 8:44 AM
    >     >     >>>>> To: meta-virtualization@yoctoproject.org
    >     >     >>>>> Subject: [meta-virtualization] RFT/FYI: docker/containerd/runc
    >     >     >>>>> uprevs pushed to master
    >     >     >>>>>
    >     >     >>>>>
    >     >     >>>>>
    >     >     >>>>> Hi all,
    >     >     >>>>>
    >     >     >>>>>
    >     >     >>>>>
    >     >     >>>>> After spending a few days de-tangling the
    >     >     >>>>> moby/docker/runc/containerd and oe-core go infrastructure changes,
    >     >     >>>>> I was able to run docker/runc/containerd through a system/stress test and everything seems to be working.
    >     >     >>>>>
    >     >     >>>>>
    >     >     >>>>>
    >     >     >>>>> There were a few regressions that I worked through, as well as
    >     >     >>>>> build/packaging changes, but I'm no longer seeing any issues and
    >     >     >>>>> all the patches/functionality have been carried forward.
    >     >     >>>>>
    >     >     >>>>>
    >     >     >>>>>
    >     >     >>>>> One thing of note is that the docker and open containers containerd
    >     >     >>>>> split/fork is no longer an issue, so I've modified the default to
    >     >     >>>>> be the opencontainers variant. Similarly, the docker and
    >     >     >>>>> opencontainers runc are very similar. I've kept both variants of
    >     >     >>>>> both recipes for now, since I'd like to track things for a bit
    >     >     >>>>> longer before declaring the split unnecessary.
    >     >     >>>>>
    >     >     >>>>>
    >     >     >>>>>
    >     >     >>>>> Also for those that care, I created a reference docker-ce recipe
    >     >     >>>>> that tracks the docker-ce repo versus the components themselves.
    >     >     >>>>> Right now it is reference only, since it needs a bit more work, but
    >     >     >>>>> I wanted to get it out there, in case someone really cares about
    >     >     >>>>> docker-ce (I don't really, but someone might!).
    >     >     >>>>>
    >     >     >>>>>
    >     >     >>>>>
    >     >     >>>>> Summary: I just pushed the following changes to master:
    >     >     >>>>>
    >     >     >>>>>
    >     >     >>>>>
    >     >     >>>>>   d7d310ae4113 meta-virt: prefer containerd-opencontainers
    >     >     >>>>>
    >     >     >>>>>   935e3d969ef1 containerd: uprev to v1.0.2
    >     >     >>>>>
    >     >     >>>>>   f5fbfa8ac4db docker-ce: introduce reference recipe/build
    >     >     >>>>>
    >     >     >>>>>   a5074cecf18f docker: uprev to 18.03.0
    >     >     >>>>>
    >     >     >>>>>   e3d960f4fcd9 runc: uprev to 1.0.0-rc5
    >     >     >>>>>
    >     >     >>>>>
    >     >     >>>>>
    >     >     >>>>> If anyone sees regressions, build or architecture issues .. report
    >     >     >>>>> them to me (and the list) and we'll get them fixed up.
    >     >     >>>>>
    >     >     >>>>>
    >     >     >>>>>
    >     >     >>>>> Cheers,
    >     >     >>>>>
    >     >     >>>>>
    >     >     >>>>>
    >     >     >>>>> Bruce
    >     >     >>>>>
    >     >     >>>>>
    >     >     >>>>>
    >     >     >>>>> --
    >     >     >>>>>
    >     >     >>>>> "Thou shalt not follow the NULL pointer, for chaos and madness
    >     >     >>>>> await thee at its end"
    >     >     >>>>>
    >     >     >>>>> --
    >     >     >>>>>
    >     >     >>>>> _______________________________________________
    >     >     >>>>>
    >     >     >>>>> meta-virtualization mailing list
    >     >     >>>>>
    >     >     >>>>> meta-virtualization@yoctoproject.org
    >     >     >>>>>
    >     >     >>>>> https://lists.yoctoproject.org/listinfo/meta-virtualization
    >     >     >>>>
    >     >     >>>>
    >     >     >>>>
    >     >     >>>> --
    >     >     >>>> "Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end"
    >     >     >>>
    >     >     >>>
    >     >     >>>
    >     >     >>> --
    >     >     >>> "Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end"
    >     >     >>
    >     >     >>
    >     >     >>
    >     >     >> --
    >     >     >> "Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end"
    >     >     >
    >     >     >
    >     >     >
    >     >     > --
    >     >     > "Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end"
    >     >
    >     >
    >     >
    >     >     --
    >     >     "Thou shalt not follow the NULL pointer, for chaos and madness await
    >     >     thee at its end"
    >     >
    >     >
    >
    >
    >
    >     --
    >     "Thou shalt not follow the NULL pointer, for chaos and madness await
    >     thee at its end"
    >
    >
    
    
    
    -- 
    "Thou shalt not follow the NULL pointer, for chaos and madness await
    thee at its end"
    

Re: RFT/FYI: docker/containerd/runc uprevs pushed to master

[Shakthi Pradeep (tpradeep)]

Hello Bruce,

Could you try running Docker with –p option. After solving the iptables issue, I am hitting another issue.

Now exec of /usr/bin/docker-proxy gives “no such file or directory” error

root@genericx86-64:/mnt# docker run -itd --name svo -p 10000:8080 svo supervisord -n
29bd8de9dd028888f5f060cb42240762e28dd07cdfa91185fa49953c3da28c36
docker: Error response from daemon: driver failed programming external connectivity on endpoint svo (6397cfd4d4e69099c609c8a933e35418a0bf30c1acb4e3b0ebad55668e099fa1): fork/exec /usr/bin/docker-proxy: no such file or directory.

root@genericx86-64:/mnt# which /usr/bin/docker-proxy
/usr/bin/docker-proxy

root@genericx86-64:/mnt# ldd /usr/bin/docker-proxy
	linux-vdso.so.1 (0x00007ffd1bbf3000)
	libpthread.so.0 => /lib/libpthread.so.0 (0x0000003267a00000)
	libc.so.6 => /lib/libc.so.6 (0x0000003267600000)
	/lib64/ld-linux-x86-64.so.2 => /lib/ld-linux-x86-64.so.2 (0x00007f0c9e5dc000)
root@genericx86-64:/mnt#

Regards,
Shakthi

On 11/04/18, 8:15 PM, "Shakthi Pradeep (tpradeep)" <tpradeep@cisco.com> wrote:

    Hello Bruce,
    
    Since I am having build issues with master branch I am back to rocko branch.
    
    With rocko branch when I use –p option with Docker, I was getting following error “iptables: No chain/target/match by that name.”
    
    root@genericx86-64:~# docker run -itd --name svo -p 10000:8080 svo supervisord -n
    52416b288a255361de6e0e09e78055627d898e44cc6b9839430bb2e48b5c5324
    docker: Error response from daemon: driver failed programming external connectivity on endpoint svo (b5a9bed9b9825027ce02fa603b5daa3d4220953404f8d3efbda4ab5f0ac49138):  (iptables failed: iptables --wait -t nat -A DOCKER -p tcp -d 0/0 --dport 10000 -j DNAT --to-destination 172.17.0.2:8080 ! -i docker0: iptables: No chain/target/match by that name.
     (exit status 1)).
    
    This was due to missing LKM, xt_nat & x_tables. With this bundled in the final iso I could solve above problem. Now I am hitting another error
    
    Below is the complete list of modules
    
    root@genericx86-64:/mnt# lsmod
    Module                  Size  Used by
    xt_tcpudp              16384  0
    ipt_MASQUERADE         16384  1
    nf_nat_masquerade_ipv4    16384  1 ipt_MASQUERADE
    iptable_nat            16384  1
    nf_conntrack_ipv4      16384  3
    nf_defrag_ipv4         16384  1 nf_conntrack_ipv4
    nf_nat_ipv4            16384  1 iptable_nat
    iptable_filter         16384  1
    ip_tables              24576  2 iptable_filter,iptable_nat
    bridge                106496  0
    stp                    16384  1 bridge
    llc                    16384  2 bridge,stp
    xt_nat                 16384  0
    nf_nat                 24576  3 xt_nat,nf_nat_masquerade_ipv4,nf_nat_ipv4
    xt_conntrack           16384  1
    nf_conntrack           86016  7 xt_nat,nf_conntrack_ipv4,ipt_MASQUERADE,nf_nat_masquerade_ipv4,xt_conntrack,nf_nat_ipv4,nf_nat
    libcrc32c              16384  2 nf_conntrack,nf_nat
    xt_addrtype            16384  2
    x_tables               28672  7 xt_nat,ip_tables,iptable_filter,xt_tcpudp,ipt_MASQUERADE,xt_addrtype,xt_conntrack
    root@genericx86-64:/mnt#
    
    Regards,
    Shakthi
    
    On 09/04/18, 7:49 PM, "Bruce Ashfield" <bruce.ashfield@gmail.com> wrote:
    
        Sure, but none of them are docker.
        
        Bruce
        
        On Mon, Apr 9, 2018 at 9:46 AM, Shakthi Pradeep (tpradeep)
        <tpradeep@cisco.com> wrote:
        > Hello Bruce,
        >
        > I see pkg_postinst_${PN}() are part of below recipes….
        >
        > TPRADEEP-M-91HW:meta-virtualization tpradeep$ grep -r postinst *
        > recipes-containers/singularity/singularity_git.bb:pkg_postinst_${PN}() {
        > recipes-containers/lxc/lxc_2.0.8.bb:pkg_postinst_${PN}() {
        > recipes-containers/lxc/lxc_2.0.8.bb:pkg_postinst_${PN}-networking() {
        > recipes-extended/xen/xen.inc:pkg_postinst_${PN}-volatiles() {
        > recipes-extended/libvirt/libvirt_1.3.5.bb:pkg_postinst_libvirt() {
        > recipes-networking/openvswitch/openvswitch.inc:# rdeps.  E.g. ovs-pki calls sed in the postinstall.  sed may be
        > recipes-networking/openvswitch/openvswitch.inc:pkg_postinst_${PN}-pki () {
        > recipes-networking/openvswitch/openvswitch.inc:pkg_postinst_${PN}-testcontroller () {
        >
        > Regards,
        > Shakthi
        >
        > On 09/04/18, 6:47 PM, "Bruce Ashfield" <bruce.ashfield@gmail.com> wrote:
        >
        >     On Mon, Apr 9, 2018 at 4:37 AM, Shakthi Pradeep (tpradeep)
        >     <tpradeep@cisco.com> wrote:
        >     > Hello Bruce,
        >     >
        >     > Moved to master branch of Yocto. When I build I am getting below error. What does this mean?
        >
        >     There were changes made to the way that postinstall scripts were run
        >     in the January
        >     timeframe,
        >
        >     i.e.:
        >
        >      commit 7bc55b29609765904af9f330600229e96cc044cf
        >     Author: Alexander Kanavin <alexander.kanavin@linux.intel.com>
        >     Date:   Mon Jan 29 14:01:32 2018 +0200
        >
        >         meta/lib/oe/package_manager.py: deprecate 'exit 1' as a way to
        >     defer to first boot
        >
        >         'exit 1' is not optimal for two reasons:
        >
        >         1) Code is hard to read; it is not obvious that it means 'defer
        >     what follows to first boot'.
        >         2) Worse, this hides actual errors in the scriptlets; there is no
        >     difference between scriptlet
        >         failing because it's intended to be run on target and scriptlet
        >     failing because there's a bug or
        >         a regression somewhere.
        >
        >         The new, supported way is to place the code that has to run on
        >     target into pkg_postinst_ontarget(),
        >         or, if a more fine-tuned control is required, call
        >     'postinst-intercepts defer_to_first_boot' from
        >         pkg_postinst() to explicitly request deferral to first boot.
        >
        >         (From OE-Core rev: d12cf56e9ff2a4f13dfbef9290ea5647b52b3f6d)
        >
        >         Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
        >         Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
        >
        >     :100644 100644 2a07f0e39ad6... f7e013437c91... M
        >     meta/lib/oe/package_manager.py
        >
        >     commit 6ca669105ff7f405e85142d1aa5375a8430c9606
        >     Author: Alexander Kanavin <alexander.kanavin@linux.intel.com>
        >     Date:   Mon Jan 29 14:01:31 2018 +0200
        >
        >         package.bbclass: add support for pkg_postinst_ontarget()
        >
        >         This function is a convenient and more readable shortcut for situations
        >         when the postinst code always needs to run on target. All commands that
        >         cannot be executed during cross-install and can only be run on target
        >         should go into this function. They will only be executed on first boot
        >         (if package was cross-installed) or immediately during package installation
        >         on target.
        >
        >         Plain pkg_postinst() works as before: it is run during cross-install time,
        >         it can contain a request to defer to first boot, and it is also run
        >         during package installation on target.
        >
        >         Also fix the oeqa test for this functionality to use the new function
        >         where appropriate.
        >
        >         (From OE-Core rev: 229f4e975fb6957f44b5c56735fd6d58564098d7)
        >
        >         Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
        >         Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
        >
        >     :100644 100644 112aa08c80f8... d4bab6dcc228... M
        >     meta-selftest/recipes-test/postinst/postinst_1.0.bb
        >     :100644 100644 7dc759699f4b... 6a7f35a3e787... M
        >     meta/classes/package.bbclass
        >
        >     -------
        >
        >     But you shouldn't be getting that warning with docker, since it doesn't
        >     have a pkg_postinst_${PN}(), or related element in the recipe.
        >
        >     So something in your build is adding that postinstall action, that isn't
        >     part of the meta-virtualization layer.
        >
        >     Bruce
        >
        >
        >     >
        >     > Initialising tasks: 100% |######################################################################################################################################################| Time: 0:00:04
        >     > NOTE: Executing SetScene Tasks
        >     > NOTE: Executing RunQueue Tasks
        >     > WARNING: core-image-full-cmdline-1.0-r0 do_rootfs: Intentionally failing postinstall scriptlets of ['docker'] to defer them to first boot is deprecated. Please place them into pkg_postinst_ontarget_${PN} ().
        >     > If deferring to first boot wasn't the intent, then scriptlet failure may mean an issue in the recipe, or a regression elsewhere.
        >     > Details of the failure are in /workdir/poky/build/tmp/work/genericx86_64-poky-linux/core-image-full-cmdline/1.0-r0/temp/log.do_rootfs.
        >     > WARNING: core-image-full-cmdline-1.0-r0 do_rootfs: [log_check] core-image-full-cmdline: found 2 warning messages in the logfile:
        >     > [log_check] warning: %post(docker-18.03.0+git708b068d3095c6a6be939eb2da78c921d2e945e2-r0.core2_64) scriptlet failed, exit status 1
        >     > [log_check] WARNING: Intentionally failing postinstall scriptlets of ['docker'] to defer them to first boot is deprecated. Please place them into pkg_postinst_ontarget_${PN} ().
        >     >
        >     > Regards,
        >     > Shakthi
        >     >
        >     > On 06/04/18, 1:09 AM, "Bruce Ashfield" <bruce.ashfield@gmail.com> wrote:
        >     >
        >     >     On Thu, Apr 5, 2018 at 11:55 AM, Shakthi Pradeep (tpradeep)
        >     >     <tpradeep@cisco.com> wrote:
        >     >     > Hello Bruce,
        >     >     >
        >     >     > I pulled master branch from git://git.yoctoproject.org/poky but build fails
        >     >     >
        >     >     > When I run "bitbake core-image-full-cmdline" or "bitbake core-image-minimal" I get following error
        >     >     >
        >     >     > ERROR: Task (/nobackup/tpradeep/playground/yocto/poky/meta/recipes-kernel/linux-libc-headers/linux-libc-headers_4.15.7.bb:do_install) failed with exit code '1'
        >     >     > ERROR: Task (/nobackup/tpradeep/playground/yocto/poky/meta/recipes-devtools/autoconf-archive/autoconf-archive_2016.09.16.bb:do_install) failed with exit code '1'
        >     >     >
        >     >     > Any idea why?
        >     >
        >     >     Nope. But the errors are unrelated to the changes in meta-virt. If the
        >     >     issue persists, asking on the oe-core list is a better bet.
        >     >     I'd suggest that you rm -rf tmp, and start the build again.
        >     >
        >     >     Bruce
        >     >
        >     >     >
        >     >     > Regards,
        >     >     > Shakthi
        >     >     >
        >     >     > -----Original Message-----
        >     >     > From: Bruce Ashfield [mailto:bruce.ashfield@gmail.com]
        >     >     > Sent: Thursday, April 05, 2018 7:44 PM
        >     >     > To: Shakthi Pradeep (tpradeep) <tpradeep@cisco.com>
        >     >     > Cc: meta-virtualization@yoctoproject.org
        >     >     > Subject: Re: [meta-virtualization] RFT/FYI: docker/containerd/runc uprevs pushed to master
        >     >     >
        >     >     > On Thu, Apr 5, 2018 at 9:32 AM, Shakthi Pradeep (tpradeep) <tpradeep@cisco.com> wrote:
        >     >     >> Hello Bruce,
        >     >     >>
        >     >     >> I am actually working on a repo from Third Party. So here things are little outdated.
        >     >     >>
        >     >     >> I found some info from http://git.yoctoproject.org
        >     >     >>
        >     >     >> I am currently using Docker 1.13.0 which was committed on 2017-01-20
        >     >     >>
        >     >     >> http://git.yoctoproject.org/cgit/cgit.cgi/meta-virtualization/commit/r
        >     >     >> ecipes-containers/docker?id=0b631bf01487d3d1be0c91ea7749168fb3c47dcb
        >     >     >>
        >     >     >> I need to migrate to 18.03.0 which you committed 3 days ago
        >     >     >>
        >     >     >> http://git.yoctoproject.org/cgit/cgit.cgi/meta-virtualization/commit/r
        >     >     >> ecipes-containers/docker?id=a5074cecf18faea1a325c8ac9220d2df41250af5
        >     >     >>
        >     >     >> If I take recipe from above commit and update my workspace, will all the dependencies migrate to latest automatically?
        >     >     >
        >     >     > Nope. You'd need to pull in all the updates that I recently pushed for the dependencies, or you'll end up with runtime errors.
        >     >     > Also note, that due to the different go versions and build infrastructure in oe-core, there's no guarantee that those new recipes will build properly on an older baseline.
        >     >     >
        >     >     > Bruce
        >     >     >
        >     >     >>
        >     >     >> Regards,
        >     >     >> Shakthi
        >     >     >>
        >     >     >> -----Original Message-----
        >     >     >> From: Bruce Ashfield [mailto:bruce.ashfield@gmail.com]
        >     >     >> Sent: Thursday, April 05, 2018 6:46 PM
        >     >     >> To: Shakthi Pradeep (tpradeep) <tpradeep@cisco.com>
        >     >     >> Cc: meta-virtualization@yoctoproject.org
        >     >     >> Subject: Re: [meta-virtualization] RFT/FYI: docker/containerd/runc
        >     >     >> uprevs pushed to master
        >     >     >>
        >     >     >> root@cube-server:~# docker --version
        >     >     >> Docker version 18.03.0, build 0f1bb353423e
        >     >     >>
        >     >     >> If you are building meta-virt master, the update should happen automatically since the PV of the updated recipe is higher than the old one. All the dependencies will follow after that.
        >     >     >>
        >     >     >> Bruce
        >     >     >>
        >     >     >> On Thu, Apr 5, 2018 at 9:02 AM, Shakthi Pradeep (tpradeep) <tpradeep@cisco.com> wrote:
        >     >     >>> Hello Bruce,
        >     >     >>>
        >     >     >>> Which version of Docker are you running.
        >     >     >>>
        >     >     >>> I just noticed I am running Docker 1.13.1 which is too old.
        >     >     >>>
        >     >     >>> How do I migrate to latest version of Docker & also corresponding dependencies.
        >     >     >>>
        >     >     >>> Regards,
        >     >     >>> Shakthi
        >     >     >>>
        >     >     >>> -----Original Message-----
        >     >     >>> From: Bruce Ashfield [mailto:bruce.ashfield@gmail.com]
        >     >     >>> Sent: Wednesday, April 04, 2018 6:45 PM
        >     >     >>> To: Shakthi Pradeep (tpradeep) <tpradeep@cisco.com>
        >     >     >>> Cc: meta-virtualization@yoctoproject.org
        >     >     >>> Subject: Re: [meta-virtualization] RFT/FYI: docker/containerd/runc
        >     >     >>> uprevs pushed to master
        >     >     >>>
        >     >     >>> Excellent news.
        >     >     >>>
        >     >     >>> Yes, everything is in master of meta-virtualization now. That way it will have time to soak a bit before the upcoming release.
        >     >     >>>
        >     >     >>> Cheers,
        >     >     >>>
        >     >     >>> Bruce
        >     >     >>>
        >     >     >>> On Wed, Apr 4, 2018 at 8:32 AM, Shakthi Pradeep (tpradeep) <tpradeep@cisco.com> wrote:
        >     >     >>>> Hello Bruce,
        >     >     >>>>
        >     >     >>>> Yes I was missing the bbappend for kernel config. Got it working after I wrote the mail to you.
        >     >     >>>>
        >     >     >>>> Are your changes committed to git repo? Is it in the master branch of Yocto?
        >     >     >>>>
        >     >     >>>> Regards,
        >     >     >>>> Shakthi
        >     >     >>>>
        >     >     >>>> -----Original Message-----
        >     >     >>>> From: Bruce Ashfield [mailto:bruce.ashfield@gmail.com]
        >     >     >>>> Sent: Wednesday, April 04, 2018 5:57 PM
        >     >     >>>> To: Shakthi Pradeep (tpradeep) <tpradeep@cisco.com>
        >     >     >>>> Cc: meta-virtualization@yoctoproject.org
        >     >     >>>> Subject: Re: [meta-virtualization] RFT/FYI: docker/containerd/runc
        >     >     >>>> uprevs pushed to master
        >     >     >>>>
        >     >     >>>> On Wed, Apr 4, 2018 at 12:57 AM, Shakthi Pradeep (tpradeep) <tpradeep@cisco.com> wrote:
        >     >     >>>>> Hello Bruce,
        >     >     >>>>>
        >     >     >>>>>
        >     >     >>>>>
        >     >     >>>>> Timing is Perfect !!!
        >     >     >>>>>
        >     >     >>>>>
        >     >     >>>>>
        >     >     >>>>> I am currently trying to get Docker CE to work with Yocto. I could
        >     >     >>>>> include the Docker executable in ISO but when I run it I get some errors.
        >     >     >>>>>
        >     >     >>>>>
        >     >     >>>>>
        >     >     >>>>> When I boot the image looks like Docker service start is failing
        >     >     >>>>> due to missing kernel modules. Please refer attached screenshot and
        >     >     >>>>> below error log.
        >     >     >>>>
        >     >     >>>> Do you have a bbappend for your 4.8 kernel that adds the docker configuration fragments ?
        >     >     >>>>
        >     >     >>>> That's the most likely reason for the issues.
        >     >     >>>>
        >     >     >>>> I was able to run a whole suite of tests against 4.12, 4.14 and 4.15 so those kernels + fragments are known to work.
        >     >     >>>>
        >     >     >>>> Bruce
        >     >     >>>>
        >     >     >>>>>
        >     >     >>>>>
        >     >     >>>>>
        >     >     >>>>> * docker.service - Docker Application Container Engine
        >     >     >>>>>
        >     >     >>>>>    Loaded: loaded (/lib/systemd/system/docker.service; enabled;
        >     >     >>>>> vendor
        >     >     >>>>> preset: enabled)
        >     >     >>>>>
        >     >     >>>>>    Active: failed (Result: exit-code) since Tue 2018-04-03 13:17:51
        >     >     >>>>> UTC; 17min ago
        >     >     >>>>>
        >     >     >>>>>      Docs: https://docs.docker.com
        >     >     >>>>>
        >     >     >>>>>   Process: 317 ExecStart=/usr/bin/dockerd -H fd:// (code=exited,
        >     >     >>>>> status=1/FAILURE)
        >     >     >>>>>
        >     >     >>>>> Main PID: 317 (code=exited, status=1/FAILURE)
        >     >     >>>>>
        >     >     >>>>>
        >     >     >>>>>
        >     >     >>>>> Apr 03 13:17:51 intel-x86-64 dockerd[317]:
        >     >     >>>>> time="2018-04-03T13:17:51.035178755Z" level=warning msg="Running
        >     >     >>>>> modprobe xt_conntrack failed with message: `modprobe: WARNING:
        >     >     >>>>> Module xt_conntrack not found in directory
        >     >     >>>>> /lib/modules/4.8.24-WR9.0.0.10_standard`, error: exit status 1"
        >     >     >>>>>
        >     >     >>>>> Apr 03 13:17:51 intel-x86-64 dockerd[317]:
        >     >     >>>>> time="2018-04-03T13:17:51.040727372Z" level=info msg="Firewalld running:
        >     >     >>>>> false"
        >     >     >>>>>
        >     >     >>>>> Apr 03 13:17:51 intel-x86-64 dockerd[317]:
        >     >     >>>>> time="2018-04-03T13:17:51.170575344Z" level=warning msg="Could not
        >     >     >>>>> load necessary modules for IPSEC rules: Running modprobe xfrm_user
        >     >     >>>>> failed with
        >     >     >>>>> message: `modprobe: WARNING: Module xfrm_user not found in
        >     >     >>>>> directory /lib/modules/4.8.24-WR9.0.0.10_standard`, error: exit status 1"
        >     >     >>>>>
        >     >     >>>>> Apr 03 13:17:51 intel-x86-64 dockerd[317]:
        >     >     >>>>> time="2018-04-03T13:17:51.172397913Z" level=info msg="Default
        >     >     >>>>> bridge
        >     >     >>>>> (docker0) is assigned with an IP address 172.17.0.0/16. Daemon
        >     >     >>>>> option --bip can be used to set a preferred IP address"
        >     >     >>>>>
        >     >     >>>>> Apr 03 13:17:51 intel-x86-64 dockerd[317]: Error starting daemon:
        >     >     >>>>> Error initializing network controller: Error creating default "bridge" network:
        >     >     >>>>> Failed to Setup IP tables: Unable to enable ACCEPT INCOMING rule:
        >     >     >>>>> (iptables
        >     >     >>>>> failed: iptables --wait -I FORWARD -o docker0 -m conntrack
        >     >     >>>>> --ctstate RELATED,ESTABLISHED -j ACCEPT: iptables: No chain/target/match by that name.
        >     >     >>>>>
        >     >     >>>>> Apr 03 13:17:51 intel-x86-64 dockerd[317]:  (exit status 1))
        >     >     >>>>>
        >     >     >>>>> Apr 03 13:17:51 intel-x86-64 systemd[1]: docker.service: Main
        >     >     >>>>> process exited, code=exited, status=1/FAILURE
        >     >     >>>>>
        >     >     >>>>> Apr 03 13:17:51 intel-x86-64 systemd[1]: Failed to start Docker
        >     >     >>>>> Application Container Engine.
        >     >     >>>>>
        >     >     >>>>> Apr 03 13:17:51 intel-x86-64 systemd[1]: docker.service: Unit
        >     >     >>>>> entered failed state.
        >     >     >>>>>
        >     >     >>>>> Apr 03 13:17:51 intel-x86-64 systemd[1]: docker.service: Failed
        >     >     >>>>> with result 'exit-code'.
        >     >     >>>>>
        >     >     >>>>>
        >     >     >>>>>
        >     >     >>>>> Regards,
        >     >     >>>>>
        >     >     >>>>> Shakthi
        >     >     >>>>>
        >     >     >>>>>
        >     >     >>>>>
        >     >     >>>>> -----Original Message-----
        >     >     >>>>> From: meta-virtualization-bounces@yoctoproject.org
        >     >     >>>>> [mailto:meta-virtualization-bounces@yoctoproject.org] On Behalf Of
        >     >     >>>>> Bruce Ashfield
        >     >     >>>>> Sent: Wednesday, April 04, 2018 8:44 AM
        >     >     >>>>> To: meta-virtualization@yoctoproject.org
        >     >     >>>>> Subject: [meta-virtualization] RFT/FYI: docker/containerd/runc
        >     >     >>>>> uprevs pushed to master
        >     >     >>>>>
        >     >     >>>>>
        >     >     >>>>>
        >     >     >>>>> Hi all,
        >     >     >>>>>
        >     >     >>>>>
        >     >     >>>>>
        >     >     >>>>> After spending a few days de-tangling the
        >     >     >>>>> moby/docker/runc/containerd and oe-core go infrastructure changes,
        >     >     >>>>> I was able to run docker/runc/containerd through a system/stress test and everything seems to be working.
        >     >     >>>>>
        >     >     >>>>>
        >     >     >>>>>
        >     >     >>>>> There were a few regressions that I worked through, as well as
        >     >     >>>>> build/packaging changes, but I'm no longer seeing any issues and
        >     >     >>>>> all the patches/functionality have been carried forward.
        >     >     >>>>>
        >     >     >>>>>
        >     >     >>>>>
        >     >     >>>>> One thing of note is that the docker and open containers containerd
        >     >     >>>>> split/fork is no longer an issue, so I've modified the default to
        >     >     >>>>> be the opencontainers variant. Similarly, the docker and
        >     >     >>>>> opencontainers runc are very similar. I've kept both variants of
        >     >     >>>>> both recipes for now, since I'd like to track things for a bit
        >     >     >>>>> longer before declaring the split unnecessary.
        >     >     >>>>>
        >     >     >>>>>
        >     >     >>>>>
        >     >     >>>>> Also for those that care, I created a reference docker-ce recipe
        >     >     >>>>> that tracks the docker-ce repo versus the components themselves.
        >     >     >>>>> Right now it is reference only, since it needs a bit more work, but
        >     >     >>>>> I wanted to get it out there, in case someone really cares about
        >     >     >>>>> docker-ce (I don't really, but someone might!).
        >     >     >>>>>
        >     >     >>>>>
        >     >     >>>>>
        >     >     >>>>> Summary: I just pushed the following changes to master:
        >     >     >>>>>
        >     >     >>>>>
        >     >     >>>>>
        >     >     >>>>>   d7d310ae4113 meta-virt: prefer containerd-opencontainers
        >     >     >>>>>
        >     >     >>>>>   935e3d969ef1 containerd: uprev to v1.0.2
        >     >     >>>>>
        >     >     >>>>>   f5fbfa8ac4db docker-ce: introduce reference recipe/build
        >     >     >>>>>
        >     >     >>>>>   a5074cecf18f docker: uprev to 18.03.0
        >     >     >>>>>
        >     >     >>>>>   e3d960f4fcd9 runc: uprev to 1.0.0-rc5
        >     >     >>>>>
        >     >     >>>>>
        >     >     >>>>>
        >     >     >>>>> If anyone sees regressions, build or architecture issues .. report
        >     >     >>>>> them to me (and the list) and we'll get them fixed up.
        >     >     >>>>>
        >     >     >>>>>
        >     >     >>>>>
        >     >     >>>>> Cheers,
        >     >     >>>>>
        >     >     >>>>>
        >     >     >>>>>
        >     >     >>>>> Bruce
        >     >     >>>>>
        >     >     >>>>>
        >     >     >>>>>
        >     >     >>>>> --
        >     >     >>>>>
        >     >     >>>>> "Thou shalt not follow the NULL pointer, for chaos and madness
        >     >     >>>>> await thee at its end"
        >     >     >>>>>
        >     >     >>>>> --
        >     >     >>>>>
        >     >     >>>>> _______________________________________________
        >     >     >>>>>
        >     >     >>>>> meta-virtualization mailing list
        >     >     >>>>>
        >     >     >>>>> meta-virtualization@yoctoproject.org
        >     >     >>>>>
        >     >     >>>>> https://lists.yoctoproject.org/listinfo/meta-virtualization
        >     >     >>>>
        >     >     >>>>
        >     >     >>>>
        >     >     >>>> --
        >     >     >>>> "Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end"
        >     >     >>>
        >     >     >>>
        >     >     >>>
        >     >     >>> --
        >     >     >>> "Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end"
        >     >     >>
        >     >     >>
        >     >     >>
        >     >     >> --
        >     >     >> "Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end"
        >     >     >
        >     >     >
        >     >     >
        >     >     > --
        >     >     > "Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end"
        >     >
        >     >
        >     >
        >     >     --
        >     >     "Thou shalt not follow the NULL pointer, for chaos and madness await
        >     >     thee at its end"
        >     >
        >     >
        >
        >
        >
        >     --
        >     "Thou shalt not follow the NULL pointer, for chaos and madness await
        >     thee at its end"
        >
        >
        
        
        
        -- 
        "Thou shalt not follow the NULL pointer, for chaos and madness await
        thee at its end"
        
    
    

Re: RFT/FYI: docker/containerd/runc uprevs pushed to master

[Shakthi Pradeep (tpradeep)]

Hello Bruce,

Found the problem…

docker-proxy was linked against /lib64/ld-linux-x86-64.so.2 while docker & dockerd are linked against /lib/ld-linux-x86-64.so

/lib64/ld-linux-x86-64.so.2 did not exist in the Yocto build nor was there a symbolic link to /lib/ld-linux-x86-64.so

After creating /lib64/ld-linux-x86-64.so.2 docker image came up fine with –p option

root@genericx86-64:/mnt# ldd /usr/bin/docker-proxy 
	linux-vdso.so.1 (0x00007ffc24bb5000)
	libpthread.so.0 => /lib/libpthread.so.0 (0x0000003ab7a00000)
	libc.so.6 => /lib/libc.so.6 (0x0000003ab7600000)
	/lib64/ld-linux-x86-64.so.2 => /lib/ld-linux-x86-64.so.2 (0x00007f9d7eeba000)

root@genericx86-64:/mnt# ldd /usr/bin/docker 
	linux-vdso.so.1 (0x00007ffcda12f000)
	libpthread.so.0 => /lib/libpthread.so.0 (0x0000003ab7a00000)
	libc.so.6 => /lib/libc.so.6 (0x0000003ab7600000)
	/lib/ld-linux-x86-64.so.2 (0x00007f8511ac0000)

root@genericx86-64:/mnt# ldd /usr/bin/dockerd  
	linux-vdso.so.1 (0x00007ffd41130000)
	libpthread.so.0 => /lib/libpthread.so.0 (0x0000003ab7a00000)
	libc.so.6 => /lib/libc.so.6 (0x0000003ab7600000)
	/lib/ld-linux-x86-64.so.2 (0x00007f848078d000)
root@genericx86-64:/mnt# 

Regards,
Shakthi

On 11/04/18, 8:20 PM, "Shakthi Pradeep (tpradeep)" <tpradeep@cisco.com> wrote:

    Hello Bruce,
    
    Could you try running Docker with –p option. After solving the iptables issue, I am hitting another issue.
    
    Now exec of /usr/bin/docker-proxy gives “no such file or directory” error
    
    root@genericx86-64:/mnt# docker run -itd --name svo -p 10000:8080 svo supervisord -n
    29bd8de9dd028888f5f060cb42240762e28dd07cdfa91185fa49953c3da28c36
    docker: Error response from daemon: driver failed programming external connectivity on endpoint svo (6397cfd4d4e69099c609c8a933e35418a0bf30c1acb4e3b0ebad55668e099fa1): fork/exec /usr/bin/docker-proxy: no such file or directory.
    
    root@genericx86-64:/mnt# which /usr/bin/docker-proxy
    /usr/bin/docker-proxy
    
    root@genericx86-64:/mnt# ldd /usr/bin/docker-proxy
    	linux-vdso.so.1 (0x00007ffd1bbf3000)
    	libpthread.so.0 => /lib/libpthread.so.0 (0x0000003267a00000)
    	libc.so.6 => /lib/libc.so.6 (0x0000003267600000)
    	/lib64/ld-linux-x86-64.so.2 => /lib/ld-linux-x86-64.so.2 (0x00007f0c9e5dc000)
    root@genericx86-64:/mnt#
    
    Regards,
    Shakthi
    
    On 11/04/18, 8:15 PM, "Shakthi Pradeep (tpradeep)" <tpradeep@cisco.com> wrote:
    
        Hello Bruce,
        
        Since I am having build issues with master branch I am back to rocko branch.
        
        With rocko branch when I use –p option with Docker, I was getting following error “iptables: No chain/target/match by that name.”
        
        root@genericx86-64:~# docker run -itd --name svo -p 10000:8080 svo supervisord -n
        52416b288a255361de6e0e09e78055627d898e44cc6b9839430bb2e48b5c5324
        docker: Error response from daemon: driver failed programming external connectivity on endpoint svo (b5a9bed9b9825027ce02fa603b5daa3d4220953404f8d3efbda4ab5f0ac49138):  (iptables failed: iptables --wait -t nat -A DOCKER -p tcp -d 0/0 --dport 10000 -j DNAT --to-destination 172.17.0.2:8080 ! -i docker0: iptables: No chain/target/match by that name.
         (exit status 1)).
        
        This was due to missing LKM, xt_nat & x_tables. With this bundled in the final iso I could solve above problem. Now I am hitting another error
        
        Below is the complete list of modules
        
        root@genericx86-64:/mnt# lsmod
        Module                  Size  Used by
        xt_tcpudp              16384  0
        ipt_MASQUERADE         16384  1
        nf_nat_masquerade_ipv4    16384  1 ipt_MASQUERADE
        iptable_nat            16384  1
        nf_conntrack_ipv4      16384  3
        nf_defrag_ipv4         16384  1 nf_conntrack_ipv4
        nf_nat_ipv4            16384  1 iptable_nat
        iptable_filter         16384  1
        ip_tables              24576  2 iptable_filter,iptable_nat
        bridge                106496  0
        stp                    16384  1 bridge
        llc                    16384  2 bridge,stp
        xt_nat                 16384  0
        nf_nat                 24576  3 xt_nat,nf_nat_masquerade_ipv4,nf_nat_ipv4
        xt_conntrack           16384  1
        nf_conntrack           86016  7 xt_nat,nf_conntrack_ipv4,ipt_MASQUERADE,nf_nat_masquerade_ipv4,xt_conntrack,nf_nat_ipv4,nf_nat
        libcrc32c              16384  2 nf_conntrack,nf_nat
        xt_addrtype            16384  2
        x_tables               28672  7 xt_nat,ip_tables,iptable_filter,xt_tcpudp,ipt_MASQUERADE,xt_addrtype,xt_conntrack
        root@genericx86-64:/mnt#
        
        Regards,
        Shakthi
        
        On 09/04/18, 7:49 PM, "Bruce Ashfield" <bruce.ashfield@gmail.com> wrote:
        
            Sure, but none of them are docker.
            
            Bruce
            
            On Mon, Apr 9, 2018 at 9:46 AM, Shakthi Pradeep (tpradeep)
            <tpradeep@cisco.com> wrote:
            > Hello Bruce,
            >
            > I see pkg_postinst_${PN}() are part of below recipes….
            >
            > TPRADEEP-M-91HW:meta-virtualization tpradeep$ grep -r postinst *
            > recipes-containers/singularity/singularity_git.bb:pkg_postinst_${PN}() {
            > recipes-containers/lxc/lxc_2.0.8.bb:pkg_postinst_${PN}() {
            > recipes-containers/lxc/lxc_2.0.8.bb:pkg_postinst_${PN}-networking() {
            > recipes-extended/xen/xen.inc:pkg_postinst_${PN}-volatiles() {
            > recipes-extended/libvirt/libvirt_1.3.5.bb:pkg_postinst_libvirt() {
            > recipes-networking/openvswitch/openvswitch.inc:# rdeps.  E.g. ovs-pki calls sed in the postinstall.  sed may be
            > recipes-networking/openvswitch/openvswitch.inc:pkg_postinst_${PN}-pki () {
            > recipes-networking/openvswitch/openvswitch.inc:pkg_postinst_${PN}-testcontroller () {
            >
            > Regards,
            > Shakthi
            >
            > On 09/04/18, 6:47 PM, "Bruce Ashfield" <bruce.ashfield@gmail.com> wrote:
            >
            >     On Mon, Apr 9, 2018 at 4:37 AM, Shakthi Pradeep (tpradeep)
            >     <tpradeep@cisco.com> wrote:
            >     > Hello Bruce,
            >     >
            >     > Moved to master branch of Yocto. When I build I am getting below error. What does this mean?
            >
            >     There were changes made to the way that postinstall scripts were run
            >     in the January
            >     timeframe,
            >
            >     i.e.:
            >
            >      commit 7bc55b29609765904af9f330600229e96cc044cf
            >     Author: Alexander Kanavin <alexander.kanavin@linux.intel.com>
            >     Date:   Mon Jan 29 14:01:32 2018 +0200
            >
            >         meta/lib/oe/package_manager.py: deprecate 'exit 1' as a way to
            >     defer to first boot
            >
            >         'exit 1' is not optimal for two reasons:
            >
            >         1) Code is hard to read; it is not obvious that it means 'defer
            >     what follows to first boot'.
            >         2) Worse, this hides actual errors in the scriptlets; there is no
            >     difference between scriptlet
            >         failing because it's intended to be run on target and scriptlet
            >     failing because there's a bug or
            >         a regression somewhere.
            >
            >         The new, supported way is to place the code that has to run on
            >     target into pkg_postinst_ontarget(),
            >         or, if a more fine-tuned control is required, call
            >     'postinst-intercepts defer_to_first_boot' from
            >         pkg_postinst() to explicitly request deferral to first boot.
            >
            >         (From OE-Core rev: d12cf56e9ff2a4f13dfbef9290ea5647b52b3f6d)
            >
            >         Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
            >         Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
            >
            >     :100644 100644 2a07f0e39ad6... f7e013437c91... M
            >     meta/lib/oe/package_manager.py
            >
            >     commit 6ca669105ff7f405e85142d1aa5375a8430c9606
            >     Author: Alexander Kanavin <alexander.kanavin@linux.intel.com>
            >     Date:   Mon Jan 29 14:01:31 2018 +0200
            >
            >         package.bbclass: add support for pkg_postinst_ontarget()
            >
            >         This function is a convenient and more readable shortcut for situations
            >         when the postinst code always needs to run on target. All commands that
            >         cannot be executed during cross-install and can only be run on target
            >         should go into this function. They will only be executed on first boot
            >         (if package was cross-installed) or immediately during package installation
            >         on target.
            >
            >         Plain pkg_postinst() works as before: it is run during cross-install time,
            >         it can contain a request to defer to first boot, and it is also run
            >         during package installation on target.
            >
            >         Also fix the oeqa test for this functionality to use the new function
            >         where appropriate.
            >
            >         (From OE-Core rev: 229f4e975fb6957f44b5c56735fd6d58564098d7)
            >
            >         Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
            >         Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
            >
            >     :100644 100644 112aa08c80f8... d4bab6dcc228... M
            >     meta-selftest/recipes-test/postinst/postinst_1.0.bb
            >     :100644 100644 7dc759699f4b... 6a7f35a3e787... M
            >     meta/classes/package.bbclass
            >
            >     -------
            >
            >     But you shouldn't be getting that warning with docker, since it doesn't
            >     have a pkg_postinst_${PN}(), or related element in the recipe.
            >
            >     So something in your build is adding that postinstall action, that isn't
            >     part of the meta-virtualization layer.
            >
            >     Bruce
            >
            >
            >     >
            >     > Initialising tasks: 100% |######################################################################################################################################################| Time: 0:00:04
            >     > NOTE: Executing SetScene Tasks
            >     > NOTE: Executing RunQueue Tasks
            >     > WARNING: core-image-full-cmdline-1.0-r0 do_rootfs: Intentionally failing postinstall scriptlets of ['docker'] to defer them to first boot is deprecated. Please place them into pkg_postinst_ontarget_${PN} ().
            >     > If deferring to first boot wasn't the intent, then scriptlet failure may mean an issue in the recipe, or a regression elsewhere.
            >     > Details of the failure are in /workdir/poky/build/tmp/work/genericx86_64-poky-linux/core-image-full-cmdline/1.0-r0/temp/log.do_rootfs.
            >     > WARNING: core-image-full-cmdline-1.0-r0 do_rootfs: [log_check] core-image-full-cmdline: found 2 warning messages in the logfile:
            >     > [log_check] warning: %post(docker-18.03.0+git708b068d3095c6a6be939eb2da78c921d2e945e2-r0.core2_64) scriptlet failed, exit status 1
            >     > [log_check] WARNING: Intentionally failing postinstall scriptlets of ['docker'] to defer them to first boot is deprecated. Please place them into pkg_postinst_ontarget_${PN} ().
            >     >
            >     > Regards,
            >     > Shakthi
            >     >
            >     > On 06/04/18, 1:09 AM, "Bruce Ashfield" <bruce.ashfield@gmail.com> wrote:
            >     >
            >     >     On Thu, Apr 5, 2018 at 11:55 AM, Shakthi Pradeep (tpradeep)
            >     >     <tpradeep@cisco.com> wrote:
            >     >     > Hello Bruce,
            >     >     >
            >     >     > I pulled master branch from git://git.yoctoproject.org/poky but build fails
            >     >     >
            >     >     > When I run "bitbake core-image-full-cmdline" or "bitbake core-image-minimal" I get following error
            >     >     >
            >     >     > ERROR: Task (/nobackup/tpradeep/playground/yocto/poky/meta/recipes-kernel/linux-libc-headers/linux-libc-headers_4.15.7.bb:do_install) failed with exit code '1'
            >     >     > ERROR: Task (/nobackup/tpradeep/playground/yocto/poky/meta/recipes-devtools/autoconf-archive/autoconf-archive_2016.09.16.bb:do_install) failed with exit code '1'
            >     >     >
            >     >     > Any idea why?
            >     >
            >     >     Nope. But the errors are unrelated to the changes in meta-virt. If the
            >     >     issue persists, asking on the oe-core list is a better bet.
            >     >     I'd suggest that you rm -rf tmp, and start the build again.
            >     >
            >     >     Bruce
            >     >
            >     >     >
            >     >     > Regards,
            >     >     > Shakthi
            >     >     >
            >     >     > -----Original Message-----
            >     >     > From: Bruce Ashfield [mailto:bruce.ashfield@gmail.com]
            >     >     > Sent: Thursday, April 05, 2018 7:44 PM
            >     >     > To: Shakthi Pradeep (tpradeep) <tpradeep@cisco.com>
            >     >     > Cc: meta-virtualization@yoctoproject.org
            >     >     > Subject: Re: [meta-virtualization] RFT/FYI: docker/containerd/runc uprevs pushed to master
            >     >     >
            >     >     > On Thu, Apr 5, 2018 at 9:32 AM, Shakthi Pradeep (tpradeep) <tpradeep@cisco.com> wrote:
            >     >     >> Hello Bruce,
            >     >     >>
            >     >     >> I am actually working on a repo from Third Party. So here things are little outdated.
            >     >     >>
            >     >     >> I found some info from http://git.yoctoproject.org
            >     >     >>
            >     >     >> I am currently using Docker 1.13.0 which was committed on 2017-01-20
            >     >     >>
            >     >     >> http://git.yoctoproject.org/cgit/cgit.cgi/meta-virtualization/commit/r
            >     >     >> ecipes-containers/docker?id=0b631bf01487d3d1be0c91ea7749168fb3c47dcb
            >     >     >>
            >     >     >> I need to migrate to 18.03.0 which you committed 3 days ago
            >     >     >>
            >     >     >> http://git.yoctoproject.org/cgit/cgit.cgi/meta-virtualization/commit/r
            >     >     >> ecipes-containers/docker?id=a5074cecf18faea1a325c8ac9220d2df41250af5
            >     >     >>
            >     >     >> If I take recipe from above commit and update my workspace, will all the dependencies migrate to latest automatically?
            >     >     >
            >     >     > Nope. You'd need to pull in all the updates that I recently pushed for the dependencies, or you'll end up with runtime errors.
            >     >     > Also note, that due to the different go versions and build infrastructure in oe-core, there's no guarantee that those new recipes will build properly on an older baseline.
            >     >     >
            >     >     > Bruce
            >     >     >
            >     >     >>
            >     >     >> Regards,
            >     >     >> Shakthi
            >     >     >>
            >     >     >> -----Original Message-----
            >     >     >> From: Bruce Ashfield [mailto:bruce.ashfield@gmail.com]
            >     >     >> Sent: Thursday, April 05, 2018 6:46 PM
            >     >     >> To: Shakthi Pradeep (tpradeep) <tpradeep@cisco.com>
            >     >     >> Cc: meta-virtualization@yoctoproject.org
            >     >     >> Subject: Re: [meta-virtualization] RFT/FYI: docker/containerd/runc
            >     >     >> uprevs pushed to master
            >     >     >>
            >     >     >> root@cube-server:~# docker --version
            >     >     >> Docker version 18.03.0, build 0f1bb353423e
            >     >     >>
            >     >     >> If you are building meta-virt master, the update should happen automatically since the PV of the updated recipe is higher than the old one. All the dependencies will follow after that.
            >     >     >>
            >     >     >> Bruce
            >     >     >>
            >     >     >> On Thu, Apr 5, 2018 at 9:02 AM, Shakthi Pradeep (tpradeep) <tpradeep@cisco.com> wrote:
            >     >     >>> Hello Bruce,
            >     >     >>>
            >     >     >>> Which version of Docker are you running.
            >     >     >>>
            >     >     >>> I just noticed I am running Docker 1.13.1 which is too old.
            >     >     >>>
            >     >     >>> How do I migrate to latest version of Docker & also corresponding dependencies.
            >     >     >>>
            >     >     >>> Regards,
            >     >     >>> Shakthi
            >     >     >>>
            >     >     >>> -----Original Message-----
            >     >     >>> From: Bruce Ashfield [mailto:bruce.ashfield@gmail.com]
            >     >     >>> Sent: Wednesday, April 04, 2018 6:45 PM
            >     >     >>> To: Shakthi Pradeep (tpradeep) <tpradeep@cisco.com>
            >     >     >>> Cc: meta-virtualization@yoctoproject.org
            >     >     >>> Subject: Re: [meta-virtualization] RFT/FYI: docker/containerd/runc
            >     >     >>> uprevs pushed to master
            >     >     >>>
            >     >     >>> Excellent news.
            >     >     >>>
            >     >     >>> Yes, everything is in master of meta-virtualization now. That way it will have time to soak a bit before the upcoming release.
            >     >     >>>
            >     >     >>> Cheers,
            >     >     >>>
            >     >     >>> Bruce
            >     >     >>>
            >     >     >>> On Wed, Apr 4, 2018 at 8:32 AM, Shakthi Pradeep (tpradeep) <tpradeep@cisco.com> wrote:
            >     >     >>>> Hello Bruce,
            >     >     >>>>
            >     >     >>>> Yes I was missing the bbappend for kernel config. Got it working after I wrote the mail to you.
            >     >     >>>>
            >     >     >>>> Are your changes committed to git repo? Is it in the master branch of Yocto?
            >     >     >>>>
            >     >     >>>> Regards,
            >     >     >>>> Shakthi
            >     >     >>>>
            >     >     >>>> -----Original Message-----
            >     >     >>>> From: Bruce Ashfield [mailto:bruce.ashfield@gmail.com]
            >     >     >>>> Sent: Wednesday, April 04, 2018 5:57 PM
            >     >     >>>> To: Shakthi Pradeep (tpradeep) <tpradeep@cisco.com>
            >     >     >>>> Cc: meta-virtualization@yoctoproject.org
            >     >     >>>> Subject: Re: [meta-virtualization] RFT/FYI: docker/containerd/runc
            >     >     >>>> uprevs pushed to master
            >     >     >>>>
            >     >     >>>> On Wed, Apr 4, 2018 at 12:57 AM, Shakthi Pradeep (tpradeep) <tpradeep@cisco.com> wrote:
            >     >     >>>>> Hello Bruce,
            >     >     >>>>>
            >     >     >>>>>
            >     >     >>>>>
            >     >     >>>>> Timing is Perfect !!!
            >     >     >>>>>
            >     >     >>>>>
            >     >     >>>>>
            >     >     >>>>> I am currently trying to get Docker CE to work with Yocto. I could
            >     >     >>>>> include the Docker executable in ISO but when I run it I get some errors.
            >     >     >>>>>
            >     >     >>>>>
            >     >     >>>>>
            >     >     >>>>> When I boot the image looks like Docker service start is failing
            >     >     >>>>> due to missing kernel modules. Please refer attached screenshot and
            >     >     >>>>> below error log.
            >     >     >>>>
            >     >     >>>> Do you have a bbappend for your 4.8 kernel that adds the docker configuration fragments ?
            >     >     >>>>
            >     >     >>>> That's the most likely reason for the issues.
            >     >     >>>>
            >     >     >>>> I was able to run a whole suite of tests against 4.12, 4.14 and 4.15 so those kernels + fragments are known to work.
            >     >     >>>>
            >     >     >>>> Bruce
            >     >     >>>>
            >     >     >>>>>
            >     >     >>>>>
            >     >     >>>>>
            >     >     >>>>> * docker.service - Docker Application Container Engine
            >     >     >>>>>
            >     >     >>>>>    Loaded: loaded (/lib/systemd/system/docker.service; enabled;
            >     >     >>>>> vendor
            >     >     >>>>> preset: enabled)
            >     >     >>>>>
            >     >     >>>>>    Active: failed (Result: exit-code) since Tue 2018-04-03 13:17:51
            >     >     >>>>> UTC; 17min ago
            >     >     >>>>>
            >     >     >>>>>      Docs: https://docs.docker.com
            >     >     >>>>>
            >     >     >>>>>   Process: 317 ExecStart=/usr/bin/dockerd -H fd:// (code=exited,
            >     >     >>>>> status=1/FAILURE)
            >     >     >>>>>
            >     >     >>>>> Main PID: 317 (code=exited, status=1/FAILURE)
            >     >     >>>>>
            >     >     >>>>>
            >     >     >>>>>
            >     >     >>>>> Apr 03 13:17:51 intel-x86-64 dockerd[317]:
            >     >     >>>>> time="2018-04-03T13:17:51.035178755Z" level=warning msg="Running
            >     >     >>>>> modprobe xt_conntrack failed with message: `modprobe: WARNING:
            >     >     >>>>> Module xt_conntrack not found in directory
            >     >     >>>>> /lib/modules/4.8.24-WR9.0.0.10_standard`, error: exit status 1"
            >     >     >>>>>
            >     >     >>>>> Apr 03 13:17:51 intel-x86-64 dockerd[317]:
            >     >     >>>>> time="2018-04-03T13:17:51.040727372Z" level=info msg="Firewalld running:
            >     >     >>>>> false"
            >     >     >>>>>
            >     >     >>>>> Apr 03 13:17:51 intel-x86-64 dockerd[317]:
            >     >     >>>>> time="2018-04-03T13:17:51.170575344Z" level=warning msg="Could not
            >     >     >>>>> load necessary modules for IPSEC rules: Running modprobe xfrm_user
            >     >     >>>>> failed with
            >     >     >>>>> message: `modprobe: WARNING: Module xfrm_user not found in
            >     >     >>>>> directory /lib/modules/4.8.24-WR9.0.0.10_standard`, error: exit status 1"
            >     >     >>>>>
            >     >     >>>>> Apr 03 13:17:51 intel-x86-64 dockerd[317]:
            >     >     >>>>> time="2018-04-03T13:17:51.172397913Z" level=info msg="Default
            >     >     >>>>> bridge
            >     >     >>>>> (docker0) is assigned with an IP address 172.17.0.0/16. Daemon
            >     >     >>>>> option --bip can be used to set a preferred IP address"
            >     >     >>>>>
            >     >     >>>>> Apr 03 13:17:51 intel-x86-64 dockerd[317]: Error starting daemon:
            >     >     >>>>> Error initializing network controller: Error creating default "bridge" network:
            >     >     >>>>> Failed to Setup IP tables: Unable to enable ACCEPT INCOMING rule:
            >     >     >>>>> (iptables
            >     >     >>>>> failed: iptables --wait -I FORWARD -o docker0 -m conntrack
            >     >     >>>>> --ctstate RELATED,ESTABLISHED -j ACCEPT: iptables: No chain/target/match by that name.
            >     >     >>>>>
            >     >     >>>>> Apr 03 13:17:51 intel-x86-64 dockerd[317]:  (exit status 1))
            >     >     >>>>>
            >     >     >>>>> Apr 03 13:17:51 intel-x86-64 systemd[1]: docker.service: Main
            >     >     >>>>> process exited, code=exited, status=1/FAILURE
            >     >     >>>>>
            >     >     >>>>> Apr 03 13:17:51 intel-x86-64 systemd[1]: Failed to start Docker
            >     >     >>>>> Application Container Engine.
            >     >     >>>>>
            >     >     >>>>> Apr 03 13:17:51 intel-x86-64 systemd[1]: docker.service: Unit
            >     >     >>>>> entered failed state.
            >     >     >>>>>
            >     >     >>>>> Apr 03 13:17:51 intel-x86-64 systemd[1]: docker.service: Failed
            >     >     >>>>> with result 'exit-code'.
            >     >     >>>>>
            >     >     >>>>>
            >     >     >>>>>
            >     >     >>>>> Regards,
            >     >     >>>>>
            >     >     >>>>> Shakthi
            >     >     >>>>>
            >     >     >>>>>
            >     >     >>>>>
            >     >     >>>>> -----Original Message-----
            >     >     >>>>> From: meta-virtualization-bounces@yoctoproject.org
            >     >     >>>>> [mailto:meta-virtualization-bounces@yoctoproject.org] On Behalf Of
            >     >     >>>>> Bruce Ashfield
            >     >     >>>>> Sent: Wednesday, April 04, 2018 8:44 AM
            >     >     >>>>> To: meta-virtualization@yoctoproject.org
            >     >     >>>>> Subject: [meta-virtualization] RFT/FYI: docker/containerd/runc
            >     >     >>>>> uprevs pushed to master
            >     >     >>>>>
            >     >     >>>>>
            >     >     >>>>>
            >     >     >>>>> Hi all,
            >     >     >>>>>
            >     >     >>>>>
            >     >     >>>>>
            >     >     >>>>> After spending a few days de-tangling the
            >     >     >>>>> moby/docker/runc/containerd and oe-core go infrastructure changes,
            >     >     >>>>> I was able to run docker/runc/containerd through a system/stress test and everything seems to be working.
            >     >     >>>>>
            >     >     >>>>>
            >     >     >>>>>
            >     >     >>>>> There were a few regressions that I worked through, as well as
            >     >     >>>>> build/packaging changes, but I'm no longer seeing any issues and
            >     >     >>>>> all the patches/functionality have been carried forward.
            >     >     >>>>>
            >     >     >>>>>
            >     >     >>>>>
            >     >     >>>>> One thing of note is that the docker and open containers containerd
            >     >     >>>>> split/fork is no longer an issue, so I've modified the default to
            >     >     >>>>> be the opencontainers variant. Similarly, the docker and
            >     >     >>>>> opencontainers runc are very similar. I've kept both variants of
            >     >     >>>>> both recipes for now, since I'd like to track things for a bit
            >     >     >>>>> longer before declaring the split unnecessary.
            >     >     >>>>>
            >     >     >>>>>
            >     >     >>>>>
            >     >     >>>>> Also for those that care, I created a reference docker-ce recipe
            >     >     >>>>> that tracks the docker-ce repo versus the components themselves.
            >     >     >>>>> Right now it is reference only, since it needs a bit more work, but
            >     >     >>>>> I wanted to get it out there, in case someone really cares about
            >     >     >>>>> docker-ce (I don't really, but someone might!).
            >     >     >>>>>
            >     >     >>>>>
            >     >     >>>>>
            >     >     >>>>> Summary: I just pushed the following changes to master:
            >     >     >>>>>
            >     >     >>>>>
            >     >     >>>>>
            >     >     >>>>>   d7d310ae4113 meta-virt: prefer containerd-opencontainers
            >     >     >>>>>
            >     >     >>>>>   935e3d969ef1 containerd: uprev to v1.0.2
            >     >     >>>>>
            >     >     >>>>>   f5fbfa8ac4db docker-ce: introduce reference recipe/build
            >     >     >>>>>
            >     >     >>>>>   a5074cecf18f docker: uprev to 18.03.0
            >     >     >>>>>
            >     >     >>>>>   e3d960f4fcd9 runc: uprev to 1.0.0-rc5
            >     >     >>>>>
            >     >     >>>>>
            >     >     >>>>>
            >     >     >>>>> If anyone sees regressions, build or architecture issues .. report
            >     >     >>>>> them to me (and the list) and we'll get them fixed up.
            >     >     >>>>>
            >     >     >>>>>
            >     >     >>>>>
            >     >     >>>>> Cheers,
            >     >     >>>>>
            >     >     >>>>>
            >     >     >>>>>
            >     >     >>>>> Bruce
            >     >     >>>>>
            >     >     >>>>>
            >     >     >>>>>
            >     >     >>>>> --
            >     >     >>>>>
            >     >     >>>>> "Thou shalt not follow the NULL pointer, for chaos and madness
            >     >     >>>>> await thee at its end"
            >     >     >>>>>
            >     >     >>>>> --
            >     >     >>>>>
            >     >     >>>>> _______________________________________________
            >     >     >>>>>
            >     >     >>>>> meta-virtualization mailing list
            >     >     >>>>>
            >     >     >>>>> meta-virtualization@yoctoproject.org
            >     >     >>>>>
            >     >     >>>>> https://lists.yoctoproject.org/listinfo/meta-virtualization
            >     >     >>>>
            >     >     >>>>
            >     >     >>>>
            >     >     >>>> --
            >     >     >>>> "Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end"
            >     >     >>>
            >     >     >>>
            >     >     >>>
            >     >     >>> --
            >     >     >>> "Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end"
            >     >     >>
            >     >     >>
            >     >     >>
            >     >     >> --
            >     >     >> "Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end"
            >     >     >
            >     >     >
            >     >     >
            >     >     > --
            >     >     > "Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end"
            >     >
            >     >
            >     >
            >     >     --
            >     >     "Thou shalt not follow the NULL pointer, for chaos and madness await
            >     >     thee at its end"
            >     >
            >     >
            >
            >
            >
            >     --
            >     "Thou shalt not follow the NULL pointer, for chaos and madness await
            >     thee at its end"
            >
            >
            
            
            
            -- 
            "Thou shalt not follow the NULL pointer, for chaos and madness await
            thee at its end"
            
        
        
    
    

Re: RFT/FYI: docker/containerd/runc uprevs pushed to master

[Bruce Ashfield]

On Thu, Apr 12, 2018 at 8:57 AM, Shakthi Pradeep (tpradeep)
<tpradeep@cisco.com> wrote:
> Hello Bruce,
>
> Found the problem…
>
> docker-proxy was linked against /lib64/ld-linux-x86-64.so.2 while docker & dockerd are linked against /lib/ld-linux-x86-64.so

I just pushed fixes for docker-proxy's build, and they were link time
/ shared object fixes

What's the SRCREV of your meta-virtualization build ?

Bruce

>
> /lib64/ld-linux-x86-64.so.2 did not exist in the Yocto build nor was there a symbolic link to /lib/ld-linux-x86-64.so
>
> After creating /lib64/ld-linux-x86-64.so.2 docker image came up fine with –p option
>
> root@genericx86-64:/mnt# ldd /usr/bin/docker-proxy
>         linux-vdso.so.1 (0x00007ffc24bb5000)
>         libpthread.so.0 => /lib/libpthread.so.0 (0x0000003ab7a00000)
>         libc.so.6 => /lib/libc.so.6 (0x0000003ab7600000)
>         /lib64/ld-linux-x86-64.so.2 => /lib/ld-linux-x86-64.so.2 (0x00007f9d7eeba000)
>
> root@genericx86-64:/mnt# ldd /usr/bin/docker
>         linux-vdso.so.1 (0x00007ffcda12f000)
>         libpthread.so.0 => /lib/libpthread.so.0 (0x0000003ab7a00000)
>         libc.so.6 => /lib/libc.so.6 (0x0000003ab7600000)
>         /lib/ld-linux-x86-64.so.2 (0x00007f8511ac0000)
>
> root@genericx86-64:/mnt# ldd /usr/bin/dockerd
>         linux-vdso.so.1 (0x00007ffd41130000)
>         libpthread.so.0 => /lib/libpthread.so.0 (0x0000003ab7a00000)
>         libc.so.6 => /lib/libc.so.6 (0x0000003ab7600000)
>         /lib/ld-linux-x86-64.so.2 (0x00007f848078d000)
> root@genericx86-64:/mnt#
>
> Regards,
> Shakthi
>
> On 11/04/18, 8:20 PM, "Shakthi Pradeep (tpradeep)" <tpradeep@cisco.com> wrote:
>
>     Hello Bruce,
>
>     Could you try running Docker with –p option. After solving the iptables issue, I am hitting another issue.
>
>     Now exec of /usr/bin/docker-proxy gives “no such file or directory” error
>
>     root@genericx86-64:/mnt# docker run -itd --name svo -p 10000:8080 svo supervisord -n
>     29bd8de9dd028888f5f060cb42240762e28dd07cdfa91185fa49953c3da28c36
>     docker: Error response from daemon: driver failed programming external connectivity on endpoint svo (6397cfd4d4e69099c609c8a933e35418a0bf30c1acb4e3b0ebad55668e099fa1): fork/exec /usr/bin/docker-proxy: no such file or directory.
>
>     root@genericx86-64:/mnt# which /usr/bin/docker-proxy
>     /usr/bin/docker-proxy
>
>     root@genericx86-64:/mnt# ldd /usr/bin/docker-proxy
>         linux-vdso.so.1 (0x00007ffd1bbf3000)
>         libpthread.so.0 => /lib/libpthread.so.0 (0x0000003267a00000)
>         libc.so.6 => /lib/libc.so.6 (0x0000003267600000)
>         /lib64/ld-linux-x86-64.so.2 => /lib/ld-linux-x86-64.so.2 (0x00007f0c9e5dc000)
>     root@genericx86-64:/mnt#
>
>     Regards,
>     Shakthi
>
>     On 11/04/18, 8:15 PM, "Shakthi Pradeep (tpradeep)" <tpradeep@cisco.com> wrote:
>
>         Hello Bruce,
>
>         Since I am having build issues with master branch I am back to rocko branch.
>
>         With rocko branch when I use –p option with Docker, I was getting following error “iptables: No chain/target/match by that name.”
>
>         root@genericx86-64:~# docker run -itd --name svo -p 10000:8080 svo supervisord -n
>         52416b288a255361de6e0e09e78055627d898e44cc6b9839430bb2e48b5c5324
>         docker: Error response from daemon: driver failed programming external connectivity on endpoint svo (b5a9bed9b9825027ce02fa603b5daa3d4220953404f8d3efbda4ab5f0ac49138):  (iptables failed: iptables --wait -t nat -A DOCKER -p tcp -d 0/0 --dport 10000 -j DNAT --to-destination 172.17.0.2:8080 ! -i docker0: iptables: No chain/target/match by that name.
>          (exit status 1)).
>
>         This was due to missing LKM, xt_nat & x_tables. With this bundled in the final iso I could solve above problem. Now I am hitting another error
>
>         Below is the complete list of modules
>
>         root@genericx86-64:/mnt# lsmod
>         Module                  Size  Used by
>         xt_tcpudp              16384  0
>         ipt_MASQUERADE         16384  1
>         nf_nat_masquerade_ipv4    16384  1 ipt_MASQUERADE
>         iptable_nat            16384  1
>         nf_conntrack_ipv4      16384  3
>         nf_defrag_ipv4         16384  1 nf_conntrack_ipv4
>         nf_nat_ipv4            16384  1 iptable_nat
>         iptable_filter         16384  1
>         ip_tables              24576  2 iptable_filter,iptable_nat
>         bridge                106496  0
>         stp                    16384  1 bridge
>         llc                    16384  2 bridge,stp
>         xt_nat                 16384  0
>         nf_nat                 24576  3 xt_nat,nf_nat_masquerade_ipv4,nf_nat_ipv4
>         xt_conntrack           16384  1
>         nf_conntrack           86016  7 xt_nat,nf_conntrack_ipv4,ipt_MASQUERADE,nf_nat_masquerade_ipv4,xt_conntrack,nf_nat_ipv4,nf_nat
>         libcrc32c              16384  2 nf_conntrack,nf_nat
>         xt_addrtype            16384  2
>         x_tables               28672  7 xt_nat,ip_tables,iptable_filter,xt_tcpudp,ipt_MASQUERADE,xt_addrtype,xt_conntrack
>         root@genericx86-64:/mnt#
>
>         Regards,
>         Shakthi
>
>         On 09/04/18, 7:49 PM, "Bruce Ashfield" <bruce.ashfield@gmail.com> wrote:
>
>             Sure, but none of them are docker.
>
>             Bruce
>
>             On Mon, Apr 9, 2018 at 9:46 AM, Shakthi Pradeep (tpradeep)
>             <tpradeep@cisco.com> wrote:
>             > Hello Bruce,
>             >
>             > I see pkg_postinst_${PN}() are part of below recipes….
>             >
>             > TPRADEEP-M-91HW:meta-virtualization tpradeep$ grep -r postinst *
>             > recipes-containers/singularity/singularity_git.bb:pkg_postinst_${PN}() {
>             > recipes-containers/lxc/lxc_2.0.8.bb:pkg_postinst_${PN}() {
>             > recipes-containers/lxc/lxc_2.0.8.bb:pkg_postinst_${PN}-networking() {
>             > recipes-extended/xen/xen.inc:pkg_postinst_${PN}-volatiles() {
>             > recipes-extended/libvirt/libvirt_1.3.5.bb:pkg_postinst_libvirt() {
>             > recipes-networking/openvswitch/openvswitch.inc:# rdeps.  E.g. ovs-pki calls sed in the postinstall.  sed may be
>             > recipes-networking/openvswitch/openvswitch.inc:pkg_postinst_${PN}-pki () {
>             > recipes-networking/openvswitch/openvswitch.inc:pkg_postinst_${PN}-testcontroller () {
>             >
>             > Regards,
>             > Shakthi
>             >
>             > On 09/04/18, 6:47 PM, "Bruce Ashfield" <bruce.ashfield@gmail.com> wrote:
>             >
>             >     On Mon, Apr 9, 2018 at 4:37 AM, Shakthi Pradeep (tpradeep)
>             >     <tpradeep@cisco.com> wrote:
>             >     > Hello Bruce,
>             >     >
>             >     > Moved to master branch of Yocto. When I build I am getting below error. What does this mean?
>             >
>             >     There were changes made to the way that postinstall scripts were run
>             >     in the January
>             >     timeframe,
>             >
>             >     i.e.:
>             >
>             >      commit 7bc55b29609765904af9f330600229e96cc044cf
>             >     Author: Alexander Kanavin <alexander.kanavin@linux.intel.com>
>             >     Date:   Mon Jan 29 14:01:32 2018 +0200
>             >
>             >         meta/lib/oe/package_manager.py: deprecate 'exit 1' as a way to
>             >     defer to first boot
>             >
>             >         'exit 1' is not optimal for two reasons:
>             >
>             >         1) Code is hard to read; it is not obvious that it means 'defer
>             >     what follows to first boot'.
>             >         2) Worse, this hides actual errors in the scriptlets; there is no
>             >     difference between scriptlet
>             >         failing because it's intended to be run on target and scriptlet
>             >     failing because there's a bug or
>             >         a regression somewhere.
>             >
>             >         The new, supported way is to place the code that has to run on
>             >     target into pkg_postinst_ontarget(),
>             >         or, if a more fine-tuned control is required, call
>             >     'postinst-intercepts defer_to_first_boot' from
>             >         pkg_postinst() to explicitly request deferral to first boot.
>             >
>             >         (From OE-Core rev: d12cf56e9ff2a4f13dfbef9290ea5647b52b3f6d)
>             >
>             >         Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
>             >         Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
>             >
>             >     :100644 100644 2a07f0e39ad6... f7e013437c91... M
>             >     meta/lib/oe/package_manager.py
>             >
>             >     commit 6ca669105ff7f405e85142d1aa5375a8430c9606
>             >     Author: Alexander Kanavin <alexander.kanavin@linux.intel.com>
>             >     Date:   Mon Jan 29 14:01:31 2018 +0200
>             >
>             >         package.bbclass: add support for pkg_postinst_ontarget()
>             >
>             >         This function is a convenient and more readable shortcut for situations
>             >         when the postinst code always needs to run on target. All commands that
>             >         cannot be executed during cross-install and can only be run on target
>             >         should go into this function. They will only be executed on first boot
>             >         (if package was cross-installed) or immediately during package installation
>             >         on target.
>             >
>             >         Plain pkg_postinst() works as before: it is run during cross-install time,
>             >         it can contain a request to defer to first boot, and it is also run
>             >         during package installation on target.
>             >
>             >         Also fix the oeqa test for this functionality to use the new function
>             >         where appropriate.
>             >
>             >         (From OE-Core rev: 229f4e975fb6957f44b5c56735fd6d58564098d7)
>             >
>             >         Signed-off-by: Alexander Kanavin <alexander.kanavin@linux.intel.com>
>             >         Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
>             >
>             >     :100644 100644 112aa08c80f8... d4bab6dcc228... M
>             >     meta-selftest/recipes-test/postinst/postinst_1.0.bb
>             >     :100644 100644 7dc759699f4b... 6a7f35a3e787... M
>             >     meta/classes/package.bbclass
>             >
>             >     -------
>             >
>             >     But you shouldn't be getting that warning with docker, since it doesn't
>             >     have a pkg_postinst_${PN}(), or related element in the recipe.
>             >
>             >     So something in your build is adding that postinstall action, that isn't
>             >     part of the meta-virtualization layer.
>             >
>             >     Bruce
>             >
>             >
>             >     >
>             >     > Initialising tasks: 100% |######################################################################################################################################################| Time: 0:00:04
>             >     > NOTE: Executing SetScene Tasks
>             >     > NOTE: Executing RunQueue Tasks
>             >     > WARNING: core-image-full-cmdline-1.0-r0 do_rootfs: Intentionally failing postinstall scriptlets of ['docker'] to defer them to first boot is deprecated. Please place them into pkg_postinst_ontarget_${PN} ().
>             >     > If deferring to first boot wasn't the intent, then scriptlet failure may mean an issue in the recipe, or a regression elsewhere.
>             >     > Details of the failure are in /workdir/poky/build/tmp/work/genericx86_64-poky-linux/core-image-full-cmdline/1.0-r0/temp/log.do_rootfs.
>             >     > WARNING: core-image-full-cmdline-1.0-r0 do_rootfs: [log_check] core-image-full-cmdline: found 2 warning messages in the logfile:
>             >     > [log_check] warning: %post(docker-18.03.0+git708b068d3095c6a6be939eb2da78c921d2e945e2-r0.core2_64) scriptlet failed, exit status 1
>             >     > [log_check] WARNING: Intentionally failing postinstall scriptlets of ['docker'] to defer them to first boot is deprecated. Please place them into pkg_postinst_ontarget_${PN} ().
>             >     >
>             >     > Regards,
>             >     > Shakthi
>             >     >
>             >     > On 06/04/18, 1:09 AM, "Bruce Ashfield" <bruce.ashfield@gmail.com> wrote:
>             >     >
>             >     >     On Thu, Apr 5, 2018 at 11:55 AM, Shakthi Pradeep (tpradeep)
>             >     >     <tpradeep@cisco.com> wrote:
>             >     >     > Hello Bruce,
>             >     >     >
>             >     >     > I pulled master branch from git://git.yoctoproject.org/poky but build fails
>             >     >     >
>             >     >     > When I run "bitbake core-image-full-cmdline" or "bitbake core-image-minimal" I get following error
>             >     >     >
>             >     >     > ERROR: Task (/nobackup/tpradeep/playground/yocto/poky/meta/recipes-kernel/linux-libc-headers/linux-libc-headers_4.15.7.bb:do_install) failed with exit code '1'
>             >     >     > ERROR: Task (/nobackup/tpradeep/playground/yocto/poky/meta/recipes-devtools/autoconf-archive/autoconf-archive_2016.09.16.bb:do_install) failed with exit code '1'
>             >     >     >
>             >     >     > Any idea why?
>             >     >
>             >     >     Nope. But the errors are unrelated to the changes in meta-virt. If the
>             >     >     issue persists, asking on the oe-core list is a better bet.
>             >     >     I'd suggest that you rm -rf tmp, and start the build again.
>             >     >
>             >     >     Bruce
>             >     >
>             >     >     >
>             >     >     > Regards,
>             >     >     > Shakthi
>             >     >     >
>             >     >     > -----Original Message-----
>             >     >     > From: Bruce Ashfield [mailto:bruce.ashfield@gmail.com]
>             >     >     > Sent: Thursday, April 05, 2018 7:44 PM
>             >     >     > To: Shakthi Pradeep (tpradeep) <tpradeep@cisco.com>
>             >     >     > Cc: meta-virtualization@yoctoproject.org
>             >     >     > Subject: Re: [meta-virtualization] RFT/FYI: docker/containerd/runc uprevs pushed to master
>             >     >     >
>             >     >     > On Thu, Apr 5, 2018 at 9:32 AM, Shakthi Pradeep (tpradeep) <tpradeep@cisco.com> wrote:
>             >     >     >> Hello Bruce,
>             >     >     >>
>             >     >     >> I am actually working on a repo from Third Party. So here things are little outdated.
>             >     >     >>
>             >     >     >> I found some info from http://git.yoctoproject.org
>             >     >     >>
>             >     >     >> I am currently using Docker 1.13.0 which was committed on 2017-01-20
>             >     >     >>
>             >     >     >> http://git.yoctoproject.org/cgit/cgit.cgi/meta-virtualization/commit/r
>             >     >     >> ecipes-containers/docker?id=0b631bf01487d3d1be0c91ea7749168fb3c47dcb
>             >     >     >>
>             >     >     >> I need to migrate to 18.03.0 which you committed 3 days ago
>             >     >     >>
>             >     >     >> http://git.yoctoproject.org/cgit/cgit.cgi/meta-virtualization/commit/r
>             >     >     >> ecipes-containers/docker?id=a5074cecf18faea1a325c8ac9220d2df41250af5
>             >     >     >>
>             >     >     >> If I take recipe from above commit and update my workspace, will all the dependencies migrate to latest automatically?
>             >     >     >
>             >     >     > Nope. You'd need to pull in all the updates that I recently pushed for the dependencies, or you'll end up with runtime errors.
>             >     >     > Also note, that due to the different go versions and build infrastructure in oe-core, there's no guarantee that those new recipes will build properly on an older baseline.
>             >     >     >
>             >     >     > Bruce
>             >     >     >
>             >     >     >>
>             >     >     >> Regards,
>             >     >     >> Shakthi
>             >     >     >>
>             >     >     >> -----Original Message-----
>             >     >     >> From: Bruce Ashfield [mailto:bruce.ashfield@gmail.com]
>             >     >     >> Sent: Thursday, April 05, 2018 6:46 PM
>             >     >     >> To: Shakthi Pradeep (tpradeep) <tpradeep@cisco.com>
>             >     >     >> Cc: meta-virtualization@yoctoproject.org
>             >     >     >> Subject: Re: [meta-virtualization] RFT/FYI: docker/containerd/runc
>             >     >     >> uprevs pushed to master
>             >     >     >>
>             >     >     >> root@cube-server:~# docker --version
>             >     >     >> Docker version 18.03.0, build 0f1bb353423e
>             >     >     >>
>             >     >     >> If you are building meta-virt master, the update should happen automatically since the PV of the updated recipe is higher than the old one. All the dependencies will follow after that.
>             >     >     >>
>             >     >     >> Bruce
>             >     >     >>
>             >     >     >> On Thu, Apr 5, 2018 at 9:02 AM, Shakthi Pradeep (tpradeep) <tpradeep@cisco.com> wrote:
>             >     >     >>> Hello Bruce,
>             >     >     >>>
>             >     >     >>> Which version of Docker are you running.
>             >     >     >>>
>             >     >     >>> I just noticed I am running Docker 1.13.1 which is too old.
>             >     >     >>>
>             >     >     >>> How do I migrate to latest version of Docker & also corresponding dependencies.
>             >     >     >>>
>             >     >     >>> Regards,
>             >     >     >>> Shakthi
>             >     >     >>>
>             >     >     >>> -----Original Message-----
>             >     >     >>> From: Bruce Ashfield [mailto:bruce.ashfield@gmail.com]
>             >     >     >>> Sent: Wednesday, April 04, 2018 6:45 PM
>             >     >     >>> To: Shakthi Pradeep (tpradeep) <tpradeep@cisco.com>
>             >     >     >>> Cc: meta-virtualization@yoctoproject.org
>             >     >     >>> Subject: Re: [meta-virtualization] RFT/FYI: docker/containerd/runc
>             >     >     >>> uprevs pushed to master
>             >     >     >>>
>             >     >     >>> Excellent news.
>             >     >     >>>
>             >     >     >>> Yes, everything is in master of meta-virtualization now. That way it will have time to soak a bit before the upcoming release.
>             >     >     >>>
>             >     >     >>> Cheers,
>             >     >     >>>
>             >     >     >>> Bruce
>             >     >     >>>
>             >     >     >>> On Wed, Apr 4, 2018 at 8:32 AM, Shakthi Pradeep (tpradeep) <tpradeep@cisco.com> wrote:
>             >     >     >>>> Hello Bruce,
>             >     >     >>>>
>             >     >     >>>> Yes I was missing the bbappend for kernel config. Got it working after I wrote the mail to you.
>             >     >     >>>>
>             >     >     >>>> Are your changes committed to git repo? Is it in the master branch of Yocto?
>             >     >     >>>>
>             >     >     >>>> Regards,
>             >     >     >>>> Shakthi
>             >     >     >>>>
>             >     >     >>>> -----Original Message-----
>             >     >     >>>> From: Bruce Ashfield [mailto:bruce.ashfield@gmail.com]
>             >     >     >>>> Sent: Wednesday, April 04, 2018 5:57 PM
>             >     >     >>>> To: Shakthi Pradeep (tpradeep) <tpradeep@cisco.com>
>             >     >     >>>> Cc: meta-virtualization@yoctoproject.org
>             >     >     >>>> Subject: Re: [meta-virtualization] RFT/FYI: docker/containerd/runc
>             >     >     >>>> uprevs pushed to master
>             >     >     >>>>
>             >     >     >>>> On Wed, Apr 4, 2018 at 12:57 AM, Shakthi Pradeep (tpradeep) <tpradeep@cisco.com> wrote:
>             >     >     >>>>> Hello Bruce,
>             >     >     >>>>>
>             >     >     >>>>>
>             >     >     >>>>>
>             >     >     >>>>> Timing is Perfect !!!
>             >     >     >>>>>
>             >     >     >>>>>
>             >     >     >>>>>
>             >     >     >>>>> I am currently trying to get Docker CE to work with Yocto. I could
>             >     >     >>>>> include the Docker executable in ISO but when I run it I get some errors.
>             >     >     >>>>>
>             >     >     >>>>>
>             >     >     >>>>>
>             >     >     >>>>> When I boot the image looks like Docker service start is failing
>             >     >     >>>>> due to missing kernel modules. Please refer attached screenshot and
>             >     >     >>>>> below error log.
>             >     >     >>>>
>             >     >     >>>> Do you have a bbappend for your 4.8 kernel that adds the docker configuration fragments ?
>             >     >     >>>>
>             >     >     >>>> That's the most likely reason for the issues.
>             >     >     >>>>
>             >     >     >>>> I was able to run a whole suite of tests against 4.12, 4.14 and 4.15 so those kernels + fragments are known to work.
>             >     >     >>>>
>             >     >     >>>> Bruce
>             >     >     >>>>
>             >     >     >>>>>
>             >     >     >>>>>
>             >     >     >>>>>
>             >     >     >>>>> * docker.service - Docker Application Container Engine
>             >     >     >>>>>
>             >     >     >>>>>    Loaded: loaded (/lib/systemd/system/docker.service; enabled;
>             >     >     >>>>> vendor
>             >     >     >>>>> preset: enabled)
>             >     >     >>>>>
>             >     >     >>>>>    Active: failed (Result: exit-code) since Tue 2018-04-03 13:17:51
>             >     >     >>>>> UTC; 17min ago
>             >     >     >>>>>
>             >     >     >>>>>      Docs: https://docs.docker.com
>             >     >     >>>>>
>             >     >     >>>>>   Process: 317 ExecStart=/usr/bin/dockerd -H fd:// (code=exited,
>             >     >     >>>>> status=1/FAILURE)
>             >     >     >>>>>
>             >     >     >>>>> Main PID: 317 (code=exited, status=1/FAILURE)
>             >     >     >>>>>
>             >     >     >>>>>
>             >     >     >>>>>
>             >     >     >>>>> Apr 03 13:17:51 intel-x86-64 dockerd[317]:
>             >     >     >>>>> time="2018-04-03T13:17:51.035178755Z" level=warning msg="Running
>             >     >     >>>>> modprobe xt_conntrack failed with message: `modprobe: WARNING:
>             >     >     >>>>> Module xt_conntrack not found in directory
>             >     >     >>>>> /lib/modules/4.8.24-WR9.0.0.10_standard`, error: exit status 1"
>             >     >     >>>>>
>             >     >     >>>>> Apr 03 13:17:51 intel-x86-64 dockerd[317]:
>             >     >     >>>>> time="2018-04-03T13:17:51.040727372Z" level=info msg="Firewalld running:
>             >     >     >>>>> false"
>             >     >     >>>>>
>             >     >     >>>>> Apr 03 13:17:51 intel-x86-64 dockerd[317]:
>             >     >     >>>>> time="2018-04-03T13:17:51.170575344Z" level=warning msg="Could not
>             >     >     >>>>> load necessary modules for IPSEC rules: Running modprobe xfrm_user
>             >     >     >>>>> failed with
>             >     >     >>>>> message: `modprobe: WARNING: Module xfrm_user not found in
>             >     >     >>>>> directory /lib/modules/4.8.24-WR9.0.0.10_standard`, error: exit status 1"
>             >     >     >>>>>
>             >     >     >>>>> Apr 03 13:17:51 intel-x86-64 dockerd[317]:
>             >     >     >>>>> time="2018-04-03T13:17:51.172397913Z" level=info msg="Default
>             >     >     >>>>> bridge
>             >     >     >>>>> (docker0) is assigned with an IP address 172.17.0.0/16. Daemon
>             >     >     >>>>> option --bip can be used to set a preferred IP address"
>             >     >     >>>>>
>             >     >     >>>>> Apr 03 13:17:51 intel-x86-64 dockerd[317]: Error starting daemon:
>             >     >     >>>>> Error initializing network controller: Error creating default "bridge" network:
>             >     >     >>>>> Failed to Setup IP tables: Unable to enable ACCEPT INCOMING rule:
>             >     >     >>>>> (iptables
>             >     >     >>>>> failed: iptables --wait -I FORWARD -o docker0 -m conntrack
>             >     >     >>>>> --ctstate RELATED,ESTABLISHED -j ACCEPT: iptables: No chain/target/match by that name.
>             >     >     >>>>>
>             >     >     >>>>> Apr 03 13:17:51 intel-x86-64 dockerd[317]:  (exit status 1))
>             >     >     >>>>>
>             >     >     >>>>> Apr 03 13:17:51 intel-x86-64 systemd[1]: docker.service: Main
>             >     >     >>>>> process exited, code=exited, status=1/FAILURE
>             >     >     >>>>>
>             >     >     >>>>> Apr 03 13:17:51 intel-x86-64 systemd[1]: Failed to start Docker
>             >     >     >>>>> Application Container Engine.
>             >     >     >>>>>
>             >     >     >>>>> Apr 03 13:17:51 intel-x86-64 systemd[1]: docker.service: Unit
>             >     >     >>>>> entered failed state.
>             >     >     >>>>>
>             >     >     >>>>> Apr 03 13:17:51 intel-x86-64 systemd[1]: docker.service: Failed
>             >     >     >>>>> with result 'exit-code'.
>             >     >     >>>>>
>             >     >     >>>>>
>             >     >     >>>>>
>             >     >     >>>>> Regards,
>             >     >     >>>>>
>             >     >     >>>>> Shakthi
>             >     >     >>>>>
>             >     >     >>>>>
>             >     >     >>>>>
>             >     >     >>>>> -----Original Message-----
>             >     >     >>>>> From: meta-virtualization-bounces@yoctoproject.org
>             >     >     >>>>> [mailto:meta-virtualization-bounces@yoctoproject.org] On Behalf Of
>             >     >     >>>>> Bruce Ashfield
>             >     >     >>>>> Sent: Wednesday, April 04, 2018 8:44 AM
>             >     >     >>>>> To: meta-virtualization@yoctoproject.org
>             >     >     >>>>> Subject: [meta-virtualization] RFT/FYI: docker/containerd/runc
>             >     >     >>>>> uprevs pushed to master
>             >     >     >>>>>
>             >     >     >>>>>
>             >     >     >>>>>
>             >     >     >>>>> Hi all,
>             >     >     >>>>>
>             >     >     >>>>>
>             >     >     >>>>>
>             >     >     >>>>> After spending a few days de-tangling the
>             >     >     >>>>> moby/docker/runc/containerd and oe-core go infrastructure changes,
>             >     >     >>>>> I was able to run docker/runc/containerd through a system/stress test and everything seems to be working.
>             >     >     >>>>>
>             >     >     >>>>>
>             >     >     >>>>>
>             >     >     >>>>> There were a few regressions that I worked through, as well as
>             >     >     >>>>> build/packaging changes, but I'm no longer seeing any issues and
>             >     >     >>>>> all the patches/functionality have been carried forward.
>             >     >     >>>>>
>             >     >     >>>>>
>             >     >     >>>>>
>             >     >     >>>>> One thing of note is that the docker and open containers containerd
>             >     >     >>>>> split/fork is no longer an issue, so I've modified the default to
>             >     >     >>>>> be the opencontainers variant. Similarly, the docker and
>             >     >     >>>>> opencontainers runc are very similar. I've kept both variants of
>             >     >     >>>>> both recipes for now, since I'd like to track things for a bit
>             >     >     >>>>> longer before declaring the split unnecessary.
>             >     >     >>>>>
>             >     >     >>>>>
>             >     >     >>>>>
>             >     >     >>>>> Also for those that care, I created a reference docker-ce recipe
>             >     >     >>>>> that tracks the docker-ce repo versus the components themselves.
>             >     >     >>>>> Right now it is reference only, since it needs a bit more work, but
>             >     >     >>>>> I wanted to get it out there, in case someone really cares about
>             >     >     >>>>> docker-ce (I don't really, but someone might!).
>             >     >     >>>>>
>             >     >     >>>>>
>             >     >     >>>>>
>             >     >     >>>>> Summary: I just pushed the following changes to master:
>             >     >     >>>>>
>             >     >     >>>>>
>             >     >     >>>>>
>             >     >     >>>>>   d7d310ae4113 meta-virt: prefer containerd-opencontainers
>             >     >     >>>>>
>             >     >     >>>>>   935e3d969ef1 containerd: uprev to v1.0.2
>             >     >     >>>>>
>             >     >     >>>>>   f5fbfa8ac4db docker-ce: introduce reference recipe/build
>             >     >     >>>>>
>             >     >     >>>>>   a5074cecf18f docker: uprev to 18.03.0
>             >     >     >>>>>
>             >     >     >>>>>   e3d960f4fcd9 runc: uprev to 1.0.0-rc5
>             >     >     >>>>>
>             >     >     >>>>>
>             >     >     >>>>>
>             >     >     >>>>> If anyone sees regressions, build or architecture issues .. report
>             >     >     >>>>> them to me (and the list) and we'll get them fixed up.
>             >     >     >>>>>
>             >     >     >>>>>
>             >     >     >>>>>
>             >     >     >>>>> Cheers,
>             >     >     >>>>>
>             >     >     >>>>>
>             >     >     >>>>>
>             >     >     >>>>> Bruce
>             >     >     >>>>>
>             >     >     >>>>>
>             >     >     >>>>>
>             >     >     >>>>> --
>             >     >     >>>>>
>             >     >     >>>>> "Thou shalt not follow the NULL pointer, for chaos and madness
>             >     >     >>>>> await thee at its end"
>             >     >     >>>>>
>             >     >     >>>>> --
>             >     >     >>>>>
>             >     >     >>>>> _______________________________________________
>             >     >     >>>>>
>             >     >     >>>>> meta-virtualization mailing list
>             >     >     >>>>>
>             >     >     >>>>> meta-virtualization@yoctoproject.org
>             >     >     >>>>>
>             >     >     >>>>> https://lists.yoctoproject.org/listinfo/meta-virtualization
>             >     >     >>>>
>             >     >     >>>>
>             >     >     >>>>
>             >     >     >>>> --
>             >     >     >>>> "Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end"
>             >     >     >>>
>             >     >     >>>
>             >     >     >>>
>             >     >     >>> --
>             >     >     >>> "Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end"
>             >     >     >>
>             >     >     >>
>             >     >     >>
>             >     >     >> --
>             >     >     >> "Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end"
>             >     >     >
>             >     >     >
>             >     >     >
>             >     >     > --
>             >     >     > "Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end"
>             >     >
>             >     >
>             >     >
>             >     >     --
>             >     >     "Thou shalt not follow the NULL pointer, for chaos and madness await
>             >     >     thee at its end"
>             >     >
>             >     >
>             >
>             >
>             >
>             >     --
>             >     "Thou shalt not follow the NULL pointer, for chaos and madness await
>             >     thee at its end"
>             >
>             >
>
>
>
>             --
>             "Thou shalt not follow the NULL pointer, for chaos and madness await
>             thee at its end"
>
>
>
>
>
>



-- 
"Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end"