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. > > The foo.img file doesn't exist in the first place, it is not getting > > partitioned, and yet, we have both loop0p1 and loop0p2 coming up, with > > sizes that match the system image built previously. Another hint is that > > we have 259:0 and 259:1 as MAJ:MIN, instead of 253:0 and 253:1 when the > > system image was being worked on. > > So the devices switch between possibly device-mapper (dynamically > allocated) and blkext (fixed 259). > > > Looking at the changes between v6.12.90 and v6.12.94, the following one > > seems pretty plausible: > > > > https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=3cef9aa17bf7dac59095b6972454c049a5fe97c0 > > The problem: this is about loop, you use device-mapper via kpartx. > > Does this also happen with a current kernel? I've just confirmed the same happens with linux-image-7.0.12+deb13-amd64 found in trixie-backports, and I'm currently building a similar revert on top of it to see what happens. Cheers, -- Cyril Brulebois ([email protected]) <https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant
signature.asc
Description: PGP signature
