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
