#1089516 kpartx won't handle boot cryptsetup'ed devices after decryption

Package:
kpartx
Source:
kpartx
Description:
create device mappings for partitions
Submitter:
Sergey Aleynikov
Date:
2024-12-08 19:45:01 UTC
Severity:
normal
Tags:
#1089516#5
Date:
2024-12-08 10:04:50 UTC
From:
To:
Dear Maintainer,

After upgrading from bullseye to bookworm, my boot sequence for assembling devices for the / partition stopped working.
I have the following scheme in place:

   /dev/sdh - separate unencrypted /boot
   /dev/sd[a-f] -> cryptsetup
X     /dev/disk[1-6] -> drive partition (kpartx acts here)
         /dev/disk[1-6]-part1 - mdadm raid with /

Prior to bookworm, all those steps happend automatically during boot, but after the upgrade second step marked X
won't occur without manual intervention - boot won't proceed, dropping me to console. After manually running kpartx -a,
boot proceeds normally and all later stages drives are assembled correctly.

While investigating this, I found that kpartx package has two following changes between bullseye and bookworm:

- dropped /lib/udev/dmsetup_env
- removed IMPORT{program}="dmsetup_env %M %m" line from /lib/udev/rules.d/60-kpartx.rules

After reverting those two changes, automatic boot sequence is restored for me. Is it possible to revert this change and restore
old correct behaviour? Or is some new mechanism suggested (and in this case it'd be great to mention it in Changes,
as currently there's no mentions of possible breakage and workarounds)?

#1089516#10
Date:
2024-12-08 18:15:09 UTC
From:
To:
* Sergey Aleynikov <sergey.aleynikov+deb@gmail.com> [241208 11:09]:

If dmsetup_env helps with anything, then you found some other
package's udev rules relying on extremely outdated stuff.

dmsetup_env should have exported DM_NAME, DM_UUID, DM_STATE=ACTIVE,
DM_TABLE_STATE=LIVE. DM_NAME and DM_UUID should be exported by the
dmsetup udev helper (from src:lvm2).

Hope that helps.

Chris

#1089516#17
Date:
2024-12-08 19:40:35 UTC
From:
To:
* Sergey Aleynikov <sergey.aleynikov@gmail.com> [241208 20:02]:

Maybe, maybe not.

ISTM you'll need to debug why adding dmsetup_env changes anything.
Maybe there's some form of race and having dmsetup_env just changes
the timing.

Chris