On 2024-09-11 14:28, Lennart Poettering wrote:
On Mi, 11.09.24 11:43, Fredrik Hugosson (fredrik.hugosson@xxxxxxxx) wrote:
Hi!
I'm trying to use the systemd-cryptsetup@.service<mailto:systemd-cryptsetup@.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@.service<mailto:fsck@.service> and mount@.service<mailto:mount@.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@.service<mailto:systemd-cryptsetup@.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
