This document is mostly just a write-down some thoughts about the partition layout mentioned in Fitting Everything Together.
The proposed layout for image based systems is (all created by systemd-repart
):
- EFI System Partition
usr
Partition (A) with labelfooOS_0.1
usr-verity
Partition (A) with labelfooOS_0.1
usr-verity-sig
Partition (A) with labelfooOS_0.1
usr
Partition (B) with label_empty
usr-verity
Partition (B) with label_empty
usr-verity-sig
Partition (B) with label_empty
root
Partition, encrypted and locked to TPM2home
Partition, integrity protected with TPM2 (managed bysd-homed
)swap
Partition, encrypted and locked to TPM2
This in my mind has the following problems:
- When wanting to dual-boot with Windows an already existing an EFI System Parition will already exist, which by default has ~100M of storage space. This is not enough for generic UKIs (especially not multiple), therefor the XBOOTLDR partiton will be required to store the UKIs. The EFI System Partition would only hause
systemd-boot
, its config and some other small EFI binaries which can be installed withbootctl install
, thereforsystemd-repart
does not need to learn to merge/selectivly copy files into an existing partiton as I see that could cause some unexpected issues down the road. - Having a single
root
partition results in system configuration being modifyable by default, which reduces the barrier to causing accidental breakage. Idealy noroot
partition exists and all the mutable state are split between thevar
and thehome
partition. This has the problem that the UUID of thevar
partition depends on the value of/etc/machine-id
, so ideally there would be anetc
partition (this currently does not exist as part of the Discoverable Partitions Specification) that is populated during installation and then made read-only by default (can be remounted to be read-write if needed) - Splitting mutable state between the
home
partition androot
(/var
) partition has the problem that its very difficult to know how much space should be allocated to each. Once the space is allocated it is difficult to reallocate when more space is needed in one or the other, so ideally thehome
partition is axed andsystemd-homed
learns to manage home directories somewhere in/var/
. This has the problem of nested encryption which isn't good performance wise, so it would be good to have some nice way of layering encryption without performance cost.
This would result in the following partition layout:
- EFI System Partition (managed by
bootctl
) - XBOOTLDR Partition
usr
Partition (A) with labelfooOS_0.1
usr-verity
Partition (A) with labelfooOS_0.1
usr-verity-sig
Partition (A) with labelfooOS_0.1
usr
Partition (B) with label_empty
usr-verity
Partition (B) with label_empty
usr-verity-sig
Partition (B) with label_empty
etc
Partition, encrypted and locked to TPM2var
Partition, encrypted and locked to TPM2 (nested/home/
management bysd-homed
)swap
Partition, encrypted and locked to TPM2
/
would be a specialtmpfs
created during bootup, that is limited to creating symlinks and directories
An installation medium/the generated minimum image would have the following layout:
- EFI System Partition
- XBOOTLDR Partition
usr
Partition (A) with labelfooOS_0.1
usr-verity
Partition (A) with labelfooOS_0.1
usr-verity-sig
Partition (A) with labelfooOS_0.1
/
would be a regulartmpfs
created during bootup (probably determined by the existance of/etc/machine-id
)
For an installation of this kinda system the following steps would be used ($DRIVE
is the target to install on):
systemd-repart --defer-partitions=var --dry-run=false "$DRIVE"
systemd-firstboot --image="$DRIVE" --prompt --setup-machine-id
systemd-repart --dry-run=false "$DRIVE"
bootctl --image="$DRIVE" install
Maybe instead of setting up fully setting up a random machine-id
, sd-firstboot
initializes it to uninitialized
and it mounts the etc
partition during ConditionFirstBoot=true
read-write, commits the generated id, then remounts it read-only. The var
partition would then be identified as uninitialized by a UUID of 4d21b016-b534-45c2-a9fb-5c16e091fd2d
and have its UUID changed to the value of HMAC-SHA256(machine-id, 0x4d21b016b53445c2a9fb5c16e091fd2d)
. Then the installation could be reduced to:
systemd-repart --dry-run=false "$DRIVE"
systemd-firstboot --image="$DRIVE" --machine-id=uninitialized # No --prompt to leave that to the actual first boot, with committing machine-id
bootctl --image="$DRIVE" install
I did often think if this would be the way to go, but I had mostly 2 reasons to not do that:
sd-repart
can do directories in the config, but not so much symlinks (without copying it from somewhere). That is why I decided it would probably be better to just have a specialtmpfs
that is only used to create the root structure and can be used to mount other stuff within it. That way the needed directories are only created when needed, but don't contain any actual content within it. Maybe also just a normaltmpfs
would also suffice, since/etc/
would be RO when it has a separate partition./etc/
should be RO and a new directory needs to be created at/
(for example to serve as a new mount point) you'd need to either have the directory already exist or you need to remount the entire partition to be RW, which I'd prefer not to do.systemd-sysext
would be used in my case for global stuff (DE, podman, neovim, ...) and user specific stuff can always be installed in the home directory (as long as it's notsuid
stuff).