Am Montag, den 19.10.2020, 18:23 +0200 schrieb Stefano Babic:
On 19.10.20 17:43, Enrico J?rns wrote:
Hi,I had the same use case as you, and I could use something like
as I did not have much success with my question in the OR irc, let's
try it here in a more verbose way. ;)
Imagine I have an A+B redundant boot system, with additional bootloader
and separate home or application file system. Thus my layout would be
p2: rootfs A
p3: rootfs B
p4: appfs A
p5: appfs B
where rootfs A + appfs A form a logical unit with respect to the image-
based update handling.
No my question is: How do I generate the images required for the
bootloader partition and/or the appfs partition with the OE standard
image generation mechanisms?
We have a working solution with the 'genimage' tool for quite some
time, but I wonder if that could be done with the more tightly
integrated wic, too.
To my understanding, the way of creating something like a bootloader
image or an application file system is by using wic's image split
capabilities and doing (non-redundant example):
part /boot --source rootfs (or some plugin)
part / ... --source rootfs
part /app --source rootfs
part /app --source rawcopy --sourceparams="file=..."
and the file points to the image I want to put on the partition.
my intention was a bit different I think. I actually wanted to generate
the /app out of the rootfs image. But then re-use the resulting image.
To be honest I am less interested in the resulting disk image but in
the intermediate artifacts.
I've heard some older discussions on how to generate a separate /home
partition and a separate /data partition and it always turned out that
generating the single monolithic rootfs first and splitting it on a
per-folder base later is a straight-forward approach for most
Trying to get yocto to build images that do not contain things like
base-files, etc. was always painful and never meant to be supported
This will create multiple file system images out of the prior monoliticI have not a straightforward solution. I inherited just "image" and I
rootfs one. It also does all necessary changes for mounting, like
modifying the rootfs /etc/fstab etc.
Thus, using these generated images in my update scenario would be the
way to go for me.
BUT, currently I do not see any straight-forward way of how to use
them. One could add them to what the image_wic* image fstypes generate,
but this will violate the default rule that each image fstype generates
exactly one image.
And the generated images are a little hard to reference as one cannot
give them names (which is probably a negligable issue) and they do not
have a fstype extension.
The more sever issue is that I would also like to have archives (like
tar.bz2) of the content of /app or /boot as I can use them quite good
for installing to partitions whose size and other parameters I do not
know very beforehand (also applicable to UBI volumes).
But, at the moment there does not seem to be a designated way of doing
something like I intended. I wonder how others solve the generation of
non-rootfs images with YP/OE?
Or did I miss something that already exists for this?
cleaned up at the end with a ROOTFS_POSTPROCESS_COMMAND what was
superfluous. Maybe forcing packagegroup-core-boot can be an option.
Yes, this would be the 'hacky' solution to the problem. Actually, I
would prefer finding a solution that is supported out-of-the-box and
compatible with how OE sees the generation of images.
Thus re-using the wic fs artifacts appears to be one possible straight-
forward solution to me. The only thing is that I actually would not
even need the disk image itself probably.
A syntax could look like
part / --source rootfs output=my-rootfs-without-appfs.ext4 --fstype=ext4
part /app --source rootfs output=my-appfs.tar.bz --fstype=tar.bz2
part /home --source rootfs output=my-homefs.ext4 --fstype=ext4
Another option could be to introduce some kind of syntax in the file
system generation classes. But I have neither a clue on how to do that
without violating the current behavior of creating only one image per
image type nor a good idea yet on how to name the artifacts.
Thanks Stefano and best regards
Pengutronix e.K. | Enrico Jörns |
Embedded Linux Consulting & Support | https://www.pengutronix.de/
Steuerwalder Str. 21 | Phone: +49-5121-206917-180 |
31137 Hildesheim, Germany | Fax: +49-5121-206917-9 |