Re: [qubes-users] Moving Qubes+VMs to Larger SSD - How to Handle Storage Pools on Other Disks?

[Chris Laprise]

On 9/7/19 5:10 PM, 'Heinrich Ulbricht' via qubes-users wrote:



It could work, take in account that backup file should be exposed
directly to dom0 or it will use 'qfile-unpacker':
https://github.com/QubesOS/qubes-issues/issues/3230#issuecomment-340277836



Good luck :)


Ok currently I'm attaching a USB drive to a temporary AppVM to restore 
from there via UI. So I should rather mount something containing the 
backup file to dom0 to restore from there using the command line(?).


The overall experience so far leaves room for improvement ;) Thanks for 
the tip.


Its a little tough for me to read all this, since my own 
Qubes-compatible backup tool with no storage overhead is nearing 
release. OTOH, if I had been in your shoes (not wanting to use someone 
else's pre-release tool) and faced with backups that large, I probably 
would have opted for a direct 'dd' copy to the new drive, or use 'dd' + 
hash for the backups.


Since you're at the point of trying to modify restore.py, you may still 
want to consider the direct 'dd' option (if so, then you would have two 
"backups", the one from qvm-backup plus the original work drive).


Even so, using tar directly with a small script as donoban suggested is 
workable and something I've done back in the R2.0-3.0 days. So I'll 
include my old verification script for you here... it could be easily 
adapted to append the segments to a whole tar file (or to save space, 
pipe them to tar directly).



===
#!/bin/bash 




# **  Quick and dirty script to verify integrity of Qubes backup files 
   **
# **  Change the backup file name and 'passphrase' variable to match 
yours  **
# **  Should be invoked from a 'tar' command (not directly) like so... 
   **
# 

# tar -i -xf put-your-backup-file-here \ 

# --to-command='./verify-qbackup $TAR_FILENAME' 






passphrase="put-your-backup-passphrase-here" 

fname=$1 






if [ "${fname##*.}" = "hmac" ] ; then 

# This file has .hmac extension; Compare with prior file's 
just-calculated hmac
  read hmac 

  echo -n "Received...  " $hmac 

  read myhmac 
  if [ "$hmac" = "$myhmac" ] ; then 

echo "  OK" 

  else 

echo "  *MISMATCH*" 

kill -SIGINT $PPID 

# Stop tar/parent 

  fi 

else 

# This file is data; create an hmac from stdin for comparison with next 
file
  echo 

  echo "FOUND " $fname 

  echo -n "Calculating..." 

  openssl dgst -hmac "$passphrase" >verifyqb.tmp 

  read myhmac 
  echo $myhmac 

fi 


===

--

Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886

--
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 qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/c95941da-f98f-19fc-f7ce-ad3b7f48b0ed%40posteo.net.

[qubes-users] Re: script to fix qubes-whonix time-sync issue

[rec wins]

On 9/6/19 4:55 AM, qtpie wrote:
> qtpie:
>> unman:
>>> On Thu, Sep 05, 2019 at 12:23:13PM +0200, donoban wrote:
 On 9/5/19 11:41 AM, qtpie wrote:> My usecase is this: suspend a laptop
 with sys-whonix and whonix appvms
> running, then resume it a few hours later.
>
> After resume Tor lost connection, re-connection fails until i manually
> sync time on sys-net then
> @sys-firewall 'sudo ntpdate [timeserver]
> @sys-whonix 'sudo qvm-sync-clock'
> @sys-whonix 'sudo systemctl restart 
> tor-fCAy/bagh0fxz5zemyojwq-xmd5yjdbdmrexy1tmh2ibg-xmd5yjdbdmrexy1tmh2...@public.gmane.org'
>
> Is this also you usecase? You do not expierence any issues after
> suspend/resume on qubes 4 with Tor running?
>

 Ouch yes, usually after suspend/resume I had to run just:
 @sys-whonix 'sudo systemctl restart 
 tor-fCAy/bagh0fxz5zemyojwq-xmd5yjdbdmrexy1tmh2ibg-xmd5yjdbdmrexy1tmh2...@public.gmane.org'


 Currently I am not using whonix, I am testing with minimal fedora torvm[1].

 It seems stable. I don't have problems with suspend/resume and I skipped
 the sync clock steps [2]. Probably it's less anonymous than Whonix, but
 for me seems fine.

 [1] https://hackmd.io/JIXLStC-Sbq8rr1mjomCDQ
>>>
>>> You know there's a Qubes package for that? (deprecated but still
>>> buildable.)
>>> I have my own fork for a torVM which includes Qubes firewall
>>> support, which Whonix doesn't provide.
>>>
>>
>> Which package? I couldnt immediately find it.
>>
> 
> FYI: I'm also going to apply shutdown-on-suspend to sys-usb, since I
> have to kill it manually right now since it hangs after resume. It might
> not be elegant, there might be a bug/fix, but I dont care, just want the
> problem solved.
> 
> If anyone knows the existing package to do this it would be very welcome.
> 

