Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > linux.debian.kernel > #93214 > unrolled thread
| Started by | Cyril Brulebois <kibi@debian.org> |
|---|---|
| First post | 2026-07-04 19:30 +0200 |
| Last post | 2026-07-06 15:00 +0200 |
| Articles | 9 — 3 participants |
Back to article view | Back to linux.debian.kernel
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
| From | Cyril Brulebois <kibi@debian.org> |
|---|---|
| Date | 2026-07-04 19:30 +0200 |
| Subject | Bug#1141434: linux-image-6.12.94+deb13-amd64: regression in loop devices |
| Message-ID | <NdclI-2Knw-7@gated-at.bofh.it> |
Package: src:linux
Version: 6.12.94-1
Severity: important
X-Debbugs-Cc: kibi@debian.org
Hi,
I've spotted a regression regarding loop devices, starting with
v6.12.94. Going back to v6.12.90 makes the issue disappear.
I'm experiencing this issue in Debian 13 VMs that are used to build
Debian 13 system images (for amd64 and for arm64), and I'm able to
reproduce this bug by building two system images for amd64 on the same
host: the first build is fine but leaves the system in a corrupted
state, which breaks the second build (one safeguard detects the
label-based device matching finds more than 1 device, and bails).
I have yet to come up with a minimal reproducer, but I was able to find
ways to assess the “corrupted state” after the first build, without
starting the second build:
root@iot-isobuilder-52:~# fallocate -l 1G foo.img
root@iot-isobuilder-52:~# kpartx -asv foo.img
root@iot-isobuilder-52:~# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
loop0 7:0 0 1G 0 loop
├─loop0p1 259:0 0 487M 0 part
└─loop0p2 259:1 0 2.3G 0 part
sda 8:0 0 20G 0 disk
├─sda1 8:1 0 18.9G 0 part /
├─sda2 8:2 0 1K 0 part
└─sda5 8:5 0 1.1G 0 part [SWAP]
root@iot-isobuilder-52:~# losetup
NAME SIZELIMIT OFFSET AUTOCLEAR RO BACK-FILE DIO LOG-SEC
/dev/loop0 0 0 0 0 /root/foo.img 0 512
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.
Without toying with foo.img, on another system, after a single build,
while lsblk and losetup report nothing related to loop0, it's quite
clear that it's not been cleaned up properly:
root@iot-isobuilder-54:~# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
sda 8:0 0 20G 0 disk
├─sda1 8:1 0 18.9G 0 part /
├─sda2 8:2 0 1K 0 part
└─sda5 8:5 0 1.1G 0 part [SWAP]
root@iot-isobuilder-54:~# losetup
root@iot-isobuilder-54:~# find /sys/ -name loop0'*'|sort
/sys/block/loop0
/sys/class/block/loop0
/sys/class/block/loop0p1
/sys/class/block/loop0p2
/sys/devices/virtual/block/loop0
/sys/devices/virtual/block/loop0/loop0p1
/sys/devices/virtual/block/loop0/loop0p2
/sys/kernel/debug/block/loop0
(Going back to the older kernel confirms that loop0pX are absent there.)
Regarding the system image build, /dev/shm/system.img is allocated, then
fdisk, kpartx, mkfs.vfat, mkfs.ext4, debootstrap, apt, and finally
virt-sparsify are involved, but I haven't been able to reproduce the
problem without the debootstrap and apt steps. I'll follow up once I
have a small reproducer than my customer's image builds.
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
backported from:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=267ec4d7223a783f029a980f41b93c39b17996da
From a quick look at loop.c in v6.12.94, the code mentioned in the
commit message looks like it's in place, so if the regression is
confirmed to come from this commit (which I'm not certain of yet), it
shouldn't be caused by assumptions valid in the master branch but not in
the stable branch.
Next steps for me (in no particular order):
- find a minimal reproducer;
- check what happens with a recent mainline kernel (e.g.
7.0.12-2~bpo13+1);
- check what happens with v6.12.94 once that commit is reverted.
Cheers,
--
Cyril Brulebois (kibi@debian.org) <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant
-- Package-specific info:
** Version:
Linux version 6.12.94+deb13-amd64 (debian-kernel@lists.debian.org) (x86_64-linux-gnu-gcc-14 (Debian 14.2.0-19) 14.2.0, GNU ld (GNU Binutils for Debian) 2.44) #1 SMP PREEMPT_DYNAMIC Debian 6.12.94-1 (2026-06-20)
** Command line:
BOOT_IMAGE=/boot/vmlinuz-6.12.94+deb13-amd64 root=UUID=64b4eb7b-a367-494a-9d40-e4380cd92c48 ro quiet
** Not tainted
** Kernel log:
[ 3.281696] systemd[1]: Starting systemd-udev-trigger.service - Coldplug All udev Devices...
[ 3.284472] systemd[1]: Mounted dev-hugepages.mount - Huge Pages File System.
[ 3.284636] systemd[1]: Mounted dev-mqueue.mount - POSIX Message Queue File System.
[ 3.284763] systemd[1]: Mounted run-lock.mount - Legacy Locks Directory /run/lock.
[ 3.284884] systemd[1]: Mounted sys-kernel-debug.mount - Kernel Debug File System.
[ 3.285002] systemd[1]: Mounted sys-kernel-tracing.mount - Kernel Trace File System.
[ 3.285377] systemd[1]: Finished blk-availability.service - Availability of block devices.
[ 3.285880] systemd[1]: Finished kmod-static-nodes.service - Create List of Static Device Nodes.
[ 3.286229] systemd[1]: modprobe@drm.service: Deactivated successfully.
[ 3.286460] systemd[1]: Finished modprobe@drm.service - Load Kernel Module drm.
[ 3.286902] systemd[1]: modprobe@fuse.service: Deactivated successfully.
[ 3.287139] systemd[1]: Finished modprobe@fuse.service - Load Kernel Module fuse.
[ 3.288865] systemd[1]: Mounting sys-fs-fuse-connections.mount - FUSE Control File System...
[ 3.290147] systemd[1]: Starting systemd-tmpfiles-setup-dev-early.service - Create Static Device Nodes in /dev gracefully...
[ 3.291283] systemd[1]: modprobe@efi_pstore.service: Deactivated successfully.
[ 3.291516] systemd[1]: Finished modprobe@efi_pstore.service - Load Kernel Module efi_pstore.
[ 3.291983] systemd[1]: modprobe@configfs.service: Deactivated successfully.
[ 3.292204] systemd[1]: Finished modprobe@configfs.service - Load Kernel Module configfs.
[ 3.293539] systemd[1]: Mounting sys-kernel-config.mount - Kernel Configuration File System...
[ 3.295665] systemd[1]: Finished systemd-modules-load.service - Load Kernel Modules.
[ 3.297105] systemd[1]: Starting systemd-sysctl.service - Apply Kernel Variables...
[ 3.298611] systemd[1]: Finished systemd-udev-load-credentials.service - Load udev Rules from Credentials.
[ 3.300421] systemd[1]: Mounted sys-fs-fuse-connections.mount - FUSE Control File System.
[ 3.302920] systemd[1]: Mounted sys-kernel-config.mount - Kernel Configuration File System.
[ 3.304083] systemd-journald[455]: Collecting audit messages is disabled.
[ 3.314457] systemd[1]: Finished systemd-sysctl.service - Apply Kernel Variables.
[ 3.319119] systemd[1]: Finished systemd-tmpfiles-setup-dev-early.service - Create Static Device Nodes in /dev gracefully.
[ 3.332712] EXT4-fs (sda1): re-mounted 64b4eb7b-a367-494a-9d40-e4380cd92c48 r/w.
[ 3.334056] systemd[1]: Finished systemd-remount-fs.service - Remount Root and Kernel File Systems.
[ 3.334641] systemd[1]: systemd-hwdb-update.service - Rebuild Hardware Database skipped, unmet condition check ConditionNeedsUpdate=/etc
[ 3.334702] systemd[1]: systemd-pstore.service - Platform Persistent Storage Archival skipped, unmet condition check ConditionDirectoryNotEmpty=/sys/fs/pstore
[ 3.336135] systemd[1]: Starting systemd-random-seed.service - Load/Save OS Random Seed...
[ 3.336196] systemd[1]: systemd-sysusers.service - Create System Users skipped, no trigger condition checks were met.
[ 3.338192] systemd[1]: Starting systemd-timesyncd.service - Network Time Synchronization...
[ 3.339408] systemd[1]: Starting systemd-tmpfiles-setup-dev.service - Create Static Device Nodes in /dev...
[ 3.339432] systemd[1]: systemd-tpm2-setup.service - TPM SRK Setup skipped, unmet condition check ConditionSecurity=measured-uki
[ 3.364819] systemd[1]: Finished systemd-tmpfiles-setup-dev.service - Create Static Device Nodes in /dev.
[ 3.366762] systemd[1]: Starting systemd-udevd.service - Rule-based Manager for Device Events and Files...
[ 3.366918] systemd[1]: Started systemd-journald.service - Journal Service.
[ 3.397301] systemd-journald[455]: Received client request to flush runtime journal.
[ 3.500672] sd 0:0:0:0: Attached scsi generic sg0 type 0
[ 3.520507] input: Power Button as /devices/LNXSYSTM:00/LNXPWRBN:00/input/input5
[ 3.540370] ACPI: button: Power Button [PWRF]
[ 3.549670] cryptd: max_cpu_qlen set to 1000
[ 3.549705] input: PC Speaker as /devices/platform/pcspkr/input/input6
[ 3.555264] Free page reporting enabled
[ 3.593151] Adding 1127420k swap on /dev/sda5. Priority:-2 extents:1 across:1127420k SS
[ 3.795901] random: crng init done
[ 3.828421] device-mapper: core: CONFIG_IMA_DISABLE_HTABLE is disabled. Duplicate IMA measurements will not be recorded in the IMA log.
[ 3.828491] device-mapper: uevent: version 1.0.3
[ 3.828628] device-mapper: ioctl: 4.48.0-ioctl (2023-03-01) initialised: dm-devel@lists.linux.dev
[ 4.376789] audit: type=1400 audit(1783183034.164:2): apparmor="STATUS" operation="profile_load" profile="unconfined" name=4D6F6E676F444220436F6D70617373 pid=697 comm="apparmor_parser"
[ 4.376830] audit: type=1400 audit(1783183034.164:3): apparmor="STATUS" operation="profile_load" profile="unconfined" name="cam" pid=704 comm="apparmor_parser"
[ 4.376877] audit: type=1400 audit(1783183034.164:4): apparmor="STATUS" operation="profile_load" profile="unconfined" name="crun" pid=710 comm="apparmor_parser"
[ 4.376917] audit: type=1400 audit(1783183034.164:5): apparmor="STATUS" operation="profile_load" profile="unconfined" name="balena-etcher" pid=700 comm="apparmor_parser"
[ 4.376973] audit: type=1400 audit(1783183034.164:6): apparmor="STATUS" operation="profile_load" profile="unconfined" name="QtWebEngineProcess" pid=698 comm="apparmor_parser"
[ 4.377169] audit: type=1400 audit(1783183034.164:7): apparmor="STATUS" operation="profile_load" profile="unconfined" name="1password" pid=695 comm="apparmor_parser"
[ 4.377175] audit: type=1400 audit(1783183034.164:8): apparmor="STATUS" operation="profile_load" profile="unconfined" name="chrome" pid=707 comm="apparmor_parser"
[ 4.377178] audit: type=1400 audit(1783183034.164:9): apparmor="STATUS" operation="profile_load" profile="unconfined" name="vscode" pid=709 comm="apparmor_parser"
[ 4.377181] audit: type=1400 audit(1783183034.164:10): apparmor="STATUS" operation="profile_load" profile="unconfined" name="Discord" pid=696 comm="apparmor_parser"
[ 4.535465] RPC: Registered named UNIX socket transport module.
[ 4.535470] RPC: Registered udp transport module.
[ 4.535471] RPC: Registered tcp transport module.
[ 4.535472] RPC: Registered tcp-with-tls transport module.
[ 4.535473] RPC: Registered tcp NFSv4.1 backchannel transport module.
[ 4.543276] 8021q: 802.1Q VLAN Support v1.8
[ 4.730653] cfg80211: Loading compiled-in X.509 certificates for regulatory database
[ 4.739764] Loaded X.509 cert 'benh@debian.org: 577e021cb980e0e820821ba7b54b4961b8b4fadf'
[ 4.739969] Loaded X.509 cert 'romain.perier@gmail.com: 3abbc6ec146e09d1b6016ab9d6cf71dd233f0328'
[ 4.740141] Loaded X.509 cert 'sforshee: 00b28ddf47aef9cea7'
[ 4.740311] Loaded X.509 cert 'wens: 61c038651aabdcf94bd0ac7ff06c7248db18c600'
[ 4.753611] 8021q: adding VLAN 0 to HW filter on device ens18
[ 5.377977] netfs: FS-Cache loaded
[ 12.513152] Key type dns_resolver registered
[ 12.761105] NFS: Registering the id_resolver key type
[ 12.761120] Key type id_resolver registered
[ 12.761121] Key type id_legacy registered
[ 42.102685] loop: module loaded
[ 42.103336] loop0: detected capacity change from 0 to 5872026
[ 42.172988] operation not supported error, dev loop0, sector 5871488 op 0x9:(WRITE_ZEROES) flags 0x10000800 phys_seg 0 prio class 2
[ 42.224310] EXT4-fs (dm-1): mounted filesystem eb013725-54ef-4605-9345-8551bad92c28 r/w with ordered data mode. Quota mode: none.
[ 246.853461] EXT4-fs (dm-1): unmounting filesystem eb013725-54ef-4605-9345-8551bad92c28.
[ 248.731833] kauditd_printk_skb: 98 callbacks suppressed
[ 248.731844] audit: type=1400 audit(1783183278.231:109): apparmor="DENIED" operation="capable" class="cap" profile="guestfs-tools" pid=29773 comm="dmesg" capability=34 capname="syslog"
[ 381.616936] I/O error, dev loop0, sector 2048 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 2
[ 381.617010] I/O error, dev loop0, sector 2048 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 2
[ 381.617031] Buffer I/O error on dev loop0p1, logical block 0, async page read
[ 381.618278] I/O error, dev loop0, sector 999424 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 2
[ 381.618320] I/O error, dev loop0, sector 999424 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 2
[ 381.618339] Buffer I/O error on dev loop0p2, logical block 0, async page read
[ 478.789998] I/O error, dev loop0, sector 2048 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 2
[ 478.790062] I/O error, dev loop0, sector 2048 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 2
[ 478.790085] Buffer I/O error on dev loop0p1, logical block 0, async page read
[ 478.790984] I/O error, dev loop0, sector 999424 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 2
[ 478.791032] I/O error, dev loop0, sector 999424 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 2
[ 478.791060] Buffer I/O error on dev loop0p2, logical block 0, async page read
[ 675.927697] loop0: detected capacity change from 0 to 2097152
[ 675.969092] I/O error, dev loop0, sector 5871488 op 0x0:(READ) flags 0x80700 phys_seg 1 prio class 2
[ 675.970095] I/O error, dev loop0, sector 5871488 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 2
[ 675.970121] Buffer I/O error on dev loop0p2, logical block 609008, async page read
** Model information
sys_vendor: QEMU
product_name: Standard PC (i440FX + PIIX, 1996)
product_version: pc-i440fx-11.0
chassis_vendor: QEMU
chassis_version: pc-i440fx-11.0
bios_vendor: SeaBIOS
bios_version: rel-1.17.0-0-gb52ca86e094d-prebuilt.qemu.org
** Configuration for modprobe:
blacklist arkfb
blacklist aty128fb
blacklist atyfb
blacklist radeonfb
blacklist cirrusfb
blacklist cyber2000fb
blacklist kyrofb
blacklist matroxfb_base
blacklist mb862xxfb
blacklist neofb
blacklist pm2fb
blacklist pm3fb
blacklist s3fb
blacklist savagefb
blacklist sisfb
blacklist tdfxfb
blacklist tridentfb
blacklist vt8623fb
blacklist microcode
options snd_pcsp index=-2
options cx88_alsa index=-2
options snd_atiixp_modem index=-2
options snd_intel8x0m index=-2
options snd_via82xx_modem index=-2
options md_mod start_ro=1
options bonding max_bonds=0
options dummy numdummies=0
options ifb numifbs=0
** Loaded modules:
nls_ascii
nls_cp437
vfat
fat
loop
rpcsec_gss_krb5
auth_rpcgss
nfsv4
dns_resolver
nfs
lockd
grace
netfs
cfg80211
rfkill
8021q
garp
stp
mrp
sunrpc
llc
binfmt_misc
dm_mod
sha512_ssse3
sha256_ssse3
sha1_ssse3
aesni_intel
gf128mul
crypto_simd
virtio_balloon
pcspkr
cryptd
button
joydev
sg
evdev
configfs
efi_pstore
nfnetlink
vsock_loopback
vmw_vsock_virtio_transport_common
vmw_vsock_vmci_transport
vsock
vmw_vmci
qemu_fw_cfg
ip_tables
x_tables
autofs4
ext4
crc16
mbcache
jbd2
btrfs
blake2b_generic
raid10
raid456
async_raid6_recov
async_memcpy
async_pq
async_xor
async_tx
xor
hid_generic
usbhid
hid
raid6_pq
libcrc32c
crc32c_generic
raid1
raid0
md_mod
bochs
drm_vram_helper
drm_ttm_helper
ttm
uhci_hcd
ata_generic
drm_kms_helper
ehci_pci
ata_piix
sd_mod
ehci_hcd
libata
drm
usbcore
virtio_scsi
psmouse
virtio_net
scsi_mod
net_failover
serio_raw
i2c_piix4
failover
crc32c_intel
usb_common
i2c_smbus
scsi_common
floppy
** PCI devices:
00:00.0 Host bridge [0600]: Intel Corporation 440FX - 82441FX PMC [Natoma] [8086:1237] (rev 02)
Subsystem: Red Hat, Inc. Qemu virtual machine [1af4:1100]
Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
00:01.0 ISA bridge [0601]: Intel Corporation 82371SB PIIX3 ISA [Natoma/Triton II] [8086:7000]
Subsystem: Red Hat, Inc. Qemu virtual machine [1af4:1100]
Physical Slot: 1
Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
00:01.1 IDE interface [0101]: Intel Corporation 82371SB PIIX3 IDE [Natoma/Triton II] [8086:7010] (prog-if 80 [ISA Compatibility mode-only controller, supports bus mastering])
Subsystem: Red Hat, Inc. Qemu virtual machine [1af4:1100]
Physical Slot: 1
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Region 0: I/O ports at 01f0 [size=8]
Region 1: I/O ports at 03f4
Region 2: I/O ports at 0170 [size=8]
Region 3: I/O ports at 0374
Region 4: I/O ports at f0a0 [size=16]
Kernel driver in use: ata_piix
Kernel modules: ata_piix, ata_generic
00:01.2 USB controller [0c03]: Intel Corporation 82371SB PIIX3 USB [Natoma/Triton II] [8086:7020] (rev 01) (prog-if 00 [UHCI])
Subsystem: Red Hat, Inc. QEMU Virtual Machine [1af4:1100]
Physical Slot: 1
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin D routed to IRQ 11
Region 4: I/O ports at f080 [size=32]
Kernel driver in use: uhci_hcd
Kernel modules: uhci_hcd
00:01.3 Bridge [0680]: Intel Corporation 82371AB/EB/MB PIIX4 ACPI [8086:7113] (rev 03)
Subsystem: Red Hat, Inc. Qemu virtual machine [1af4:1100]
Physical Slot: 1
Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B+ ParErr- DEVSEL=medium >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Interrupt: pin A routed to IRQ 9
Kernel driver in use: piix4_smbus
Kernel modules: i2c_piix4
00:02.0 VGA compatible controller [0300]: Device [1234:1111] (rev 02) (prog-if 00 [VGA controller])
Subsystem: Red Hat, Inc. Device [1af4:1100]
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx-
Status: Cap- 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Region 0: Memory at fd000000 (32-bit, prefetchable) [size=16M]
Region 2: Memory at fea50000 (32-bit, non-prefetchable) [size=4K]
Expansion ROM at 000c0000 [disabled] [size=128K]
Kernel driver in use: bochs-drm
Kernel modules: bochs
00:03.0 Unclassified device [00ff]: Red Hat, Inc. Virtio memory balloon [1af4:1002]
Subsystem: Red Hat, Inc. Device [1af4:0005]
Physical Slot: 3
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 10
Region 0: I/O ports at f000 [size=64]
Region 1: Memory at fea51000 (32-bit, non-prefetchable) [size=4K]
Region 4: Memory at 280600000 (64-bit, prefetchable) [size=16K]
Capabilities: [98] MSI-X: Enable+ Count=2 Masked-
Vector table: BAR=1 offset=00000000
PBA: BAR=1 offset=00000800
Capabilities: [84] Vendor Specific Information: VirtIO: <unknown>
BAR=0 offset=00000000 size=00000000
Capabilities: [70] Vendor Specific Information: VirtIO: Notify
BAR=4 offset=00003000 size=00001000 multiplier=00000004
Capabilities: [60] Vendor Specific Information: VirtIO: DeviceCfg
BAR=4 offset=00002000 size=00001000
Capabilities: [50] Vendor Specific Information: VirtIO: ISR
BAR=4 offset=00001000 size=00001000
Capabilities: [40] Vendor Specific Information: VirtIO: CommonCfg
BAR=4 offset=00000000 size=00001000
Kernel driver in use: virtio-pci
00:05.0 PCI bridge [0604]: Red Hat, Inc. QEMU PCI-PCI bridge [1b36:0001] (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 11
Region 0: Memory at 240000000 (64-bit, non-prefetchable) [size=256]
Bus: primary=00, secondary=01, subordinate=01, sec-latency=0
I/O behind bridge: e000-efff [size=4K] [16-bit]
Memory behind bridge: fe800000-fe9fffff [size=2M] [32-bit]
Prefetchable memory behind bridge: 280400000-2805fffff [size=2M] [32-bit]
Secondary status: 66MHz+ FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR-
BridgeCtl: Parity- SERR+ NoISA- VGA- VGA16- MAbort- >Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: [4c] MSI: Enable- Count=1/1 Maskable+ 64bit+
Address: 0000000000000000 Data: 0000
Masking: 00000000 Pending: 00000000
Capabilities: [48] Slot ID: 0 slots, First+, chassis 03
Capabilities: [40] Hot-plug capable
00:12.0 Ethernet controller [0200]: Red Hat, Inc. Virtio network device [1af4:1000]
Subsystem: Red Hat, Inc. Device [1af4:0001]
Physical Slot: 18
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 10
Region 0: I/O ports at f040 [size=64]
Region 1: Memory at fea52000 (32-bit, non-prefetchable) [size=4K]
Region 4: Memory at 280604000 (64-bit, prefetchable) [size=16K]
Expansion ROM at fea00000 [disabled] [size=256K]
Capabilities: [98] MSI-X: Enable+ Count=4 Masked-
Vector table: BAR=1 offset=00000000
PBA: BAR=1 offset=00000800
Capabilities: [84] Vendor Specific Information: VirtIO: <unknown>
BAR=0 offset=00000000 size=00000000
Capabilities: [70] Vendor Specific Information: VirtIO: Notify
BAR=4 offset=00003000 size=00001000 multiplier=00000004
Capabilities: [60] Vendor Specific Information: VirtIO: DeviceCfg
BAR=4 offset=00002000 size=00001000
Capabilities: [50] Vendor Specific Information: VirtIO: ISR
BAR=4 offset=00001000 size=00001000
Capabilities: [40] Vendor Specific Information: VirtIO: CommonCfg
BAR=4 offset=00000000 size=00001000
Kernel driver in use: virtio-pci
00:1e.0 PCI bridge [0604]: Red Hat, Inc. QEMU PCI-PCI bridge [1b36:0001] (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Interrupt: pin A routed to IRQ 10
Region 0: Memory at 240001000 (64-bit, non-prefetchable) [size=256]
Bus: primary=00, secondary=02, subordinate=02, sec-latency=0
I/O behind bridge: d000-dfff [size=4K] [16-bit]
Memory behind bridge: fe600000-fe7fffff [size=2M] [32-bit]
Prefetchable memory behind bridge: 280200000-2803fffff [size=2M] [32-bit]
Secondary status: 66MHz+ FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR-
BridgeCtl: Parity- SERR+ NoISA- VGA- VGA16- MAbort- >Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: [4c] MSI: Enable- Count=1/1 Maskable+ 64bit+
Address: 0000000000000000 Data: 0000
Masking: 00000000 Pending: 00000000
Capabilities: [48] Slot ID: 0 slots, First+, chassis 01
Capabilities: [40] Hot-plug capable
00:1f.0 PCI bridge [0604]: Red Hat, Inc. QEMU PCI-PCI bridge [1b36:0001] (prog-if 00 [Normal decode])
Control: I/O+ Mem+ BusMaster- SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx-
Status: Cap+ 66MHz+ UDF- FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Interrupt: pin A routed to IRQ 11
Region 0: Memory at 240002000 (64-bit, non-prefetchable) [size=256]
Bus: primary=00, secondary=03, subordinate=03, sec-latency=0
I/O behind bridge: c000-cfff [size=4K] [16-bit]
Memory behind bridge: fe400000-fe5fffff [size=2M] [32-bit]
Prefetchable memory behind bridge: 280000000-2801fffff [size=2M] [32-bit]
Secondary status: 66MHz+ FastB2B+ ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- <SERR- <PERR-
BridgeCtl: Parity- SERR+ NoISA- VGA- VGA16- MAbort- >Reset- FastB2B-
PriDiscTmr- SecDiscTmr- DiscTmrStat- DiscTmrSERREn-
Capabilities: [4c] MSI: Enable- Count=1/1 Maskable+ 64bit+
Address: 0000000000000000 Data: 0000
Masking: 00000000 Pending: 00000000
Capabilities: [48] Slot ID: 0 slots, First+, chassis 02
Capabilities: [40] Hot-plug capable
01:01.0 SCSI storage controller [0100]: Red Hat, Inc. Virtio SCSI [1af4:1004] (prog-if 00 [Vendor specific])
Subsystem: Red Hat, Inc. Device [1af4:0008]
Physical Slot: 1-2
Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR+ FastB2B- DisINTx+
Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- <TAbort- <MAbort- >SERR- <PERR- INTx-
Latency: 0
Interrupt: pin A routed to IRQ 10
Region 0: I/O ports at e000 [size=64]
Region 1: Memory at fe800000 (32-bit, non-prefetchable) [size=4K]
Region 4: Memory at 280400000 (64-bit, prefetchable) [size=16K]
Capabilities: [98] MSI-X: Enable+ Count=19 Masked-
Vector table: BAR=1 offset=00000000
PBA: BAR=1 offset=00000800
Capabilities: [84] Vendor Specific Information: VirtIO: <unknown>
BAR=4 offset=00001000 size=00000001
Capabilities: [70] Vendor Specific Information: VirtIO: Notify
BAR=4 offset=00003000 size=00001000 multiplier=00000004
Capabilities: [60] Vendor Specific Information: VirtIO: DeviceCfg
BAR=4 offset=00002000 size=00001000
Capabilities: [50] Vendor Specific Information: VirtIO: ISR
BAR=4 offset=00001000 size=00001000
Capabilities: [40] Vendor Specific Information: VirtIO: CommonCfg
BAR=4 offset=00000000 size=00001000
Kernel driver in use: virtio-pci
** USB devices:
Bus 001 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub
Bus 001 Device 002: ID 0627:0001 Adomax Technology Co., Ltd QEMU Tablet
-- System Information:
Debian Release: 13.5
APT prefers stable-updates
APT policy: (500, 'stable-updates'), (500, 'stable-security'), (500, 'proposed-updates'), (500, 'stable')
Architecture: amd64 (x86_64)
Kernel: Linux 6.12.94+deb13-amd64 (SMP w/16 CPU threads; PREEMPT)
Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled
Versions of packages linux-image-6.12.94+deb13-amd64 depends on:
ii initramfs-tools [linux-initramfs-tool] 0.148.4
ii kmod 34.2-2
ii linux-base 4.12.1
Versions of packages linux-image-6.12.94+deb13-amd64 recommends:
ii apparmor 4.1.0-1
Versions of packages linux-image-6.12.94+deb13-amd64 suggests:
pn debian-kernel-handbook <none>
ii extlinux 3:6.04~git20190206.bf6db5b4+dfsg1-3.1
pn firmware-linux-free <none>
ii grub-pc 2.12-9+deb13u2
pn linux-doc-6.12 <none>
Versions of packages linux-image-6.12.94+deb13-amd64 is related to:
pn firmware-amd-graphics <none>
pn firmware-atheros <none>
pn firmware-bnx2 <none>
pn firmware-bnx2x <none>
pn firmware-brcm80211 <none>
pn firmware-cavium <none>
pn firmware-cirrus <none>
pn firmware-intel-graphics <none>
pn firmware-intel-misc <none>
pn firmware-intel-sound <none>
pn firmware-ipw2x00 <none>
pn firmware-ivtv <none>
pn firmware-iwlwifi <none>
pn firmware-libertas <none>
pn firmware-marvell-prestera <none>
pn firmware-mediatek <none>
pn firmware-misc-nonfree <none>
pn firmware-myricom <none>
pn firmware-netronome <none>
pn firmware-netxen <none>
pn firmware-nvidia-graphics <none>
pn firmware-qcom-soc <none>
pn firmware-qlogic <none>
pn firmware-realtek <none>
pn firmware-samsung <none>
pn firmware-siano <none>
pn firmware-ti-connectivity <none>
pn xen-hypervisor <none>
-- no debconf information
[toc] | [next] | [standalone]
| From | Cyril Brulebois <kibi@debian.org> |
|---|---|
| Date | 2026-07-04 21:30 +0200 |
| Message-ID | <NdedP-2Lpb-1@gated-at.bofh.it> |
| In reply to | #93214 |
[Multipart message — attachments visible in raw view] — view raw
TL;DR: Regression in 3cef9aa17bf7dac59095b6972454c049a5fe97c0 confirmed.
Cyril Brulebois <kibi@debian.org> (2026-07-04):
> 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
>
> backported from:
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=267ec4d7223a783f029a980f41b93c39b17996da
>
> From a quick look at loop.c in v6.12.94, the code mentioned in the
> commit message looks like it's in place, so if the regression is
> confirmed to come from this commit (which I'm not certain of yet), it
> shouldn't be caused by assumptions valid in the master branch but not in
> the stable branch.
>
> Next steps for me (in no particular order):
> - find a minimal reproducer;
> - check what happens with a recent mainline kernel (e.g.
> 7.0.12-2~bpo13+1);
> - check what happens with v6.12.94 once that commit is reverted.
Building a 6.12.94-2 version with just that patch reverted, deploying
the resulting linux-image-6.12.94+deb13.1-amd64-unsigned package, and
building a system image leaves the system in a consistent state again:
root@iot-isobuilder-54:~# find /sys/ -name loop0'*'|sort
/sys/block/loop0
/sys/class/block/loop0
/sys/devices/virtual/block/loop0
/sys/kernel/debug/block/loop0
(i.e. no more extraneous loop0pX.)
Toying with a fresh file doesn't bring back remnants from the image
build:
root@iot-isobuilder-54:~# fallocate -l 1G foo.img
root@iot-isobuilder-54:~# kpartx -asv foo.img
root@iot-isobuilder-54:~# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
loop0 7:0 0 1G 0 loop
sda 8:0 0 20G 0 disk
├─sda1 8:1 0 18.9G 0 part /
├─sda2 8:2 0 1K 0 part
└─sda5 8:5 0 1.1G 0 part [SWAP]
Cleaning this up, and partitioning also gives the expected brand new
partitions (2 × ~500M):
root@iot-isobuilder-54:~# kpartx -dsv foo.img
loop deleted : /dev/loop0
root@iot-isobuilder-54:~# fdisk /dev/foo.img
[…]
root@iot-isobuilder-54:~# kpartx -asv foo.img
add map loop0p1 (253:2): 0 1024000 linear 7:0 2048
add map loop0p2 (253:3): 0 1071104 linear 7:0 1026048
root@iot-isobuilder-54:~# lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINTS
loop0 7:0 0 1G 0 loop
├─loop0p1 253:0 0 500M 0 part
└─loop0p2 253:1 0 523M 0 part
sda 8:0 0 20G 0 disk
├─sda1 8:1 0 18.9G 0 part /
├─sda2 8:2 0 1K 0 part
└─sda5 8:5 0 1.1G 0 part [SWAP]
And finally, a second system image build succeeds again, as there are no
duplicates that trigger the safeguard's exit condition.
Cheers,
--
Cyril Brulebois (kibi@debian.org) <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant
[toc] | [prev] | [next] | [standalone]
| From | Cyril Brulebois <kibi@debian.org> |
|---|---|
| Date | 2026-07-04 23:10 +0200 |
| Message-ID | <NdfMB-2Mjb-1@gated-at.bofh.it> |
| In reply to | #93218 |
[Multipart message — attachments visible in raw view] — view raw
TL;DR: Regression in 9e19f817940113ecfe33b1f1440407c826586b5c
(stable/linux-7.0.y) confirmed as well.
Cyril Brulebois <kibi@debian.org> (2026-07-04):
> > Next steps for me (in no particular order):
> > - find a minimal reproducer;
> > - check what happens with a recent mainline kernel (e.g.
> > 7.0.12-2~bpo13+1);
> > - check what happens with v6.12.94 once that commit is reverted.
Adding trixie-backports to that system's configuration and installing
linux-image-7.0.12+deb13-amd64 from there lets me reproduce this issue
as well.
Then, building a 7.0.12-2~bpo13+2 version with a revert of commit
9e19f817940113ecfe33b1f1440407c826586b5c, and deploying the resulting
linux-{base,binary,image,modules} packages, lets me confirm the issue
disappears as well.
Cheers,
--
Cyril Brulebois (kibi@debian.org) <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant
[toc] | [prev] | [next] | [standalone]
| From | Bastian Blank <waldi@debian.org> |
|---|---|
| Date | 2026-07-04 22:00 +0200 |
| Message-ID | <NdeGR-2LBb-1@gated-at.bofh.it> |
| In reply to | #93214 |
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. > 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? Bastian -- Another Armenia, Belgium ... the weak innocents who always seem to be located on a natural invasion route. -- Kirk, "Errand of Mercy", stardate 3198.4
[toc] | [prev] | [next] | [standalone]
| From | Cyril Brulebois <kibi@debian.org> |
|---|---|
| Date | 2026-07-04 22:10 +0200 |
| Message-ID | <NdeQx-2LO3-5@gated-at.bofh.it> |
| In reply to | #93219 |
[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
[toc] | [prev] | [next] | [standalone]
| From | Bastian Blank <waldi@debian.org> |
|---|---|
| Date | 2026-07-06 09:00 +0200 |
| Message-ID | <NdLt8-33Ew-1@gated-at.bofh.it> |
| In reply to | #93220 |
Control: tag -1 moreinfo On Sat, Jul 04, 2026 at 10:08:13PM +0200, Cyril Brulebois wrote: > 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. Please try replacing kpartx with losetup. Bastian -- Pain is a thing of the mind. The mind can be controlled. -- Spock, "Operation -- Annihilate!" stardate 3287.2
[toc] | [prev] | [next] | [standalone]
| From | Cyril Brulebois <kibi@debian.org> |
|---|---|
| Date | 2026-07-31 19:40 +0200 |
| Message-ID | <NmZnb-87nF-1@gated-at.bofh.it> |
| In reply to | #93238 |
[Multipart message — attachments visible in raw view] — view raw
Hi Bastian,
Hi Daan De Meyer and Jens Axboe as well,
Bastian Blank <waldi@debian.org> (2026-07-06):
> On Sat, Jul 04, 2026 at 10:08:13PM +0200, Cyril Brulebois wrote:
> > 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.
>
> 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 <daan@amutable.com>
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 <oliver.sang@intel.com>
Closes: https://lore.kernel.org/oe-lkp/202607150754.b660f5b9-lkp@intel.com
Signed-off-by: Daan De Meyer <daan@amutable.com>
Link: https://patch.msgid.link/20260715-b4-loop-partition-cleanup-v1-1-b9f59910cd1e@amutable.com
Signed-off-by: Jens Axboe <axboe@kernel.dk>
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 (kibi@debian.org) <https://debamax.com/>
D-I release manager -- Release team member -- Freelance Consultant
[toc] | [prev] | [next] | [standalone]
| From | "Debian Bug Tracking System" <owner@bugs.debian.org> |
|---|---|
| Date | 2026-07-06 09:00 +0200 |
| Subject | Processed: Re: Bug#1141434: linux-image-6.12.94+deb13-amd64: regression in loop devices |
| Message-ID | <NdLt8-33Ew-3@gated-at.bofh.it> |
| In reply to | #93214 |
Processing control commands: > tag -1 moreinfo Bug #1141434 [src:linux] linux-image-6.12.94+deb13-amd64: regression in loop devices Added tag(s) moreinfo. -- 1141434: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1141434 Debian Bug Tracking System Contact owner@bugs.debian.org with problems
[toc] | [prev] | [next] | [standalone]
| From | Bastian Blank <waldi@debian.org> |
|---|---|
| Date | 2026-07-06 15:00 +0200 |
| Subject | Bug#1141434: [waldi@debian.org: Bug#1141434: linux-image-6.12.94+deb13-amd64: regression in loop devices] |
| Message-ID | <NdR5v-36Ci-3@gated-at.bofh.it> |
| In reply to | #93214 |
----- Forwarded message from Bastian Blank <waldi@debian.org> ----- Date: Mon, 6 Jul 2026 08:50:35 +0200 From: Bastian Blank <waldi@debian.org> To: 1141434@bugs.debian.org Subject: Bug#1141434: linux-image-6.12.94+deb13-amd64: regression in loop devices X-Spam-Status: No, score=-5.8 tagged_above=-9999 required=6.31 tests=[DKIM_INVALID=0.1, DKIM_SIGNED=0.1, MAILING_LIST_MULTI=-1, RCVD_IN_DNSWL_HI=-5, RCVD_IN_MSPIKE_H3=0.001, RCVD_IN_MSPIKE_WL=0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001] autolearn=disabled Reply-To: Bastian Blank <waldi@debian.org>, 1141434@bugs.debian.org Control: tag -1 moreinfo On Sat, Jul 04, 2026 at 10:08:13PM +0200, Cyril Brulebois wrote: > 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. Please try replacing kpartx with losetup. Bastian -- Pain is a thing of the mind. The mind can be controlled. -- Spock, "Operation -- Annihilate!" stardate 3287.2 ----- End forwarded message ----- -- The best diplomat I know is a fully activated phaser bank. -- Scotty
[toc] | [prev] | [standalone]
Back to top | Article view | linux.debian.kernel
csiph-web