Create a wks.in that allows an out-of-the-box build of a bootable
USB image using systemd and the hash data as a separate device or
partition.
A focus here was to ensure we used proper GPT names and GPT types,
and the GPT UUIDs that are based on splitting the root hash.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
We have systemd-bootdisk-dmverity.wks.in as an example template but
no mention of it in docs or config files. Similar to the beaglebone
black insructions added earlier, we do the same for (qemu)x86-64.
This hopefully walks through getting things configured for building
a systemd based dm-verity image and booting it on qemux86-64 --filling
in a lot of blanks and assumptions so that someone relatively new to
the feature can get off the ground more quickly by using qemu as a
stepping stone towards their final physical implementation.
Finally, the full image is deployed and booted on real hardware.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Adding to your local.conf right out of the gate:
EXTRA_IMAGE_FEATURES = "read-only-rootfs"
while you are trying to sort out other things can be just another
complication to an already steep learning curve.
For example, I found simply enabling this with systemd caused:
systemd[1]: Failed to fork off sandboxing environment for executing generators: Protocol error
[!!!!!!] Failed to start up manager.
systemd[1]: Freezing execution.
While I'd like to get to the root cause of that, it doesn't change that
things boot fine w/o adding to EXTRA_IMAGE_FEATURES, even though the
rootfs is still read-only courtesy of dm-verity.
Reword things so as to make it clear it isn't strictly a hard requirement
and hence can be delayed as people work through their implementation.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
Some platform creators tend to list a whole bunch of layers by
default in conf/bblayers.conf. Without getting into the debate of
whether that is a good idea, it can tend to have the effect of
people seeing the meta-security DISTRO_FEATURES warning time and
time again and becoming essentially numb to it.
After having fallen into this trap myself, I figured it was worth
the extra mention in the dm-verity doc so there is a better chance
of users realizing "hey - this applies to me!".
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
This is meant to augment the generic dm-verity instructions with
the board specifics for this platform.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
As things stand currently, the only way to learn about the Yocto
specific settings for implementing dm-verity is by reading the source.
Here we try and capture some of the basic information that exists
out there in mailing list posts and get that in-tree.
Board specific settings/tips will be stored in board specific files.
Signed-off-by: Paul Gortmaker <paul.gortmaker@windriver.com>
Signed-off-by: Armin Kuster <akuster808@gmail.com>