I have been running sdwtime-gui  in sys-whonix and anon-whonix every
time I use them,  then it is hit and miss  whether  it  awakes and has
failed, but I don't suspend so often

-- 
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 qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/586d615a-72c3-344c-3d64-8ff0adf1e302%40riseup.net.

Re: [qubes-users] Cant connect hard drive to appvms?

[Brendan Hoar]

On Sat, Sep 7, 2019 at 3:04 PM Stumpy  wrote:

> ...


Does the template for the VM have the ntfs-3g package installed?

B

>

-- 
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 qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/CAOajFeefnLynfkZF6%2BD7tcJenntz9D%3DJUM_%2BWPTFaLDatU1t9Q%40mail.gmail.com.

Re: [qubes-users] Moving Qubes+VMs to Larger SSD - How to Handle Storage Pools on Other Disks?

[donoban]

On 9/7/19 11:10 PM, 'Heinrich Ulbricht' via qubes-users wrote:
> Ok currently I'm attaching a USB drive to a temporary AppVM to restore
> from there via UI. So I should rather mount something containing the
> backup file to dom0 to restore from there using the command line(?).
> 
> The overall experience so far leaves room for improvement ;) Thanks for
> the tip.
> 

Obliviously it is a security risk but you can attach directly to dom0
using command line: qvm-device block attach dom0 sys-usb:sdx  . And then
mount it. Then you can use the UI backup and select dom0 as Qube.

-- 
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 qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/60b114a8-df6d-189c-13f9-7596c4b73d14%40riseup.net.

Re: [qubes-users] Moving Qubes+VMs to Larger SSD - How to Handle Storage Pools on Other Disks?

['Heinrich Ulbricht' via qubes-users]

>
> It could work, take in account that backup file should be exposed 
> directly to dom0 or it will use 'qfile-unpacker': 
> https://github.com/QubesOS/qubes-issues/issues/3230#issuecomment-340277836 
>
> Good luck :) 
>

Ok currently I'm attaching a USB drive to a temporary AppVM to restore from 
there via UI. So I should rather mount something containing the backup file 
to dom0 to restore from there using the command line(?).

The overall experience so far leaves room for improvement ;) Thanks for the 
tip.

(I also commented on the mentioned GitHub issue 

).

-- 
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 qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/98d458d1-2fd0-41a2-915d-fb6fd516bd89%40googlegroups.com.

Re: [qubes-users] Moving Qubes+VMs to Larger SSD - How to Handle Storage Pools on Other Disks?

[donoban]

On 9/7/19 10:54 PM, 'Heinrich Ulbricht' via qubes-users wrote:
> The best bet I currently have it applying the "sleep trick" (see here
> )
> to line 598ff
> 
> in /restore.py/.
> 
> So this:
> elifinner_name inself.handlers:
> tar2_cmdline =['tar',
> '-%svvO'%("t"ifself.verify_only else"x"),
> inner_name]
> redirect_stdout =subprocess.PIPE
> 
> Would become something like this:
> elifinner_name inself.handlers:
> tar2_cmdline =['tar',
> '-%svvO'%("t"ifself.verify_only else"x"),
> '--checkpoint=2',
> '--checkpoint-action=exec=\'sleep "$(stat -f
> --format="(((%b-%a)/%b)^5)*30" /var/tmp | bc -l)"\'',
> inner_name]
> redirect_stdout =subprocess.PIPE
> 
> 
> Too naive?
> 

It could work, take in account that backup file should be exposed
directly to dom0 or it will use 'qfile-unpacker':
https://github.com/QubesOS/qubes-issues/issues/3230#issuecomment-340277836

Good luck :)

-- 
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 qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/6a0e8f93-8755-696c-bc5b-6a4035a72da7%40riseup.net.

Re: [qubes-users] Moving Qubes+VMs to Larger SSD - How to Handle Storage Pools on Other Disks?

['Heinrich Ulbricht' via qubes-users]

>
>
> Can anybody suggest a modification (or hack, however dirty - it's meant to 
> be temporary) to restore.py so it won't need 700 GB of additional temporary 
> storage when I try to restore my 700 GB AppVM?
>
>
The best bet I currently have it applying the "sleep trick" (see here 
) 
to line 598ff 

 
in *restore.py*.

So this:
elif inner_name in self.handlers:
tar2_cmdline = ['tar',
'-%svvO' % ("t" if self.verify_only else "x"),
inner_name]
redirect_stdout = subprocess.PIPE

Would become something like this:
elif inner_name in self.handlers:
tar2_cmdline = ['tar',
'-%svvO' % ("t" if self.verify_only else "x"),
'--checkpoint=2',
'--checkpoint-action=exec=\'sleep "$(stat -f --format="(((%b-%a)/%b)^5)*30" 
/var/tmp | bc -l)"\'',
inner_name]
redirect_stdout = subprocess.PIPE


Too naive?

