<div dir="ltr"><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, Oct 7, 2024 at 11:23 AM Lennart Poettering <<a href="mailto:lennart@poettering.net">lennart@poettering.net</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Fr, 04.10.24 15:03, Fredrik Hugosson (<a href="mailto:hugo@axis.com" target="_blank">hugo@axis.com</a>) wrote:<br>
<br>
> On 2024-09-11 14:28, Lennart Poettering wrote:<br>
> > On Mi, 11.09.24 11:43, Fredrik Hugosson (<a href="mailto:fredrik.hugosson@axis.com" target="_blank">fredrik.hugosson@axis.com</a>) wrote:<br>
> ><br>
> > > Hi!<br>
> > ><br>
> > > I'm trying to use the systemd-cryptsetup@.service<mailto:<a href="mailto:systemd-cryptsetup@" target="_blank">systemd-cryptsetup@</a>.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:<a href="mailto:fsck@" target="_blank">fsck@</a>.service> and mount@.service<mailto:<a href="mailto:mount@" target="_blank">mount@</a>.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:<a href="mailto:systemd-cryptsetup@" target="_blank">systemd-cryptsetup@</a>.service> shows.<br>
> > ><br>
> > > 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<br>
> > ><br>
> > > .....<br>
> >><br>
> > > On my host system, I have noticed that some udev rules stemming from<br>
> > > LVM2 mention device mapper, do we need to also install LVM2 to make<br>
> > > device mapping work? In that case do we need the whole LVM2 or only<br>
> > > some subset? I have tried various combinations of these rules on my<br>
> > > product but nothing seems to solve the issue.<br>
> ><br>
> > No, you do not need LVM for LUKS. You do need libdevmapper (i.e. DM<br>
> > userspace) for it though, because libcryptsetup needs that.<br>
> ><br>
> > This is typically an integration issue with your distro. Please ping<br>
> > them.<br>
><br>
> Thanks for the pointer, it was indeed a distro problem, the udev rules<br>
> were missing.<br>
><br>
> But I also got sting by this line in 99-systemd.rules<br>
><br>
> # Ignore encrypted devices with no identified superblock on it, since<br>
> # we are probably still calling mke2fs or mkswap on it.<br>
> SUBSYSTEM=="block", ENV{DM_UUID}=="CRYPT-*", ENV{ID_PART_TABLE_TYPE}=="",<br>
> ENV{ID_FS_USAGE}=="", ENV{SYSTEMD_READY}="0"<br>
><br>
> Which made our (maybe poorly setup) SD-card not being set to READY. I will<br>
> look further into if we can set those identifiers in a better way, but we do<br>
> have a lot of devices out there already without those set.<br>
><br>
> So would it be OK to send in a PR like below to first check if it is already<br>
> set?<br>
><br>
> SUBSYSTEM=="block", ENV{DM_UUID}=="CRYPT-*", ENV{ID_PART_TABLE_TYPE}=="",<br>
> ENV{ID_FS_USAGE}=="", ENV{SYSTEMD_READY}=="", ENV{SYSTEMD_READY}="0"<br>
><br>
> Then we can add our own rules file before, which sets our specific card to<br>
> ready. I could also just put our rule after, but with the 99- naming and<br>
> lexicographic ordering it starts to be a naming contest to get it to run<br>
> after the systemd rule.<br>
<br>
Not sure I grok this? Why should those devices be detected as ready,<br>
if they don't have a file system or partition table? What's the<br>
rationale here?<br>
<br>
Aren't you just proprosing some workaround for your distro's broken<br>
udev setup? (i.e. a hosed blkid setup or so?)<br></blockquote><div><br></div><div>What? Since when does readiness have anything to do with the block device's contents in the first place?</div><div><br></div><div>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.<br></div></div><br><span class="gmail_signature_prefix">-- </span><br><div dir="ltr" class="gmail_signature"><div dir="ltr">Mantas Mikulėnas</div></div></div>