debian 11 VMs
Some update I downloaded recently broke me (I wasn’t getting update notifications for a while so I don’t know when it actually was).
If I mount a file as a loop device in some VM, using losetup, it normally shows up in the devices widget as a new device, which can be “attached” to some other running VM.
This is still true, provided I mount it read-write. Readonly mounts do not have this happen any more, and they used to.
Steps to reproduce: do
sudo losetup loop1 <filename> in some VM. It becomes an “available” device in the device manager applet and also, a notification balloon announces that fact. Correct behavior.
sudo losetup -l in the VM will confirm it’s a loop.
sudo losetup -r loop2 <filename> in that same VM; the new loop doesn’t show up in the widget, no balloon pops up.
sudo losetup -l will confirm it got mounted; note the difference in the RO flag column of the listing. Incorrect behavior…OK maybe it was never supposed to work, but it’s a change in behavior from before.
Looks like some (probably kernel?) race in the second part of this test.
As a workaround, you could set up a read-write loop device inside the VM and then still attach it read-only using
qvm-block attach --ro DESTINATION SOURCE:loopN
Thank you! OK it looks like a bug of some sort.
As far as the workaround goes, I was thinking of doing something precisely like that (this is the first step of several I go through to implement split veracrypt), but hadn’t got around to trying it yet. (There are two places it does a losetup, in fact–both need to be altered for this to work.) For now I’ve just been using it in read-write mode always.
That works but of course it’s a bit hazardous.
I didn’t tell the whole story but this episode has been valuable to me in that it shows me my error-handling stinks. If for some reason (like this one) the block attach doesn’t work, of course split-veracrypt fails, but in its wake it leaves behind a decryptor disposable that, since it’s named is still running and must be shut down and explicitly deleted, as well as “recordkeeping” in the store that must be undone so the store knows the vault is still available. Pain in the butt, and I need to work on all of that this weekend. As things sit right now, it’s actually going to be handy that this is broken right now.
I learned one more thing about this.
Apparently the first time I mount a particular file, call it A, read-only works. Subsequent mounts will not. This can be cleared by restarting the VM that does the mounting, or also (in my particular case) by dismounting and remounting the share where A resides. (Of course if A doesn’t reside on some share, this is moot.)
In any case I’ve long since implemented a workaround–and I don’t have to do it that way in both places, since the other place is a one-use disposable (it can’t mount the file twice, because it’s once-per-lifetime for the DVM).