This bug is awaiting verification that the linux-azure/5.4.0-1110.116
kernel in -proposed solves the problem. Please test the kernel and
update this bug with the results. If the problem is solved, change the
tag 'verification-needed-focal' to 'verification-done-focal'. If the
problem still exists,
This bug is awaiting verification that the linux-aws/5.4.0-1104.112
kernel in -proposed solves the problem. Please test the kernel and
update this bug with the results. If the problem is solved, change the
tag 'verification-needed-focal' to 'verification-done-focal'. If the
problem still exists, ch
I restored the verification-done-focal tag because I already verified
this bug on focal (see comment #24). I think the linux-bluefield kernel
patch is not appropriate for this bug.
** Tags removed: verification-needed-focal
** Tags added: verification-done-focal
--
You received this bug notifica
This bug is awaiting verification that the linux-bluefield/5.4.0-1064.70
kernel in -proposed solves the problem. Please test the kernel and
update this bug with the results. If the problem is solved, change the
tag 'verification-needed-focal' to 'verification-done-focal'. If the
problem still exist
This bug was fixed in the package linux - 5.4.0-149.166
---
linux (5.4.0-149.166) focal; urgency=medium
* focal/linux: 5.4.0-149.166 -proposed tracker (LP: #2016591)
* Focal update: v5.4.233 upstream stable release (LP: #2015909)
- dma-mapping: add generic helpers for mapping
** Changed in: linux (Ubuntu Bionic)
Status: In Progress => Fix Committed
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1856871
Title:
i/o error if next unused loo
Tested with kernel 5.4.0-149.166 in focal. Test plan works Ok.
** Tags removed: verification-needed-focal
** Tags added: verification-done-focal
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.
This bug is awaiting verification that the linux/5.4.0-149.166 kernel in
-proposed solves the problem. Please test the kernel and update this bug
with the results. If the problem is solved, change the tag
'verification-needed-focal' to 'verification-done-focal'. If the problem
still exists, change
** Changed in: linux (Ubuntu Focal)
Status: In Progress => Fix Committed
** Changed in: linux (Ubuntu Bionic)
Importance: Undecided => Medium
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https:
** Also affects: parted (Ubuntu Bionic)
Importance: Undecided
Status: New
** Also affects: udev (Ubuntu Bionic)
Importance: Undecided
Status: New
** Also affects: linux (Ubuntu Bionic)
Importance: Undecided
Status: New
** Also affects: systemd (Ubuntu Bionic)
Imp
** Changed in: linux (Ubuntu Focal)
Importance: Undecided => Medium
** Changed in: linux (Ubuntu Jammy)
Importance: Undecided => Medium
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.lau
** Description changed:
- This is reproducible in Bionic and late.
- Here's an example running 'focal':
+ [Impact]
- $ lsb_release -cs
- focal
+ * There's an I/O error on fsync() in a detached loop device if it has
+ been previously attached. The issue is that write cache is enabled in
+ the
The fix/commit is applied in v5.12, thus available on Jammy
(v5.15-based).
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=4ceddce55eb35d15b0f87f5dcf6f0058fd15d3a4
~/git/linux$ git describe --contains 4ceddce55eb35d15b0f87f5dcf6f0058fd15d3a4
v5.12-rc1-dontuse~7^2~13
** Changed in: linux (Ubuntu)
Assignee: Eric Desrochers (slashd) => (unassigned)
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1856871
Title:
i/o error if next unuse
** Changed in: linux (Ubuntu)
Status: Incomplete => In Progress
** Changed in: linux (Ubuntu)
Importance: Undecided => Medium
** Changed in: linux (Ubuntu)
Assignee: (unassigned) => Mauricio Faria de Oliveira (mfo)
** Changed in: parted (Ubuntu)
Status: New => Invalid
** C
The upstream proposal fix that mfo and I worked on has been applied:
https://patchwork.kernel.org/project/linux-
block/patch/20210222154123.61797-1-...@canonical.com/
- Eric
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to s
** Changed in: udev (Ubuntu)
Status: New => Invalid
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1856871
Title:
i/o error if next unused loop device is queried
S
marking invalid for systemd, as i think we all agree it's not an issue
caused by systemd, but please feel free to re-mark it for systemd if i'm
incorrect
** Changed in: systemd (Ubuntu)
Status: New => Invalid
--
You received this bug notification because you are a member of Ubuntu
Touch s
I reproduced the behaviour using 5.5 upstream kernel by:
1) Mounting a loop device
2) Setup frace for all loop function for capture purposes
3) Then umount the loop device
trace_pipe reveal the following:
"umount-1850 [000] 471.727511: loop_release_xfer <-__loop_clr_fd"
As cascardo mentione
I reproduced the behaviour using 5.5 upstream kernel by:
1) Mounting a loop device
2) Setup frace for all loop function for capture purposes
3) Then umount the loop device
trace_pipe reveal the following:
"umount-1850 [000] 471.727511: loop_release_xfer <-__loop_clr_fd"
As cascardo menti
so 2 things come to my mind right now
Does the kernel (loop driver) do the right thing by not clear/reset the
loop device' stats after the umount/detached operation ?
and/or
Does parted need to be smarter and not only based is detection on stat()
to assume if its a legit device or not to be
so 2 things come to my mind right now
Does the kernel (loop driver) do the right thing by not clear/reset the
loop device' stats after the umount/detached operation ?
and/or
Does parted need to smarter and not only based is detection only on
stat() ?
Let's circle back on Jan 2020.
** Also
Ok so in fact the inconsistency is due to "parted" that will try to
probe devices iff the given block device return informations from
stat(), regardless if the block device is available or not.
Seems like the only trigger/criteria is the stat() return. Since the
loop device stat doesn't clear/rese
Agreed with your comment #11
will start a discussion with the linux-block maintainer.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages, which is subscribed to systemd in Ubuntu.
https://bugs.launchpad.net/bugs/1856871
Title:
i/o error if next unus
It then might be a problem with "/dev/loop-control" device node. Which
dynamically find or allocate a free device, but also add and remove loop
devices from the running system.
# drivers/block/loop.c
2090 static void loop_remove(struct loop_device *lo)
2091 {
2092 del_gendisk(lo-
Exactly my point about consistency. They should either return EIO in
both cases or succeed in both cases. Which behavior will depend on: 1)
which is the easier solution; 2) what upstream thinks is okay.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages
@thadeu,
To respond your question "What is the exact problem this is causing?"
So far it's not causing much problem, it's pretty harmless, but while
running sosreport block plugin (which most Canonical customer uses) it
may lead to output "blk" error to the stderr and save syslog ||
kern.log.
As
so the problem is inside the block layer ?
More likely the loop driver not undoing something it does when a file is
attached to it. But could as well be something related to the multiqueue
support, so could still be something in the block layer. Still needs
investigation.
Anyway, as this is not
I did some quick testing and it seems this happens on whatever loop
device that had a file attached and then detached. No matter if it's the
next available or not. So, if you create a new loop device without ever
attaching a file to it, it seems the block layer is not setup
sufficiently so any requ
FWIW snapd mounts and unmounts a squashfs on startup to determine
whether the system can mount squashfs's. It does this using mount, and
cleans up with umount -l. That is, it's not via systemd in this instance
in particular.
I'm setting it as invalid for snapd, but if this behaviour is somehow
tic
# parted code (3.3-1) from focal
-
libparted/arch/linux.c:
.
=> if (fsync (fd) < 0 || close (fd) < 0)
if (ped_exception_throw (
PED_EXCEPTION_WARNING,
losetup -l
NAME SIZELIMIT OFFSET AUTOCLEAR RO BACK-FILE
DIO LOG-SEC
/dev/loop1 0 0 1 1 /var/lib/snapd/snaps/core_7270.snap
0 512
/dev/loop2 0 0 1 1 /var/lib/snapd/snaps/core_8268.snap
0 512
/dev/loop0
Talking with mvo (snap team) on the subject trying to eliminate some
components:
[09:48:27] so snapd does not do anything "special" with block devices
beside using them
[09:48:39] it uses the standard system mount units to do that
[09:49:01] so if you see strange things with extra block device
Interesting fact,
If I modified "snapd.service" to prevent snapd to run and reboot. I
don't get the problem with the first unused loop device which is
/dev/loop0 since nothing is using a loop device.
--
You received this bug notification because you are a member of Ubuntu
Touch seeded packages,
** Description changed:
This is reproducible in Bionic and late.
Here's an example running 'focal':
$ lsb_release -cs
focal
$ uname -r
5.3.0-24-generic
The error is:
blk_update_request: I/O error, dev loop2, sector 0
+
+ and on more recent kernel:
+
+ kernel: [18135.1
I also filed a sosreport upstream issue, because I believe sosreport
shouldn't try to query "unused" block device such as loop device.
https://github.com/sosreport/sos/issues/1897
but situation remain that there is something going wrong with loop
device and systemd/systemd-udevd at boot as explai
Booting with "systemd.log_level=debug" revealed:
Dec 18 17:26:22 ubuntu systemd-udevd[1326]: value '[dmi/id]sys_vendor' is 'QEMU'
Dec 18 17:26:22 ubuntu systemd-udevd[1326]: created db file
'/run/udev/data/b7:2' for '/devices/virtual/block/loop2'
Dec 18 17:26:22 ubuntu systemd[1]: dev-loop2.devic
** Description changed:
This is reproducible in Bionic and late.
Here's an example running 'focal':
$ lsb_release -cs
focal
$ uname -r
5.3.0-24-generic
+ The error is:
+ blk_update_request: I/O error, dev loop2, sector 0
+
How to trigger it:
-
$ sosreport -o block
38 matches
Mail list logo
