On Saturday, May 19, 2018 at 4:23:09 AM UTC-4, David Hobach wrote: > 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: SHA256 > >>> > >>> On 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/3437 > >> > >> As 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.
Thank you. You might be right about waiting. I've already wasted too much time on this, but I'll take a look at it :) Thanks again -- 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/bd0fd569-a8d9-4237-94e0-b95edad2d059%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
