Simpler workarounds: For non-existing /dev/loopN devices, `losetup /dev/loopN image` should work (i.e., don't do `mknod /dev/loopN`).
For /dev/non-loopN devices, it doesn't (different code path), so the utility attached should help for now. Details below. ... # lsb_release -cs jammy # uname -rv 5.15.0-69-generic #76-Ubuntu SMP Fri Mar 17 17:19:29 UTC 2023 # cat /sys/module/loop/parameters/max_loop 8 # ls -1 /dev/loop* /dev/loop-control /dev/loop0 /dev/loop1 /dev/loop2 /dev/loop3 /dev/loop4 /dev/loop5 /dev/loop6 /dev/loop7 # grep loop /proc/devices 7 loop # truncate -s 1g test Case 1) Existing /dev/loopN: LOOP_CTL_ADD is not called, open() fails (non-init mutex, apparently). # mknod /dev/loop8 b 7 8 # strace -e openat,ioctl losetup /dev/loop8 test 2>&1 | grep -i loop openat(AT_FDCWD, "/dev/loop8", O_RDWR|O_CLOEXEC) = -1 ENXIO (No such device or address) openat(AT_FDCWD, "/dev/loop8", O_RDWR|O_CLOEXEC) = -1 ENXIO (No such device or address) losetup: /dev/loop8: failed to set up loop device Case 2) Non-existing /dev/loopN: LOOP_CTL_ADD is called, open() works. # rm /dev/loop8 # strace -e openat,ioctl losetup /dev/loop8 test 2>&1 | grep -i loop openat(AT_FDCWD, "/dev/loop-control", O_RDWR|O_CLOEXEC) = 3 ioctl(3, LOOP_CTL_ADD, 8) = 8 openat(AT_FDCWD, "/dev/loop8", O_RDWR|O_CLOEXEC) = 4 ioctl(4, LOOP_CONFIGURE, {fd=3, block_size=0, info={lo_offset=0, lo_number=0, lo_flags=0, lo_file_name="/root/test", ...}}) = 0 Case 3) Non-existing /dev/non-loopN: LOOP_CTL_ADD is not called, open() fails. # strace -e openat,ioctl losetup /dev/mynameX test 2>&1 | grep -i loop losetup: /dev/mynameX: failed to set up loop device Case 4) Existing /dev/non-loopN with workaround tool (attached) # gcc -o loop-ctl-add loop-ctl-add.c # mknod /dev/mynameX b 7 42 # losetup /dev/mynameX test losetup: /dev/mynameX: failed to set up loop device: No such device or address # ./loop-ctl-add 42 Success on ioctl('/dev/loop-control', LOOP_CTL_ADD, 42) # losetup /dev/mynameX test # works! -- You received this bug notification because you are a member of Kernel Packages, which is subscribed to linux-hwe-5.15 in Ubuntu. https://bugs.launchpad.net/bugs/2015400 Title: losetup with mknod fails on jammy with kernel 5.15.0-69-generic Status in linux package in Ubuntu: Confirmed Status in linux-hwe-5.15 package in Ubuntu: New Bug description: losetup fails with devices created manually by mknod on kernel 5.15.0-69-generic # fallocate -l 1G test # mknod -m 660 /dev/loop8 b 7 8 # chown root:disk /dev/loop8 # losetup /dev/loop8 ./test losetup: ./test: failed to set up loop device: Device or resource busy Possibly as a result of this patch: https://lore.kernel.org/lkml/20221208200605.756287-1-isaacmanjar...@google.com/T/ which was introduced in 5.15.0-68: http://launchpadlibrarian.net/653145495/linux_5.15.0-67.74_5.15.0-68.75.diff.gz On a machine prior to this change (no issue with losetup): # cat /sys/module/loop/parameters/max_loop 0 # uname -r 5.15.0-58-generic On a machine after the change (has losetup issue as described above): # cat /sys/module/loop/parameters/max_loop 8 # uname -r 5.15.0-69-generic So it looks like the default changed and the max amount of loop devices that can be created with mknod (not loop-control) is 8. If we set max_loop=0 on the kernel command line, it works as before. Cannot unload and reload module on a running system to change the parameter because it is built into the kernel. Another workaround is to use `losetup --find` but that means you cannot create with named devices created with mknod. To manage notifications about this bug go to: https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2015400/+subscriptions -- Mailing list: https://launchpad.net/~kernel-packages Post to : kernel-packages@lists.launchpad.net Unsubscribe : https://launchpad.net/~kernel-packages More help : https://help.launchpad.net/ListHelp