-- 
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 qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/bdb6b20f-b829-41e1-b6cf-ce6c1917f6e9%40googlegroups.com.

Re: [qubes-users] Moving Qubes+VMs to Larger SSD - How to Handle Storage Pools on Other Disks?

[donoban]

> On 01/09/2019 3.46 AM, 'Heinrich Ulbricht' via qubes-users wrote:> Here is an 
> update on how my migration from SSD_small to SSD_big is going
> so far.
> 
> Just as a remindet this is the challenge I face:
> * dom0 SSD has 100 GB capacity, ~10% of this is free (that's why I want
> to migrate to a new SSD)
> * external storage pool 1 has 1 TB storage, AppVM *1* with < 500 GB
> private storage in use
> * external storage pool 2 has 1 TB storage, AppVM *2* with > 500 GB
> private storage in use
> * I want to migrate everything via backup+restore to new disks/pools
> 
> _Here is what worked_
> * backing up App VMs from all 3 pools using built-in backup mechanisms
> (UI) - cool
> 
> _Here is what did not work_
> * *verifying* the huge (400-700 GB) backups *did not work* since this
> filled up my dom0 pretty fast and then failed -> this is the reason why
> I resorted to what Andrew wrote: having the original still in place
> while restoring to different disks, not overwriting anything, just in
> case restoring fails
> * *restoring* the huge (400-700 GB) backups *did not work* since this
> filled up my dom0 pretty fast and then failed -> this is exactly like
> donoban wrote; I managed to work around this for AppVM *1*, NOT for
> AppVM *2* (yet)
> 
> To restore AppVM *1* (< 500 GB) I modified /restore.py
> /
> to restore to another location than //var/tmp/. The easiest for me was
> to create a new (temporary) AppVM in my new 1 TB external storate pool
> *1*, to increase its private storage to 500 GB, to mount its private
> volume to dom0 and to use this path as temporary location in
> /restore.py/. So I was using my 1 TB disk both as restore target and
> temporary location for backup extraction. I was lucky - the pool filled
> up to 99.8% and the restore succeeded. So currently it seems you need
> double the amount of storage your to-be-restored AppVM consumes to
> restore the AppVM.
> 
> Now there is one challenge left. I have to restore AppVM *2* which is
> about 700 GB. To my current knowledge I would now need to have twice
> this amount to restore - which currently I don't have. This is why I'd
> like to somehow slow down the extraction. donoban mentioned this is
> possible. I had a look at restore.py
> 
> but honestly have not idea where to start. I also currently don't know
> how the different extraction processes interact and how the backup is
> structured.
> 
> Can anybody suggest a modification (or hack, however dirty - it's meant
> to be temporary) to restore.py so it won't need 700 GB of additional
> temporary storage when I try to restore my 700 GB AppVM?
> 
> Thanks for all your input so far. Knowing that dom0 could fill up
> certainly saved my some hours of questioning life.
> 
Sorry to hear that. There are two options in 'tar' (--checkpoint and
--checkpoint-exec) that can be used for execute a command during the
extraction process so they could potentially be used to force a 'sleep'
and slow down it. Take a look on this issue comment[1], and try to hack
restore.py with it. I personally didn't try it since my AppVM's were
small enough for just restoring them in few groups.

Hopefully Marek could help with this, probably he will answer if you
comment on the github issue.

[1]
https://github.com/QubesOS/qubes-issues/issues/3230#issuecomment-340253679

-- 
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 qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/728163a8-1fd9-113a-7a5a-45c1d898ffdd%40riseup.net.

Re: [qubes-users] Moving Qubes+VMs to Larger SSD - How to Handle Storage Pools on Other Disks?

['Heinrich Ulbricht' via qubes-users]

