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.ashfi...@gmail.com> wrote:

    On Mon, Apr 9, 2018 at 4:37 AM, Shakthi Pradeep (tpradeep)
    <tprad...@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.kana...@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.kana...@linux.intel.com>
        Signed-off-by: Richard Purdie <richard.pur...@linuxfoundation.org>
    
    :100644 100644 2a07f0e39ad6... f7e013437c91... M
    meta/lib/oe/package_manager.py
    
    commit 6ca669105ff7f405e85142d1aa5375a8430c9606
    Author: Alexander Kanavin <alexander.kana...@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.kana...@linux.intel.com>
        Signed-off-by: Richard Purdie <richard.pur...@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.ashfi...@gmail.com> wrote:
    >
    >     On Thu, Apr 5, 2018 at 11:55 AM, Shakthi Pradeep (tpradeep)
    >     <tprad...@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.ashfi...@gmail.com]
    >     > Sent: Thursday, April 05, 2018 7:44 PM
    >     > To: Shakthi Pradeep (tpradeep) <tprad...@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) 
<tprad...@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.ashfi...@gmail.com]
    >     >> Sent: Thursday, April 05, 2018 6:46 PM
    >     >> To: Shakthi Pradeep (tpradeep) <tprad...@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) 
<tprad...@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.ashfi...@gmail.com]
    >     >>> Sent: Wednesday, April 04, 2018 6:45 PM
    >     >>> To: Shakthi Pradeep (tpradeep) <tprad...@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) 
<tprad...@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.ashfi...@gmail.com]
    >     >>>> Sent: Wednesday, April 04, 2018 5:57 PM
    >     >>>> To: Shakthi Pradeep (tpradeep) <tprad...@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) 
<tprad...@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-boun...@yoctoproject.org
    >     >>>>> [mailto:meta-virtualization-boun...@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"
    

-- 
_______________________________________________
meta-virtualization mailing list
meta-virtualization@yoctoproject.org
https://lists.yoctoproject.org/listinfo/meta-virtualization

Reply via email to