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

[Tobias Hunger]

Hi Lennart,

On Wed, May 20, 2020 at 12:01 PM Lennart Poettering
<lennart at poettering.net> wrote:
> 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.

Yeap.

> 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=.

I assume CopyBlocks= will just dd and so does not need a formatted partition?

CopyFiles= obviously does.

> 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.

What about things like create subvolumes on BTRFS? systemd-tmpfiles
does support that.

> 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).

Yes, I am considering to move my image generation over to
systemd-repart as well.

> 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.

gpt-auto is not enough. I will want to set up pretty complex things
like dm/crypto/etc.

> > 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.

I opened a PR for custom partition UUIDs.

> 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.

I will probably prefer UUIDs to uniquely identify something over labels:-)

> > 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.

Nice, but what about btrfs subvolumes? I will probably end up needing those:-)

Best Regards,
Tobias

> 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.

Good idea!

Best Regards,
Tobias