On Monday, September 2, 2019 at 6:11:58 AM UTC+2, Andrew David Wong wrote:
>
> -BEGIN PGP SIGNED MESSAGE- 
> Hash: SHA512 
>
> On 01/09/2019 3.46 AM, 'Heinrich Ulbricht' via qubes-users wrote: 
> >> Personally, I would just stick with this. In other words, I would treat 
> >> the new Qubes installation as completely new and use qvm-backup-restore 
> >> as the only mechanism for migrating my old data to the new 
> installation. 
> >> This is the only way I would be confident that I weren't screwing 
> >> anything up. 
> >> 
> >> 
> > Thank you very much for helping me out on this, awokd and Andrew. 
> Currently 
> > I'm leaning toward taking the safe path. If I understand correctly that 
> > means: 
> > 
> >1. Backup everything that's on the SSD *and* the external storage 
> pool 
> >HDDs - this will take a lot of time and space but that's the price I 
> have 
> >to pay for the safety I get 
> >2. Connect the new SSD, wipe the external drives 
> >3. Install Qubes OS on the new SSD 
> >4. Create external storage pools on the additional HDDs 
> >5. Make the SSD the default pool; restore VMs for SSD 
> >6. Make external disk 1 the default pool; restore VMs for this pool 
> >7. Make external disk 2 the default pool; restore VMs for this pool 
> >8. Switch default pool back to SSD 
> >9. Done 
> > 
> > How does this sound? 
> > 
>
> I haven't personally used external storage pools, so I can't comment 
> there. (Thankfully, though, others have already weighed in on that part.) 
>
> Related to Brendan's point, in step 1, it's important to *verify* the 
> backups you've just created. 
>
> GUI: Qube Manager -> Restore qubes from backup -> [x] Verify backup 
>  integrity, do not restore the data 
>
> CLI: qvm-backup-restore --verify-only [...] 
>
> As the saying goes: Backups always succeed. It's restores that fail. 
>
> (If you have the extra disks, it would technically be even safer to 
> use new HDDs and refrain from wiping the existing ones until after 
> you've verified that everything is correct in the new system, but this 
> might be overly cautious. I personally don't feel the need to do this 
> anymore, because I know the data is already there in a verified Qubes 
> backup, and I've tested my ability to manually recover it 
> independently of Qubes as a last resort.) 
>
> Aside from these caveats, your plan sounds like what I would do. 
>
> - -- 
> Andrew David Wong (Axon) 
> Community Manager, Qubes OS 
> https://www.qubes-os.org 
>
> -BEGIN PGP SIGNATURE- 
>
> iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAl1sloEACgkQ203TvDlQ 
> MDDqdg//cFoY4k/EFm5t2pVpoiFKubh/o34CzJo8eYfOWgHaNnnVlhfqXGartWkS 
> F5aSeig2PiPWpPqfJ9G4mWV46ySjC/hez0fSmAl2rsNA/PaRTAG/aIhIy7DlNuoo 
> H9MQJw5TsiHvgz6h/FfYVOcl1/mDOwmVw4n9WQ1x49bgsmI+CdZf94c7P+XvEpde 
> YM3G2hGi6e1Bd3H3Xm1B5EtovsMXC3ieDkXDYlun814t1jBv0BmVib93vRaltHIt 
> Bdd766BAvhkdMOOWONHfmOrw1An7FBm1uKIxdJb71w5Kltv8VV1S7xXq387/QmGF 
> fcdJljdEtArgxg4Pe35i03GseDjRfw1rhsH3TL/8PDjY2P1n+lwI5JG8+fa7ZPUM 
> FHKoQAiPk9D3d8vOXmnwVT8QrCdaJvnX0bqtihusUnUh13+ZCrP5akq3KE7hrIn3 
> dgVG6eywbwS/Y18pbXChdvDdz3kx6Q05cB56nsFfyR65amLJh7F3NmkVd20HBDoh 
> yNxEqWMaHLiz/chOLLXFxUy8nAor/CQ8JgRPbERh40M5l67jzhFEXgHRl5u4XmbM 
> g8iNpYbFoUsBDP8bSzgPIFaNJ/OuUGnNsXtyYGwfxTzH45UMHLqGCqAPPdRUqaRB 
> W3JYH81cFnRVJdqBU+bj+1GPyD6an31++0ahJFX11DawHiP8nEc= 
> =d7uO 
> -END PGP SIGNATURE- 
>
>
Here is an update on how my migration from SSD_small to SSD_big is going so 
far.

Just as a remindet this is the challenge I face:
* dom0 SSD has 100 GB capacity, ~10% of this is free (that's why I want to 
migrate to a new SSD)
* external storage pool 1 has 1 TB storage, AppVM *1* with < 500 GB private 
storage in use
* external storage pool 2 has 1 TB storage, AppVM *2* with > 500 GB private 
storage in use
* I want to migrate everything via backup+restore to new disks/pools

*Here is what worked*
* backing up App VMs from all 3 pools using built-in backup mechanisms (UI) 
- cool

*Here is what did not work*
* *verifying* the huge (400-700 GB) backups *did not work* since this 
filled up my dom0 pretty fast and then failed -> this is the reason why I 
resorted to what Andrew wrote: having the original still in place while 
restoring to different disks, not overwriting anything, just in case 
restoring fails
* *restoring* the huge (400-700 GB) backups *did not work* since this 
filled up my dom0 pretty fast and then failed -> this is exactly like 
donoban wrote; I managed to work around this for AppVM *1*, NOT for AppVM 
*2* (yet)

To restore AppVM *1* (< 500 GB) I modified *restore.py 
*
 
to restore to another location than */var/tmp*. The easiest for me was to 
create a new (temporary) AppVM in my new 1 TB external storate pool *1*, to 
increase its private storage to 500 GB, to mount its private volume to dom0 
and to 

Re: [qubes-users] Cant connect hard drive to appvms?

[Stumpy]

On 9/6/19 11:32 AM, Stumpy wrote:

On 9/5/19 10:42 AM, unman wrote:

On Wed, Sep 04, 2019 at 08:12:26PM -0400, Stumpy wrote:
I have a hard drive that i cant seem to connect to any of the appvms 
yet I

