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