Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.kernel > #93220
| 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.
[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
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