From: Marcus Folkesson <marcus.folkesson@gmail.com>
To: "Martin Hundebøll" <martin@geanix.com>
Cc: Ross Burton <Ross.Burton@arm.com>,
openembedded-core <openembedded-core@lists.openembedded.org>
Subject: Re: [OE-core] [PATCH v4 0/2] image-bootfiles: new class
Date: Tue, 11 Jun 2024 17:04:08 +0200 [thread overview]
Message-ID: <ZmhnaAv3KziwhCKF@gmail.com> (raw)
In-Reply-To: <e21366a98f2769cb7460ad6ebfe86ad3a51c24cd.camel@geanix.com>
[-- Attachment #1: Type: text/plain, Size: 3570 bytes --]
Hello Martin,
On Tue, Jun 11, 2024 at 04:44:04PM +0200, Martin Hundebøll wrote:
> On Tue, 2024-06-11 at 15:22 +0200, Marcus Folkesson wrote:
> > Hi Ross,
> >
> > On Tue, Jun 11, 2024 at 10:37:06AM +0000, Ross Burton wrote:
> > > On 30 May 2024, at 10:53, Marcus Folkesson via
> > > lists.openembedded.org
> > > <marcus.folkesson=gmail.com@lists.openembedded.org> wrote:
> > > > The image-bootfiles class is used to put all files listed in
> > > > IMAGE_BOOT_FILES into the root filesystem.
> > > >
> > > > IMAGE_BOOT_FILES is used by the bootimg-partition wic plugin to
> > > > put the
> > > > files into a boot partition.
> > > > Be able to list files as "boot files" in e.g. your .conf or image
> > > > files
> > > > instead of install those in every recipe is a good thing.
> > > >
> > > > It is not always desired to have a separate boot partition for
> > > > boot
> > > > files. Sometimes it could be good to have them as a part of the
> > > > root
> > > > filesystem.
> > > >
> > > > For example, if a double copy strategy is used for update the
> > > > system,
> > > > then you probably want to update both the boot files and root
> > > > filesystem
> > > > at the same time as there may be dependencies.
> > >
> > > In my mind, IMAGE_BOOT_FILES is a workaround for the fact that some
> > > /boot partitions (such as ones generated by wic) are not managed by
> > > bitbake directly. If you have a setup where you just have a / that
> > > contains /boot isn’t adding eg grub to IMAGE_INSTALL sufficient to
> > > get it in the right place in the rootfs?
> >
> > I don't know about the workaround, but it would'nt surprise me as it
> > is
> > not handled by bitbake as it is now.
> >
> > For some packages yes, but not for all. If you, for instance, have an
> > embedded
> > system where you depend on other files that are critical for the boot
> > process, there is no uniform way to specify that for those files.
> >
> > IMAGE_BOOT_FILES is good as it let you include e.g. ramdisks and such
> > that does not have installation scripts to the boot partition.
> >
> > The use case that I had was that I was first using a separate boot
> > partition using the bootimg-partition wic plugin. Everything was
> > good.
> > Then I wanted to include those files into the root filesystem instead
> > to
> > be able to do an atomic update on everything, but there is no good
> > way
> > to achive that.
>
> I'd suggest updating the recipe providing those boot files, so it
> installs them into /boot (maybe in addition to deploying them to
> $DEPLOYDIR).
Yes, that is the option.
>
> > This image-class make the swap from bootimg-partition to rootfs
> > seamless as it uses the same mechanics for both implementations.
>
> I have always disliked the concept of recipes pulling files from
> ${DEPLOY_DIR_IMAGE}. That folder is an output folder, and should not be
> used as input for other packages.
>
> Instead, a proper do_populate_deploy task similar to
> do_populate_sysroot would make it possible to DEPEND += on deployed
> files from other recipes.
I would probably have implemented it differently if we did not already
had the bootimg-partition plugin that works this way.
I think there is a point in having them work in a similar a way.
>
> But this is probably a discussion for another mail thread. Sorry for
> raising my opinion so late in the process.
No problem, all feedback is good. Thank you
>
> // Martin
Best regards,
Marcus Folkesson
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]
next prev parent reply other threads:[~2024-06-11 14:57 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-05-30 9:53 [PATCH v4 0/2] image-bootfiles: new class Marcus Folkesson
2024-05-30 9:53 ` [PATCH v4 1/2] bootimg-partition: break out code to a common library Marcus Folkesson
2024-05-30 9:53 ` [PATCH v4 2/2] image-bootfiles.bbclass: new class, copy boot files to root filesystem Marcus Folkesson
2024-05-31 12:09 ` Quentin Schulz
2024-06-16 4:26 ` Konrad Weihmann
2024-06-17 6:23 ` [OE-core] " Marcus Folkesson
2024-06-11 10:37 ` [OE-core] [PATCH v4 0/2] image-bootfiles: new class Ross Burton
2024-06-11 13:22 ` Marcus Folkesson
2024-06-11 14:44 ` Martin Hundebøll
2024-06-11 15:04 ` Marcus Folkesson [this message]
2024-07-16 11:28 ` Ross Burton
2024-07-22 7:36 ` Marcus Folkesson
2024-06-14 20:25 ` Marcus Folkesson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=ZmhnaAv3KziwhCKF@gmail.com \
--to=marcus.folkesson@gmail.com \
--cc=Ross.Burton@arm.com \
--cc=martin@geanix.com \
--cc=openembedded-core@lists.openembedded.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.