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 <[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). > > 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
-=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#140216): https://lists.openembedded.org/g/openembedded-core/message/140216 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]] -=-=-=-=-=-=-=-=-=-=-=-