can see and access it via dom0 (not good i know).
I can attach a usb flash drive to my appvms but not the hard drive?

This is on my laptop and i do not have a sys-usb (didnt give me the 
option

when installing qubes (v4.0.2) but if i can connect a flash then i cant
figure why i cant connect the external hard drive to appvms, esp if i 
can

use/see the drive via dom0?

Thoughts?



It's notable that you dont say what you are doing and what does happen
(if anything). Any chance of a little more information?


oops, i replied only to unman by accident.

I am hoping to copy things from the external usb hard drive (sata drive 
in a usb dock).


When i connect my external usb drive to the computer i get the popup 
that its recognized, both sdc and sdc1.


When i attach it via qubes devices it doesnt say or give any errors.

When i try to access it on the appvm that i connect it to it does not 
show up in nautilus like say my flash usb devices, nor does it show as 
being mounted when i check for mounted devs via the terminal


yet.

On dom0 i can see the drive, i can access the drive, and modify the 
contents but of course this is not a good idea.


I have not tried qvm-usb, qvm-device, or qvm-block as i am not familar 
with them but at this point am open to trying them (any docs on how to 
use them?)




should it make a difference if the external hard drive is formatted in NTFS?

I tried putting it on another qubes computer that i have (v4.0.1), that 
does have a sys-usb, and my sys-usb can access it, but, as with my 
notebook I cant mount it in a regular appvm?


In this case, i plug it in, i get a popup indicating its detected, i 
then take a look at it via sys-usb, can access the contents, then go to 
qubes devices click the appvm to attach it to and nothing.


in dom0 i do qvm-usb list sys-usb and it shows me everything except the 
hard drive, that i know is attached because I am looking at its contents 
in sys-usb. I really dont know what to make of this. is there like a 
drive size limit? (this is a 6tb drive)


--
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 qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/86185fc8-7999-56cc-354c-a825d6d608d8%40posteo.net.

Re: [qubes-users] Cant connect hard drive to appvms?

['awokd' via qubes-users]

Stumpy:

> I am hoping to copy things from the external usb hard drive (sata drive
> in a usb dock).
> 
https://www.qubes-os.org/doc/block-devices/

-- 
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 qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/f22461e6-0eeb-8e42-844d-2bf526d064e7%40danwin1210.me.

Re: [qubes-users] Black screen after legacy mode installation(Conventional/search result methods didnt work)

['awokd' via qubes-users]

gamesmasr3...@gmail.com:
> Worked, thanks
> 
> On Saturday, 7 September 2019 15:31:16 UTC+1, awokd wrote:
>>
>> 42079801612 via qubes-users: 
>>
>>> This lead me to this solution 
>>> <
>> https://www.qubes-os.org/doc/uefi-troubleshooting/#cannot-start-installation-installation-completes-successfully-but-then-bios-loops-at-boot-device-selection-hangs-at-four-penguins-after-choosing-test-media-and-install-qubes-os-in-grub-menu>(<-Link).
>>  
>>
>>
>> I think you meant 
>>
>> https://www.qubes-os.org/doc/uefi-troubleshooting/#installation-finished-but-qubes-boot-option-is-missing-and-xencfg-is-empty
>>  
>> ? You can perform step #4 from another distro booted in UEFI mode too. 
>>
>> If that still doesn't work, remove legacy boot and try 
>>
>> https://www.qubes-os.org/doc/uefi-troubleshooting/#installation-freezes-before-getting-to-anaconda-qubes-40
>>  
>> or the no-rs one below it. 

Which method worked? Enjoy Qubes!

-- 
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 qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/5330d7f7-e9eb-4dca-649a-536faca5cc08%40danwin1210.me.

Re: [qubes-users] Black screen after legacy mode installation(Conventional/search result methods didnt work)

[gamesmasr3000]

Worked, thanks

On Saturday, 7 September 2019 15:31:16 UTC+1, awokd wrote:
>
> 42079801612 via qubes-users: 
>
> > This lead me to this solution 
> > <
> https://www.qubes-os.org/doc/uefi-troubleshooting/#cannot-start-installation-installation-completes-successfully-but-then-bios-loops-at-boot-device-selection-hangs-at-four-penguins-after-choosing-test-media-and-install-qubes-os-in-grub-menu>(<-Link).
>  
>
>
> I think you meant 
>
> https://www.qubes-os.org/doc/uefi-troubleshooting/#installation-finished-but-qubes-boot-option-is-missing-and-xencfg-is-empty
>  
> ? You can perform step #4 from another distro booted in UEFI mode too. 
>
> If that still doesn't work, remove legacy boot and try 
>
> https://www.qubes-os.org/doc/uefi-troubleshooting/#installation-freezes-before-getting-to-anaconda-qubes-40
>  
> or the no-rs one below it. 
>
>

-- 
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 qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/ac0889df-d3b1-4fb3-9f0b-e0778fbfa20b%40googlegroups.com.

Re: [qubes-users] Have to drop Qubes because of company policy: workarounds?

[Pablo Di Noto]

Hello,
 

> I think you may be overstating the problem of running anti-virus on 
> Qubes. If you could find an AV that updates its virus definitions via 
> signed RPMs, then it can be made to work without a lot of effort. 
>

The issue in this case is two fold: The designated ~antivius~ endpoint 
protection solution (Sentinel One in our case) offers no support for 
Fedora, specially an oldish one like F25. Also, the whole compliance point 
is to have the endpoint report frequently its compliance status, which dom0 
would not do.
And, of course, this solution has its own update mechanism, so it cannot be 
made work with the RPM proxy Qubes offers.


> Beyond that, you could still do it without RPMs, assuming the AV program 
> requires all of its data to be signed. 
>
> - 
>
> Whatever AV installation you had in dom0 would also need to be installed 
> in a template as well... this allows DispVMs to scan your various 
> working VMs while still maintaining isolation. The definition update 
> mechanism for the template would be the same as for dom0 (i.e. import an 
> RPM, or some other signed data file via qvm-copy). 
>

I see no issue with that.
Unfortunately, from my company point of view, having only all VMs with the 
endpoint security software would not make me compliant.

Thanks for your comments!
///Pablo

>
>

-- 
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 qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/ca6a5923-15f7-42c2-a0c4-d2179b61abcd%40googlegroups.com.

Re: [qubes-users] Re: SWAPGS Side Channel Attack

[Lorenzo Lamas]

On Saturday, September 7, 2019 at 8:45:52 AM UTC+2, Andrew David Wong wrote:
>
> -BEGIN PGP SIGNED MESSAGE- 
> Hash: SHA512 
>
> On 06/09/2019 6.30 AM, 'awokd' via qubes-users wrote: 
> > Lorenzo Lamas: 
> >> Is anyone from Qubes team reading this? 
> >> 
> > ADW and unman are pretty active in this list, but the original 
> > question might be better suited for qubes-devel. 
> > 
>
> The Qubes Security Team is preparing an answer to this question. 
> Please stand by. 
>
> - -- 
> Andrew David Wong (Axon) 
> Community Manager, Qubes OS 
> https://www.qubes-os.org 
>
> -BEGIN PGP SIGNATURE- 
>
> iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAl1zUhUACgkQ203TvDlQ 
> MDAQkw//ctHN6HCb6R5fzPNnqcIhLzAyWoOWewXEGJGBPD1PHXT0xSKDakeqXn91 
> yaZ5t54sB2rnTgZmAvo0GfcBoxt2mMO0KTyYosVDoQYsJIlNlvsKFHsxhMUvgSxP 
> wtYATAuYna6Ohj+hDzCPzt1x3ld3ALk7dBMLIknpepPnkbrKzE24JG3t9N8FPlll 
> kYAwtO3KQWbPA2YLIOlRO5+rgkgNucMflVipSuIUzVH3zc7wQKEpqipYoE9P2/bl 
> yxomkoqZsVLhsuebKnLBlHa/RHhMlWj7sgXC2xL3NTc+O5cTLbnTlEGqzmxmTEHD 
> 6M1GRNa8caO9y0lisoAAb0SSlX6QwAf5r1f0X1G9RRbpN61bHFE/AfGOt9lpHaGM 
> irOacfzcJ5U4+L9g5MzkX/HGfDxN6muaPa5WffvHQpYFl2eBV9t/QBsinKS5oSTI 
> gSsuO5aG6dZ2hvn/n7LXzsaS2OuluU5TSzlvVHMKD79YlNVx3ymFHpV2rXQfS2rM 
> AX3QgjjU2ZAVkKjRRJI3Lwg1cJfiZmHqHOCxDoW05KAwK2pnIAN2646wcT4q8Job 
> 9NVOT1OMDDPIgVfTHJgPLZ0oY06vOS79Et3G44OzhD+zXSJ8bWra469bg4Tf7iXk 
> Rt/5SkJpD3E83qjL8OKXlKKZCGeT3fGswAkkLdU/FILbFh9/KDw= 
> =CQeP 
> -END PGP SIGNATURE- 
>
> Thanks for taking the time to reply! I'll await news from the Qubes 
Security Team. 

-- 
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 qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/37518413-f8e7-4c44-bc7a-6cce9ab90819%40googlegroups.com.

Re: [qubes-users] Black screen after legacy mode installation(Conventional/search result methods didnt work)

['awokd' via qubes-users]

42079801612 via qubes-users:

> This lead me to this solution 
> (<-Link).
>  

I think you meant
https://www.qubes-os.org/doc/uefi-troubleshooting/#installation-finished-but-qubes-boot-option-is-missing-and-xencfg-is-empty
? You can perform step #4 from another distro booted in UEFI mode too.

If that still doesn't work, remove legacy boot and try
https://www.qubes-os.org/doc/uefi-troubleshooting/#installation-freezes-before-getting-to-anaconda-qubes-40
or the no-rs one below it.

-- 
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 qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/646cf3eb-6a19-ae24-81b3-3cee4a82bd31%40danwin1210.me.

[qubes-users] Black screen after legacy mode installation(Conventional/search result methods didnt work)

[42079801612 via qubes-users]

I am trying to install qubes on a machine that has worked fine with linux 
on in the past.
At my first attempt, I did everything how I would install an OS normally 
,selected my installation media in the USB boot menu and tried to install. 
After seeing some text fly by, the screen would go black and stayed so for 
around 20 minutes before I decided something was wrong. A few searches 
later I found there were some inherent problems with UEFI and qubes, so 
enabling legacy boot in my BIOS allowed me to boot the installer 
successfully(At this point I also enabled an option to do with 
virtualisation that I noticed and tried again, it had no different result). 
Now I followed the installer as normal and after rebooting, I met the same 
issue described before, where the screen would just go black. (To be sure 
it was booting normally I also tried with the USB removed). 

Firstly I found an official guide 
(<-Link).
 
The file shown after pressing "e" in GRUB had no "chainloader line" in it. 
Regardless I tried adding "/mapbs /noexitboot" on the end of the command I 
saw and carried out step 11 appropriately. Same result, black screen.

After this I came across a reddit post 
(<-Link).
 
I tried this solution however I was met with a different issue, where 
instead of going to a black screen the startup log would stay on the screen 
and start blinking on and off indefinitely. However something else I found 
that was off, was the "xen.cfg" that was mentioned in the reddit post, 
specifically how the instruction was to write the lines beneath "BOTH 
paragraphs", however my xen.cfg was empty at the time(Unsure whether it was 
empty or didn't exist, didn't notice it at the time).

