<div dir="auto"><div>Responses inline <div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Oct 19, 2024, 21:52 Thayne Harbaugh <<a href="mailto:thayne@mastodonlabs.com">thayne@mastodonlabs.com</a>> wrote: </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Response in line: On Sat, 2024-10-19 at 20:36 -0400, Adrian Vovk wrote: > Hello, > I might have spotted something Thank you for reviewing my long email. > You tell repart to encrypt with a keyfile, but it seems like you > don't pass in which keyfile to use. Maybe I'm confused about how Encrypt= and EncryptedVolume= interact. >From repart.d(5) v256.7: EncryptedVolume= Specify how the encrypted partition should be set up. Takes at least one and at most three fields separated with a colon (":"). The first field specifies the encrypted volume name under /dev/mapper/. If not specified, "luks-UUID" will be used where "UUID" is the LUKS UUID. The second field specifies the keyfile to use following the same format as specified in crypttab. The third field specifies a comma-delimited list of crypttab options. These fields correspond to the first, third and fourth column of the crypttab(5) format. Note that this setting is only taken into account when --generate-crypttab= is specified on the systemd-repart command line. Added in version 256. My (possibly incorrect) understanding is that EncryptedVolume= specifies the key-file in the second position - which in my demo code is the following: Encrypt=key-file EncryptedVolume=dc-xdata:/run/fscrypt.sock:luks,discard Which would then be /run/fscrypt.sock. Am I confused about Encrypt= and EncryptedVolume= ? </blockquote></div></div><div dir="auto"> </div><div dir="auto">Yeah I think you are. I'm pretty sure EncryptedVolume= is about defining what goes into /etc/crypttab, and thus how the volume is set up at runtime or at boot. Not how the volume is set up when it's created. Basically each EncryptedVolume= entry is an entry in /etc/crypttab and no more.</div><div dir="auto"> </div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> > By default, repart will encrypt > with a null key in that case. IIRC, you have to pass in the keyfile > (or maybe socket) to use in your drop-in. I feel like I should know what my "drop-in" ... but I have no idea. Is thet the repart.d/30-xdata.conf? Is it the override I made to systemd-repart.service as systemd-repart.service.d/systemd-repart-gen_tabs.conf ? </blockquote></div></div><div dir="auto"> </div><div dir="auto">I mean the override you made to systemd-repart.service</div><div dir="auto"> </div><div dir="auto">Best,</div><div dir="auto">Adrian </div><div dir="auto"> </div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> > Apologies if I'm wrong. I'm on my phone and haven't pulled up the > docs to verify. Maybe you can send something with more details when you have access to a system. Thank you for the response.</blockquote></div></div><div dir="auto"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"> > Best, > Adrian > > On Sat, Oct 19, 2024, 20:21 Thayne Harbaugh <<a href="mailto:thayne@mastodonlabs.com" target="_blank" rel="noreferrer">thayne@mastodonlabs.com</a>> > wrote: > > Greetings - apologies if this isn't the proper list - please > > redirect > > me. > > > > I'm writing a systemd-repart HOWTO with demo code for various use > > cases: > > > > <a href="https://github.com/plastikos/repart_howto" rel="noreferrer noreferrer" target="_blank">https://github.com/plastikos/repart_howto</a> > > > > The HOWTO is a typical document while the demos are minimal cases > > built with mkosi and available for growing into larger solutions. > > > > Initially it has two use-case demos: > > > > 1. Creating a new partition (xdata) on first boot > > > > 2. Creating a new partition (xdata) with encryption on first boot > > > > Currently #1 works. It's simple. I still need to create more > > details > > around growing partitions and other ideas. > > > > The encryption case #2, however, does not work and I'm looking for > > some assistance. While there is significant documentation around > > the > > systemd ecosystem of tools I feel like I have possibly missed some > > detail or may not be understanding how to synthesize the > > information > > into a working model. > > > > The encryption demo is identical to case #1 of adding a partition > > with > > the following changes: > > > > 1. The /usr/lib/repart.d/30-xdata.conf file adds the following: > > > > Encrypt=key-file > > EncryptedVolume=dc-xdata:/run/fscrypt.sock:luks,discard > > > > 2. a /usr/lib/systemd/system/fscrypt.socket file is added along > > with > > a fscrypt@.service file (see the project source, please). > > > > 3. A /usr/bin/getkey file is added for fscrypt@.service to call. > > getkey provides a simplistic way of producing an encryption > > key > > for *demonstration* purposes *ONLY*. > > > > 4. A /var/lib/key.bin is added as a binary encryption key that > > getkey retrieves - for *demonstration* purposes *ONLY*. > > > > When built into a disk image by mkosi and started with qemu it > > fails > > to create the new xdata partition. I see quite a few journal > > messages > > from systemd-repart and related udev events. I have verified a few > > things: > > > > 1. /run/fscrypt.sock does get created > > > > 2. getkey does emit the encryption key to stdout > > > > 3. systemd-repart is started and initiates creating a partition > > with > > LUKS > > > > There are two notable details that cause me concern and might be > > where > > the problem lies: > > > > 1. There is no evidence that getkey is invoked even when I > > instrument it to generate side-effects. > > > > 2. There are messages in the journal that indicate that > > systemd-repart never exits and that it might be in deadlock > > waiting > > for child events. > > > > The messages around the possible deadlock of #2 above are the > > following: > > > > Oct 19 12:08:48.510843 localhost systemd-repart[276]: loop0: > > Acquired exclusive lock. > > Oct 19 12:08:48.512130 localhost systemd-repart[276]: > > Successfully acquired /dev/loop0, devno=7:0, nr=0, diskseq=11 > > Oct 19 12:08:48.516941 localhost systemd-repart[276]: Encrypting > > future partition 2... > > Oct 19 12:08:48.517077 localhost systemd-repart[276]: Allocating > > context for crypt device /dev/loop0. > > <SNIP/> > > Oct 19 12:08:49.114118 localhost (udev-worker)[299]: loop0: > > Processing device (SEQNUM=1996, ACTION=change) > > Oct 19 12:08:49.114972 localhost (udev-worker)[299]: loop0: > > Failed to flock(/dev/loop0): Resource temporarily unavailable > > Oct 19 12:08:49.114979 localhost (udev-worker)[299]: loop0: Block > > device is currently locked, requeueing the event. > > <SNIP/> > > Oct 19 12:08:49.328308 localhost (udev-worker)[296]: loop0: > > Processing device (SEQNUM=1996, ACTION=change) > > Oct 19 12:08:49.328345 localhost (udev-worker)[296]: loop0: > > Failed to flock(/dev/loop0): Resource temporarily unavailable > > Oct 19 12:08:49.328352 localhost (udev-worker)[296]: loop0: Block > > device is currently locked, requeueing the event. > > <SNIP/> > > > > Those last three messages about failing to lock repeat until QEMU > > is > > shut down. > > > > There are quite a few additional diagnostic details and logs that > > may > > be of interest but it might be easier to clone the repart_howto > > project from github and run it: > > > > >$ ./demo crypt > > > > Once it executes all of the mkosi configuration files and disk > > image > > are in the build-crypt sub-directory. All relevant files specific > > to > > partition creation and encryption are in build-crypt/mkosi.extra - > > there are not many since I'm trying to keep the demo as simple as > > possible. All relevant journal events and state information can be > > extracted from build-crypt/image.raw. > > > > Thanks for either directing me to a more appropriate help resource > > and/or providing direct assistance. > > > > > > P.S. If you want to run demo #1 of partition creation sans > > encryption > > then execute the following from the project source tree: > > > > >$ ./demo clear -- Big Solutions </blockquote></div></div></div>