How do I attach a hard drive to a VM on boot?

[bill...@gmail.com]

I have an HP laptop with 4.0.2.rc2 installed.  Everything works well, with the exception of a couple of small things I've asked about previously.   Now I'm trying to tune it a bit.  I have a 256G SSD where qubes is installed, and a 1TB traditional hard drive.  I want to attach the hard drive to my "work" VM on boot.  Currently, I boot up the machine, go to the "Qubes Devices" tab on the panel, choose the device, and attach it manually.  Then I open a terminal in the VM and mount it to a directory from the command line.  It works fine.

However...  it would be more convenient to have it mount automatically on that VM on boot up.  I know how to edit the /etc/fstab file to automatically mount a visible drive.  What I don't know how to do is to make the drive visible to the VM automatically on boot.  I've poked around the documentation but missed the instructions, if they are there.

Can anybody either tell me how to do this or point me to the documentatoin on it?

And, by the way, the more I'm using this OS, the more I like it.  I have to think a little differently about managing workflow, but the idea of being able to surf the web on one VM and do work on another while compartmentalizing them transparently is really great.  Great job.  I appreciate the work the developers have done.

[bill...@gmail.com]

So, here's an update:

I've figured out how to attach the device automatically, using "qvm-device block attach --persistent untrusted dom0:sda3" in the dom0 command line.   However, I can't seem to get it to mount on bringing up the VM.  My "untrusted" VM is debian based.  My /etc/fstab entry contains:

/dev/xvdi    /mnt/tmp    auto noauto,user,rw 0 0

and I can mount it manually in the untrusted VM command line with "sudo mount /mnt/tmp"

Thus, the "mount" command is looking at /etc/fstab, but it is ignored when the VM comes up.   Any ideas on what I need to do to move forward?

Thanks!

[bill...@gmail.com]

Doh.  I just noticed the "noauto" option.  Sigh. Deleted it and it works fine.

[David Hobach]

On 12/12/19 8:46 PM, bill...@gmail.com wrote:
>
> Doh. I just noticed the "noauto" option. Sigh. Deleted it and it works
> fine.

The only remaining problem here might be that /dev/sda3 doesn't
reference the same drive on each dom0 boot process...

So you'd have to write a udev rule for that. Alternatively your could
write a little dom0 script to do the attachment by disk ID
(/dev/disk/by-uuid) rather than via --persistent.

But I might also be wrong and Qubes OS solved that referencing issue
internally.

[bill...@gmail.com]

No, it's been consistent for a few weeks now, so I'm not going to worry about it.  I did find another way to screw up, though.  I attached the drive persistently to my "untrusted" VM, and then put the mount in /etc/fstab in the debian-10 template, so it would persist also.  That worked fine for the untrusted VM, but none of the other debian-based VMs would start, since they couldn't mount /dev/sda3.  Sigh.  So, now I have to figure out how to add that to the fstab just for "untrusted."  I saw some instructions, involving adding an echo command to an rc script, but haven't tried it yet.

[David Hobach]

Yes, simply use your mount in /rw/config/rc.local, cf. [1].

[1] https://www.qubes-os.org/doc/config-files/

[244clar...@gmail.com]

The only remaining problem here might be that /dev/sda3 doesn't
reference the same drive on each dom0 boot process...

So you'd have to write ... Alternatively  you could  ...

Another option is to label the filesystem, say with

tune2fs -L foo /dev/sda3

Then, instead of the /dev/xxx entry in fstab, use LABEL=foo like this

LABEL=foo   /mnt/tmp    auto user,rw 0 0

That way it will find the relevant partition, even if it moves around in the partition table on the real disk, or if it appears on a different virtual disk.(not yet tested on Qubes, but this is my normal way of making fstab entries persist)

You can also do the same using UUIDs, but I prefer to use meaningful identifiers. I am old-school in that respect.

R~~

[River~~]

On 16:36, Sun, 22 Dec 2019 <244clar...@gmail.com wrote:
>
>
>> The only remaining problem here might be that /dev/sda3 doesn't
>> reference the same drive on each dom0 boot process...
>>
>> So you'd have to write ... Alternatively  you could  ...
>
>
> Another option is to label the filesystem, say with
>
> tune2fs -L foo /dev/sda3
>
> Then, instead of the /dev/xxx entry in fstab, use LABEL=foo like this
>
>
> LABEL=foo   /mnt/tmp    auto user,rw 0 0
>
> That way it will find the relevant partition, even if it moves around in the partition table on the real disk, or if it appears on a different virtual disk.(not yet tested on Qubes, but this is my normal way of making fstab entries persist)

That success the problem of the disk moving around in the VM. It doesn't solve the issue that it might be on a different unit in Dom0.

To get ground that, you might like to label the filesystem as before, and refer to it in Dom0 as

/dev/disk/by-label/foo

Happy new year !