This lead me to this solution 
(<-Link).
 
Before I start, I tried this solution both in recovery mode and in tty2 
after installation to the same result. I wrote the xen.cfg as described and 
substituted the versions for the same that were in the EFI/qubes folder. 
However, when running the final command in step 4, I get "EFI variables are 
not supported on this system.". I have a hunch that this is because I 
booted in legacy(which is my only working option). Search results brought 
no relevant results, they all seemed to be related to chroot scenarios 
rather to qubes. 

At this point I'm not sure where to go, I can find no leads relevant to 
qubes, yet a github post lead me here.

-- 
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 qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/229ca4d9-ec98-4f25-9672-1c921086ca61%40googlegroups.com.

Re: [qubes-users] Have to drop Qubes because of company policy: workarounds?

[Chris Laprise]

On 9/7/19 8:48 AM, Pablo Di Noto wrote:

Hello!

I have been a Qubes user for 3+ years and adopted its 
separation-of-concern model deeply into my day to day activities.


A year ago I started to work for a cloud company that is 
seeking/re-certifying several security certifications, and among the 
requirement of these certifications are strict policies that require any 
organization member accessing any company resource to have a certified 
antivirus solution installed on their computer(s), including Linux. That 
is a very common requirement for corporate work.


Unfortunately, these policies leave much room for interpretation, and 
companies tend to lean on the safe side to avoiding corner cases that 
may "upset" the certification auditing teams.


