[qubes-users] HCL - Dell OptiPlex 780
The last time I tried to install Qubes onto this machine was almost two years ago. I had a lot of trouble with the install. The final result was that the system ran fine, but the HVM and IOMMU were giving me trouble. Rather than troubleshoot it, I got distracted by other shiny things. I decided to haul the machine out of the closet and give it another go. It occurred to me that I should probably update the BIOS on the computer first. It might improve the compatibility. It turns out that the machine has BIOS rev A03. Dell's last release is A15! I installed the latest BIOS. The end result is that a lot more is functional now. For anybody having trouble installing to a machine that (on paper) should meet the requirements, I recommend that you see if you've got the latest BIOS installed. (BTW, apparently the BIOS upgrade installers that run under Windows are notoriously unreliable. Many folks claim that they risk bricking the computer. You should instead use the DOS installer. It's a royal pain, but the safer route.) So anyway, I did the Qubes install. After a few hiccups, I got the thing installed. It has been running fine for a whole day now, so attached is the HCL report. -- 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/6b4dc7fc-3d0e-4d6c-b8d4-f66e1f178296%40googlegroups.com. For more options, visit https://groups.google.com/d/optout. Qubes-HCL-Dell_Inc_-OptiPlex_780_-20161120-001907.yml Description: Binary data
Re: [qubes-users] Re: Kaspersky OS
The article i read failed to mention it was close source... Totally agree if thats the case. -- 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/98bc077f-684d-4e35-92cc-419d2833da47%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Kaspersky OS
Am 20.11.2016 um 05:26 schrieb Sec Tester: > Dam maybe this could be a new super hardened VM for Qubes..? All we get is a heap of paper. And a switch I could not even pre-order yet. But I've got a few Qubes systems happily running. It might be an ideal solution for the outward-facing VMs (networking, firewall) as it is in fact a minimalistic OS for this kind of devices (or why would they have put it on a router first?). But I could just as well imagine them running on QNX which is obviously safe enouth to protect Cisco hardware (think IOS XR) (keep in mind that the Cisco vulnerabilities up to now are results from sloppily written non-core functionality modules). I even wondered briefly if it was possible to use a Mikrotik router VM on Qubes. Alas, someone has to provide it; I'm not going to do that myself. Achim -- 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/7b37ccae-7caa-613c-bb6f-3208442a83e5%40noses.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Kaspersky OS
Am 20.11.2016 um 05:44 schrieb Fabian Wloch: > And: Probably nothing will run on that Kaspersky OS, because its coded > from scratch. No browser, no email client etc. What would the be needed for? It's obviously not the intended use anyway. As soon as there is a user in front of a terminal, "hack-proofing" the system isn't possible as it is a known fact that the stated goal of nature is creating dumber and dumber users. Technology will never catch up. Achim -- 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/33d51c17-48b3-4965-2093-0e382a03d8bc%40noses.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Access all vm data from a backup-vm?
Hello dear new qubes family,
I am having trouble designing a backup concept for my qubes workstation.
My goal is to have a (daily) copy of the entire workstation on a trusted
remote backup target (versioning, encryption, rotation is done
remotely). Only a small part of the local data ("vault") would need to
be encrypted before sending it on its way.
My plan was to use a dedicated backup-vm, locked down to only connect to
the remote target.
- My first idea was to "mount --bind" the data to the backup-vm in
read-only mode. It would then do a simple rsync to the remote backup
target. This seems not to be possible, as I can't mount a directory from
outside, dom0, into the filesystem of the backup-vm. Mounting a
btrfs-snapshot would be a nice alternative, which doesn't seem to be
possible neither.
- I could use a dedicated drive, partition, or .img file to hold a copy
of all data locally and connect this back and forth between dom0 and the
backup-vm. This seems wasteful and opens security risks.
- I could serve all data via nfs to the backup-vm. This would, of
course, open security risks in enabling some kind of networking in dom0.
- I could send the backup-stream ("btrfs send", for example) to the
backup-vm and it forwards it to the remote backup target. This would
need all backup logic, programs and scripts to run in dom0. Also, I
suppose this would be an unstable solution, where (network) problems
immediately lead to a failed and broken backup (where rsync fails more
gracefully).
How do other people backup their qubes machine to a remote target?
Thank you,
N2
--
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/5831792C.3060308%40posteo.de.
For more options, visit https://groups.google.com/d/optout.
signature.asc
Description: OpenPGP digital signature
Re: [qubes-users] Access all vm data from a backup-vm?
On Sun, Nov 20, 2016 at 7:21 AM, Stickstoff wrote:
> Hello dear new qubes family,
>
> I am having trouble designing a backup concept for my qubes workstation.
> My goal is to have a (daily) copy of the entire workstation on a trusted
> remote backup target (versioning, encryption, rotation is done
> remotely). Only a small part of the local data ("vault") would need to
> be encrypted before sending it on its way.
> My plan was to use a dedicated backup-vm, locked down to only connect to
> the remote target.
>
> - My first idea was to "mount --bind" the data to the backup-vm in
> read-only mode. It would then do a simple rsync to the remote backup
> target. This seems not to be possible, as I can't mount a directory from
> outside, dom0, into the filesystem of the backup-vm. Mounting a
> btrfs-snapshot would be a nice alternative, which doesn't seem to be
> possible neither.
>
> - I could use a dedicated drive, partition, or .img file to hold a copy
> of all data locally and connect this back and forth between dom0 and the
> backup-vm. This seems wasteful and opens security risks.
>
> - I could serve all data via nfs to the backup-vm. This would, of
> course, open security risks in enabling some kind of networking in dom0.
>
> - I could send the backup-stream ("btrfs send", for example) to the
> backup-vm and it forwards it to the remote backup target. This would
> need all backup logic, programs and scripts to run in dom0. Also, I
> suppose this would be an unstable solution, where (network) problems
> immediately lead to a failed and broken backup (where rsync fails more
> gracefully).
>
>
> How do other people backup their qubes machine to a remote target?
>
>
I have a simple script in dom0 that mounts a NAS via nfs on a backupVM and
launches the default encrypted backup system.
best
Fran
Thank you,
>
> N2
>
> --
> 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/5831792C.3060308%40posteo.de.
> 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/CAPzH-qBbgPMHLjgZ76gu1D0_Z5L-nPXZpzBsmcdwWyhADzoNAA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
Re: Enigmial and Splig GPG2 (previously Re: [qubes-users] Upgrading from Split GPG1 to Split GPG2?)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Sat, Nov 19, 2016 at 09:11:21PM -0800, Andrew David Wong wrote: > On 2016-11-19 03:43, Andrew David Wong wrote: > > On 2016-11-17 10:05, cubit wrote: > >> 17. Nov 2016 15:33 by dmoer...@gmail.com: > > > >>> On Wednesday, November 16, 2016 at 10:21:33 PM UTC-5, george wrote: > Yes. I get the same issue too. I can read the message, but I can't > write, and I'm also in Debian-8 VM on Qubes 3.2, with Enigmail and > Thunderbird. I can READ messages, but I can't send them, nor > verify/encrypt/sign them. I'm not sure what to do with this... > >>> > >>> What template are you using for the gpg VM? > >>> > >> For me both my vault VM and thunderbird VM are sharing the same Debian 8 > >> template. This template does have gnupg-agent 2.0.26-6+deb8u1 installed > > > > > > Sorry, this is a known issue. Enigmail 1.9 is incompatible with Split GPG > > on Debian 8: > > > > https://github.com/QubesOS/qubes-issues/issues/2170 > > > > Until this is resolved, I recommend using the Fedora template instead. > > > > Update: 3n7r0p1 has pointed out that this is not an issue, since Enigmail 1.9 > is not contained in the Debian 8 repos to begin with. Isn't it possible to install enigmail directly from thunderbird/icedove? That would result in the most recent version. - -- 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 iQEcBAEBCAAGBQJYMYwHAAoJENuP0xzK19csvmoH/1iyLXWzIVdUm73Biza1Krbc TMjcjZX76p0KF8Oo8P7PGNuWaCHV0fKK6FRBsP28o4AH+cyVvAeYmX+qrg725lZ0 irqwxAIntrWgeqLRqArMjU+l374FmU1WD1MKoaK41H+1kA5197En3sekCNRaEqlY Iu4ct6r4550W/0r6rj3nRxuxNoqYdKSxYn6qgZ0uMfo3dKp1248q9+qAuP8j+HA7 QM51irIwpoi1t9Rm24AqmNILmAakviM1c0EwilEphrW2SJFT0pvxm/tJ7RIk55mg nl6bUU5XECUY/3x4YTAvo61AoNgIoVZg7BnguyLHW2qAdqKcVUEK5NUjb+M5UEA= =QjVB -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/20161120114157.GE1145%40mail-itl. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Access all vm data from a backup-vm?
On 11/20/2016 12:35 PM, Franz wrote:
On Sun, Nov 20, 2016 at 7:21 AM, Stickstoff wrote:
Hello dear new qubes family,
I am having trouble designing a backup concept for my qubes workstation.
My goal is to have a (daily) copy of the entire workstation on a trusted
remote backup target (versioning, encryption, rotation is done
remotely). Only a small part of the local data ("vault") would need to
be encrypted before sending it on its way.
My plan was to use a dedicated backup-vm, locked down to only connect to
the remote target.
- My first idea was to "mount --bind" the data to the backup-vm in
read-only mode. It would then do a simple rsync to the remote backup
target. This seems not to be possible, as I can't mount a directory from
outside, dom0, into the filesystem of the backup-vm. Mounting a
btrfs-snapshot would be a nice alternative, which doesn't seem to be
possible neither.
That works. Just use qvm-block from dom0 to attach your other VMs to
your backup VM. Then you can e.g. start rsync in your backup VM from
dom0 using qvm-run.
The concrete dom0 command should be
qvm-block -A [BACKUP_VM] dom0:/var/lib/qubes/appvms/[CLIENT_VM]/private.img
and then mount etc. in your backup VM using e.g. qvm-run.
read-only didn't work though the last time I tested it (you can write
anyway - probably some bug).
--
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/d9a9692a-102f-9c50-8006-11af7573cacf%40hackingthe.net.
For more options, visit https://groups.google.com/d/optout.
smime.p7s
Description: S/MIME Cryptographic Signature
Re: [qubes-users] Re: Kaspersky OS
I'm not sure if it is, or if it is open source. But he didn't mentioned it at all in his blog post ( https://eugene.kaspersky.com/2016/11/15/finally-our-own-os-oh-yes/) If I would make such an operating system, I would at least mention that it will be open source, if it would be. He didn't, and Kaspersky isn't fame for doing Free Software/publishing source code, so I guess its closed source. But it could be open source. I just don't believe so. The article i read failed to mention it was close source... Totally agree if thats the case. -- 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/15881bad170.275d.db864a7b1d5e2becb017b42ae5cd9fc6%40posteo.de. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Access all vm data from a backup-vm?
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On Sun, Nov 20, 2016 at 01:04:03PM +0100, David Hobach wrote:
> On 11/20/2016 12:35 PM, Franz wrote:
> > On Sun, Nov 20, 2016 at 7:21 AM, Stickstoff wrote:
> >
> > > Hello dear new qubes family,
> > >
> > > I am having trouble designing a backup concept for my qubes workstation.
> > > My goal is to have a (daily) copy of the entire workstation on a trusted
> > > remote backup target (versioning, encryption, rotation is done
> > > remotely). Only a small part of the local data ("vault") would need to
> > > be encrypted before sending it on its way.
> > > My plan was to use a dedicated backup-vm, locked down to only connect to
> > > the remote target.
> > >
> > > - My first idea was to "mount --bind" the data to the backup-vm in
> > > read-only mode. It would then do a simple rsync to the remote backup
> > > target. This seems not to be possible, as I can't mount a directory from
> > > outside, dom0, into the filesystem of the backup-vm. Mounting a
> > > btrfs-snapshot would be a nice alternative, which doesn't seem to be
> > > possible neither.
>
> That works. Just use qvm-block from dom0 to attach your other VMs to your
> backup VM. Then you can e.g. start rsync in your backup VM from dom0 using
> qvm-run.
>
> The concrete dom0 command should be
> qvm-block -A [BACKUP_VM] dom0:/var/lib/qubes/appvms/[CLIENT_VM]/private.img
> and then mount etc. in your backup VM using e.g. qvm-run.
This is risky. If one of your VMs is compromised, it may try to exploit
some bug in filesystem handling code, or rsync, to steal data from other
VMs.
Handling this at block device level (so do not mount, but use /dev/xvdi
as is) should be much safer. But then, you have qvm-backup tool which
handle all this for you. The disadvantage (at least for now) is copy
all the data each time - no support for incremental backups or such.
> read-only didn't work though the last time I tested it (you can write anyway
> - probably some bug).
Yes, this one:
https://github.com/QubesOS/qubes-issues/issues/2255
- --
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
iQEcBAEBCAAGBQJYMaApAAoJENuP0xzK19csIzIIAIUsmVoT3OkLxXMPdJcya1hp
LRPG+YxM09Zo8eVrMZwqGmnyew+YMb8p66yi0RMSUF2bPIoNmb0cNrfUCHzuSlXc
Hd0eQ2cBFwCvVyzepxdUobkZebNiG+zylV6hEj3T9vpVXs0QYR6vbdHe90YO8yRe
IpzzyG2/lPowNQOzbm3GN8EIISSymfuVqfFT4wXzZk2zdZAsJ63xsgO9PfAFghts
k2f0zq763WtpbDcpNjAoBSsB5OjtKbCG4tBEO8AXSEfepzMssB99QAInfcEOiq1m
L6AAcqPGUwPSj8Xa3iQ6VvnNowGjjOA2KxStmgN+XqzU5FCa/93ettIa/iukHIk=
=gj/a
-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/20161120130750.GF1145%40mail-itl.
For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Access all vm data from a backup-vm?
On Sunday, November 20, 2016 at 8:07:58 AM UTC-5, Marek Marczykowski-Górecki wrote: > This is risky. If one of your VMs is compromised, it may try to exploit > some bug in filesystem handling code, or rsync, to steal data from other > VMs. > Handling this at block device level (so do not mount, but use /dev/xvdi > as is) should be much safer. But then, you have qvm-backup tool which > handle all this for you. The disadvantage (at least for now) is copy > all the data each time - no support for incremental backups or such. what do you think of "qvm-copy-to-vm backupvm ." followed by rdiff-backup on the backupvm to luks encrypted disks? if you were using qubes-backup, how would you restore a single file or folder? -- 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/6b5d8162-ef0c-44bd-9c82-be3ad1d51c55%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Access all vm data from a backup-vm?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Sun, Nov 20, 2016 at 07:02:28AM -0800, pixel fairy wrote: > On Sunday, November 20, 2016 at 8:07:58 AM UTC-5, Marek Marczykowski-Górecki > wrote: > > > This is risky. If one of your VMs is compromised, it may try to exploit > > some bug in filesystem handling code, or rsync, to steal data from other > > VMs. > > Handling this at block device level (so do not mount, but use /dev/xvdi > > as is) should be much safer. But then, you have qvm-backup tool which > > handle all this for you. The disadvantage (at least for now) is copy > > all the data each time - no support for incremental backups or such. > > what do you think of "qvm-copy-to-vm backupvm ." followed by rdiff-backup on > the backupvm to luks encrypted disks? It's better, but personally I wouldn't do that either. > if you were using qubes-backup, how would you restore a single file or folder? Restore selected VM (under another name - it's done automatically), copy that single file to original VM, then remove restored VM. - -- 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 iQEcBAEBCAAGBQJYMb4cAAoJENuP0xzK19csAFQH/1Qb9VUHbFT9CSPMGfFmhpg7 CYSSMFZ7CkfJCnuMO3VfYJk4iACLbgBwfej5MWqnimgW5oihQdmXZ6q/qhuYmZjY MkLCvfKLcOtLMZaCjkFkPjrs8plYmmtovo8wRA89ji3L0JilnAgClQ0cc5wL7Cjb d5YFMAHemMiomWJx5pHAUJHS4hgbgXvH57Hx7OgObA8f4DTfQBXI18bVqGdgMnUK cdqze1lagALso+poNJG7p1IhJABb+FN30cTwTCwy9NudwnmQfRjShMaWKG7rXIXF H1wk9IQc5/PSo4eKlEj3h/ML/aHGlff6RQtBdO8bF4QdTVduLJfKI71CfBf6Lrw= =3S2/ -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/20161120151537.GH1145%40mail-itl. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Qubes R3.2 on Thinkpad X250: cannot install Windows 7 (hangs on "Starting Windows" at install)
On Wednesday, November 9, 2016 at 5:03:12 AM UTC-8, Pablo Di Noto wrote: > Hello, > > Never had much use for a Windows7 HVM so far. > > Months ago, I installed W7 on Qubes just for the sake of testing. Got to the > point of installing qubes-windows-tools and had some success with it, but > never used it much (in fact, never activated a license on the resulting W7 > install). > > Now I want to start from scratch, but cannot make a HVM to go further than > "Starting Windows" screen on the install phase. > > Only changes I recognize on my setup are: > - R3.2 final installed (which included several Xen updates, 4.6 to 4.6.3 IIRC) > - Got a "storage pool" enabled, to use the machine SHDD together with the > boot SSD. > > So far, tried all this: > - several W7 ISO versions (including the ones I successfully used before). > - creating the HVM with 2, 3 and 4gb of memory. > - creating the HVM on my "big storage" pool, the local SHDD, using -P option > in the qvm-create command > - creating the HVM on the original storage pool, the local boot > qubes-dom0-root volume, using the GUI to create the machine. > - using debug options on all the attempts, but logs show absolutely nothing > that I can recognize as error. > > Any pointers on what to try next, or how to debug? > > Thanks in advance! > ///Pablo New to Qubes (installed today!), and this is my first post, but I had this same problem on my Thinkpad T420 and have gotten past it. Some light google sleuthing led me to a Proxmox issue that was similar, and they suggested trying a 'cirrus' video card instead of default. Digging around in Qubes source, I found you can pass a custom config to qvm-start. I copied the config for the vm to another location (from /var/lib/qubes/vm-templates/win7/win7.conf in my case) and edited the line in domain->devices->video->model and changed the type from 'xen' to 'cirrus'. So the result looked like this: Then I started the vm with: qvm-start win7 --custom-config=[path to new config] This allowed me to get past the install hang. I haven't completed the install yet, so don't know if it'll be necessary once the install is complete. Hope that helps! Scot -- 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/97c03cc1-d5fb-4d07-80c2-25f85dc1074e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] AppVMs with pci devices attached don't start
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Sun, Nov 20, 2016 at 01:53:30PM -0500, eldor...@riseup.net wrote: > Hi! > > After upgrading dom0 and fedora-23 templates two days ago i can't run any > appvm that has pci devices like sys-net and sys-usb. > sys-net and sys-usb work after removing pci devices. > Download attachments for more info. > How can i fix this issue? Is it include also automatic starting of them during system startup? Generally starting a VM with PCI device after long system uptime is unreliable (at least) because of how Xen handle memory for such VMs (needs coherent memory area, which may not be available after running many VMs). - -- 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 iQEcBAEBCAAGBQJYMgR1AAoJENuP0xzK19csy6IH/0s9v3SmPAJPrZOIopnLcwpx de8D+7VSRMDsGwBYfRtdI0P/j3J72Jla/ju9tINXwDUZkeYHahxVGMPht389PIUt I1EGcd58vpWIdDrSUI8PfBf4uZGnR2FMd9C7irHFAFqgI+7S8c38vMQi9HXZ5Jiq mnw9QvCst2FjwRtOpJt2daSAPVx5X04AelfVEnl8jaIjkZ15doqgYuXXLFi5QN6u wYUCEx8FQTmtUveOID0mR7WsZpO778LQj68ncK34llZXgv5wwbDEcT/aeRj9CP+8 iqb+Tuk7m85iRArJqFzGpa10qcXLswIqyHtMO6HuE/p9xJ9fpc9ZBf38z0YkDJA= =yhwM -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/20161120201548.GJ1145%40mail-itl. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Fedora 24 Template for Qubes 3.1?
Hi, since Qubes 3.1 is supported until 2017-03-29 according to https://www.qubes-os.org/doc/supported-versions/ does that mean we will see a Fedora 24 template for R3.1 before Fedora 23 reaches EOL? thanks, Joonas -- 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/ca965017-c5c4-52a4-4d35-0211c994ca40%40openmailbox.org. For more options, visit https://groups.google.com/d/optout. signature.asc Description: OpenPGP digital signature
[qubes-users] No Ethernet (Broadcom BCM5764M)
Wired networking is not working on a fresh install of Qubes 3.2. The motherboard has two built-in NICs, both Broadcom NetXtreme BCM5764M PCIe (rev 10). Here's what I've tried thus far: 1. Both controllers show up correctly in the sys-net VM settings Devices tab. 2. Reboot with first one, and then the other NIC connected to the router. 3. Repeat step 2 with first one, then the other controller selected in the sys-net VM settings Devices tab. 4. Both controllers are detected by lspci in sys-net. What else might I try to enable networking? -- 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/4507d720-1141-4bb8-8b92-0fb455bdf33c%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] AppVMs with pci devices attached don't start
On 2016-11-20 15:15, Marek Marczykowski-Górecki wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Sun, Nov 20, 2016 at 01:53:30PM -0500, eldor...@riseup.net wrote: Hi! After upgrading dom0 and fedora-23 templates two days ago i can't run any appvm that has pci devices like sys-net and sys-usb. sys-net and sys-usb work after removing pci devices. Download attachments for more info. How can i fix this issue? Is it include also automatic starting of them during system startup? Generally starting a VM with PCI device after long system uptime is unreliable (at least) because of how Xen handle memory for such VMs (needs coherent memory area, which may not be available after running many VMs). - -- 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 iQEcBAEBCAAGBQJYMgR1AAoJENuP0xzK19csy6IH/0s9v3SmPAJPrZOIopnLcwpx de8D+7VSRMDsGwBYfRtdI0P/j3J72Jla/ju9tINXwDUZkeYHahxVGMPht389PIUt I1EGcd58vpWIdDrSUI8PfBf4uZGnR2FMd9C7irHFAFqgI+7S8c38vMQi9HXZ5Jiq mnw9QvCst2FjwRtOpJt2daSAPVx5X04AelfVEnl8jaIjkZ15doqgYuXXLFi5QN6u wYUCEx8FQTmtUveOID0mR7WsZpO778LQj68ncK34llZXgv5wwbDEcT/aeRj9CP+8 iqb+Tuk7m85iRArJqFzGpa10qcXLswIqyHtMO6HuE/p9xJ9fpc9ZBf38z0YkDJA= =yhwM -END PGP SIGNATURE- Yes , all of these AppVMs automatically start on boot but logs show failed. -- 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/5a59e56a247f6bebf510ccaef3db4252%40riseup.net. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: No Ethernet (Broadcom BCM5764M)
On Monday, 21 November 2016 07:26:38 UTC+11, television.v...@gmail.com wrote: > Wired networking is not working on a fresh install of Qubes 3.2. > > The motherboard has two built-in NICs, both Broadcom NetXtreme BCM5764M PCIe > (rev 10). > > Here's what I've tried thus far: > > 1. Both controllers show up correctly in the sys-net VM settings Devices tab. > 2. Reboot with first one, and then the other NIC connected to the router. > 3. Repeat step 2 with first one, then the other controller selected in the > sys-net VM settings Devices tab. > 4. Both controllers are detected by lspci in sys-net. > > What else might I try to enable networking? You need the drivers from BroadCom, and then you need to try to get them installed properly and the device to be recognised and start The drivers need to be installed in the NetVM Template. I STILL to this day can NOT get mine working. Nothing I have tried, even people that have gotten theirs to work (aparently) If you have any luck, please let me know. -- 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/479c8eeb-02e3-4f32-a465-93cc10fe65e7%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: No Ethernet (Broadcom BCM5764M)
Thanks for the reply, Drew. Sounds like a worst-case scenario, but I'll do my best. Meanwhile, if anyone else has any other pointers, please share. At least two of us could use the help! -- 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/09ea042b-d9ff-4e46-8008-92d10d5fcf6f%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Problem creating Win7 HVM
On Sunday, 20 November 2016 14:56:05 UTC+11, Sec Tester wrote: > So using the VM manager i created a Win7 HVM (not a HVM template) > > I copied over the Win7.iso to a the user directory in dom0 > > using "qvm-run --pass-io 'cat /path/to/file_in_src_domain' > > /path/to/file_name_in_dom0" > > > And ran "qvm-start win7 --cdrom=/home/myusername/Win7.iso" > > = > First attempt > = > HVM loaded, got to the stage where it starts installing files, and got an > error reading file or something along those lines. > > I assumed the Win7_64bit.iso i downloaded from microsoft got corrupted, so I > re-downloaded the .iso > > == > Second attempt > == > I deleted the previous Win7 HVM, and created a new one > > Copied over the iso and ran command to start HVM again. > > Whats happening is Now is the HVM doesnt pass the windows logo stage. it just > sits there and glows. > > I dont think that i should even see the glowing windows logo at this stage of > the install. I suspect that even tho i deleted & re-created the Win7 HVM, its > still trying to boot of the failed partial install. > === > Is there a way to check the old Win7 HVM has been completely deleted? > > Could this be another issue? > > Cheers > Is I have never had a problem installing a Win7 HVM or HVM Template. When you run it, it should juut continue. Give the guest 2 threads and AT LEAST 2 GB RAM. Anything less than that and it MAY have issues. I have had issues with less than 1024 GB RAM in the past, that is why I recommend 2 GB, and NOT BALANCED. I have a Win7Template, and I spawn all my Win7 Guests off that. If you have trouble installing it from the MS ISO, then I recommend downloading from elsewhere. http://getintopc.com/page/1/?s=Windows+7 This is the site I got an ISO from when I needed one for a specific version of Win7. The ISOs boots fine and works and I've been using it for years. Just be sure to get one that is not an AIO or something that is modified like that. Get one that is purely x86_64 and one version. -- 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/55c0424a-6b38-4726-b69b-216efcc1c8de%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Problem creating Win7 HVM
Create a template if you can too, rather than creating an HVM. Makes everything much easier. Creating an HVM is easy then. Only problem is, IF you want a STANDALONE, you have to copy the root image file to the newly created HVM directory because the qubes-manager doesn't perform the full standalone functionality IN THAT WAY. It creates a standalone that has no template nor is copied from any template. -- 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/7075c043-d4b0-42e2-b4c4-d3dec75582fc%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: No Ethernet (Broadcom BCM5764M)
On Monday, 21 November 2016 10:46:32 UTC+11, television.v...@gmail.com wrote: > Thanks for the reply, Drew. Sounds like a worst-case scenario, but I'll do my > best. > > Meanwhile, if anyone else has any other pointers, please share. At least two > of us could use the help! I've read other posts, and they all had to install the drivers. So that's why I passed that on. Fedora by default does NOT have those drivers. I don't know if any version of Linux does, but it doesn't work with GENERIC drivers. -- 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/0bd146e6-c1d7-4ec3-9378-f3e14d1cd2ee%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: Enigmial and Splig GPG2 (previously Re: [qubes-users] Upgrading from Split GPG1 to Split GPG2?)
Marek Marczykowski-Górecki: > On Sat, Nov 19, 2016 at 09:11:21PM -0800, Andrew David Wong wrote: >> On 2016-11-19 03:43, Andrew David Wong wrote: >>> On 2016-11-17 10:05, cubit wrote: 17. Nov 2016 15:33 by dmoer...@gmail.com: >>> > On Wednesday, November 16, 2016 at 10:21:33 PM UTC-5, george wrote: >> Yes. I get the same issue too. I can read the message, but I can't >> write, and I'm also in Debian-8 VM on Qubes 3.2, with Enigmail and >> Thunderbird. I can READ messages, but I can't send them, nor >> verify/encrypt/sign them. I'm not sure what to do with this... > > What template are you using for the gpg VM? > For me both my vault VM and thunderbird VM are sharing the same Debian 8 template. This template does have gnupg-agent 2.0.26-6+deb8u1 installed >>> >>> >>> Sorry, this is a known issue. Enigmail 1.9 is incompatible with Split GPG >>> on Debian 8: >>> >>> https://github.com/QubesOS/qubes-issues/issues/2170 >>> >>> Until this is resolved, I recommend using the Fedora template instead. >>> > >> Update: 3n7r0p1 has pointed out that this is not an issue, since Enigmail >> 1.9 is not contained in the Debian 8 repos to begin with. > > Isn't it possible to install enigmail directly from thunderbird/icedove? > That would result in the most recent version. > Marek is correct. When installed from the repo, enigmail updates are disabled. However, newer versions can be installed through the addons manager and such versions can also be updated via that method. Issue should be re-opened or docs should advise Debian users to install via apt-get (not a bad practice anyway). -- 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/3deb9340-2909-d6d2-9123-a56f0ecbef58%40gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: Enigmial and Splig GPG2 (previously Re: [qubes-users] Upgrading from Split GPG1 to Split GPG2?)
Marek Marczykowski-Górecki: > On Sat, Nov 19, 2016 at 09:11:21PM -0800, Andrew David Wong wrote: >> On 2016-11-19 03:43, Andrew David Wong wrote: >>> On 2016-11-17 10:05, cubit wrote: 17. Nov 2016 15:33 by dmoer...@gmail.com: >>> > On Wednesday, November 16, 2016 at 10:21:33 PM UTC-5, george wrote: >> Yes. I get the same issue too. I can read the message, but I can't >> write, and I'm also in Debian-8 VM on Qubes 3.2, with Enigmail and >> Thunderbird. I can READ messages, but I can't send them, nor >> verify/encrypt/sign them. I'm not sure what to do with this... > > What template are you using for the gpg VM? > For me both my vault VM and thunderbird VM are sharing the same Debian 8 template. This template does have gnupg-agent 2.0.26-6+deb8u1 installed >>> >>> >>> Sorry, this is a known issue. Enigmail 1.9 is incompatible with Split GPG >>> on Debian 8: >>> >>> https://github.com/QubesOS/qubes-issues/issues/2170 >>> >>> Until this is resolved, I recommend using the Fedora template instead. >>> > >> Update: 3n7r0p1 has pointed out that this is not an issue, since Enigmail >> 1.9 is not contained in the Debian 8 repos to begin with. > > Isn't it possible to install enigmail directly from thunderbird/icedove? > That would result in the most recent version. > Marek is correct. When installed from the repo, enigmail updates are disabled. However, newer versions can be installed through the addons manager and such versions can also be updated via that method. Issue should be re-opened or docs should advise Debian users to install via apt-get (not a bad practice anyway). -- 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/0eb05b6c-d586-829c-b021-ab93e60f2366%40gmail.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Any chance the freezing could be resolved?
Still getting Dom0 crash / parts not responding. Primarily it's a guest that causes the whole of Dom0 to slow and stop. I have yet to find out what the root cause it, but it's still locking things up. Sometimes after running a guest for a few hours will cause the system to start having a coronary. I'm not doing anything super intensive, only programming. IF I run ANY guest with Firefox, and have it running for a couple of days, I come back from the weekend or sometimes even 1 night, and the PC is locked up solid. At that point, not even the logging in Dom0 is working. Sometimes, as I have said before, the logging in Dom0 is still running and working but I can't get access to the machine any more and have to physically power it down to then start it up again. Which causes an fsck to be run because the filesystem wasn't cleanly unmounted. Any help on these bugs would be greatly appreciated. Mainly I find the issue is with FireFox running. I've found other guests running for days on end don't cause the system to lock up. If information for the developers is required, I would be happy to email you the details, logs, and specs. -- 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/f84e8027-cc81-4272-90ad-72288476c575%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Any chance the freezing could be resolved?
If I were you I would try to see if you can reproduce the issue with upstream xen, and then ask on the xen mailing list. It sounds more like a this-xen-version + this-linux-version on your-hardware problem than a qubes problem. -- 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/CABQWM_DKJWXD_jRU6Ou5mB%2BPiB5s3dw2LYdkF9W05ZcQ2Raajg%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Any chance the freezing could be resolved?
On Monday, 21 November 2016 12:11:39 UTC+11, Jean-Philippe Ouellet wrote: > If I were you I would try to see if you can reproduce the issue with > upstream xen, and then ask on the xen mailing list. > > It sounds more like a this-xen-version + this-linux-version on > your-hardware problem than a qubes problem. How do I reproduce the issue on upstream XEN when I run Qubes and keep working and doing my stuff without wasting several weeks on testing it on upstream XEN? Qubes is downstream XEN I assume from what you are saying, which means that the version of XEN that Qubes uses is modified in some ways? Which means that it's a different version of XEN altogether? -- 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/0f92eb7b-c958-451b-9bf3-edc28af2a69d%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Fedora 24 template available for Qubes 3.2
On 2016-11-14 23:57, Marek Marczykowski-Górecki wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Mon, Nov 14, 2016 at 11:14:19PM +, Gaijin wrote: systemctl doesn't show anything abnormal systemctl --all shows several not found inactive dead listings ex. livesys.service ntpd.service qubes-core.service qubes-dvm.service qubes-firewall.service qubes-iptables.service qubes-misc-post.service qubes-mount-dirs.service qubes-mount-home.service qubes-netwatcher.service qubes-network.service qubes-qmemman.service qubes-qrexec.service qubes-random-seed.service qubes-sysinit.service qubes-updates-proxy.service sntp.service syslog.service ypbind.service sys-log.service qubes-update-check.service Uhm, it looks like you've uninstalled qubes tools in the process... If you still have qubes repository definition in /etc/yum.repos.d/qubes-r3.repo, you can try to reinstall it: sudo dnf install qubes-core-vm-systemd It should show you what conflicts with this package (if anything). If you don't have repository definition anymore, you'll need to create it first. It should look like this: [qubes-vm-r3.2-current] name = Qubes OS Repository for VM (updates) baseurl = http://yum.qubes-os.org/r3.2/current/vm/fc$releasever gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-qubes-3-primary skip_if_unavailable=False gpgcheck = 1 enabled=1 [qubes-vm-r3.2-current-testing] name = Qubes OS Repository for VM (updates-testing) baseurl = http://yum.qubes-os.org/r3.2/current-testing/vm/fc$releasever gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-qubes-3-primary skip_if_unavailable=False gpgcheck = 1 enabled=0 [qubes-vm-r3.2-security-testing] name = Qubes OS Repository for VM (security-testing) baseurl = http://yum.qubes-os.org/r3.2/security-testing/vm/fc$releasever gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-qubes-3-primary skip_if_unavailable=False gpgcheck = 1 enabled=0 [qubes-vm-r3.2-unstable] name = Qubes OS Repository for VM (unstable) baseurl = http://yum.qubes-os.org/r3.2/unstable/vm/fc$releasever gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-qubes-3-unstable gpgcheck = 1 enabled=0 You can save some typing by using only the first section (it is enough for recovery) - save it in some other file there, like /etc/yum.repos.d/qubes-recovery.repo. You'll also need to configure network manually (as you no longer have a script which did that for you) - take a look here (procedure is very similar): https://www.qubes-os.org/doc/upgrade-to-r3.0/#upgrading-template-on-already-upgraded-dom0 - -- 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 iQEcBAEBCAAGBQJYKk+BAAoJENuP0xzK19cs7fsH/AlhudAV3YMj8xcHlq2qON9h AttdZrrbtO5GA796EP8iLhDpN1b6iV0NMIh2Wbyhxuk6+Wijs6751iJ7F3fKtldA eh9NJrssHVtgcEWMHfKmflerYWWgPUwqHztTA4vNWXxM7b4uyjxphDzSzvQpNblX W5C8QKxNhdqYLmf2n4X9FmX4hG09q4CMVwqfwk2T0T9reyv6Hbqlkj68e0sKL1Ig w4mF/gZqgDHKcHz6YDB0yJzIk0lop7mztBMYA8Dj4WSnGoVtDlPrCepffSCFogOC xfP9s0GnIjP+z7yTqSlPqpvd/PH8OsAH7Pvn1Hb8z+071SXazm0YhA95WgRecqI= =wEUi -END PGP SIGNATURE- Thanks Marek. Your advice got me pointed in the right direction. My Fedora-23 templates with software installed were still using the repository definition for R3.1, so I tried the --allowerase on the distro-sync step, and subsequently removed Qubes. (my bad) Someone may want to add your suggestion to make sure the repository definition is up-to-date to the upgrade documentation. Updating those R3.2 repository definitions in /etc/yum.repos.d/qubes-r3.repo solved my upgrade issue. I had not thought to check there. -- 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/05b07292527c3cf54c163691a0aecf6a%40riseup.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Any chance the freezing could be resolved?
On Sun, Nov 20, 2016 at 8:44 PM, Drew White wrote: > How do I reproduce the issue on upstream XEN when I run Qubes and keep > working and doing my stuff without wasting several weeks on testing it on > upstream XEN? I don't know, but seeing as you're the only person who reports experiencing this issue, nobody else can test things to try to narrow it down for you. > Qubes is downstream XEN I assume from what you are saying, which means that > the version of XEN that Qubes uses is modified in some ways? > Which means that it's a different version of XEN altogether? Well, Qubes uses a slightly patched Xen -- the applied patches can be found here: https://github.com/QubesOS/qubes-vmm-xen My suggestions for you at this point: 1) Post your output of: $ cat /etc/qubes-release $ xl dmesg | head -1 to this list 2) See if there's any way you can get a serial console on your machine. Either via Intel AMT (definitely easiest if supported) or perhaps via an internal serial header someplace (if you have the necessary hardware and technical inclination) to see if xen produces any useful log output while it is actually hanging. Make sure your xen loglvl=all while doing so (which should be already set by the qubes installer). 3) Provide a full detailed description of the behavior you exhibit to the xen-users list. (And the first thing they will probably ask is if you can still reproduce the issue with the latest upstream un-patched Xen...) -- 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/CABQWM_AS9C1CZ0wtP-ZPnM7%3Ds9jMEiO_%2BwqbQ3yFB3M8TG6N4g%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Any chance the freezing could be resolved?
Drew White: > Still getting Dom0 crash / parts not responding. > > Primarily it's a guest that causes the whole of Dom0 to slow and stop. > > I have yet to find out what the root cause it, but it's still locking things > up. > > Sometimes after running a guest for a few hours will cause the system to > start having a coronary. > > I'm not doing anything super intensive, only programming. > > > IF I run ANY guest with Firefox, and have it running for a couple of days, I > come back from the weekend or sometimes even 1 night, and the PC is locked up > solid. At that point, not even the logging in Dom0 is working. > Sometimes, as I have said before, the logging in Dom0 is still running and > working but I can't get access to the machine any more and have to physically > power it down to then start it up again. Which causes an fsck to be run > because the filesystem wasn't cleanly unmounted. > > Any help on these bugs would be greatly appreciated. > Mainly I find the issue is with FireFox running. I've found other guests > running for days on end don't cause the system to lock up. > > If information for the developers is required, I would be happy to email you > the details, logs, and specs. > Drew, Is there any chance you are using a recent (Braswell or maybe Broadwell or similar) low-end Intel CPU? If so, your problem may actually be due to a bug in the Linux kernel. For example, I recently acquired just such a system and experienced seemingly random total system freezes with Qubes 3.2 ranging anywhere from 5m to 12h after boot. What fixed the problem, or worked around it, was: -use the 4.8.* kernel in the unstable repository -change the "i915.preliminary_hw_support=1" in the kernel boot command line to "intel_idle.max_cstate=1", which limits the CPU to drawing the maximum power :-\ -(may be unnecessary) disabling DRI in my dom0 Xorg.conf (I had to create a new file): -"NoAccel" "true" -"DRI" "false" Let me know if you're affected by the same bug. Cheers, Andrew -- 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/3f83c214-81f9-e9ff-81c0-139561ab2bf5%40riseup.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Any chance the freezing could be resolved?
(will post a copy of this on the xen users forum as well as here on the qubes
users forum.)
On Monday, 21 November 2016 13:40:02 UTC+11, Jean-Philippe Ouellet wrote:
> On Sun, Nov 20, 2016 at 8:44 PM, Drew White wrote:
> > How do I reproduce the issue on upstream XEN when I run Qubes and keep
> > working and doing my stuff without wasting several weeks on testing it on
> > upstream XEN?
>
> I don't know, but seeing as you're the only person who reports
> experiencing this issue, nobody else can test things to try to narrow
> it down for you.
>
> > Qubes is downstream XEN I assume from what you are saying, which means that
> > the version of XEN that Qubes uses is modified in some ways?
> > Which means that it's a different version of XEN altogether?
>
> Well, Qubes uses a slightly patched Xen -- the applied patches can be
> found here: https://github.com/QubesOS/qubes-vmm-xen
I'll have to take a look at that again, I have the code here.
> My suggestions for you at this point:
>
> 1) Post your output of:
> $ cat /etc/qubes-release
> $ xl dmesg | head -1
> to this list
[{user}@dom0 {folder}]$ cat /etc/qubes-release
Qubes release 3.2 (R3.2)
[{user}@dom0 {folder}]$ xl dmesg | head -1
Xen 4.6.1-20.fc23
[{user}@dom0 {folder}]$
> 2) See if there's any way you can get a serial console on your
> machine. Either via Intel AMT (definitely easiest if supported) or
> perhaps via an internal serial header someplace (if you have the
> necessary hardware and technical inclination) to see if xen produces
> any useful log output while it is actually hanging. Make sure your xen
> loglvl=all while doing so (which should be already set by the qubes
> installer).
Nope, no possibility.
When the PC freezes completely EVERYTHING stops, the whole thing is no longer
responding and no processes function.
When the system background logging continues (crond) which I set up to log
things every 5 minutes on every virtual as well as dom0.
> 3) Provide a full detailed description of the behavior you exhibit to
> the xen-users list. (And the first thing they will probably ask is if
> you can still reproduce the issue with the latest upstream un-patched
> Xen...)
I leave system on for a couple of days, sometimes even a day, or over night, or
sometimes even while I'm using it...
It locks up.
Sometimes logging continues, sometimes it doesn't. (my crond logging script)
I only have 50 guests.
I only have maybe 10-15 running at any one time.
Normally they use 2048 GB RAM each, not balanced.
Some I have set to 1024 GB RAM, such as NetVM or ProxyVM or other Guests that
do not do much other than file sharing, or inter-vm operations or just a
firewall. (or dos / my own / others)
--
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/fde60e9c-e430-4093-b016-d1a4ecfa6c22%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Any chance the freezing could be resolved?
On Monday, 21 November 2016 14:31:10 UTC+11, Andrew wrote: > Drew White: > > Still getting Dom0 crash / parts not responding. > > > > Primarily it's a guest that causes the whole of Dom0 to slow and stop. > > > > I have yet to find out what the root cause it, but it's still locking > > things up. > > > > Sometimes after running a guest for a few hours will cause the system to > > start having a coronary. > > > > I'm not doing anything super intensive, only programming. > > > > > > IF I run ANY guest with Firefox, and have it running for a couple of days, > > I come back from the weekend or sometimes even 1 night, and the PC is > > locked up solid. At that point, not even the logging in Dom0 is working. > > Sometimes, as I have said before, the logging in Dom0 is still running and > > working but I can't get access to the machine any more and have to > > physically power it down to then start it up again. Which causes an fsck to > > be run because the filesystem wasn't cleanly unmounted. > > > > Any help on these bugs would be greatly appreciated. > > Mainly I find the issue is with FireFox running. I've found other guests > > running for days on end don't cause the system to lock up. > > > > If information for the developers is required, I would be happy to email > > you the details, logs, and specs. > > > > Drew, > > Is there any chance you are using a recent (Braswell or maybe Broadwell > or similar) low-end Intel CPU? If so, your problem may actually be due > to a bug in the Linux kernel. > > For example, I recently acquired just such a system and experienced > seemingly random total system freezes with Qubes 3.2 ranging anywhere > from 5m to 12h after boot. What fixed the problem, or worked around it, > was: > -use the 4.8.* kernel in the unstable repository > -change the "i915.preliminary_hw_support=1" in the kernel boot command > line to "intel_idle.max_cstate=1", which limits the CPU to drawing the > maximum power :-\ > -(may be unnecessary) disabling DRI in my dom0 Xorg.conf (I had to > create a new file): > -"NoAccel" "true" > -"DRI" "false" > > Let me know if you're affected by the same bug. > > Cheers, > Andrew I honestly don't know. Perhaps you can see the info and let me know if it's similar to yours? -- 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/83d40493-94da-432c-b5ef-770d30fb1d71%40googlegroups.com. For more options, visit https://groups.google.com/d/optout. # dmidecode 3.0 Getting SMBIOS data from sysfs. SMBIOS 2.5 present. Handle 0x0400, DMI type 4, 40 bytes Processor Information Socket Designation: CPU1 Type: Central Processor Family: Xeon Manufacturer: Intel ID: C2 06 02 00 FF FB EB BF Signature: Type 0, Family 6, Model 44, Stepping 2 Flags: FPU (Floating-point unit on-chip) VME (Virtual mode extension) DE (Debugging extension) PSE (Page size extension) TSC (Time stamp counter) MSR (Model specific registers) PAE (Physical address extension) MCE (Machine check exception) CX8 (CMPXCHG8 instruction supported) APIC (On-chip APIC hardware supported) SEP (Fast system call) MTRR (Memory type range registers) PGE (Page global enable) MCA (Machine check architecture) CMOV (Conditional move instruction supported) PAT (Page attribute table) PSE-36 (36-bit page size extension) CLFSH (CLFLUSH instruction supported) DS (Debug store) ACPI (ACPI supported) MMX (MMX technology supported) FXSR (FXSAVE and FXSTOR instructions supported) SSE (Streaming SIMD extensions) SSE2 (Streaming SIMD extensions 2) SS (Self-snoop) HTT (Multi-threading) TM (Thermal monitor supported) PBE (Pending break enabled) Version: Not Specified Voltage: Unknown External Clock: 6400 MHz Max Speed: 3800 MHz Current Speed: 2666 MHz Status: Populated, Enabled Upgrade: Socket LGA771 L1 Cache Handle: 0x0700 L2 Cache Handle: 0x0701 L3 Cache Handle: 0x0704 Serial Number: Not Specified Asset Tag: Not Specified Part Number: Not Specified Core Count: 6 Core Enabled: 6 Thread Count: 2 Characteristics: 64-bit capable Handle 0x0401
Re: [qubes-users] Any chance the freezing could be resolved?
On Monday, 21 November 2016 14:31:10 UTC+11, Andrew wrote: > Drew White: > > Still getting Dom0 crash / parts not responding. > > > > Primarily it's a guest that causes the whole of Dom0 to slow and stop. > > > > I have yet to find out what the root cause it, but it's still locking > > things up. > > > > Sometimes after running a guest for a few hours will cause the system to > > start having a coronary. > > > > I'm not doing anything super intensive, only programming. > > > > > > IF I run ANY guest with Firefox, and have it running for a couple of days, > > I come back from the weekend or sometimes even 1 night, and the PC is > > locked up solid. At that point, not even the logging in Dom0 is working. > > Sometimes, as I have said before, the logging in Dom0 is still running and > > working but I can't get access to the machine any more and have to > > physically power it down to then start it up again. Which causes an fsck to > > be run because the filesystem wasn't cleanly unmounted. > > > > Any help on these bugs would be greatly appreciated. > > Mainly I find the issue is with FireFox running. I've found other guests > > running for days on end don't cause the system to lock up. > > > > If information for the developers is required, I would be happy to email > > you the details, logs, and specs. > > > > Drew, > > Is there any chance you are using a recent (Braswell or maybe Broadwell > or similar) low-end Intel CPU? If so, your problem may actually be due > to a bug in the Linux kernel. > > For example, I recently acquired just such a system and experienced > seemingly random total system freezes with Qubes 3.2 ranging anywhere > from 5m to 12h after boot. What fixed the problem, or worked around it, > was: > -use the 4.8.* kernel in the unstable repository > -change the "i915.preliminary_hw_support=1" in the kernel boot command > line to "intel_idle.max_cstate=1", which limits the CPU to drawing the > maximum power :-\ > -(may be unnecessary) disabling DRI in my dom0 Xorg.conf (I had to > create a new file): > -"NoAccel" "true" > -"DRI" "false" > > Let me know if you're affected by the same bug. > > Cheers, > Andrew I have no second CPU in the system at the moment. Not the extra RAM. That' shwy it says there is a second, but there is none. I have no Xorg.conf anywhere on my system to alter or move and create a new. So you did EVERYTHING there at once? Or did you do one thing, check it, then try a different thing, check it, then when they didn't work on their own you tried them in combination? -- 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/3e1da9be-e7f1-4e21-b022-f8e3ecc66232%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Qubes not shutting down
On Wednesday, November 16, 2016 at 3:13:26 PM UTC-5, Loren Rogers wrote: > On 11/16/2016 02:33 PM, Grzesiek Chodzicki wrote: > > W dniu środa, 16 listopada 2016 20:04:14 UTC+1 użytkownik Loren Rogers > > napisał: > >> Hi all, > >> > >> I've successfully installed Qubes on my Thinkpad X201 tablet, but it has > >> issues shutting down. When I explicitly tell it to reboot or shutdown, > >> it goes through the entire shutdown sequence, but hangs on an empty > >> black screen. Occasionally, I see an unchanging white underscore (_) > >> character displayed in the top left when it hangs. > >> > >> I tried leaving it in this state for about an hour, and no change--I've > >> always had to force-reset. I assume this is not normal? > >> > >> Also, I find that the system randomly begins the shutdown sequence on > >> its own. (And hangs on the black screen at the end.) > >> > >> Thanks, > >> Loren > > The same issue occurs on my system only if I shut the system down while a > > VM with a PCI device without FLR support is running > > Interesting - thanks for the info. Are you saying it doesn't shut down, > or that it shuts down automatically? ya i just usually have to shutdown all vms except for the sys-vms that autostart. -- 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/e79e7d8f-f42e-42f9-99d2-3cd4d303af22%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Access all vm data from a backup-vm?
On Sunday, November 20, 2016 at 10:15:44 AM UTC-5, Marek Marczykowski-Górecki wrote: > > what do you think of "qvm-copy-to-vm backupvm ." followed by rdiff-backup > > on the backupvm to luks encrypted disks? > > It's better, but personally I wouldn't do that either. how would you do incremental backups? would lvm/btrfs/zfs snapshots on the backup volume work? > > if you were using qubes-backup, how would you restore a single file or > > folder? > > Restore selected VM (under another name - it's done automatically), > copy that single file to original VM, then remove restored VM. just tried that, it complained that there was already a vm of the same name. did you mean to rename the original and then restore the old name? it would be nice to have it offer to restore foo to foo_backup- with out networking and maybe even start the file browser or shell -- 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/95d82edc-665b-4f50-8208-53ac06992686%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Qubes not shutting down
On Sunday, 20 November 2016 04:56:03 UTC+11, Loren Rogers wrote: > Another correlation I've noticed is that my machine randomly shuts > itself down without warning when I'm browsing in the Anon-Whonix VM. It > seems that simply having the Whonix browser open causes the problem. > I've not been able to pin down an exact cause, but it seems to happen > after about 5-20min. When this happens, the machine sometimes ends up in > a hung state (black screen) at the end of the shutdown process. > > I've also noticed that the fan speeds up right at it starts to shutdown. > (The screen turns to the Qubes logo with the progress bar, then the fan > cranks up.) Sometimes the bar makes it all the way to the end, other > times it seems to simply crash to a hault. As I mentioned elsewhere, the > Thinkpad X201t is known to have overheating issues, but I'm not sure if > this is related. I'm not working the machine particularly hard (just > browsing articles on the web), and the hardware is not particularly hot > to the touch. When it gets to the qubes logo screen, press ESC to see what it's actually doing. If you wish to always know what it's doing, turn off rhgb and quiet in the boot config. Then you will see where the issue is. -- 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/ecb10d01-4853-427c-b41d-44851607bb6f%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
