Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.bugs.dist > #1223191 > unrolled thread

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

Back to article view | Back to linux.debian.bugs.dist

Contents

  Bug#1089516: kpartx won't handle boot cryptsetup'ed devices after decryption Sergey Aleynikov <sergey.aleynikov+deb@gmail.com> - 2024-12-08 11:10 +0100
    Bug#1089516: kpartx won't handle boot cryptsetup'ed devices after decryption Chris Hofstaedtler <zeha@debian.org> - 2024-12-08 19:20 +0100
    Bug#1089516: kpartx won't handle boot cryptsetup'ed devices after decryption Chris Hofstaedtler <zeha@debian.org> - 2024-12-08 20:50 +0100

#1223191 — Bug#1089516: kpartx won't handle boot cryptsetup'ed devices after decryption

Package: kpartx
Version: 0.9.4-3+deb12u1
Severity: important
X-Debbugs-Cc: sergey.aleynikov+deb@gmail.com

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)?


-- System Information:
Debian Release: 12.8
  APT prefers stable-security
  APT policy: (500, 'stable-security'), (500, 'stable')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.1.0-28-amd64 (SMP w/56 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) (ignored: LC_ALL set to en_US.UTF-8), LANGUAGE=en_US:en
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)

Versions of packages kpartx depends on:
ii  dmsetup             2:1.02.185-2
ii  libc6               2.36-9+deb12u9
ii  libdevmapper1.02.1  2:1.02.185-2
ii  udev                254.16-1~bpo12+1

kpartx recommends no packages.

kpartx suggests no packages.

-- no debconf information

[toc] | [next] | [standalone]

#1223251

Control: tags -1 + wontfix

* Sergey Aleynikov <sergey.aleynikov+deb@gmail.com> [241208 11:09]:
> 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)?

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

[toc] | [prev] | [next] | [standalone]

#1223258

* Sergey Aleynikov <sergey.aleynikov@gmail.com> [241208 20:02]:
> > 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).
> 
> I've generated a list of all files in /lib/udev/rules.d mentioning
> DM_* variables with the following script:
> 
> ack -c DM_ /lib/udev/rules.d/|grep -v ':0'|cut -d: -f1|xargs -n1 dpkg -S
> kpartx: /lib/udev/rules.d/68-del-part-nodes.rules
> dmsetup: /lib/udev/rules.d/55-dm.rules
> dmsetup: /lib/udev/rules.d/95-dm-notify.rules
> systemd: /lib/udev/rules.d/99-systemd.rules
> lvm2: /lib/udev/rules.d/56-lvm.rules
> lvm2: /lib/udev/rules.d/69-lvm.rules
> kpartx: /lib/udev/rules.d/60-kpartx.rules
> dmsetup: /lib/udev/rules.d/60-persistent-storage-dm.rules
> kpartx: /lib/udev/rules.d/56-dm-parts.rules
> 
> Than I proceeded to compare the content of all those files with
> originals from the respected packages, and the only different found
> was my modification of reverting a single line in 60-kpartx.rules, so
> if there is a some obsolete usage it's packaged with boorkworm.

> Should
> this report be then moved to lvm2?

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

[toc] | [prev] | [standalone]

Back to top | Article view | linux.debian.bugs.dist

csiph-web