| 2023-04-05 19:50:21 |
Marcus Furlong |
bug |
|
|
added bug |
| 2023-04-05 19:51:07 |
Marcus Furlong |
affects |
nvidia-graphics-drivers-525 (Ubuntu) |
ubuntu |
|
| 2023-04-05 19:51:56 |
Marcus Furlong |
affects |
ubuntu |
linux (Ubuntu) |
|
| 2023-04-05 19:52:11 |
Marcus Furlong |
affects |
linux (Ubuntu) |
linux |
|
| 2023-04-05 19:52:30 |
Marcus Furlong |
affects |
linux |
linux (Ubuntu) |
|
| 2023-04-05 19:54:43 |
Launchpad Janitor |
linux (Ubuntu): status |
New |
Confirmed |
|
| 2023-04-05 19:56:09 |
Salvatore LaMendola |
bug task added |
|
linux-hwe-5.15 (Ubuntu) |
|
| 2023-04-05 19:56:58 |
Salvatore LaMendola |
tags |
|
jammy |
|
| 2023-04-05 19:59:13 |
Salvatore LaMendola |
bug |
|
|
added subscriber Salvatore LaMendola |
| 2023-04-05 20:01:07 |
Salvatore LaMendola |
bug |
|
|
added subscriber David A. Desrosiers |
| 2023-04-05 20:04:06 |
Salvatore LaMendola |
tags |
jammy |
jammy kernel-bug |
|
| 2023-04-06 19:48:41 |
Mauricio Faria de Oliveira |
attachment added |
|
loop-ctl-add.c https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2015400/+attachment/5661724/+files/loop-ctl-add.c |
|
| 2023-04-06 20:22:42 |
Mauricio Faria de Oliveira |
linux (Ubuntu): status |
Confirmed |
In Progress |
|
| 2023-04-06 20:22:44 |
Mauricio Faria de Oliveira |
linux (Ubuntu): importance |
Undecided |
Medium |
|
| 2023-04-06 20:22:47 |
Mauricio Faria de Oliveira |
linux (Ubuntu): assignee |
|
Mauricio Faria de Oliveira (mfo) |
|
| 2023-04-06 20:22:57 |
Mauricio Faria de Oliveira |
linux-hwe-5.15 (Ubuntu): status |
New |
Invalid |
|
| 2023-04-06 20:24:30 |
Mauricio Faria de Oliveira |
bug |
|
|
added subscriber Mauricio Faria de Oliveira |
| 2023-07-25 18:12:16 |
Mauricio Faria de Oliveira |
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-isaacmanjarres@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. |
[ Impact ]
* Regression in the loop block driver in Jammy kernel
between 5.15.0-67 to 5.15.0-68 (in v5.15.86 stable),
due to a change in the default behavior (value) of
kernel parameter `max_loop` (from 0 to 8) in commit:
`loop: Fix the max_loop commandline argument treatment
when it is set to 0` (comment #6).
* Users of loop devices (major 7) with minor >= 8 now
fail to `open()` a loop device created with `mknod()`.
* This is a corner case, as most people use `losetup`
with usual /dev/loopNUMBER (or `--find`) which are
not affected as it uses a different code path.
(`losetup` for `/dev/loopNOT-A-NUMBER` is affected.)
[ Test Steps ]
* Run the test cases (losetup and test-loop.c in comment #6):
- max_loop not set (default)
- max_loop=0
- max_loop=8
* Verify the default behavior (max_loop not set) is restored.
* Verify the modified behavior (max_loop is set) is unchanged.
[ Regression Potential ]
* Regressions would be limited to the loop block driver,
more specifically its default behavior (but it's that now)
or specific usage of max_loop parameter (tested; looks OK).
[ Other Info ]
* The fix on Jammy is just a Revert, since it had not been
released with the offending patch.
* The fix on Lunar is the recently accepted 2 patches [1, 2]
as it was released with the offending patch, so let's keep
that patch's improvement/behavior for the max_loop=0 case,
and "fix"/restore the historical no-limit default behavior.
* The fix on Mantic is the recently accepted 2 patches too,
now in v6.5-rc3, which should be automatically incorporated
as Mantic apparently will release with the 6.5 kernel [3]
* Patch 1 [1] is not quite a fix, but adds CONFIG guards that
Patch 2 [2] depends on. (Alternatively, a Patch 2 backport
with that could be done, but Patch 1 seems trivial enough.)
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=23881aec85f3219e8462e87c708815ee2cd82358
[2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=bb5faa99f0ce40756ab7bbbce4f16c01ca5ebd5a
[3] https://discourse.ubuntu.com/t/introducing-kernel-6-5-for-the-23-10-mantic-minotaur-release
Original 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-isaacmanjarres@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. |
|
| 2023-07-25 18:12:24 |
Mauricio Faria de Oliveira |
nominated for series |
|
Ubuntu Jammy |
|
| 2023-07-25 18:12:24 |
Mauricio Faria de Oliveira |
bug task added |
|
linux (Ubuntu Jammy) |
|
| 2023-07-25 18:12:24 |
Mauricio Faria de Oliveira |
bug task added |
|
linux-hwe-5.15 (Ubuntu Jammy) |
|
| 2023-07-25 18:12:24 |
Mauricio Faria de Oliveira |
nominated for series |
|
Ubuntu Mantic |
|
| 2023-07-25 18:12:24 |
Mauricio Faria de Oliveira |
bug task added |
|
linux (Ubuntu Mantic) |
|
| 2023-07-25 18:12:24 |
Mauricio Faria de Oliveira |
bug task added |
|
linux-hwe-5.15 (Ubuntu Mantic) |
|
| 2023-07-25 18:12:24 |
Mauricio Faria de Oliveira |
nominated for series |
|
Ubuntu Lunar |
|
| 2023-07-25 18:12:24 |
Mauricio Faria de Oliveira |
bug task added |
|
linux (Ubuntu Lunar) |
|
| 2023-07-25 18:12:24 |
Mauricio Faria de Oliveira |
bug task added |
|
linux-hwe-5.15 (Ubuntu Lunar) |
|
| 2023-07-25 18:12:40 |
Mauricio Faria de Oliveira |
linux (Ubuntu Jammy): status |
New |
In Progress |
|
| 2023-07-25 18:12:42 |
Mauricio Faria de Oliveira |
linux (Ubuntu Jammy): importance |
Undecided |
Medium |
|
| 2023-07-25 18:12:44 |
Mauricio Faria de Oliveira |
linux (Ubuntu Jammy): assignee |
|
Mauricio Faria de Oliveira (mfo) |
|
| 2023-07-25 18:12:48 |
Mauricio Faria de Oliveira |
linux (Ubuntu Lunar): status |
New |
In Progress |
|
| 2023-07-25 18:12:51 |
Mauricio Faria de Oliveira |
linux (Ubuntu Lunar): importance |
Undecided |
Medium |
|
| 2023-07-25 18:12:54 |
Mauricio Faria de Oliveira |
linux (Ubuntu Lunar): assignee |
|
Mauricio Faria de Oliveira (mfo) |
|
| 2023-07-25 18:13:05 |
Mauricio Faria de Oliveira |
linux (Ubuntu Mantic): status |
In Progress |
Invalid |
|
| 2023-07-25 18:13:09 |
Mauricio Faria de Oliveira |
linux (Ubuntu Mantic): importance |
Medium |
Undecided |
|
| 2023-07-25 18:13:11 |
Mauricio Faria de Oliveira |
linux (Ubuntu Mantic): assignee |
Mauricio Faria de Oliveira (mfo) |
|
|
| 2023-07-25 18:13:42 |
Mauricio Faria de Oliveira |
linux-hwe-5.15 (Ubuntu Lunar): status |
New |
Invalid |
|
| 2023-07-25 18:14:04 |
Mauricio Faria de Oliveira |
linux-hwe-5.15 (Ubuntu Jammy): status |
New |
Invalid |
|
| 2023-07-25 18:14:27 |
Mauricio Faria de Oliveira |
nominated for series |
|
Ubuntu Focal |
|
| 2023-07-25 18:14:27 |
Mauricio Faria de Oliveira |
bug task added |
|
linux (Ubuntu Focal) |
|
| 2023-07-25 18:14:27 |
Mauricio Faria de Oliveira |
bug task added |
|
linux-hwe-5.15 (Ubuntu Focal) |
|
| 2023-07-25 18:14:34 |
Mauricio Faria de Oliveira |
linux (Ubuntu Focal): status |
New |
Invalid |
|
| 2023-07-25 18:14:47 |
Mauricio Faria de Oliveira |
linux-hwe-5.15 (Ubuntu Focal): importance |
Undecided |
Medium |
|
| 2023-07-25 18:14:47 |
Mauricio Faria de Oliveira |
linux-hwe-5.15 (Ubuntu Focal): status |
New |
In Progress |
|
| 2023-07-25 18:14:56 |
Mauricio Faria de Oliveira |
linux-hwe-5.15 (Ubuntu Focal): assignee |
|
Mauricio Faria de Oliveira (mfo) |
|
| 2023-07-25 18:15:40 |
Mauricio Faria de Oliveira |
description |
[ Impact ]
* Regression in the loop block driver in Jammy kernel
between 5.15.0-67 to 5.15.0-68 (in v5.15.86 stable),
due to a change in the default behavior (value) of
kernel parameter `max_loop` (from 0 to 8) in commit:
`loop: Fix the max_loop commandline argument treatment
when it is set to 0` (comment #6).
* Users of loop devices (major 7) with minor >= 8 now
fail to `open()` a loop device created with `mknod()`.
* This is a corner case, as most people use `losetup`
with usual /dev/loopNUMBER (or `--find`) which are
not affected as it uses a different code path.
(`losetup` for `/dev/loopNOT-A-NUMBER` is affected.)
[ Test Steps ]
* Run the test cases (losetup and test-loop.c in comment #6):
- max_loop not set (default)
- max_loop=0
- max_loop=8
* Verify the default behavior (max_loop not set) is restored.
* Verify the modified behavior (max_loop is set) is unchanged.
[ Regression Potential ]
* Regressions would be limited to the loop block driver,
more specifically its default behavior (but it's that now)
or specific usage of max_loop parameter (tested; looks OK).
[ Other Info ]
* The fix on Jammy is just a Revert, since it had not been
released with the offending patch.
* The fix on Lunar is the recently accepted 2 patches [1, 2]
as it was released with the offending patch, so let's keep
that patch's improvement/behavior for the max_loop=0 case,
and "fix"/restore the historical no-limit default behavior.
* The fix on Mantic is the recently accepted 2 patches too,
now in v6.5-rc3, which should be automatically incorporated
as Mantic apparently will release with the 6.5 kernel [3]
* Patch 1 [1] is not quite a fix, but adds CONFIG guards that
Patch 2 [2] depends on. (Alternatively, a Patch 2 backport
with that could be done, but Patch 1 seems trivial enough.)
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=23881aec85f3219e8462e87c708815ee2cd82358
[2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=bb5faa99f0ce40756ab7bbbce4f16c01ca5ebd5a
[3] https://discourse.ubuntu.com/t/introducing-kernel-6-5-for-the-23-10-mantic-minotaur-release
Original 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-isaacmanjarres@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. |
[ Impact ]
* Regression in the loop block driver in Jammy kernel
between 5.15.0-67 to 5.15.0-68 (in v5.15.86 stable),
due to a change in the default behavior (value) of
kernel parameter `max_loop` (from 0 to 8) in commit:
`loop: Fix the max_loop commandline argument treatment
when it is set to 0` (comment #6).
* Users of loop devices (major 7) with minor >= 8 now
fail to `open()` a loop device created with `mknod()`.
* This is a corner case, as most people use `losetup`
with usual /dev/loopNUMBER (or `--find`) which are
not affected as it uses a different code path.
(`losetup` for `/dev/loopNOT-A-NUMBER` is affected.)
* Workaround: kernel parameter `max_loop=0`.
[ Test Steps ]
* Run the test cases (losetup and test-loop.c in comment #6):
- max_loop not set (default)
- max_loop=0
- max_loop=8
* Verify the default behavior (max_loop not set) is restored.
* Verify the modified behavior (max_loop is set) is unchanged.
[ Regression Potential ]
* Regressions would be limited to the loop block driver,
more specifically its default behavior (but it's that now)
or specific usage of max_loop parameter (tested; looks OK).
[ Other Info ]
* The fix on Jammy is just a Revert, since it had not been
released with the offending patch.
* The fix on Lunar is the recently accepted 2 patches [1, 2]
as it was released with the offending patch, so let's keep
that patch's improvement/behavior for the max_loop=0 case,
and "fix"/restore the historical no-limit default behavior.
* The fix on Mantic is the recently accepted 2 patches too,
now in v6.5-rc3, which should be automatically incorporated
as Mantic apparently will release with the 6.5 kernel [3]
* Patch 1 [1] is not quite a fix, but adds CONFIG guards that
Patch 2 [2] depends on. (Alternatively, a Patch 2 backport
with that could be done, but Patch 1 seems trivial enough.)
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=23881aec85f3219e8462e87c708815ee2cd82358
[2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=bb5faa99f0ce40756ab7bbbce4f16c01ca5ebd5a
[3] https://discourse.ubuntu.com/t/introducing-kernel-6-5-for-the-23-10-mantic-minotaur-release
Original 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-isaacmanjarres@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. |
|
| 2023-08-01 22:21:34 |
Mauricio Faria de Oliveira |
description |
[ Impact ]
* Regression in the loop block driver in Jammy kernel
between 5.15.0-67 to 5.15.0-68 (in v5.15.86 stable),
due to a change in the default behavior (value) of
kernel parameter `max_loop` (from 0 to 8) in commit:
`loop: Fix the max_loop commandline argument treatment
when it is set to 0` (comment #6).
* Users of loop devices (major 7) with minor >= 8 now
fail to `open()` a loop device created with `mknod()`.
* This is a corner case, as most people use `losetup`
with usual /dev/loopNUMBER (or `--find`) which are
not affected as it uses a different code path.
(`losetup` for `/dev/loopNOT-A-NUMBER` is affected.)
* Workaround: kernel parameter `max_loop=0`.
[ Test Steps ]
* Run the test cases (losetup and test-loop.c in comment #6):
- max_loop not set (default)
- max_loop=0
- max_loop=8
* Verify the default behavior (max_loop not set) is restored.
* Verify the modified behavior (max_loop is set) is unchanged.
[ Regression Potential ]
* Regressions would be limited to the loop block driver,
more specifically its default behavior (but it's that now)
or specific usage of max_loop parameter (tested; looks OK).
[ Other Info ]
* The fix on Jammy is just a Revert, since it had not been
released with the offending patch.
* The fix on Lunar is the recently accepted 2 patches [1, 2]
as it was released with the offending patch, so let's keep
that patch's improvement/behavior for the max_loop=0 case,
and "fix"/restore the historical no-limit default behavior.
* The fix on Mantic is the recently accepted 2 patches too,
now in v6.5-rc3, which should be automatically incorporated
as Mantic apparently will release with the 6.5 kernel [3]
* Patch 1 [1] is not quite a fix, but adds CONFIG guards that
Patch 2 [2] depends on. (Alternatively, a Patch 2 backport
with that could be done, but Patch 1 seems trivial enough.)
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=23881aec85f3219e8462e87c708815ee2cd82358
[2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=bb5faa99f0ce40756ab7bbbce4f16c01ca5ebd5a
[3] https://discourse.ubuntu.com/t/introducing-kernel-6-5-for-the-23-10-mantic-minotaur-release
Original 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-isaacmanjarres@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. |
[ Impact ]
* Regression in the loop block driver in Jammy kernel
between 5.15.0-67 to 5.15.0-68 (in v5.15.86 stable),
due to a change in the default behavior (value) of
kernel parameter `max_loop` (from 0 to 8) in commit:
`loop: Fix the max_loop commandline argument treatment
when it is set to 0` (comment #6).
* Users of loop devices (major 7) with minor >= 8 now
fail to `open()` a loop device created with `mknod()`.
* This is a corner case, as most people use `losetup`
with usual /dev/loopNUMBER (or `--find`) which are
not affected as it uses a different code path.
(`losetup` for `/dev/loopNOT-A-NUMBER` is affected.)
* Workaround: kernel parameter `max_loop=0`.
[ Test Steps ]
* Run the test cases (losetup and test-loop.c in comment #6):
- max_loop not set (default)
- max_loop=0
- max_loop=8
* Verify the default behavior (max_loop not set) is restored.
* Verify the modified behavior (max_loop is set) is unchanged.
[ Regression Potential ]
* Regressions would be limited to the loop block driver,
more specifically its default behavior (but it's that now)
or specific usage of max_loop parameter (tested; looks OK).
[ Other Info ]
* Patch 1 [1] is not quite a fix, but adds CONFIG guards that
Patch 2 [2] depends on. (Alternatively, a Patch 2 backport
with that could be done, but Patch 1 seems trivial enough.)
* The fix on Jammy is only Patch 2, with a trivial backport
(that CONFIG option is not in Jammy/v5.15, only in v5.18).
* The fix on Lunar is both patches; clean cherry-picks.
* The fix on Mantic is both patches too,
now in v6.5-rc3, which should be automatically incorporated
as Mantic apparently will release with the 6.5 kernel [3]
[1] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=23881aec85f3219e8462e87c708815ee2cd82358
[2] https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=bb5faa99f0ce40756ab7bbbce4f16c01ca5ebd5a
[3] https://discourse.ubuntu.com/t/introducing-kernel-6-5-for-the-23-10-mantic-minotaur-release
Original 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-isaacmanjarres@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. |
|
| 2023-08-03 18:01:50 |
Stefan Bader |
linux (Ubuntu Lunar): status |
In Progress |
Fix Committed |
|
| 2023-08-03 18:02:21 |
Stefan Bader |
linux (Ubuntu Jammy): status |
In Progress |
Fix Committed |
|
| 2023-08-10 19:51:36 |
Ubuntu Kernel Bot |
tags |
jammy kernel-bug |
jammy kernel-bug kernel-spammed-lunar-linux-v2 verification-needed-lunar-linux |
|
| 2023-08-11 15:47:25 |
Mauricio Faria de Oliveira |
tags |
jammy kernel-bug kernel-spammed-lunar-linux-v2 verification-needed-lunar-linux |
jammy kernel-bug kernel-spammed-lunar-linux-v2 verification-done-lunar-linux |
|
| 2023-08-16 16:16:23 |
Ubuntu Kernel Bot |
tags |
jammy kernel-bug kernel-spammed-lunar-linux-v2 verification-done-lunar-linux |
jammy kernel-bug kernel-spammed-jammy-linux-v2 kernel-spammed-lunar-linux-v2 verification-done-lunar-linux verification-needed-jammy-linux |
|
| 2023-08-21 19:45:07 |
Mauricio Faria de Oliveira |
tags |
jammy kernel-bug kernel-spammed-jammy-linux-v2 kernel-spammed-lunar-linux-v2 verification-done-lunar-linux verification-needed-jammy-linux |
jammy kernel-bug kernel-spammed-jammy-linux-v2 kernel-spammed-lunar-linux-v2 verification-done-jammy-linux verification-done-lunar-linux |
|
| 2023-08-21 19:50:12 |
Mauricio Faria de Oliveira |
linux-hwe-5.15 (Ubuntu Focal): assignee |
Mauricio Faria de Oliveira (mfo) |
|
|
| 2023-08-21 19:50:42 |
Mauricio Faria de Oliveira |
bug task deleted |
linux-hwe-5.15 (Ubuntu) |
|
|
| 2023-08-21 19:50:54 |
Mauricio Faria de Oliveira |
bug task deleted |
linux-hwe-5.15 (Ubuntu Focal) |
|
|
| 2023-08-21 19:50:59 |
Mauricio Faria de Oliveira |
bug task deleted |
linux-hwe-5.15 (Ubuntu Jammy) |
|
|
| 2023-08-21 19:51:04 |
Mauricio Faria de Oliveira |
bug task deleted |
linux-hwe-5.15 (Ubuntu Lunar) |
|
|
| 2023-08-21 19:51:09 |
Mauricio Faria de Oliveira |
bug task deleted |
linux-hwe-5.15 (Ubuntu Mantic) |
|
|
| 2023-08-30 21:51:12 |
Ubuntu Kernel Bot |
tags |
jammy kernel-bug kernel-spammed-jammy-linux-v2 kernel-spammed-lunar-linux-v2 verification-done-jammy-linux verification-done-lunar-linux |
jammy kernel-bug kernel-spammed-jammy-linux-nvidia-6.2-v2 kernel-spammed-jammy-linux-v2 kernel-spammed-lunar-linux-v2 verification-done-jammy-linux verification-done-lunar-linux verification-needed-jammy-linux-nvidia-6.2 |
|
| 2023-09-05 19:50:50 |
Ubuntu Kernel Bot |
tags |
jammy kernel-bug kernel-spammed-jammy-linux-nvidia-6.2-v2 kernel-spammed-jammy-linux-v2 kernel-spammed-lunar-linux-v2 verification-done-jammy-linux verification-done-lunar-linux verification-needed-jammy-linux-nvidia-6.2 |
jammy kernel-bug kernel-spammed-jammy-linux-nvidia-6.2-v2 kernel-spammed-jammy-linux-nvidia-tegra-v2 kernel-spammed-jammy-linux-v2 kernel-spammed-lunar-linux-v2 verification-done-jammy-linux verification-done-lunar-linux verification-needed-jammy-linux-nvidia-6.2 verification-needed-jammy-linux-nvidia-tegra |
|
| 2023-09-06 14:20:56 |
Ubuntu Kernel Bot |
tags |
jammy kernel-bug kernel-spammed-jammy-linux-nvidia-6.2-v2 kernel-spammed-jammy-linux-nvidia-tegra-v2 kernel-spammed-jammy-linux-v2 kernel-spammed-lunar-linux-v2 verification-done-jammy-linux verification-done-lunar-linux verification-needed-jammy-linux-nvidia-6.2 verification-needed-jammy-linux-nvidia-tegra |
jammy kernel-bug kernel-spammed-jammy-linux-nvidia-6.2-v2 kernel-spammed-jammy-linux-nvidia-tegra-v2 kernel-spammed-jammy-linux-v2 kernel-spammed-lunar-linux-starfive-v2 kernel-spammed-lunar-linux-v2 verification-done-jammy-linux verification-done-lunar-linux verification-needed-jammy-linux-nvidia-6.2 verification-needed-jammy-linux-nvidia-tegra verification-needed-lunar-linux-starfive |
|
| 2023-09-07 18:11:22 |
Ubuntu Kernel Bot |
tags |
jammy kernel-bug kernel-spammed-jammy-linux-nvidia-6.2-v2 kernel-spammed-jammy-linux-nvidia-tegra-v2 kernel-spammed-jammy-linux-v2 kernel-spammed-lunar-linux-starfive-v2 kernel-spammed-lunar-linux-v2 verification-done-jammy-linux verification-done-lunar-linux verification-needed-jammy-linux-nvidia-6.2 verification-needed-jammy-linux-nvidia-tegra verification-needed-lunar-linux-starfive |
jammy kernel-bug kernel-spammed-jammy-linux-azure-v2 kernel-spammed-jammy-linux-nvidia-6.2-v2 kernel-spammed-jammy-linux-nvidia-tegra-v2 kernel-spammed-jammy-linux-v2 kernel-spammed-lunar-linux-starfive-v2 kernel-spammed-lunar-linux-v2 verification-done-jammy-linux verification-done-lunar-linux verification-needed-jammy-linux-azure verification-needed-jammy-linux-nvidia-6.2 verification-needed-jammy-linux-nvidia-tegra verification-needed-lunar-linux-starfive |
|
| 2023-09-08 23:46:20 |
Ubuntu Kernel Bot |
tags |
jammy kernel-bug kernel-spammed-jammy-linux-azure-v2 kernel-spammed-jammy-linux-nvidia-6.2-v2 kernel-spammed-jammy-linux-nvidia-tegra-v2 kernel-spammed-jammy-linux-v2 kernel-spammed-lunar-linux-starfive-v2 kernel-spammed-lunar-linux-v2 verification-done-jammy-linux verification-done-lunar-linux verification-needed-jammy-linux-azure verification-needed-jammy-linux-nvidia-6.2 verification-needed-jammy-linux-nvidia-tegra verification-needed-lunar-linux-starfive |
jammy kernel-bug kernel-spammed-jammy-linux-azure-v2 kernel-spammed-jammy-linux-intel-iotg-v2 kernel-spammed-jammy-linux-nvidia-6.2-v2 kernel-spammed-jammy-linux-nvidia-tegra-v2 kernel-spammed-jammy-linux-v2 kernel-spammed-lunar-linux-starfive-v2 kernel-spammed-lunar-linux-v2 verification-done-jammy-linux verification-done-lunar-linux verification-needed-jammy-linux-azure verification-needed-jammy-linux-intel-iotg verification-needed-jammy-linux-nvidia-6.2 verification-needed-jammy-linux-nvidia-tegra verification-needed-lunar-linux-starfive |
|
| 2023-09-09 11:17:18 |
Ubuntu Kernel Bot |
tags |
jammy kernel-bug kernel-spammed-jammy-linux-azure-v2 kernel-spammed-jammy-linux-intel-iotg-v2 kernel-spammed-jammy-linux-nvidia-6.2-v2 kernel-spammed-jammy-linux-nvidia-tegra-v2 kernel-spammed-jammy-linux-v2 kernel-spammed-lunar-linux-starfive-v2 kernel-spammed-lunar-linux-v2 verification-done-jammy-linux verification-done-lunar-linux verification-needed-jammy-linux-azure verification-needed-jammy-linux-intel-iotg verification-needed-jammy-linux-nvidia-6.2 verification-needed-jammy-linux-nvidia-tegra verification-needed-lunar-linux-starfive |
jammy kernel-bug kernel-spammed-jammy-linux-aws-6.2-v2 kernel-spammed-jammy-linux-azure-v2 kernel-spammed-jammy-linux-intel-iotg-v2 kernel-spammed-jammy-linux-nvidia-6.2-v2 kernel-spammed-jammy-linux-nvidia-tegra-v2 kernel-spammed-jammy-linux-v2 kernel-spammed-lunar-linux-starfive-v2 kernel-spammed-lunar-linux-v2 verification-done-jammy-linux verification-done-lunar-linux verification-needed-jammy-linux-aws-6.2 verification-needed-jammy-linux-azure verification-needed-jammy-linux-intel-iotg verification-needed-jammy-linux-nvidia-6.2 verification-needed-jammy-linux-nvidia-tegra verification-needed-lunar-linux-starfive |
|
| 2023-09-10 20:51:26 |
Ubuntu Kernel Bot |
tags |
jammy kernel-bug kernel-spammed-jammy-linux-aws-6.2-v2 kernel-spammed-jammy-linux-azure-v2 kernel-spammed-jammy-linux-intel-iotg-v2 kernel-spammed-jammy-linux-nvidia-6.2-v2 kernel-spammed-jammy-linux-nvidia-tegra-v2 kernel-spammed-jammy-linux-v2 kernel-spammed-lunar-linux-starfive-v2 kernel-spammed-lunar-linux-v2 verification-done-jammy-linux verification-done-lunar-linux verification-needed-jammy-linux-aws-6.2 verification-needed-jammy-linux-azure verification-needed-jammy-linux-intel-iotg verification-needed-jammy-linux-nvidia-6.2 verification-needed-jammy-linux-nvidia-tegra verification-needed-lunar-linux-starfive |
jammy kernel-bug kernel-spammed-focal-linux-riscv-5.15-v2 kernel-spammed-jammy-linux-aws-6.2-v2 kernel-spammed-jammy-linux-azure-v2 kernel-spammed-jammy-linux-intel-iotg-v2 kernel-spammed-jammy-linux-nvidia-6.2-v2 kernel-spammed-jammy-linux-nvidia-tegra-v2 kernel-spammed-jammy-linux-v2 kernel-spammed-lunar-linux-starfive-v2 kernel-spammed-lunar-linux-v2 verification-done-jammy-linux verification-done-lunar-linux verification-needed-focal-linux-riscv-5.15 verification-needed-jammy-linux-aws-6.2 verification-needed-jammy-linux-azure verification-needed-jammy-linux-intel-iotg verification-needed-jammy-linux-nvidia-6.2 verification-needed-jammy-linux-nvidia-tegra verification-needed-lunar-linux-starfive |
|
| 2023-09-11 10:24:05 |
Ubuntu Kernel Bot |
tags |
jammy kernel-bug kernel-spammed-focal-linux-riscv-5.15-v2 kernel-spammed-jammy-linux-aws-6.2-v2 kernel-spammed-jammy-linux-azure-v2 kernel-spammed-jammy-linux-intel-iotg-v2 kernel-spammed-jammy-linux-nvidia-6.2-v2 kernel-spammed-jammy-linux-nvidia-tegra-v2 kernel-spammed-jammy-linux-v2 kernel-spammed-lunar-linux-starfive-v2 kernel-spammed-lunar-linux-v2 verification-done-jammy-linux verification-done-lunar-linux verification-needed-focal-linux-riscv-5.15 verification-needed-jammy-linux-aws-6.2 verification-needed-jammy-linux-azure verification-needed-jammy-linux-intel-iotg verification-needed-jammy-linux-nvidia-6.2 verification-needed-jammy-linux-nvidia-tegra verification-needed-lunar-linux-starfive |
jammy kernel-bug kernel-spammed-focal-linux-riscv-5.15-v2 kernel-spammed-jammy-linux-aws-6.2-v2 kernel-spammed-jammy-linux-azure-v2 kernel-spammed-jammy-linux-intel-iotg-v2 kernel-spammed-jammy-linux-nvidia-6.2-v2 kernel-spammed-jammy-linux-nvidia-tegra-v2 kernel-spammed-jammy-linux-raspi-v2 kernel-spammed-jammy-linux-v2 kernel-spammed-lunar-linux-starfive-v2 kernel-spammed-lunar-linux-v2 verification-done-jammy-linux verification-done-lunar-linux verification-needed-focal-linux-riscv-5.15 verification-needed-jammy-linux-aws-6.2 verification-needed-jammy-linux-azure verification-needed-jammy-linux-intel-iotg verification-needed-jammy-linux-nvidia-6.2 verification-needed-jammy-linux-nvidia-tegra verification-needed-jammy-linux-raspi verification-needed-lunar-linux-starfive |
|
| 2023-09-12 05:52:07 |
Ubuntu Kernel Bot |
tags |
jammy kernel-bug kernel-spammed-focal-linux-riscv-5.15-v2 kernel-spammed-jammy-linux-aws-6.2-v2 kernel-spammed-jammy-linux-azure-v2 kernel-spammed-jammy-linux-intel-iotg-v2 kernel-spammed-jammy-linux-nvidia-6.2-v2 kernel-spammed-jammy-linux-nvidia-tegra-v2 kernel-spammed-jammy-linux-raspi-v2 kernel-spammed-jammy-linux-v2 kernel-spammed-lunar-linux-starfive-v2 kernel-spammed-lunar-linux-v2 verification-done-jammy-linux verification-done-lunar-linux verification-needed-focal-linux-riscv-5.15 verification-needed-jammy-linux-aws-6.2 verification-needed-jammy-linux-azure verification-needed-jammy-linux-intel-iotg verification-needed-jammy-linux-nvidia-6.2 verification-needed-jammy-linux-nvidia-tegra verification-needed-jammy-linux-raspi verification-needed-lunar-linux-starfive |
jammy kernel-bug kernel-spammed-focal-linux-riscv-5.15-v2 kernel-spammed-jammy-linux-aws-6.2-v2 kernel-spammed-jammy-linux-azure-v2 kernel-spammed-jammy-linux-intel-iotg-v2 kernel-spammed-jammy-linux-nvidia-6.2-v2 kernel-spammed-jammy-linux-nvidia-tegra-v2 kernel-spammed-jammy-linux-raspi-v2 kernel-spammed-jammy-linux-v2 kernel-spammed-lunar-linux-azure-v2 kernel-spammed-lunar-linux-starfive-v2 kernel-spammed-lunar-linux-v2 verification-done-jammy-linux verification-done-lunar-linux verification-needed-focal-linux-riscv-5.15 verification-needed-jammy-linux-aws-6.2 verification-needed-jammy-linux-azure verification-needed-jammy-linux-intel-iotg verification-needed-jammy-linux-nvidia-6.2 verification-needed-jammy-linux-nvidia-tegra verification-needed-jammy-linux-raspi verification-needed-lunar-linux-azure verification-needed-lunar-linux-starfive |
|
| 2023-09-15 17:51:36 |
Ubuntu Kernel Bot |
tags |
jammy kernel-bug kernel-spammed-focal-linux-riscv-5.15-v2 kernel-spammed-jammy-linux-aws-6.2-v2 kernel-spammed-jammy-linux-azure-v2 kernel-spammed-jammy-linux-intel-iotg-v2 kernel-spammed-jammy-linux-nvidia-6.2-v2 kernel-spammed-jammy-linux-nvidia-tegra-v2 kernel-spammed-jammy-linux-raspi-v2 kernel-spammed-jammy-linux-v2 kernel-spammed-lunar-linux-azure-v2 kernel-spammed-lunar-linux-starfive-v2 kernel-spammed-lunar-linux-v2 verification-done-jammy-linux verification-done-lunar-linux verification-needed-focal-linux-riscv-5.15 verification-needed-jammy-linux-aws-6.2 verification-needed-jammy-linux-azure verification-needed-jammy-linux-intel-iotg verification-needed-jammy-linux-nvidia-6.2 verification-needed-jammy-linux-nvidia-tegra verification-needed-jammy-linux-raspi verification-needed-lunar-linux-azure verification-needed-lunar-linux-starfive |
jammy kernel-bug kernel-spammed-focal-linux-riscv-5.15-v2 kernel-spammed-jammy-linux-aws-6.2-v2 kernel-spammed-jammy-linux-azure-v2 kernel-spammed-jammy-linux-intel-iotg-v2 kernel-spammed-jammy-linux-nvidia-6.2-v2 kernel-spammed-jammy-linux-nvidia-tegra-igx-v2 kernel-spammed-jammy-linux-nvidia-tegra-v2 kernel-spammed-jammy-linux-raspi-v2 kernel-spammed-jammy-linux-v2 kernel-spammed-lunar-linux-azure-v2 kernel-spammed-lunar-linux-starfive-v2 kernel-spammed-lunar-linux-v2 verification-done-jammy-linux verification-done-lunar-linux verification-needed-focal-linux-riscv-5.15 verification-needed-jammy-linux-aws-6.2 verification-needed-jammy-linux-azure verification-needed-jammy-linux-intel-iotg verification-needed-jammy-linux-nvidia-6.2 verification-needed-jammy-linux-nvidia-tegra verification-needed-jammy-linux-nvidia-tegra-igx verification-needed-jammy-linux-raspi verification-needed-lunar-linux-azure verification-needed-lunar-linux-starfive |
|
| 2023-09-15 23:15:03 |
Ubuntu Kernel Bot |
tags |
jammy kernel-bug kernel-spammed-focal-linux-riscv-5.15-v2 kernel-spammed-jammy-linux-aws-6.2-v2 kernel-spammed-jammy-linux-azure-v2 kernel-spammed-jammy-linux-intel-iotg-v2 kernel-spammed-jammy-linux-nvidia-6.2-v2 kernel-spammed-jammy-linux-nvidia-tegra-igx-v2 kernel-spammed-jammy-linux-nvidia-tegra-v2 kernel-spammed-jammy-linux-raspi-v2 kernel-spammed-jammy-linux-v2 kernel-spammed-lunar-linux-azure-v2 kernel-spammed-lunar-linux-starfive-v2 kernel-spammed-lunar-linux-v2 verification-done-jammy-linux verification-done-lunar-linux verification-needed-focal-linux-riscv-5.15 verification-needed-jammy-linux-aws-6.2 verification-needed-jammy-linux-azure verification-needed-jammy-linux-intel-iotg verification-needed-jammy-linux-nvidia-6.2 verification-needed-jammy-linux-nvidia-tegra verification-needed-jammy-linux-nvidia-tegra-igx verification-needed-jammy-linux-raspi verification-needed-lunar-linux-azure verification-needed-lunar-linux-starfive |
jammy kernel-bug kernel-spammed-focal-linux-nvidia-tegra-5.15-v2 kernel-spammed-focal-linux-riscv-5.15-v2 kernel-spammed-jammy-linux-aws-6.2-v2 kernel-spammed-jammy-linux-azure-v2 kernel-spammed-jammy-linux-intel-iotg-v2 kernel-spammed-jammy-linux-nvidia-6.2-v2 kernel-spammed-jammy-linux-nvidia-tegra-igx-v2 kernel-spammed-jammy-linux-nvidia-tegra-v2 kernel-spammed-jammy-linux-raspi-v2 kernel-spammed-jammy-linux-v2 kernel-spammed-lunar-linux-azure-v2 kernel-spammed-lunar-linux-starfive-v2 kernel-spammed-lunar-linux-v2 verification-done-jammy-linux verification-done-lunar-linux verification-needed-focal-linux-nvidia-tegra-5.15 verification-needed-focal-linux-riscv-5.15 verification-needed-jammy-linux-aws-6.2 verification-needed-jammy-linux-azure verification-needed-jammy-linux-intel-iotg verification-needed-jammy-linux-nvidia-6.2 verification-needed-jammy-linux-nvidia-tegra verification-needed-jammy-linux-nvidia-tegra-igx verification-needed-jammy-linux-raspi verification-needed-lunar-linux-azure verification-needed-lunar-linux-starfive |
|
| 2023-10-03 20:41:48 |
Ubuntu Kernel Bot |
tags |
jammy kernel-bug kernel-spammed-focal-linux-nvidia-tegra-5.15-v2 kernel-spammed-focal-linux-riscv-5.15-v2 kernel-spammed-jammy-linux-aws-6.2-v2 kernel-spammed-jammy-linux-azure-v2 kernel-spammed-jammy-linux-intel-iotg-v2 kernel-spammed-jammy-linux-nvidia-6.2-v2 kernel-spammed-jammy-linux-nvidia-tegra-igx-v2 kernel-spammed-jammy-linux-nvidia-tegra-v2 kernel-spammed-jammy-linux-raspi-v2 kernel-spammed-jammy-linux-v2 kernel-spammed-lunar-linux-azure-v2 kernel-spammed-lunar-linux-starfive-v2 kernel-spammed-lunar-linux-v2 verification-done-jammy-linux verification-done-lunar-linux verification-needed-focal-linux-nvidia-tegra-5.15 verification-needed-focal-linux-riscv-5.15 verification-needed-jammy-linux-aws-6.2 verification-needed-jammy-linux-azure verification-needed-jammy-linux-intel-iotg verification-needed-jammy-linux-nvidia-6.2 verification-needed-jammy-linux-nvidia-tegra verification-needed-jammy-linux-nvidia-tegra-igx verification-needed-jammy-linux-raspi verification-needed-lunar-linux-azure verification-needed-lunar-linux-starfive |
jammy kernel-bug kernel-spammed-focal-linux-nvidia-tegra-5.15-v2 kernel-spammed-focal-linux-riscv-5.15-v2 kernel-spammed-jammy-linux-aws-6.2-v2 kernel-spammed-jammy-linux-azure-v2 kernel-spammed-jammy-linux-intel-iotg-v2 kernel-spammed-jammy-linux-nvidia-6.2-v2 kernel-spammed-jammy-linux-nvidia-tegra-igx-v2 kernel-spammed-jammy-linux-nvidia-tegra-v2 kernel-spammed-jammy-linux-raspi-v2 kernel-spammed-jammy-linux-v2 kernel-spammed-jammy-linux-xilinx-zynqmp-v2 kernel-spammed-lunar-linux-azure-v2 kernel-spammed-lunar-linux-starfive-v2 kernel-spammed-lunar-linux-v2 verification-done-jammy-linux verification-done-lunar-linux verification-needed-focal-linux-nvidia-tegra-5.15 verification-needed-focal-linux-riscv-5.15 verification-needed-jammy-linux-aws-6.2 verification-needed-jammy-linux-azure verification-needed-jammy-linux-intel-iotg verification-needed-jammy-linux-nvidia-6.2 verification-needed-jammy-linux-nvidia-tegra verification-needed-jammy-linux-nvidia-tegra-igx verification-needed-jammy-linux-raspi verification-needed-jammy-linux-xilinx-zynqmp verification-needed-lunar-linux-azure verification-needed-lunar-linux-starfive |
|
| 2024-01-25 20:38:01 |
Brian Murray |
linux (Ubuntu Lunar): status |
Fix Committed |
Won't Fix |
|
| 2024-03-01 06:19:01 |
Ubuntu Kernel Bot |
tags |
jammy kernel-bug kernel-spammed-focal-linux-nvidia-tegra-5.15-v2 kernel-spammed-focal-linux-riscv-5.15-v2 kernel-spammed-jammy-linux-aws-6.2-v2 kernel-spammed-jammy-linux-azure-v2 kernel-spammed-jammy-linux-intel-iotg-v2 kernel-spammed-jammy-linux-nvidia-6.2-v2 kernel-spammed-jammy-linux-nvidia-tegra-igx-v2 kernel-spammed-jammy-linux-nvidia-tegra-v2 kernel-spammed-jammy-linux-raspi-v2 kernel-spammed-jammy-linux-v2 kernel-spammed-jammy-linux-xilinx-zynqmp-v2 kernel-spammed-lunar-linux-azure-v2 kernel-spammed-lunar-linux-starfive-v2 kernel-spammed-lunar-linux-v2 verification-done-jammy-linux verification-done-lunar-linux verification-needed-focal-linux-nvidia-tegra-5.15 verification-needed-focal-linux-riscv-5.15 verification-needed-jammy-linux-aws-6.2 verification-needed-jammy-linux-azure verification-needed-jammy-linux-intel-iotg verification-needed-jammy-linux-nvidia-6.2 verification-needed-jammy-linux-nvidia-tegra verification-needed-jammy-linux-nvidia-tegra-igx verification-needed-jammy-linux-raspi verification-needed-jammy-linux-xilinx-zynqmp verification-needed-lunar-linux-azure verification-needed-lunar-linux-starfive |
jammy kernel-bug kernel-spammed-focal-linux-nvidia-tegra-5.15-v2 kernel-spammed-focal-linux-riscv-5.15-v2 kernel-spammed-jammy-linux-aws-6.2-v2 kernel-spammed-jammy-linux-azure-v2 kernel-spammed-jammy-linux-intel-iotg-v2 kernel-spammed-jammy-linux-mtk-v2 kernel-spammed-jammy-linux-nvidia-6.2-v2 kernel-spammed-jammy-linux-nvidia-tegra-igx-v2 kernel-spammed-jammy-linux-nvidia-tegra-v2 kernel-spammed-jammy-linux-raspi-v2 kernel-spammed-jammy-linux-v2 kernel-spammed-jammy-linux-xilinx-zynqmp-v2 kernel-spammed-lunar-linux-azure-v2 kernel-spammed-lunar-linux-starfive-v2 kernel-spammed-lunar-linux-v2 verification-done-jammy-linux verification-done-lunar-linux verification-needed-focal-linux-nvidia-tegra-5.15 verification-needed-focal-linux-riscv-5.15 verification-needed-jammy-linux-aws-6.2 verification-needed-jammy-linux-azure verification-needed-jammy-linux-intel-iotg verification-needed-jammy-linux-mtk verification-needed-jammy-linux-nvidia-6.2 verification-needed-jammy-linux-nvidia-tegra verification-needed-jammy-linux-nvidia-tegra-igx verification-needed-jammy-linux-raspi verification-needed-jammy-linux-xilinx-zynqmp verification-needed-lunar-linux-azure verification-needed-lunar-linux-starfive |
|
