On 6/12/20 9:27 PM, Bruce Ashfield wrote:
On Fri, Jun 12, 2020 at 3:47 AM Xu, Yanfei <[email protected]> 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)
This is a piece of very useful code!
Thanks for your detailed suggestions, and I have implemented it basicly. ：)
Cheers,
Yanfei
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
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#139495):
https://lists.openembedded.org/g/openembedded-core/message/139495
Mute This Topic: https://lists.openembedded.org/mt/74771247/21656
Group Owner: [email protected]
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[[email protected]]
-=-=-=-=-=-=-=-=-=-=-=-
