[systemd-devel] Mapped device not becoming active

[Fredrik Hugosson]

On 2024-09-11 14:28, Lennart Poettering wrote:
> On Mi, 11.09.24 11:43, Fredrik Hugosson (fredrik.hugosson at axis.com) wrote:
> 
>> Hi!
>>
>> I'm trying to use the systemd-cryptsetup at .service<mailto:systemd-cryptsetup at .service> to open a LUKS encrypted device, everything works nice except that systemd never realizes that the corresponding device-unit is active, which leads to fsck at .service<mailto:fsck at .service> and mount at .service<mailto:mount at .service> waiting for the device to become active. I can fsck and mount manually so the cryptsetup service succeded, which also is what systemctl status systemd-cryptsetup at .service<mailto:systemd-cryptsetup at .service> shows.
>>
>> The HW is an embedded product on ARM 64 bit architecture, built on Yocto 5.0 (April 2024), with kernel 5.15 and systemd 255
>>
>>.....
 >>
>> On my host system, I have noticed that some udev rules stemming from
>> LVM2 mention device mapper, do we need to also install LVM2 to make
>> device mapping work? In that case do we need the whole LVM2 or only
>> some subset? I have tried various combinations of these rules on my
>> product but nothing seems to solve the issue.
> 
> No, you do not need LVM for LUKS. You do need libdevmapper (i.e. DM
> userspace) for it though, because libcryptsetup needs that.
> 
> This is typically an integration issue with your distro. Please ping
> them.

Thanks for the pointer, it was indeed a distro problem, the udev rules
were missing.

But I also got sting by this line in 99-systemd.rules

# Ignore encrypted devices with no identified superblock on it, since
# we are probably still calling mke2fs or mkswap on it.
SUBSYSTEM=="block", ENV{DM_UUID}=="CRYPT-*", 
ENV{ID_PART_TABLE_TYPE}=="", ENV{ID_FS_USAGE}=="", ENV{SYSTEMD_READY}="0"

Which made our (maybe poorly setup) SD-card not being set to READY. I 
will look further into if we can set those identifiers in a better way, 
but we do have a lot of devices out there already without those set.

So would it be OK to send in a PR like below to first check if it is 
already set?

SUBSYSTEM=="block", ENV{DM_UUID}=="CRYPT-*", 
ENV{ID_PART_TABLE_TYPE}=="", ENV{ID_FS_USAGE}=="", 
ENV{SYSTEMD_READY}=="", ENV{SYSTEMD_READY}="0"

Then we can add our own rules file before, which sets our specific card 
to ready. I could also just put our rule after, but with the 99- naming 
and lexicographic ordering it starts to be a naming contest to get it to 
run after the systemd rule.

Thanks!
/Fredrik Hugosson

> Lennart
> 
> --
> Lennart Poettering, Berlin