I created homed managed user and put home dir onto two 1.92GB SSDs in the MD RAID1 configuration. Storage=LUKS, filesystem=EXT4.
There is the problem with activation of my systemd-homed managed user - activation (via GDM login or in CLI) takes minutes. GDM prompt and CLI times out, but I can check the user status with ‘homectl inspect’ and see when it is activated.
I cannot find what causes such delays - Linux RAID, LUKS, EXT4 or maybe some activation process (homectl):
Activation of a home directory involves various operations that depend on the selected storage mechanism. If the LUKS2 mechanism is used, this generally involves: inquiring the user for a password, setting up a loopback device, validating and activating the LUKS2 volume, checking the file system, mounting the file system, and potentially changing the ownership of all included files to the correct UID/GID.
Yes, I followed this guide. It worked flawlessly on my MacBook Pro where I created my home dir as loopback file. Now I tried to put my home dir onto Linux MD RAID1 block device and user activation takes minutes.
I am interested in how you created the md raid array.
Did you use mdadm and create the array before you put a file system on it?
Was it done during the system install?
Was it created inside the luks file system?
As I understand it, if you used mdadm while booted to the live media and created the array, then rebooted before doing the install the installer should have seen the array as a single device and done its encryption and partitioning as if it were a single physical device.
If the array were created differently then I don’t know how the different pieces would interact when booting. This especially becomes problematic if the array is the fake array created by bios which seems to actually create 2 duplicate array devices and uses mdadm as well as bios to manage the array.
mdadm mirror was created after the system was installed:
I created the RAID1 from two 1.92GB SSDs.
I followed the instruction mentioned in one of the replays above and created homed managed used with --image-path=/dev/md0 among other things.
User was created as per parameters provided, including the storage - EXT4 on LUKS on mdadm RAID1 block device. With the default settings the LUKS discard takes place on user activation and that procedure lasts for 6 minutes for ~1.7TB of empty space. This results into activation time outs (GUI and CLI). I wonder if there is way to configure trim/discard operations in much less intrusive way. Important - none of OS operations (e.g., boot up, etc) are impacted, only homed-managed user activation with the default LUKS discard settings/options.
I assume this means you did the install, and the encryption during the install.
You then booted and added the extra drive using mdadm so the encryption was not done on the array but the array was added after the fact.
I would suspect the order in which that was done is affecting the result.
It is always best to treat an array as a simple device, created before writing to it, not create the array after the fact.
No, maybe I wasn’t clear enough.
OS is installed onto NVME drive for several years already. I used it professionally and for personal purposes with that one NVME drive, my local user’s home dir is on the NVME.
Recently I added two SATA SSDs with the purpose to dedicate both new drives solely for homed managed user’s home dir. So, I created mdadm RAID1 on those two new SATA SSDs and then used md0 block device to store my homed managed user’s (not to confuse with local “normal” linux user) home dir. And it worked except massively long LUKS discard times when activating/deactivating (depending on the LUKS config) homed user. This is the only, but big problem I have.
Exploring homed user on mdadm mirror revealed more strange things, e.g., more “empty” options to system menu were added, e.g., mobile data, bluetooth and other toggles. That wasn’t the case with homed-managed user’s dir on loopback file. It seams that systemd-home has to mature in order to fully cover all intended use cases and functions.
In the meantime I moved my “normal” user’s home to the mdadm mirror without systemd-homed support. It is encrypted and unlocked on boot by cryptsetup which uses the key file from encrypted root. Yes, that is workaround, but fully working and satisfying my security threat model, until systemd-home is ready for prime time.
