On Wed, Jul 1, 2020 at 4:22 AM Xu, Yanfei <[email protected]> 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 <[email protected]> > >>>>>>> wrote: > >>>>>>>> From: Yanfei Xu <[email protected]> > >>>>>>>> > >>>>>>>> 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 <[email protected]> > >>>>>>>> Suggested-by: Richard Purdie < > >>>>>>>> [email protected]> > >>>>>>>> Signed-off-by: Yanfei Xu <[email protected]> > >>>>>>>> --- > >>>>>>>> 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
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#140180): https://lists.openembedded.org/g/openembedded-core/message/140180 Mute This Topic: https://lists.openembedded.org/mt/74977721/21656 Group Owner: [email protected] Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [[email protected]] -=-=-=-=-=-=-=-=-=-=-=-
