[systemd-devel] Image based OS, CopyBlocks, verity and duplicate UUIDs
Marius Schiffer
marius.schiffer at gmail.com
Thu Jun 15 13:04:40 UTC 2023
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"
On Tue, Jun 13, 2023 at 2:25 PM Lennart Poettering <lennart at poettering.net>
wrote:
> On Mo, 12.06.23 15:28, Marius Schiffer (marius.schiffer at gmail.com) 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20230615/6d9d2080/attachment.htm>
More information about the systemd-devel
mailing list