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 On Sat, Oct 19, 2024, 20:21 Thayne Harbaugh <tha...@mastodonlabs.com> 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: > > https://github.com/plastikos/repart_howto > > 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 >
