[systemd-devel] Antw: [EXT] Re: [systemd‑devel] Running actual systemd‑based distribution image in systemd‑nspawn

[Lennart Poettering]

On Mo, 11.07.22 13:57, Ulrich Windl (Ulrich.Windl at rz.uni-regensburg.de) wrote:

> > That said: I strongly recommend that distros ship empty /etc/fstab by
> > default, and rely on GPT partition auto discovery
> > (i.e. systemd‑gpt‑auto‑generator) to mount everything, and only depart
> > from that if there's a strong reason to, i.e. default mount options
> > don't work, or external block device referenced or so.
>
> What if you have multiple operating systems in various partitions on one
> disk?
> /etc/fstab absolutely makes sense

See boot loader spec about that. Basically, the assumption that for
things like swap, /var/tmp or /home it's OK or even a good thing if
shared between OSes. The major execption is /var/ itself, which is per
OS installation and should not be shared between multiple
installations. The boot loader spec hence by default will only
auto-mount /var/ partitions only if the GPT partition uuid of that is
hashed from the machine id.

But there are two distinct concepts here:

1. tag your partitions properly by type uuid. This is always a good
idea, and makes nspawn just work. and all other tools that recognize
partition type uuids, i.e. all the --image= switches systemd tools
have, and so on.

2. actually ship an empty /etc/fstab and rely solely on gpt auto
discovery. i'd always do that whereever possible (i.e. any OS where
multibot does't matter, i.e. appliances, images for VMs/nspawn, cloud
stuff, servers).

i.e. concept 1 should always be done. If you then also adopt concept 2
is up to you. You can, but you don't have to.

Lennart

--
Lennart Poettering, Berlin