How do image-based systems figure out what partition sizes they need?

> With such a system, how does determine partition sizes that are a) big enough to be future-proof for whatever system software you might want to install later, while b) not taking up unneeded space that might be later wanted for user data?

Usually, there's well-known sizes which are parameters of your deployment:

- ESP, fixed size (1GB or so)
- Nix store (so the code, the config, etc.), we put some reasonable limits here, let's say 200GB
- Verity partition for Nix store, answer: https://github.com/systemd/systemd/pull/34636 (another contributor of this whole project made this PR)
- User data, minimized size for initial startup and then automatic grow

(add the extra salt for A/B schema)

If that's not enough, I kind of asked this question during the image based summit, see: https://lwn.net/Articles/994704/ under "ESP resizing", the suggested solution is dm-linear.

So theoretically, if you overcome your 200GB budget, and you really need to do fancy things, I suppose a dm-linear based solution can do smart things if you can safely downsize the user partition.

Nonetheless, for an image-based system: `/srv`, `/home` doesn't really exist, I would map everything to `/var`, the only mutable partition in the setup. And bind mount `/home` to `/var/home`, etc. So it may look like your unified encrypted root setup, except that the Nix store doesn't require confidentiality as long you don't put secrets in your code or configuration and use systemd-credentials (or similar concepts).