Can `losetup` automatically expose the partitions of a loop device within a container?

Incus
1

Create a test container and a disk file with two partitions,

incus init images:ubuntu/noble c1
incus config device add c1 loop-control unix-char path=/dev/loop-control
incus config device add c1 loop0 unix-block path=/dev/loop0

incus config set c1 \
    security.syscalls.intercept.mount=true \
    security.syscalls.intercept.mount.allowed=ext4

incus start c1
incus exec c1 -- bash

dd if=/dev/zero of=disk.img bs=1M count=2048

apt-get install fdisk

# Create two partitions.
sfdisk disk.img <<EOF
1M,64M,c
65M,1024M,83
EOF

losetup -Pf disk.img

In the c1 container,

root@c1:~# ll /dev/loop0*
brw-rw---- 1 root root 7, 0 Apr 10 10:22 /dev/loop0

In the host,

itviewer@JackMa:~/maker/armbian$ ll /dev/loop0*
brw-rw---- 1 root disk   7,  0 Apr 10 18:30 /dev/loop0
brw-rw---- 1 root disk 259, 15 Apr 10 18:30 /dev/loop0p1
brw-rw---- 1 root disk 259, 16 Apr 10 18:30 /dev/loop0p2

loop0p1 and loop0p2 cannot be automatically exposed to the c1 container

Can't use partitions of attached incus unix-block device
2

That’s unfortunately not possible. We started doing some kernel work to support per-container loops and partition probing but that didn’t really go anywhere.

What you can do as a workaround which we’re actively doing for our own image builds with distrobuilder is tell mount to look for a partition at a specific offset. By doing that, you can mount from just loop0 without needing the loop0pX block devices.