Hello, I might have spotted something You tell repart to encrypt with a keyfile, but it seems like you don't pass in which keyfile to use. 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. Apologies if I'm wrong. I'm on my phone and haven't pulled up the docs to verify. Best, Adrian <div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Sat, Oct 19, 2024, 20:21 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">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 </blockquote></div>