Long story short, as Qubes cannot run (and does not make any sense to 
run) a self-updating, status reporting antivirus on dom0, it is not 
compliant.


Sad times, as I will be having to go back many, many steps back in terms 
of real security and data protection in order to use one of the main 
distributions.


My managers are ok for me to to use xen (or other hypervisor, for that 
matter) and a compliant distribution as dom0 which would make the whole 
thing almost indistinguishable from a regular endpoint to any auditor.


Now finally the question: How difficult would be to have a Xen-based 
Fedora (or better, Debian) dom0 and then install the libvirt and qubes 
middleware for template handling, inter VM communications, etc? I know 
that would require a cumbersome install process, but does seem feasible. 
At the same time, it could be a nice experience in terms of testing 
Qubes middleware into multiple dom0 environments.


I know there are security implications to this: All the hardening on 
non-connected dom0 would be lost, the use of a off-the-shelf dom0 may 
bring lots of attack vectors, all installation-time setup of sys-* VMs 
would have to be redone manually, etc. But the final product would have 
the isolation-by-nature workflow I grew to love.


I think you may be overstating the problem of running anti-virus on 
Qubes. If you could find an AV that updates its virus definitions via 
signed RPMs, then it can be made to work without a lot of effort.


Beyond that, you could still do it without RPMs, assuming the AV program 
requires all of its data to be signed.


-

Whatever AV installation you had in dom0 would also need to be installed 
in a template as well... this allows DispVMs to scan your various 
working VMs while still maintaining isolation. The definition update 
mechanism for the template would be the same as for dom0 (i.e. import an 
RPM, or some other signed data file via qvm-copy).


--

Chris Laprise, tas...@posteo.net
https://github.com/tasket
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886

--
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 qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/5a8cbc35-00bd-e4a8-f56a-aa0fd6938a78%40posteo.net.

