From: Fiona Klute via buildroot <buildroot@buildroot.org>
To: Peter Korsgaard <peter@korsgaard.com>
Cc: Fiona Klute via buildroot <buildroot@buildroot.org>
Subject: Re: [Buildroot] [PATCH next 1/3] fs/common.mk: add optional hook to build a verity hash tree
Date: Tue, 1 Sep 2026 14:53:25 +0200 [thread overview]
Message-ID: <3fbbaf51-47dc-4b3a-8a28-7768ae5d42a1@gmx.de> (raw)
In-Reply-To: <875x0p8als.fsf@dell.be.48ers.dk>
Am 01.09.26 um 13:38 schrieb Peter Korsgaard:
>>>>>> "Fiona" == Fiona Klute <fiona.klute@gmx.de> writes:
>
> Hi,
>
> >> Possibly, but should that then be per-fs or global? I wonder if it
> >> is
> >> worth the complexity to add this logic versus how fairly simple it is to
> >> just do it with whatever options you want in a post-image script.
>
> > I'd say per-fs. The logic could be shared like the general veritysetup
> > call, just the option would need to be added for each fs (in
> > Config.in). I don't think Kconfig has a kind of templating for that?
>
> > I agree running veritysetup in a post-image script isn't very
> > complicated. Where I'm actually trying to do is to have the roothash
> > of my rootfs before building an initramfs (using
> > BR2_TARGET_ROOTFS_CPIO_DRACUT), so it can be included (and signed
> > along with the initramfs, in my case in a FIT image). Of course these
> > patches don't achieve that, they'd just provide the roothash as a
> > start.
>
> > If you have a better idea how to do that I'm all ears.
>
> The way I have solved it in the past is to use "late" binding between
> the kernel and rootfs, E.G. only when I build the FIT image by sticking
> the root hash into a u-boot boot script that I generate in my post-image
> script and embed in the FIT.
That's exactly what I'm doing for now, with a config for the script in
the FIT image running "source $loadaddr#set-roothash" works, but it
seems kind of convoluted. Especially given Dracut explicitly provides
the option to embed command line options in the initramfs. :D
> > script can't do it (rootfs image isn't ready), post-image doesn't have
> > the fakeroot environment for running Dracut (and other setup [1]).
> > Maybe we should move building initramfs to a separate stage, after
> > rootfs (I'd definitely need to order cpio after other fs types), and
> > add a pre-initramfs script? Is there another non-messy way to use the
> > fakeroot environment and variables from Buildroot config that I've
> > missed so far (other than rules in external.mk)?
>
> Initramfs is indeed annoying because of the circular dependencies. It
> has been quite a while since I last used one. Out of interest, what do
> you need the initramfs for?
Right now for setting up that dm-verity device, in the future probably
dm-crypt, too. If it was *only* dm-verity I could use dm-mod.create
(assemble parameters like in the test in post-image) and let the kernel
handle the rest. Systemd has a bunch of automation for it, which is why
I've been working on fixing Dracut. ;-)
We don't really need the circular dependency, we just have to order the
initramfs after the rootfs. Kinda crude, but works (in external.mk):
$(BINARIES_DIR)/rootfs.cpio: $(BINARIES_DIR)/rootfs.squashfs
My general idea so far is to add something similar (but generic)
conditional on BR2_TARGET_ROOTFS_CPIO_DRACUT=y. We might still need a
script hook, but maybe a custom Dracut module would be enough (e.g.
build a veritytab/crypttab and install it in the initramfs). I'm still
working this out. :-)
_______________________________________________
buildroot mailing list
buildroot@buildroot.org
https://lists.buildroot.org/mailman/listinfo/buildroot
prev parent reply other threads:[~2026-09-01 12:53 UTC|newest]
Thread overview: 9+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-31 12:51 [Buildroot] [PATCH next 1/3] fs/common.mk: add optional hook to build a verity hash tree Fiona Klute via buildroot
2026-08-31 12:51 ` [Buildroot] [PATCH next 2/3] fs/squashfs: add option to build verity tree Fiona Klute via buildroot
2026-08-31 12:51 ` [Buildroot] [PATCH next 3/3] support/testing/tests/fs/test_squashfs.py: add test with dm-verity Fiona Klute via buildroot
2026-08-31 19:16 ` [Buildroot] [PATCH next 1/3] fs/common.mk: add optional hook to build a verity hash tree Peter Korsgaard
2026-08-31 21:10 ` Fiona Klute via buildroot
2026-09-01 6:41 ` Peter Korsgaard
2026-09-01 10:26 ` Fiona Klute via buildroot
2026-09-01 11:38 ` Peter Korsgaard
2026-09-01 12:53 ` Fiona Klute via buildroot [this message]
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=3fbbaf51-47dc-4b3a-8a28-7768ae5d42a1@gmx.de \
--to=buildroot@buildroot.org \
--cc=fiona.klute@gmx.de \
--cc=peter@korsgaard.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox