I’m currently updating our software from BSP 2.5 to 2.6.1.
In 2.6.1 the kernel (and device tree blob) is moved from the rootfs to an extra ubi volume, but the generated kernel archive kernel-image-4.4.21-v2.6.1b1+g7ecc29c_4.4-r0_colibri_vf.ipk has no install routine for the new layout. It still installs to /boot/ and calls update-alternatives in the postinst script.
Are there plans to fix this? For me it’s really important to be able to install updates from the running system without access to the u-boot command line.
Using the package manager to update the kernel might have worked so far, but it is not an update mode we explicitly test and maintain… Our default, tested update mode is through the update scripts in U-Boot.
The reason we switched to the new boot mode with independent UBI volumes is to lower the risk that the boot loader corrupts the root file system. It was also an advice of UBI co-author Richard Weinberger. It also works well for boot scenarios with initramfs.
However, even though the separate UBI volumes are not directly accessible, there is ubiupdatevol which allows to write UBI volumes from Linux. A postinst script for the kernel package could call those scripts and hence update the kernel/device tree on the volumes.
The problem remaining however is that switching to that new format requires to create new UBI volumes… In V2.5 all space has been consumed by the rootfs, hence it also requires a resizing of the root file system. I don’t think there is a way to shrink a UBIFS or a UBI volume, hence the only way doing this is using U-Boot and deleting the volume entirely… (which is what our update scripts do, see prepare_ubi in flash_blk.scr, introduced with this change).
thank you for your reply.
I did not expect to be able to change the flash layout in a running system, I just want to update a kernel as it was possible before.
OK, I created something to update my kernel and devicetree.
I decided to do everything from within the linux system (there is also a way to tell U-Boot to update the kernel at the next boot without accessing the rootfs on every startup)
I created an include file for OpenEmbedded (Download here) which contains the update function:
What it does:
check if the image file (first parameter) exists
seach for a UBI volume with the given name (second parameter of the function)
checkif the image file fits into the volume
write image into the UBI volume.
The “Search for volume” is added because my layout looks different from the original Toradex layout and I want to have a generic way to write into volumes.
The script is in an extra file because it could be interesting for other stuff, too.
It should be possible to use it for a U-Boot update.
The postrm stuff (it calls update-alternatives) should also be removed if you remove the kernel / devicetree image after writing it to the UBI volume.
To use it, I added the following to my linux-toradex_4.4.bbappend file:
require update-ubi-vol.inc
pkg_postinst_kernel-image_prepend = "${flash_ubi_script}"
pkg_postinst_kernel-image() {
if [ -z $D ]; then
flashUbi /${KERNEL_IMAGEDEST}/${KERNEL_IMAGETYPE}-${KERNEL_VERSION} kernel && rm /${KERNEL_IMAGEDEST}/${KERNEL_IMAGETYPE}-${KERNEL_VERSION}
fi
}
The pkg_postinst_kernel-image() overrides the original postinst content (calling update-alternatives).
If you don’t want this, rename it to pkg_postinst_kernel-image_append().
It should also work with the device tree (not tested):
pkg_postinst_kernel-devicetree_prepend = "${flash_ubi_script}"
pkg_postinst_kernel-devicetree() {
if [ -z $D ]; then
flashUbi /${KERNEL_IMAGEDEST}/devicetree-${KERNEL_VERSION} dtb && rm /${KERNEL_IMAGEDEST}/devicetree-${KERNEL_VERSION}
fi
}
I guess for the device tree you would have to have a mechanism to choose the right device tree ( vf500-colibri-eval-v3.dtb, vf610-colibri-eval-v3.dtb, or vfxx0-colibri-<yourboard>.dtb)
