Re: Mapped device not becoming active

[Lennart Poettering <lennart@xxxxxxxxxxxxxx>]

On Fr, 04.10.24 15:03, Fredrik Hugosson (hugo@xxxxxxxx) wrote:

> 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.

Not sure I grok this? Why should those devices be detected as ready,
if they don't have a file system or partition table? What's the
rationale here?

Aren't you just proprosing some workaround for your distro's broken
udev setup? (i.e. a hosed blkid setup or so?)

Lennart

--
Lennart Poettering, Berlin