I'll send a fix to the list. Cheers,
Daan On Fri, Jul 31, 2026 at 7:32 PM Cyril Brulebois <[email protected]> wrote: > 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 >
