Hi!
Waking up an old thread, as we now finally understand the issue better.
Basically, it comes from that some mapped devices are set up in our bootloader,
which does not use udev. So, they are setup in the kernel and can be used, but
udev has no knowledge of them and specifically the device /dev/mapper/<name>
does not exist.
The approach we are taking now is to probe for this kind of mapped devices with
a rule and trigger dmsetup:
# Make udev aware of mapped devices setup directly thru the kernel, and set the
DM_NAME so the rule in 99-systemd.rules does not trigger
SUBSYSTEM=="block", ACTION=="add", KERNEL=="dm-*", ENV{DM_NAME}!="?*",
ATTR{dm/name}=="?*", ENV{DM_NAME}="$attr{dm/name}", RUN+="/usr/sbin/dmsetup
mknodes $attr{dm/name}"
The questions now are:
Is this a good approach?
Is this a common enough use case that makes it worth integrating a solution
upstream and in that case in which rule file?
And last, is there some other approach that could make these devices active
even earlier? E.g. I would like to start the templated systemd service for fsck
as early as possible, not waiting for udev to start.
Thanks,
Fredrik Hugosson
From: Mantas Mikulėnas <[email protected]>
Sent: Monday, October 7, 2024 11:26 AM
To: Lennart Poettering <[email protected]>
Cc: Fredrik Hugosson <[email protected]>; Fredrik Hugosson
<[email protected]>; [email protected]
Subject: Re: [systemd-devel] Mapped device not becoming active
On Mon, Oct 7, 2024 at 11:23 AM Lennart Poettering
<[email protected]<mailto:[email protected]>> wrote:
On Fr, 04.10.24 15:03, Fredrik Hugosson ([email protected]<mailto:[email protected]>)
wrote:
> On 2024-09-11 14:28, Lennart Poettering wrote:
> > On Mi, 11.09.24 11:43, Fredrik Hugosson
> > ([email protected]<mailto:[email protected]>) wrote:
> >
> > > Hi!
> > >
> > > I'm trying to use the
> > > [email protected]<mailto:systemd-cryptsetup@<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 [email protected]<mailto:fsck@<mailto:fsck@>.service> and
> > > [email protected]<mailto:mount@<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
> > > [email protected]<mailto:systemd-cryptsetup@<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
