On Mon, Oct 7, 2024 at 11:23 AM Lennart Poettering <lenn...@poettering.net> wrote:
> On Fr, 04.10.24 15:03, Fredrik Hugosson (h...@axis.com) wrote: > > > On 2024-09-11 14:28, Lennart Poettering wrote: > > > On Mi, 11.09.24 11:43, Fredrik Hugosson (fredrik.hugos...@axis.com) > 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
