How to consistently mount a second storage device (hdd)

Hey everyone,

i am trying to get my second storage device permanently mounted to a specific AppVM.
The problem with persistently attaching a block device like this

qvm-block attach -p …

is that qubes asigns a new name to the device on every restart.
How can i remedy that?

Is their a better way to add a big storage pool that is flexible and can be shared with multiple AppVMs?

1 Like

More info needed.

Well as i said, i have got a second storage drive (hdd in this case) running.
I managed to encrypt it using luks and crypttab, so it gets automatically decrypted with my main drive.

Now i want to use it to store large files (pictures, videos, documents, …). The drive should be accessable by multiple AppVMs (2 or 3). So i usually attach it using

qvm-device attach dm0:dm-8

But I want to automate this a bit, so the storage device gets attach to the respective VMs when I start them. That’s why I tried the persistant-flag (-p). The problem I run into, is that the device gets renamed every time i restart the host machine.

Meaning the next time it might be “dm0:dm-16” or “dm0:dm-90” which means I get an error when i start the AppVM that had the drive mounted to with the old name. The message goes something like:

“can’t find storage device dm0:dm-8. Unable to start VM”

You know what I mean? I either have to keep my machine running all the time, which I dont want to do. Or I reattach the device every time I reboot.

Probably the main thing missing. Is it USB device, or internal second storage? What confuses me is that it has label dm. These are usually stubdomain labels, as I can recall? It should be something like dom0:sdxxx, and when USB as block device then sys-usb:sdxx, or as USB device sys-usb:2-1.1 or similar…

So, what is it exactly?

Might be related:

Also, we don’t know the full command you ran, and if this is typo when bringing it here, or you pasted it properly, so your command doesn’t looks proper.

More info needed.

If you find a solution let me know.
If you can find some kind of a static identifier for the device, you could use a startup script to auto attach it based on the identifier.

UUIDs are static. Maybe run with those?

Hi, I dont know jack so dont kill me if this is a stupid idea but could you use a variable for your

qvm-device attach dm0:dm-8

So that it calls on the random name given to the drive and attaches it that way? I assume not but this is a common way to sort out stuff like this I believe.
not sure how to say it but create a variable that is the random name generated for the drive and then use the variable to call that name into your attachment command?

What kind of hard drive even is this bro…? I’ve only ever seen dm-XX naming on temporary stuff eg. nbd ramdisks or volumes that get kicked out of a RAID array.

I would only recommend this as a temporary workaround, but you could turn your drive into a cacheless bcache device. Then you can expect it to persist at /dev/bcache0. Only catch is if you do this you have to reformat your drive because the bcache header has to go in front of the filesystem header, so may not be viable if you already have a lot of data.

sudo make-bcache -B /dev/dm-8
(AGAIN - this will wipe your data so make sure to backup)