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


Groups > linux.debian.kernel > #93220

Bug#1141434: linux-image-6.12.94+deb13-amd64: regression in loop devices

From Cyril Brulebois <kibi@debian.org>
Newsgroups linux.debian.bugs.dist, linux.debian.kernel
Subject Bug#1141434: linux-image-6.12.94+deb13-amd64: regression in loop devices
Date 2026-07-04 22:10 +0200
Message-ID <NdeQx-2LO3-5@gated-at.bofh.it> (permalink)
References <NdclI-2Knw-7@gated-at.bofh.it> <NdclI-2Knw-7@gated-at.bofh.it> <NdeGR-2LBb-1@gated-at.bofh.it> <NdclI-2Knw-7@gated-at.bofh.it> <NdeGR-2LBb-1@gated-at.bofh.it>
Organization Debian

Cross-posted to 2 groups.

Show all headers | View raw


[Multipart message — attachments visible in raw view] - view raw

Bastian Blank <waldi@debian.org> (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 (kibi@debian.org)            <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant

Back to linux.debian.kernel | Previous | Next — Previous in thread | Next in thread | Find similar | Unroll thread


Thread

Bug#1141434: linux-image-6.12.94+deb13-amd64: regression in loop devices Cyril Brulebois <kibi@debian.org> - 2026-07-04 19:30 +0200
  Bug#1141434: linux-image-6.12.94+deb13-amd64: regression in loop devices Cyril Brulebois <kibi@debian.org> - 2026-07-04 21:30 +0200
    Bug#1141434: linux-image-6.12.94+deb13-amd64: regression in loop devices Cyril Brulebois <kibi@debian.org> - 2026-07-04 23:10 +0200
  Bug#1141434: linux-image-6.12.94+deb13-amd64: regression in loop devices Bastian Blank <waldi@debian.org> - 2026-07-04 22:00 +0200
    Bug#1141434: linux-image-6.12.94+deb13-amd64: regression in loop devices Cyril Brulebois <kibi@debian.org> - 2026-07-04 22:10 +0200
      Bug#1141434: linux-image-6.12.94+deb13-amd64: regression in loop devices Bastian Blank <waldi@debian.org> - 2026-07-06 09:00 +0200
        Bug#1141434: linux-image-6.12.94+deb13-amd64: regression in loop devices Cyril Brulebois <kibi@debian.org> - 2026-07-31 19:40 +0200
  Processed: Re: Bug#1141434: linux-image-6.12.94+deb13-amd64:  regression in loop devices "Debian Bug Tracking System" <owner@bugs.debian.org> - 2026-07-06 09:00 +0200
  Bug#1141434: [waldi@debian.org: Bug#1141434: linux-image-6.12.94+deb13-amd64: regression in loop devices] Bastian Blank <waldi@debian.org> - 2026-07-06 15:00 +0200

csiph-web