Re: [qubes-users] Safe to switch default-mgmt-dvm TemplateVM from Fedora 29 to Fedora 30?

['Heinrich Ulbricht' via qubes-users]

Thank you. Then I'll do it.

On Wednesday, October 16, 2019 at 2:12:37 PM UTC+2, Marek 
Marczykowski-Górecki wrote:
>
> -BEGIN PGP SIGNED MESSAGE- 
> Hash: SHA256 
>
> On Tue, Oct 15, 2019 at 02:39:56PM -0700, 'Heinrich Ulbricht' via 
> qubes-users wrote: 
> > I want to switch the template for all my Fedora 29 AppVMs to Fedora 30. 
> > 
> > In the process I learned about *default-mgmt-dvm* which is currently 
> based 
> > on Fedora 29. Is it safe to simply switch the template to a 
> (stock+updates) 
> > Fedora 30 template? 
> > 
> > This issues <https://github.com/QubesOS/qubes-issues/issues/5181> 
> suggests 
> > there might still be problems. 
> > This answer 
> > <https://groups.google.com/d/msg/qubes-users/WMSowoOgfIA/dXA8tco-CAAJ> 
> > suggests it is indeed as simple as switching the template. 
> > This thread 
> > <
> https://groups.google.com/forum/#!msg/qubes-users/qf4zN6SFe18/rr6rclqoCAAJ> 
>
> > has never been answered but covers basically the same topic (switching 
> to 
> > Fedora 29). 
> > 
> > Should I just switch or rather not touch it? 
>
> Yes, it's ok to and even desirable to switch. It should be based on 
> stock template without less trusted repositories and software installed. 
>
> - -- 
> Best Regards, 
> Marek Marczykowski-Górecki 
> Invisible Things Lab 
> A: Because it messes up the order in which people normally read text. 
> Q: Why is top-posting such a bad thing? 
> -BEGIN PGP SIGNATURE- 
>
> iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAl2nCSoACgkQ24/THMrX 
> 1yyAGggAkUSGnRuUiA2OnHRWqgfSXglHFiiZBXQipuYgHtuYtNr6dCDBOiCFfV5t 
> xaCZalo/wwi3LZ6RG+/8BqvaetoGM2bBjWNUXeFBCBe+GVWM1X6DGwF0xrVaacVQ 
> kl72aXJXg/h1SnlxNbTkqGQtJ51PlyfWOnr95jRwFegKdGng/RZGkyGwQnA0EKXw 
> 3kzCM1s5SoEakuy/jsXIDrBqD4h1OR4uWev2Bld4FdwnSAVlX/ioKhxWM0Q0BH9W 
> 2dKgVyUbWBE97w5KiSe0PllTdf0J/ZaNKfdmuxs7riBvcki1KesjycUdNthlgK+e 
> KQkCIlKsMPyJ1RirldPd7NTqOmfM2w== 
> =53kw 
> -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/53736e49-9c48-422b-a4c7-1c81d3fdf4fa%40googlegroups.com.

[qubes-users] Re: Anyone tried Anbox ('Android in a box') under Qubes

['Heinrich Ulbricht' via qubes-users]

Two years later - did anybody try this again and succeeded?

I tried installing it in an Debian 10 template VM (there is now *apt 
install anbox*!) but got stuck at the kernel modules as another person 
trying it here 
.


On Monday, July 17, 2017 at 9:21:15 AM UTC+2, P R wrote:
>
> Hello,
>
> I'm interested in running Android as HVM within Qubes.
> Has anyone trying to do so already with the code from the Anbox Project?
>
> https://anbox.io
> *"(...) Anbox puts the Android operating system into a container, 
> abstracts hardware access and integrates core system services into a 
> GNU/Linux system. Every Android application will be integrated with your 
> operating system like any other native application. (...)"*
>
> I haven't seen it yet, but having the application  integrated with the OS 
> sounds like what Qubes is doing with AppVMs to the user, so very 
> user-friendly.
>
> - PhR
>

