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

Tobias Hunger tobias.hunger at gmail.com
Tue May 19 22:12:21 UTC 2020


Hi Lennart,

On Tue, May 19, 2020 at 11:26 PM Lennart Poettering
<lennart at poettering.net> wrote:
> So, yes, "systemd-makefs" was how I intended this originally to be
> done. However, I think that's not going to suffice in the long run,
> and instead systemd-repart will soon be able to format file systems
> natively by invoking mkfs.<xyz>. For the following reasons:
>
> 1. Something I find particularly sexy: this way we can format the
>    partitions before writing the partition table. <snip>

Nice!

> 2. We should support setting up encryption, too. <snip>

That was also something I had been wondering about, great that it is
on your agenda already.

> 3. This way we can also derive the fs UUIDs by hashing from the
>    machine ID, like we already do for the partition UUIDs. which makes
>    everything even more deterministic, which I like.

Ok.

> 4. I want to cover the usecase where /usr/ is an immutable (verity
>    verified even) image, and the root fs is created on first boot as
>    writable fs, and then combined with /usr. This kind of setup means
>    the initrd must already format the root fs, and x-systemd.makefs
>    doesn't really cover that so nicely, since its run after the
>    transition to the host fs.

That is close to my use case... I still run immutable systems and am
very happy with the setup I have there.

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.

> Long story short: expect new settings FileSystemType= and Encrypt=
> soon in /etc/repart.d/*.conf files soon. It's high on my TODO list.
>
> > Would it maybe make sense to add a way to provide the partition UUID
> > via the partitions .conf file as well? That way I would not need to
> > add a UUID-part to my labels.
>
> Yes, I guess we can make that available. Please file an RFE
> issue. Even better, provide a patch!

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

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

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?

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

Best Regards,
Tobias

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


More information about the systemd-devel mailing list