On Mon, Oct 7, 2024 at 11:23 AM Lennart Poettering <lennart@xxxxxxxxxxxxxx> wrote:
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?)
What? Since when does readiness have anything to do with the block device's contents in the first place?
It has always been about the device being available for use (multi-device assembled, etc) and not about what it contains. I don't remember a single case where e.g. /dev/sda would be "not ready" because it hasn't been partitioned yet. Partitioning it gives readiness to *child* devices.
--
Mantas Mikulėnas