-- 
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/8974a813-bc8a-429d-9a42-e1e9388ebd9f%40googlegroups.com.

[qubes-users] Re: Anyone tried Anbox ('Android in a box') under Qubes

['Heinrich Ulbricht' via qubes-users]

Two years later - did anybody try this again and succeeded?

I tried installing it in an Ubuntu 10 template VM (there is now *apt 
install anbox*!) but got stuck at the kernel modules as another person 
trying it here 
.


On Monday, July 17, 2017 at 9:21:15 AM UTC+2, P R wrote:
>
> Hello,
>
> I'm interested in running Android as HVM within Qubes.
> Has anyone trying to do so already with the code from the Anbox Project?
>
> https://anbox.io
> *"(...) Anbox puts the Android operating system into a container, 
> abstracts hardware access and integrates core system services into a 
> GNU/Linux system. Every Android application will be integrated with your 
> operating system like any other native application. (...)"*
>
> I haven't seen it yet, but having the application  integrated with the OS 
> sounds like what Qubes is doing with AppVMs to the user, so very 
> user-friendly.
>
> - PhR
>

-- 
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/e3496504-19e6-4548-98e9-384c38fb69ba%40googlegroups.com.

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

['Heinrich Ulbricht' via qubes-users]

>
>
>
> THIS is the place to insert the checkpoint operation for the un-tar (line 
> 913ff in restore.py 
> 
> ):
>
> tar1_command = ['tar',
> '-ixv',
> '--occurrence=1',
> '--checkpoint=2',
> '--checkpoint-action=exec=\'sleep "$(stat -f --format="(((%b-%a)/%b))*120" 
> /var/tmp | bc -l)"\'',
> '-C', self.tmpdir] + filelist
>
> This seems to be a non-interruptable tar operation that is pushing 
> thousands of chunk files into the temp location with the other processes 
> having no chance to process them in time. I'll follow up with details.
>


Above sole change to restore.py did solve the problem for me. Note that I 
tweaked the parameters a bit to give it more time. With this change the 
initial sleep duration was about 2 seconds. The temp directory slowly 
filled up and the sleep duration increased to about 11 seconds and stayed 
there, keeping everything in balance. Looking at the task manager I saw the 
checkpoint was hit about every 5 seconds. That's an 11 second sleep every 5 
seconds.

To summarize this is what I did to restore:
* copy the 700 GB backup file to a new temporary AppVM in storage pool *1 *(I 
had to free some space there...) [HDD]
* mount the private storage of this new AppVM to dom0
* modify *restore.py* as described above (added checkpoint, left */var/temp* 
unchanged as temporary location which is on a SSD)
* set the default storage pool to storage pool *2 *[HDD]
* used the "Restore Backup" UI to select the backup file
* start the restore operation and wait until it successfully finished

There were other proposed solutions I did not try:
* dd the old HDD content to a new HDD, make the new Qubes installation 
recognize it
* LVM mirroring
* use Chris' pre-release script
* slow down qfile-dom0-unpacker (<- this solution came in as slowing down 
the tar process was already working)
* attach USB drive to dom0 and restore from there (<- I choose to not 
attach a USB drive)

I would've tried those next had the restore operation with modified 
*restore.py* failed. In my view the out-of-the-box solution has the lowest 
security and maintenance risks.

Thank you to all who helped me getting this done! And good to hear there is 
currently work being done to make this smoother in the future (by Chris & 
Marek - should you synchronize?).

Note: While fiddling around I discovered that the restore operation cannot 
be canceled: https://github.com/QubesOS/qubes-issues/issues/5304

-- 
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/0a61520e-24a7-4dfa-84c0-135873103b5a%40googlegroups.com.

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

['Heinrich Ulbricht' via qubes-users]

