Hi Bastian, Hi Daan De Meyer and Jens Axboe as well, Bastian Blank <[email protected]> (2026-07-06): > On Sat, Jul 04, 2026 at 10:08:13PM +0200, Cyril Brulebois wrote: > > Bastian Blank <[email protected]> (2026-07-04): > > > On Sat, Jul 04, 2026 at 07:27:29PM +0200, Cyril Brulebois wrote: > > > > root@iot-isobuilder-52:~# fallocate -l 1G foo.img > > > > root@iot-isobuilder-52:~# kpartx -asv foo.img > > > Why kpartx and not losetup -P? kpartx uses device mapper, while losetup > > > -P uses the internal partition support of the kernel. > > That's been working for me for many years, and I never noticed losetup > > -P until today. kpartx also happens to be what's used by vmdb2 in > > various recipes, including the basis for that particular image build. > > Please try replacing kpartx with losetup.
While I appreciate the suggestion to switch to newer tools, I'm not sure
it's OK to sweep what seems to be an obvious kernel regression under the
rug.
With v6.12.100 becoming available for trixie (Debian 13) today I've had
a quick look at upstream commits in the stable branch, and didn't see
anything that might fix this issue. Checking mainline master, this
commit from Daan De Meyer drew my attention:
commit c4f4c0fc551cbcdccbbbc2d874d7d6440c7b4983
Author: Daan De Meyer <[email protected]>
Date: Wed Jul 15 21:39:57 2026 +0200
loop: remove manually added partitions on detach
Commit 267ec4d7223a ("loop: fix partition scan race between udev and
loop_reread_partitions()") stopped disk_force_media_change() from
setting GD_NEED_PART_SCAN because loop devices with LO_FLAGS_PARTSCAN
rescan partitions explicitly. However, partitions can also be added
manually with BLKPG while LO_FLAGS_PARTSCAN is clear.
When such a loop device is detached, __loop_clr_fd() skips
bdev_disk_changed(). Without GD_NEED_PART_SCAN, reopening the unbound
device no longer performs the previous lazy cleanup, leaving dead
partition devices behind. A subsequent LOOP_CONFIGURE can then fail its
partition scan with -EBUSY, as seen in blktests loop/009 after loop/008.
Call bdev_disk_changed() unconditionally during __loop_clr_fd(). The
disk capacity is already zero and the release path holds open_mutex, so
this drops all partitions without rescanning the detached backing file.
The new blktests loop/013 case covers this sequence by adding a
partition
with BLKPG without LO_FLAGS_PARTSCAN, detaching the loop device, and
checking that the partition is gone when the device is reopened.
Fixes: 267ec4d7223a ("loop: fix partition scan race between udev and
loop_reread_partitions()")
Reported-by: kernel test robot <[email protected]>
Closes:
https://lore.kernel.org/oe-lkp/[email protected]
Signed-off-by: Daan De Meyer <[email protected]>
Link:
https://patch.msgid.link/20260715-b4-loop-partition-cleanup-v1-1-b9f59910c...@amutable.com
Signed-off-by: Jens Axboe <[email protected]>
Cherry-picking it locally on top of v6.12.100 (as packaged by Debian),
and deploying it on the previously-mentioned Debian 13 systems, then
performing a few builds seems to confirm this is indeed fixing the exact
issue I've been facing.
Seeing how this commit wasn't cc'd to stable@ in the first place, I've
taken the liberty of adding both signed-off-by-ers to recipients for
information.
Full bug report on the Debian side available at:
https://bugs.debian.org/1141434
Cheers,
--
Cyril Brulebois ([email protected]) <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant
signature.asc
Description: PGP signature
