> 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.hun...@gmail.com> wrote: > Hi Lennart, > > On Wed, May 20, 2020 at 12:01 PM Lennart Poettering > <lenn...@poettering.net> wrote: > > On Mi, 20.05.20 00:12, Tobias Hunger (tobias.hun...@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@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
_______________________________________________ systemd-devel mailing list systemd-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/systemd-devel
