[systemd-devel] repart: How to use CopyBocks= with usr-verity?

[Nils Kattenbeck]

Hi Daan,

accepting more verity arguments might help but I am not even sure what
one would specify there. The recreation of the verity partition was
also only something I tried as a workaround which would not be
necessary if CopyBlocks= could correctly pick up the existing verity
partition.

I have now created an issue for this and linked reproducer:
https://github.com/systemd/systemd/issues/32029

Best regards, Nils

On Sun, Mar 31, 2024 at 12:30 PM Daan De Meyer <daan.j.demeyer at gmail.com> wrote:
>
> Hi Nils,
>
> Pretty sure nobody ever tried this. The root hash might be changing
> because we format the verity hash partition with different parameters
> than it was originally formatted with in your case. I assume the
> roothash will only stay the same if the verity format arguments are
> exactly the same. We'd probably accept PRs to allow configuring more
> verity arguments to support this use case.
>
> Cheers,
>
> Daan
>
> On Fri, 29 Mar 2024 at 19:55, Nils Kattenbeck <nilskemail at gmail.com> wrote:
> >
> > Hello everyone,
> >
> > I am having trouble with getting CopyBlocks= to work with a verify enabled usr partition. The documentations says that it should automatically work automatically but it does not describe which properties have to be set for which partition, i.e. repart.d file.
> > So far I have tried several variations of Verity=/VerityMatchKey=, settings it only on one partition, both etc., setting CopyBlocks= on only usr or usr and usr-verity. Setting CopyBlocks= on both does not work and systemd-repart fails with the message that it was unable to find the correct partition for usr-verity. The other approach was setting CopyBlocks= only on the usr partition but regardless of what I try with Verity= the root hash changes (and thus also the partition UUIDs). Or more specifically the usr partition retains the correct/original PARTUUID whereas the PARTUUID of the usr-verity partition changes.
> >
> > Maybe someone has an idea what might cause this or better yet already has a similar working solution which they could share.
> >
> > Kind regards,
> > Nils
> >