* [OE-core][PATCH 0/1 v3] classes/kernel: Use a copy of image for kernel*.rpm if fs doesn't support symlinks
@ 2020-06-19 11:47 Xu, Yanfei
2020-06-19 11:47 ` [OE-core][PATCH 1/1 " Xu, Yanfei
0 siblings, 1 reply; 18+ messages in thread
From: Xu, Yanfei @ 2020-06-19 11:47 UTC (permalink / raw)
To: bruce.ashfield, richard.purdie, openembedded-core
From: Yanfei Xu <yanfei.xu@windriver.com>
v1->v2->v3:
1.Put the symlink creation at postinstall script instead of build time.
2.Add a postremove script for removing image created in postinstall.
Yanfei Xu (1):
classes/kernel: Use a copy of image for kernel*.rpm if fs doesn't
support symlinks
meta/classes/kernel.bbclass | 19 ++++++++++++++++---
1 file changed, 16 insertions(+), 3 deletions(-)
--
2.18.2
^ permalink raw reply [flat|nested] 18+ messages in thread* [OE-core][PATCH 1/1 v3] classes/kernel: Use a copy of image for kernel*.rpm if fs doesn't support symlinks 2020-06-19 11:47 [OE-core][PATCH 0/1 v3] classes/kernel: Use a copy of image for kernel*.rpm if fs doesn't support symlinks Xu, Yanfei @ 2020-06-19 11:47 ` Xu, Yanfei 2020-06-23 14:31 ` Bruce Ashfield 0 siblings, 1 reply; 18+ messages in thread From: Xu, Yanfei @ 2020-06-19 11:47 UTC (permalink / raw) To: bruce.ashfield, richard.purdie, openembedded-core From: Yanfei Xu <yanfei.xu@windriver.com> Some filesystems don't support symlink, then you will get failure when you install or update the kernel rpm package. Now we use a copy of image for these filesystems instead of symlink. Suggested-by: Bruce Ashfield <bruce.ashfield@gmail.com> Suggested-by: Richard Purdie <richard.purdie@linuxfoundation.org> Signed-off-by: Yanfei Xu <yanfei.xu@windriver.com> --- meta/classes/kernel.bbclass | 19 ++++++++++++++++--- 1 file changed, 16 insertions(+), 3 deletions(-) diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass index 20a0135fc9..1269b54343 100644 --- a/meta/classes/kernel.bbclass +++ b/meta/classes/kernel.bbclass @@ -94,6 +94,22 @@ python __anonymous () { d.appendVar('RDEPENDS_%s-image' % kname, ' %s-image-%s' % (kname, typelower)) d.setVar('PKG_%s-image-%s' % (kname,typelower), '%s-image-%s-${KERNEL_VERSION_PKG_NAME}' % (kname, typelower)) d.setVar('ALLOW_EMPTY_%s-image-%s' % (kname, typelower), '1') + d.setVar('pkg_postinst_ontarget_%s-image-%s' % (kname,typelower), """ +set +e +ln -sf %s-${KERNEL_VERSION} ${KERNEL_IMAGEDEST}/%s > /dev/null 2>&1 +if [ $? -ne 0 ]; then + echo "Filesystem on ${KERNEL_IMAGEDEST}/ doesn't support symlinks, falling back to copied image (%s)." + install -m 0644 ${KERNEL_IMAGEDEST}/%s-${KERNEL_VERSION} ${KERNEL_IMAGEDEST}/%s +fi +set -e +""" % (type, type, type, type, type)) + d.setVar('pkg_postrm_%s-image-%s' % (kname,typelower), """ +set +e +if [ -f "${KERNEL_IMAGEDEST}/%s" -o -L "${KERNEL_IMAGEDEST}/%s" ]; then + rm -f ${KERNEL_IMAGEDEST}/%s > /dev/null 2>&1 +fi +set -e +""" % (type, type, type)) image = d.getVar('INITRAMFS_IMAGE') # If the INTIRAMFS_IMAGE is set but the INITRAMFS_IMAGE_BUNDLE is set to 0, @@ -385,9 +401,6 @@ kernel_do_install() { install -d ${D}/boot for imageType in ${KERNEL_IMAGETYPES} ; do install -m 0644 ${KERNEL_OUTPUT_DIR}/${imageType} ${D}/${KERNEL_IMAGEDEST}/${imageType}-${KERNEL_VERSION} - if [ "${KERNEL_PACKAGE_NAME}" = "kernel" ]; then - ln -sf ${imageType}-${KERNEL_VERSION} ${D}/${KERNEL_IMAGEDEST}/${imageType} - fi done install -m 0644 System.map ${D}/boot/System.map-${KERNEL_VERSION} install -m 0644 .config ${D}/boot/config-${KERNEL_VERSION} -- 2.18.2 ^ permalink raw reply related [flat|nested] 18+ messages in thread
* Re: [OE-core][PATCH 1/1 v3] classes/kernel: Use a copy of image for kernel*.rpm if fs doesn't support symlinks 2020-06-19 11:47 ` [OE-core][PATCH 1/1 " Xu, Yanfei @ 2020-06-23 14:31 ` Bruce Ashfield 2020-06-23 21:51 ` Richard Purdie 2020-06-24 1:44 ` Xu, Yanfei 0 siblings, 2 replies; 18+ messages in thread From: Bruce Ashfield @ 2020-06-23 14:31 UTC (permalink / raw) To: Xu, Yanfei Cc: Richard Purdie, Patches and discussions about the oe-core layer On Fri, Jun 19, 2020 at 7:47 AM <yanfei.xu@windriver.com> wrote: > > From: Yanfei Xu <yanfei.xu@windriver.com> > > Some filesystems don't support symlink, then you will get failure when > you install or update the kernel rpm package. Now we use a copy of > image for these filesystems instead of symlink. > > Suggested-by: Bruce Ashfield <bruce.ashfield@gmail.com> > Suggested-by: Richard Purdie <richard.purdie@linuxfoundation.org> > Signed-off-by: Yanfei Xu <yanfei.xu@windriver.com> > --- > meta/classes/kernel.bbclass | 19 ++++++++++++++++--- > 1 file changed, 16 insertions(+), 3 deletions(-) > > diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass > index 20a0135fc9..1269b54343 100644 > --- a/meta/classes/kernel.bbclass > +++ b/meta/classes/kernel.bbclass > @@ -94,6 +94,22 @@ python __anonymous () { > d.appendVar('RDEPENDS_%s-image' % kname, ' %s-image-%s' % (kname, typelower)) > d.setVar('PKG_%s-image-%s' % (kname,typelower), '%s-image-%s-${KERNEL_VERSION_PKG_NAME}' % (kname, typelower)) > d.setVar('ALLOW_EMPTY_%s-image-%s' % (kname, typelower), '1') > + d.setVar('pkg_postinst_ontarget_%s-image-%s' % (kname,typelower), """ You were previously concerned about boot issues if the unversioned image link/copy was deferred until boot. I don't see a summary of why that's no longer a concern in the v3 of the patch. Can you confirm that it isn't an issue ? Is it simply because the booted image isn't installed via this package, and hence we are fine ? > +set +e > +ln -sf %s-${KERNEL_VERSION} ${KERNEL_IMAGEDEST}/%s > /dev/null 2>&1 > +if [ $? -ne 0 ]; then > + echo "Filesystem on ${KERNEL_IMAGEDEST}/ doesn't support symlinks, falling back to copied image (%s)." > + install -m 0644 ${KERNEL_IMAGEDEST}/%s-${KERNEL_VERSION} ${KERNEL_IMAGEDEST}/%s > +fi > +set -e > +""" % (type, type, type, type, type)) > + d.setVar('pkg_postrm_%s-image-%s' % (kname,typelower), """ > +set +e > +if [ -f "${KERNEL_IMAGEDEST}/%s" -o -L "${KERNEL_IMAGEDEST}/%s" ]; then > + rm -f ${KERNEL_IMAGEDEST}/%s > /dev/null 2>&1 > +fi > +set -e > +""" % (type, type, type)) > > image = d.getVar('INITRAMFS_IMAGE') > # If the INTIRAMFS_IMAGE is set but the INITRAMFS_IMAGE_BUNDLE is set to 0, > @@ -385,9 +401,6 @@ kernel_do_install() { > install -d ${D}/boot > for imageType in ${KERNEL_IMAGETYPES} ; do > install -m 0644 ${KERNEL_OUTPUT_DIR}/${imageType} ${D}/${KERNEL_IMAGEDEST}/${imageType}-${KERNEL_VERSION} > - if [ "${KERNEL_PACKAGE_NAME}" = "kernel" ]; then > - ln -sf ${imageType}-${KERNEL_VERSION} ${D}/${KERNEL_IMAGEDEST}/${imageType} > - fi For on-target installs, this is what I was doing in the past as well. Make the symlink during package install, that way we are encapsulated in that unit. That just leaves my boot question as the last remaining thing for the change. Bruce > done > install -m 0644 System.map ${D}/boot/System.map-${KERNEL_VERSION} > install -m 0644 .config ${D}/boot/config-${KERNEL_VERSION} > -- > 2.18.2 > -- - Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end - "Use the force Harry" - Gandalf, Star Trek II ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [OE-core][PATCH 1/1 v3] classes/kernel: Use a copy of image for kernel*.rpm if fs doesn't support symlinks 2020-06-23 14:31 ` Bruce Ashfield @ 2020-06-23 21:51 ` Richard Purdie 2020-06-24 1:47 ` Xu, Yanfei 2020-06-24 1:44 ` Xu, Yanfei 1 sibling, 1 reply; 18+ messages in thread From: Richard Purdie @ 2020-06-23 21:51 UTC (permalink / raw) To: Bruce Ashfield, Xu, Yanfei Cc: Patches and discussions about the oe-core layer On Tue, 2020-06-23 at 10:31 -0400, Bruce Ashfield wrote: > On Fri, Jun 19, 2020 at 7:47 AM <yanfei.xu@windriver.com> wrote: > > From: Yanfei Xu <yanfei.xu@windriver.com> > > > > Some filesystems don't support symlink, then you will get failure > > when > > you install or update the kernel rpm package. Now we use a copy of > > image for these filesystems instead of symlink. > > > > Suggested-by: Bruce Ashfield <bruce.ashfield@gmail.com> > > Suggested-by: Richard Purdie <richard.purdie@linuxfoundation.org> > > Signed-off-by: Yanfei Xu <yanfei.xu@windriver.com> > > --- > > meta/classes/kernel.bbclass | 19 ++++++++++++++++--- > > 1 file changed, 16 insertions(+), 3 deletions(-) > > > > diff --git a/meta/classes/kernel.bbclass > > b/meta/classes/kernel.bbclass > > index 20a0135fc9..1269b54343 100644 > > --- a/meta/classes/kernel.bbclass > > +++ b/meta/classes/kernel.bbclass > > @@ -94,6 +94,22 @@ python __anonymous () { > > d.appendVar('RDEPENDS_%s-image' % kname, ' %s-image-%s' % > > (kname, typelower)) > > d.setVar('PKG_%s-image-%s' % (kname,typelower), '%s-image- > > %s-${KERNEL_VERSION_PKG_NAME}' % (kname, typelower)) > > d.setVar('ALLOW_EMPTY_%s-image-%s' % (kname, typelower), > > '1') > > + d.setVar('pkg_postinst_ontarget_%s-image-%s' % > > (kname,typelower), """ > > You were previously concerned about boot issues if the unversioned > image link/copy was deferred until boot. I don't see a summary of why > that's no longer a concern in the v3 of the patch. Can you confirm > that it isn't an issue ? Is it simply because the booted image isn't > installed via this package, and hence we are fine ? I'm suspecting this patch is why we're seeing selftest failures: https://autobuilder.yoctoproject.org/typhoon/#/builders/86/builds/1055 Cheers, Richard ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [OE-core][PATCH 1/1 v3] classes/kernel: Use a copy of image for kernel*.rpm if fs doesn't support symlinks 2020-06-23 21:51 ` Richard Purdie @ 2020-06-24 1:47 ` Xu, Yanfei 2020-06-24 13:08 ` Richard Purdie 0 siblings, 1 reply; 18+ messages in thread From: Xu, Yanfei @ 2020-06-24 1:47 UTC (permalink / raw) To: Richard Purdie, Bruce Ashfield Cc: Patches and discussions about the oe-core layer On 6/24/20 5:51 AM, Richard Purdie wrote: > On Tue, 2020-06-23 at 10:31 -0400, Bruce Ashfield wrote: >> On Fri, Jun 19, 2020 at 7:47 AM <yanfei.xu@windriver.com> wrote: >>> From: Yanfei Xu <yanfei.xu@windriver.com> >>> >>> Some filesystems don't support symlink, then you will get failure >>> when >>> you install or update the kernel rpm package. Now we use a copy of >>> image for these filesystems instead of symlink. >>> >>> Suggested-by: Bruce Ashfield <bruce.ashfield@gmail.com> >>> Suggested-by: Richard Purdie <richard.purdie@linuxfoundation.org> >>> Signed-off-by: Yanfei Xu <yanfei.xu@windriver.com> >>> --- >>> meta/classes/kernel.bbclass | 19 ++++++++++++++++--- >>> 1 file changed, 16 insertions(+), 3 deletions(-) >>> >>> diff --git a/meta/classes/kernel.bbclass >>> b/meta/classes/kernel.bbclass >>> index 20a0135fc9..1269b54343 100644 >>> --- a/meta/classes/kernel.bbclass >>> +++ b/meta/classes/kernel.bbclass >>> @@ -94,6 +94,22 @@ python __anonymous () { >>> d.appendVar('RDEPENDS_%s-image' % kname, ' %s-image-%s' % >>> (kname, typelower)) >>> d.setVar('PKG_%s-image-%s' % (kname,typelower), '%s-image- >>> %s-${KERNEL_VERSION_PKG_NAME}' % (kname, typelower)) >>> d.setVar('ALLOW_EMPTY_%s-image-%s' % (kname, typelower), >>> '1') >>> + d.setVar('pkg_postinst_ontarget_%s-image-%s' % >>> (kname,typelower), """ >> >> You were previously concerned about boot issues if the unversioned >> image link/copy was deferred until boot. I don't see a summary of why >> that's no longer a concern in the v3 of the patch. Can you confirm >> that it isn't an issue ? Is it simply because the booted image isn't >> installed via this package, and hence we are fine ? > > I'm suspecting this patch is why we're seeing selftest failures: > > https://autobuilder.yoctoproject.org/typhoon/#/builders/86/builds/1055 > Do you mean this patch has been applied? and introduce new issues? Regards, Yanfei > Cheers, > > Richard > ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [OE-core][PATCH 1/1 v3] classes/kernel: Use a copy of image for kernel*.rpm if fs doesn't support symlinks 2020-06-24 1:47 ` Xu, Yanfei @ 2020-06-24 13:08 ` Richard Purdie 2020-06-24 15:57 ` Xu, Yanfei 0 siblings, 1 reply; 18+ messages in thread From: Richard Purdie @ 2020-06-24 13:08 UTC (permalink / raw) To: Xu, Yanfei, Bruce Ashfield Cc: Patches and discussions about the oe-core layer On Wed, 2020-06-24 at 09:47 +0800, Xu, Yanfei wrote: > > On 6/24/20 5:51 AM, Richard Purdie wrote: > > On Tue, 2020-06-23 at 10:31 -0400, Bruce Ashfield wrote: > > > On Fri, Jun 19, 2020 at 7:47 AM <yanfei.xu@windriver.com> wrote: > > > > From: Yanfei Xu <yanfei.xu@windriver.com> > > > > > > > > Some filesystems don't support symlink, then you will get > > > > failure > > > > when > > > > you install or update the kernel rpm package. Now we use a copy > > > > of > > > > image for these filesystems instead of symlink. > > > > > > > > Suggested-by: Bruce Ashfield <bruce.ashfield@gmail.com> > > > > Suggested-by: Richard Purdie < > > > > richard.purdie@linuxfoundation.org> > > > > Signed-off-by: Yanfei Xu <yanfei.xu@windriver.com> > > > > --- > > > > meta/classes/kernel.bbclass | 19 ++++++++++++++++--- > > > > 1 file changed, 16 insertions(+), 3 deletions(-) > > > > > > > > diff --git a/meta/classes/kernel.bbclass > > > > b/meta/classes/kernel.bbclass > > > > index 20a0135fc9..1269b54343 100644 > > > > --- a/meta/classes/kernel.bbclass > > > > +++ b/meta/classes/kernel.bbclass > > > > @@ -94,6 +94,22 @@ python __anonymous () { > > > > d.appendVar('RDEPENDS_%s-image' % kname, ' %s-image- > > > > %s' % > > > > (kname, typelower)) > > > > d.setVar('PKG_%s-image-%s' % (kname,typelower), '%s- > > > > image- > > > > %s-${KERNEL_VERSION_PKG_NAME}' % (kname, typelower)) > > > > d.setVar('ALLOW_EMPTY_%s-image-%s' % (kname, > > > > typelower), > > > > '1') > > > > + d.setVar('pkg_postinst_ontarget_%s-image-%s' % > > > > (kname,typelower), """ > > > > > > You were previously concerned about boot issues if the > > > unversioned > > > image link/copy was deferred until boot. I don't see a summary of > > > why > > > that's no longer a concern in the v3 of the patch. Can you > > > confirm > > > that it isn't an issue ? Is it simply because the booted image > > > isn't > > > installed via this package, and hence we are fine ? > > > > I'm suspecting this patch is why we're seeing selftest failures: > > > > https://autobuilder.yoctoproject.org/typhoon/#/builders/86/builds/1055 > > > Do you mean this patch has been applied? and introduce new issues? Yes, I reverted it and retested and confirmed this patch causes the selftest failure in the link to the build above. Cheers, Richard ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [OE-core][PATCH 1/1 v3] classes/kernel: Use a copy of image for kernel*.rpm if fs doesn't support symlinks 2020-06-24 13:08 ` Richard Purdie @ 2020-06-24 15:57 ` Xu, Yanfei 2020-06-24 16:18 ` Richard Purdie 0 siblings, 1 reply; 18+ messages in thread From: Xu, Yanfei @ 2020-06-24 15:57 UTC (permalink / raw) To: Richard Purdie, Bruce Ashfield Cc: Patches and discussions about the oe-core layer On 6/24/20 9:08 PM, Richard Purdie wrote: > On Wed, 2020-06-24 at 09:47 +0800, Xu, Yanfei wrote: >> >> On 6/24/20 5:51 AM, Richard Purdie wrote: >>> On Tue, 2020-06-23 at 10:31 -0400, Bruce Ashfield wrote: >>>> On Fri, Jun 19, 2020 at 7:47 AM <yanfei.xu@windriver.com> wrote: >>>>> From: Yanfei Xu <yanfei.xu@windriver.com> >>>>> >>>>> Some filesystems don't support symlink, then you will get >>>>> failure >>>>> when >>>>> you install or update the kernel rpm package. Now we use a copy >>>>> of >>>>> image for these filesystems instead of symlink. >>>>> >>>>> Suggested-by: Bruce Ashfield <bruce.ashfield@gmail.com> >>>>> Suggested-by: Richard Purdie < >>>>> richard.purdie@linuxfoundation.org> >>>>> Signed-off-by: Yanfei Xu <yanfei.xu@windriver.com> >>>>> --- >>>>> meta/classes/kernel.bbclass | 19 ++++++++++++++++--- >>>>> 1 file changed, 16 insertions(+), 3 deletions(-) >>>>> >>>>> diff --git a/meta/classes/kernel.bbclass >>>>> b/meta/classes/kernel.bbclass >>>>> index 20a0135fc9..1269b54343 100644 >>>>> --- a/meta/classes/kernel.bbclass >>>>> +++ b/meta/classes/kernel.bbclass >>>>> @@ -94,6 +94,22 @@ python __anonymous () { >>>>> d.appendVar('RDEPENDS_%s-image' % kname, ' %s-image- >>>>> %s' % >>>>> (kname, typelower)) >>>>> d.setVar('PKG_%s-image-%s' % (kname,typelower), '%s- >>>>> image- >>>>> %s-${KERNEL_VERSION_PKG_NAME}' % (kname, typelower)) >>>>> d.setVar('ALLOW_EMPTY_%s-image-%s' % (kname, >>>>> typelower), >>>>> '1') >>>>> + d.setVar('pkg_postinst_ontarget_%s-image-%s' % >>>>> (kname,typelower), """ >>>> >>>> You were previously concerned about boot issues if the >>>> unversioned >>>> image link/copy was deferred until boot. I don't see a summary of >>>> why >>>> that's no longer a concern in the v3 of the patch. Can you >>>> confirm >>>> that it isn't an issue ? Is it simply because the booted image >>>> isn't >>>> installed via this package, and hence we are fine ? >>> >>> I'm suspecting this patch is why we're seeing selftest failures: >>> >>> https://autobuilder.yoctoproject.org/typhoon/#/builders/86/builds/1055 >>> >> Do you mean this patch has been applied? and introduce new issues? > > Yes, I reverted it and retested and confirmed this patch causes the > selftest failure in the link to the build above. > OK, I am trying to analyse the log. But I haven't figured out what cause it fialed， and how to reproduce it on my mechine. I'd apprecate any information. Regards， Yanfei > Cheers, > > Richard > ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [OE-core][PATCH 1/1 v3] classes/kernel: Use a copy of image for kernel*.rpm if fs doesn't support symlinks 2020-06-24 15:57 ` Xu, Yanfei @ 2020-06-24 16:18 ` Richard Purdie 2020-06-28 12:21 ` Xu, Yanfei 0 siblings, 1 reply; 18+ messages in thread From: Richard Purdie @ 2020-06-24 16:18 UTC (permalink / raw) To: Xu, Yanfei, Bruce Ashfield Cc: Patches and discussions about the oe-core layer On Wed, 2020-06-24 at 23:57 +0800, Xu, Yanfei wrote: > > On 6/24/20 9:08 PM, Richard Purdie wrote: > > On Wed, 2020-06-24 at 09:47 +0800, Xu, Yanfei wrote: > > > On 6/24/20 5:51 AM, Richard Purdie wrote: > > > > On Tue, 2020-06-23 at 10:31 -0400, Bruce Ashfield wrote: > > > > > On Fri, Jun 19, 2020 at 7:47 AM <yanfei.xu@windriver.com> > > > > > wrote: > > > > > > From: Yanfei Xu <yanfei.xu@windriver.com> > > > > > > > > > > > > Some filesystems don't support symlink, then you will get > > > > > > failure > > > > > > when > > > > > > you install or update the kernel rpm package. Now we use a > > > > > > copy > > > > > > of > > > > > > image for these filesystems instead of symlink. > > > > > > > > > > > > Suggested-by: Bruce Ashfield <bruce.ashfield@gmail.com> > > > > > > Suggested-by: Richard Purdie < > > > > > > richard.purdie@linuxfoundation.org> > > > > > > Signed-off-by: Yanfei Xu <yanfei.xu@windriver.com> > > > > > > --- > > > > > > meta/classes/kernel.bbclass | 19 ++++++++++++++++--- > > > > > > 1 file changed, 16 insertions(+), 3 deletions(-) > > > > > > > > > > > > diff --git a/meta/classes/kernel.bbclass > > > > > > b/meta/classes/kernel.bbclass > > > > > > index 20a0135fc9..1269b54343 100644 > > > > > > --- a/meta/classes/kernel.bbclass > > > > > > +++ b/meta/classes/kernel.bbclass > > > > > > @@ -94,6 +94,22 @@ python __anonymous () { > > > > > > d.appendVar('RDEPENDS_%s-image' % kname, ' %s- > > > > > > image- > > > > > > %s' % > > > > > > (kname, typelower)) > > > > > > d.setVar('PKG_%s-image-%s' % (kname,typelower), > > > > > > '%s- > > > > > > image- > > > > > > %s-${KERNEL_VERSION_PKG_NAME}' % (kname, typelower)) > > > > > > d.setVar('ALLOW_EMPTY_%s-image-%s' % (kname, > > > > > > typelower), > > > > > > '1') > > > > > > + d.setVar('pkg_postinst_ontarget_%s-image-%s' % > > > > > > (kname,typelower), """ > > > > > > > > > > You were previously concerned about boot issues if the > > > > > unversioned > > > > > image link/copy was deferred until boot. I don't see a > > > > > summary of > > > > > why > > > > > that's no longer a concern in the v3 of the patch. Can you > > > > > confirm > > > > > that it isn't an issue ? Is it simply because the booted > > > > > image > > > > > isn't > > > > > installed via this package, and hence we are fine ? > > > > > > > > I'm suspecting this patch is why we're seeing selftest > > > > failures: > > > > > > > > https://autobuilder.yoctoproject.org/typhoon/#/builders/86/builds/1055 > > > > > > > Do you mean this patch has been applied? and introduce new > > > issues? > > > > Yes, I reverted it and retested and confirmed this patch causes the > > selftest failure in the link to the build above. > > > OK, I am trying to analyse the log. But I haven't figured out what > cause > it fialed， and how to reproduce it on my mechine. I'd apprecate any > information. The command to reproduce should be: oe-selftest -r efibootpartition.GenericEFITest.test_boot_efi Cheers, Richard ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [OE-core][PATCH 1/1 v3] classes/kernel: Use a copy of image for kernel*.rpm if fs doesn't support symlinks 2020-06-24 16:18 ` Richard Purdie @ 2020-06-28 12:21 ` Xu, Yanfei 2020-07-01 8:22 ` Xu, Yanfei 0 siblings, 1 reply; 18+ messages in thread From: Xu, Yanfei @ 2020-06-28 12:21 UTC (permalink / raw) To: Richard Purdie, Bruce Ashfield Cc: Patches and discussions about the oe-core layer On 6/25/20 12:18 AM, Richard Purdie wrote: > On Wed, 2020-06-24 at 23:57 +0800, Xu, Yanfei wrote: >> >> On 6/24/20 9:08 PM, Richard Purdie wrote: >>> On Wed, 2020-06-24 at 09:47 +0800, Xu, Yanfei wrote: >>>> On 6/24/20 5:51 AM, Richard Purdie wrote: >>>>> On Tue, 2020-06-23 at 10:31 -0400, Bruce Ashfield wrote: >>>>>> On Fri, Jun 19, 2020 at 7:47 AM <yanfei.xu@windriver.com> >>>>>> wrote: >>>>>>> From: Yanfei Xu <yanfei.xu@windriver.com> >>>>>>> >>>>>>> Some filesystems don't support symlink, then you will get >>>>>>> failure >>>>>>> when >>>>>>> you install or update the kernel rpm package. Now we use a >>>>>>> copy >>>>>>> of >>>>>>> image for these filesystems instead of symlink. >>>>>>> >>>>>>> Suggested-by: Bruce Ashfield <bruce.ashfield@gmail.com> >>>>>>> Suggested-by: Richard Purdie < >>>>>>> richard.purdie@linuxfoundation.org> >>>>>>> Signed-off-by: Yanfei Xu <yanfei.xu@windriver.com> >>>>>>> --- >>>>>>> meta/classes/kernel.bbclass | 19 ++++++++++++++++--- >>>>>>> 1 file changed, 16 insertions(+), 3 deletions(-) >>>>>>> >>>>>>> diff --git a/meta/classes/kernel.bbclass >>>>>>> b/meta/classes/kernel.bbclass >>>>>>> index 20a0135fc9..1269b54343 100644 >>>>>>> --- a/meta/classes/kernel.bbclass >>>>>>> +++ b/meta/classes/kernel.bbclass >>>>>>> @@ -94,6 +94,22 @@ python __anonymous () { >>>>>>> d.appendVar('RDEPENDS_%s-image' % kname, ' %s- >>>>>>> image- >>>>>>> %s' % >>>>>>> (kname, typelower)) >>>>>>> d.setVar('PKG_%s-image-%s' % (kname,typelower), >>>>>>> '%s- >>>>>>> image- >>>>>>> %s-${KERNEL_VERSION_PKG_NAME}' % (kname, typelower)) >>>>>>> d.setVar('ALLOW_EMPTY_%s-image-%s' % (kname, >>>>>>> typelower), >>>>>>> '1') >>>>>>> + d.setVar('pkg_postinst_ontarget_%s-image-%s' % >>>>>>> (kname,typelower), """ >>>>>> >>>>>> You were previously concerned about boot issues if the >>>>>> unversioned >>>>>> image link/copy was deferred until boot. I don't see a >>>>>> summary of >>>>>> why >>>>>> that's no longer a concern in the v3 of the patch. Can you >>>>>> confirm >>>>>> that it isn't an issue ? Is it simply because the booted >>>>>> image >>>>>> isn't >>>>>> installed via this package, and hence we are fine ? >>>>> >>>>> I'm suspecting this patch is why we're seeing selftest >>>>> failures: >>>>> >>>>> https://autobuilder.yoctoproject.org/typhoon/#/builders/86/builds/1055 >>>>> >>>> Do you mean this patch has been applied? and introduce new >>>> issues? >>> >>> Yes, I reverted it and retested and confirmed this patch causes the >>> selftest failure in the link to the build above. >>> >> OK, I am trying to analyse the log. But I haven't figured out what >> cause >> it fialed， and how to reproduce it on my mechine. I'd apprecate any >> information. > > The command to reproduce should be: > > oe-selftest -r efibootpartition.GenericEFITest.test_boot_efi > I've addressed this failure why due to boot partation in wic doesn't contain no-versioned image. This result is different from the previous I verified, because of the different configuraions in wks. "--source" field in wks decides where the files in boot partation come from. So no-versioned image may come from ${IMAGE_ROOTFS}/boot which is installed by rpm package. Blow is the wks used by 'oe-selftest -r efibootpartition.GenericEFITest.test_boot_efi' bootloader --ptable gpt part /boot --source rootfs --rootfs-dir=${IMAGE_ROOTFS}/boot --fstype=vfat --label boot --active --align 1024 --use-uuid --overhead-factor 1.0 part / --source rootfs --fstype=ext4 --label root --align 1024 --exclude-path boot/ Hence we still should keep the no-versioned iamge in kernel-image*.rpm which is like the previous v2 patch. Cheers， Yanfei > Cheers, > > Richard > ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [OE-core][PATCH 1/1 v3] classes/kernel: Use a copy of image for kernel*.rpm if fs doesn't support symlinks 2020-06-28 12:21 ` Xu, Yanfei @ 2020-07-01 8:22 ` Xu, Yanfei 2020-07-01 13:42 ` Bruce Ashfield 0 siblings, 1 reply; 18+ messages in thread From: Xu, Yanfei @ 2020-07-01 8:22 UTC (permalink / raw) To: Richard Purdie, Bruce Ashfield Cc: Patches and discussions about the oe-core layer On 6/28/20 8:21 PM, Xu, Yanfei wrote: > > > On 6/25/20 12:18 AM, Richard Purdie wrote: >> On Wed, 2020-06-24 at 23:57 +0800, Xu, Yanfei wrote: >>> >>> On 6/24/20 9:08 PM, Richard Purdie wrote: >>>> On Wed, 2020-06-24 at 09:47 +0800, Xu, Yanfei wrote: >>>>> On 6/24/20 5:51 AM, Richard Purdie wrote: >>>>>> On Tue, 2020-06-23 at 10:31 -0400, Bruce Ashfield wrote: >>>>>>> On Fri, Jun 19, 2020 at 7:47 AM <yanfei.xu@windriver.com> >>>>>>> wrote: >>>>>>>> From: Yanfei Xu <yanfei.xu@windriver.com> >>>>>>>> >>>>>>>> Some filesystems don't support symlink, then you will get >>>>>>>> failure >>>>>>>> when >>>>>>>> you install or update the kernel rpm package. Now we use a >>>>>>>> copy >>>>>>>> of >>>>>>>> image for these filesystems instead of symlink. >>>>>>>> >>>>>>>> Suggested-by: Bruce Ashfield <bruce.ashfield@gmail.com> >>>>>>>> Suggested-by: Richard Purdie < >>>>>>>> richard.purdie@linuxfoundation.org> >>>>>>>> Signed-off-by: Yanfei Xu <yanfei.xu@windriver.com> >>>>>>>> --- >>>>>>>> meta/classes/kernel.bbclass | 19 ++++++++++++++++--- >>>>>>>> 1 file changed, 16 insertions(+), 3 deletions(-) >>>>>>>> >>>>>>>> diff --git a/meta/classes/kernel.bbclass >>>>>>>> b/meta/classes/kernel.bbclass >>>>>>>> index 20a0135fc9..1269b54343 100644 >>>>>>>> --- a/meta/classes/kernel.bbclass >>>>>>>> +++ b/meta/classes/kernel.bbclass >>>>>>>> @@ -94,6 +94,22 @@ python __anonymous () { >>>>>>>> d.appendVar('RDEPENDS_%s-image' % kname, ' %s- >>>>>>>> image- >>>>>>>> %s' % >>>>>>>> (kname, typelower)) >>>>>>>> d.setVar('PKG_%s-image-%s' % (kname,typelower), >>>>>>>> '%s- >>>>>>>> image- >>>>>>>> %s-${KERNEL_VERSION_PKG_NAME}' % (kname, typelower)) >>>>>>>> d.setVar('ALLOW_EMPTY_%s-image-%s' % (kname, >>>>>>>> typelower), >>>>>>>> '1') >>>>>>>> + d.setVar('pkg_postinst_ontarget_%s-image-%s' % >>>>>>>> (kname,typelower), """ >>>>>>> >>>>>>> You were previously concerned about boot issues if the >>>>>>> unversioned >>>>>>> image link/copy was deferred until boot. I don't see a >>>>>>> summary of >>>>>>> why >>>>>>> that's no longer a concern in the v3 of the patch. Can you >>>>>>> confirm >>>>>>> that it isn't an issue ? Is it simply because the booted >>>>>>> image >>>>>>> isn't >>>>>>> installed via this package, and hence we are fine ? >>>>>> >>>>>> I'm suspecting this patch is why we're seeing selftest >>>>>> failures: >>>>>> >>>>>> https://autobuilder.yoctoproject.org/typhoon/#/builders/86/builds/1055 >>>>>> >>>>>> >>>>> Do you mean this patch has been applied? and introduce new >>>>> issues? >>>> >>>> Yes, I reverted it and retested and confirmed this patch causes the >>>> selftest failure in the link to the build above. >>>> >>> OK, I am trying to analyse the log. But I haven't figured out what >>> cause >>> it fialed， and how to reproduce it on my mechine. I'd apprecate any >>> information. >> >> The command to reproduce should be: >> >> oe-selftest -r efibootpartition.GenericEFITest.test_boot_efi >> > I've addressed this failure why due to boot partation in wic doesn't > contain no-versioned image. This result is different from the previous > I verified, because of the different configuraions in wks. > > "--source" field in wks decides where the files in boot partation come > from. So no-versioned image may come from ${IMAGE_ROOTFS}/boot which is > installed by rpm package. Blow is the wks used by 'oe-selftest -r > efibootpartition.GenericEFITest.test_boot_efi' > > bootloader --ptable gpt > part /boot --source rootfs --rootfs-dir=${IMAGE_ROOTFS}/boot > --fstype=vfat --label boot --active --align 1024 --use-uuid > --overhead-factor 1.0 > part / --source rootfs --fstype=ext4 --label root --align 1024 > --exclude-path boot/ > > Hence we still should keep the no-versioned iamge in kernel-image*.rpm > which is like the previous v2 patch. > Any opinions? It does cause the kernel rpm larger. However, the kernel image is not always large, only a few MB. And it will be changed to symlink when installed on targe. So this patch's only negative effect is the little increasement about update payloads. BTW, should I resend the v2 patch? Cheers, Yanfei > Cheers， > > Yanfei > >> Cheers, >> >> Richard >> ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [OE-core][PATCH 1/1 v3] classes/kernel: Use a copy of image for kernel*.rpm if fs doesn't support symlinks 2020-07-01 8:22 ` Xu, Yanfei @ 2020-07-01 13:42 ` Bruce Ashfield 2020-07-02 2:43 ` Xu, Yanfei 0 siblings, 1 reply; 18+ messages in thread From: Bruce Ashfield @ 2020-07-01 13:42 UTC (permalink / raw) To: Xu, Yanfei Cc: Richard Purdie, Patches and discussions about the oe-core layer On Wed, Jul 1, 2020 at 4:22 AM Xu, Yanfei <yanfei.xu@windriver.com> wrote: > > > > On 6/28/20 8:21 PM, Xu, Yanfei wrote: > > > > > > On 6/25/20 12:18 AM, Richard Purdie wrote: > >> On Wed, 2020-06-24 at 23:57 +0800, Xu, Yanfei wrote: > >>> > >>> On 6/24/20 9:08 PM, Richard Purdie wrote: > >>>> On Wed, 2020-06-24 at 09:47 +0800, Xu, Yanfei wrote: > >>>>> On 6/24/20 5:51 AM, Richard Purdie wrote: > >>>>>> On Tue, 2020-06-23 at 10:31 -0400, Bruce Ashfield wrote: > >>>>>>> On Fri, Jun 19, 2020 at 7:47 AM <yanfei.xu@windriver.com> > >>>>>>> wrote: > >>>>>>>> From: Yanfei Xu <yanfei.xu@windriver.com> > >>>>>>>> > >>>>>>>> Some filesystems don't support symlink, then you will get > >>>>>>>> failure > >>>>>>>> when > >>>>>>>> you install or update the kernel rpm package. Now we use a > >>>>>>>> copy > >>>>>>>> of > >>>>>>>> image for these filesystems instead of symlink. > >>>>>>>> > >>>>>>>> Suggested-by: Bruce Ashfield <bruce.ashfield@gmail.com> > >>>>>>>> Suggested-by: Richard Purdie < > >>>>>>>> richard.purdie@linuxfoundation.org> > >>>>>>>> Signed-off-by: Yanfei Xu <yanfei.xu@windriver.com> > >>>>>>>> --- > >>>>>>>> meta/classes/kernel.bbclass | 19 ++++++++++++++++--- > >>>>>>>> 1 file changed, 16 insertions(+), 3 deletions(-) > >>>>>>>> > >>>>>>>> diff --git a/meta/classes/kernel.bbclass > >>>>>>>> b/meta/classes/kernel.bbclass > >>>>>>>> index 20a0135fc9..1269b54343 100644 > >>>>>>>> --- a/meta/classes/kernel.bbclass > >>>>>>>> +++ b/meta/classes/kernel.bbclass > >>>>>>>> @@ -94,6 +94,22 @@ python __anonymous () { > >>>>>>>> d.appendVar('RDEPENDS_%s-image' % kname, ' %s- > >>>>>>>> image- > >>>>>>>> %s' % > >>>>>>>> (kname, typelower)) > >>>>>>>> d.setVar('PKG_%s-image-%s' % (kname,typelower), > >>>>>>>> '%s- > >>>>>>>> image- > >>>>>>>> %s-${KERNEL_VERSION_PKG_NAME}' % (kname, typelower)) > >>>>>>>> d.setVar('ALLOW_EMPTY_%s-image-%s' % (kname, > >>>>>>>> typelower), > >>>>>>>> '1') > >>>>>>>> + d.setVar('pkg_postinst_ontarget_%s-image-%s' % > >>>>>>>> (kname,typelower), """ > >>>>>>> > >>>>>>> You were previously concerned about boot issues if the > >>>>>>> unversioned > >>>>>>> image link/copy was deferred until boot. I don't see a > >>>>>>> summary of > >>>>>>> why > >>>>>>> that's no longer a concern in the v3 of the patch. Can you > >>>>>>> confirm > >>>>>>> that it isn't an issue ? Is it simply because the booted > >>>>>>> image > >>>>>>> isn't > >>>>>>> installed via this package, and hence we are fine ? > >>>>>> > >>>>>> I'm suspecting this patch is why we're seeing selftest > >>>>>> failures: > >>>>>> > >>>>>> https://autobuilder.yoctoproject.org/typhoon/#/builders/86/builds/1055 > >>>>>> > >>>>>> > >>>>> Do you mean this patch has been applied? and introduce new > >>>>> issues? > >>>> > >>>> Yes, I reverted it and retested and confirmed this patch causes the > >>>> selftest failure in the link to the build above. > >>>> > >>> OK, I am trying to analyse the log. But I haven't figured out what > >>> cause > >>> it fialed， and how to reproduce it on my mechine. I'd apprecate any > >>> information. > >> > >> The command to reproduce should be: > >> > >> oe-selftest -r efibootpartition.GenericEFITest.test_boot_efi > >> > > I've addressed this failure why due to boot partation in wic doesn't > > contain no-versioned image. This result is different from the previous > > I verified, because of the different configuraions in wks. > > > > "--source" field in wks decides where the files in boot partation come > > from. So no-versioned image may come from ${IMAGE_ROOTFS}/boot which is > > installed by rpm package. Blow is the wks used by 'oe-selftest -r > > efibootpartition.GenericEFITest.test_boot_efi' > > > > bootloader --ptable gpt > > part /boot --source rootfs --rootfs-dir=${IMAGE_ROOTFS}/boot > > --fstype=vfat --label boot --active --align 1024 --use-uuid > > --overhead-factor 1.0 > > part / --source rootfs --fstype=ext4 --label root --align 1024 > > --exclude-path boot/ > > > > Hence we still should keep the no-versioned iamge in kernel-image*.rpm > > which is like the previous v2 patch. > > > Any opinions? It does cause the kernel rpm larger. However, the kernel > image is not always large, only a few MB. And it will be changed to > symlink when installed on targe. So this patch's only negative effect > is the little increasement about update payloads. I'm trying to follow the description that you had about the oe-selftest and I'm missing something. Can you describe it again ? In a way that someone not familiar with that the selftest is seeing as a failure can grok ? i.e. in the selftest configuration are we not getting the (un)versioned kernel image because the symlink (or copy fallback) is in an on-boot post install hook ? And the test is looking for the versioned/unversioned kernel image at image construction time ? So that leaves us at either installing both the versioned and unversioned, or some sort of package install time testing of the target filesystem ? Does that partition exist at package install time ? Is that the approach we tried in v1 of the patch (I know v2 was keeping both as copies in the package, and converting it to a symlink on boot). Bruce > > BTW, should I resend the v2 patch? > > Cheers, > > Yanfei > > > Cheers， > > > > Yanfei > > > >> Cheers, > >> > >> Richard > >> -- - Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end - "Use the force Harry" - Gandalf, Star Trek II ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [OE-core][PATCH 1/1 v3] classes/kernel: Use a copy of image for kernel*.rpm if fs doesn't support symlinks 2020-07-01 13:42 ` Bruce Ashfield @ 2020-07-02 2:43 ` Xu, Yanfei 2020-07-02 7:46 ` Richard Purdie 0 siblings, 1 reply; 18+ messages in thread From: Xu, Yanfei @ 2020-07-02 2:43 UTC (permalink / raw) To: Bruce Ashfield Cc: Richard Purdie, Patches and discussions about the oe-core layer On 7/1/20 9:42 PM, Bruce Ashfield wrote: > On Wed, Jul 1, 2020 at 4:22 AM Xu, Yanfei <yanfei.xu@windriver.com> wrote: >> >> >> >> On 6/28/20 8:21 PM, Xu, Yanfei wrote: >>> >>> >>> On 6/25/20 12:18 AM, Richard Purdie wrote: >>>> On Wed, 2020-06-24 at 23:57 +0800, Xu, Yanfei wrote: >>>>> >>>>> On 6/24/20 9:08 PM, Richard Purdie wrote: >>>>>> On Wed, 2020-06-24 at 09:47 +0800, Xu, Yanfei wrote: >>>>>>> On 6/24/20 5:51 AM, Richard Purdie wrote: >>>>>>>> On Tue, 2020-06-23 at 10:31 -0400, Bruce Ashfield wrote: >>>>>>>>> On Fri, Jun 19, 2020 at 7:47 AM <yanfei.xu@windriver.com> >>>>>>>>> wrote: >>>>>>>>>> From: Yanfei Xu <yanfei.xu@windriver.com> >>>>>>>>>> >>>>>>>>>> Some filesystems don't support symlink, then you will get >>>>>>>>>> failure >>>>>>>>>> when >>>>>>>>>> you install or update the kernel rpm package. Now we use a >>>>>>>>>> copy >>>>>>>>>> of >>>>>>>>>> image for these filesystems instead of symlink. >>>>>>>>>> >>>>>>>>>> Suggested-by: Bruce Ashfield <bruce.ashfield@gmail.com> >>>>>>>>>> Suggested-by: Richard Purdie < >>>>>>>>>> richard.purdie@linuxfoundation.org> >>>>>>>>>> Signed-off-by: Yanfei Xu <yanfei.xu@windriver.com> >>>>>>>>>> --- >>>>>>>>>> meta/classes/kernel.bbclass | 19 ++++++++++++++++--- >>>>>>>>>> 1 file changed, 16 insertions(+), 3 deletions(-) >>>>>>>>>> >>>>>>>>>> diff --git a/meta/classes/kernel.bbclass >>>>>>>>>> b/meta/classes/kernel.bbclass >>>>>>>>>> index 20a0135fc9..1269b54343 100644 >>>>>>>>>> --- a/meta/classes/kernel.bbclass >>>>>>>>>> +++ b/meta/classes/kernel.bbclass >>>>>>>>>> @@ -94,6 +94,22 @@ python __anonymous () { >>>>>>>>>> d.appendVar('RDEPENDS_%s-image' % kname, ' %s- >>>>>>>>>> image- >>>>>>>>>> %s' % >>>>>>>>>> (kname, typelower)) >>>>>>>>>> d.setVar('PKG_%s-image-%s' % (kname,typelower), >>>>>>>>>> '%s- >>>>>>>>>> image- >>>>>>>>>> %s-${KERNEL_VERSION_PKG_NAME}' % (kname, typelower)) >>>>>>>>>> d.setVar('ALLOW_EMPTY_%s-image-%s' % (kname, >>>>>>>>>> typelower), >>>>>>>>>> '1') >>>>>>>>>> + d.setVar('pkg_postinst_ontarget_%s-image-%s' % >>>>>>>>>> (kname,typelower), """ >>>>>>>>> >>>>>>>>> You were previously concerned about boot issues if the >>>>>>>>> unversioned >>>>>>>>> image link/copy was deferred until boot. I don't see a >>>>>>>>> summary of >>>>>>>>> why >>>>>>>>> that's no longer a concern in the v3 of the patch. Can you >>>>>>>>> confirm >>>>>>>>> that it isn't an issue ? Is it simply because the booted >>>>>>>>> image >>>>>>>>> isn't >>>>>>>>> installed via this package, and hence we are fine ? >>>>>>>> >>>>>>>> I'm suspecting this patch is why we're seeing selftest >>>>>>>> failures: >>>>>>>> >>>>>>>> https://autobuilder.yoctoproject.org/typhoon/#/builders/86/builds/1055 >>>>>>>> >>>>>>>> >>>>>>> Do you mean this patch has been applied? and introduce new >>>>>>> issues? >>>>>> >>>>>> Yes, I reverted it and retested and confirmed this patch causes the >>>>>> selftest failure in the link to the build above. >>>>>> >>>>> OK, I am trying to analyse the log. But I haven't figured out what >>>>> cause >>>>> it fialed， and how to reproduce it on my mechine. I'd apprecate any >>>>> information. >>>> >>>> The command to reproduce should be: >>>> >>>> oe-selftest -r efibootpartition.GenericEFITest.test_boot_efi >>>> >>> I've addressed this failure why due to boot partation in wic doesn't >>> contain no-versioned image. This result is different from the previous >>> I verified, because of the different configuraions in wks. >>> >>> "--source" field in wks decides where the files in boot partation come >>> from. So no-versioned image may come from ${IMAGE_ROOTFS}/boot which is >>> installed by rpm package. Blow is the wks used by 'oe-selftest -r >>> efibootpartition.GenericEFITest.test_boot_efi' >>> >>> bootloader --ptable gpt >>> part /boot --source rootfs --rootfs-dir=${IMAGE_ROOTFS}/boot >>> --fstype=vfat --label boot --active --align 1024 --use-uuid >>> --overhead-factor 1.0 >>> part / --source rootfs --fstype=ext4 --label root --align 1024 >>> --exclude-path boot/ >>> >>> Hence we still should keep the no-versioned iamge in kernel-image*.rpm >>> which is like the previous v2 patch. >>> >> Any opinions? It does cause the kernel rpm larger. However, the kernel >> image is not always large, only a few MB. And it will be changed to >> symlink when installed on targe. So this patch's only negative effect >> is the little increasement about update payloads. > > I'm trying to follow the description that you had about the > oe-selftest and I'm missing something. > > Can you describe it again ? In a way that someone not familiar with > that the selftest is seeing as a failure can grok ? > > i.e. in the selftest configuration are we not getting the > (un)versioned kernel image because the symlink (or copy fallback) is > in an on-boot post install hook ? And the test is looking for the > versioned/unversioned kernel image at image construction time ? > > So that leaves us at either installing both the versioned and > unversioned, or some sort of package install time testing of the > target filesystem ? Does that partition exist at package install time > ? Is that the approach we tried in v1 of the patch (I know v2 was > keeping both as copies in the package, and converting it to a symlink > on boot). Sorry for the uncleared discription. For the os-selftest failure: The failure happened at qemu booting with its wic image. Qemu could not find the unversioned kernel image in wic image for booting itself ,then caused the test failed. Why the booted partition in wic image doesn't contain the unversioned kernel image? Cause the wks can decide where the unversioned kernel images in wic image comes from. For this test, it comes from ${IMAGE_ROOTFS}/boot which is installed by kernel rpm package. Actually it didn't get unversioned kernel image because the symlink（or copy fallback） is in an on-boot post install hook. Hence we should keep a unversioned kernel image in kernel rpm package. And patch v2 did it.（ v1 and v2 are similar, but v2 improves print messages.） Yanfei > > Bruce > >> >> BTW, should I resend the v2 patch? >> >> Cheers, >> >> Yanfei >> >>> Cheers， >>> >>> Yanfei >>> >>>> Cheers, >>>> >>>> Richard >>>> > -- > - Thou shalt not follow the NULL pointer, for chaos and madness await > thee at its end > - "Use the force Harry" - Gandalf, Star Trek II > ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [OE-core][PATCH 1/1 v3] classes/kernel: Use a copy of image for kernel*.rpm if fs doesn't support symlinks 2020-07-02 2:43 ` Xu, Yanfei @ 2020-07-02 7:46 ` Richard Purdie 2020-07-02 9:49 ` Xu, Yanfei 0 siblings, 1 reply; 18+ messages in thread From: Richard Purdie @ 2020-07-02 7:46 UTC (permalink / raw) To: Xu, Yanfei, Bruce Ashfield Cc: Patches and discussions about the oe-core layer On Thu, 2020-07-02 at 10:43 +0800, Xu, Yanfei wrote: > > On 7/1/20 9:42 PM, Bruce Ashfield wrote: > > On Wed, Jul 1, 2020 at 4:22 AM Xu, Yanfei <yanfei.xu@windriver.com> > > wrote: > > > > > > > > > On 6/28/20 8:21 PM, Xu, Yanfei wrote: > > > > > > > > On 6/25/20 12:18 AM, Richard Purdie wrote: > > > > > On Wed, 2020-06-24 at 23:57 +0800, Xu, Yanfei wrote: > > > > > > On 6/24/20 9:08 PM, Richard Purdie wrote: > > > > > > > On Wed, 2020-06-24 at 09:47 +0800, Xu, Yanfei wrote: > > > > > > > > On 6/24/20 5:51 AM, Richard Purdie wrote: > > > > > > > > > On Tue, 2020-06-23 at 10:31 -0400, Bruce Ashfield > > > > > > > > > wrote: > > > > > > > > > > On Fri, Jun 19, 2020 at 7:47 AM < > > > > > > > > > > yanfei.xu@windriver.com> > > > > > > > > > > wrote: > > > > > > > > > > > From: Yanfei Xu <yanfei.xu@windriver.com> > > > > > > > > > > > > > > > > > > > > > > Some filesystems don't support symlink, then you > > > > > > > > > > > will get > > > > > > > > > > > failure > > > > > > > > > > > when > > > > > > > > > > > you install or update the kernel rpm package. Now > > > > > > > > > > > we use a > > > > > > > > > > > copy > > > > > > > > > > > of > > > > > > > > > > > image for these filesystems instead of symlink. > > > > > > > > > > > > > > > > > > > > > > Suggested-by: Bruce Ashfield < > > > > > > > > > > > bruce.ashfield@gmail.com> > > > > > > > > > > > Suggested-by: Richard Purdie < > > > > > > > > > > > richard.purdie@linuxfoundation.org> > > > > > > > > > > > Signed-off-by: Yanfei Xu <yanfei.xu@windriver.com > > > > > > > > > > > > > > > > > > > > > > > --- > > > > > > > > > > > meta/classes/kernel.bbclass | 19 > > > > > > > > > > > ++++++++++++++++--- > > > > > > > > > > > 1 file changed, 16 insertions(+), 3 > > > > > > > > > > > deletions(-) > > > > > > > > > > > > > > > > > > > > > > diff --git a/meta/classes/kernel.bbclass > > > > > > > > > > > b/meta/classes/kernel.bbclass > > > > > > > > > > > index 20a0135fc9..1269b54343 100644 > > > > > > > > > > > --- a/meta/classes/kernel.bbclass > > > > > > > > > > > +++ b/meta/classes/kernel.bbclass > > > > > > > > > > > @@ -94,6 +94,22 @@ python __anonymous () { > > > > > > > > > > > d.appendVar('RDEPENDS_%s-image' % > > > > > > > > > > > kname, ' %s- > > > > > > > > > > > image- > > > > > > > > > > > %s' % > > > > > > > > > > > (kname, typelower)) > > > > > > > > > > > d.setVar('PKG_%s-image-%s' % > > > > > > > > > > > (kname,typelower), > > > > > > > > > > > '%s- > > > > > > > > > > > image- > > > > > > > > > > > %s-${KERNEL_VERSION_PKG_NAME}' % (kname, > > > > > > > > > > > typelower)) > > > > > > > > > > > d.setVar('ALLOW_EMPTY_%s-image-%s' % > > > > > > > > > > > (kname, > > > > > > > > > > > typelower), > > > > > > > > > > > '1') > > > > > > > > > > > + d.setVar('pkg_postinst_ontarget_%s- > > > > > > > > > > > image-%s' % > > > > > > > > > > > (kname,typelower), """ > > > > > > > > > > > > > > > > > > > > You were previously concerned about boot issues if > > > > > > > > > > the > > > > > > > > > > unversioned > > > > > > > > > > image link/copy was deferred until boot. I don't > > > > > > > > > > see a > > > > > > > > > > summary of > > > > > > > > > > why > > > > > > > > > > that's no longer a concern in the v3 of the patch. > > > > > > > > > > Can you > > > > > > > > > > confirm > > > > > > > > > > that it isn't an issue ? Is it simply because the > > > > > > > > > > booted > > > > > > > > > > image > > > > > > > > > > isn't > > > > > > > > > > installed via this package, and hence we are fine ? > > > > > > > > > > > > > > > > > > I'm suspecting this patch is why we're seeing > > > > > > > > > selftest > > > > > > > > > failures: > > > > > > > > > > > > > > > > > > https://autobuilder.yoctoproject.org/typhoon/#/builders/86/builds/1055 > > > > > > > > > > > > > > > > > > > > > > > > > > Do you mean this patch has been applied? and introduce > > > > > > > > new > > > > > > > > issues? > > > > > > > > > > > > > > Yes, I reverted it and retested and confirmed this patch > > > > > > > causes the > > > > > > > selftest failure in the link to the build above. > > > > > > > > > > > > > OK, I am trying to analyse the log. But I haven't figured > > > > > > out what > > > > > > cause > > > > > > it fialed， and how to reproduce it on my mechine. I'd > > > > > > apprecate any > > > > > > information. > > > > > > > > > > The command to reproduce should be: > > > > > > > > > > oe-selftest -r efibootpartition.GenericEFITest.test_boot_efi > > > > > > > > > I've addressed this failure why due to boot partation in wic > > > > doesn't > > > > contain no-versioned image. This result is different from the > > > > previous > > > > I verified, because of the different configuraions in wks. > > > > > > > > "--source" field in wks decides where the files in boot > > > > partation come > > > > from. So no-versioned image may come from ${IMAGE_ROOTFS}/boot > > > > which is > > > > installed by rpm package. Blow is the wks used by 'oe-selftest > > > > -r > > > > efibootpartition.GenericEFITest.test_boot_efi' > > > > > > > > bootloader --ptable gpt > > > > part /boot --source rootfs --rootfs-dir=${IMAGE_ROOTFS}/boot > > > > --fstype=vfat --label boot --active --align 1024 --use-uuid > > > > --overhead-factor 1.0 > > > > part / --source rootfs --fstype=ext4 --label root --align 1024 > > > > --exclude-path boot/ > > > > > > > > Hence we still should keep the no-versioned iamge in kernel- > > > > image*.rpm > > > > which is like the previous v2 patch. > > > > > > > Any opinions? It does cause the kernel rpm larger. However, the > > > kernel > > > image is not always large, only a few MB. And it will be changed > > > to > > > symlink when installed on targe. So this patch's only negative > > > effect > > > is the little increasement about update payloads. > > > > I'm trying to follow the description that you had about the > > oe-selftest and I'm missing something. > > > > Can you describe it again ? In a way that someone not familiar with > > that the selftest is seeing as a failure can grok ? > > > > i.e. in the selftest configuration are we not getting the > > (un)versioned kernel image because the symlink (or copy fallback) > > is > > in an on-boot post install hook ? And the test is looking for the > > versioned/unversioned kernel image at image construction time ? > > > > So that leaves us at either installing both the versioned and > > unversioned, or some sort of package install time testing of the > > target filesystem ? Does that partition exist at package install > > time > > ? Is that the approach we tried in v1 of the patch (I know v2 was > > keeping both as copies in the package, and converting it to a > > symlink > > on boot). > > Sorry for the uncleared discription. > > For the os-selftest failure: The failure happened at qemu booting > with > its wic image. Qemu could not find the unversioned kernel image in > wic > image for booting itself ,then caused the test failed. > > Why the booted partition in wic image doesn't contain the unversioned > kernel image? Cause the wks can decide where the unversioned kernel > images in wic image comes from. For this test, it comes from > ${IMAGE_ROOTFS}/boot which is installed by kernel rpm package. > Actually > it didn't get unversioned kernel image because the symlink（or copy > fallback） is in an on-boot post install hook. > > Hence we should keep a unversioned kernel image in kernel rpm > package. > And patch v2 did it.（ v1 and v2 are similar, but v2 improves print > messages.） This does bring us to a bit of an impasse as I don't really like the idea of duplicating the kernel binaries twice in the packages just to work around fat filesystem limitations. Today its this file, you could argue we have to replace a load more files with duplicate copies and postinstalls which would seem to be the wrong direction to go in. Which tools does the extraction of the files onto this fat system? Could we ignore the symlink errors there and rely on a postinstall to create if not already created? Cheers, Richard ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [OE-core][PATCH 1/1 v3] classes/kernel: Use a copy of image for kernel*.rpm if fs doesn't support symlinks 2020-07-02 7:46 ` Richard Purdie @ 2020-07-02 9:49 ` Xu, Yanfei 2020-07-02 10:23 ` Richard Purdie 2020-07-02 12:37 ` Bruce Ashfield 0 siblings, 2 replies; 18+ messages in thread From: Xu, Yanfei @ 2020-07-02 9:49 UTC (permalink / raw) To: Richard Purdie, Bruce Ashfield Cc: Patches and discussions about the oe-core layer On 7/2/20 3:46 PM, Richard Purdie wrote: > On Thu, 2020-07-02 at 10:43 +0800, Xu, Yanfei wrote: >> >> On 7/1/20 9:42 PM, Bruce Ashfield wrote: >>> On Wed, Jul 1, 2020 at 4:22 AM Xu, Yanfei <yanfei.xu@windriver.com> >>> wrote: >>>> >>>> >>>> On 6/28/20 8:21 PM, Xu, Yanfei wrote: >>>>> >>>>> On 6/25/20 12:18 AM, Richard Purdie wrote: >>>>>> On Wed, 2020-06-24 at 23:57 +0800, Xu, Yanfei wrote: >>>>>>> On 6/24/20 9:08 PM, Richard Purdie wrote: >>>>>>>> On Wed, 2020-06-24 at 09:47 +0800, Xu, Yanfei wrote: >>>>>>>>> On 6/24/20 5:51 AM, Richard Purdie wrote: >>>>>>>>>> On Tue, 2020-06-23 at 10:31 -0400, Bruce Ashfield >>>>>>>>>> wrote: >>>>>>>>>>> On Fri, Jun 19, 2020 at 7:47 AM < >>>>>>>>>>> yanfei.xu@windriver.com> >>>>>>>>>>> wrote: >>>>>>>>>>>> From: Yanfei Xu <yanfei.xu@windriver.com> >>>>>>>>>>>> >>>>>>>>>>>> Some filesystems don't support symlink, then you >>>>>>>>>>>> will get >>>>>>>>>>>> failure >>>>>>>>>>>> when >>>>>>>>>>>> you install or update the kernel rpm package. Now >>>>>>>>>>>> we use a >>>>>>>>>>>> copy >>>>>>>>>>>> of >>>>>>>>>>>> image for these filesystems instead of symlink. >>>>>>>>>>>> >>>>>>>>>>>> Suggested-by: Bruce Ashfield < >>>>>>>>>>>> bruce.ashfield@gmail.com> >>>>>>>>>>>> Suggested-by: Richard Purdie < >>>>>>>>>>>> richard.purdie@linuxfoundation.org> >>>>>>>>>>>> Signed-off-by: Yanfei Xu <yanfei.xu@windriver.com >>>>>>>>>>>>> >>>>>>>>>>>> --- >>>>>>>>>>>> meta/classes/kernel.bbclass | 19 >>>>>>>>>>>> ++++++++++++++++--- >>>>>>>>>>>> 1 file changed, 16 insertions(+), 3 >>>>>>>>>>>> deletions(-) >>>>>>>>>>>> >>>>>>>>>>>> diff --git a/meta/classes/kernel.bbclass >>>>>>>>>>>> b/meta/classes/kernel.bbclass >>>>>>>>>>>> index 20a0135fc9..1269b54343 100644 >>>>>>>>>>>> --- a/meta/classes/kernel.bbclass >>>>>>>>>>>> +++ b/meta/classes/kernel.bbclass >>>>>>>>>>>> @@ -94,6 +94,22 @@ python __anonymous () { >>>>>>>>>>>> d.appendVar('RDEPENDS_%s-image' % >>>>>>>>>>>> kname, ' %s- >>>>>>>>>>>> image- >>>>>>>>>>>> %s' % >>>>>>>>>>>> (kname, typelower)) >>>>>>>>>>>> d.setVar('PKG_%s-image-%s' % >>>>>>>>>>>> (kname,typelower), >>>>>>>>>>>> '%s- >>>>>>>>>>>> image- >>>>>>>>>>>> %s-${KERNEL_VERSION_PKG_NAME}' % (kname, >>>>>>>>>>>> typelower)) >>>>>>>>>>>> d.setVar('ALLOW_EMPTY_%s-image-%s' % >>>>>>>>>>>> (kname, >>>>>>>>>>>> typelower), >>>>>>>>>>>> '1') >>>>>>>>>>>> + d.setVar('pkg_postinst_ontarget_%s- >>>>>>>>>>>> image-%s' % >>>>>>>>>>>> (kname,typelower), """ >>>>>>>>>>> >>>>>>>>>>> You were previously concerned about boot issues if >>>>>>>>>>> the >>>>>>>>>>> unversioned >>>>>>>>>>> image link/copy was deferred until boot. I don't >>>>>>>>>>> see a >>>>>>>>>>> summary of >>>>>>>>>>> why >>>>>>>>>>> that's no longer a concern in the v3 of the patch. >>>>>>>>>>> Can you >>>>>>>>>>> confirm >>>>>>>>>>> that it isn't an issue ? Is it simply because the >>>>>>>>>>> booted >>>>>>>>>>> image >>>>>>>>>>> isn't >>>>>>>>>>> installed via this package, and hence we are fine ? >>>>>>>>>> >>>>>>>>>> I'm suspecting this patch is why we're seeing >>>>>>>>>> selftest >>>>>>>>>> failures: >>>>>>>>>> >>>>>>>>>> https://autobuilder.yoctoproject.org/typhoon/#/builders/86/builds/1055 >>>>>>>>>> >>>>>>>>>> >>>>>>>>> Do you mean this patch has been applied? and introduce >>>>>>>>> new >>>>>>>>> issues? >>>>>>>> >>>>>>>> Yes, I reverted it and retested and confirmed this patch >>>>>>>> causes the >>>>>>>> selftest failure in the link to the build above. >>>>>>>> >>>>>>> OK, I am trying to analyse the log. But I haven't figured >>>>>>> out what >>>>>>> cause >>>>>>> it fialed， and how to reproduce it on my mechine. I'd >>>>>>> apprecate any >>>>>>> information. >>>>>> >>>>>> The command to reproduce should be: >>>>>> >>>>>> oe-selftest -r efibootpartition.GenericEFITest.test_boot_efi >>>>>> >>>>> I've addressed this failure why due to boot partation in wic >>>>> doesn't >>>>> contain no-versioned image. This result is different from the >>>>> previous >>>>> I verified, because of the different configuraions in wks. >>>>> >>>>> "--source" field in wks decides where the files in boot >>>>> partation come >>>>> from. So no-versioned image may come from ${IMAGE_ROOTFS}/boot >>>>> which is >>>>> installed by rpm package. Blow is the wks used by 'oe-selftest >>>>> -r >>>>> efibootpartition.GenericEFITest.test_boot_efi' >>>>> >>>>> bootloader --ptable gpt >>>>> part /boot --source rootfs --rootfs-dir=${IMAGE_ROOTFS}/boot >>>>> --fstype=vfat --label boot --active --align 1024 --use-uuid >>>>> --overhead-factor 1.0 >>>>> part / --source rootfs --fstype=ext4 --label root --align 1024 >>>>> --exclude-path boot/ >>>>> >>>>> Hence we still should keep the no-versioned iamge in kernel- >>>>> image*.rpm >>>>> which is like the previous v2 patch. >>>>> >>>> Any opinions? It does cause the kernel rpm larger. However, the >>>> kernel >>>> image is not always large, only a few MB. And it will be changed >>>> to >>>> symlink when installed on targe. So this patch's only negative >>>> effect >>>> is the little increasement about update payloads. >>> >>> I'm trying to follow the description that you had about the >>> oe-selftest and I'm missing something. >>> >>> Can you describe it again ? In a way that someone not familiar with >>> that the selftest is seeing as a failure can grok ? >>> >>> i.e. in the selftest configuration are we not getting the >>> (un)versioned kernel image because the symlink (or copy fallback) >>> is >>> in an on-boot post install hook ? And the test is looking for the >>> versioned/unversioned kernel image at image construction time ? >>> >>> So that leaves us at either installing both the versioned and >>> unversioned, or some sort of package install time testing of the >>> target filesystem ? Does that partition exist at package install >>> time >>> ? Is that the approach we tried in v1 of the patch (I know v2 was >>> keeping both as copies in the package, and converting it to a >>> symlink >>> on boot). >> >> Sorry for the uncleared discription. >> >> For the os-selftest failure: The failure happened at qemu booting >> with >> its wic image. Qemu could not find the unversioned kernel image in >> wic >> image for booting itself ,then caused the test failed. >> >> Why the booted partition in wic image doesn't contain the unversioned >> kernel image? Cause the wks can decide where the unversioned kernel >> images in wic image comes from. For this test, it comes from >> ${IMAGE_ROOTFS}/boot which is installed by kernel rpm package. >> Actually >> it didn't get unversioned kernel image because the symlink（or copy >> fallback） is in an on-boot post install hook. >> >> Hence we should keep a unversioned kernel image in kernel rpm >> package. >> And patch v2 did it.（ v1 and v2 are similar, but v2 improves print >> messages.） > > This does bring us to a bit of an impasse as I don't really like the > idea of duplicating the kernel binaries twice in the packages just to > work around fat filesystem limitations. > > Today its this file, you could argue we have to replace a load more > files with duplicate copies and postinstalls which would seem to be the > wrong direction to go in. Yes, I agree that duplicate copies is not a good way to solve these symlink problems for normal rpm. Users should be awared the disadvantages of vfat filesystem. But kernel rpm maybe more important than others rpm? so we could make its compatibility more all-around? > > Which tools does the extraction of the files onto this fat system? > Could we ignore the symlink errors there and rely on a postinstall to > create if not already created? It may not. Cause if the extraction of the files runs failed, the postinstall of this rpm package won't excute. So... Cheers, Yanfei > > Cheers, > > Richard > > > > > > > ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [OE-core][PATCH 1/1 v3] classes/kernel: Use a copy of image for kernel*.rpm if fs doesn't support symlinks 2020-07-02 9:49 ` Xu, Yanfei @ 2020-07-02 10:23 ` Richard Purdie 2020-07-02 12:37 ` Bruce Ashfield 1 sibling, 0 replies; 18+ messages in thread From: Richard Purdie @ 2020-07-02 10:23 UTC (permalink / raw) To: Xu, Yanfei, Bruce Ashfield Cc: Patches and discussions about the oe-core layer On Thu, 2020-07-02 at 17:49 +0800, Xu, Yanfei wrote: > > On 7/2/20 3:46 PM, Richard Purdie wrote: > > On Thu, 2020-07-02 at 10:43 +0800, Xu, Yanfei wrote: > > > On 7/1/20 9:42 PM, Bruce Ashfield wrote: > > > > On Wed, Jul 1, 2020 at 4:22 AM Xu, Yanfei <yanfei.xu@windriver.com> > > > > wrote: > > > > > > > > > > On 6/28/20 8:21 PM, Xu, Yanfei wrote: > > > > > > On 6/25/20 12:18 AM, Richard Purdie wrote: > > > > > > > On Wed, 2020-06-24 at 23:57 +0800, Xu, Yanfei wrote: > > > > > > > > On 6/24/20 9:08 PM, Richard Purdie wrote: > > > > > > > > > On Wed, 2020-06-24 at 09:47 +0800, Xu, Yanfei wrote: > > > > > > > > > > On 6/24/20 5:51 AM, Richard Purdie wrote: > > > > > > > > > > > On Tue, 2020-06-23 at 10:31 -0400, Bruce Ashfield > > > > > > > > > > > wrote: > > > > > > > > > > > > On Fri, Jun 19, 2020 at 7:47 AM < > > > > > > > > > > > > yanfei.xu@windriver.com> > > > > > > > > > > > > wrote: > > > > > > > > > > > > > From: Yanfei Xu <yanfei.xu@windriver.com> > > > > > > > > > > > > > > > > > > > > > > > > > > Some filesystems don't support symlink, then you > > > > > > > > > > > > > will get > > > > > > > > > > > > > failure > > > > > > > > > > > > > when > > > > > > > > > > > > > you install or update the kernel rpm package. Now > > > > > > > > > > > > > we use a > > > > > > > > > > > > > copy > > > > > > > > > > > > > of > > > > > > > > > > > > > image for these filesystems instead of symlink. > > > > > > > > > > > > > > > > > > > > > > > > > > Suggested-by: Bruce Ashfield < > > > > > > > > > > > > > bruce.ashfield@gmail.com> > > > > > > > > > > > > > Suggested-by: Richard Purdie < > > > > > > > > > > > > > richard.purdie@linuxfoundation.org> > > > > > > > > > > > > > Signed-off-by: Yanfei Xu <yanfei.xu@windriver.com > > > > > > > > > > > > > --- > > > > > > > > > > > > > meta/classes/kernel.bbclass | 19 > > > > > > > > > > > > > ++++++++++++++++--- > > > > > > > > > > > > > 1 file changed, 16 insertions(+), 3 > > > > > > > > > > > > > deletions(-) > > > > > > > > > > > > > > > > > > > > > > > > > > diff --git a/meta/classes/kernel.bbclass > > > > > > > > > > > > > b/meta/classes/kernel.bbclass > > > > > > > > > > > > > index 20a0135fc9..1269b54343 100644 > > > > > > > > > > > > > --- a/meta/classes/kernel.bbclass > > > > > > > > > > > > > +++ b/meta/classes/kernel.bbclass > > > > > > > > > > > > > @@ -94,6 +94,22 @@ python __anonymous () { > > > > > > > > > > > > > d.appendVar('RDEPENDS_%s-image' % > > > > > > > > > > > > > kname, ' %s- > > > > > > > > > > > > > image- > > > > > > > > > > > > > %s' % > > > > > > > > > > > > > (kname, typelower)) > > > > > > > > > > > > > d.setVar('PKG_%s-image-%s' % > > > > > > > > > > > > > (kname,typelower), > > > > > > > > > > > > > '%s- > > > > > > > > > > > > > image- > > > > > > > > > > > > > %s-${KERNEL_VERSION_PKG_NAME}' % (kname, > > > > > > > > > > > > > typelower)) > > > > > > > > > > > > > d.setVar('ALLOW_EMPTY_%s-image-%s' % > > > > > > > > > > > > > (kname, > > > > > > > > > > > > > typelower), > > > > > > > > > > > > > '1') > > > > > > > > > > > > > + d.setVar('pkg_postinst_ontarget_%s- > > > > > > > > > > > > > image-%s' % > > > > > > > > > > > > > (kname,typelower), """ > > > > > > > > > > > > > > > > > > > > > > > > You were previously concerned about boot issues if > > > > > > > > > > > > the > > > > > > > > > > > > unversioned > > > > > > > > > > > > image link/copy was deferred until boot. I don't > > > > > > > > > > > > see a > > > > > > > > > > > > summary of > > > > > > > > > > > > why > > > > > > > > > > > > that's no longer a concern in the v3 of the patch. > > > > > > > > > > > > Can you > > > > > > > > > > > > confirm > > > > > > > > > > > > that it isn't an issue ? Is it simply because the > > > > > > > > > > > > booted > > > > > > > > > > > > image > > > > > > > > > > > > isn't > > > > > > > > > > > > installed via this package, and hence we are fine ? > > > > > > > > > > > > > > > > > > > > > > I'm suspecting this patch is why we're seeing > > > > > > > > > > > selftest > > > > > > > > > > > failures: > > > > > > > > > > > > > > > > > > > > > > https://autobuilder.yoctoproject.org/typhoon/#/builders/86/builds/1055 > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > > Do you mean this patch has been applied? and introduce > > > > > > > > > > new > > > > > > > > > > issues? > > > > > > > > > > > > > > > > > > Yes, I reverted it and retested and confirmed this patch > > > > > > > > > causes the > > > > > > > > > selftest failure in the link to the build above. > > > > > > > > > > > > > > > > > OK, I am trying to analyse the log. But I haven't figured > > > > > > > > out what > > > > > > > > cause > > > > > > > > it fialed， and how to reproduce it on my mechine. I'd > > > > > > > > apprecate any > > > > > > > > information. > > > > > > > > > > > > > > The command to reproduce should be: > > > > > > > > > > > > > > oe-selftest -r efibootpartition.GenericEFITest.test_boot_efi > > > > > > > > > > > > > I've addressed this failure why due to boot partation in wic > > > > > > doesn't > > > > > > contain no-versioned image. This result is different from the > > > > > > previous > > > > > > I verified, because of the different configuraions in wks. > > > > > > > > > > > > "--source" field in wks decides where the files in boot > > > > > > partation come > > > > > > from. So no-versioned image may come from ${IMAGE_ROOTFS}/boot > > > > > > which is > > > > > > installed by rpm package. Blow is the wks used by 'oe-selftest > > > > > > -r > > > > > > efibootpartition.GenericEFITest.test_boot_efi' > > > > > > > > > > > > bootloader --ptable gpt > > > > > > part /boot --source rootfs --rootfs-dir=${IMAGE_ROOTFS}/boot > > > > > > --fstype=vfat --label boot --active --align 1024 --use-uuid > > > > > > --overhead-factor 1.0 > > > > > > part / --source rootfs --fstype=ext4 --label root --align 1024 > > > > > > --exclude-path boot/ > > > > > > > > > > > > Hence we still should keep the no-versioned iamge in kernel- > > > > > > image*.rpm > > > > > > which is like the previous v2 patch. > > > > > > > > > > > Any opinions? It does cause the kernel rpm larger. However, the > > > > > kernel > > > > > image is not always large, only a few MB. And it will be changed > > > > > to > > > > > symlink when installed on targe. So this patch's only negative > > > > > effect > > > > > is the little increasement about update payloads. > > > > > > > > I'm trying to follow the description that you had about the > > > > oe-selftest and I'm missing something. > > > > > > > > Can you describe it again ? In a way that someone not familiar with > > > > that the selftest is seeing as a failure can grok ? > > > > > > > > i.e. in the selftest configuration are we not getting the > > > > (un)versioned kernel image because the symlink (or copy fallback) > > > > is > > > > in an on-boot post install hook ? And the test is looking for the > > > > versioned/unversioned kernel image at image construction time ? > > > > > > > > So that leaves us at either installing both the versioned and > > > > unversioned, or some sort of package install time testing of the > > > > target filesystem ? Does that partition exist at package install > > > > time > > > > ? Is that the approach we tried in v1 of the patch (I know v2 was > > > > keeping both as copies in the package, and converting it to a > > > > symlink > > > > on boot). > > > > > > Sorry for the uncleared discription. > > > > > > For the os-selftest failure: The failure happened at qemu booting > > > with > > > its wic image. Qemu could not find the unversioned kernel image in > > > wic > > > image for booting itself ,then caused the test failed. > > > > > > Why the booted partition in wic image doesn't contain the unversioned > > > kernel image? Cause the wks can decide where the unversioned kernel > > > images in wic image comes from. For this test, it comes from > > > ${IMAGE_ROOTFS}/boot which is installed by kernel rpm package. > > > Actually > > > it didn't get unversioned kernel image because the symlink（or copy > > > fallback） is in an on-boot post install hook. > > > > > > Hence we should keep a unversioned kernel image in kernel rpm > > > package. > > > And patch v2 did it.（ v1 and v2 are similar, but v2 improves print > > > messages.） > > > > This does bring us to a bit of an impasse as I don't really like the > > idea of duplicating the kernel binaries twice in the packages just to > > work around fat filesystem limitations. > > > > Today its this file, you could argue we have to replace a load more > > files with duplicate copies and postinstalls which would seem to be the > > wrong direction to go in. > > Yes, I agree that duplicate copies is not a good way to solve these > symlink problems for normal rpm. Users should be awared the > disadvantages of vfat filesystem. But kernel rpm maybe more important > than others rpm? so we could make its compatibility more all-around? > > > Which tools does the extraction of the files onto this fat system? > > Could we ignore the symlink errors there and rely on a postinstall to > > create if not already created? > > It may not. Cause if the extraction of the files runs failed, the > postinstall of this rpm package won't excute. So... I wonder if the preinst could check for vfat and do something like a temporary mount to work around the issue? Cheers, Richard ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [OE-core][PATCH 1/1 v3] classes/kernel: Use a copy of image for kernel*.rpm if fs doesn't support symlinks 2020-07-02 9:49 ` Xu, Yanfei 2020-07-02 10:23 ` Richard Purdie @ 2020-07-02 12:37 ` Bruce Ashfield 2020-07-03 2:29 ` Xu, Yanfei 1 sibling, 1 reply; 18+ messages in thread From: Bruce Ashfield @ 2020-07-02 12:37 UTC (permalink / raw) To: Xu, Yanfei Cc: Richard Purdie, Patches and discussions about the oe-core layer On Thu, Jul 2, 2020 at 5:49 AM Xu, Yanfei <yanfei.xu@windriver.com> wrote: > > > > On 7/2/20 3:46 PM, Richard Purdie wrote: > > On Thu, 2020-07-02 at 10:43 +0800, Xu, Yanfei wrote: > >> > >> On 7/1/20 9:42 PM, Bruce Ashfield wrote: > >>> On Wed, Jul 1, 2020 at 4:22 AM Xu, Yanfei <yanfei.xu@windriver.com> > >>> wrote: > >>>> > >>>> > >>>> On 6/28/20 8:21 PM, Xu, Yanfei wrote: > >>>>> > >>>>> On 6/25/20 12:18 AM, Richard Purdie wrote: > >>>>>> On Wed, 2020-06-24 at 23:57 +0800, Xu, Yanfei wrote: > >>>>>>> On 6/24/20 9:08 PM, Richard Purdie wrote: > >>>>>>>> On Wed, 2020-06-24 at 09:47 +0800, Xu, Yanfei wrote: > >>>>>>>>> On 6/24/20 5:51 AM, Richard Purdie wrote: > >>>>>>>>>> On Tue, 2020-06-23 at 10:31 -0400, Bruce Ashfield > >>>>>>>>>> wrote: > >>>>>>>>>>> On Fri, Jun 19, 2020 at 7:47 AM < > >>>>>>>>>>> yanfei.xu@windriver.com> > >>>>>>>>>>> wrote: > >>>>>>>>>>>> From: Yanfei Xu <yanfei.xu@windriver.com> > >>>>>>>>>>>> > >>>>>>>>>>>> Some filesystems don't support symlink, then you > >>>>>>>>>>>> will get > >>>>>>>>>>>> failure > >>>>>>>>>>>> when > >>>>>>>>>>>> you install or update the kernel rpm package. Now > >>>>>>>>>>>> we use a > >>>>>>>>>>>> copy > >>>>>>>>>>>> of > >>>>>>>>>>>> image for these filesystems instead of symlink. > >>>>>>>>>>>> > >>>>>>>>>>>> Suggested-by: Bruce Ashfield < > >>>>>>>>>>>> bruce.ashfield@gmail.com> > >>>>>>>>>>>> Suggested-by: Richard Purdie < > >>>>>>>>>>>> richard.purdie@linuxfoundation.org> > >>>>>>>>>>>> Signed-off-by: Yanfei Xu <yanfei.xu@windriver.com > >>>>>>>>>>>>> > >>>>>>>>>>>> --- > >>>>>>>>>>>> meta/classes/kernel.bbclass | 19 > >>>>>>>>>>>> ++++++++++++++++--- > >>>>>>>>>>>> 1 file changed, 16 insertions(+), 3 > >>>>>>>>>>>> deletions(-) > >>>>>>>>>>>> > >>>>>>>>>>>> diff --git a/meta/classes/kernel.bbclass > >>>>>>>>>>>> b/meta/classes/kernel.bbclass > >>>>>>>>>>>> index 20a0135fc9..1269b54343 100644 > >>>>>>>>>>>> --- a/meta/classes/kernel.bbclass > >>>>>>>>>>>> +++ b/meta/classes/kernel.bbclass > >>>>>>>>>>>> @@ -94,6 +94,22 @@ python __anonymous () { > >>>>>>>>>>>> d.appendVar('RDEPENDS_%s-image' % > >>>>>>>>>>>> kname, ' %s- > >>>>>>>>>>>> image- > >>>>>>>>>>>> %s' % > >>>>>>>>>>>> (kname, typelower)) > >>>>>>>>>>>> d.setVar('PKG_%s-image-%s' % > >>>>>>>>>>>> (kname,typelower), > >>>>>>>>>>>> '%s- > >>>>>>>>>>>> image- > >>>>>>>>>>>> %s-${KERNEL_VERSION_PKG_NAME}' % (kname, > >>>>>>>>>>>> typelower)) > >>>>>>>>>>>> d.setVar('ALLOW_EMPTY_%s-image-%s' % > >>>>>>>>>>>> (kname, > >>>>>>>>>>>> typelower), > >>>>>>>>>>>> '1') > >>>>>>>>>>>> + d.setVar('pkg_postinst_ontarget_%s- > >>>>>>>>>>>> image-%s' % > >>>>>>>>>>>> (kname,typelower), """ > >>>>>>>>>>> > >>>>>>>>>>> You were previously concerned about boot issues if > >>>>>>>>>>> the > >>>>>>>>>>> unversioned > >>>>>>>>>>> image link/copy was deferred until boot. I don't > >>>>>>>>>>> see a > >>>>>>>>>>> summary of > >>>>>>>>>>> why > >>>>>>>>>>> that's no longer a concern in the v3 of the patch. > >>>>>>>>>>> Can you > >>>>>>>>>>> confirm > >>>>>>>>>>> that it isn't an issue ? Is it simply because the > >>>>>>>>>>> booted > >>>>>>>>>>> image > >>>>>>>>>>> isn't > >>>>>>>>>>> installed via this package, and hence we are fine ? > >>>>>>>>>> > >>>>>>>>>> I'm suspecting this patch is why we're seeing > >>>>>>>>>> selftest > >>>>>>>>>> failures: > >>>>>>>>>> > >>>>>>>>>> https://autobuilder.yoctoproject.org/typhoon/#/builders/86/builds/1055 > >>>>>>>>>> > >>>>>>>>>> > >>>>>>>>> Do you mean this patch has been applied? and introduce > >>>>>>>>> new > >>>>>>>>> issues? > >>>>>>>> > >>>>>>>> Yes, I reverted it and retested and confirmed this patch > >>>>>>>> causes the > >>>>>>>> selftest failure in the link to the build above. > >>>>>>>> > >>>>>>> OK, I am trying to analyse the log. But I haven't figured > >>>>>>> out what > >>>>>>> cause > >>>>>>> it fialed， and how to reproduce it on my mechine. I'd > >>>>>>> apprecate any > >>>>>>> information. > >>>>>> > >>>>>> The command to reproduce should be: > >>>>>> > >>>>>> oe-selftest -r efibootpartition.GenericEFITest.test_boot_efi > >>>>>> > >>>>> I've addressed this failure why due to boot partation in wic > >>>>> doesn't > >>>>> contain no-versioned image. This result is different from the > >>>>> previous > >>>>> I verified, because of the different configuraions in wks. > >>>>> > >>>>> "--source" field in wks decides where the files in boot > >>>>> partation come > >>>>> from. So no-versioned image may come from ${IMAGE_ROOTFS}/boot > >>>>> which is > >>>>> installed by rpm package. Blow is the wks used by 'oe-selftest > >>>>> -r > >>>>> efibootpartition.GenericEFITest.test_boot_efi' > >>>>> > >>>>> bootloader --ptable gpt > >>>>> part /boot --source rootfs --rootfs-dir=${IMAGE_ROOTFS}/boot > >>>>> --fstype=vfat --label boot --active --align 1024 --use-uuid > >>>>> --overhead-factor 1.0 > >>>>> part / --source rootfs --fstype=ext4 --label root --align 1024 > >>>>> --exclude-path boot/ > >>>>> > >>>>> Hence we still should keep the no-versioned iamge in kernel- > >>>>> image*.rpm > >>>>> which is like the previous v2 patch. > >>>>> > >>>> Any opinions? It does cause the kernel rpm larger. However, the > >>>> kernel > >>>> image is not always large, only a few MB. And it will be changed > >>>> to > >>>> symlink when installed on targe. So this patch's only negative > >>>> effect > >>>> is the little increasement about update payloads. > >>> > >>> I'm trying to follow the description that you had about the > >>> oe-selftest and I'm missing something. > >>> > >>> Can you describe it again ? In a way that someone not familiar with > >>> that the selftest is seeing as a failure can grok ? > >>> > >>> i.e. in the selftest configuration are we not getting the > >>> (un)versioned kernel image because the symlink (or copy fallback) > >>> is > >>> in an on-boot post install hook ? And the test is looking for the > >>> versioned/unversioned kernel image at image construction time ? > >>> > >>> So that leaves us at either installing both the versioned and > >>> unversioned, or some sort of package install time testing of the > >>> target filesystem ? Does that partition exist at package install > >>> time > >>> ? Is that the approach we tried in v1 of the patch (I know v2 was > >>> keeping both as copies in the package, and converting it to a > >>> symlink > >>> on boot). > >> > >> Sorry for the uncleared discription. > >> > >> For the os-selftest failure: The failure happened at qemu booting > >> with > >> its wic image. Qemu could not find the unversioned kernel image in > >> wic > >> image for booting itself ,then caused the test failed. > >> > >> Why the booted partition in wic image doesn't contain the unversioned > >> kernel image? Cause the wks can decide where the unversioned kernel > >> images in wic image comes from. For this test, it comes from > >> ${IMAGE_ROOTFS}/boot which is installed by kernel rpm package. > >> Actually > >> it didn't get unversioned kernel image because the symlink（or copy > >> fallback） is in an on-boot post install hook. > >> > >> Hence we should keep a unversioned kernel image in kernel rpm > >> package. > >> And patch v2 did it.（ v1 and v2 are similar, but v2 improves print > >> messages.） > > > > This does bring us to a bit of an impasse as I don't really like the > > idea of duplicating the kernel binaries twice in the packages just to > > work around fat filesystem limitations. > > > > Today its this file, you could argue we have to replace a load more > > files with duplicate copies and postinstalls which would seem to be the > > wrong direction to go in. > > Yes, I agree that duplicate copies is not a good way to solve these > symlink problems for normal rpm. Users should be awared the > disadvantages of vfat filesystem. But kernel rpm maybe more important > than others rpm? so we could make its compatibility more all-around? > > > > > Which tools does the extraction of the files onto this fat system? > > Could we ignore the symlink errors there and rely on a postinstall to > > create if not already created? > > It may not. Cause if the extraction of the files runs failed, the > postinstall of this rpm package won't excute. So... Is that true even if it is a "normal" post install hook (not the on-target/boot one, just a standard package post install hook) ? We can programatically create a package post install the same way the ontarget one was being created (or at least it was when I last checked). Wouldn't that make the /boot partition and filesystem available and before wic runs ? So we could have the "try symlink, fail to a copy" before anything ever looks for it. It would also cover the on-target package upgrade path. My apologies if we've already discussed that, and discarded it due to technical issues. Bruce > > > Cheers, > > Yanfei > > > > Cheers, > > > > Richard > > > > > > > > > > > > > > -- - Thou shalt not follow the NULL pointer, for chaos and madness await thee at its end - "Use the force Harry" - Gandalf, Star Trek II ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [OE-core][PATCH 1/1 v3] classes/kernel: Use a copy of image for kernel*.rpm if fs doesn't support symlinks 2020-07-02 12:37 ` Bruce Ashfield @ 2020-07-03 2:29 ` Xu, Yanfei 0 siblings, 0 replies; 18+ messages in thread From: Xu, Yanfei @ 2020-07-03 2:29 UTC (permalink / raw) To: Bruce Ashfield Cc: Richard Purdie, Patches and discussions about the oe-core layer On 7/2/20 8:37 PM, Bruce Ashfield wrote: > On Thu, Jul 2, 2020 at 5:49 AM Xu, Yanfei <yanfei.xu@windriver.com> wrote: >> >> >> >> On 7/2/20 3:46 PM, Richard Purdie wrote: >>> On Thu, 2020-07-02 at 10:43 +0800, Xu, Yanfei wrote: >>>> >>>> On 7/1/20 9:42 PM, Bruce Ashfield wrote: >>>>> On Wed, Jul 1, 2020 at 4:22 AM Xu, Yanfei <yanfei.xu@windriver.com> >>>>> wrote: >>>>>> >>>>>> >>>>>> On 6/28/20 8:21 PM, Xu, Yanfei wrote: >>>>>>> >>>>>>> On 6/25/20 12:18 AM, Richard Purdie wrote: >>>>>>>> On Wed, 2020-06-24 at 23:57 +0800, Xu, Yanfei wrote: >>>>>>>>> On 6/24/20 9:08 PM, Richard Purdie wrote: >>>>>>>>>> On Wed, 2020-06-24 at 09:47 +0800, Xu, Yanfei wrote: >>>>>>>>>>> On 6/24/20 5:51 AM, Richard Purdie wrote: >>>>>>>>>>>> On Tue, 2020-06-23 at 10:31 -0400, Bruce Ashfield >>>>>>>>>>>> wrote: >>>>>>>>>>>>> On Fri, Jun 19, 2020 at 7:47 AM < >>>>>>>>>>>>> yanfei.xu@windriver.com> >>>>>>>>>>>>> wrote: >>>>>>>>>>>>>> From: Yanfei Xu <yanfei.xu@windriver.com> >>>>>>>>>>>>>> >>>>>>>>>>>>>> Some filesystems don't support symlink, then you >>>>>>>>>>>>>> will get >>>>>>>>>>>>>> failure >>>>>>>>>>>>>> when >>>>>>>>>>>>>> you install or update the kernel rpm package. Now >>>>>>>>>>>>>> we use a >>>>>>>>>>>>>> copy >>>>>>>>>>>>>> of >>>>>>>>>>>>>> image for these filesystems instead of symlink. >>>>>>>>>>>>>> >>>>>>>>>>>>>> Suggested-by: Bruce Ashfield < >>>>>>>>>>>>>> bruce.ashfield@gmail.com> >>>>>>>>>>>>>> Suggested-by: Richard Purdie < >>>>>>>>>>>>>> richard.purdie@linuxfoundation.org> >>>>>>>>>>>>>> Signed-off-by: Yanfei Xu <yanfei.xu@windriver.com >>>>>>>>>>>>>>> >>>>>>>>>>>>>> --- >>>>>>>>>>>>>> meta/classes/kernel.bbclass | 19 >>>>>>>>>>>>>> ++++++++++++++++--- >>>>>>>>>>>>>> 1 file changed, 16 insertions(+), 3 >>>>>>>>>>>>>> deletions(-) >>>>>>>>>>>>>> >>>>>>>>>>>>>> diff --git a/meta/classes/kernel.bbclass >>>>>>>>>>>>>> b/meta/classes/kernel.bbclass >>>>>>>>>>>>>> index 20a0135fc9..1269b54343 100644 >>>>>>>>>>>>>> --- a/meta/classes/kernel.bbclass >>>>>>>>>>>>>> +++ b/meta/classes/kernel.bbclass >>>>>>>>>>>>>> @@ -94,6 +94,22 @@ python __anonymous () { >>>>>>>>>>>>>> d.appendVar('RDEPENDS_%s-image' % >>>>>>>>>>>>>> kname, ' %s- >>>>>>>>>>>>>> image- >>>>>>>>>>>>>> %s' % >>>>>>>>>>>>>> (kname, typelower)) >>>>>>>>>>>>>> d.setVar('PKG_%s-image-%s' % >>>>>>>>>>>>>> (kname,typelower), >>>>>>>>>>>>>> '%s- >>>>>>>>>>>>>> image- >>>>>>>>>>>>>> %s-${KERNEL_VERSION_PKG_NAME}' % (kname, >>>>>>>>>>>>>> typelower)) >>>>>>>>>>>>>> d.setVar('ALLOW_EMPTY_%s-image-%s' % >>>>>>>>>>>>>> (kname, >>>>>>>>>>>>>> typelower), >>>>>>>>>>>>>> '1') >>>>>>>>>>>>>> + d.setVar('pkg_postinst_ontarget_%s- >>>>>>>>>>>>>> image-%s' % >>>>>>>>>>>>>> (kname,typelower), """ >>>>>>>>>>>>> >>>>>>>>>>>>> You were previously concerned about boot issues if >>>>>>>>>>>>> the >>>>>>>>>>>>> unversioned >>>>>>>>>>>>> image link/copy was deferred until boot. I don't >>>>>>>>>>>>> see a >>>>>>>>>>>>> summary of >>>>>>>>>>>>> why >>>>>>>>>>>>> that's no longer a concern in the v3 of the patch. >>>>>>>>>>>>> Can you >>>>>>>>>>>>> confirm >>>>>>>>>>>>> that it isn't an issue ? Is it simply because the >>>>>>>>>>>>> booted >>>>>>>>>>>>> image >>>>>>>>>>>>> isn't >>>>>>>>>>>>> installed via this package, and hence we are fine ? >>>>>>>>>>>> >>>>>>>>>>>> I'm suspecting this patch is why we're seeing >>>>>>>>>>>> selftest >>>>>>>>>>>> failures: >>>>>>>>>>>> >>>>>>>>>>>> https://autobuilder.yoctoproject.org/typhoon/#/builders/86/builds/1055 >>>>>>>>>>>> >>>>>>>>>>>> >>>>>>>>>>> Do you mean this patch has been applied? and introduce >>>>>>>>>>> new >>>>>>>>>>> issues? >>>>>>>>>> >>>>>>>>>> Yes, I reverted it and retested and confirmed this patch >>>>>>>>>> causes the >>>>>>>>>> selftest failure in the link to the build above. >>>>>>>>>> >>>>>>>>> OK, I am trying to analyse the log. But I haven't figured >>>>>>>>> out what >>>>>>>>> cause >>>>>>>>> it fialed， and how to reproduce it on my mechine. I'd >>>>>>>>> apprecate any >>>>>>>>> information. >>>>>>>> >>>>>>>> The command to reproduce should be: >>>>>>>> >>>>>>>> oe-selftest -r efibootpartition.GenericEFITest.test_boot_efi >>>>>>>> >>>>>>> I've addressed this failure why due to boot partation in wic >>>>>>> doesn't >>>>>>> contain no-versioned image. This result is different from the >>>>>>> previous >>>>>>> I verified, because of the different configuraions in wks. >>>>>>> >>>>>>> "--source" field in wks decides where the files in boot >>>>>>> partation come >>>>>>> from. So no-versioned image may come from ${IMAGE_ROOTFS}/boot >>>>>>> which is >>>>>>> installed by rpm package. Blow is the wks used by 'oe-selftest >>>>>>> -r >>>>>>> efibootpartition.GenericEFITest.test_boot_efi' >>>>>>> >>>>>>> bootloader --ptable gpt >>>>>>> part /boot --source rootfs --rootfs-dir=${IMAGE_ROOTFS}/boot >>>>>>> --fstype=vfat --label boot --active --align 1024 --use-uuid >>>>>>> --overhead-factor 1.0 >>>>>>> part / --source rootfs --fstype=ext4 --label root --align 1024 >>>>>>> --exclude-path boot/ >>>>>>> >>>>>>> Hence we still should keep the no-versioned iamge in kernel- >>>>>>> image*.rpm >>>>>>> which is like the previous v2 patch. >>>>>>> >>>>>> Any opinions? It does cause the kernel rpm larger. However, the >>>>>> kernel >>>>>> image is not always large, only a few MB. And it will be changed >>>>>> to >>>>>> symlink when installed on targe. So this patch's only negative >>>>>> effect >>>>>> is the little increasement about update payloads. >>>>> >>>>> I'm trying to follow the description that you had about the >>>>> oe-selftest and I'm missing something. >>>>> >>>>> Can you describe it again ? In a way that someone not familiar with >>>>> that the selftest is seeing as a failure can grok ? >>>>> >>>>> i.e. in the selftest configuration are we not getting the >>>>> (un)versioned kernel image because the symlink (or copy fallback) >>>>> is >>>>> in an on-boot post install hook ? And the test is looking for the >>>>> versioned/unversioned kernel image at image construction time ? >>>>> >>>>> So that leaves us at either installing both the versioned and >>>>> unversioned, or some sort of package install time testing of the >>>>> target filesystem ? Does that partition exist at package install >>>>> time >>>>> ? Is that the approach we tried in v1 of the patch (I know v2 was >>>>> keeping both as copies in the package, and converting it to a >>>>> symlink >>>>> on boot). >>>> >>>> Sorry for the uncleared discription. >>>> >>>> For the os-selftest failure: The failure happened at qemu booting >>>> with >>>> its wic image. Qemu could not find the unversioned kernel image in >>>> wic >>>> image for booting itself ,then caused the test failed. >>>> >>>> Why the booted partition in wic image doesn't contain the unversioned >>>> kernel image? Cause the wks can decide where the unversioned kernel >>>> images in wic image comes from. For this test, it comes from >>>> ${IMAGE_ROOTFS}/boot which is installed by kernel rpm package. >>>> Actually >>>> it didn't get unversioned kernel image because the symlink（or copy >>>> fallback） is in an on-boot post install hook. >>>> >>>> Hence we should keep a unversioned kernel image in kernel rpm >>>> package. >>>> And patch v2 did it.（ v1 and v2 are similar, but v2 improves print >>>> messages.） >>> >>> This does bring us to a bit of an impasse as I don't really like the >>> idea of duplicating the kernel binaries twice in the packages just to >>> work around fat filesystem limitations. >>> >>> Today its this file, you could argue we have to replace a load more >>> files with duplicate copies and postinstalls which would seem to be the >>> wrong direction to go in. >> >> Yes, I agree that duplicate copies is not a good way to solve these >> symlink problems for normal rpm. Users should be awared the >> disadvantages of vfat filesystem. But kernel rpm maybe more important >> than others rpm? so we could make its compatibility more all-around? >> >>> >>> Which tools does the extraction of the files onto this fat system? >>> Could we ignore the symlink errors there and rely on a postinstall to >>> create if not already created? >> >> It may not. Cause if the extraction of the files runs failed, the >> postinstall of this rpm package won't excute. So... > > Is that true even if it is a "normal" post install hook (not the > on-target/boot one, just a standard package post install hook) ? > > We can programatically create a package post install the same way the > ontarget one was being created (or at least it was when I last > checked). Wouldn't that make the /boot partition and filesystem > available and before wic runs ? So we could have the "try symlink, > fail to a copy" before anything ever looks for it. It would also cover > the on-target package upgrade path. My apologies if we've already > discussed that, and discarded it due to technical issues. Good idea. I'll try it. Yanfei > > Bruce > >> >> >> Cheers, >> >> Yanfei >>> >>> Cheers, >>> >>> Richard >>> >>> >>> >>> >>> >>> >>> > > > > > > ^ permalink raw reply [flat|nested] 18+ messages in thread
* Re: [OE-core][PATCH 1/1 v3] classes/kernel: Use a copy of image for kernel*.rpm if fs doesn't support symlinks 2020-06-23 14:31 ` Bruce Ashfield 2020-06-23 21:51 ` Richard Purdie @ 2020-06-24 1:44 ` Xu, Yanfei 1 sibling, 0 replies; 18+ messages in thread From: Xu, Yanfei @ 2020-06-24 1:44 UTC (permalink / raw) To: Bruce Ashfield Cc: Richard Purdie, Patches and discussions about the oe-core layer On 6/23/20 10:31 PM, Bruce Ashfield wrote: > On Fri, Jun 19, 2020 at 7:47 AM <yanfei.xu@windriver.com> wrote: >> >> From: Yanfei Xu <yanfei.xu@windriver.com> >> >> Some filesystems don't support symlink, then you will get failure when >> you install or update the kernel rpm package. Now we use a copy of >> image for these filesystems instead of symlink. >> >> Suggested-by: Bruce Ashfield <bruce.ashfield@gmail.com> >> Suggested-by: Richard Purdie <richard.purdie@linuxfoundation.org> >> Signed-off-by: Yanfei Xu <yanfei.xu@windriver.com> >> --- >> meta/classes/kernel.bbclass | 19 ++++++++++++++++--- >> 1 file changed, 16 insertions(+), 3 deletions(-) >> >> diff --git a/meta/classes/kernel.bbclass b/meta/classes/kernel.bbclass >> index 20a0135fc9..1269b54343 100644 >> --- a/meta/classes/kernel.bbclass >> +++ b/meta/classes/kernel.bbclass >> @@ -94,6 +94,22 @@ python __anonymous () { >> d.appendVar('RDEPENDS_%s-image' % kname, ' %s-image-%s' % (kname, typelower)) >> d.setVar('PKG_%s-image-%s' % (kname,typelower), '%s-image-%s-${KERNEL_VERSION_PKG_NAME}' % (kname, typelower)) >> d.setVar('ALLOW_EMPTY_%s-image-%s' % (kname, typelower), '1') >> + d.setVar('pkg_postinst_ontarget_%s-image-%s' % (kname,typelower), """ > > You were previously concerned about boot issues if the unversioned > image link/copy was deferred until boot. I don't see a summary of why > that's no longer a concern in the v3 of the patch. Can you confirm > that it isn't an issue ? Is it simply because the booted image isn't > installed via this package, and hence we are fine ? > Yes, it is. Previously I have a wrong thounght that the booted image in boot partation is installed via this package. Then I confirmed it isn't like that by compiling wic image with an empty kernel-image*.rpm（modify kernel.bbclass）, the no-versioned iamge still be contained boot partation. Hence we are fine. Yanfei >> +set +e >> +ln -sf %s-${KERNEL_VERSION} ${KERNEL_IMAGEDEST}/%s > /dev/null 2>&1 >> +if [ $? -ne 0 ]; then >> + echo "Filesystem on ${KERNEL_IMAGEDEST}/ doesn't support symlinks, falling back to copied image (%s)." >> + install -m 0644 ${KERNEL_IMAGEDEST}/%s-${KERNEL_VERSION} ${KERNEL_IMAGEDEST}/%s >> +fi >> +set -e >> +""" % (type, type, type, type, type)) >> + d.setVar('pkg_postrm_%s-image-%s' % (kname,typelower), """ >> +set +e >> +if [ -f "${KERNEL_IMAGEDEST}/%s" -o -L "${KERNEL_IMAGEDEST}/%s" ]; then >> + rm -f ${KERNEL_IMAGEDEST}/%s > /dev/null 2>&1 >> +fi >> +set -e >> +""" % (type, type, type)) >> >> image = d.getVar('INITRAMFS_IMAGE') >> # If the INTIRAMFS_IMAGE is set but the INITRAMFS_IMAGE_BUNDLE is set to 0, >> @@ -385,9 +401,6 @@ kernel_do_install() { >> install -d ${D}/boot >> for imageType in ${KERNEL_IMAGETYPES} ; do >> install -m 0644 ${KERNEL_OUTPUT_DIR}/${imageType} ${D}/${KERNEL_IMAGEDEST}/${imageType}-${KERNEL_VERSION} >> - if [ "${KERNEL_PACKAGE_NAME}" = "kernel" ]; then >> - ln -sf ${imageType}-${KERNEL_VERSION} ${D}/${KERNEL_IMAGEDEST}/${imageType} >> - fi > > For on-target installs, this is what I was doing in the past as well. > Make the symlink during package install, that way we are encapsulated > in that unit. > > That just leaves my boot question as the last remaining thing for the change. > > Bruce > >> done >> install -m 0644 System.map ${D}/boot/System.map-${KERNEL_VERSION} >> install -m 0644 .config ${D}/boot/config-${KERNEL_VERSION} >> -- >> 2.18.2 >> > > > > > ^ permalink raw reply [flat|nested] 18+ messages in thread
end of thread, other threads:[~2020-07-03 2:29 UTC | newest] Thread overview: 18+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-06-19 11:47 [OE-core][PATCH 0/1 v3] classes/kernel: Use a copy of image for kernel*.rpm if fs doesn't support symlinks Xu, Yanfei 2020-06-19 11:47 ` [OE-core][PATCH 1/1 " Xu, Yanfei 2020-06-23 14:31 ` Bruce Ashfield 2020-06-23 21:51 ` Richard Purdie 2020-06-24 1:47 ` Xu, Yanfei 2020-06-24 13:08 ` Richard Purdie 2020-06-24 15:57 ` Xu, Yanfei 2020-06-24 16:18 ` Richard Purdie 2020-06-28 12:21 ` Xu, Yanfei 2020-07-01 8:22 ` Xu, Yanfei 2020-07-01 13:42 ` Bruce Ashfield 2020-07-02 2:43 ` Xu, Yanfei 2020-07-02 7:46 ` Richard Purdie 2020-07-02 9:49 ` Xu, Yanfei 2020-07-02 10:23 ` Richard Purdie 2020-07-02 12:37 ` Bruce Ashfield 2020-07-03 2:29 ` Xu, Yanfei 2020-06-24 1:44 ` Xu, Yanfei
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.