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,
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
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
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
** Changed in: linux (Ubuntu Bionic)
Status: In Progress => Fix Committed
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1856871
Title:
i/o error if next unused loop device is
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 Kernel
Packages, which is subscribed to linux in Ubuntu.
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 Kernel
Packages, which is subscribed to linux in Ubuntu.
** 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)
** 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 Kernel
Packages, which is subscribed to linux in Ubuntu.
** 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 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
** Changed in: linux (Ubuntu)
Assignee: Eric Desrochers (slashd) => (unassigned)
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1856871
Title:
i/o error if next unused loop device
** 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
**
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 Kernel
Packages, which is subscribed to linux in
** Changed in: udev (Ubuntu)
Status: New => Invalid
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1856871
Title:
i/o error if next unused loop device is queried
Status in linux
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 Kernel
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
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
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
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 Kernel
Packages, which is subscribed to linux in Ubuntu.
https://bugs.launchpad.net/bugs/1856871
Title:
i/o error if next unused loop device
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
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 Kernel
Packages, which is
@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.
27 matches
Mail list logo
