Comment 35 for bug 1842751

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 mode. Opts: (null)
tyhicks@sec-disco-amd64:~$ uname -a
Linux sec-disco-amd64 5.0.0-27-generic #28-Ubuntu SMP Tue Aug 20 19:53:07 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux
tyhicks@sec-disco-amd64:~$ lsb_release -c
Codename: disco
tyhicks@sec-disco-amd64:~$ sudo umount /mnt
[sudo] password for tyhicks:
tyhicks@sec-disco-amd64:~$ lsblk
NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT
sr0 11:0 1 1024M 0 rom
vda 252:0 0 16G 0 disk
└─vda1 252:1 0 16G 0 part
  ├─vmtools--vg-root 253:0 0 15G 0 lvm /
  └─vmtools--vg-swap_1 253:1 0 980M 0 lvm [SWAP]
vdb 252:16 0 10G 0 disk
tyhicks@sec-disco-amd64:~$ sudo mkfs.xfs -f -i size=1024 /dev/vdb
meta-data=/dev/vdb isize=1024 agcount=4, agsize=655360 blks
         = sectsz=512 attr=2, projid32bit=1
         = crc=1 finobt=1, sparse=0, rmapbt=0, reflink=0
data = bsize=4096 blocks=2621440, imaxpct=25
         = sunit=0 swidth=0 blks
naming =version 2 bsize=4096 ascii-ci=0 ftype=1
log =internal log bsize=4096 blocks=2560, version=2
         = sectsz=512 sunit=0 blks, lazy-count=1
realtime =none extsz=4096 blocks=0, rtextents=0

I manually ran those commands after the VM came up. This doesn't really rule anything out but might indicate that the more complex juju/OpenStack environment is needed to reproduce.