[systemd-devel] How to use systemd-repart partitions?

[Lennart Poettering]

On Mi, 20.05.20 00:12, Tobias Hunger (tobias.hunger at gmail.com) wrote:

>
> The one thing that is frustrating is to get a machine image generated
> by my build server onto a new piece of hardware. So I wanted to see
> how far I can get with systemd-repart and co. to get this initial
> deployment to new hardware more automated after booting with the
> machine image from an USB stick.

So I eventually want to cover three usecases with systemd-repart:

1. building OS images
2. installing an OS from an installer medium onto a host medium
3. adapting an OS images to the medium it has been dd'ed to on first
   boot

I think the 3rd usecase we already cover quite OK.

To deliver the others, I want to add Encrypt= and Format= as
mentioned. To cover the 2nd usecase I then also want to provide
CopyBlocks= and CopyFiles=. The former would stream data into a
partition that is created on the block level. Primary usecase would be
to copy a partition 1:1 from the installer medium onto the host
medium. The latter would copy in a file tree on the fs level.

Image builder tools such as "mkosi" could make use of this to be
simplified a bit: an invocation of "systemd-repart" will set up the
basic partition layout and file systems. "systemd-dissect --mount"
would then mount this, before dnf/apt/… are run. "bootctl --image=…"
would then install the boot loader (that switch doesn't exist yet, but
is on the todo list, too).

Installer tools would just need one invocation of "systemd-repart" to
make the basic partitions, and stream in the OS. This is then followed
by "bootctl --image=…" to install the boot loader. Possibly
"systemd-firstboot --image=…" is finally used to set root pw and such
(yeah, this optoin doesn't exist yet either, but you get the idea).

On first boot, "systemd-repart" would run to add in swap or so, maybe
scaled by RAM size or so, and maybe format and encrypt /home.

> I would -- if I was sure what the best solution for the problem is:-)
>
> I have an immutable image on an USB stick that I boot from. That
> contains systemd-repart files in /usr/lib/repart.d, /etc/fstab,
> /etc/crypttab and whatever else that is needed. I want to boot from
> that USB stick, use it to partition hardware as configured in the
> image and then copy the image over to the hdd. Think of it as
> auto-install:-)

This sounds for the perfect usecase for systemd-repart.

> With your extended systemd-repart: How can I reference these newly
> created filesystems in /etc/fstab?

Well, my thinking was to mostly rely on the "gpt-auto" logic,
i.e. that simply because they carry correct gpt type uuids systemd
would discover and find them.

> Labels suck, UUIDs are generated and not known before they are written
> to disk (and not even then, since systemd-repart might skip some
> partitions, changing UUIDs of those with the same type that come
> later) and partition numbers are not fixed as systemd-repart may leave
> out low-priority partitions.
>
> So how can I reliably reference filesystems newly created by
> systemd-repart in /etc/fstab?

So, if the gpt auto logic doesn't suffice, then probably labels. Or
you come up with your own UUIDs for the partitions.

> Is providing UUIDs (both for filesystems as well as for partitions) in
> addition to labels (both for filesystems once that becomes available
> or for partitions) the best approach? I can't think of something
> better, but that does not mean there is nothing;-)

So I'd not discount labels. I think we should start supporting
specifier expansion in the label strings, so that we can generate them
somewhat automatically, derived from environment parameters.

> PS: Is systemd-tmpfiles run after mounts with --prefix=/mnt/point? Or
> how do you see people populating the newly created filesystems?

As indicated above with CopyBlocks= and CopyFiles= if this shall be
done during image creation. Copying in blocks and files is probably a
20 line patch or so only (we have helpers for it in place anyway, we
just need to call them), and has again this nice benefit that we can
schedule it so that the partitions pop up fully populated and there's
no time where they are half initialized. This means you can abort an
installer any time and the disk will appear as it was before, only
when it comes to the very latest step the partitions suddenly pop into
existance, fully populated with whatever they shall contain.

That said, I also want to add an --image= switch to "systemd-tmpfiles"
and "systemd-sysusers" so that you can run them easily offline too if
you want, just by pointing them to some disk image.

Lennart

--
Lennart Poettering, Berlin