[qubes-users] Have to drop Qubes because of company policy: workarounds?

[Pablo Di Noto]

Hello!

I have been a Qubes user for 3+ years and adopted its separation-of-concern 
model deeply into my day to day activities.

A year ago I started to work for a cloud company that is 
seeking/re-certifying several security certifications, and among the 
requirement of these certifications are strict policies that require any 
organization member accessing any company resource to have a certified 
antivirus solution installed on their computer(s), including Linux. That is 
a very common requirement for corporate work. 

Unfortunately, these policies leave much room for interpretation, and 
companies tend to lean on the safe side to avoiding corner cases that may 
"upset" the certification auditing teams.

Long story short, as Qubes cannot run (and does not make any sense to run) 
a self-updating, status reporting antivirus on dom0, it is not compliant.

Sad times, as I will be having to go back many, many steps back in terms of 
real security and data protection in order to use one of the main 
distributions.

My managers are ok for me to to use xen (or other hypervisor, for that 
matter) and a compliant distribution as dom0 which would make the whole 
thing almost indistinguishable from a regular endpoint to any auditor.

Now finally the question: How difficult would be to have a Xen-based Fedora 
(or better, Debian) dom0 and then install the libvirt and qubes middleware 
for template handling, inter VM communications, etc? I know that would 
require a cumbersome install process, but does seem feasible. At the same 
time, it could be a nice experience in terms of testing Qubes middleware 
into multiple dom0 environments. 

I know there are security implications to this: All the hardening on 
non-connected dom0 would be lost, the use of a off-the-shelf dom0 may bring 
lots of attack vectors, all installation-time setup of sys-* VMs would have 
to be redone manually, etc. But the final product would have the 
isolation-by-nature workflow I grew to love.

Thanks for any advice about feasibility of this.
Cheers,
///Pablo

-- 
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 qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/282a9871-cd1a-421e-86cb-c4bdc263ff8b%40googlegroups.com.

Re: [qubes-users] Re: SWAPGS Side Channel Attack

[Andrew David Wong]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On 06/09/2019 6.30 AM, 'awokd' via qubes-users wrote:
> Lorenzo Lamas:
>> Is anyone from Qubes team reading this?
>> 
> ADW and unman are pretty active in this list, but the original
> question might be better suited for qubes-devel.
> 

The Qubes Security Team is preparing an answer to this question.
Please stand by.

- -- 
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org

-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAl1zUhUACgkQ203TvDlQ
MDAQkw//ctHN6HCb6R5fzPNnqcIhLzAyWoOWewXEGJGBPD1PHXT0xSKDakeqXn91
yaZ5t54sB2rnTgZmAvo0GfcBoxt2mMO0KTyYosVDoQYsJIlNlvsKFHsxhMUvgSxP
wtYATAuYna6Ohj+hDzCPzt1x3ld3ALk7dBMLIknpepPnkbrKzE24JG3t9N8FPlll
kYAwtO3KQWbPA2YLIOlRO5+rgkgNucMflVipSuIUzVH3zc7wQKEpqipYoE9P2/bl
yxomkoqZsVLhsuebKnLBlHa/RHhMlWj7sgXC2xL3NTc+O5cTLbnTlEGqzmxmTEHD
6M1GRNa8caO9y0lisoAAb0SSlX6QwAf5r1f0X1G9RRbpN61bHFE/AfGOt9lpHaGM
irOacfzcJ5U4+L9g5MzkX/HGfDxN6muaPa5WffvHQpYFl2eBV9t/QBsinKS5oSTI
gSsuO5aG6dZ2hvn/n7LXzsaS2OuluU5TSzlvVHMKD79YlNVx3ymFHpV2rXQfS2rM
AX3QgjjU2ZAVkKjRRJI3Lwg1cJfiZmHqHOCxDoW05KAwK2pnIAN2646wcT4q8Job
9NVOT1OMDDPIgVfTHJgPLZ0oY06vOS79Et3G44OzhD+zXSJ8bWra469bg4Tf7iXk
Rt/5SkJpD3E83qjL8OKXlKKZCGeT3fGswAkkLdU/FILbFh9/KDw=
=CQeP
-END PGP SIGNATURE-

-- 
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 qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/04706b14-3b53-b6e3-550c-7a294363b8a6%40qubes-os.org.

[qubes-users] script to fix qubes-whonix time-sync issue

[qtpie]

The only issue I keep having with Qubes-Whonix, is that after
suspend/resume, Whonix-GW time is out of sync and cant connect to the
Tor network. According to Whonix the safe option is to simply not
suspend Whonix.

https://www.whonix.org/wiki/Post_Install_Advice#Network_Time_Syncing

However with a laptop running from battery not using suspend is not
really an option and manually shutting down multiple qubes is annoying.
To do this automatically I wrote this script, but cant get it working
yet. Any help is welcome.

https://github.com/qtpies/qubes-whonix-suspending

-- 
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 qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/qkm37v%243e72%241%40blaine.gmane.org.