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

Wed May 20 12:29:11 UTC 2020

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

Note that gpt-auto-generator will detect if the partition is a LUKS
partition or has dm-verity, and will set up a `/dev/mapper/root` device
automatically.
But I don't think more complex devicemapper setups are supported like
dm-raid are supported.

On Wed, May 20, 2020 at 1:58 PM Tobias Hunger <tobias.hunger at gmail.com>
wrote:

> 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
> _______________________________________________
> systemd-devel mailing list
> systemd-devel at lists.freedesktop.org
> https://lists.freedesktop.org/mailman/listinfo/systemd-devel
>

-- 

*Zeta Project Germany GmbH  *l  Rosenthaler Straße 40,
<https://maps.google.com/?q=Rosenthaler+Stra%C3%9Fe+40,%C2%A0+10178+Berlin,%C2%A0+Germany&entry=gmail&source=g>10178
Berlin,
<https://maps.google.com/?q=Rosenthaler+Stra%C3%9Fe+40,%C2%A0+10178+Berlin,%C2%A0+Germany&entry=gmail&source=g>
Germany
<https://maps.google.com/?q=Rosenthaler+Stra%C3%9Fe+40,%C2%A0+10178+Berlin,%C2%A0+Germany&entry=gmail&source=g>

Geschäftsführer/Managing Director: Morten J. Broegger, Dylan Riley

HRB 149847 beim Handelsregister Charlottenburg, Berlin

VAT-ID DE288748675
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20200520/4fd703b6/attachment.htm>