<div dir="ltr">> gpt-auto is not enough. I will want to set up pretty complex things <div> like dm/crypto/etc.</div><div> </div><div>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.</div><div>But I don't think more complex devicemapper setups are supported like dm-raid are supported. </div><div></div><div></div></div> <div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Wed, May 20, 2020 at 1:58 PM Tobias Hunger <<a href="mailto:tobias.hunger@gmail.com">tobias.hunger@gmail.com</a>> wrote: </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi Lennart, On Wed, May 20, 2020 at 12:01 PM Lennart Poettering <<a href="mailto:lennart@poettering.net" target="_blank">lennart@poettering.net</a>> wrote: > On Mi, 20.05.20 00:12, Tobias Hunger (<a href="mailto:tobias.hunger@gmail.com" target="_blank">tobias.hunger@gmail.com</a>) 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 <a href="mailto:systemd-devel@lists.freedesktop.org" target="_blank">systemd-devel@lists.freedesktop.org</a> <a href="https://lists.freedesktop.org/mailman/listinfo/systemd-devel" rel="noreferrer" target="_blank">https://lists.freedesktop.org/mailman/listinfo/systemd-devel</a> </blockquote></div> -- <div dir="ltr" class="gmail_signature"><div dir="ltr"> Zeta Project Germany GmbH l <a href="https://maps.google.com/?q=Rosenthaler+Stra%C3%9Fe+40,%C2%A0+10178+Berlin,%C2%A0+Germany&entry=gmail&source=g" target="_blank">Rosenthaler Straße 40, </a><a href="https://maps.google.com/?q=Rosenthaler+Stra%C3%9Fe+40,%C2%A0+10178+Berlin,%C2%A0+Germany&entry=gmail&source=g" target="_blank">10178 Berlin, </a><a href="https://maps.google.com/?q=Rosenthaler+Stra%C3%9Fe+40,%C2%A0+10178+Berlin,%C2%A0+Germany&entry=gmail&source=g" target="_blank">Germany</a> Geschäftsführer/Managing Director: Morten J. Broegger, Dylan RileyHRB 149847 beim Handelsregister Charlottenburg, BerlinVAT-ID DE288748675</div></div>