[systemd-devel] Mapped device not becoming active

[Mantas Mikulėnas]

On Mon, Oct 7, 2024 at 11:23 AM Lennart Poettering <lennart at poettering.net>
wrote:

> On Fr, 04.10.24 15:03, Fredrik Hugosson (hugo at axis.com) wrote:
>
> > 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@
> .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.
>
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.freedesktop.org/archives/systemd-devel/attachments/20241007/1bcc5ab0/attachment.htm>