On Fri, Jun 12, 2020 at 3:47 AM Xu, Yanfei <yanfei...@windriver.com> wrote:
>
> Ping Bruce.
Hmm, yes. I did miss the original message.
gmail isn't as effective at highlighting messages that are to me (and
also to the list) as I would like.
>
> On 6/9/20 6:32 PM, Xu, Yanfei wrote:
> > Hi Bruce,
> >
> > I encountered an issue that updating kernel rpm package will fail when
> > the /boot dir was mount with vfat filesystem. The root cause is vfat
> > don't support symlink.
> > --------cut here----------
> > error: unpacking of archive failed on file /boot/Image;5eda8385: cpio:
> > symlink failed - Resource temporarily unavailable
> > error:
> > kernel-image-image-5.4.43-yocto-standard-5.4.x+git0+f8c88c4331_9961cc8b79-r0.bcm_2xxx_rpi4:
> > install failed
> > root@bcm-2xxx-rpi4:/boot#
> >
> > Currently I have two ideas to fix it:
> > 1. we use 'install' cmd instead of 'ln -sf' in kernel_do_install to
> > avoid generating symlink in kernel-image-image*.rpm. And then add an
> > postinstall to this rpm. It will check if the /boot dir is vfat, if not,
> > we remove the copy image* and make a softlink for the image.
Note that for this option, you have to make sure that it really is
done in a post install or you end up with overlapping file errors in
scenarios where multiple kernel packages are installed (i.e. an
upgrade).
> > 2. we specially add an package type which doesn't contain symlink for
> > the vfat filesystem.
> >
> > For the first idea, I met an problem when I try to add
> > pkg_postinst_packagename function in kernel.bbclass file. Due to there
> > are not package name variables defined for the kernel-image-image.gz
> > kernel-image-image or other type kernel images. So I can not add
> > postinst functions statically why that how many packages and packages'
> > name are not certainly.
You can still generate the package names in python, i.e.:
d.setVar('pkg_postinst_ontarget_%s-image-%s' % (kname,
typelower), 'ln -sf ' + type + '-${KERNEL_VERSION}
/${KERNEL_IMAGEDEST}/' + type)
that's from a patch that I've had locally for a while, that deals with
kernel upgrade issues.
Any logic that deals with this really does have to be on target,
otherwise, information about the image (and partitions) is leaking
into the packages, and you'd need to carry specific image package
lists for the filesystem layout.
My suggestion for the post install is that it simply try and create
the symlink, and if that fails, then do a copy. That way there's no
need to detect filesystem types, etc.
You also need to ensure that you test the kernel upgrade path, since
with copies, you may end up with more kernel images around boot and
not get some of the implicit cleanup that you get by simply
redirecting a symlink (but if you are always copying the active kernel
to "image", then simply overwriting the target will get you that same
cleanup).
Cheers,
Bruce
> >
> > Do you have any opinions about these?
> >
> >
> > Regards,
> > Yanfei
> >
> >
> >
--
- 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 (#139440):
https://lists.openembedded.org/g/openembedded-core/message/139440
Mute This Topic: https://lists.openembedded.org/mt/74771247/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
