I'm already using systemd from the main branch.
When both the USB stick is plugged in, the partitions are installed on the NVMe drive (so identical PARTUUIDs exist on USB and main drive),
and the USB stick is selected for boot, the NVMe drive's root partition seems to be preferably mounted.
In any case, all other partitions are mounted from the same drive the root partition was mounted from, so that works perfectly fine.
Marius
Just for more clarity, this is what blkid looks like after installation:
/dev/nvme0n1p1: LABEL_FATBOOT="ESP" LABEL="ESP" UUID="7C1F-9627" TYPE="vfat" PARTLABEL="esp" PARTUUID="f9eff1ff-965e-4d8c-a61a-39ef56bc1dd1"
/dev/nvme0n1p2: LABEL="root-x86-64" UUID="24520d0f-3e13-43b5-b0c9-b418cf50164c" TYPE="ext4" PARTLABEL="root_1" PARTUUID="7e235d5c-cc7a-6776-fccf-120b2b86cb2f"
/dev/nvme0n1p4: UUID="50b51166-347f-4478-8892-10b6e438c563" TYPE="DM_verity_hash" PARTLABEL="root-verity_1" PARTUUID="e37e4064-8988-10db-f418-286f9ae94076"
/dev/nvme0n1p6: LABEL="srv" UUID="41106901-caf0-4fff-af75-f3d576db144d" TYPE="ext4" PARTLABEL="srv" PARTUUID="68741eb6-97cb-4b66-ae84-8b7c612e0020"
/dev/mapper/root: LABEL="root-x86-64" UUID="24520d0f-3e13-43b5-b0c9-b418cf50164c" TYPE="ext4"
/dev/nvme0n1p3: PARTLABEL="_empty" PARTUUID="c24bbf42-a3cc-4725-af16-df486984187d"
/dev/nvme0n1p5: PARTLABEL="_empty" PARTUUID="6c90b41a-5c7d-4f8f-ba74-d16566db5c3e"
/dev/sda1: LABEL_FATBOOT="ESP" LABEL="ESP" UUID="A25B-8FBD" TYPE="vfat" PARTLABEL="esp" PARTUUID="ac2e5243-8289-41db-80a7-a88962b85e92"
/dev/sda2: LABEL="root-x86-64" UUID="24520d0f-3e13-43b5-b0c9-b418cf50164c" TYPE="ext4" PARTLABEL="root-x86-64" PARTUUID="7e235d5c-cc7a-6776-fccf-120b2b86cb2f"
/dev/sda3: UUID="50b51166-347f-4478-8892-10b6e438c563" TYPE="DM_verity_hash" PARTLABEL="root-x86-64-verity" PARTUUID="e37e4064-8988-10db-f418-286f9ae94076"
/dev/sda4: LABEL="srv" UUID="691ce3e3-17a1-48fb-82d2-814d3da322b6" TYPE="ext4" PARTLABEL="srv" PARTUUID="8115ab6c-137a-49d7-80f4-a8476282cf9d"
/dev/nvme0n1p2: LABEL="root-x86-64" UUID="24520d0f-3e13-43b5-b0c9-b418cf50164c" TYPE="ext4" PARTLABEL="root_1" PARTUUID="7e235d5c-cc7a-6776-fccf-120b2b86cb2f"
/dev/nvme0n1p4: UUID="50b51166-347f-4478-8892-10b6e438c563" TYPE="DM_verity_hash" PARTLABEL="root-verity_1" PARTUUID="e37e4064-8988-10db-f418-286f9ae94076"
/dev/nvme0n1p6: LABEL="srv" UUID="41106901-caf0-4fff-af75-f3d576db144d" TYPE="ext4" PARTLABEL="srv" PARTUUID="68741eb6-97cb-4b66-ae84-8b7c612e0020"
/dev/mapper/root: LABEL="root-x86-64" UUID="24520d0f-3e13-43b5-b0c9-b418cf50164c" TYPE="ext4"
/dev/nvme0n1p3: PARTLABEL="_empty" PARTUUID="c24bbf42-a3cc-4725-af16-df486984187d"
/dev/nvme0n1p5: PARTLABEL="_empty" PARTUUID="6c90b41a-5c7d-4f8f-ba74-d16566db5c3e"
/dev/sda1: LABEL_FATBOOT="ESP" LABEL="ESP" UUID="A25B-8FBD" TYPE="vfat" PARTLABEL="esp" PARTUUID="ac2e5243-8289-41db-80a7-a88962b85e92"
/dev/sda2: LABEL="root-x86-64" UUID="24520d0f-3e13-43b5-b0c9-b418cf50164c" TYPE="ext4" PARTLABEL="root-x86-64" PARTUUID="7e235d5c-cc7a-6776-fccf-120b2b86cb2f"
/dev/sda3: UUID="50b51166-347f-4478-8892-10b6e438c563" TYPE="DM_verity_hash" PARTLABEL="root-x86-64-verity" PARTUUID="e37e4064-8988-10db-f418-286f9ae94076"
/dev/sda4: LABEL="srv" UUID="691ce3e3-17a1-48fb-82d2-814d3da322b6" TYPE="ext4" PARTLABEL="srv" PARTUUID="8115ab6c-137a-49d7-80f4-a8476282cf9d"
On Tue, Jun 13, 2023 at 2:25 PM Lennart Poettering <lennart@xxxxxxxxxxxxxx> wrote:
On Mo, 12.06.23 15:28, Marius Schiffer (marius.schiffer@xxxxxxxxx) wrote:
> Hi,
>
> I'm currently building an OS image (with mkosi), for which I'm struggling
> to find a suitable installation and updating strategy for. One requirement
> is a self-replicating install. It should be bootable from a USB stick with
> full functionality and be installable from there.
>
> I settled on using verity protected partitions with their roothash embedded
> into the signed UKI's cmdline.
> This works perfectly fine for booting from the USB stick.
> For the installation, I use systemd-repart to create slots for A/B
> partitions and copying the partitions from the USB stick by block to the
> first slot.
> Updating using systemd-sysupdate (on the installed system) installs a new
> data and verity partition in the unused slot and a UKI with the
> corresponding roothash. systemd-boot can then sort the UKIs by version.
>
> Unfortunately, copying the data and verity partitions on installation of
> course results in the same partition UUIDs on the installed medium and the
> USB stick. UUID collision results in unpredictable mounting when both the
> installed medium and the USB stick is present (which could be the case for
> reinstallation for some reason, or if the USB stick was left on
> reboot).
If systemd-gpt-auto-generator is used to mount these, then
https://github.com/systemd/systemd/commit/1a81ddef00a0a25f6bcdd1e6633430e8b240b87f
should address your issue, no? because then we'll not mount by uuid
anymore, but purely by diskseq ensuring that the stuff
gpt-auto-generator finds is also the stuff we'll end up mounting
eventually.
Lennart
--
Lennart Poettering, Berlin
