> Hello - Does the recent switch from New -> Triaged for charm-cinder
and charm-nova-compute mean that someone was able to determine that the
charms are to blame and perhaps not the kernel?
Sadly not; I'm just knocking them off new; the alternative is incomplete
which means they'll time out after
Hello - Does the recent switch from New -> Triaged for charm-cinder and
charm-nova-compute mean that someone was able to determine that the
charms are to blame and perhaps not the kernel?
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to
** Changed in: charm-cinder
Status: New => Triaged
** Changed in: charm-nova-compute
Status: New => Triaged
--
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/1842751
Title:
On 2019-09-06 00:15:03, Ryan Beisner wrote:
> We’ve just dug into this aspect of both Disco and Eoan. Unfortunately,
> I don’t know if this ever succeeded on these two releases.
I don't know if you're easily able to test old kernel versions but it
could be helpful to test the kernel that Disco
We’ve just dug into this aspect of both Disco and Eoan. Unfortunately,
I don’t know if this ever succeeded on these two releases.
--
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/1842751
Ryan, did this work on Eoan and Disco at some point in the past or is
this the first time that you've tested this workflow on those releases?
--
You received this bug notification because you are a member of Kernel
Packages, which is subscribed to linux in Ubuntu.
I was unable to reproduce this in a Disco VM that I manually configured
to mount an ext4 virtio-blk device at boot:
$ dmesg | grep vdb
[2.352490] virtio_blk virtio4: [vdb] 20971520 512-byte logical blocks (10.7
GB/10.0 GiB)
[6.898149] EXT4-fs (vdb): mounted filesystem with ordered data
It is useful to note that the attached logs indicate that /dev/vdb2 is a
virtio-blk device containing a mounted ext4 filesystem prior to it being
unmounted and (attempted to be) reformatted with xfs.
--
You received this bug notification because you are a member of Kernel
Packages, which is
And Bionic for grins:
** Description changed:
Disco and Eoan device is busy after unmounting an ephemeral disk, cannot
format the device until rebooting.
This is blocking all of OpenStack Charms which interact with block
devices (Nova Compute, Ceph, Swift, Cinder), on the Disco and
^ Disco apport above, Eoan to follow:
** Tags added: eoan
** Description changed:
Disco and Eoan device is busy after unmounting an ephemeral disk, cannot
format the device until rebooting.
This is blocking all of OpenStack Charms which interact with block
devices (Nova Compute,
Similar behaviour documented in this bug for ceph-mon and ceph-osd with
disco series. https://bugs.launchpad.net/charm-ceph-mon/+bug/1842498.
Might be a duplicate if the underlying cause is the same
--
You received this bug notification because you are a member of Kernel
Packages, which is
apport information
** Tags added: apport-collected disco ec2-images
** Description changed:
Disco and Eoan device is busy after unmounting an ephemeral disk, cannot
format the device until rebooting.
This is blocking all of OpenStack Charms which interact with block
devices (Nova
** Also affects: linux (Ubuntu)
Importance: Undecided
Status: New
--
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/1842751
Title:
[disco] [eoan] After unmount, cannot open
13 matches
Mail list logo
