Re: [qubes-users] Backup/Restore issue
Yep. When I first installed the apps on the template and afterwards shut it off I saw the apps in the AppVM. The issue happened when I've restored. And, again, I did not reinstall the apps in the template, they were already there. The dnf install command resulted in no change but it somehow "reminded" Qubes they exist and so I could use the again as UI/windows. Regards -- 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/6d44d12a-9c99-4905-966e-cecdf6e5bf24%40googlegroups.com.
Re: [qubes-users] Backup/Restore issue
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 Claudio Chinicz: > Hi, > > I've created an oathtool AppVM following instructions from here: > https://www.qubes-os.org/doc/multifactor-authentication/ > > On the Fedora-30-minimal template I've also installed Nautilus file > manager and Gedit to easy my process of token creation. > > I tested it and it worked as designed. Then I want to test > backup/recovery before I would rely on this to store my tokens. > > To my surprise, when I restored the OTP VM together with it's > template the applications (file manager and text editor) did not > show up as available applications. > > I had to open a terminal on the template and run again dnf install. > Although they were not installed again (because they were present > when I backed up), after running dnf install Qubes "remembered" > they were there as if were notified just then. > > Did I miss something when I backed up? Or is this behaviour > expected? > > Thanks > Are you sure you installed the oathtool and other apps in the Fedora-30 template and not in the AppVM? Once you install the packages in the Fedora-30 template, shutdown the template. Once the template is switched off, start the AppVM based on Fedora-30 and you should see the packages available (in all Fedora-30 AppVMs based on that template). -BEGIN PGP SIGNATURE- iQKTBAEBCgB9FiEExlmPb5HoPUTt+CQT44JZDAWK6UwFAl5972JfFIAALgAo aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldEM2 NTk4RjZGOTFFODNENDRFREY4MjQxM0UzODI1OTBDMDU4QUU5NEMACgkQ44JZDAWK 6Uwriw//TMeDqlPrldYqR/QJa023S19h3LQy0seMqKToFR++YKMJAPg4PP917hJd Ar468AzKTLcP4+UmJd6RXvzMBrMdgJD/NBOXap2mgFUrMrG7CICRSzsJ+hSS8Ze4 +owUQXIWNiTbiNlMii0IBQhpOdRbWa0RG9ocsUabBDZi5IPs0w19MGfelRkHU94Z JjoH3boRgPk2QhzVGh25e5uT2WzLnXSBJRt7IyNdvxJ62BZMdgVDWjKS5nYzoZ6+ swjPjsZyLxkIHeePseGcC1r9FDekIwOhib5Mkak2Dk/WCfNsR7vUpgJ6e/XgTxSH LBC1ul41+eefJ+UWzYs2Xw9giwHCtK7pEWE+elnjoRRRhFNdv2asQogUxiVmYt9g xMivKaNmjhQyV+YQd728mPT9ltnlJvYuJaHwdACeof92AiMt053PApFv5U8HhWMZ JKW/gUymrNsdVpTv3q7+ZFxF3qOfwt3y5Op67dzZ98PHUrum6Rw8G0KtA9y+ZVK9 cxYsgwLfO+xlB36PM+T5notXPTWaa9plP/f0R1JeWsO+WOQMa7f1JFuAkn/gBEzX VhjA1qoVoq7Ge0DHtqJsylyvdoxEq0vaazzrYh8Iori6KgSEp8Msq3b5wPbIQB7Q cCvojwHqrWTBW0NCvoKVWpa4Uv4RSjXJJNwCREsYb8Oco90xYtQ= =BWBq -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/389c65e9-22ef-15c4-dfa5-0c7c7f4a2ba6%40cock.li. 0xC1F4E83AF470A4ED.asc Description: application/pgp-keys
Re: [qubes-users] Backup issues with external USB and ESATA devices
Charles Peters: > In late September I backed up qubes using a new WD Elements external > drive. At the time I don't think I had sys-usb installed. Yesterday when > I tried to do the backups I was unable to mount the WD Elements drive, > another USB connected Toshiba hard drive, or the Toshiba drive connected > with ESATA. I can mount USB flash drives, but with a vfat filesystem it > will not support the large multi GB backup file. > > Booting Debian with the ESATA connected Toshiba drive I can mount the WD > Elements drive without any problems. However I haven't figured out how to > mount the SSD with Qubes OS lvm to copy the backup files. > > Does anyone have any suggestions? Pass the external partition through to a VM with qvm-block, then mount it from inside the VM. -- - don't top post Mailing list etiquette: - trim quoted reply to only relevant portions - when possible, copy and paste text instead of screenshots -- 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/aab9ab93-d1a0-2d00-c576-a58886123409%40danwin1210.me.
Re: [qubes-users] Backup while VMs are running??
On Mon, May 27, 2019 at 11:51:02PM -0700, Claudio Chinicz wrote: > Hi All, > > I make few backups because I fear doing backups while using my VMs, specially > Windows 10 and Linux Mint HVMs. So, I do it once in a while, when I have have > some free time and can spen not using the computer while it prepares the > backups, after having shut down the VMs. > > All the discussion about updates breaking Qubes makes me wonder I should do > backups more often. > > Is it possible to do backups of HVMs and VMs in general while using them? I'm > afraid I may have an issue when restoring. > > Thanks in advance, > Claudio > If you backup a running qube with Qubes backup, it will backup the state before you started it. May or may not be what you want. You can use file backups to capture anything since qube started. btrfs will let you snapshot running systems. -- 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 post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20190528232916.4jmlhu4le4vl2u5x%40thirdeyesecurity.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Backup while VMs are running??
On 5/28/19 2:51 AM, Claudio Chinicz wrote: Hi All, I make few backups because I fear doing backups while using my VMs, specially Windows 10 and Linux Mint HVMs. So, I do it once in a while, when I have have some free time and can spen not using the computer while it prepares the backups, after having shut down the VMs. All the discussion about updates breaking Qubes makes me wonder I should do backups more often. Is it possible to do backups of HVMs and VMs in general while using them? I'm afraid I may have an issue when restoring. If you installed Qubes with the disk/storage defaults, which uses LVM snapshots – or if you manually set it to install with Btrfs – then its safe to backup while VMs are running. The backup will simply use the snapshot from the last time the VM was shut down. OTOH, if you manually changed the Qubes install to use Ext4 filesystem, there might be a problem in that case. The disk usage widget in the system tray will tell you what kind of storage system your Qubes is using; if you used the default LVM it will say "lvm" with the usage stats to the right. -- 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 post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/af598aec-0a29-4f3c-65c2-2216bb16e88e%40posteo.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Backup Error: Warning: unrecognized data found in configuration files
Eccentric Butterfly: Speaking of which, is there really any security benefit in making sure the backup is not connected to a network? Provided the encryption password is secure. I don't think this was mentioned in the docs anywhere as something to consider so it's probably a bit excessive on my part. Of course, provided the password is long and secure. Since all contents of all AppVMs you select pass through your Backup VM, it's a good idea in general to be cautious about attaching it to a network if you don't have to. Same with any other AppVM, really. Security benefit is that it makes it harder to exfiltrate data. -- 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 post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/4c5c021a-8375-5e0a-0cc6-704cc6484e92%40danwin1210.me. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Backup Error: Warning: unrecognized data found in configuration files
On Monday, 6 May 2019 17:14:46 UTC+1, daniel wrote: > On Sun, 5 May 2019 20:24:07 + > "'awokd' via qubes-users" wrote: > > > Eccentric Butterfly: > > > When I go to backup my Qubes, the backup screen shows a red error > > > at the bottom of the window saying "Warning: unrecognized data > > > found in configuration files". > > I ran into this and it was innocuous. Probably you have deleted a qube > that you backed up the last time you ran backup. The system remembers > the choices you made in the last backup and sets them up as the > defaults. So it knows it is supposed to backup a qube that isn't there > anymore. So it says it's confused. You can follow awokd's advice > (the file will be recreated when you run backup; it is where the > previous-backup settings are stored). Or you can just ignore the > message and continue with your backup. I'd delete the file, just in > case something more serious is happening. > > Best Wishes, > Daniel > > > /etc/qubes/backup/qubes-manager-backup.conf" in dom0 terminal. This > > will delete the configuration you saved last time you ran backup. > > > > > Why is this? Is there anything I need to do? Will this have any > > > effect on my ability to backup and restore? > > Haven't seen it before so don't know if it would prevent backups or > > restores. > > Thanks for your reply guys. I think it's a mix of what both of you are saying. When I backup qubes to a hard drive, I make sure the qube is not connected to a network. When I'm done, I usually delete the qube. Though in this case, it wasn't deleted (or I re-made the qube with the same name). but it also wasn't running. When I saw the contents of that file, I realised the path in the 'BACKUP' qube was no longer valid as 1) the qube was not running and 2) the hard drive would not be mounted. Thus, I ran the qube and mounted it and the error was gone. Thanks for your help, it was much appreciated! Butterfly. -- 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 post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/f1d22ab5-6296-47fb-8e7c-eb5fe6ed4243%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Backup Error: Warning: unrecognized data found in configuration files
On Monday, 6 May 2019 22:35:55 UTC+1, Eccentric Butterfly wrote: > On Monday, 6 May 2019 17:14:46 UTC+1, daniel wrote: > > On Sun, 5 May 2019 20:24:07 + > > "'awokd' via qubes-users" wrote: > > > > > Eccentric Butterfly: > > > > When I go to backup my Qubes, the backup screen shows a red error > > > > at the bottom of the window saying "Warning: unrecognized data > > > > found in configuration files". > > > > I ran into this and it was innocuous. Probably you have deleted a qube > > that you backed up the last time you ran backup. The system remembers > > the choices you made in the last backup and sets them up as the > > defaults. So it knows it is supposed to backup a qube that isn't there > > anymore. So it says it's confused. You can follow awokd's advice > > (the file will be recreated when you run backup; it is where the > > previous-backup settings are stored). Or you can just ignore the > > message and continue with your backup. I'd delete the file, just in > > case something more serious is happening. > > > > Best Wishes, > > Daniel > > > > > /etc/qubes/backup/qubes-manager-backup.conf" in dom0 terminal. This > > > will delete the configuration you saved last time you ran backup. > > > > > > > Why is this? Is there anything I need to do? Will this have any > > > > effect on my ability to backup and restore? > > > Haven't seen it before so don't know if it would prevent backups or > > > restores. > > > > > > Thanks for your reply guys. I think it's a mix of what both of you are saying. > > When I backup qubes to a hard drive, I make sure the qube is not connected to > a network. When I'm done, I usually delete the qube. Though in this case, it > wasn't deleted (or I re-made the qube with the same name). but it also wasn't > running. > > When I saw the contents of that file, I realised the path in the 'BACKUP' > qube was no longer valid as 1) the qube was not running and 2) the hard drive > would not be mounted. Thus, I ran the qube and mounted it and the error was > gone. > > Thanks for your help, it was much appreciated! > Butterfly. Speaking of which, is there really any security benefit in making sure the backup is not connected to a network? Provided the encryption password is secure. I don't think this was mentioned in the docs anywhere as something to consider so it's probably a bit excessive on my part. Of course, provided the password is long and secure. -- 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 post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/22534478-c0e4-4428-adcf-35baa15aa4ce%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Backup Error: Warning: unrecognized data found in configuration files
On Sun, 5 May 2019 20:24:07 + "'awokd' via qubes-users" wrote: > Eccentric Butterfly: > > When I go to backup my Qubes, the backup screen shows a red error > > at the bottom of the window saying "Warning: unrecognized data > > found in configuration files". I ran into this and it was innocuous. Probably you have deleted a qube that you backed up the last time you ran backup. The system remembers the choices you made in the last backup and sets them up as the defaults. So it knows it is supposed to backup a qube that isn't there anymore. So it says it's confused. You can follow awokd's advice (the file will be recreated when you run backup; it is where the previous-backup settings are stored). Or you can just ignore the message and continue with your backup. I'd delete the file, just in case something more serious is happening. Best Wishes, Daniel > /etc/qubes/backup/qubes-manager-backup.conf" in dom0 terminal. This > will delete the configuration you saved last time you ran backup. > > > Why is this? Is there anything I need to do? Will this have any > > effect on my ability to backup and restore? > Haven't seen it before so don't know if it would prevent backups or > restores. > -- 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 post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20190506111437.6a563379%40allcock.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Backup Error: Warning: unrecognized data found in configuration files
Eccentric Butterfly: When I go to backup my Qubes, the backup screen shows a red error at the bottom of the window saying "Warning: unrecognized data found in configuration files". Try closing backup, then "rm /etc/qubes/backup/qubes-manager-backup.conf" in dom0 terminal. This will delete the configuration you saved last time you ran backup. Why is this? Is there anything I need to do? Will this have any effect on my ability to backup and restore? Haven't seen it before so don't know if it would prevent backups or restores. -- 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 post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/2d59434f-6304-3753-ab5a-509f2dbc7194%40danwin1210.me. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] backup with debian-10-minimal based sys-usb fails
On 4/15/19 6:25 PM, unman wrote: > Why do you say this? Backup works fine with a buster qube. What is the > exact problem that you have? I apologize. The issue was between chair and keyboard. In Fedora external drives are mounted under /run/media/user and in Debian under /media/user ... sorry for wasting your time. I must have been very tired last time I tried. It all works now. Funny enough all of my qubes are based on modified debian-minimal templates, which makes me very happy as there are no unneeded packages installed. OCD granted. The only qube I have to run with the full debian template is sys-usb. I'll keep searching what is needed (natuilus and qubes-core-agent-nautilus alone are not enough). If I figure it out, I will reply here. Thank you! /Sven -- 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 post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/f9e9494b-303f-0118-54af-226efb419181%40SvenSemmler.org. For more options, visit https://groups.google.com/d/optout. signature.asc Description: OpenPGP digital signature
Re: [qubes-users] backup with debian-10-minimal based sys-usb fails
On Mon, Apr 15, 2019 at 04:23:25PM -0500, Sven Semmler wrote: > On 4/5/19 12:52 AM, Sven Semmler wrote: > >> You could install a file manager but then you're getting closer to > >> the normal Debian template which is pretty minimal. If you are > >> committed to minimal service qubes, CLI backup . > > You convinced me. My intermediate solution will be to run sys-net and > > sys-firewall as named disposable VMs based on a true minimal (not the > > one I messed with, but the original minimal template plus the > > qubes-core-* packets required for networking). And sys-usb as a named > > disposable VM based on the plain debian template. > > Actually with the normal debian template only restore works. Backup has > the same issue even though the file manager and selection comes up. For > the time being I have restored the fedora-29 minimal template just for > sys-usb, but I'd love to find out what packages are required to make it > work ... so I could use a debian based template for sys-usb. > Why do you say this? Backup works fine with a buster qube. What is the exact problem that you have? -- 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 post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20190415232511.cn6dqipm2gwglb6r%40thirdeyesecurity.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] backup with debian-10-minimal based sys-usb fails
On 4/5/19 12:52 AM, Sven Semmler wrote: >> You could install a file manager but then you're getting closer to >> the normal Debian template which is pretty minimal. If you are >> committed to minimal service qubes, CLI backup . > You convinced me. My intermediate solution will be to run sys-net and > sys-firewall as named disposable VMs based on a true minimal (not the > one I messed with, but the original minimal template plus the > qubes-core-* packets required for networking). And sys-usb as a named > disposable VM based on the plain debian template. Actually with the normal debian template only restore works. Backup has the same issue even though the file manager and selection comes up. For the time being I have restored the fedora-29 minimal template just for sys-usb, but I'd love to find out what packages are required to make it work ... so I could use a debian based template for sys-usb. -- 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 post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/e645edf3-cbc0-3087-b7b0-19a07f544a32%40SvenSemmler.org. For more options, visit https://groups.google.com/d/optout. signature.asc Description: OpenPGP digital signature
Re: [qubes-users] backup with debian-10-minimal based sys-usb fails
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 3/31/19 9:36 AM, unman wrote: > 1. The minimal template is minimal - it doenst have any GUI file > manager. When you click on the ... button it spawns a file manager > in the backup qube. Since you dont have one installed it cant be > opened. I neglected to mention that I did install nautilus for that very reason. > You could install a file manager but then you're getting closer to > the normal Debian template which is pretty minimal. If you are > committed to minimal service qubes, CLI backup . You convinced me. My intermediate solution will be to run sys-net and sys-firewall as named disposable VMs based on a true minimal (not the one I messed with, but the original minimal template plus the qubes-core-* packets required for networking). And sys-usb as a named disposable VM based on the plain debian template. Soon though I will understand the CLI for backup and restore and automate my backups using a shell script. Then sys-usb will be like sys-net and sys-firewall already are. Thank you for your help! /Sven -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEE18ry22WNibwI1qeq2m4We49UH7YFAlym7RQACgkQ2m4We49U H7bMpg//XeEzn1KGpgVWGK4MCekQ2RuJXNJItOsdnnGK4yxDHbPIEewdP4EIl+ZW /+jwoTsWXHImpSJBaaFCWBayZwhOgyUaLVBT08GGd6P6hbNYBxiOG2qdrPrCEsds XlVfwgfPTKIVVKn2poegzZ/762c/kPa5E1aL+nB+UqCzO05kuXoH720HpVcTmywW ig6bOeuXlowOrLMXgUKsHaA111WmEfrbReVDDzf25xrZukPiFX7FhIKT3wQfGdSf Z+wFvL+7CEvk4WBBR5PA2y8mx5BSXiYVOuR4zKPI9yXVhZnc5QkrB9lp3LljcIqA TF6VfsYyAYYjg7rmEe7i72gzUf8eAbXvKXvZUzfJ3cblRUxAKIdUU/rCRUJS2QvX 5gR+y4XFG4ZXit3LNxqRmi0G1aL0haSvnGWhykeTK+q7Jclym9sInabuoKs+zme4 Tu2wg7Exkvx6kJ9+DRn1DhVyi1CPAJP6dXHsqnVhy6/xpSfulMPsqugW8EngcdsK 8xYKQfO2N1ddTI6qlljeE/PLDPPsgyPW0wk0/dHadOfFQ9FrdSYV1H3ZDxfRozEH HjL8DmXuwpgEash748pb0KQgbEGRBorUGTRWVD6RtXgBpDu15ME0MwF7DYiYMC9V FFWPHAin1hMI3jLC+TaPRnNlkC7CPXLmKCxpBHEY2jzj3YqhOew= =ZgVG -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 post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/2680f942-0284-d929-9b51-01226087e07e%40SvenSemmler.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] backup with debian-10-minimal based sys-usb fails
On 3/31/19 10:36 AM, unman wrote: I'm not convinced about Debian packages being more secure than rpm: they are, of course nicer. :-) To me, its a matter of Fedora packages being less secure than *everyone else*. I'm a long standing Debian user with an antipathy to RedHat and Fedora. The biggest drawback in using Debian packages in Qubes is that they are configured on install, which requires some user intervention across various qubes. Fedora doesnt do this, I think. Shouldn't it be possible to run 'apt' in a mode where it accepts the default (not always 'yes') response? The qubes-multi-update script already does this when run in unattended mode and I've never had a problem with it, even in highly customized Debian templates. -- 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 post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/f3075d83-a02e-f49d-abc8-76ffc4bfed3d%40posteo.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] backup with debian-10-minimal based sys-usb fails
On Sun, Mar 31, 2019 at 01:10:14AM -0500, Sven Semmler wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > Very recently I migrated all my AppVMs to a debian-10 (buster) > template, which itself was created by upgrading the debian-9 template. > > Equally my sys-net, sys-usb and sys-firewall dispvms are based on a > debian-10-minimal, which was upgraded from the debian-9-minimal. There > was one little hick-up with the qubes-update-proxy (tinyproxy), but > unman quickly pointed out what needed to be done. > > Now I have only 2 things left that don't work as before: > > 1) Currently I can't backup. I never tried the CLI way and will do so > soon. Until now I always used the qubes manager. However, since my > sys-usb is based on the minimal debian-10 template ... it doesn't work > anymore. When I want to make a backup I simply get a message that the > backup is not running. Also, in both cases (making and restoring > backup) the dialog that lets me select target/source doesn't show up > anymore after clicking the "..." button. > > I searched qubes-users and qubes-issue and did install the > qubes-core-admin-client in the template but that alone doesn't do the > trick. What could my next step be? Which log file to check? Any idea > what could be missing? (If I switch back to the fedora-minimal based > sys-usb it works). > > 2) When selecting what to backup I am used to see sys-net(0), > sys-usb(0) and sys-firewall(0) and exclude them. They are of size zero > as they are named disposable vms. However now I see both sys-net and > sys-firewall having a size (~30 MB slowly increasing day by day !?!) > But they are of class DispVM and are based on dvm-sys which in turn is > based on the minimal debian template. What could be going on here? > > Why am I doing this? ... over the last few months I have formed the > impression that some of the more knowledgeable contributors on > qubes-users (e.g. unman and tasket) prefer debian. And I do get > annoyed be the super frequent updates of fedora. So I thought I'd try > out to switch everything to debian in the hope that I would then have > templates that can stay in use for many months if not years before I > need to switch again (I went through fedora 24-29 since using qubes). > Also another person with linux background said something about the > debian package format being better and more secure against > man-in-the-middle attacks (haven't researched that claim myself yet). > > If anyone has information to confirm or disabuse me of the above > impressions, I am all ears. > > Thank you! > > -BEGIN PGP SIGNATURE- > > iQIzBAEBCgAdFiEE18ry22WNibwI1qeq2m4We49UH7YFAlygWcYACgkQ2m4We49U > H7ZhABAA4gEFBVqImM+Xr7yjHKqJ1NC+kJez7yBUSxxPfRPoZhzoFuRJxlsSrit4 > Bkglan0auyqDWQLaUjMwy3NWJQpxvBQuv/1HpQN1q3FuZoKw0giCT1ZkZ+FhvOwv > UsjmyiXdOmPSCXeejDLAhuwX1ZmUEV1JuLxAnexswEMe1QZV1N8Qa1DwwFG5XoEw > SXYLXKgZceTT/OQXh8CZhiKCAEKEOX38U86w0OXVdNH4oSPcoLy14MAXa0WlDukk > 7QXeh4kPfsOx9hWxtQMKJ3Lyw4kxZoTvXFOGzUx94WyGRuuTQpru8CQJywAdM0Xe > sTbOmxyQAeH5ABY9ZUsO/I4BTq34uSpLEFDirNQ7FnK+vcG2MwdjnSP7xdDR1Iom > Hw4sRhvlnJzWxFuZVoT2F2dLKnNd833d6zy4xyiy2h0LkHETDyo4Oprp5uVDrJPk > 1J43eZHBdHF+YjAREwC1/JPkfbGWOx1q5KpVE3TtQpOf82kLjJNWBqaERyEY1J/e > QAAnRPbXI1LNUYazOkJ1Qv992gsyglHPDqdQtl+g8bKudRznvdoEr+kLyn1uduF9 > A7IUT1Ctk+NVyA7N9msjSCdzPiANCIdMddqL94zvpRuSaRTK7qRUN7z5fspt3XZb > 3NPvTTh0hRinNh7c1rrzLdnJfb/0QDl9bX6touxhuOOdkYwAgAE= > =Ujwj > -END PGP SIGNATURE- > 1. The minimal template is minimal - it doenst have any GUI file manager. When you click on the ... button it spawns a file manager in the backup qube. Since you dont have one installed it cant be opened. You could install a file manager but then you're getting closer to the normal Debian template which is pretty minimal. If you are committed to minimal service qubes, CLI backup . 2. DisposableVMs will still have *some* size, as they differ from the underlying template. When they are closed those differences will be thrown away. (Just as you can download an iso in a disposableVM and see the size balloon.) I dont know what exactly is happening in your case - logs perhaps? I'm not convinced about Debian packages being more secure than rpm: they are, of course nicer. :-) I'm a long standing Debian user with an antipathy to RedHat and Fedora. The biggest drawback in using Debian packages in Qubes is that they are configured on install, which requires some user intervention across various qubes. Fedora doesnt do this, I think. -- 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 post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20190331143618.o32x7fhqkof7xfxl%40thirdeyesecurity.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] backup of files in a qube without networking to an internet service
On Tue, Feb 19, 2019 at 03:41:23PM +, lik...@gmx.de wrote: > Hi, > > assume there are files stored in a qube without networking. Furthermore > assume there's a secured backup server located in the internet. This server > is only a storage of client-side (before data is sent over the wire) > encrypted files. What options do you imagine to backup those files (skip the > client-side encryption) to the server? > > I can imagine the following options: > 1. enable temporary the network with firewall restricted to the server for > the (previously offline) qube > Advantage: no inter-vm copying of files. > Disadvantage: firewall rules must be setup correctly to avoid to bypass > any other traffic like icmp/dns etc. I can imaging a potential information > leakage due to enabling network access. > 2. copy files temporary to another qube (dvm?) with a firewalled internet > connection > Advantage: files not being backed up can stay secured in the non-network > cube. Leakage of data is reduced in comparison to 1. > Disadvantage: can take time and needs additional disk ressources > > I've learned that you should always find at least 3 options, otherwise you > haven't thought hard enough. Which options am I missing? > > Which option would you prefer and why? > > Best, Pete 3. Create encrypted (compressed) backup in offline qube. qvm-copy backup to online disposableVM. Copy encrypted file to backup server. Advantage: All files secured in non-network qube. Disadvantage: ??? Is inter-vm copying of files really an issue? Free space such an issue? Using compressed backups should help mitigate this as a serious issue, but that problem would extend to *all* your Qubes use. unman -- 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 post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20190220004623.q5vg6vwzhg3r5fv6%40thirdeyesecurity.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] backup of files in a qube without networking to an internet service
On 2/19/19 10:41 AM, lik...@gmx.de wrote: Hi, assume there are files stored in a qube without networking. Furthermore assume there's a secured backup server located in the internet. This server is only a storage of client-side (before data is sent over the wire) encrypted files. What options do you imagine to backup those files (skip the client-side encryption) to the server? I can imagine the following options: 1. enable temporary the network with firewall restricted to the server for the (previously offline) qube Advantage: no inter-vm copying of files. Disadvantage: firewall rules must be setup correctly to avoid to bypass any other traffic like icmp/dns etc. I can imaging a potential information leakage due to enabling network access. 2. copy files temporary to another qube (dvm?) with a firewalled internet connection Advantage: files not being backed up can stay secured in the non-network cube. Leakage of data is reduced in comparison to 1. Disadvantage: can take time and needs additional disk ressources I've learned that you should always find at least 3 options, otherwise you haven't thought hard enough. Which options am I missing? Which option would you prefer and why? Another disadvantage of #1 is that connecting the net to the source qube exposes it to attack. Had you thought about using qvm-backup? Also, I'm working on a fast incremental backup tool that's suitable for Qubes: https://github.com/tasket/sparsebak -- 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 post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/cfdd9ce7-b95b-f26a-5cf9-19e0df29d70d%40posteo.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Backup stops when the backup file reaches 3Gb
On Fri, 25 Jan 2019 13:52:55 + Mike Keehan wrote: > On Thu, 24 Jan 2019 11:29:50 + > unman wrote: > > > On Thu, Jan 24, 2019 at 01:00:15AM -0500, Chris Laprise wrote: > > > On 01/23/2019 08:15 PM, js...@bitmessage.ch wrote: > > > > Mike Keehan: > > > > > Hi, > > > > > > > > > > I'm using Qubes Backup to save some of my qubes into another > > > > > VM. The backup VM has 18 Gb of storage available, but > > > > > whenever the backup file reaches 3Gb, the backup process just > > > > > hangs. > > > > > > > > > > No CPU usage, no error messages, just stops. The backup > > > > > window shows 40% complete, but never moves any further > > > > > (different % for different combinations of qubes in the > > > > > backup list). > > > > > > > > > > After waiting a considerable time (well, 5-10 minutes), > > > > > hitting Cancel in the backup window does cancel it. The rest > > > > > of the system is continuing to work without problem. Happens > > > > > every time I try to use Qubes backup. > > > > > > > > > > The Qubes Disk Space widget shows less than 50% disk used > > > > > overall, the backupVM shows only 18% disk used when the 3Gb > > > > > file has been saved. > > > > > > > > > > I'm stumped. > > > > > > > > > > Mike. > > > > > > > > Hi, > > > > > > > > You may have to wait longer than 5-10 minutes. I experience > > > > something similar when doing a full backup, except it's worse > > > > because i'm backing up like 2.5TB. It appears to hang for > > > > several hours at a time (and this happens more than once), but > > > > it does eventually make visible progress again. The whole > > > > process takes over 24 hours. This is why i do full backups very > > > > infrequently. > > > > > > > > For you it shouldn't take nearly as long because it's a lot less > > > > data, but the progress appearing to hang for a while seems to be > > > > normal. > > > > > > > > I'm using 3.2 tho, and i know they made changes to the backup > > > > mechanism under the hood in 4.0, so i'm not sure if this issue > > > > still applies in 4.0. > > > > > > Marek, > > > > > > Isn't this the null bytes bug in GNU tar? > > > > > > https://groups.google.com/d/msgid/qubes-users/f4d997d5-7191-06d0-e7bb-ef42745a7db5%40posteo.net > > > > > > It would be a good idea to update this in dom0. My own backup tool > > > uses GNU tar as well. > > > > > > -- > > > > > > Chris Laprise, tas...@posteo.net > > > https://github.com/tasket > > > https://twitter.com/ttaskett > > > PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886 > > > > It seems a little early to judge. > > > > Mike - it looks from your comment as if you have been trying with > > subsets of the qubes? Can you confirm if these are running or > > stopped. > > > > Like jsnow, I'm regularly able to backup far more than 3G without > > issue, so it looks as if there's something particular about this > > scenario. It would be helpful if you could confirm the issue when > > all qubes you are backing up are stopped. > > Then try bisecting the qubes backup group - keep bisecting if you > > hit the problem again until you either find the problematic qubes > > or have backed them all up. > > > > OK, progress:) > > I can backup a list of stopped qubes, running out to a 10Gb file > without any issues. They all verify OK too. However, backing up > running qubes exhibits the problem. > > Starting up one of these qubes and trying to backup causes the > progress indicator to stop at some point, BUT, the data is still > being backed up to disk, and continues flowing for some time. When > the data flow stops, then I have to cancel the backup operation. > However, verifying the backup works OK - file size reported is > correct, and the verify process finishes successfully. I haven't > tried to actually restore one of these yet. > > I tried recording the process status of both dom0 and the backup vm > during the backups, but could not see any particular process dying > when the progress updater stopped moving. The tar processes stopped > in dom0 but I guess that was because they had finished creating the > private.img files. > > So it looks like backing up a live VM causes the backup process to > fail at some point, but not before the data is actually backed up. > > It doesn't look like a tar null issue as the data does get to disk OK. > It's just the control of the backup process getting out of step > somewhere. > > Mike. > I'm trying to debug the backup halting part way when backing up a running VM. (I have restored one of these backups successfully!) The backup.py script shows a debug log can be produced, but I can't find it - do I have to turn it on somehow? Mike. -- 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 post to this group, send email to qubes-users
Re: [qubes-users] Backup stops when the backup file reaches 3Gb
On Thu, 24 Jan 2019 11:29:50 + unman wrote: > On Thu, Jan 24, 2019 at 01:00:15AM -0500, Chris Laprise wrote: > > On 01/23/2019 08:15 PM, js...@bitmessage.ch wrote: > > > Mike Keehan: > > > > Hi, > > > > > > > > I'm using Qubes Backup to save some of my qubes into another VM. > > > > The backup VM has 18 Gb of storage available, but whenever the > > > > backup file reaches 3Gb, the backup process just hangs. > > > > > > > > No CPU usage, no error messages, just stops. The backup window > > > > shows 40% complete, but never moves any further (different % for > > > > different combinations of qubes in the backup list). > > > > > > > > After waiting a considerable time (well, 5-10 minutes), hitting > > > > Cancel in the backup window does cancel it. The rest of the > > > > system is continuing to work without problem. Happens every > > > > time I try to use Qubes backup. > > > > > > > > The Qubes Disk Space widget shows less than 50% disk used > > > > overall, the backupVM shows only 18% disk used when the 3Gb > > > > file has been saved. > > > > > > > > I'm stumped. > > > > > > > > Mike. > > > > > > Hi, > > > > > > You may have to wait longer than 5-10 minutes. I experience > > > something similar when doing a full backup, except it's worse > > > because i'm backing up like 2.5TB. It appears to hang for several > > > hours at a time (and this happens more than once), but it does > > > eventually make visible progress again. The whole process takes > > > over 24 hours. This is why i do full backups very infrequently. > > > > > > For you it shouldn't take nearly as long because it's a lot less > > > data, but the progress appearing to hang for a while seems to be > > > normal. > > > > > > I'm using 3.2 tho, and i know they made changes to the backup > > > mechanism under the hood in 4.0, so i'm not sure if this issue > > > still applies in 4.0. > > > > Marek, > > > > Isn't this the null bytes bug in GNU tar? > > > > https://groups.google.com/d/msgid/qubes-users/f4d997d5-7191-06d0-e7bb-ef42745a7db5%40posteo.net > > > > It would be a good idea to update this in dom0. My own backup tool > > uses GNU tar as well. > > > > -- > > > > Chris Laprise, tas...@posteo.net > > https://github.com/tasket > > https://twitter.com/ttaskett > > PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886 > > It seems a little early to judge. > > Mike - it looks from your comment as if you have been trying with > subsets of the qubes? Can you confirm if these are running or stopped. > > Like jsnow, I'm regularly able to backup far more than 3G without > issue, so it looks as if there's something particular about this > scenario. It would be helpful if you could confirm the issue when all > qubes you are backing up are stopped. > Then try bisecting the qubes backup group - keep bisecting if you hit > the problem again until you either find the problematic qubes or have > backed them all up. > OK, progress:) I can backup a list of stopped qubes, running out to a 10Gb file without any issues. They all verify OK too. However, backing up running qubes exhibits the problem. Starting up one of these qubes and trying to backup causes the progress indicator to stop at some point, BUT, the data is still being backed up to disk, and continues flowing for some time. When the data flow stops, then I have to cancel the backup operation. However, verifying the backup works OK - file size reported is correct, and the verify process finishes successfully. I haven't tried to actually restore one of these yet. I tried recording the process status of both dom0 and the backup vm during the backups, but could not see any particular process dying when the progress updater stopped moving. The tar processes stopped in dom0 but I guess that was because they had finished creating the private.img files. So it looks like backing up a live VM causes the backup process to fail at some point, but not before the data is actually backed up. It doesn't look like a tar null issue as the data does get to disk OK. It's just the control of the backup process getting out of step somewhere. Mike. -- 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 post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20190125135255.23ddcca0.mike%40keehan.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Backup stops when the backup file reaches 3Gb
On Thu, 24 Jan 2019 11:27:00 -0500 Chris Laprise wrote: > On 01/24/2019 06:29 AM, unman wrote: > > On Thu, Jan 24, 2019 at 01:00:15AM -0500, Chris Laprise wrote: > >> On 01/23/2019 08:15 PM, js...@bitmessage.ch wrote: > >>> Mike Keehan: > Hi, > > I'm using Qubes Backup to save some of my qubes into another VM. > The backup VM has 18 Gb of storage available, but whenever the > backup file reaches 3Gb, the backup process just hangs. > > No CPU usage, no error messages, just stops. The backup window > shows 40% complete, but never moves any further (different % for > different combinations of qubes in the backup list). > > After waiting a considerable time (well, 5-10 minutes), hitting > Cancel in the backup window does cancel it. The rest of the > system is continuing to work without problem. Happens every > time I try to use Qubes backup. > > The Qubes Disk Space widget shows less than 50% disk used > overall, the backupVM shows only 18% disk used when the 3Gb file > has been saved. > > I'm stumped. > > Mike. > >>> > >>> Hi, > >>> > >>> You may have to wait longer than 5-10 minutes. I experience > >>> something similar when doing a full backup, except it's worse > >>> because i'm backing up like 2.5TB. It appears to hang for several > >>> hours at a time (and this happens more than once), but it does > >>> eventually make visible progress again. The whole process takes > >>> over 24 hours. This is why i do full backups very infrequently. > >>> > >>> For you it shouldn't take nearly as long because it's a lot less > >>> data, but the progress appearing to hang for a while seems to be > >>> normal. > >>> > >>> I'm using 3.2 tho, and i know they made changes to the backup > >>> mechanism under the hood in 4.0, so i'm not sure if this issue > >>> still applies in 4.0. > >> > >> Marek, > >> > >> Isn't this the null bytes bug in GNU tar? > >> > >> https://groups.google.com/d/msgid/qubes-users/f4d997d5-7191-06d0-e7bb-ef42745a7db5%40posteo.net > >> > >> It would be a good idea to update this in dom0. My own backup tool > >> uses GNU tar as well. > >> > >> -- > >> > >> Chris Laprise, tas...@posteo.net > >> https://github.com/tasket > >> https://twitter.com/ttaskett > >> PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886 > > > > It seems a little early to judge. > > > > Mike - it looks from your comment as if you have been trying with > > subsets of the qubes? Can you confirm if these are running or > > stopped. > > > > Like jsnow, I'm regularly able to backup far more than 3G without > > issue, so it looks as if there's something particular about this > > scenario. It would be helpful if you could confirm the issue when > > all qubes you are backing up are stopped. > > Then try bisecting the qubes backup group - keep bisecting if you > > hit the problem again until you either find the problematic qubes > > or have backed them all up. > > > > Oops, I pasted the wrong link. Here is the correct one: > > https://utcc.utoronto.ca/~cks/space/blog/sysadmin/TarFindingTruncateBug > > The symptoms sound remarkably the same... potentially hours-long > delays with no adverse effect on data. Trigger condition is not about > size, but due to corner cases that involve backing up nulls. > I left a backup running before I left home this morning - it was stuck at 1.8Gb then (confirming that size is not the issue), and it was still at 1.8Gb when I got home this evening. That was about 8 hours or so. I have a recollection from my dim and distant past, that I had a similar stuck tar issue when it could not handle fifos. Not Linux in those days. There is no mention of fifos (or sockets etc.) in the tar manpage, so I don't know if gnu tar is supposed to handle them or not. I had to use cpio to backup systems which contained those things. Anyway, I'll investigate further tomorrow. You have given me a number of things to look into. Thanks, Mike. -- 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 post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20190124193856.01f80d02.mike%40keehan.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Backup stops when the backup file reaches 3Gb
On Thu, 24 Jan 2019 11:27:00 -0500 Chris Laprise wrote: > On 01/24/2019 06:29 AM, unman wrote: > > On Thu, Jan 24, 2019 at 01:00:15AM -0500, Chris Laprise wrote: > >> On 01/23/2019 08:15 PM, js...@bitmessage.ch wrote: > >>> Mike Keehan: > Hi, > > I'm using Qubes Backup to save some of my qubes into another VM. > The backup VM has 18 Gb of storage available, but whenever the > backup file reaches 3Gb, the backup process just hangs. > > No CPU usage, no error messages, just stops. The backup window > shows 40% complete, but never moves any further (different % for > different combinations of qubes in the backup list). > > After waiting a considerable time (well, 5-10 minutes), hitting > Cancel in the backup window does cancel it. The rest of the > system is continuing to work without problem. Happens every > time I try to use Qubes backup. > > The Qubes Disk Space widget shows less than 50% disk used > overall, the backupVM shows only 18% disk used when the 3Gb file > has been saved. > > I'm stumped. > > Mike. > >>> > >>> Hi, > >>> > >>> You may have to wait longer than 5-10 minutes. I experience > >>> something similar when doing a full backup, except it's worse > >>> because i'm backing up like 2.5TB. It appears to hang for several > >>> hours at a time (and this happens more than once), but it does > >>> eventually make visible progress again. The whole process takes > >>> over 24 hours. This is why i do full backups very infrequently. > >>> > >>> For you it shouldn't take nearly as long because it's a lot less > >>> data, but the progress appearing to hang for a while seems to be > >>> normal. > >>> > >>> I'm using 3.2 tho, and i know they made changes to the backup > >>> mechanism under the hood in 4.0, so i'm not sure if this issue > >>> still applies in 4.0. > >> > >> Marek, > >> > >> Isn't this the null bytes bug in GNU tar? > >> > >> https://groups.google.com/d/msgid/qubes-users/f4d997d5-7191-06d0-e7bb-ef42745a7db5%40posteo.net > >> > >> It would be a good idea to update this in dom0. My own backup tool > >> uses GNU tar as well. > >> > >> -- > >> > >> Chris Laprise, tas...@posteo.net > >> https://github.com/tasket > >> https://twitter.com/ttaskett > >> PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886 > > > > It seems a little early to judge. > > > > Mike - it looks from your comment as if you have been trying with > > subsets of the qubes? Can you confirm if these are running or > > stopped. > > > > Like jsnow, I'm regularly able to backup far more than 3G without > > issue, so it looks as if there's something particular about this > > scenario. It would be helpful if you could confirm the issue when > > all qubes you are backing up are stopped. > > Then try bisecting the qubes backup group - keep bisecting if you > > hit the problem again until you either find the problematic qubes > > or have backed them all up. > > > > Oops, I pasted the wrong link. Here is the correct one: > > https://utcc.utoronto.ca/~cks/space/blog/sysadmin/TarFindingTruncateBug > > The symptoms sound remarkably the same... potentially hours-long > delays with no adverse effect on data. Trigger condition is not about > size, but due to corner cases that involve backing up nulls. > Thanks to all of you !! I've been out today, but will have a look at tracking down the culprit tomorrow:) Mike. -- 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 post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20190124184812.24128610.mike%40keehan.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Backup stops when the backup file reaches 3Gb
On 01/24/2019 06:29 AM, unman wrote: On Thu, Jan 24, 2019 at 01:00:15AM -0500, Chris Laprise wrote: On 01/23/2019 08:15 PM, js...@bitmessage.ch wrote: Mike Keehan: Hi, I'm using Qubes Backup to save some of my qubes into another VM. The backup VM has 18 Gb of storage available, but whenever the backup file reaches 3Gb, the backup process just hangs. No CPU usage, no error messages, just stops. The backup window shows 40% complete, but never moves any further (different % for different combinations of qubes in the backup list). After waiting a considerable time (well, 5-10 minutes), hitting Cancel in the backup window does cancel it. The rest of the system is continuing to work without problem. Happens every time I try to use Qubes backup. The Qubes Disk Space widget shows less than 50% disk used overall, the backupVM shows only 18% disk used when the 3Gb file has been saved. I'm stumped. Mike. Hi, You may have to wait longer than 5-10 minutes. I experience something similar when doing a full backup, except it's worse because i'm backing up like 2.5TB. It appears to hang for several hours at a time (and this happens more than once), but it does eventually make visible progress again. The whole process takes over 24 hours. This is why i do full backups very infrequently. For you it shouldn't take nearly as long because it's a lot less data, but the progress appearing to hang for a while seems to be normal. I'm using 3.2 tho, and i know they made changes to the backup mechanism under the hood in 4.0, so i'm not sure if this issue still applies in 4.0. Marek, Isn't this the null bytes bug in GNU tar? https://groups.google.com/d/msgid/qubes-users/f4d997d5-7191-06d0-e7bb-ef42745a7db5%40posteo.net It would be a good idea to update this in dom0. My own backup tool uses GNU tar as well. -- Chris Laprise, tas...@posteo.net https://github.com/tasket https://twitter.com/ttaskett PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886 It seems a little early to judge. Mike - it looks from your comment as if you have been trying with subsets of the qubes? Can you confirm if these are running or stopped. Like jsnow, I'm regularly able to backup far more than 3G without issue, so it looks as if there's something particular about this scenario. It would be helpful if you could confirm the issue when all qubes you are backing up are stopped. Then try bisecting the qubes backup group - keep bisecting if you hit the problem again until you either find the problematic qubes or have backed them all up. Oops, I pasted the wrong link. Here is the correct one: https://utcc.utoronto.ca/~cks/space/blog/sysadmin/TarFindingTruncateBug The symptoms sound remarkably the same... potentially hours-long delays with no adverse effect on data. Trigger condition is not about size, but due to corner cases that involve backing up nulls. -- 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 post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/e7181586-a839-0f44-f7a5-1d1d654f5d58%40posteo.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Backup stops when the backup file reaches 3Gb
On Thu, Jan 24, 2019 at 01:00:15AM -0500, Chris Laprise wrote: > On 01/23/2019 08:15 PM, js...@bitmessage.ch wrote: > > Mike Keehan: > > > Hi, > > > > > > I'm using Qubes Backup to save some of my qubes into another VM. > > > The backup VM has 18 Gb of storage available, but whenever the > > > backup file reaches 3Gb, the backup process just hangs. > > > > > > No CPU usage, no error messages, just stops. The backup window > > > shows 40% complete, but never moves any further (different % for > > > different combinations of qubes in the backup list). > > > > > > After waiting a considerable time (well, 5-10 minutes), hitting > > > Cancel in the backup window does cancel it. The rest of the > > > system is continuing to work without problem. Happens every > > > time I try to use Qubes backup. > > > > > > The Qubes Disk Space widget shows less than 50% disk used overall, > > > the backupVM shows only 18% disk used when the 3Gb file has been > > > saved. > > > > > > I'm stumped. > > > > > > Mike. > > > > Hi, > > > > You may have to wait longer than 5-10 minutes. I experience something > > similar when doing a full backup, except it's worse because i'm backing > > up like 2.5TB. It appears to hang for several hours at a time (and this > > happens more than once), but it does eventually make visible progress > > again. The whole process takes over 24 hours. This is why i do full > > backups very infrequently. > > > > For you it shouldn't take nearly as long because it's a lot less data, > > but the progress appearing to hang for a while seems to be normal. > > > > I'm using 3.2 tho, and i know they made changes to the backup mechanism > > under the hood in 4.0, so i'm not sure if this issue still applies in > > 4.0. > > Marek, > > Isn't this the null bytes bug in GNU tar? > > https://groups.google.com/d/msgid/qubes-users/f4d997d5-7191-06d0-e7bb-ef42745a7db5%40posteo.net > > It would be a good idea to update this in dom0. My own backup tool uses GNU > tar as well. > > -- > > Chris Laprise, tas...@posteo.net > https://github.com/tasket > https://twitter.com/ttaskett > PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886 It seems a little early to judge. Mike - it looks from your comment as if you have been trying with subsets of the qubes? Can you confirm if these are running or stopped. Like jsnow, I'm regularly able to backup far more than 3G without issue, so it looks as if there's something particular about this scenario. It would be helpful if you could confirm the issue when all qubes you are backing up are stopped. Then try bisecting the qubes backup group - keep bisecting if you hit the problem again until you either find the problematic qubes or have backed them all up. -- 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 post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20190124112950.ldybghvvpc5jham4%40thirdeyesecurity.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Backup stops when the backup file reaches 3Gb
On 01/23/2019 08:15 PM, js...@bitmessage.ch wrote: Mike Keehan: Hi, I'm using Qubes Backup to save some of my qubes into another VM. The backup VM has 18 Gb of storage available, but whenever the backup file reaches 3Gb, the backup process just hangs. No CPU usage, no error messages, just stops. The backup window shows 40% complete, but never moves any further (different % for different combinations of qubes in the backup list). After waiting a considerable time (well, 5-10 minutes), hitting Cancel in the backup window does cancel it. The rest of the system is continuing to work without problem. Happens every time I try to use Qubes backup. The Qubes Disk Space widget shows less than 50% disk used overall, the backupVM shows only 18% disk used when the 3Gb file has been saved. I'm stumped. Mike. Hi, You may have to wait longer than 5-10 minutes. I experience something similar when doing a full backup, except it's worse because i'm backing up like 2.5TB. It appears to hang for several hours at a time (and this happens more than once), but it does eventually make visible progress again. The whole process takes over 24 hours. This is why i do full backups very infrequently. For you it shouldn't take nearly as long because it's a lot less data, but the progress appearing to hang for a while seems to be normal. I'm using 3.2 tho, and i know they made changes to the backup mechanism under the hood in 4.0, so i'm not sure if this issue still applies in 4.0. Marek, Isn't this the null bytes bug in GNU tar? https://groups.google.com/d/msgid/qubes-users/f4d997d5-7191-06d0-e7bb-ef42745a7db5%40posteo.net It would be a good idea to update this in dom0. My own backup tool uses GNU tar as well. -- 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 post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/54678bc8-8091-fb49-92ac-7ad1b59e42d4%40posteo.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Backup stops when the backup file reaches 3Gb
Mike Keehan: Hi, I'm using Qubes Backup to save some of my qubes into another VM. The backup VM has 18 Gb of storage available, but whenever the backup file reaches 3Gb, the backup process just hangs. No CPU usage, no error messages, just stops. The backup window shows 40% complete, but never moves any further (different % for different combinations of qubes in the backup list). After waiting a considerable time (well, 5-10 minutes), hitting Cancel in the backup window does cancel it. The rest of the system is continuing to work without problem. Happens every time I try to use Qubes backup. The Qubes Disk Space widget shows less than 50% disk used overall, the backupVM shows only 18% disk used when the 3Gb file has been saved. I'm stumped. Mike. Hi, You may have to wait longer than 5-10 minutes. I experience something similar when doing a full backup, except it's worse because i'm backing up like 2.5TB. It appears to hang for several hours at a time (and this happens more than once), but it does eventually make visible progress again. The whole process takes over 24 hours. This is why i do full backups very infrequently. For you it shouldn't take nearly as long because it's a lot less data, but the progress appearing to hang for a while seems to be normal. I'm using 3.2 tho, and i know they made changes to the backup mechanism under the hood in 4.0, so i'm not sure if this issue still applies in 4.0. -- Jackie -- 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 post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/5406576f-66c0-3af8-d74e-fbb6b9d4a952%40bitmessage.ch. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] BACKUP IMPORTANT VMS Q4
> Mount to a live system or use the install disk and use rescue mode. > I'm assuming that you have something like a standard install on /dev/sda > (boot in /dev/sda1 and data in /dev/sda2?) > You can check this from the prompt by running cfdisk /dev/sda, to see > how the disk is configured. > Once you know how the disk is configured, use lvm tools to dig into it. > lvmdiskscan will show you the volumes. > lvscan will show you the status of the drives. > lvdisplay will show you the LV and VG names. > > vgchange -ay will make the volumes active, and lvscan should then show > you the appropriate volumes: > /dev/qubes_dom0/root > > Then you should be able to mount /dev/qubes_dom0/root and back up the VM > data from there. > > If you need more help or something doesnt look right, just ask. > (Cloning the disk was a good move, and would have been my first bit of > advice.) Thank you, you solved my problem, i can mount the disk now What should i backup? I mounted: /dev/qubes_dom0/root, went to /var/lib/qubes/appvms/ and it shows all my vms, but i open any folder and theres only 2 files: Firewall.xml, and icon.png What should i backup? Is there another folder i can get the files from my vms? Thank you, i will make a backup using qubes so this doesnt happen 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 qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/0b44ae29-28b3-4eb6-a033-403f1ec04867%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] BACKUP IMPORTANT VMS Q4
On Fri, Dec 21, 2018 at 09:52:29PM -0800, amap...@gmail.com wrote: > Hello, im using qubes os 4, i updated all the VMs + updated dom0 > When i turned on my pc, Qubes os didnt get recognized at boot menu, i have > tried a lot of things and now im tired, i just want to backup my vms and i > will make a fresh install. I have saw a lot of tutorials but im not that > familiar with disk partitions, logical volumes etc. Can someone please tell > me step by step how to backup the important vms? I have tried mounting the > drive to a live system but i cant mount it, i always get this issue: mount: > /mnt: unknown filesystem type 'LVM2_member'. > > Encrypted partition with all vm data: /dev/sda > > I cloned the disk in case something goes wrong. > Hope you can help me! > Mount to a live system or use the install disk and use rescue mode. I'm assuming that you have something like a standard install on /dev/sda (boot in /dev/sda1 and data in /dev/sda2?) You can check this from the prompt by running cfdisk /dev/sda, to see how the disk is configured. Once you know how the disk is configured, use lvm tools to dig into it. lvmdiskscan will show you the volumes. lvscan will show you the status of the drives. lvdisplay will show you the LV and VG names. vgchange -ay will make the volumes active, and lvscan should then show you the appropriate volumes: /dev/qubes_dom0/root Then you should be able to mount /dev/qubes_dom0/root and back up the VM data from there. If you need more help or something doesnt look right, just ask. (Cloning the disk was a good move, and would have been my first bit of advice.) -- 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 post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20181222132021.psi36jxdrxvq4dir%40thirdeyesecurity.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Backup verification error
On 10/17/2018 06:13 PM, 'awokd' via qubes-users wrote: Kelly Dean wrote on 10/17/18 6:00 PM: On Qubes 4.0, I did a full backup to an external hard drive using the standard backup utility, which completed successfully. 225GB total, compressed 130GB, took about 12 hours. Then I tried to verify it (restore with verify-only option), and watched it for a few minutes to make sure it was running ok, then left it alone. Last line in the message window at the time was: Extracting data: 209.6 GiB to restore Came back a few hours later and the next line was: Finished with errors! And there was a dialog box: [Dom0] Backup error! ERROR: failed to decrypt /var/tmp/restorexnuw0a8p/vm31/private.img.034.enc: b'scrypt: Decrypting file would take too much CPU time\n' Partially restored files left in /var/tmp/restore_*, investigate them and/or clean them up OK So now I don't know if I have a good backup. The error message also leaves me doubtful that I'd be able to restore the backup even if it is good. The indicated file doesn't exist in dom0. Neither does any other /var/tmp/restore* file. Googling the message (Decrypting file would take too much CPU time) finds nothing. Looks like that error string comes from scrypt. There is a command line option (-f) to scrypt that forces it to proceed even if it might take excessive memory or CPU time, but I'm not sure how to pass it on through qubes-backup-restore. Looking at the scrypt source, this error code results from the estimated number of operations exceeding a max time limit. Using -f should override this check. In restore.py the function 'def launch_scrypt' contains the line starting with: command_line = ['scrypt', action, input_name This could be changed to: command_line = ['scrypt', action, '-f', input_name Of course, this advice is offered "at your own risk" and a backup copy of restore.py should be made before doing any modification. - BTW, since your backups are rather large, you might be interested in a new backup tool I'm writing that can perform fast incremental backups even on large volumes: https://github.com/tasket/sparsebak Its still experimental but could be in beta as soon as December. -- 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 post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/ddd8b81d-9558-9bfc-aeee-a950e3236cb4%40posteo.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Backup verification error
Kelly Dean wrote on 10/17/18 6:00 PM: On Qubes 4.0, I did a full backup to an external hard drive using the standard backup utility, which completed successfully. 225GB total, compressed 130GB, took about 12 hours. Then I tried to verify it (restore with verify-only option), and watched it for a few minutes to make sure it was running ok, then left it alone. Last line in the message window at the time was: Extracting data: 209.6 GiB to restore Came back a few hours later and the next line was: Finished with errors! And there was a dialog box: [Dom0] Backup error! ERROR: failed to decrypt /var/tmp/restorexnuw0a8p/vm31/private.img.034.enc: b'scrypt: Decrypting file would take too much CPU time\n' Partially restored files left in /var/tmp/restore_*, investigate them and/or clean them up OK So now I don't know if I have a good backup. The error message also leaves me doubtful that I'd be able to restore the backup even if it is good. The indicated file doesn't exist in dom0. Neither does any other /var/tmp/restore* file. Googling the message (Decrypting file would take too much CPU time) finds nothing. Looks like that error string comes from scrypt. There is a command line option (-f) to scrypt that forces it to proceed even if it might take excessive memory or CPU time, but I'm not sure how to pass it on through qubes-backup-restore. -- 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 post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/88ea4d17-f523-9813-d73c-0c16ac1a3ea0%40danwin1210.me. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Backup verification error
Considering how long it takes and the chance for errors I also make a post fsck dd backup of the entire drive/partition and then sha1sum it just in case, which has saved me a few times. I wish there was a choice to use more RAM to make it go faster or what not. -- 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 post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/5297d787-63b2-5814-39c3-30e94bb31484%40gmx.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] BACKUP PROBLEM
Thanks for comments. To clarify - i’m only using qubes4 vm’s and templates. In ideal world, i ‘d use clonezilla say to clone everything and copy the clonezilla image back if i ever thought there was a problem with active system. This does not seem possible with qubes. (This process is simple and works well with debian, ubuntu etc) Instead I’ve copied all my qubes3.2 data offline and was intending to use filezilla to bring it all back -once i was confident of stable qubes4 setup. I think i’m further away from ever with that. Just done the umpteenth install of qubes4 and now can’t get my test vm’s to recognise software eg filezilla, libreoffice writer that i’ ve added to fedora 26. I done endless resume, stop/starts and turn pc off/on - but nothing happening. Was intending to generate a fedora-26 template backup again, including a few test vm’s - then transfer to another pc , then do a fresh install on main pc, zap the new fedora-26 and vm’s and then try and copy the backup file to main pc and restore. Qubes is a great idea - for 12 months or so i’ve done almost all my internet stuff on dispvm’s and kept a good discipline wrt untusted/ personal vm’s etc. My old pc couldn’t handle qubes4 - so ive invested in new kit so i could start with qubes4. I can’t spend any more time with this so it’s back to debian for me. I’ll have another look at qubes in a few months when hopefully it’s more stable. Thanks again for comments. -- 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 post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/274633a8-90c4-49ca-9193-9aabede65d68%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] BACKUP PROBLEM
On Sun, May 13, 2018 1:58 pm, higginsonj...@gmail.com wrote: > > Just posted a comment on earlier BACKUP problem where message appeared > > "Backup header retrieval failed (exit code 2)" after qvm-backup restore. > > > Tried a simpler backup this time - just fedora-26 template and a small > personal VM. > > Process seemed to go OK - but following backup - was left with fedora-26 > template and fedora-261 template. (Think others have seen this also) You mean on restore, right? I saw that on mine too, it wanted to create some 0 byte DispVMs so I didn't include those on the restore. Note too that you should only be restoring your AppVMs and StandaloneVMs and using the templates that come with 4.0 instead. See https://www.qubes-os.org/doc/upgrade-to-r4.0/#restore-from-your-backup: "We recommend that you restore only your TemplateBasedVMs and StandaloneVMs from R3.2. Using TemplateVMs and SystemVMs from R3.2 is not fully supported (see #3514). Instead, we recommend using the TemplateVMs that were created specifically for R4.0" > Trying to get rid of fedora-261 template. Normal process won't allow it - > so tried "REMOVE VM's MANUALLY" approach as per docs. > First 3 instructions seem OK - but final one achieves nothing since there > is no content in the "applications-merged" folder. Looks like this doc is for R3.2 only and I missed it! I submitted an edit. If you have nothing else on your R4.0 installation, it might be faster to just reinstall it. > Hence can't remove FEDORA-261 from QUBES MANAGER. > > Note ALSO - the FEDORA-261 template created does not include any > APPLICATIONS from the FEDORA-26 template I stared with. > > SPECIFICALLY - it contains none at all! > > This seems similar to problems I encountered before with QUBES 4. > > 1) With QUBES3.2 - I used DEBIAN template - but have had to give up on > that as I can't get any applications to show within DEBIAN template and > have no means to add any. eg no TERMINAL > > 2) WIth QUBES 3.2 I also used a STANDALONE template for development work. > > Again - even if it's based on FEDORA-26 template - I get no APPLICATIONS > available to me and NO terminal. > > Basically I have given up on STANDALONE VM also. > > > I can install QUBES4 quickly and get what appears to be a workable system > - but am loathe to commit to it as every step I take seems to offer more > problems. > QUBES3.2 was simple and straightforward - and just seemed to work. > Am basically trying to get everything setup on new computer but after many > many days of trying (2 or 3 weeks of effort)- I cant achieve a stable > state > > No Debian > No Standalone > No BACKUP working consistently > Duplicated template - can't get rid from menu > QUBES manager clunky > Struggling to get rid of DISPOSABLE VM template(based on Fedora-26 when I > updated main template to fedora-27. > DispVM - quite slow compared to QUBES3.2 > > HAS ANYONE PREPARED AND USED BACKUPS SUCCESSFULLY ? > > -- > 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 post to this group, send email to qubes-users@googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/qubes-users/55328bb9-688e-4186-ab78-8d160c22e27e%40googlegroups.com. > For more options, visit https://groups.google.com/d/optout. > -- 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 post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/e931199dc42b3467df788af401806d5d%40elude.in. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Backup Error
> Likely the filesystem (FAT?) on the destination cannot handle files over > a certain size. You may want to reformat it with a native Linux fs like > Ext4. > > -- > > Chris Laprise, tas...@openmailbox.org > https://twitter.com/ttaskett > PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886 That was indeed the issue, thanks for the insight and suggestion! -- 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 post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/81bc0cac-c133-49ec-9974-1c3872dd555c%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Backup Error
On Friday, March 17, 2017 at 3:31:37 PM UTC-4, Chris Laprise wrote: > On 03/17/2017 02:55 PM, jimmy.dack...@gmail.com wrote: > > I'm trying out the backup feature in Qubes but getting an error. > > > > I'm trying to save VMs totaling 22.4GB in size on a USB stick with 63GB > > free. > > > > At 19% progress is get: > > "[Dom0] Backup error! > > ERROR: Failed to write the backup, VM output: cat: write error: File too > > large." > > > > Is there a maximum file size for backups? A RAM limitation (I have 8GB RAM > > and when I do the backup about 6GB is free)? Something else I'm not > > thinking of? > > > > I am able to do a small backup, such as just Dom0 itself. > > > > Also a general question about backups: if I do a backup and then restore, > > will it add what I backed up to what is already on the system? Or > > completely overwrite everything? For example, if I have 10 VMs and backup > > 3, then restore the 3, will it just overwrite those three and leave the > > other 7 alone? Or will I only have those 3 and the other 7 are wiped out? > > > > Likely the filesystem (FAT?) on the destination cannot handle files over > a certain size. You may want to reformat it with a native Linux fs like > Ext4. > 5Bp9975@cB%m0wkX > -- > > Chris Laprise, tas...@openmailbox.org > https://twitter.com/ttaskett > PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886 That was indeed the issue, thanks for the insight! -- 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 post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/fd093e5a-5e9b-4330-a11e-3f783b09bc3b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Backup Error
On 2017-03-17 11:55, jimmy.dack...@gmail.com wrote: I'm trying out the backup feature in Qubes but getting an error. I'm trying to save VMs totaling 22.4GB in size on a USB stick with 63GB free. At 19% progress is get: "[Dom0] Backup error! ERROR: Failed to write the backup, VM output: cat: write error: File too large." Is there a maximum file size for backups? A RAM limitation (I have 8GB RAM and when I do the backup about 6GB is free)? Something else I'm not thinking of? I am able to do a small backup, such as just Dom0 itself. Also a general question about backups: if I do a backup and then restore, will it add what I backed up to what is already on the system? Or completely overwrite everything? For example, if I have 10 VMs and backup 3, then restore the 3, will it just overwrite those three and leave the other 7 alone? Or will I only have those 3 and the other 7 are wiped out? Also, be sure you didn't make the mistake I made once. I (stupidly) mounted by backup USB stick in Dom0. Then, when backing up Dom0, it tried to back up all the data on the backup stick, which of course kept increasing in size as more stuff got backed up onto it. I've since learned to use a USBVM, and mount the stick in a dedicated BackupVM. -- 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 post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/10747aff541781e0d2738fb6c6ca7f97%40nowlas.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Backup Error
On Fri, Mar 17, 2017 at 03:31:24PM -0400, Chris Laprise wrote: > On 03/17/2017 02:55 PM, jimmy.dack...@gmail.com wrote: > >I'm trying out the backup feature in Qubes but getting an error. > > > >I'm trying to save VMs totaling 22.4GB in size on a USB stick with 63GB free. > > > >At 19% progress is get: > >"[Dom0] Backup error! > >ERROR: Failed to write the backup, VM output: cat: write error: File too > >large." > > > >Is there a maximum file size for backups? A RAM limitation (I have 8GB RAM > >and when I do the backup about 6GB is free)? Something else I'm not thinking > >of? > > > >I am able to do a small backup, such as just Dom0 itself. > > > >Also a general question about backups: if I do a backup and then restore, > >will it add what I backed up to what is already on the system? Or completely > >overwrite everything? For example, if I have 10 VMs and backup 3, then > >restore the 3, will it just overwrite those three and leave the other 7 > >alone? Or will I only have those 3 and the other 7 are wiped out? > > > > Likely the filesystem (FAT?) on the destination cannot handle files over a > certain size. You may want to reformat it with a native Linux fs like Ext4. > To answer your general question, the restore operation will tell you there is an existing qube with the same name and wont allow you to overwrite it. It certainly wont delete qubes not included in the restore. As always the command line tool offers many more options and more granular control - it still wont act on qubes not involved in the restore operation, (unless you are doing something to their template obviously.) unman -- 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 post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20170317212124.GC1810%40thirdeyesecurity.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Backup Error
On 03/17/2017 02:55 PM, jimmy.dack...@gmail.com wrote: I'm trying out the backup feature in Qubes but getting an error. I'm trying to save VMs totaling 22.4GB in size on a USB stick with 63GB free. At 19% progress is get: "[Dom0] Backup error! ERROR: Failed to write the backup, VM output: cat: write error: File too large." Is there a maximum file size for backups? A RAM limitation (I have 8GB RAM and when I do the backup about 6GB is free)? Something else I'm not thinking of? I am able to do a small backup, such as just Dom0 itself. Also a general question about backups: if I do a backup and then restore, will it add what I backed up to what is already on the system? Or completely overwrite everything? For example, if I have 10 VMs and backup 3, then restore the 3, will it just overwrite those three and leave the other 7 alone? Or will I only have those 3 and the other 7 are wiped out? Likely the filesystem (FAT?) on the destination cannot handle files over a certain size. You may want to reformat it with a native Linux fs like Ext4. -- Chris Laprise, tas...@openmailbox.org 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 post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/07c70ef9-0e9f-336b-1c04-2c2920d55e72%40openmailbox.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Backup error - where is the log?
If I install a second Qubes system on a different partition - is there any way to copy the VMs from the first one? Because that was my goal with the backups. It is possible that the lack of space somehow corrupted the system - and that is the reason for the problems with backups - so maybe there is any other way to do that? Z. -- 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 post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/CAGL_UUvMPW%3D6LteSw_gA3C%2B3jVyNbruc8BvuCRinfjy6c-77BQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Backup error - where is the log?
I removed some templates - and now there is no error about no disk space - but when restoring I still get the same error. It might be indeed about the path fed to tar - because when creating the archive I also get errors when I try to archive to a file in the current dir without giving the full path - it looks like the variable base_backup_dir does not get initialized, see below for the output. Backing up worked when I gave it a full path - still failing at restoring time. Z. == [zby@dom0 ~]$ qvm-backup -x dom0 -x anon-whonix -x sys-net -x sys-firewall -x sys-whonix -x python-anaconda backup --+--+--+ VM | type | size | --+--+--+ untrusted |AppVM | 16.0 KiB | personal |AppVM |0 | myovm |AppVM | 5.0 GiB | my-new-vm |AppVM | 9.9 GiB | exch |AppVM |315.8 MiB | --+--+--+ Total size: |15.1 GiB | --+--+--+ VMs not selected for backup: anon-whonix debian-8 debian-8-python dom0 fedora-23 fedora-23-dvm python-anaconda sys-firewall sys-net sys-whonix whonix-gw whonix-ws Traceback (most recent call last): File "/usr/bin/qvm-backup", line 218, in main() File "/usr/bin/qvm-backup", line 141, in main stat = os.statvfs(os.path.dirname(base_backup_dir)) OSError: [Errno 2] No such file or directory: '' On Fri, Feb 24, 2017 at 9:27 AM, Marek Marczykowski-Górecki wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA256 > > On Fri, Feb 24, 2017 at 08:23:00AM -0500, Zbigniew Łukasiak wrote: >> Ok - I tried the command line version - the output is below. The same >> error I see in ~/.xsession-errors. It looks to work correctly with the >> symlinked tmp - but still fails somehow - maybe the archive is >> corrupted. >> >> I tried to re-make the bacup from commandline, and this reports >> "qvm-backup: export error: [Errno 28] No space left on device" - even >> though I have enough space on both the /home and the /var/tmp >> partitions. See below for details - I mounted quite a big partition on >> /var/tmp. Maybe it somehow still uses the root partition. I did not >> see that error when running backup from Qubes Manager - but maybe the >> problem was still there and it was corrupting the backup. >> >> >> >> >> [zby@dom0 ~]$ qvm-backup-restore qubes-2017-02-22T111605 --verify-only >> --debug >> Please enter the passphrase to verify and (if encrypted) decrypt the backup: >> Checking backup content... >> Working in temporary dir:/var/tmp/restore_RxbZ1b >> Extracting data: 1.0 MiB to restore >> Run command[u'tar', u'-ixvf', 'qubes-2017-02-22T111605', u'-C', >> u'/var/tmp/restore_RxbZ1b', u'backup-header', u'backup-header.hmac', >> u'qubes.xml.000', u'qubes.xml.000.hmac'] >> Got backup header and hmac: backup-header, backup-header.hmac >> Verifying file /var/tmp/restore_RxbZ1b/backup-header >> Loading hmac for file /var/tmp/restore_RxbZ1b/backup-header >> File verification OK -> Sending file /var/tmp/restore_RxbZ1b/backup-header >> Creating pipe in: /var/tmp/restore_RxbZ1b/restore_pipe >> Getting new file:qubes.xml.000 >> Getting hmac:qubes.xml.000.hmac >> Verifying file /var/tmp/restore_RxbZ1b/qubes.xml.000 >> Started sending thread >> Moving to dir /var/tmp/restore_RxbZ1b >> Loading hmac for file /var/tmp/restore_RxbZ1b/qubes.xml.000 >> File verification OK -> Sending file /var/tmp/restore_RxbZ1b/qubes.xml.000 >> Getting new file: >> Waiting for the extraction process to finish...Extracting file >> /var/tmp/restore_RxbZ1b/qubes.xml.000 >> >> Running command [u'tar', u'-xkv', >> u'../../../../var/tmp/restore_RxbZ1b/qubes.xml'] > > This path looks strange. AFAIR it's calculated as "path to > /var/tmp/restore_RxbZ1b/qubes.xml, relative to /var/tmp/restore_RxbZ1b". > Have you actually mounted something on /var/tmp, or used a symlink? You > can use mount --bind if you don't want to mount the whole device there. > And be sure do to it before launching qvm-backup-restore, not during it. > >> === >> >> >> [zby@dom0 ~]$ df >> Filesystem 1K-blocks Used Available Use% Mounted on >> devtmpfs 2002988 0 2002988 0% /dev >> tmpfs2014408308256 1706152 16% /dev/shm >> tmpfs2014408 1316 2013092 1% /run >> tmpfs2014408 0 2014408 0% /sys/fs/cgroup >> /dev/dm-1 95989516 92623640 0 100% / > > Having / full is a problem anyway. Even if large files are placed in > /var/tmp. You need to clean up something - maybe old content of > /var/tmp? Or some old logs in /var/log? > >> tmpfs201440852 2014356 1% /tmp >> xenstore 2014408 240 2014168
Re: [qubes-users] Backup error - where is the log?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Fri, Feb 24, 2017 at 08:23:00AM -0500, Zbigniew Łukasiak wrote: > Ok - I tried the command line version - the output is below. The same > error I see in ~/.xsession-errors. It looks to work correctly with the > symlinked tmp - but still fails somehow - maybe the archive is > corrupted. > > I tried to re-make the bacup from commandline, and this reports > "qvm-backup: export error: [Errno 28] No space left on device" - even > though I have enough space on both the /home and the /var/tmp > partitions. See below for details - I mounted quite a big partition on > /var/tmp. Maybe it somehow still uses the root partition. I did not > see that error when running backup from Qubes Manager - but maybe the > problem was still there and it was corrupting the backup. > > > > > [zby@dom0 ~]$ qvm-backup-restore qubes-2017-02-22T111605 --verify-only --debug > Please enter the passphrase to verify and (if encrypted) decrypt the backup: > Checking backup content... > Working in temporary dir:/var/tmp/restore_RxbZ1b > Extracting data: 1.0 MiB to restore > Run command[u'tar', u'-ixvf', 'qubes-2017-02-22T111605', u'-C', > u'/var/tmp/restore_RxbZ1b', u'backup-header', u'backup-header.hmac', > u'qubes.xml.000', u'qubes.xml.000.hmac'] > Got backup header and hmac: backup-header, backup-header.hmac > Verifying file /var/tmp/restore_RxbZ1b/backup-header > Loading hmac for file /var/tmp/restore_RxbZ1b/backup-header > File verification OK -> Sending file /var/tmp/restore_RxbZ1b/backup-header > Creating pipe in: /var/tmp/restore_RxbZ1b/restore_pipe > Getting new file:qubes.xml.000 > Getting hmac:qubes.xml.000.hmac > Verifying file /var/tmp/restore_RxbZ1b/qubes.xml.000 > Started sending thread > Moving to dir /var/tmp/restore_RxbZ1b > Loading hmac for file /var/tmp/restore_RxbZ1b/qubes.xml.000 > File verification OK -> Sending file /var/tmp/restore_RxbZ1b/qubes.xml.000 > Getting new file: > Waiting for the extraction process to finish...Extracting file > /var/tmp/restore_RxbZ1b/qubes.xml.000 > > Running command [u'tar', u'-xkv', > u'../../../../var/tmp/restore_RxbZ1b/qubes.xml'] This path looks strange. AFAIR it's calculated as "path to /var/tmp/restore_RxbZ1b/qubes.xml, relative to /var/tmp/restore_RxbZ1b". Have you actually mounted something on /var/tmp, or used a symlink? You can use mount --bind if you don't want to mount the whole device there. And be sure do to it before launching qvm-backup-restore, not during it. > === > > > [zby@dom0 ~]$ df > Filesystem 1K-blocks Used Available Use% Mounted on > devtmpfs 2002988 0 2002988 0% /dev > tmpfs2014408308256 1706152 16% /dev/shm > tmpfs2014408 1316 2013092 1% /run > tmpfs2014408 0 2014408 0% /sys/fs/cgroup > /dev/dm-1 95989516 92623640 0 100% / Having / full is a problem anyway. Even if large files are placed in /var/tmp. You need to clean up something - maybe old content of /var/tmp? Or some old logs in /var/log? > tmpfs201440852 2014356 1% /tmp > xenstore 2014408 240 2014168 1% /var/lib/xenstored > /dev/sda11 1889292184884 1590388 11% /boot > /dev/dm-3 288243040 67263564 206314468 25% /home > tmpfs 402884 0402884 0% /run/user/991 > tmpfs 402884 8402876 1% /run/user/1000 > /dev/sda7 272256456 167991052 90412476 66% /home/zby/tmp - -- 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- Version: GnuPG v2 iQEcBAEBCAAGBQJYsELWAAoJENuP0xzK19cs4sIH/3xTOfvVJ3RmfzdoXAfz85Z2 QH1loLH347X5omAENt+4HwhzlTq84LZFGKwRWMEgSDQUuj67saas711x5+ybH47N riswwTJfRC6SrEKPO27/QIN/JSGhCi1h+kmco9UxQSvaovSD0iSBoHsUui2iSvfL 4JfszFiWWVAsOZJu2nJdFOQPH7e69yKBC/hwMX+6PhP+FbhgmT8QZtIm6qWu3NGA n69O00exgPVKVjv1zhz1QoBzZn9J/MCq+N5vx/Ur6zVb8dD7+Vwu/3fvMFeuxKbx PJ7XXUQgVuiTxxc3GNfk0nrJqLSSAbn6HAmXDY6rtpcdXt1PyaYZDoxQkKtKJtY= =nXLP -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 post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20170224142730.GO1146%40mail-itl. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Backup error - where is the log?
Ok - I tried the command line version - the output is below. The same error I see in ~/.xsession-errors. It looks to work correctly with the symlinked tmp - but still fails somehow - maybe the archive is corrupted. I tried to re-make the bacup from commandline, and this reports "qvm-backup: export error: [Errno 28] No space left on device" - even though I have enough space on both the /home and the /var/tmp partitions. See below for details - I mounted quite a big partition on /var/tmp. Maybe it somehow still uses the root partition. I did not see that error when running backup from Qubes Manager - but maybe the problem was still there and it was corrupting the backup. [zby@dom0 ~]$ qvm-backup-restore qubes-2017-02-22T111605 --verify-only --debug Please enter the passphrase to verify and (if encrypted) decrypt the backup: Checking backup content... Working in temporary dir:/var/tmp/restore_RxbZ1b Extracting data: 1.0 MiB to restore Run command[u'tar', u'-ixvf', 'qubes-2017-02-22T111605', u'-C', u'/var/tmp/restore_RxbZ1b', u'backup-header', u'backup-header.hmac', u'qubes.xml.000', u'qubes.xml.000.hmac'] Got backup header and hmac: backup-header, backup-header.hmac Verifying file /var/tmp/restore_RxbZ1b/backup-header Loading hmac for file /var/tmp/restore_RxbZ1b/backup-header File verification OK -> Sending file /var/tmp/restore_RxbZ1b/backup-header Creating pipe in: /var/tmp/restore_RxbZ1b/restore_pipe Getting new file:qubes.xml.000 Getting hmac:qubes.xml.000.hmac Verifying file /var/tmp/restore_RxbZ1b/qubes.xml.000 Started sending thread Moving to dir /var/tmp/restore_RxbZ1b Loading hmac for file /var/tmp/restore_RxbZ1b/qubes.xml.000 File verification OK -> Sending file /var/tmp/restore_RxbZ1b/qubes.xml.000 Getting new file: Waiting for the extraction process to finish...Extracting file /var/tmp/restore_RxbZ1b/qubes.xml.000 Running command [u'tar', u'-xkv', u'../../../../var/tmp/restore_RxbZ1b/qubes.xml'] Removing file /var/tmp/restore_RxbZ1b/qubes.xml.000 ERROR: unable to extract files for /var/tmp/restore_RxbZ1b/qubes.xml.000.(u'', u'tar: ../../../../var/tmp/restore_RxbZ1b/qubes.xml: Not found in archive\n\ntar: Exiting with failure status due to previous errors\n') Tar command output: %s Process ExtractWorker3-1: Traceback (most recent call last): File "/usr/lib64/python2.7/multiprocessing/process.py", line 258, in _bootstrap self.run() File "/usr/lib64/python2.7/site-packages/qubes/backup.py", line 931, in run self.__run__() File "/usr/lib64/python2.7/site-packages/qubes/backup.py", line 1251, in __run__ "\n".join(self.tar2_stderr QubesException: unable to extract files for /var/tmp/restore_RxbZ1b/qubes.xml.000.(u'', u'tar: ../../../../var/tmp/restore_RxbZ1b/qubes.xml: Not found in archive\n\ntar: Exiting with failure status due to previous errors\n') Tar command output: %s Extraction process finished with code:1 ERROR: unable to extract the qubes backup. Check extracting process errors. === [zby@dom0 ~]$ df Filesystem 1K-blocks Used Available Use% Mounted on devtmpfs 2002988 0 2002988 0% /dev tmpfs2014408308256 1706152 16% /dev/shm tmpfs2014408 1316 2013092 1% /run tmpfs2014408 0 2014408 0% /sys/fs/cgroup /dev/dm-1 95989516 92623640 0 100% / tmpfs201440852 2014356 1% /tmp xenstore 2014408 240 2014168 1% /var/lib/xenstored /dev/sda11 1889292184884 1590388 11% /boot /dev/dm-3 288243040 67263564 206314468 25% /home tmpfs 402884 0402884 0% /run/user/991 tmpfs 402884 8402876 1% /run/user/1000 /dev/sda7 272256456 167991052 90412476 66% /home/zby/tmp [zby@dom0 ~]$ qvm-backup -x dom0 -x untrusted -x anon-whonix -x vault -x personal -x work -x sys-net -x sys-firewall -x sys-whonix back -x python-anaconda --debug --+--+--+ VM | type | size | --+--+--+ myovm |AppVM | 5.0 GiB | my-new-vm |AppVM | 9.8 GiB | <-- The VM is running, please shut it down before proceeding with the backup! exch |AppVM |316.0 MiB | <-- The VM is running, please shut it down before proceeding with the backup! qvm-backup: export error: [Errno 28] No space left on device --+--+--+ Total size: |15.1 GiB | --+--+--+ VMs not selected for backup: anon-whonix debian-8 debian-8-python dom0 fedora-23 fedora-23-dvm personal python-anaconda sys-firewall sys-net sys-whonix untrusted vault whonix-gw whonix-ws work ERROR: Please shutdown all VMs before proceeding. On Thu, Feb 23, 2017 at 3:42 AM, Marek Marczykowski-G
Re: [qubes-users] Backup error - where is the log?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Wed, Feb 22, 2017 at 12:38:48PM -0500, Zbigniew Łukasiak wrote: > I am getting an error message when trying to restore a VM backup: > "unable to extract the qubes backup. Check the extracting process errors." > > Where should I look for the extracting process error log? > I don't see anything relevant in /var/log - but maybe I missed something. If you launched the backup from Qubes Manager, check ~/.xsession-errors. > More info: > > I made a bacup using the 'System' -> 'Bacup VMs' menu entry in the > Qubes VM Manager and then I tried to restore it with the 'System' -> > 'Restore VMs from backup' menu entry. I tried both just veryfying the > integrity and restoring it entirely - with the same result. > > My root filesystem if full - and I noticed that the backup > verification process tried to write to /var/tmp . This was failing - > so I tried symlinking that directory to another filesystem and > mounting another partition over it. This worked at the start and it > did create a 'restore_*' directory with some files in /var/tmp - > but then failed with the message I described above. I would like to > look into the error message - to understand what is failing. Out of disk space is most likely the reason. But if it isn't the case after symlinking /var/tmp, check messages in ~/.xsession-errors. If still nothing interesting, you can launch restoring (or verification) from command line (qvm-backup-restore), with --debug switch. - -- 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- Version: GnuPG v2 iQEcBAEBCAAGBQJYrqCOAAoJENuP0xzK19csQXYH/2j89aAzUg1LAemETRfxOMcy T4oM+/ps2qlR1kgA1/LLKx6LdbW2cu5rMR9uAQhr5yHeLp15j5JXF4Ef/pFp1fXr TrvSMl4x9z+OAUKt+6uZncyl81J7UhMzJ0ixwE58B1vxUzP76aBXz7N8BwhdCLTw ydi0mg4Pd2iIMRV8wYCX4qxjT0M9OmYf4ClQpOcDUc8+68rEX2vwrD7vOuC0RIfu MUjutenc3jkLEnAEr0W9cXjwCR360R4ZU5r3SaOPXXo6P4JpBwHkdYdan1uv+cPT dGtKHMoQlgb6Gq3KPIobaMLhi+8WPv0RkThgjxodirUOHfiZ9GlVfpChtrd8Hjc= =pEg5 -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 post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20170223084254.GB13918%40mail-itl. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] backup failes
haaber: > > Cannot create /media/user/hexstring/qubes-backup/2017-02... : permission > > denied. > > Try "sudo chown user:user /media/user/hexstring/qubes-backup". > > Rusty Thank you that worked! Bernhard -- 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 post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/24341d31-3953-b7d1-a67e-0e9eed76984f%40web.de. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] backup failes
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 haaber: > Cannot create /media/user/hexstring/qubes-backup/2017-02... : permission > denied. Try "sudo chown user:user /media/user/hexstring/qubes-backup". Rusty -BEGIN PGP SIGNATURE- iQJ8BAEBCgBmBQJYnPnSXxSAAC4AKGlzc3Vlci1mcHJAbm90YXRpb25zLm9w ZW5wZ3AuZmlmdGhob3JzZW1hbi5uZXQ4NEI1OUJDRkM2MkIxMjlGRTFCMDZEMDQ0 NjlENzhGNDdBQUYyQURGAAoJEEadePR6ryrfgRoP/1dJWam9ej7w+LGSN8ECzDew t1eF65sNwrPiuZX6gZvOepkgKfqk7aUPYkeggW2MXnYPUGZKt4+ZOzFloV/29KOw JhCgSHjmTmati3E/vvAAgBSc+LxDeozweYM0OFTql0Q5s1ha8NtmEpqlHm94G6Ok x5XzYikRvVeHXoC3U4vmvAR974gWG9nUU+Oi4CDZrTAMQjR3uWjSqsQDH6r7vEuG 7/IWt/eFp3/196abeLqhV/zuwCzE9H6QyBMVfQOGbrJ2nKZjIStQw0v/X2vaG6nF gTtjzv3LSj5nhP8uzrlwvIfAG85WMWofjhsILuMMVv342GmupcMEwW2U2KEwH8LB f20H5c9iHPzzT3XTNzCRlO/be6igxHcGRsnBgH+KCZ++1B1sq4JROR5hOduu0hnD K9fOr6Buyg1lbz3W+1wFHXIs2mBppu936Kfhs0R6A4/2hCXhZKZm72aDgpVnEoTL MoTHHAaw6UW6iuBSirrzzvCuUhnjSPdcs7k1p9wdkwdMNmVaG5Xl+Qb6EB5XfrV0 kO2/F56OTZmsE8H3n0oF/sNwVAbZmN9g4eOujdDm0a4rHMx/fwQFGH9CrHsdKCK7 T5FhWHIXk0JJ7C98s9MNb+BWVIlkZ19RXPnKa5ishnuIkcEWG/+UE21UccUxh8mh yff9xd+OMCZ0mx9FaK9U =rDDj -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 post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20170209232258.GA2634%40mutt. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] "Backup VMs" does not backup salt configuration
On 05/02/17 23:59, john.david.r.smith wrote: On 05/02/17 00:06, Oleg Artemiev wrote: Hi. On Wed, Feb 1, 2017 at 11:56 PM, john.david.r.smith wrote: On 01/02/17 21:30, qu...@posteo.de wrote: I have now nearly a complete salt configuration for all my templates so I do not need to backup them anymore and save a lot of space by this. So I have ran a backup including dom0 and realized that the salt configuration ("/srv/salt") does not seem to be included because it is much bigger than the MB listed for dom0. Is there a way to back it up right now with this method or do I manually have to copy everything outside of dom0? Thx in advance i put my files in ~/salt and symlinked them to /srv/salt then backups should work Could you point to source for more information on your work? Backups work slow (disk/network bottlenecks) & I'm also interested to backup less. i started to extend the salt documentation and just added an pull-request. you can find my repo of the doc here: https://github.com/john-david-r-smith/qubes-doc/blob/salt-doc/configuration/salt.md here the correct link (i failed to push on my branch...): https://github.com/john-david-r-smith/qubes-doc/blob/master/configuration/salt.md -- 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 post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/d90a0278-4868-264f-8abf-2f8232788037%40openmailbox.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] "Backup VMs" does not backup salt configuration
On 05/02/17 00:06, Oleg Artemiev wrote: Hi. On Wed, Feb 1, 2017 at 11:56 PM, john.david.r.smith wrote: On 01/02/17 21:30, qu...@posteo.de wrote: I have now nearly a complete salt configuration for all my templates so I do not need to backup them anymore and save a lot of space by this. So I have ran a backup including dom0 and realized that the salt configuration ("/srv/salt") does not seem to be included because it is much bigger than the MB listed for dom0. Is there a way to back it up right now with this method or do I manually have to copy everything outside of dom0? Thx in advance i put my files in ~/salt and symlinked them to /srv/salt then backups should work Could you point to source for more information on your work? Backups work slow (disk/network bottlenecks) & I'm also interested to backup less. i started to extend the salt documentation and just added an pull-request. you can find my repo of the doc here: https://github.com/john-david-r-smith/qubes-doc/blob/salt-doc/configuration/salt.md -- 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 post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/2505d2c9-ff11-08e0-b815-bf768464b65a%40openmailbox.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] "Backup VMs" does not backup salt configuration
Hey, On 05.02.2017 00:06, Oleg Artemiev wrote: Hi. On Wed, Feb 1, 2017 at 11:56 PM, john.david.r.smith wrote: On 01/02/17 21:30, qu...@posteo.de wrote: I have now nearly a complete salt configuration for all my templates so I do not need to backup them anymore and save a lot of space by this. Could you point to source for more information on your work? I have not posted my work anywhere but I learned most things from this repo https://github.com/Nekroze/qubes-salt and of course the salt documentation and hints from John Regards -- 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 post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/d3860054a52b9e9541b8aa80793ef99f%40posteo.de. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] "Backup VMs" does not backup salt configuration
Hi. On Wed, Feb 1, 2017 at 11:56 PM, john.david.r.smith wrote: > On 01/02/17 21:30, qu...@posteo.de wrote: >> I have now nearly a complete salt configuration for all my templates so I >> do not need to backup them anymore and save a lot of space by this. >> >> So I have ran a backup including dom0 and realized that the salt >> configuration ("/srv/salt") does not seem to be included because it is much >> bigger than the MB listed for dom0. >> >> Is there a way to back it up right now with this method or do I manually >> have to copy everything outside of dom0? >> >> Thx in advance >> > > i put my files in ~/salt and symlinked them to /srv/salt > then backups should work Could you point to source for more information on your work? Backups work slow (disk/network bottlenecks) & I'm also interested to backup less. -- Bye.Olli. gpg --search-keys grey_olli , use key w/ fingerprint below: Key fingerprint = 9901 6808 768C 8B89 544C 9BE0 49F9 5A46 2B98 147E Blog keys (the blog is mostly in Russian): http://grey-olli.livejournal.com/tag/ -- 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 post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/CABunX6Of_4KrpHRFSvcpLLd1sWPg6BKqjJiBsBuQvr8F1d2VBQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] "Backup VMs" does not backup salt configuration
On 01/02/17 21:30, qu...@posteo.de wrote: Hi, I have now nearly a complete salt configuration for all my templates so I do not need to backup them anymore and save a lot of space by this. So I have ran a backup including dom0 and realized that the salt configuration ("/srv/salt") does not seem to be included because it is much bigger than the MB listed for dom0. Is there a way to back it up right now with this method or do I manually have to copy everything outside of dom0? Thx in advance i put my files in ~/salt and symlinked them to /srv/salt then backups should work -- 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 post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/ba5ec9f2-6b8c-7bf0-570d-7c3e6aac5c84%40openmailbox.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] backup
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 2016-09-28 00:32, Gabriel wrote: > On 2016-09-27 06:59, 'Gabriel' via qubes-users wrote: >> 2. I tried running qvm-backup from the command line, which ran fine, no >> permission problems on the same HDD. However, the template VMs are not >> included by default and I saw no command-line option to automatically >> achieve this. Am I missing something here? >> > >> The RPM-managed TemplateVMs should normally not be backed up. Instead, you >> should clone them (if you can spare the drive space), make your >> customizations, then back up the clones. > Does this imply the AppVMs should be based upon the cloned VMs? > Correct. - -- Andrew David Wong (Axon) Community Manager, Qubes OS https://www.qubes-os.org -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJX7RfIAAoJENtN07w5UDAwfJoQAMOEl75O7pfUH1bddOcBrAmD +q+ocQta8pEjI3j3atG1pxcuTUDFrG32BkrZ7OrbIBEOw3PeapNYh0ht1peamdx7 UJJ9uk5LJ1RE2yiKSAB80mRntgJUEI/MimblEPkG/wPFFlJi1drp0gAA42y0oBg3 ioYmsEoX3buCxN9nj2iOdLsqe+WVlMJJwK1tmBIoryEfvuKmiGlMfuI/Y0zJFSPM TWWhHtPwu83lhZRQW/bk1PU0nP3m8iFr9ia3orYZaGODnHs6ukCQJfFmlNRsCg/5 BFuuIYdm3lUBdyXobzYHtJea5N/XACWl+QHW58a0YQij7ZfqFAvlynP5SKujrTuU BMbxHJ8DCfdOjv8lazgt4a0fac82whXXr/qSGMePz/ROzhiQy1jFtAB4/vXe4OKM SrHh97jKdROp9TcH7SLSIg+inSOqMUk3Ax8IVvJ8V1rij+VWz67FJdf2g/FmgS2b LL6ZTTeHE+EAI1ToT2QSmp3hbWmjNSRSuzFT/bj0GpqwK/IJpRLLOwirOGoU8DRl Mq6QLmhU0mV5dgVs92MH3Ekyk06qUh9v5RbhkTJJTg0yQnloAa6JTcsNnB2m5HKq vFAUjMOmJ3Juz+BmSUwhm+chmVqoC0iHVkspTpoMjutELCmhi9IVN1b79P7eVFNG AA33k2NAdCAm8Zlc4Y/Z =Pge6 -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 post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/1c043b27-1201-6917-36d2-2c2388658293%40qubes-os.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] backup
On 2016-09-27 06:59, 'Gabriel' via qubes-users wrote: > Hi fellows, > > I started using qubes a while ago and I have a question concerning backups. > What I want is a complete backup to a dedicated external USB HDD. I > understand to achieve this all the VMs must be shut down. > Therefore when I plugged in the HDD I mounted it in dom0 under /mnt. > >This is fine as long as you trust the USB device you're attaching to dom0. If >you don't, consider using a USB qube instead: >https://www.qubes-os.org/doc/usb/#creating-and-using-a-usb-qube The USB device is trsted but I'll consider the usb-cube too. > Questions: > 1. When I ran Qubes VM Manager -> Backup VMs, I received an error message > stating no place on device and a zero byte backup file. Permissions are OK, > there's more than enough space on the HDD. > Any reasons why the backup did not succeed? > >Are you sure you selected the correct device in the menu? There was only one option > 2. I tried running qvm-backup from the command line, which ran fine, no > permission problems on the same HDD. However, the template VMs are not > included by default and I saw no command-line option to automatically achieve > this. Am I missing something here? > >The RPM-managed TemplateVMs should normally not be backed up. Instead, you >should clone them (if you can spare the drive space), make your >customizations, then back up the clones. Does this imply the AppVMs should be based upon the cloned VMs? > 3. I know I can manually list all the VMs on the command line to be backed > up, but I find that a bit awkward, so I tried this: > qvm-ls --raw-list | xargs qvm-backup /mnt/test/ > > but this threw a Python exception... > > For now I resorted to typing all the VMs by hand ... not elegant. > > Any help is appreciated. > Try this: $ qvm-backup /mnt/test/ `qvm-ls --raw-list` This one works nice, thank you. Gabe -- 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 post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/7jVsr2iHJEOfEeyN1cR_geYvDZnXIWWUa4iu_iCYAGBrQnpPD1p03FxuJdeTqK1qbIB8SPZZihvglfzbMD4iC0d97cn2RTKdO2lB2nuweio%3D%40protonmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] backup
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 2016-09-27 06:59, 'Gabriel' via qubes-users wrote: > Hi fellows, > > I started using qubes a while ago and I have a question concerning backups. > What I want is a complete backup to a dedicated external USB HDD. I > understand to achieve this all the VMs must be shut down. > Therefore when I plugged in the HDD I mounted it in dom0 under /mnt. > This is fine as long as you trust the USB device you're attaching to dom0. If you don't, consider using a USB qube instead: https://www.qubes-os.org/doc/usb/#creating-and-using-a-usb-qube > Questions: > 1. When I ran Qubes VM Manager -> Backup VMs, I received an error message > stating no place on device and a zero byte backup file. Permissions are OK, > there's more than enough space on the HDD. > Any reasons why the backup did not succeed? > Are you sure you selected the correct device in the menu? > 2. I tried running qvm-backup from the command line, which ran fine, no > permission problems on the same HDD. However, the template VMs are not > included by default and I saw no command-line option to automatically achieve > this. Am I missing something here? > The RPM-managed TemplateVMs should normally not be backed up. Instead, you should clone them (if you can spare the drive space), make your customizations, then back up the clones. > 3. I know I can manually list all the VMs on the command line to be backed > up, but I find that a bit awkward, so I tried this: > qvm-ls --raw-list | xargs qvm-backup /mnt/test/ > > but this threw a Python exception... > > For now I resorted to typing all the VMs by hand ... not elegant. > > Any help is appreciated. > Try this: $ qvm-backup /mnt/test/ `qvm-ls --raw-list` You can also prepare a list of VMs (one VM name per line) as a file, then: $ qvm-backup /mnt/test/ `cat vm_list.txt` - -- Andrew David Wong (Axon) Community Manager, Qubes OS https://www.qubes-os.org -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJX6rLjAAoJENtN07w5UDAwuJQQAMu+Wfr56Bmf6bmJVCrZWY76 ZosTo+0ouB7jBYcoplACyirVmXjhFK3G9AFKRnpNZ3qo7m9w3rWD6cgbYwv88yfW nTJZBV88xqQqLGjqz3+OCi84/sfpOgIC8tXhzZndKcGb+5yd0FxRgZhZg4shdJ4d DoBX2hAfwzaUG9FCH7spaIFE5XPeOXNlK+ft5kuhbstWxGsFz7plf1ibrRii+Z2U DNamPVhAD6x4/cIzakb57SJ4BWcDoCuyeeG0ICpHyTjEMBq3GH0pvt4bVsSIWUC8 3LrUYAkuKrtxeSBHuJ0eAMilpkz9rld8tl58FUiMW1ZkanSYYB/GV8ENhAruFvVL bvlgJ0vsOBg1FRXGC8LUUsXiw2owUP4z7Dgtl3Q5eZ+Zb1K/OAdbnmrkXbu/PpiR E50qQig/Ugxlg9XDdWCgANfFRfhdi2btA+qfP7aSJt+0Kf60GxmQtUGbHm+Q0ECP L03ZEFG33K/3xu26CFXjWQRwlFGMAAUF5BEiFuLDJ96rhwU5blHjV/lZ1e1rEyv1 uRjdJ06slyv78uLanqIXyMqH1nXBlu/RyayrqTJW1Jdo0GX3iSoF7SR1A8zPbf3r 3d/PmRfY2/1/okIcFYc0tkqq9fTvi0M+ixVIdPmYzoVuzsiP/y5tBM+7CT5YxY+q 0KnOMeWlDzFguSEdha+e =KRMx -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 post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/d7357dd5-7283-2368-17c0-2f88113418dc%40qubes-os.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] backup
'Gabriel' via qubes-users: > Hi fellows, > > I started using qubes a while ago and I have a question concerning backups. > What I want is a complete backup to a dedicated external USB HDD. I > understand to achieve this all the VMs must be shut down. > Therefore when I plugged in the HDD I mounted it in dom0 under /mnt. You can backup a subset of VM's from the GUI. I typically backup every VM except the USB VM (with the external HDD attached to the USB VM and mounted in a DispVM), under the assumption that if I'm ever restoring to a fresh Qubes install, there will already be a USB VM there, so backing up the USB VM isn't really needed. Cheers, -Jeremy -- 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 post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/58032d10-22a7-7c1b-8ee1-bd95c4ba563a%40airmail.cc. For more options, visit https://groups.google.com/d/optout. signature.asc Description: OpenPGP digital signature
Re: [qubes-users] Backup Encryption Options
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 2016-08-16 10:07, entr0py wrote: > According to: > > https://www.qubes-os.org/doc/backup-restore/ > https://groups.google.com/forum/#!searchin/qubes-users/ > backup$20encryption|sort:relevance/qubes-users/sS4A3vJdCQ8/w9-jIj5VW9oJ > > Qubes backup system has a "weak key derivation scheme". > > Is a reasonable workaround to just put the backups (with or without Qubes > encryption) on a LUKS device? > Yes. You can also read more about the key derivation issue here: https://github.com/QubesOS/qubes-issues/issues/971 > And a general cryptsetup question: Is there any security benefit to > encrypting an entire drive versus encrypting individual partitions (ie > /dev/sda vs /dev/sda1)? > Hm. Good question. One case where encrypting the entire drive would be better is if the OS might potentially write metadata, temp files, etc. to unencrypted partitions. If we're only considering an encrypted volume for storing data at rest (e.g., encrypting an entire external hard drive versus just a partition on that external hard drive), then I'd wager there's not much of a difference. It would be best to ask the cryptsetup devs, though (or just anyone more knowledgeable than me). - -- Andrew David Wong (Axon) Community Manager, Qubes OS https://www.qubes-os.org -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJXs0tHAAoJENtN07w5UDAw/HMQAKayEjqVm8iVj6kQN7oMy9G5 R2mCXRXRy1YOB13lbiLhAt5P0xokp8TWVUedVV5Ysx/64mW2tTwCzwfdQvBSzZUn JmK7PbhGOgkK+Az5QZhVC9iYk+QtuamVesjvcorc+V2+321guKOj3nC7rNA32KTV qKrN+ows67P+ASfHP7K3Gf+KMVOVIFxqUP1olbOomEolVGXgIImBFK896kGyowN4 VPSH2AJhp1X1i5EhBsGWvBVvqZnH1S+FvT1f948RBJzpEeQBWfSlTdv+U79l6nsB X1q1uhm1wWQmung+UMtqVnRlJq2Qo/QSUZt7TOYxGWI1PjX7+2BoV4DqB/2dYW5r Yy8a7MEXZcKWFTAAu2qksGfglFwy2W1mMb6/0Pcmi/QQvbzmgcGKV9k2IaNfwXpA J6GSrzEpCoaR5rYUjuTm7dDT41XhPZuHM0dAgdg8MPvppjIDLh6cjZF+y0fogMIm PshSa4hgRGouxwAb1wfh8C5Y1J/tixm1bU9MNgQCTD6SXL/bP1wKAHWZLWV7cORM 66dg4ZQk83JaY0Wcc4ByoVWsxRVXfIi5ALlcDdGI/2VAg+MCTTxsCfXDcFO6KyPh so6DotmuMQr+6NlYE0kvRcHeoVb6xc+vUIX9eSZMXoSlyZgMW1CuXZ4pICQHsr68 E2Km5Pp6SiuYbsVgP6G/ =Tmo2 -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 post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/8eb258e9-d6fe-5ccb-71a0-67b7d02be0b4%40qubes-os.org. For more options, visit https://groups.google.com/d/optout.