Re: [qubes-users] I am unable to verify my image. Please help?
On 01/25/2018 03:33 PM, Optimal Joy wrote: Hi. New to Qubes, just downloading it, and wish to verify my image. I have downloaded my images and keys. Also got the master signing key. user Downloads # wget https://mirrors.kernel.org/qubes/iso/Qubes-R3.2-x86_64.iso && wget https://keys.qubes-os.org/keys/qubes-release-3-signing-key.asc && wget https://mirrors.kernel.org/qubes/iso/Qubes-R3.2-x86_64.iso.asc ... snip ... I have these files now in my ~/Downloads directory: -rw-r--r-- 1 elliot elliot 1.6K Jan 25 11:21 qubes-master-signing-key.asc -rw-r--r-- 1 root root819 Sep 20 2016 Qubes-R3.2-x86_64.iso.asc -rw-r--r-- 1 root root 4.0G Sep 20 2016 Qubes-R3.2-x86_64.iso -rw-r--r-- 1 root root 2.4K Nov 19 2014 qubes-release-3-signing-key.asc I tried this command earlier to fetch the qubes-master key, ~/Downloads $ gpg2 --fetch-keys https://keys.qubes-os.org/keys/qubes-master-signing-key.asc gpg: requesting key from 'https://keys.qubes-os.org/keys/qubes-master-signing-key.asc' gpg: WARNING: unable to fetch URI https://keys.qubes-os.org/keys/qubes-master-signing-key.asc: General error Since it wasn't working, I manually downloaded the file from the Qubes site, however I am afraid that I only have the file, but have not imported the public key. When trying to verify the iso, I get the following error: Downloads # gpg2 --verify Qubes-R3.2-x86_64.iso.asc Qubes-R3.2-x86_64.iso gpg: Signature made Tue 20 Sep 2016 10:33:37 AM PDT using RSA key ID 03FA5082 gpg: Can't check signature: No public key How can I download/get my Public Key manually? Or what could be wrong with my fetch? Help, thanks! If you have the key files on disk, use --import: $ gpg2 --import qubes-master-signing-key.asc $ gpg2 --import qubes-release-3-signing-key.asc Then use --edit-key to set trust level to 4 on master key: $ gpg2 --edit-key 36879494 gpg> trust gpg> save Then check that master<>release signatures are valid: $ gpg2 --check-sigs You'll see the release key as "uid ... Qubes OS Release 3 Signing Key" and directly underneath a line like: "sig! DDFA1A3E36879494 2017-03-08 Qubes Master Signing Key" After all of this, the thing that validates the Signing key is "sig!". It shows the Release key has been signed by the Master key and "!" means the signature is valid. At this point, if you have taken care to verify the Master key by retrieving it or viewing its fingerprint through other channels, then your keys are all set. (Some people skip most of this and only import the Singing key and verify its fingerprint, but I digress.) You can now do the --verify step. -- 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/05229c42-86d5-eaa8-9881-ef86c6a59d9d%40posteo.net. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Qubes 4.0 Documentation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 2018-01-25 12:28, awokd wrote: > Resuming working my way through splitting up the documentation now > that the 3.2 vs. 3.3 question has been mostly settled. Some > general questions: > > 1. Should I open an issue for tracking and move the discussion > over there? Move to qubes-devel? Keep here? Please open an issue in qubes-issues. (Doing so does not preclude discussion here or on qubes-devel.) > 2. The command line tools in particular > (https://www.qubes-os.org/doc/vm-tools/ and > https://www.qubes-os.org/doc/dom0-tools/) seem Wrong to try to > share the same pages for 3.2 and 4.0. Not only is the selection of > commands slightly different between versions, but many have > slightly different options ("-a" vs. "a"). I'm thinking of copying > all the existing pages, appending "4" so they can be linked to > directly, and putting in their own section. Thoughts? Those pages are automatically generated from the man pages stored with the tools' source code in their own respective repos, so any changes to those pages in qubes-doc will be overwritten. Changes should be made to the original files instead. That way, the changes will persist when the qubes-doc versions are automatically generated. I agree that the tool man pages should not be shared between 3.2 and 4.0 (but they probably wouldn't be anyway, due to the nature of the system just described). > 3. Some of these documents are pretty outdated. Should we have an > Archive link and move stuff like > https://www.qubes-os.org/doc/template/fedora/upgrade-18-to-20/ to > it so it doesn't clutter up the main Docs page? > There are two categories of outdated documents: 1. Documents that we want updated (but that no one has updated yet). 2. Documents that are about old topics (but are otherwise good). I don't think it would make sense to move documents of category 1 into an archive section, since that would incorrectly suggest that we don't want or expect them to be updated. The old Fedora upgrade documents fall into category 2. However, it looks like they (and perhaps the release notes for unsupported Qubes versions) are the only major offenders visible in the main table of contents. This is understandable, since a new version of the document gets added each time there's a new version of the corresponding software. I think it makes sense to handle these cases specifically, by creating a page that collects all the versions of each one. I'll do this now. In general, it's worth thinking about whether we even want to keep severely outdated category 2 documentation around. Does it have any value anymore, or will it just produce misleading search results? (Note that it will all remain permanently archived in the git revision history, so it's mainly a question of visibility on the website.) - -- Andrew David Wong (Axon) Community Manager, Qubes OS https://www.qubes-os.org -BEGIN PGP SIGNATURE- iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAlpqojUACgkQ203TvDlQ MDDG4Q//Q6ND5fzToFv6KKQn4SzkcUSIIZQKtMPTlG9BkC7UCgjFZ+7sxrLA1N5X H+9Z88+QNRL6FBOa6DHpFZOOA6vomzw0HXkTF+g9VcplsJIFZh6iB7lpSta1XwKU 1DG+ayF0oDd8PxKtSjaslMWRsr9p9cApPM7G+z6sGLB34LLZfolx19FRhwcpfBBK 09wyaAzmr5sF9oO8rSxC1llz5u75GatXUu+tHIc3Jh9C4hBtX7MSwyoq7eTkXnKQ VpS35O8thmhm6cEuyNQsUD7ia853lWRcdTur1Am7GIx3jwl7VBQ6YCqanLRLueaI tm4LbBfNrZcxFexHp0mB+veDeIfkC4cJZm8/sbjrHEicK6Cuvp5E0E6iLOaMw9gI y3D1ypbEwMXyYQFPWW0h488pNow9RCrTHTcvBhgyIBw0xhCe0j89RZpbV3UB79k1 n5YRoj36XXRmHho/KVIlFMrzsXE6q9sawU8P1/Q7mBjX3fQLDoOEwFMtHRZTiFLk NOkqv328xsqJy1smKgfFI4cpNMa1+Be0zGjqRWjBFNTqWEoNPkAbDbhbiwYPZYop CW0lDS6b6dc2KCMcxlP+3BwuFC+pS9Yw/Qw2B0yceVjrH0YnLoVkOaqC6ojGx6DH JAFtJLB6FbXssbK3JASOvGKpMxcktfQe3quJZmTaMY2yLkBaomA= =8MfO -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/fcd0e17f-4deb-cea5-b4f8-d62ea2a34b95%40qubes-os.org. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: [qubes-announce] [UPDATE] QSB #37: Information leaks due to processor speculative execution bugs (XSA-254, Meltdown & Sepctre)
On 2018-01-25 13:33, awokd wrote: > On Thu, January 25, 2018 10:51 pm, yreb...@riseup.net wrote: > >> *by this if I ran sudo qubes-dom0-update >> --enablerepo=qubes-dom0-security-testing*once, I take it , that >> I am still on the Stable Track "repo" so somehow magically I >> have the current testing Xen version (I checked and do), but when the >> security Xen goes to Stable , they will just be integrated . so >> currently I have a combination of 1 time security Xen and the rest is >> "current" (Not testing) ? > > Exactly! sorry, plz just disregard, restart the AppVM disappears , guess I don't need to 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/f11fe0f4034c1950f36eb761d84d578a%40riseup.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: [qubes-announce] [UPDATE] QSB #37: Information leaks due to processor speculative execution bugs (XSA-254, Meltdown & Sepctre)
On 2018-01-25 13:33, awokd wrote: > On Thu, January 25, 2018 10:51 pm, yreb...@riseup.net wrote: > >> *by this if I ran sudo qubes-dom0-update >> --enablerepo=qubes-dom0-security-testing*once, I take it , that >> I am still on the Stable Track "repo" so somehow magically I >> have the current testing Xen version (I checked and do), but when the >> security Xen goes to Stable , they will just be integrated . so >> currently I have a combination of 1 time security Xen and the rest is >> "current" (Not testing) ? > > Exactly! fwiw, I am noticing "qrexec not connected" in AppVM triangle in the GUI Manager on what appears to be a normal operating AppVM , but think I saw it on a frozen HVM before rebooting is this of any particular concern .or possibly related to the new Testing Xen packages? -- 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/ba5150aa517babac1bf3c064cb73d747%40riseup.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: [qubes-announce] [UPDATE] QSB #37: Information leaks due to processor speculative execution bugs (XSA-254, Meltdown & Sepctre)
On Thu, January 25, 2018 10:51 pm, yreb...@riseup.net wrote: > *by this if I ran sudo qubes-dom0-update > --enablerepo=qubes-dom0-security-testing*once, I take it , that > I am still on the Stable Track "repo" so somehow magically I > have the current testing Xen version (I checked and do), but when the > security Xen goes to Stable , they will just be integrated . so > currently I have a combination of 1 time security Xen and the rest is > "current" (Not testing) ? Exactly! -- 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/07ea481657628bfab2ee108e36be7883.squirrel%40tt3j2x4k5ycaa5zt.onion. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: [qubes-announce] [UPDATE] QSB #37: Information leaks due to processor speculative execution bugs (XSA-254, Meltdown & Sepctre)
On 2018-01-24 23:20, awokd wrote: > On Thu, January 25, 2018 2:17 am, yreb...@riseup.net wrote: >> On 2018-01-24 15:12, Andrew David Wong wrote: > >>> >>> These packages will migrate from the security-testing repository to the >>> current (stable) repository over the next two weeks after being tested >>> by the community. >> >> >> 1) >> The latter (security) packages will migrate, I'd assume this means ? > > Yes, this is the standard model for deploying all updates including > security. They appear in testing first for bleeding edge users, then > stable for everyone. Sometimes bugs are found in the testing phase causing > the package to be pulled, so unless you are comfortable rolling back > packages yourself you should leave it on stable. > >> 2) >> Where would I find the repositories in dom0 for the track I'm currently >> using? > > If you haven't changed it manually, you are on stable. > >> 3) >> after doing the 1x securitytesting repo update, how do I check which Xen >> package is now installed? > > In dom0, "dnf list installed". > >> and/or how do I bring up the GUI >> update manager when it doesn't actually need to update it doesn't persist > > No GUI, but in dom0 you can force it to check for updates with "sudo > qubes-dom0-update". Might not be following your question here. Mostly, got it. Just the one item I'm unsure about. @URL: https://www.qubes-os.org/doc/software-update-dom0/ it mentions: -- To temporarily enable any of these repos, use the --enablerepo= option. Example commands: sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing sudo qubes-dom0-update --enablerepo=qubes-dom0-security-testing sudo qubes-dom0-update --enablerepo=qubes-dom0-unstable To enable or disable any of these repos permanently, change the corresponding boolean in /etc/yum.repos.d/qubes-dom0.repo. -- *by this if I ran sudo qubes-dom0-update --enablerepo=qubes-dom0-security-testing*once, I take it , that I am still on the Stable Track "repo" so somehow magically I have the current testing Xen version (I checked and do), but when the security Xen goes to Stable , they will just be integrated . so currently I have a combination of 1 time security Xen and the rest is "current" (Not testing) ? -- 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/a80d2cd6a26c9e89b67949a414f96f9d%40riseup.net. For more options, visit https://groups.google.com/d/optout.
[qubes-users] I am unable to verify my image. Please help?
Hi. New to Qubes, just downloading it, and wish to verify my image. I have downloaded my images and keys. Also got the master signing key. user Downloads # wget https://mirrors.kernel.org/qubes/iso/Qubes-R3.2-x86_64.iso && wget https://keys.qubes-os.org/keys/qubes-release-3-signing-key.asc && wget https://mirrors.kernel.org/qubes/iso/Qubes-R3.2-x86_64.iso.asc ... snip ... I have these files now in my ~/Downloads directory: -rw-r--r-- 1 elliot elliot 1.6K Jan 25 11:21 qubes-master-signing-key.asc -rw-r--r-- 1 root root819 Sep 20 2016 Qubes-R3.2-x86_64.iso.asc -rw-r--r-- 1 root root 4.0G Sep 20 2016 Qubes-R3.2-x86_64.iso -rw-r--r-- 1 root root 2.4K Nov 19 2014 qubes-release-3-signing-key.asc I tried this command earlier to fetch the qubes-master key, ~/Downloads $ gpg2 --fetch-keys https://keys.qubes-os.org/keys/qubes-master-signing-key.asc gpg: requesting key from 'https://keys.qubes-os.org/keys/qubes-master-signing-key.asc' gpg: WARNING: unable to fetch URI https://keys.qubes-os.org/keys/qubes-master-signing-key.asc: General error Since it wasn't working, I manually downloaded the file from the Qubes site, however I am afraid that I only have the file, but have not imported the public key. When trying to verify the iso, I get the following error: Downloads # gpg2 --verify Qubes-R3.2-x86_64.iso.asc Qubes-R3.2-x86_64.iso gpg: Signature made Tue 20 Sep 2016 10:33:37 AM PDT using RSA key ID 03FA5082 gpg: Can't check signature: No public key How can I download/get my Public Key manually? Or what could be wrong with my fetch? Help, thanks! -- 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/bfcd7e1e-fc52-4340-87bd-e34f8c15187a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Please help with custom template build
On Tuesday, 23 January 2018 17:36:00 UTC, Krišjānis Gross wrote: > Hi, > > I am trying to build a custom installation .iso. I have an issue that I have > purchased a new set of hardware that does not work with the current builds of > qubes. I am trying to build the most updated version with hope that it could > work. > > I am running a Fedora linux and trying to build with these instructions: > https://www.qubes-os.org/doc/building-archlinux-template/ > > I use the ./setup to create the installation configuration. > > make install-deps goes fine. > make get-sources goes smooth as well > > but I get an error when running the mage qubes command. > Here is what I get: > > [krish@localhost qubes-builder]$ make qubes > Currently installed dependencies: > git-2.14.3-2.fc27.x86_64 > rpmdevtools-8.10-3.fc27.noarch > rpm-build-4.14.0-2.fc27.x86_64 > createrepo-0.10.3-12.fc27.noarch > debootstrap-1.0.92-1.fc27.noarch > dpkg-dev-1.18.24-3.fc27.noarch > python2-sh-1.12.14-2.fc27.noarch > dialog-1.3-10.20170509.fc27.x86_64 > dpkg-dev-1.18.24-3.fc27.noarch > debootstrap-1.0.92-1.fc27.noarch > PyYAML-3.12-5.fc27.x86_64 > make[1]: Entering directory '/home/krish/qubes-builder' > -> Preparing fc25 build environment > -> Initializing RPM database... > -> Retreiving core RPM packages... > -> Verifying signatures... > Filename: > /home/krish/qubes-builder/cache/fc25/base_rpms/acl-2.2.52-13.fc25.x86_64.rpm > is not signed. Exiting! > make[1]: *** > [/home/krish/qubes-builder/qubes-src/builder-fedora/Makefile.fedora:86: > /home/krish/qubes-builder/chroot-fc25/home/user/.prepared_base] Error 1 > make[1]: Leaving directory '/home/krish/qubes-builder' > make: *** [Makefile:224: vmm-xen-dom0] Error 1 > > > Does anyone has an idea of what I do wrong or how to resolve this? > I have attached the builder.conf file that I have. Like in installing Fedora 25 on the system and perform the build procedure on that? Will give it a try. Thank You for 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/5929b0fe-f056-48a6-9678-5ddeedd82c14%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Installation error: need at least 3mb more on /boot/efi
Thanks for the lenghty response! Indeed the errors were python-code related, but it turns out the problem was in the sys-net domain not starting correctly because of the card reader, which was seemingly seen as a network adapter. Now that I fixed that everything seems to work properly and I'm loving it. One last thing: I set qubes to update packages over tor. I immediately regretted the decision. Is there a way to download update w/o Tor? 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/969f7165-a2bd-43fd-bdf4-fffc5741999d%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: i3 under Qubes 4 RC3
i3 has been working fine for me. Did you follow the installation instructions on https://www.qubes-os.org/doc/i3/? Specifically: $ sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing i3-settings-qubes What do you mean you cannot start any programs from vms? How are you trying to start programs? For me I have mod4+d to use dmenu. And do you mean to say that qvm-run works correctly? -- 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/b05a4107-dcf1-4ee2-9102-75d767fd063b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Qubes 4.0 Documentation
Resuming working my way through splitting up the documentation now that the 3.2 vs. 3.3 question has been mostly settled. Some general questions: 1. Should I open an issue for tracking and move the discussion over there? Move to qubes-devel? Keep here? 2. The command line tools in particular (https://www.qubes-os.org/doc/vm-tools/ and https://www.qubes-os.org/doc/dom0-tools/) seem Wrong to try to share the same pages for 3.2 and 4.0. Not only is the selection of commands slightly different between versions, but many have slightly different options ("-a" vs. "a"). I'm thinking of copying all the existing pages, appending "4" so they can be linked to directly, and putting in their own section. Thoughts? 3. Some of these documents are pretty outdated. Should we have an Archive link and move stuff like https://www.qubes-os.org/doc/template/fedora/upgrade-18-to-20/ to it so it doesn't clutter up the main Docs page? -- 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/d53c8644bc985ae4263f1f5ec25a7622.squirrel%40tt3j2x4k5ycaa5zt.onion. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Save virtual machine state?
On pausing: Remember that there are some issues. For example, the VMs resume after sleep&resume. Also, it seems it does not work well with changes of monitor configuration. On hibernation: This can work with standalone VMs, but it is problematic by design on template-based (although probably possible) VMs. once you hibernate a VM, you need to remember all the state, including the root filesystem. Unlike traditional systems, the root device can be updated outside the VM, just by running the TemplateVM. In such case, Qubes has to ensure that the VM won't see the changes before reboot. Qubes has some ways to achieve this for running VMs (you see, you don't need to shut the template-based VMs down when updating the template), but it probably degrades some performance. Having to maintain it for some forgotten hibernated VMs would be some unexpected source of performance hit. So, it would be probably technically feasible (though maybe not easy), but hard for UX. Regards, Vít Šesták 'v6ak' -- 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/53c68803-2ed6-433c-bafa-ee12ffc123f4%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: "Qubes Air: Generalizing the Qubes Architecture" by Joanna Rutkowska
Raspberry Pi as a DVM is not that easy, but it is probably possible: 1. Let's have an image for the "VM" in your laptop. 2. Insert a SD card to the laptop and dd the image. 3. Boot Raspberry Pi. This assumes that: * You perform this every time you want a clean state. * Raspberry Pi has no persistent storage outside of the SD card. * MicroSD card cannot be hacked (e.g., Raspberry Pi cannot overwrite the firmware). * Your laptop is not configured to parse anything from the card. (If it is not that case, it could try to compromise your laptop.) Regards, Vít Šesták 'v6ak' -- 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/8286b8c8-4b3c-4980-88a0-7bc77d87be83%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: GPU?
On January 25, 2018 5:56:41 PM GMT+01:00, "taii...@gmx.com" wrote: >On 01/18/2018 04:00 PM, Alex Dubois wrote: >Correct me if I am wrong but I don't see the issue with an apparmor >restricted qemu running in dom0... Well, AppArmor might reduce the attack surface, but remember that: 1. Qubes was not intended to run QEMU in dom0 and 2. Qubes dom0 is often based on outdated Fedora. While ITL provides security updates for security-critical components, it does not necessarily cover all vulnerabilities in kernel and apparmor, because of #1. 3. Linux kernel is considered as quite weaker than Xen in terms of attack surface, so exploits in Linux kernel are more likely. AppArmor might mitigate *some* of them, but not all. Regards, Vít Šesták 'v6ak' -- 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/203975FF-A8A0-4EEF-8C0B-20AC09EC19EE%40v6ak.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: GPU?
On 01/18/2018 04:00 PM, Alex Dubois wrote: If you have multiple GPU (i.e. integrated + NVidia), it is possible with Xen to do GPU pass-through (Assign the NVidia GPU to a dedicated VM) however: - It is far from trivial and only limited setups are known to work - The security of it is not as robust (I can't remember where I read that, I think it was in the GPU Pass-through page of the Xen wiki) I have tried with limited success few years back (only one boot and was never able to get it back after)... I do this all the time to play games and watch movies. I recommend either a quality server board or a platform that has libre or open source firmware so that IOMMU issues can be fixed if they happen. Correct me if I am wrong but I don't see the issue with an apparmor restricted qemu running in dom0... -- 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/b959b86d-f0b4-1f76-19d7-58493c07a3e5%40gmx.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Installation error: need at least 3mb more on /boot/efi
On Thursday, January 25, 2018 at 4:28:30 PM UTC+1, dark...@gmail.com wrote: > I'm back and you were right! There was some efi junk on ssd that once deleted > let me install smoothly. Although I'm now facing another issue: when I boot > up for the first time, the qubes configuration goes all the way until a point > when it gives me a pci-related error (I'll try reproducing it again but I > dumbly closed the window). Anyways, the os let's me enter the desktop nd > I can't open VMs. This means that whatever VM I click on won't open. The only > VM that opens is sys-usb. > Regards Were it by any chance python code errors? and happening the moment you tried to configure new VM's, network, etc. during the last step after first boot? In which case, you can solve it either by identifying missing UEFI/BIOS settings, updating UEFI/BIOS (be sure you know what you do first, so you don't brick your hardware here), and lastly but not least, you can pull out the HDD/SSD/NMMe, whichever you use, and then put it in another computer. Install Qubes, fully update Qubes, and then pull the drive back out and put it back in your original machine. I've successfully done this a few times to bypass the Qubes 4 errors and other installation issues that normally are fixed with updates, but are not fixed in the install medium. This in particular helps in Qubes 4, where this step frequently happens during the last setup step on first boot on the Qubes 4 RC-1 / RC-2 and RC-3. Hopefully RC-4 is free of this issue. Precausions!! 1): Using this method, it's best to only install with Grub, unless you know your way around UEFI/EFI install paths. If you use UEFI/EFI, then not only will it be tricky to regain any old EFI paths you had on the other machine, it will also be tricky to install on the current machine when you put it back in. If you on the other hand install with LegacyBIOS/Grub, then it should just work, plain and simple. 2: Might want to pull out any drives you got on the other machine, while installing Qubes, just in case anything should be written to the drives, like new grub configurations, etc. just to be safe, remove them. Then put them back in as they were when you pull the drive out you just installed Qubes on (best use same cables if any software is sensitive to the drive numbers). 3: When you put it back in the old machine, and errors that were corrected between RC-3 and now today, will be fixed. I've had quite a lot of success on multiple different Qubes 4 machines using this method as of late. Maybe worth a a try if you got a sparing computer around that can run Qubes? Just keep in mind your Qubes will be exposed to unsafe hardware if the other machine isn't trustworthy. But for the most part, if its beween not getting Qubes to work, and this, then it's well worth the risk imho. Also the risk might be low, depending on what you pulled that machine through, and/or your public profile. Like probably only high profile people are heavily targeted, like really heavy profiles. You're probably not at much rish in this day and age, but you never know for sure though, but probably not big odds. Either way, it's definitely worth it if its your last option to try. Also your description of the issue sounds a lot like the issues I encounter, where it helps installing on another machine, update, and then put the drive back. It may be worth a shot if you got the means to do it. Further keep in mind if you break any still valid warrenties, and/or be sure you don't do something that might break your computer. Think twice, or triple, and ask if you got questions before doing something you're not sure about is doing. Just to be safer, there is always a risk when going into UEFI/BIOS settings, nevermind updating it which can brick your system if it breaks halffway or there is a corruption in your downloaded update file, poweroutages during UEFI/BIOS update, instability causing freezes, etc. etc. -- 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/c401b7fc-2dd7-486b-939e-2100b4f1cb7c%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Installation error: need at least 3mb more on /boot/efi
I'm back and you were right! There was some efi junk on ssd that once deleted let me install smoothly. Although I'm now facing another issue: when I boot up for the first time, the qubes configuration goes all the way until a point when it gives me a pci-related error (I'll try reproducing it again but I dumbly closed the window). Anyways, the os let's me enter the desktop nd I can't open VMs. This means that whatever VM I click on won't open. The only VM that opens is sys-usb. 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/ecdc3fc2-b0cd-44fb-880c-b5d0305865b1%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] No space left
On Thursday, January 25, 2018 at 3:29:28 PM UTC+1, beso wrote: > On Thursday, January 25, 2018 at 4:03:16 PM UTC+2, Yuraeitha wrote: > > On Thursday, January 25, 2018 at 2:32:38 PM UTC+1, beso wrote: > > > On Thursday, January 25, 2018 at 1:13:53 PM UTC+2, donoban wrote: > > > > On 01/24/2018 07:11 PM, beso wrote: > > > > > On Wednesday, January 24, 2018 at 2:47:55 PM UTC+2, donoban wrote: > > > > >> On 01/24/2018 09:34 AM, beso wrote: > > > > >>> On Tuesday, January 23, 2018 at 3:53:15 PM UTC+2, steve.coleman > > > > >>> wrote: > > > > On 01/23/2018 04:55 AM, beso wrote: > > > > > Something is eating free space in my system. It step by step > > > > > decreasing. I haven't found any good solution for that. > > > > > > > > > > > > > This command should give you a clue as to where the space is going: > > > > > > > > $ sudo du -h / | sort -g | tail -100 > > > > > > > > >> > > > > >> Try reversing the sort output: > > > > >> > > > > >> sudo du -h / | sort -g -r | tail -100 > > > > > > > > > > sudo du -h / | sort -g -r | tail -100 > > > > > du: `/proc/5947/task/5947/fd/4' ei saa kasutada: No such file or > > > > > directory > > > > > du: `/proc/5947/task/5947/fdinfo/4' ei saa kasutada: No such file or > > > > > directory > > > > > du: `/proc/5947/fd/3' ei saa kasutada: No such file or directory > > > > > du: `/proc/5947/fdinfo/3' ei saa kasutada: No such file or directory > > > > > 0 /proc/109/ns > > > > > 0 /proc/109/net/stat > > > > > > > > Ouch, try better this way: > > > > > > > > cd / > > > > sudo du -sh * > > > > > > > > You should see each dir on / and its disk usage > > > > > > > > then cd what you think it's using more than expected and du -sh * again. > > > > > > Thank you for the answer. Actually I know generally that some of my > > > appvm-s are quite big and there is quite few room(about 6G). Thing I > > > don't understand and would like to know is that this free room is > > > disappearing sometimes(not always) "in my eyes"(free space checker shows > > > me in real time :-)) > > > > It may be, "possible" that discard / fstrim only partially works? For > > example if it works in dom0, but not in some, or all your VM's, then > > numbers may change, but they won't be exact. This too means some VM's can > > grow larger than the actual files they hold, i.e. if you once had more > > files in, but no longer have that much now. If it can't shrink back down, > > then it'll stay large. Does your VM's shrink back down too? > > > > I modified donoban's command slightly, it's a good command and it's a good > > advice he gives. The only reason I modified it to AppVM folder, is because > > it's a likely source for your disk changes, so it's a good place to start > > looking too in addition to overall root at "/". > > > > Try: > > > > in dom0: cd /var/lib/qubes/appvms > > in dom0: sudo du -sh * > > > > It'll show all your AppVM's and their total disk usage, it's way simpler > > than the "qvm-ls --format disk" dommand I gave you earlier. > > > > It's recommendable that you save these logs over some days, i.e. sudo nano > > and copy-paste into it, and save with ctrl+x and follow the guideline to > > save. > > > > By keeping these logs, you can easily narrow down where it changes in an > > uncontrollable manner when compared. You can even post them here if you > > prefer, or cross out the VM names with numbers instead if you prefer > > privacy (just be sure they match numbers between logs). > > > > As donoban also said, if you do this properly, you'll be able to narrow > > down the possible culprit. Run the commands once a day over a few days, on > > both "/" and "/var/lib/qubes/appvms", and keep one log for each path, for > > some days. > > > > This way, you'll quickly narrow it down with minimal effort once a day, > > only requiring a bit of patience and a few quick commands daily, max 3-4 > > minutes. > > > Actually I haven't trimmed dom0 itself only templates/appvms/standalones. Is > this link https://www.qubes-os.org/doc/disk-trim/ correctway to do that? It depends, are you using UEFI/EFI to install Qubes? or LegacyBIOS/Grup? You found the right guide, but this guide is only for LegacyBIOS/Grup, and I'm not entirely happy with some of the commands in it, it seems a bit dangerous, but then again, I'm no expert. I'm also not sure if it works for Qubes 4, or only Qubes 3.2. Some guides still have to be updated for Qubes 4. I just find it odd that the "dracut -H -f" command is used, which as far as I know is related to the kernel installations. It seems possible to be related to fstab etc., but it also seems a bit overkill/dangerous without further insight into why it's used. Perhaps someone more knowledgeable can confirm that this works and doesn't break a system? I might be too careful, it's an official Qubes guide after all. But just to be sure and safe. If you're on UEFI/EFI, then it's quite a lot
Re: [qubes-users] Save virtual machine state?
Original Message On January 25, 2018 9:54 AM, Chris Laprise wrote: >On 01/24/2018 10:33 PM, Loren Rogers wrote: >>I'm sure this has already been discussed, but is there a way to save the >> state of a virtual machine, instead of shutting it down? I can't find >> any info in the docs on what exactly pausing a VM does, but could this >> be similar? >>Thanks >> > > Pausing is only in-memory stopping of the VM. Un-pausing makes the VM > continue running. > > Qubes doesn't (yet) support saving to disk like hibernate. If this ever > does become a feature it will probably be for use with HVMs in Qubes 4.x. > > > > Chris Laprise, tas...@posteo.net >https://github.com/tasket >https://twitter.com/ttaskett > PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886 > Thanks Chris - good to 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/5ZBUAyYt_eU3Ii20ra0rjFzRlBDByAgXs3cNKYCUtCFWr-vUmxjOnMP1ukkKk726WxHEqlnIWrQD64stfPHMYSqWgzqkiDzctLFghn3zVdg%3D%40lorentrogers.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Save virtual machine state?
On 01/24/2018 10:33 PM, Loren Rogers wrote: I'm sure this has already been discussed, but is there a way to save the state of a virtual machine, instead of shutting it down? I can't find any info in the docs on what exactly pausing a VM does, but could this be similar? Thanks Pausing is only in-memory stopping of the VM. Un-pausing makes the VM continue running. Qubes doesn't (yet) support saving to disk like hibernate. If this ever does become a feature it will probably be for use with HVMs in Qubes 4.x. -- 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/b6a77ee9-8414-e2d6-9ffa-141c68bf7842%40posteo.net. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Kernel Panic on a Lenovo Yoga 300 11-iby on attempt at install
Den torsdag den 25. januar 2018 kl. 14.40.14 UTC+1 skrev WolfSkin: > On Thursday, 25 January 2018 13:36:18 UTC, WolfSkin wrote: > > Basically my issue is that I am getting a kernel panic when I try > > installing qubes-os on my laptop both in UEFI and legacy mode. > > The kernel panic can be seen here: https://imagebin.ca/v/3pPwokGAMAVB and I > > sadly can't provide a hastebin dump since I have no way to log the error in > > text form (at least none that I'm aware of). > > > > I have followed the steps in the uefi-troubleshooting docs page, to no avail > > > > Steps to reproduce: > > - Buy this laptop > > - Burn the iso to usb using etcher or rufus after having verified file > > integrity via checksums and signature > > - Boot to the usb in uefi or legacy > > > > What I expect to happen: > > - Normal boot to the installer > > > > What I get instead: > > - Attempts to boot, manages to get to the loading bar on legacy, not even > > close on uefi > > - Then kernel panic (as seen in picture) > > > > Any help with this would be greatly appreciated > > Since I can't edit the above afaik, this is both on R4-rc3 and R3.2 Did you try the steps from this doc page? https://www.qubes-os.org/doc/thinkpad-troubleshooting/#instructions-to-create-usb-installation-medium-for-newer-uefi-only-thinkpads DISCLAIMER: I have a ThinkPad X270, but I installed in legacy mode, so I haven't tried this myself.. Perhaps someone with more knowledge can assist, if this fails :) -- 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/9df52da3-ce82-4036-92a1-a23a0f40bc17%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Kernel Panic on a Lenovo Yoga 300 11-iby on attempt at install
On Thursday, January 25, 2018 at 2:36:18 PM UTC+1, WolfSkin wrote: > Basically my issue is that I am getting a kernel panic when I try installing > qubes-os on my laptop both in UEFI and legacy mode. > The kernel panic can be seen here: https://imagebin.ca/v/3pPwokGAMAVB and I > sadly can't provide a hastebin dump since I have no way to log the error in > text form (at least none that I'm aware of). > > I have followed the steps in the uefi-troubleshooting docs page, to no avail > > Steps to reproduce: > - Buy this laptop > - Burn the iso to usb using etcher or rufus after having verified file > integrity via checksums and signature > - Boot to the usb in uefi or legacy > > What I expect to happen: > - Normal boot to the installer > > What I get instead: > - Attempts to boot, manages to get to the loading bar on legacy, not even > close on uefi > - Then kernel panic (as seen in picture) > > Any help with this would be greatly appreciated Three methods for you to consider/try: 1) Update your BIOS/UEFI, new laptops usually have a couple of versions laying around to be update. Just be careful, if you haven't done this before, then take proper precautions and read up on it, ask questions if you're in doubt, and don't do anything reckless, as there is the potential of bricking your entire machine, aka, zero value and can be thrown in the crash can. But if you don't do any mistakes, then it should be no problem to do, and it might very well fix your Qubes issues. In particular, because BIOS/UEFI errors can easily mess up a Qubes install. 2): Pull out the SDD/HHD/NVMe, whichever you installed on, and then insert it in another computer. Install Qubes on this other system. Then update it completely, make sure everything is up-to-date. Once that is done, move the drive back into the new desktop/laptop. Be sure to install with Grub, both so you don't mess up your other machines EFI paths (can be annoying), and also to avoid hassles to re-build a EFI path when returning it to the new machine. So, with this method, if you install with legacy/grub, you avoid any such troubles. Also it might be a good idea to unplug any other drives on the machine you install it on, just in case the installer writes to them. Then plug them back in once you're pulling the other drive out. I've done this about 5 times with Qubes, for various computers that could not install Qubes, or claimed to lack hardware support (which in some cases is wrong and is only corrected after updating under current-release), failed to load installer, or failed at the last step during first boot with python errors. Basically, this method solved quite many of my Qubes problems, in particular and foremost on Qubes 4 installations, albeit it might help for Qubes 3.2. too. 3) Change UEFI/BIOS settings. Sometimes it can just be an otherwise innocent UEFI/BIOS setting you never would suspect is messing it up. I've spend more than once an hour or so adjusting UEFI/BIOS settings, in combination with above suggestions. More often than not by using these steps, I get Qubes running and working on a system that did not install otherwise. For example make sure VT-d is enabled, it's often disabled on new computer systems. Be sure there is no extra virtualization setting, some motherboards (like i.e. Asus) may have an extra setting, it may hide under CPU settings in the advanced menu. Be sure VT-d is enabled, and make sure there is no extra setting for virtualization, and if there is, make sure that it's enabled as well. There can be any number of settings that cause a kernel panic, typically though, it does seem like your hardware might be too new for the instlaled kernel. 4) Qubes 3.2. comes with 4.4 kernel, iirc? It might be too old for your new machine. You can either use option 2) above, install on another machine, update it so it has a new higher version kernel, and then try put it back in your new machine again. Or, instead, you could try install Qubes 4 RC-3, although Qubes 4 RC-4 "might" be out soon, but there is no news released yet whether a normal update is required, or if you need to re-install between Qubes 4 RC-3 and Qubes 4 RC-4. For example between Qubes 4 RC-2 and Qubes 4 RC-3, no install was required, and normal updates was sufficient. Either way, if I had to guess, the real issue is likely too new hardware on an too old kernel, and likely outdated BIOS/UEFI. The safest you can do, if you want to do the minimum risk first, is to try install Qubes 4 RC-3. If you succeed, then it might just be because Qubes 4 RC-3 has a newer kernel, which means newwer essential drivers for CPU's/RAM/Motherboard, etc. If memory serves, I believe Qubes 4 RC-3 comes with kernel 4.9.x. If this isn't enough, then you'll need to try put it in another computer, install Qubes 4, and update it to gain access to the recently released kernel 4.14. If you don't have another computer available to do this on, or you can't
Re: [qubes-users] No space left
On Thursday, January 25, 2018 at 4:03:16 PM UTC+2, Yuraeitha wrote: > On Thursday, January 25, 2018 at 2:32:38 PM UTC+1, beso wrote: > > On Thursday, January 25, 2018 at 1:13:53 PM UTC+2, donoban wrote: > > > On 01/24/2018 07:11 PM, beso wrote: > > > > On Wednesday, January 24, 2018 at 2:47:55 PM UTC+2, donoban wrote: > > > >> On 01/24/2018 09:34 AM, beso wrote: > > > >>> On Tuesday, January 23, 2018 at 3:53:15 PM UTC+2, steve.coleman wrote: > > > On 01/23/2018 04:55 AM, beso wrote: > > > > Something is eating free space in my system. It step by step > > > > decreasing. I haven't found any good solution for that. > > > > > > > > > > This command should give you a clue as to where the space is going: > > > > > > $ sudo du -h / | sort -g | tail -100 > > > > > > >> > > > >> Try reversing the sort output: > > > >> > > > >> sudo du -h / | sort -g -r | tail -100 > > > > > > > > sudo du -h / | sort -g -r | tail -100 > > > > du: `/proc/5947/task/5947/fd/4' ei saa kasutada: No such file or > > > > directory > > > > du: `/proc/5947/task/5947/fdinfo/4' ei saa kasutada: No such file or > > > > directory > > > > du: `/proc/5947/fd/3' ei saa kasutada: No such file or directory > > > > du: `/proc/5947/fdinfo/3' ei saa kasutada: No such file or directory > > > > 0 /proc/109/ns > > > > 0 /proc/109/net/stat > > > > > > Ouch, try better this way: > > > > > > cd / > > > sudo du -sh * > > > > > > You should see each dir on / and its disk usage > > > > > > then cd what you think it's using more than expected and du -sh * again. > > > > Thank you for the answer. Actually I know generally that some of my appvm-s > > are quite big and there is quite few room(about 6G). Thing I don't > > understand and would like to know is that this free room is disappearing > > sometimes(not always) "in my eyes"(free space checker shows me in real time > > :-)) > > It may be, "possible" that discard / fstrim only partially works? For example > if it works in dom0, but not in some, or all your VM's, then numbers may > change, but they won't be exact. This too means some VM's can grow larger > than the actual files they hold, i.e. if you once had more files in, but no > longer have that much now. If it can't shrink back down, then it'll stay > large. Does your VM's shrink back down too? > > I modified donoban's command slightly, it's a good command and it's a good > advice he gives. The only reason I modified it to AppVM folder, is because > it's a likely source for your disk changes, so it's a good place to start > looking too in addition to overall root at "/". > > Try: > > in dom0: cd /var/lib/qubes/appvms > in dom0: sudo du -sh * > > It'll show all your AppVM's and their total disk usage, it's way simpler than > the "qvm-ls --format disk" dommand I gave you earlier. > > It's recommendable that you save these logs over some days, i.e. sudo nano > and copy-paste into it, and save with ctrl+x and follow the guideline to > save. > > By keeping these logs, you can easily narrow down where it changes in an > uncontrollable manner when compared. You can even post them here if you > prefer, or cross out the VM names with numbers instead if you prefer privacy > (just be sure they match numbers between logs). > > As donoban also said, if you do this properly, you'll be able to narrow down > the possible culprit. Run the commands once a day over a few days, on both > "/" and "/var/lib/qubes/appvms", and keep one log for each path, for some > days. > > This way, you'll quickly narrow it down with minimal effort once a day, only > requiring a bit of patience and a few quick commands daily, max 3-4 minutes. Actually I haven't trimmed dom0 itself only templates/appvms/standalones. Is this link https://www.qubes-os.org/doc/disk-trim/ correctway to do that? -- 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/2d249d6b-852d-4a08-94a0-1026703f191f%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: USB3 attach problem
On Thursday, January 25, 2018 at 12:44:37 PM UTC+1, Ilpo Järvinen wrote: > On Wed, 24 Jan 2018, beso wrote: > > > On Thursday, January 25, 2018 at 5:01:00 AM UTC+2, cooloutac wrote: > > > On Wednesday, January 24, 2018 at 2:35:14 PM UTC-5, beso wrote: > > > > ERROR: Device attach failed: USB SuperSpeed require kernel >= > > > > 4.13/usr/lib/qubes/usb-import: line 71: printf: write error: Invalid > > > > argument > > > > > > I don't have this issue on 3.2. are you using 4.0? > > > > No, I use 3.2. > > Qubes usb-proxy recently gained support for USB3 [1] but perhaps it might > need to check that the kernel is new enough to support it? > > R3.2 stable repo only has 4.9 series kernel in stable repo, whereas > testing has new enough kernel. > > Perhaps these different experiences you see come from different kernel / > usb-proxy versions installed? > > -- > i. > > > [1] > https://github.com/QubesOS/qubes-app-linux-usb-proxy/commit/5f94e1064fd5946f127e1257062756be75f92f99 Doesn't Qubes 3.2. have access to kernel 4.14? If true, then this "might" be a possible reason. Qubes 4 has access to kernel 4.14. Currently Qubes 4 has received some qubes-usb-proxy updates, if these updates were only considered for Qubes 4, and not Qubes 3.2., then it might be an overlook pr. design? It's a lot of things to keep track of afterall, if I'm not mistaken, human error could easily happen here. In which case, this update wasnt designed for Qubes 3.2. which doesn't have 4.14 kernel yet? But I'm a bit puzzled, shouldn't 4.14 be vailaboe for Qubes 3.2. as well? Considering meltdown, spectra, and eveything is fixed in 4.14. I was under the impression the reason for the unexpected sudden hasteful release of 4.14. was to fix spectra and meltdown. Perhaps this is similar to the other Linux distributions that stopped working due to hasteful quick updates in a race to fix this issue? Only in Qubes might have been a less harmful mistake (if it was a mistake, I'm unable to confirm). In other words, it might just be a question of reversing the Qubes Proxy USB back to the older one, and all the dependencies that follow? -- 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/2f568c78-870d-4753-8676-fc81900def88%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] No space left
On Thursday, January 25, 2018 at 2:32:38 PM UTC+1, beso wrote: > On Thursday, January 25, 2018 at 1:13:53 PM UTC+2, donoban wrote: > > On 01/24/2018 07:11 PM, beso wrote: > > > On Wednesday, January 24, 2018 at 2:47:55 PM UTC+2, donoban wrote: > > >> On 01/24/2018 09:34 AM, beso wrote: > > >>> On Tuesday, January 23, 2018 at 3:53:15 PM UTC+2, steve.coleman wrote: > > On 01/23/2018 04:55 AM, beso wrote: > > > Something is eating free space in my system. It step by step > > > decreasing. I haven't found any good solution for that. > > > > > > > This command should give you a clue as to where the space is going: > > > > $ sudo du -h / | sort -g | tail -100 > > > > >> > > >> Try reversing the sort output: > > >> > > >> sudo du -h / | sort -g -r | tail -100 > > > > > > sudo du -h / | sort -g -r | tail -100 > > > du: `/proc/5947/task/5947/fd/4' ei saa kasutada: No such file or directory > > > du: `/proc/5947/task/5947/fdinfo/4' ei saa kasutada: No such file or > > > directory > > > du: `/proc/5947/fd/3' ei saa kasutada: No such file or directory > > > du: `/proc/5947/fdinfo/3' ei saa kasutada: No such file or directory > > > 0 /proc/109/ns > > > 0 /proc/109/net/stat > > > > Ouch, try better this way: > > > > cd / > > sudo du -sh * > > > > You should see each dir on / and its disk usage > > > > then cd what you think it's using more than expected and du -sh * again. > > Thank you for the answer. Actually I know generally that some of my appvm-s > are quite big and there is quite few room(about 6G). Thing I don't understand > and would like to know is that this free room is disappearing sometimes(not > always) "in my eyes"(free space checker shows me in real time :-)) It may be, "possible" that discard / fstrim only partially works? For example if it works in dom0, but not in some, or all your VM's, then numbers may change, but they won't be exact. This too means some VM's can grow larger than the actual files they hold, i.e. if you once had more files in, but no longer have that much now. If it can't shrink back down, then it'll stay large. Does your VM's shrink back down too? I modified donoban's command slightly, it's a good command and it's a good advice he gives. The only reason I modified it to AppVM folder, is because it's a likely source for your disk changes, so it's a good place to start looking too in addition to overall root at "/". Try: in dom0: cd /var/lib/qubes/appvms in dom0: sudo du -sh * It'll show all your AppVM's and their total disk usage, it's way simpler than the "qvm-ls --format disk" dommand I gave you earlier. It's recommendable that you save these logs over some days, i.e. sudo nano and copy-paste into it, and save with ctrl+x and follow the guideline to save. By keeping these logs, you can easily narrow down where it changes in an uncontrollable manner when compared. You can even post them here if you prefer, or cross out the VM names with numbers instead if you prefer privacy (just be sure they match numbers between logs). As donoban also said, if you do this properly, you'll be able to narrow down the possible culprit. Run the commands once a day over a few days, on both "/" and "/var/lib/qubes/appvms", and keep one log for each path, for some days. This way, you'll quickly narrow it down with minimal effort once a day, only requiring a bit of patience and a few quick commands daily, max 3-4 minutes. -- 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/e41165b7-a96a-4ec2-8318-78df25ffe486%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] No space left
On 01/25/2018 02:32 PM, beso wrote: > Thank you for the answer. Actually I know generally that some of my appvm-s > are quite big and there is quite few room(about 6G). Thing I don't understand > and would like to know is that this free room is disappearing sometimes(not > always) "in my eyes"(free space checker shows me in real time :-)) > Well 6G free is really low. You should consider to use maximum 75% of a SSD disk and ~50% for a conventional (unless it's used only for long term storage). If you can't remove anything consider to buy another hard disk. -- 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/5dbe34c0-8417-75f7-6698-911c8e474610%40riseup.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: USB3 attach problem
On Thursday, January 25, 2018 at 1:44:37 PM UTC+2, Ilpo Järvinen wrote: > On Wed, 24 Jan 2018, beso wrote: > > > On Thursday, January 25, 2018 at 5:01:00 AM UTC+2, cooloutac wrote: > > > On Wednesday, January 24, 2018 at 2:35:14 PM UTC-5, beso wrote: > > > > ERROR: Device attach failed: USB SuperSpeed require kernel >= > > > > 4.13/usr/lib/qubes/usb-import: line 71: printf: write error: Invalid > > > > argument > > > > > > I don't have this issue on 3.2. are you using 4.0? > > > > No, I use 3.2. > > Qubes usb-proxy recently gained support for USB3 [1] but perhaps it might > need to check that the kernel is new enough to support it? > > R3.2 stable repo only has 4.9 series kernel in stable repo, whereas > testing has new enough kernel. > > Perhaps these different experiences you see come from different kernel / > usb-proxy versions installed? > > -- > i. > > > [1] > https://github.com/QubesOS/qubes-app-linux-usb-proxy/commit/5f94e1064fd5946f127e1257062756be75f92f99 What kernel it shoud be? Unstable repo has also 4.9 kernels. -- 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/97cc7f91-c04c-4e47-9e11-be05cde20b75%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Kernel Panic on a Lenovo Yoga 300 11-iby on attempt at install
On Thursday, 25 January 2018 13:36:18 UTC, WolfSkin wrote: > Basically my issue is that I am getting a kernel panic when I try installing > qubes-os on my laptop both in UEFI and legacy mode. > The kernel panic can be seen here: https://imagebin.ca/v/3pPwokGAMAVB and I > sadly can't provide a hastebin dump since I have no way to log the error in > text form (at least none that I'm aware of). > > I have followed the steps in the uefi-troubleshooting docs page, to no avail > > Steps to reproduce: > - Buy this laptop > - Burn the iso to usb using etcher or rufus after having verified file > integrity via checksums and signature > - Boot to the usb in uefi or legacy > > What I expect to happen: > - Normal boot to the installer > > What I get instead: > - Attempts to boot, manages to get to the loading bar on legacy, not even > close on uefi > - Then kernel panic (as seen in picture) > > Any help with this would be greatly appreciated Since I can't edit the above afaik, this is both on R4-rc3 and R3.2 -- 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/b00ff228-962c-47d3-9170-1c33cbbc34ef%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] i3 under Qubes 4 RC3
Hey all, I installed i3 when first set up my machine, but I can't seem to get it working.. Has anyone else experienced issues with i3? In my case, no applets are shown in the bar and I cannot start any programs from VM's (any VM). If I run qvm-ls, it shows that VM's are running, and if I try to do somethings like qvm-run firefox, my CPU responds. Just a peculiar issue, but makes i3 unusable for me nonetheless.. Any feedback appreciated :) Cheers! -- 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/8a0771c6-0756-41d0-b7a7-f46cbf94b45c%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Kernel Panic on a Lenovo Yoga 300 11-iby on attempt at install
Basically my issue is that I am getting a kernel panic when I try installing qubes-os on my laptop both in UEFI and legacy mode. The kernel panic can be seen here: https://imagebin.ca/v/3pPwokGAMAVB and I sadly can't provide a hastebin dump since I have no way to log the error in text form (at least none that I'm aware of). I have followed the steps in the uefi-troubleshooting docs page, to no avail Steps to reproduce: - Buy this laptop - Burn the iso to usb using etcher or rufus after having verified file integrity via checksums and signature - Boot to the usb in uefi or legacy What I expect to happen: - Normal boot to the installer What I get instead: - Attempts to boot, manages to get to the loading bar on legacy, not even close on uefi - Then kernel panic (as seen in picture) Any help with this would be greatly appreciated -- 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/de215f32-99c2-4f3a-b561-66c67f374b0e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] No space left
On Thursday, January 25, 2018 at 1:13:53 PM UTC+2, donoban wrote: > On 01/24/2018 07:11 PM, beso wrote: > > On Wednesday, January 24, 2018 at 2:47:55 PM UTC+2, donoban wrote: > >> On 01/24/2018 09:34 AM, beso wrote: > >>> On Tuesday, January 23, 2018 at 3:53:15 PM UTC+2, steve.coleman wrote: > On 01/23/2018 04:55 AM, beso wrote: > > Something is eating free space in my system. It step by step > > decreasing. I haven't found any good solution for that. > > > > This command should give you a clue as to where the space is going: > > $ sudo du -h / | sort -g | tail -100 > > >> > >> Try reversing the sort output: > >> > >> sudo du -h / | sort -g -r | tail -100 > > > > sudo du -h / | sort -g -r | tail -100 > > du: `/proc/5947/task/5947/fd/4' ei saa kasutada: No such file or directory > > du: `/proc/5947/task/5947/fdinfo/4' ei saa kasutada: No such file or > > directory > > du: `/proc/5947/fd/3' ei saa kasutada: No such file or directory > > du: `/proc/5947/fdinfo/3' ei saa kasutada: No such file or directory > > 0 /proc/109/ns > > 0 /proc/109/net/stat > > Ouch, try better this way: > > cd / > sudo du -sh * > > You should see each dir on / and its disk usage > > then cd what you think it's using more than expected and du -sh * again. Thank you for the answer. Actually I know generally that some of my appvm-s are quite big and there is quite few room(about 6G). Thing I don't understand and would like to know is that this free room is disappearing sometimes(not always) "in my eyes"(free space checker shows me in real time :-)) -- 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/43c73ab1-74de-4872-ae7c-bb58cf9fd216%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Do allowing USB Keyboard expose to badusb attacks?
On Wednesday, January 24, 2018 at 4:47:58 AM UTC-6, koto...@gmail.com wrote: > If a USB keyboard is allowed with /etc/qubes-rpc/policy/qubes.InputKeyboard, > does it increase the risk for badusb kind of attacks? Yes, it does. I asked a similar question here: https://groups.google.com/forum/#!topic/qubes-users/52d0rqNnVqU The TLDR I got is that someone is working on a "USG hardware firewall mentioned in issue 2518" to prevent this kind of thing. -- 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/f9efbfb2-0ea4-4a06-80bc-ae3ccee33463%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: USB3 attach problem
On Wed, 24 Jan 2018, beso wrote: > On Thursday, January 25, 2018 at 5:01:00 AM UTC+2, cooloutac wrote: > > On Wednesday, January 24, 2018 at 2:35:14 PM UTC-5, beso wrote: > > > ERROR: Device attach failed: USB SuperSpeed require kernel >= > > > 4.13/usr/lib/qubes/usb-import: line 71: printf: write error: Invalid > > > argument > > > > I don't have this issue on 3.2. are you using 4.0? > > No, I use 3.2. Qubes usb-proxy recently gained support for USB3 [1] but perhaps it might need to check that the kernel is new enough to support it? R3.2 stable repo only has 4.9 series kernel in stable repo, whereas testing has new enough kernel. Perhaps these different experiences you see come from different kernel / usb-proxy versions installed? -- i. [1] https://github.com/QubesOS/qubes-app-linux-usb-proxy/commit/5f94e1064fd5946f127e1257062756be75f92f99 -- 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/alpine.DEB.2.20.1801251338050.29120%40whs-18.cs.helsinki.fi. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: How to deal with Yubikey ?
On Mon, 22 Jan 2018 22:47:55 -0800 (PST) ThierryIT wrote: > I have today to deal with two problems: > > 1) I am using Yubikey to be authentified on some web site like > Github ... 2) I am using Yubikey to stock my PGP keys and to use them > with mainly my emails (Thinderbird+Enigmail) > > What to do under Qubes to make this possible ? > I have already sys-usb running. Hi. I studied and followed https://mig5.net/content/yubikey-2fa-qubes-redux-adding-backup-key as well as https://mig5.net/content/yubikey-challenge-response-mode-qubes and it works perfectly fine on Qubes 3.2, Fedora 26. And my skills are mediocre. (Sending *63* bits, »variable«, you'll recognize later.) However, Qubes' own tutorial can, of course, work flawlessly with your set-up: https://www.qubes-os.org/doc/yubi-key/ If you like to dig in deeper, see the discussions on Github: https://www.qubes-os.org/doc/yubi-key/ Best regards, r. -- 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/20180125113702.770c2005.robotico%40posteo.es. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] No space left
On 01/24/2018 07:11 PM, beso wrote: > On Wednesday, January 24, 2018 at 2:47:55 PM UTC+2, donoban wrote: >> On 01/24/2018 09:34 AM, beso wrote: >>> On Tuesday, January 23, 2018 at 3:53:15 PM UTC+2, steve.coleman wrote: On 01/23/2018 04:55 AM, beso wrote: > Something is eating free space in my system. It step by step decreasing. > I haven't found any good solution for that. > This command should give you a clue as to where the space is going: $ sudo du -h / | sort -g | tail -100 >> >> Try reversing the sort output: >> >> sudo du -h / | sort -g -r | tail -100 > > sudo du -h / | sort -g -r | tail -100 > du: `/proc/5947/task/5947/fd/4' ei saa kasutada: No such file or directory > du: `/proc/5947/task/5947/fdinfo/4' ei saa kasutada: No such file or directory > du: `/proc/5947/fd/3' ei saa kasutada: No such file or directory > du: `/proc/5947/fdinfo/3' ei saa kasutada: No such file or directory > 0 /proc/109/ns > 0 /proc/109/net/stat Ouch, try better this way: cd / sudo du -sh * You should see each dir on / and its disk usage then cd what you think it's using more than expected and du -sh * 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/91d495ae-18c0-d286-b0e6-3caec6c1c141%40riseup.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Installation error: need at least 3mb more on /boot/efi
On Thu, January 25, 2018 10:14 am, darkla...@gmail.com wrote: > 4.0. I'll try asap. Sorry, thought of a third option right after hitting send... You might have leftover junk in the EFI partition from other OSes. You could look around in /boot/efi/EFI to see if there's anything to delete to free up space. It's pretty easy to end up with a non-booting system if there are other OSes on the same drive, so use caution if that's the case (don't think it is in 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/e8c41ed6b808222e0a4e4f4ad9516b8f.squirrel%40tt3j2x4k5ycaa5zt.onion. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Installation error: need at least 3mb more on /boot/efi
4.0. I'll try asap. -- 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/c63b2770-1104-4179-9957-f3389a2952a1%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Installation error: need at least 3mb more on /boot/efi
On Thu, January 25, 2018 9:10 am, darkla...@gmail.com wrote: > Hi, > as per title, when trying to install on a laptop (with new partitions > automatically created by the installer) I get this error. I've seen > another person with the same problem but he was upgrading qubes, qhereas > I'm on a fresh install. > Thanks for your help! 3.2 or 4.0? In 3.2 I believe the installer re-uses the existing EFI partition instead of creating a new one. 4.0 might be the same. So a couple options are: - completely wipe the drive before installing Qubes on it (e.g. secure erase if SSD). If that doesn't work, - manually specify partition sizes on install. I'd set EFI at 512MB. -- 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/b68aa0996c307e02b9399141ff8f0ba6.squirrel%40tt3j2x4k5ycaa5zt.onion. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Please help with custom template build
On Wed, January 24, 2018 7:42 pm, Krišjānis Gross wrote: > On Tuesday, 23 January 2018 19:36:00 UTC+2, Krišjānis Gross wrote: >> -> Verifying signatures... >> Filename: >> /home/krish/qubes-builder/cache/fc25/base_rpms/acl-2.2.52-13.fc25.x86_6 >> 4.rpm is not signed. Exiting! Just noticed you are using F27 for your build environment. Can you try F25? -- 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/d439ce9e014d0cdba2ccc4f0b8459396.squirrel%40tt3j2x4k5ycaa5zt.onion. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: [qubes-announce] [UPDATE] QSB #37: Information leaks due to processor speculative execution bugs (XSA-254, Meltdown & Sepctre)
There actually is a GUI for checking dom0 updates. In Qubes VM manager, select dom0 and click the update button in top toolbar. Or you can also use the context menu. OTOH, in this case, the main benefit of the GUI are the notifications. The update process itself is usually more friendly from commandline. And you cannot install security-testing using GUI. -- 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/17ef6cbe-00d4-45ac-93e2-3220d4c01e81%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Qubes OS screensharing
Dave, why you start a new VM and not just use a loopback? Is the reason sharing apps from multiple VMs? If si, you are at least significantly weakening isolation. Maybe you are not keeping any, not sure. X11 was not designed for isolation at all. Nuno, this is probably possible, but not so trivial. You would need Grub (as HVMs and PVs have different boot mechanisms) and you would need to adjust some things made for PVs - probably some startup services and some X11 config files. Those changes (especially the Grub change) would require a modification of the template. And you would also need to reboot to change it. I have some idea for full screensharing (considering Qubes-agnostic generic screensharing apps): 1. Scrap the screen in dom0 and send it to a VM through Qubes RPC. It seems that VLC can be used for that. Uncompressed video could be ideal for low latency and lower CPU usage. Compression does not make much sense within a physical computer. But compressed video could be also acceptable. I believe video encoding is not a risky operation, so it can be done in dom0 without any additional real risk. 2. In the VM, play the video in a VNC-loopback X11 session. 3. Run the screensharing app of your choice in the same X11 session. 4. Make the screensharing video fullscreen. Of course, this would make some fractal effect when the VNC client is visible on screen ☺ I haven't tried it yet, but it seems Regards, Vít Šesták 'v6ak' -- 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/624034b4-6326-4a7a-9484-1eda6bfc5bea%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: [qubes-announce] [UPDATE] QSB #37: Information leaks due to processor speculative execution bugs (XSA-254, Meltdown & Sepctre)
On Thu, January 25, 2018 2:17 am, yreb...@riseup.net wrote: > On 2018-01-24 15:12, Andrew David Wong wrote: >> >> These packages will migrate from the security-testing repository to the >> current (stable) repository over the next two weeks after being tested >> by the community. > > > 1) > The latter (security) packages will migrate, I'd assume this means ? Yes, this is the standard model for deploying all updates including security. They appear in testing first for bleeding edge users, then stable for everyone. Sometimes bugs are found in the testing phase causing the package to be pulled, so unless you are comfortable rolling back packages yourself you should leave it on stable. > 2) > Where would I find the repositories in dom0 for the track I'm currently > using? If you haven't changed it manually, you are on stable. > 3) > after doing the 1x securitytesting repo update, how do I check which Xen > package is now installed? In dom0, "dnf list installed". > and/or how do I bring up the GUI > update manager when it doesn't actually need to update it doesn't persist No GUI, but in dom0 you can force it to check for updates with "sudo qubes-dom0-update". Might not be following your question here. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To 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/5877f3a839a49a8520367e507d47c1f8.squirrel%40tt3j2x4k5ycaa5zt.onion. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Installation error: need at least 3mb more on /boot/efi
Hi, as per title, when trying to install on a laptop (with new partitions automatically created by the installer) I get this error. I've seen another person with the same problem but he was upgrading qubes, qhereas I'm on a fresh install. Thanks for your 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/6d3554c0-f61b-48a2-9ff6-c705bbceda77%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Please help with 8th Generation Intel i5
On Wed, January 24, 2018 7:09 pm, Krišjānis Gross wrote: > > I can not find a kern.log or dmesg. I did find the Xorg log files. (This > is all on the Fedora that I recently installed on this same hardware). > Xorg Log files attached. Try "sudo journalctl -b > journal.log". Review and redact any sensitive information (serial numbers, usernames, etc.) then reply here with it attached. -- 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/c82c15c702f99652584acc1e5bebd3d0.squirrel%40tt3j2x4k5ycaa5zt.onion. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: which linux works well as a standalone hvm in qubes-4.0?
On Wednesday, January 24, 2018 at 7:25:50 PM UTC-8, pixel fairy wrote: > has anyone gotten a linux desktop with more than 800x600 in hvm in qubes-4? For anyone looking, fedora-26 works with a few resolutions.couldnt get the fedora-27 installer to boot, but you can update from 26 just fine. -- 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/8ff7dced-e17d-4d4f-b530-82c801cbf4a3%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.