On Saturday, September 7, 2019 at 10:54:34 PM UTC+2, Heinrich Ulbricht 
wrote:
>
>
>> 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?
>


Quick update on how it is going: I' got the restore operation in an 
equilibrium now.

THIS is the place to insert the checkpoint operation for the un-tar (line 
913ff in restore.py 

):

tar1_command = ['tar',
'-ixv',
'--occurrence=1',
'--checkpoint=2',
'--checkpoint-action=exec=\'sleep "$(stat -f --format="(((%b-%a)/%b)^5)*30" 
/var/tmp | bc -l)"\'',
'-C', self.tmpdir] + filelist

This seems to be a non-interruptable tar operation that is pushing 
thousands of chunk files into the temp location with the other processes 
having no chance to process them in time. I'll follow up with details.

-- 
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/7c409720-bed9-4198-823a-d1f081d91ed2%40googlegroups.com.

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?

['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?

['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 
<

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

['Heinrich Ulbricht' via qubes-users]

On Sunday, September 1, 2019 at 12:00:20 PM UTC+2, donoban wrote:
>
> On 9/1/19 10:46 AM, 'Heinrich Ulbricht' via qubes-users wrote: 
> > 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? 
> > 
>
> Hi, 
>
> I recently did a hard disk upgrade and reinstall so I followed this same 
> steps. 
>
> Generally it should work fine but in mi experience there is a little 
> issue[1] that can cause additional delay on the process. In steps 6/7, 
> if your destination hard disk is slower than the your main hard disk 
> (where dom0 is installed), your backup will be full extracted on dom0, 
> so you can run out of space if you don't take this in account. 
>
> If your dom0 is smaller than the total amount to extract, you should 
> restore your domains grouping them in a reasonable amount. 
>
> Another way is changing the temporary directory for the restore process 
> but it can not be changed with command arguments. You need to modify 
> 'restore.py' or mount /var/tmp on another device, or use symbolic link. 
>
> [1] https://github.com/QubesOS/qubes-issues/issues/3230 
>

Thank you very much for pointing this out. Sounds like a lot of saved 
troubleshooting time for me as I might run into this.

I think I'm set for the safe path (although the shortcut proposed by Chris 
Laprise sounds tempting). I'll report back how it went.

-- 
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/6c7ef9dc-37cc-43f7-b59e-cc22c3b33355%40googlegroups.com.

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

['Heinrich Ulbricht' via qubes-users]

> 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?

-- 
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/84d1e9c3-d2f6-4262-b3fa-fd62140109d5%40googlegroups.com.

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

['Heinrich Ulbricht' via qubes-users]

I need to move Qubes OS and all VMs to a larger SSD since I'm running low 
on disk space. 

According to the documentation 
 this should be easy:

   1. Backup everything
   2. Install Qubes OS to new SSD
   3. Restore everything
   4. Done.

But my current system has two additional (slower) disks attached for 
storage of larger App VMs (thin storage pools). How do I handle those? I'm 
worried about two scenarios that aren't explicitly mentioned in the 
documentation:

*Scenario A - this is for getting the small SSD replaced by a larger one 
(top priority)*

   - migration of Qubes OS from SSD OLD (the small one) to SSD NEW (larger 
   one)
   - within the same computer
   - leaving the other two disks attached, making no changes to them, 
   leaving the App VMs in place

Will this "just work"?

*Scenario B - a future scenario (lower priority)*

   - restore everything to a new computer with new empty disks
   - while putting the App VMs back to their respective separate disks in 
   the new computer

This scenario I simply did not test yet and the restore UI might provide 
options for this (?). But I did not find documentation about this scenario. 
Any links/hints are appreciated.



How much do I need to worry? What do I need to prepare *in addition* to the 
steps outlined in the documentation 
?

(I'm on Qubes OS v4 latest)

-- 
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/d71f72b0-c229-4184-9441-a5e4dffb9f3a%40googlegroups.com.