On 05/19/2018 01:04 AM, Qubes Guy wrote:
On Friday, May 18, 2018 at 5:59:09 PM UTC-4, David Hobach wrote:On 05/18/2018 08:19 PM, Marek Marczykowski-Górecki wrote:-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256On Thu, May 17, 2018 at 05:57:09PM -0700, Qubes Guy wrote:I've successfully used qvm-block (in Dom0) to attach USB drives to different VMs (persistently), but I've noticed that Qubes (or Linux) sometimes gives them to different devices over time. In other words, on Monday, my BIG_TOSHIBA drive will be on /dev/sda, but it'll be assigned to /dev/sdj when I boot up on Wednesday. This is throwing off my VeraCrypt / FreeFileSync backup routine. (Another way of saying this is if I say "qvm-block attach MyVM sys-usb:sda --persistent" when one of the three drives I use for MyVM is currently attached to that, this will fail if Qubes moves that drive to a different device-name (during boot) that isn't one of the three I previously attached (when I go to start up that VM). I thought about persistently attaching all 10 of my USB drives to the VM (some HDs, some flash, one SSD - I never use all of them at once - don't ask!) because that would certainly fix this problem, but I get the following error when I try to start the VM: "ERROR: Start failed: XML error: target 'xvdi' duplicated for disk sources '/dev/sdc' and '/dev/sde', see /var/log/libvirt/libxl/libxl-driver.log for details". Note that I did all the persistent attachment commands while the VM was not running. If I detach all those, start the VM, do the persistent attachments, shut down the VM and then restart it, I get an error along the lines of "qrexec process failed to respond in 60 seconds". So, I guess I'm asking if there's a way to just persistently attach 2 or 3 external USB drives and have them consistently available on the same device names when I start the VM so VeraCrypt doesn't balk? (VeraCrypt ultimately doesn't care what device a drive is attached to (it could be sda - sdj on my system) because it shows the attached drive as "/media/user/BIG_TOSHIBA, but if a drive isn't where it's supposed to be, that'll fail. In case you're curious, the error messages in /var/log/libvirt/libxl/libxl-driver.log are meaningless to me, but if you want me to post it, I can. Any help you guys can give me would be greatly appreciated! Thanks...It isn't available yet, related issue: https://github.com/QubesOS/qubes-issues/issues/3437As a workaround you could mount the device via uuid or file system label in sys-usb, create a loop device from the container you want to pass to another VM and use qvm-block on that loop device (for which you can define the name yourself). Of course that's only convenient if you script it...Thanks, but how do you do create a loop device? I'm (mostly) a Linux newbie (and, as of 5 weeks ago, I was a Qubes newbie) - I'm your worst nightmare :) I tried the UUID mount thing described in the article I mentioned above, but it just prevents sys-net from starting, but maybe with this loop thing you mention? Can you give me the actual commands required, or direct me to an article showing this? I'm not even sure what to search for. Thanks much!
Honestly you'll probably be off better by waiting for the feature to be implemented then.
Anyway for reference I was talking about something like in your sys-usb: 1. mount -U [uuid] [mount point] 2. losetup -f --show [your veracrypt file on the mounted file system] in dom0: 3. qvm-block a [target VM] "sys-usb:[output of 2]"4. Open the veracrypt block device now attached to [target VM]. (luks supports that, not sure about veracrypt)
You can script all of that from dom0 using qvm-run. Essentially the idea was to attach the Veracrypt file to [target VM] instead of attaching the USB device itself.
qvm-block also supported files itself in 3.2 (i.e. 1. & 2. could be done with qvm-block), but from my experience that didn't work so well in the past. In 4.0 it was then removed I think; qvm-block -p [target VM] [some file] would have made for some really interesting applications such as the one described above without much need for scripting.
-- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/f3ba3bf3-4a30-f45a-6ce6-7a06ac57ed60%40hackingthe.net. For more options, visit https://groups.google.com/d/optout.
smime.p7s
Description: S/MIME Cryptographic Signature
