[qubes-users] Import back VM (3.2) to Qubes 4.0RC3 ?
Hi, I am a bit lost with Qubes 4.0 RC3 ... Before moving to 4.0, I have done my VM's backup. How to restore them to Qubes 4.0 ? Thx -- 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/10638a91-a7eb-4a89-97d8-b3d9278be77a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Anon-whonix browser fails to connect to tor in Qubes 3.2, any ideas?
Solved. Not sure if it was relevant but since the most recent Whonix updates this has gone back to normal. Thanks to all. -- 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/9dd5a721-bb5d-4e88-9b66-c4b567c9621b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Split GPG and Emacs/mu4e: able to retrieve email but not send
Apparently creating a post for help is like replacing something you've lost, only to find it immediately after replacing it. Here's the solution to this problem: Apparently Emacs will trick you into thinking you've changed the epa-gpg-program variable, but it won't actually honor that change when it runs a gpg call. This: https://blogs.fsfe.org/jens.lechtenboerger/2017/04/12/gnu-emacs-under-qubes-os/ Supposedly I should be able to use the following to make Emacs recognize qubes-gpg-client-wrapper: (customize-set-variable 'epg-gpg-program "/usr/bin/qubes-gpg-client-wrapper") But even though I'm running 25.3.1, it didn't work. I had to fall back to a second option: (require 'epg-config) (customize-set-variable 'epg-gpg-program "/usr/bin/qubes-gpg-client-wrapper") (push (cons 'OpenPGP (epg-config--make-gpg-configuration epg-gpg-program)) epg--configurations) This did the trick and actually got Emacs to recognize the changed variable. I can now send email using emacs/mu4e and Qubes split gpg. -- 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/c5d489a0-6826-4184-9744-0c9fd7616aca%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: A few bugs in 4.0.rc3
On Sunday, January 28, 2018 at 4:17:10 AM UTC+1, Jo wrote: > Yes, im running the backups trough sys-usb-> extern ssd.The sys-usb is > the default one from the installation.Im doing a complete new setup, for > the very same reasons you mentioned. > > Updating (and enabling testingrepos) was the very first thing i did. > > Im using coreboot+seabios and coreboot+grub+encrypted /boot, i could try > an installation with the original bios/firmware, however this would be > only for testing-purposes, since it would completely break my my > security-setup/threat-model. > > They device(x230/i7/16gbram) did run qubes 3:2 so far without any > issues.(and the very same coreboot images) > > Thanks for the hint, i will play around a bit tomorrow with different > coreboot images. > > cheers. > > > On 01/28/2018 03:56 AM, Yuraeitha wrote: > > > > - Are you running the backup through an AppVM? Doing backup in dom0 may > > cause bugs or be really slow. I believe this is involved in the > > python/admin code in Qubes 4, and is therefore different than it was in > > Qubes 3.2. So in Qubes 4, be sure to do it in an AppVM, freshly made in > > Qubes 4. The general idea I believe is to allow to network the backup > > process, that's why it was made to work in an AppVM. No attention was given > > to allow backup in dom0 here, probably on purpose since nothing should be > > done in dom0 anyway. > > > > - Is the template/AppVM you're using specifically to run the backup based > > on a Qubes 4 template/AppVM? While Qubes 3.2. AppVM's can work in Qubes 4, > > it's generally my experience that they are more buggy/slow, and work better > > if re-made in Qubes 4 and then transfer the files over. Personally I took > > no chances and purged all my Qubes 3.2. templates/AppVM's in favour for > > fresh Qubes 4 ones. Removing Qubes 3.2. templates is obvious due to likely > > code differences in the qubes-core-agent-* packages, etc., but the AppVM is > > more controversial without confirmation and based on anecdotal experience. > > Generally I experienced improvements by purging Qubes 3.2. AppVM's in > > favour for freshly Qubes 4 made ones. > > > > - Did you update dom0? I've also seen the qvm-create not working, but this > > only happens on a buggy install of Qubes 4, typically with python errors on > > the last step during first boot when creating default VM-configuarations > > and networking VM's. Generally I solved it either by re-install with > > different UEFI/BIOS settings, EFI/Grub settings, UEFI/BIOS update, try > > switch between EFI/Grub boot methods, loading different drivers. > > > > Generally the most effective method to get Qubes 4 RC-1/2/3 to work on a > > system that I had issues with, was to unplug the drive, put it in a machine > > that works with Qubes. Then install Qubes, update it fully, and then put it > > back into the first machine again. Usually always work for me on any > > machine that on paper should support Qubes. Also Grub is easier to do this, > > as EFI paths can be a pain to adjust, they change when moving from a > > machine to another, while Grub does not change. Also be careful if you > > install on another machine, might be a good idea to remove the other drives > > first, just in case. Also EFI installs on a machine with existing EFI paths > > may cause issues. > > All in all in short, use Grub is recommended here, and also to unplug other > > drives on the install machine you use. > > > > Assuming you did not update dom0 due to the above bug, then once you get it > > updated, everything "should" work much, much better. > > Np's :) I hope you succeed! I've sometimes had longer issues with the UEFI/BIOS settings. I remember once when I started using Qubes, I used a couple of days to figure out why I could't install Qubes on a z170 Asus motherboard, i5 6500 CPU. Then it turned out it was a UEFI/BIOS setting to allow two graphic cards (one intel onboard, the other extenal nvidia card). Quite frankly, I was stunned by the cause, sometimes it's settings we least expect to cause any problems. The mix of VT-d, hypervisors and other exotic things in Qubes, seems to make it more sensitive to some UEFI/BIOS settings. -- 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/043d86e4-8fec-436e-b2a1-5dc20506957e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: connect to other VMs in qubes by using vm name
On Saturday, January 27, 2018 at 3:45:28 PM UTC+1, Yoganandam Marava wrote: > by adding forward rules at sysfirewall we can ping each other VM through ip > address but not using VM name. > Is this some thing possible with Qubes 4? I am naive in networking.please > suggest if there is a way? > > Thanks As far as I can tell, it's pretty much the exact same thing in Qubes 4. Although I did not verify it, but it looks like it works the same way in Qubes 4. I did not quite follow what you meant by using the VM name in the Qubes internal networking. Are you not referring to the various Qubes-core-agent-* tools here? Like sending files between VM's? Sending files between VM's by a VM's name is not networking however. Rather it's a process that happens in dom0 outside the VM's, transfering the files between the VM's .img files without allowing any moved content to touch dom0 (roughly said). I assume this is the kind of process you meant by "name"? Generally you'd need something like a DNS server between the networked VM's in Qubes if you want to replace IP's with names. But I don't think this was ever included in Qubes by default or encouraged by the developers? By default Qubes discourages any kind of inter-VM networking. Even the Qubes tools are not using networking, they're services executed outside the VM's reach, which include any kind of networking. As for the inter-VM networking concept itself, you may want to create a separate "network" for any VM's you allow to talk together though, and a separate firewall VM for it too. At least in PV virtualization mode sophisticated attacks are possible if attacking while two or more VM's running at the same time, which becomes more easy if they are networked together. But now on HVM/PVH modes, I'm not sure if this particular kind of attack is possible, probably not, but it's advanced stuff. Some of these kind of attacks have not even been observed in the "wilds" but have been deemed "possible" through research. But maybe there are other attack vectors that discourage networked VM's to talk to each others. For example any attacker may more easily gain access to other VM's after having successfully exploited a protocol through the firewall-port, of the many or few internet services going through. Here it may not be desirable to make it easier for any attacker, although disallowing network between VM's probably doesn't make you immune to get attacked in other VM's, but at the very least it minimizes possible attack vectors. It's also important that both VM's have proper secured firewalls in place between them. So by that logic, it may be desirable to create a separate network/firewall for any VM's that talk to each others, and consider possible attacks to be an increased attack vector for any VM's you added to this parallel Qubes inter-VM network. However someone more knowledgeable should probably confirm first if this is something useful, redundant or pointless, or perhaps downright dangerous to do. -- 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/6d0c76f5-9b97-4def-a498-7f9092ab4b3f%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: A few bugs in 4.0.rc3
Yes, im running the backups trough sys-usb-> extern ssd.The sys-usb is the default one from the installation.Im doing a complete new setup, for the very same reasons you mentioned. Updating (and enabling testingrepos) was the very first thing i did. Im using coreboot+seabios and coreboot+grub+encrypted /boot, i could try an installation with the original bios/firmware, however this would be only for testing-purposes, since it would completely break my my security-setup/threat-model. They device(x230/i7/16gbram) did run qubes 3:2 so far without any issues.(and the very same coreboot images) Thanks for the hint, i will play around a bit tomorrow with different coreboot images. cheers. On 01/28/2018 03:56 AM, Yuraeitha wrote: > > - Are you running the backup through an AppVM? Doing backup in dom0 may cause > bugs or be really slow. I believe this is involved in the python/admin code > in Qubes 4, and is therefore different than it was in Qubes 3.2. So in Qubes > 4, be sure to do it in an AppVM, freshly made in Qubes 4. The general idea I > believe is to allow to network the backup process, that's why it was made to > work in an AppVM. No attention was given to allow backup in dom0 here, > probably on purpose since nothing should be done in dom0 anyway. > > - Is the template/AppVM you're using specifically to run the backup based on > a Qubes 4 template/AppVM? While Qubes 3.2. AppVM's can work in Qubes 4, it's > generally my experience that they are more buggy/slow, and work better if > re-made in Qubes 4 and then transfer the files over. Personally I took no > chances and purged all my Qubes 3.2. templates/AppVM's in favour for fresh > Qubes 4 ones. Removing Qubes 3.2. templates is obvious due to likely code > differences in the qubes-core-agent-* packages, etc., but the AppVM is more > controversial without confirmation and based on anecdotal experience. > Generally I experienced improvements by purging Qubes 3.2. AppVM's in favour > for freshly Qubes 4 made ones. > > - Did you update dom0? I've also seen the qvm-create not working, but this > only happens on a buggy install of Qubes 4, typically with python errors on > the last step during first boot when creating default VM-configuarations and > networking VM's. Generally I solved it either by re-install with different > UEFI/BIOS settings, EFI/Grub settings, UEFI/BIOS update, try switch between > EFI/Grub boot methods, loading different drivers. > > Generally the most effective method to get Qubes 4 RC-1/2/3 to work on a > system that I had issues with, was to unplug the drive, put it in a machine > that works with Qubes. Then install Qubes, update it fully, and then put it > back into the first machine again. Usually always work for me on any machine > that on paper should support Qubes. Also Grub is easier to do this, as EFI > paths can be a pain to adjust, they change when moving from a machine to > another, while Grub does not change. Also be careful if you install on > another machine, might be a good idea to remove the other drives first, just > in case. Also EFI installs on a machine with existing EFI paths may cause > issues. > All in all in short, use Grub is recommended here, and also to unplug other > drives on the install machine you use. > > Assuming you did not update dom0 due to the above bug, then once you get it > updated, everything "should" work much, much better. > -- 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/c472b4d1-52cd-cdba-eedc-5f27a0211d1b%40seefelder-web.de. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Can I install Qubes 4.0 rc3 on external hard drive?
On Sunday, January 28, 2018 at 2:03:35 AM UTC+1, bill...@gmail.com wrote: > On Saturday, January 27, 2018 at 6:23:54 PM UTC-5, Yuraeitha wrote: > > On Friday, January 26, 2018 at 8:45:43 PM UTC+1, bill...@gmail.com wrote: > > > Thanks so much for your reply and your help. I installed using legacy > > > boot and it worked fine -- in fact, I'm responding from "untrusted > > > firefox" right now! I don't know if qubes comes up in the grub menu yet. > > > I just got this installed, and ran it from the BIOS boot sequence > > > Legacy-USB option, and I'm off for some errands myself. > > > > > > However, in lieu of killing myself with UEFI, since this works, I'll > > > stick with it and am a happy camper. Maybe in the next week I'll play > > > around more with UEFI, but I'm going to have to learn a bit more about > > > it, I think. > > > > > > Anyway, you made my weekend! Thanks again for your reply. > > > > I'm glad you got it working! :) > > > > Try run 'qubes-hcl-report' in dom0, and check if HVM, I/O MMU, HAP/SLAT, > > TPM, and Remapping, is working properly in your Qubes setup. The top one, > > HVM, as far as I know is the most important one. The lowest, remapping, > > should with my limited knowledge as far as I can tell, be the least > > important of the 5. All of them are relevant for security, and to some > > extent, proper working features. > > > > If I'm not mistaken, I haven't ventured into these waters before, and > > someone might correct me here. But I believe if a Qubes (or Linux in > > general) uses the same partition table as UEFI/EFI (GPT), over the old > > out-dated MBR), then it might be possible to switch between UEFI/EFI and > > Legacy/BIOS without re-installing a system if retaining the modern GTR > > partition table. But it can be tricky if something goes wrong, especially > > if you have precious data you don't want to loose. Also UEFI/EFI is heavily > > reliant on not having a buggy motherboard firmware, which many > > unfortunately have. I also recall having issues not being able to restore > > an EFI path for Qubes 4, which used to always work on the same machine on > > Qubes 3.2. I'm not sure if this got fixed, it was some months back and > > Qubes 4 has rapidly been updated on many ways since then. But this issue is > > likely to be Qubes related, or at least partly Qubes related. So it's not > > always the hardware that is causing it, although the hardware in this case > > might be part-reason still. > > > > Remember to take frequent AppVM backups. If you're learning with the trial > > and error method like I do, many things can end up going wrong. For > > example, burned my fingers more than a few times my self there before I got > > into proper backup habits. Never take that risk, it will eventually go > > wrong :') > > I'll do that, probably next week. Today was my "play with new linuxes" day. > Tomorrow is the sabbath for me, and then it's back to the grindstone. Sigh. uh yeah, workdays can really get in the way for these things. I have probably somewhat similar issues, there are so many things to catch up on. It can be fun, but indeed this is really time-consuming, which is already frustratingly in short-supply. -- 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/ef7549b8-2667-4514-9206-0b1afa6b0292%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: A few bugs in 4.0.rc3
On Sunday, January 28, 2018 at 3:17:05 AM UTC+1, Jo wrote: > hello guys, > > i played a bit with rc3 and came across the following bugs: > > > qvm-backup/restore results in a complete system-shutdown, which is very > annoying.Using the gui/ qubes-manager instead of the terminal makes no > difference. > > I will have a look into it/ try to fix it in my spare time these days. > > So far, it looks like its related to fedora-26 templates(both minimal > and regular ), but appears only with certain templates i have. > > Could be coincidence, tough. > > > qvm-sync appmenus removes the menu-entrys systemtools, logut, launch > terminal emulator etc. > > Logging out/back in does not solve the problem temporally, like in the past. > > Couldnt find a solution/workaround so far, nore was i able to pin down > exactly what triggers this bug. > > > For any hints id be grateful, since im already setting up my new system > for 4.0 stable. > > > btw, have the disp-vm commands changed? qvm-create is not recognized > anymore. > > cheers. - Are you running the backup through an AppVM? Doing backup in dom0 may cause bugs or be really slow. I believe this is involved in the python/admin code in Qubes 4, and is therefore different than it was in Qubes 3.2. So in Qubes 4, be sure to do it in an AppVM, freshly made in Qubes 4. The general idea I believe is to allow to network the backup process, that's why it was made to work in an AppVM. No attention was given to allow backup in dom0 here, probably on purpose since nothing should be done in dom0 anyway. - Is the template/AppVM you're using specifically to run the backup based on a Qubes 4 template/AppVM? While Qubes 3.2. AppVM's can work in Qubes 4, it's generally my experience that they are more buggy/slow, and work better if re-made in Qubes 4 and then transfer the files over. Personally I took no chances and purged all my Qubes 3.2. templates/AppVM's in favour for fresh Qubes 4 ones. Removing Qubes 3.2. templates is obvious due to likely code differences in the qubes-core-agent-* packages, etc., but the AppVM is more controversial without confirmation and based on anecdotal experience. Generally I experienced improvements by purging Qubes 3.2. AppVM's in favour for freshly Qubes 4 made ones. - Did you update dom0? I've also seen the qvm-create not working, but this only happens on a buggy install of Qubes 4, typically with python errors on the last step during first boot when creating default VM-configuarations and networking VM's. Generally I solved it either by re-install with different UEFI/BIOS settings, EFI/Grub settings, UEFI/BIOS update, try switch between EFI/Grub boot methods, loading different drivers. Generally the most effective method to get Qubes 4 RC-1/2/3 to work on a system that I had issues with, was to unplug the drive, put it in a machine that works with Qubes. Then install Qubes, update it fully, and then put it back into the first machine again. Usually always work for me on any machine that on paper should support Qubes. Also Grub is easier to do this, as EFI paths can be a pain to adjust, they change when moving from a machine to another, while Grub does not change. Also be careful if you install on another machine, might be a good idea to remove the other drives first, just in case. Also EFI installs on a machine with existing EFI paths may cause issues. All in all in short, use Grub is recommended here, and also to unplug other drives on the install machine you use. Assuming you did not update dom0 due to the above bug, then once you get it updated, everything "should" work much, much better. -- 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/316f8658-ddba-4d9c-b1f9-4a0305415776%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qubes 4.0-rc3 not installing on Lenovo P71
On Sunday, January 28, 2018 at 10:30:47 AM UTC+8, awokd wrote: > On Sun, January 28, 2018 2:13 am, xxx wrote: > > I burned the ISO to USB stick then started to install Qubes but got the > > following: > > > > > > [0.093375] ACPI Error: [\SB_.PCIO.XHC_.RHUB.HS11] Namespace lookup > > failure, AE_NOT_FOUND (20170531/dswload-210) [0.093383] ACPI > > Exception: AE_NOT_FOUND, During name lookup/catalog > > (20170531/psobject-252) > > [0.093539] ACPI Exception: AE_NOT_FOUND, (SSDT:ProjSsdt) while loading > > table (20170531/tbxfload-220) [0.098243] ACPI Error: 1 table load > > failures, 12 successful (20170531/tbxfload-246) [2.376031] Couldn't > > get size: 0x800e [ 137.216201] dracut-initqueue[566]: > > Looks like a buggy firmware. See if your manufacturer has a bios update. > Could maybe try turning off power saving since some messages sort of sound > related. If you don't care about EFI, you could disable it and boot and > install in legacy mode. If you want EFI, could try booting Refind, then > the installer from there. I just updated the BIOS yesterday through the Lenovo Avantage program. Starting Windows doesn't present any problems. I'll check out your other suggestions, 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/df3606ee-3eb1-4c6b-8f9d-a715622ac32b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qubes 4.0-rc3 not installing on Lenovo P71
On Sun, January 28, 2018 2:33 am, Yuraeitha wrote: > > Awkward same-time posting x) > But listen to awokd, he has more experience than I do. Not that much more! Unfortunately, on these boot issues most come down to trial and error like you said... -- 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/785a33dcc7e6cd626f7585bd9e485e08.squirrel%40tt3j2x4k5ycaa5zt.onion. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qubes 4.0-rc3 not installing on Lenovo P71
On Sunday, January 28, 2018 at 3:30:47 AM UTC+1, awokd wrote: > On Sun, January 28, 2018 2:13 am, joeh9...@gmail.com wrote: > > I burned the ISO to USB stick then started to install Qubes but got the > > following: > > > > > > [0.093375] ACPI Error: [\SB_.PCIO.XHC_.RHUB.HS11] Namespace lookup > > failure, AE_NOT_FOUND (20170531/dswload-210) [0.093383] ACPI > > Exception: AE_NOT_FOUND, During name lookup/catalog > > (20170531/psobject-252) > > [0.093539] ACPI Exception: AE_NOT_FOUND, (SSDT:ProjSsdt) while loading > > table (20170531/tbxfload-220) [0.098243] ACPI Error: 1 table load > > failures, 12 successful (20170531/tbxfload-246) [2.376031] Couldn't > > get size: 0x800e [ 137.216201] dracut-initqueue[566]: > > Looks like a buggy firmware. See if your manufacturer has a bios update. > Could maybe try turning off power saving since some messages sort of sound > related. If you don't care about EFI, you could disable it and boot and > install in legacy mode. If you want EFI, could try booting Refind, then > the installer from there. Awkward same-time posting x) But listen to awokd, he has more experience than I do. -- 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/1e71125b-25fc-47f8-8bac-e77bd9131743%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Qubes 4.0-rc3 not installing on Lenovo P71
On Sunday, January 28, 2018 at 3:13:47 AM UTC+1, joeh...@gmail.com wrote: > I burned the ISO to USB stick then started to install Qubes but got the > following: > > [0.093375] ACPI Error: [\SB_.PCIO.XHC_.RHUB.HS11] Namespace lookup > failure, AE_NOT_FOUND (20170531/dswload-210) > [0.093383] ACPI Exception: AE_NOT_FOUND, During name lookup/catalog > (20170531/psobject-252) > [0.093539] ACPI Exception: AE_NOT_FOUND, (SSDT:ProjSsdt) while loading > table (20170531/tbxfload-220) > [0.098243] ACPI Error: 1 table load failures, 12 successful > (20170531/tbxfload-246) > [2.376031] Couldn't get size: 0x800e > [ 137.216201] dracut-initqueue[566]: Warning: Dracut-initqueue timeout - > starting timeout scripts > [ 137.779207] dracut-initqueue[566]: Warning: Dracut-initqueue timeout - > starting timeout scripts > [ 138.324711] dracut-initqueue[566]: Warning: Dracut-initqueue timeout - > starting timeout scripts > [ 138.852226] dracut-initqueue[566]: Warning: Dracut-initqueue timeout - > starting timeout scripts > [ 139.395971] dracut-initqueue[566]: Warning: Dracut-initqueue timeout - > starting timeout scripts > . > . > . > > This went on for some time, so I switched off and wrote this message. > I hope there are no serious typos coz I typed this off of a picture taken of > the screen. > > Any hints? > Thanks I'm by no means an expert on the kernel, but dracut "looks" like kernel errors, and "ACPI" (Advanced Configuration and Power Interface) looks like a firmware/kernel support mismatch, either by a lack of features, lack of development, firmware-bug, kernel-bug, or possibly an un-updated firmware. The firmware should be the motherboard (BIOS/UEFI). You could start looking in your BIOS/UEFI after settings that may be wrong and require adjustments. Is VT-d enabled? Is there a second "Virtualization" that needs enabling, for exaple under "Advanced --> CPU" UEFI settings? There can be other settings too, it's hard to mention them all, but those two are the most important ones, which is sometimes only 1 merged setting. Does your hardware support VT-d and other Qubes hardware requirements? Does Qubes 3.2. run on this hardware? Qubes 4 is known to be more strict to hardware requirements and may not work smoothly or may not even install if the hardware requirements or security is not correct. Qubes 3.2. is less an issue when missing VT-d and similar. This might also be a place to look and confirm. If you got Qubes 3.2. running on the machine, then try run in dom0 "qubes-hcl-report" to see if you meet the requirements. However, dracut/ACPI errors doesn't strike me as errors that appear if there are issues with the Qubes 4 specific requirements. You may want to try install with LegacyBIOS/Grub if you tried UEFI/EFI, or vice versa, whichever you did not try yet. You can also update your BIOS/UEFI to the newest version, however be sure you don't brick your machine. Make sure you know any pitfalls as it may make your motherboard break and become useless. The kernel contains drivers too, the most essential ones, while the modules contain extra drivers for the kernel. These errors could also be driver issues, for example you may have to edit the EFI or the Grub to pick a different driver before starting. Unfortunately I believe you need to edit the /boot/efi/EFI.cfg file on the install media, but you can more easily change it live on Grub by hovering over the install menu, and thne press "E" key to edit the install menu in grub. Here you can change ACPI settings, drivers, virtulization states, hide/unhide hardware, and so on. I'm not sure if it even is a driver issue, I can't see that from the logs, whether it can be found there or not. But it's some clues to go with, and maybe you can google some up to trial and error. Just be careful, for example few of the ACPI settings can be dangerous to your hardwaree, so double-check any recommendations you find on the internet. Also it may be worth if you can find any ACPI settings in your UEFI/BIOS too. At any rate, I usually solve these kind of problems with trial and errors through experiments. Someone more knowledgeable might drop by with a better advice. For now though, some clues you can try start with if you did not do them already. -- 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/74168688-4fa3-4630-8052-5352536a8f82%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qubes 4.0-rc3 not installing on Lenovo P71
On Sun, January 28, 2018 2:13 am, joeh9...@gmail.com wrote: > I burned the ISO to USB stick then started to install Qubes but got the > following: > > > [0.093375] ACPI Error: [\SB_.PCIO.XHC_.RHUB.HS11] Namespace lookup > failure, AE_NOT_FOUND (20170531/dswload-210) [0.093383] ACPI > Exception: AE_NOT_FOUND, During name lookup/catalog > (20170531/psobject-252) > [0.093539] ACPI Exception: AE_NOT_FOUND, (SSDT:ProjSsdt) while loading > table (20170531/tbxfload-220) [0.098243] ACPI Error: 1 table load > failures, 12 successful (20170531/tbxfload-246) [2.376031] Couldn't > get size: 0x800e [ 137.216201] dracut-initqueue[566]: Looks like a buggy firmware. See if your manufacturer has a bios update. Could maybe try turning off power saving since some messages sort of sound related. If you don't care about EFI, you could disable it and boot and install in legacy mode. If you want EFI, could try booting Refind, then the installer from 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/3899d232c9b8d69f53a3a43bdf9ed6e8.squirrel%40tt3j2x4k5ycaa5zt.onion. For more options, visit https://groups.google.com/d/optout.
[qubes-users] A few bugs in 4.0.rc3
hello guys, i played a bit with rc3 and came across the following bugs: qvm-backup/restore results in a complete system-shutdown, which is very annoying.Using the gui/ qubes-manager instead of the terminal makes no difference. I will have a look into it/ try to fix it in my spare time these days. So far, it looks like its related to fedora-26 templates(both minimal and regular ), but appears only with certain templates i have. Could be coincidence, tough. qvm-sync appmenus removes the menu-entrys systemtools, logut, launch terminal emulator etc. Logging out/back in does not solve the problem temporally, like in the past. Couldnt find a solution/workaround so far, nore was i able to pin down exactly what triggers this bug. For any hints id be grateful, since im already setting up my new system for 4.0 stable. btw, have the disp-vm commands changed? qvm-create is not recognized anymore. 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/893a293f-afe7-4f00-4eeb-e0d12765b3a6%40seefelder-web.de. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Qubes 4.0-rc3 not installing on Lenovo P71
I burned the ISO to USB stick then started to install Qubes but got the following: [0.093375] ACPI Error: [\SB_.PCIO.XHC_.RHUB.HS11] Namespace lookup failure, AE_NOT_FOUND (20170531/dswload-210) [0.093383] ACPI Exception: AE_NOT_FOUND, During name lookup/catalog (20170531/psobject-252) [0.093539] ACPI Exception: AE_NOT_FOUND, (SSDT:ProjSsdt) while loading table (20170531/tbxfload-220) [0.098243] ACPI Error: 1 table load failures, 12 successful (20170531/tbxfload-246) [2.376031] Couldn't get size: 0x800e [ 137.216201] dracut-initqueue[566]: Warning: Dracut-initqueue timeout - starting timeout scripts [ 137.779207] dracut-initqueue[566]: Warning: Dracut-initqueue timeout - starting timeout scripts [ 138.324711] dracut-initqueue[566]: Warning: Dracut-initqueue timeout - starting timeout scripts [ 138.852226] dracut-initqueue[566]: Warning: Dracut-initqueue timeout - starting timeout scripts [ 139.395971] dracut-initqueue[566]: Warning: Dracut-initqueue timeout - starting timeout scripts . . . This went on for some time, so I switched off and wrote this message. I hope there are no serious typos coz I typed this off of a picture taken of the screen. Any hints? 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/a41da9e6-8ef4-43e6-ae62-babf1b1f2507%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Looking for an approach to change the borderline between /dev/xvda and /dev/xvdb
Just a heads-up for anyone else reading this thread who may want to try this too and is not aware of this pitfall, a warning before trying. Any mistakes done in the scripts can make the template unable to start applications. For example even if it can boot-up, applications may not start. So be very careful to try this on any templates that are used for something else, especially important stuff, like sys-net / sys-firewall, or templates many AppVM's are based on, making it tough to undo any user-mistakes. Recommendable to make a dom0: "qvm-clone template-nr template-nr-clone" before editing anything. Thereby only having to worry about the testing 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/6e9f291e-1660-46cd-98f2-56c13a1354d0%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Looking for an approach to change the borderline between /dev/xvda and /dev/xvdb
On Wednesday, January 24, 2018 at 8:32:24 PM UTC+1, Chris Laprise wrote: > On 01/24/2018 10:55 AM, Yuraeitha wrote: > > > > > All 3 suggestions are you guys brought up are really intriguig, I'm pretty > > excited about this, these ideas are excellent, even better than I hoped for. > > > > I'm using Qubes 4, so I assume I can't give the beta setup a try until or > > if it becomes available on Qubes 4. But I from my initial understanding I > > like the extra security it provides, although I've yet to better grasp its > > full potential. It seems like a pretty cool project you're working on there > > Chris. > > > > Unfortunately I don't have much experience as a coder either, so I can't > > make such a script Alex, I can at most read scripts or make simple ones. > > But it's a pretty good idea as well, it'd be amazing if someone would want > > to make such a bookmark-manager and contribute it to Qubes. Maybe even take > > it further and storing the bookmarks outside the VM until a single bookmark > > is needed? Similar to keeping i.e. KeePassX in an offline VM? Though I > > imagine that would add further complicity, which is definitely outside my > > skill-set. > > I'm going to test the Qubes-VM-hardening service on Qubes 4 tonight to > see if it needs any adjustment for the whitelisting feature to work. > I'll also expand on the (admittedly sparse) instructions. > > If it works then its probably easier to add a service and maintain a > single whitelist file. > > > > For now I'll try dwell down into the /usr/lib/qubes/init/setup-rw.sh > > re-mounting suggestion. It's the only one I have the skill-set and > > current-means to pull off on my own. It's been some long exhausting days, > > so hopefully I'll get around to try this tomorrow. > > > > I'm currently pondering about how to change the mount points correctly > > though. It seems like it has similar logic to traditional Linux mounting > > logic, and when combined with Qubes template/appVM logic, then it seems > > like I can solve it with some trial and error and exploring-testing, using > > your post as an initial starting point. I have some leads now, it'll be > > interesting to look into. I'll post pack on how it goes. > > Actually, you don't even need to change the mountpoint, which is done by > mount-dirs.sh, BTW. One example is to change the line that starts > 'initialize_home' to: > > rm -rf /rw/home-old > mv /rw/home /rw/home-old > initialize_home "/rw/home" unconditionally > > ...and then cp or mv files from /rw/home-old as needed. > > > -- > > Chris Laprise, tas...@posteo.net > https://github.com/tasket > https://twitter.com/ttaskett > PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886 Sorry for the delay, it was finally possible to find home-time to play with this (the dread of being on the road too much). I followed your instructions, and it works beautifully! The change from "ifneeded" to "unconditionally", is it correctly understood to be the one that freezes the /rw/home folder at the template: /usr/lib/qubes/init/mount-dirs.sh? If so, then I think I understand this part of it now. I might do this to all my templates, it's a pretty awesome trick, many thanks for sharing/helping! :) My worries are if updates clean up these scripts though. I know it might be an impossible question to answer as anything is likely subject to change whenever, but does updates happen to these files frequently? Will the updater warn if there are changes? (like i.e. it does if there are changes to /etc/fstab in debian templates?). Have you considered sharing this as a guide on https://www.qubes-os.org/doc/ on this? Of course only if you got the time and interest. Maybe even whether your script adjustment can be implemented as a permanent feature of Qubes templates, and then people only have to move between the folders in the AppVM, and not do anything to the scripts in the template? That'd be pretty neat for those who have a hard time getting to the motor under the car's lid, so to speak. I mean, it's pretty smart, it even works like before if not moving anything between the folders, so people won't even feel any difference if not moving between the folders, I assume. Will be keeping an eye out for when/if you release the VM-hardening beta for Qubes 4, no pressure though, can wait till/if you have the time/interest. -- 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/9268fb67-8353-45da-b418-a760ebc0e2b9%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Can I install Qubes 4.0 rc3 on external hard drive?
On Saturday, January 27, 2018 at 6:23:54 PM UTC-5, Yuraeitha wrote: > On Friday, January 26, 2018 at 8:45:43 PM UTC+1, bill...@gmail.com wrote: > > Thanks so much for your reply and your help. I installed using legacy boot > > and it worked fine -- in fact, I'm responding from "untrusted firefox" > > right now! I don't know if qubes comes up in the grub menu yet. I just > > got this installed, and ran it from the BIOS boot sequence Legacy-USB > > option, and I'm off for some errands myself. > > > > However, in lieu of killing myself with UEFI, since this works, I'll stick > > with it and am a happy camper. Maybe in the next week I'll play around > > more with UEFI, but I'm going to have to learn a bit more about it, I think. > > > > Anyway, you made my weekend! Thanks again for your reply. > > I'm glad you got it working! :) > > Try run 'qubes-hcl-report' in dom0, and check if HVM, I/O MMU, HAP/SLAT, TPM, > and Remapping, is working properly in your Qubes setup. The top one, HVM, as > far as I know is the most important one. The lowest, remapping, should with > my limited knowledge as far as I can tell, be the least important of the 5. > All of them are relevant for security, and to some extent, proper working > features. > > If I'm not mistaken, I haven't ventured into these waters before, and someone > might correct me here. But I believe if a Qubes (or Linux in general) uses > the same partition table as UEFI/EFI (GPT), over the old out-dated MBR), then > it might be possible to switch between UEFI/EFI and Legacy/BIOS without > re-installing a system if retaining the modern GTR partition table. But it > can be tricky if something goes wrong, especially if you have precious data > you don't want to loose. Also UEFI/EFI is heavily reliant on not having a > buggy motherboard firmware, which many unfortunately have. I also recall > having issues not being able to restore an EFI path for Qubes 4, which used > to always work on the same machine on Qubes 3.2. I'm not sure if this got > fixed, it was some months back and Qubes 4 has rapidly been updated on many > ways since then. But this issue is likely to be Qubes related, or at least > partly Qubes related. So it's not always the hardware that is causing it, > although the hardware in this case might be part-reason still. > > Remember to take frequent AppVM backups. If you're learning with the trial > and error method like I do, many things can end up going wrong. For example, > burned my fingers more than a few times my self there before I got into > proper backup habits. Never take that risk, it will eventually go wrong :') I'll do that, probably next week. Today was my "play with new linuxes" day. Tomorrow is the sabbath for me, and then it's back to the grindstone. Sigh. -- 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/f7cfa1d1-2e89-4327-8c51-cf61944956bb%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Anon-whonix browser fails to connect to tor in Qubes 3.2, any ideas?
I would ask on the Whonix Forum. https://forums.whonix.org/ -- 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/aJ1V4QSx0UbFs1cSmb2yVujSxb3EFwcladO21nkVDsnfiQG-VQ_7F0Z5sJGujtRaSQA2U5Qd9q8halk4nPLHHRiDejMz-iDgwvbwVLr4JM0%3D%40protonmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] How to get to command line for dom0?
On Wednesday, January 24, 2018 at 3:30:11 AM UTC+1, Kyle Breneman wrote: > >Note that those directions are about upgrading *templates*, not dom0. > > >Dom0 should generally stay at the fedora release it started at, > > >otherwise you are asking for compatibility trouble. > > > Thanks for that clarification, Jean-Philippe. I successfully upgraded to the > Fedora 26 template, but now I want to get rid of my Fedora 23 template. How > do I do that? (Or shouldn't I do that?) > > > Kyle Once nothing is bound to fedora-23, then you can remove it with "sudo dnf remove qubes-template-fedora-23" in your dom0 terminal. (Don't run it yet). Be sure fedora-26 works as intended before you remove the old template, i.e. test if internet works in sys-net and sys-firewall with the fedora-26 template. Run "qubes-global-settings" in dom0, switch any possible fedora-23 to fedora-24. Test if the changes work, in particular the dom0 update (just to be on the safe side). Then run "qvm-ls" in dom0, and detect any possible AppVM running fedora-23. Change it with either the GUI VM-settings for each respective AppVM, or use the qvm-prefs to do it. Both net same results, whichever you prefer GUI/Terminal. A bit redundant, but you may also check if the fedora-26 can start on other critical VM's, if copy/transfer from/to fedora-26 VM's work, whether their internet works, and so on. Once everything is untied and conirmed working, then you should be able to use the "dnf remove" command above mentioned initially. Any primary templates pre-installed, or primary ones you got from the qubes repositories, should only be removed with "sudo dnf remove qubes-template- 'template-name'". Do never, EVER, use "qvm-remove" for these primary templates. If I'm not mistaken, this is still possible user-mistake to pull and the system won't prevent you from doing this mistake. Any templates you cannot with normal means re-name, has RPM update enabled, etc. are typically the ones that are primary and require the "sudo dnf remove". Any template copies of the primary Qubes templates you can remove the same way you remove AppVM's, with "qvm-remove VM-name". Just be sure you don't use it on the primary ones like fedora-23, fedora-26, debian-8, debian-9, whonix-gw, and so on. While fedora-26-copy instead must be removed with "qvm-remove", never use qvm-remove on the primary ones. Also be sure to keep a watch out for when fedora-26 has end-of-life (EoL). Check here https://fedoraproject.org/wiki/End_of_life for the known ones. Fedora-26 is still unknown, but if you check here Quote: "Fedora generally develops new releases over a six month period to provide a regular and predictable release schedule. The bi-annual targeted release dates are May Day (May 1st) and Halloween (October 31) making them easy to remember and for avoiding significant holiday breaks. Changes to this standard must be approved by the community-elected Fedora Engineering Steering Committee (FESCo)." https://fedoraproject.org/wiki/Fedora_Release_Life_Cycle Basically, new release every 6 months, but it takes extra time to fully update the release to stable, including older versions having further support for a while afterwards. They are generally kept updated in rougly 400 days after first release. So be sure to check when to upgrade to fedora-27. Qubes will still release qubes-based-updates after fedora EoL, so you might get the illustion its still maintained, when it's not. Keep an aye out for these dates. -- 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/164a0fe6-4e9e-4d50-ba5f-f59f2fa658d5%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Split GPG and Emacs/mu4e: able to retrieve email but not send
Novice computer user here. I use mu4e with mbsync in emacs for email. Login info for email is retrieved from an encrypted file. The appropriated gpg keys are present and working in the offline gpg-qube. Using "/usr/bin/qubes-gpg-client-wrapper" in place of "gpg" as a pass command in the mbsync file for retrieving login information from the encrypted file is working properly for retrieving my email, but when I try to send an email I get an error: Error while decrypting with "gpg2": gpg: encrypted with RSA key, ID gpg: decryption failed: No secret key I thought that I might just need to change the epg-gpg-program variable in emacs to qubes-gpg-client or /usr/bin/qubes-gpg-client-wrapper but neither of those two changes make any difference. It only results in the same error message, but with "gpg2" being replaced by "qubes-gpg-client" or "/urs/bin/qubes-gpg-client-wrapper". I've scoured the internet and have exhausted my ability to try to troubleshoot this with my own understanding. I'm hoping that someone here can point out what I've missed. -- 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/6f9cdb1b-53e5-4da1-abff-1256d0ae1bf6%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: [qubes-project] Hosting for OpenQA instance
No one offered yet? Must be someone out there that keep some old desktops/laptops laying around. Can an increase in subscription based donations be of use? For example if, say, 10 people each donate 10 euro (or alternatively expand any current donation subscription with 10 euro), then it should be sufficient to solve this issue? -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To 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/3a262992-a588-48d5-884e-2597b7fa476e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Can I install Qubes 4.0 rc3 on external hard drive?
On Friday, January 26, 2018 at 8:45:43 PM UTC+1, bill...@gmail.com wrote: > Thanks so much for your reply and your help. I installed using legacy boot > and it worked fine -- in fact, I'm responding from "untrusted firefox" right > now! I don't know if qubes comes up in the grub menu yet. I just got this > installed, and ran it from the BIOS boot sequence Legacy-USB option, and I'm > off for some errands myself. > > However, in lieu of killing myself with UEFI, since this works, I'll stick > with it and am a happy camper. Maybe in the next week I'll play around more > with UEFI, but I'm going to have to learn a bit more about it, I think. > > Anyway, you made my weekend! Thanks again for your reply. I'm glad you got it working! :) Try run 'qubes-hcl-report' in dom0, and check if HVM, I/O MMU, HAP/SLAT, TPM, and Remapping, is working properly in your Qubes setup. The top one, HVM, as far as I know is the most important one. The lowest, remapping, should with my limited knowledge as far as I can tell, be the least important of the 5. All of them are relevant for security, and to some extent, proper working features. If I'm not mistaken, I haven't ventured into these waters before, and someone might correct me here. But I believe if a Qubes (or Linux in general) uses the same partition table as UEFI/EFI (GPT), over the old out-dated MBR), then it might be possible to switch between UEFI/EFI and Legacy/BIOS without re-installing a system if retaining the modern GTR partition table. But it can be tricky if something goes wrong, especially if you have precious data you don't want to loose. Also UEFI/EFI is heavily reliant on not having a buggy motherboard firmware, which many unfortunately have. I also recall having issues not being able to restore an EFI path for Qubes 4, which used to always work on the same machine on Qubes 3.2. I'm not sure if this got fixed, it was some months back and Qubes 4 has rapidly been updated on many ways since then. But this issue is likely to be Qubes related, or at least partly Qubes related. So it's not always the hardware that is causing it, although the hardware in this case might be part-reason still. Remember to take frequent AppVM backups. If you're learning with the trial and error method like I do, many things can end up going wrong. For example, burned my fingers more than a few times my self there before I got into proper backup habits. Never take that risk, it will eventually go wrong :') -- 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/fe19c798-c618-4887-aaae-802b8619ec8f%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] clock VM
> On 01/27/18 22:12, haaber wrote: >> Hello, all of my appVMs run on random times. I reall having had this >> issue on Q3.2 but it comes back on Q4.3 - I forgot the solution in the >> meantime. Qumes-Manager indicates sys-net is ClockVM. How do I configure >> all AppVM's to fetch time there?? Thank you !! Bernhard > > Do you have a laptop and are you suspending/resuming ? If yes, do you > have totally random times, or is the clock lagging ? You are right it is a > laptop that is sometimes suspended, and yes, all times are lagging. And they are not lagging randomly, as I first thought: this mail-VM and dom0 for example are precisely 6h late. My anon-whonix is exactly 1h late and sys-whonix as well (so the TOR circuit cannot be set up due to timing errors). qvm-sync-clock (run as root) does not change anything. This observation, together with the entire-number of hours delta suggests that I may just need to set timeszones in each VM correctly! I try that out ... Thank you. Bernhard -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/9c71cfcf-0c50-9152-d517-ae5181f90b55%40web.de. For more options, visit https://groups.google.com/d/optout.
[qubes-users] possible editing bug in default KDE setup script
I downloaded and installed KDE today, and it went fine. Now I am upgrading the default fedora-25 template to fedora-26. I've gone through the downloading and all, and am now at the "change default template" part. So... I click on Applications-> System Tools -> Qubes Global Settings and nothing happens. I try to find out where it's supposed to be, so I click on "edit application -> Application" and lo and behold, it has "/user/bin" as the Work Path. I go look in /usr/bin and there it is -- and it runs fine from the command line. I'm pretty confident I didn't type in /user/bin as the work path, since I had no clue where it lived and was looking for it. This may be a copyediting error in the script for KDE installation. Been there, done that. billo -- 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/907a1fa7-1c07-48df-8256-029972f5ac52%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] clock VM
On 01/27/18 22:12, haaber wrote: Hello, all of my appVMs run on random times. I reall having had this issue on Q3.2 but it comes back on Q4.3 - I forgot the solution in the meantime. Qumes-Manager indicates sys-net is ClockVM. How do I configure all AppVM's to fetch time there?? Thank you !! Bernhard Do you have a laptop and are you suspending/resuming ? If yes, do you have totally random times, or is the clock lagging ? What happens when you run 'qvm-sync-clock' in a VM with the wrong time ? If you had clock lags and the VM's clock gets synchronized when you run qvm-sync-clock, you probably have the same problem I described in issue #3489 ([1]). I tried to debug it the day after I reported it, but I then noticed that the problem had gone away by itself (!) and all the VMs' clocks were synchronized. I didn't manage to replicate the bug since then so I closed the issue, but feel free to reopen. [1] https://github.com/QubesOS/qubes-issues/issues/3489 -- 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/8d2fe569-546e-bfae-b1c1-e67127df8c78%40maa.bz. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] ERROR: Device attach failed
On Sat, 27 Jan 2018, beso wrote: > On Saturday, January 27, 2018 at 4:33:47 PM UTC+2, awokd wrote: > > On Sat, January 27, 2018 2:20 pm, beso wrote: > > > > >> On Sat, January 27, 2018 6:31 am, beso wrote: > > >> > > >>> ERROR: Device attach failed: /usr/lib/qubes/usb-import: 37: [: > > >>> Illegal > > >>> number: stash: printf: I/O error. > > >>> How to solve this problem? > > >>> > > > > > Sorry, > > > > No trouble! > > > > > Qubes - 3.2; > > > Attached device - Samsung M3 Portable 1TB; > > > Command I used to attach to one of my appVm - qvm-usb -a appvm > > > sys-net:3-1; > > > > I'm assuming the ";" at the end of sys-net:3-1 is a separator and not > > actually part of the command you are entering, right? Has this device > > worked before on your system or is this the first time you are trying it? > > If it was working before, when did it start giving you the error? > > Yes, that is separator here. No, it never worked. I'd recommend you use qvm-block instead of qvm-usb (for block capable devices such as external HDDs). qvm-block should work even with usb3 connected devices. This particular error message you see is caused by a formating change in usbip status file for 4.9 kernels that is incompatible what qubes-usb-proxy expects. There's an updated version for qubes-usb-proxy in R3.2 testing repo that is capable of getting past this error (but ironically, even there there is inconsistency between assumed status file format and what 4.9 prints but it luckily affects only unused variables). However, qvm-usb will fail in R3.2 with even if this error is fixed based on the testing I did yesterday: usbip doesn't seem to, e.g., fall-back to highspeed but attempts to use superspeed that is only supported starting 4.13 kernel and you just get a different error message. -- i. -- 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.1801272200590.9381%40whs-18.cs.helsinki.fi. For more options, visit https://groups.google.com/d/optout.
[qubes-users] clock VM
Hello, all of my appVMs run on random times. I reall having had this issue on Q3.2 but it comes back on Q4.3 - I forgot the solution in the meantime. Qumes-Manager indicates sys-net is ClockVM. How do I configure all AppVM's to fetch time there?? Thank you !! Bernhard -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/226dbaea-92bc-5229-600b-509e0348f3cd%40web.de. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Qubes 4.0 Documentation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Fri, Jan 26, 2018 at 11:37:31PM -0600, Andrew David Wong wrote: > On 2018-01-26 05:14, awokd wrote: > > On Fri, January 26, 2018 3:36 am, Andrew David Wong wrote: > >> On 2018-01-25 12:28, awokd wrote: > >>> 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. > > > > https://github.com/QubesOS/qubes-issues/issues/3495 > > > > > >> 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). > > > > What will be the naming convention for direct links? I can see > > sometimes we'd want to link to the latest version of qvm-whatever, > > and other times when we want to link to a specific major version. > > > > We could either have different subdirectories for each version or > include the version in the page name, as we do for some other > version-specific pages. I'd go with different subdirectories - it will be easier to handle (both generate and later reference). - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? -BEGIN PGP SIGNATURE- iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlps18QACgkQ24/THMrX 1yyZ8Af+P6P0CjFiUiW1HdMHe5NCje/ZxjJxpSE+HXLPT/2Hr+Bhm/CjIGXS7cOr /IO920qG3+c6EmDxBplIDCCaov5xz3jxWih5JjtRR9FUx29yCGwm9Fu2vHPiiaDJ RvEmTFRfkGgsm3EOJ1U/j7uao7uuMPrpRmyVNyWWIKHKPk6S/DmBodVQepl7uE2Q Mw/uXITtl3EaBfGoN/W6lnCNc0/0E6wPLUv6rsMaeSEAcihzRlrzAXDDdcNYWMQL EWEYV/mqdXjtksqtzLMCpQwiCkuGBOhIptQjRZ3DqBPQZQm5eQH4+tbytBR63nby tQqOXmUDWjBFdj3UuulZkQVbRUxNuw== =6lu1 -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/20180127194924.GF2653%40mail-itl. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qubes 4.0 Documentation
On Thursday, 25 January 2018 19:28:58 CET 'awokd' via qubes-users 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: Awesome! I was thinking about the qubes docs when I saw a wiki that had a banner for articles (or sections) that were known to be "disputed". I was wondering if it might be useful to have such a concept on the doc pages, it may invite people to actually add their knowledge. -- Tom Zander Blog: https://zander.github.io Vlog: https://vimeo.com/channels/tomscryptochannel -- 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/2186960.iXCjZ6PEC1%40mail. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Network turns off when I close laptop lid, and I can't restart it
That was it! Thanks, folks. Problem is solved. billo -- 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/8c86efcd-629d-4b33-97f7-2a692dd02e41%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Network turns off when I close laptop lid, and I can't restart it
workarounds, fixes: https://github.com/QubesOS/qubes-issues/issues/3486 -- 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/kLUYryhOUdITkAaWqlAyt6ajYx0jie5i_JwSdQU03zI7Qz2wM0IpomMc9aUjaYF7kZHiNJOvqYoCcNSZra9SPPwM2HpC-WqGLverg2fKciM%3D%40protonmail.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Network turns off when I close laptop lid, and I can't restart it
On 01/27/2018 12:26 PM, billol...@gmail.com wrote: > I recently installed Qubes 4 rc3 on my Dell laptop, and it seems to working > well. However, there's a little bit of a problem with my networking. It > comes up fine when I reboot the machine, and runs like a charm... but when I > close the laptop lid, networking turns off, and I can't figure out how to get > it restarted without rebooting. > > I'm currently running KDE as my desktop, but it happened in the default as > well. > > > I have tried the following. In the KDE systems utilities gui, I went to > power management and turned off all the actions on lid closure, power > decline, etc. hoping to keep it from turning off at all. That didn't seem to > change anything. > > I wandered over to the sys-net domain and looked around. When the network is > running, ifconfig shows the wireless interface wls5, as well as vif3.0,lo,and > ens6. Once I close the lid, wls5 disappears though the others are unchanged. > > > ps -ef | grep Network provides /usr/bin/NetworkManager --nodaemon and > sbin/dhclient with a zillion options. > > after I close the lid, only /usr/bin/NetworkManager is running. > > When the network goes off, I have tried > > service networking restart in sys-net domain, and I get [OK] back, but > nothing changes. I tried "service network-manager restart" and "service > NetworkManager restart" but they come up as not existing. > > So... how to I re-initialize networking and NetworkManager when the crump, > and how to do stop it from doing that on lid closing? Did you check out the blacklisting section here ? https://www.qubes-os.org/doc/wireless-troubleshooting/ Good luck! Bernhard -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/99ffd58e-c441-fc5f-5e12-ae3aaf30581c%40web.de. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Network turns off when I close laptop lid, and I can't restart it
I recently installed Qubes 4 rc3 on my Dell laptop, and it seems to working well. However, there's a little bit of a problem with my networking. It comes up fine when I reboot the machine, and runs like a charm... but when I close the laptop lid, networking turns off, and I can't figure out how to get it restarted without rebooting. I'm currently running KDE as my desktop, but it happened in the default as well. I have tried the following. In the KDE systems utilities gui, I went to power management and turned off all the actions on lid closure, power decline, etc. hoping to keep it from turning off at all. That didn't seem to change anything. I wandered over to the sys-net domain and looked around. When the network is running, ifconfig shows the wireless interface wls5, as well as vif3.0,lo,and ens6. Once I close the lid, wls5 disappears though the others are unchanged. ps -ef | grep Network provides /usr/bin/NetworkManager --nodaemon and sbin/dhclient with a zillion options. after I close the lid, only /usr/bin/NetworkManager is running. When the network goes off, I have tried service networking restart in sys-net domain, and I get [OK] back, but nothing changes. I tried "service network-manager restart" and "service NetworkManager restart" but they come up as not existing. So... how to I re-initialize networking and NetworkManager when the crump, and how to do stop it from doing that on lid closing? Thanks! billo -- 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/b17b799e-351f-48a0-9c2f-ccc364b4ce05%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Newbie question on KDE configuration
I installed Qubes 4 rc3 yesterday and am having a great time exploring it. I'm kind of a KDE person, so I installed KDE, and it works pretty much like a charm, though I'm having a bit of an issue personalizing it. If anybody can give me some aid, I'd appreciate it. First, while KDE seems to be working well, I noticed that I can't download and install new themes, widgets, etc. through the KDE GUI. It can't connect to the KDE server. I'm assuming that this is because dom0 doesn't actually have a network connection (which I think I read somewhere). It's not the end of the world for me to download the stuff from kde.org and install it from file, but it's more convenient to use the gui interface. What I need to know is if it is possible or should I move on and just do it by hand. Second, I really liked that convention in the default window manager for having a different color for the title bar for each domain. That got lost when I moved to KDE, though the domain is still *listed* in the title bar. I know how to set colors in kwin on an application by application basis, but I don't know how to do it on a domain basis. Is there a mechanism for that in KDE? Thanks in advance! billo -- 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/1b7feb42-45a1-4ded-8995-f3f27e64d718%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] ERROR: Device attach failed
On Sat, January 27, 2018 3:00 pm, beso wrote: > On Saturday, January 27, 2018 at 4:33:47 PM UTC+2, awokd wrote: > >> On Sat, January 27, 2018 2:20 pm, beso wrote: >> >> On Sat, January 27, 2018 6:31 am, beso wrote: > ERROR: Device attach failed: /usr/lib/qubes/usb-import: 37: [: > Illegal > number: stash: printf: I/O error. > How to solve this problem? > > >> >>> Sorry, >>> >> >> No trouble! >> >> >>> Qubes - 3.2; >>> Attached device - Samsung M3 Portable 1TB; >>> Command I used to attach to one of my appVm - qvm-usb -a appvm >>> sys-net:3-1; >>> >> >> I'm assuming the ";" at the end of sys-net:3-1 is a separator and not >> actually part of the command you are entering, right? Has this device >> worked before on your system or is this the first time you are trying >> it? If it was working before, when did it start giving you the error? >> > > Yes, that is separator here. No, it never worked. If you're running through an external USB hub, try a direct port. I've also seen some people have had trouble with USB 3.0, so use a 2.0 direct port if possible. If neither of those help, hopefully someone else will have a better idea! -- 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/2abf36b03f29635c6ee1f7566c0c624c.squirrel%40tt3j2x4k5ycaa5zt.onion. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Anon-whonix browser fails to connect to tor in Qubes 3.2, any ideas?
Yeh, the anon-whonix app vm is routed through sys-whonix properly. I haven't changed that from default. I do route most non-whonix app vms through a vpn in a proxy vm but that all works as it should. Both systems have worked independently and as expected for months. Checking today some IP address checks in the anon-whonix app vm do come out in places other than Germany but they're not my vpn's servers, or my ISP's. It's like tor is mostly working but not fully. I'll leave this help request here and see if there are any more suggestions but if I have to I'll try deleting the var/lib/tor file contents - the tor data file mentioned above - and if it doesn't work try re-installing all the whonix stuff. 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/5a5d2c4f-a3db-4579-8ed0-74e573c8e574%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] ERROR: Device attach failed
On Saturday, January 27, 2018 at 4:33:47 PM UTC+2, awokd wrote: > On Sat, January 27, 2018 2:20 pm, beso wrote: > > >> On Sat, January 27, 2018 6:31 am, beso wrote: > >> > >>> ERROR: Device attach failed: /usr/lib/qubes/usb-import: 37: [: > >>> Illegal > >>> number: stash: printf: I/O error. > >>> How to solve this problem? > >>> > > > Sorry, > > No trouble! > > > Qubes - 3.2; > > Attached device - Samsung M3 Portable 1TB; > > Command I used to attach to one of my appVm - qvm-usb -a appvm > > sys-net:3-1; > > I'm assuming the ";" at the end of sys-net:3-1 is a separator and not > actually part of the command you are entering, right? Has this device > worked before on your system or is this the first time you are trying it? > If it was working before, when did it start giving you the error? Yes, that is separator here. No, it never worked. -- 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/2b2e84f6-77f9-4d82-a72e-91e43d6c872a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] connect to other VMs in qubes by using vm name
by adding forward rules at sysfirewall we can ping each other VM through ip address but not using VM name. Is this some thing possible with Qubes 4? I am naive in networking.please suggest if there is a way? 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/2a6cd289-246d-4489-bda5-58544d5db0fd%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] ERROR: Device attach failed
On Sat, January 27, 2018 2:20 pm, beso wrote: >> On Sat, January 27, 2018 6:31 am, beso wrote: >> >>> ERROR: Device attach failed: /usr/lib/qubes/usb-import: 37: [: >>> Illegal >>> number: stash: printf: I/O error. >>> How to solve this problem? >>> > Sorry, No trouble! > Qubes - 3.2; > Attached device - Samsung M3 Portable 1TB; > Command I used to attach to one of my appVm - qvm-usb -a appvm > sys-net:3-1; I'm assuming the ";" at the end of sys-net:3-1 is a separator and not actually part of the command you are entering, right? Has this device worked before on your system or is this the first time you are trying it? If it was working before, when did it start giving you the error? -- 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/7c63a2dafe233ac59c97f8438aa94f25.squirrel%40tt3j2x4k5ycaa5zt.onion. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] ERROR: Device attach failed
On Saturday, January 27, 2018 at 3:58:35 PM UTC+2, awokd wrote: > On Sat, January 27, 2018 6:31 am, beso wrote: > > ERROR: Device attach failed: /usr/lib/qubes/usb-import: 37: [: Illegal > > number: stash: printf: I/O error. > > How to solve this problem? > > Not to sound cranky, but can you review > https://www.qubes-os.org/mailing-lists/ Discussion list guidelines? > There's not enough information in your question to be able to answer it. > For example: Qubes version, type of USB device, speed of USB device, > command or method you are using to attach it, etc. Sorry, Qubes - 3.2; Attached device - Samsung M3 Portable 1TB; Command I used to attach to one of my appVm - qvm-usb -a appvm sys-net:3-1; -- 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/a7284e2d-3eff-4290-b28e-4746f3978853%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] ERROR: Device attach failed
On Sat, January 27, 2018 6:31 am, beso wrote: > ERROR: Device attach failed: /usr/lib/qubes/usb-import: 37: [: Illegal > number: stash: printf: I/O error. > How to solve this problem? Not to sound cranky, but can you review https://www.qubes-os.org/mailing-lists/ Discussion list guidelines? There's not enough information in your question to be able to answer it. For example: Qubes version, type of USB device, speed of USB device, command or method you are using to attach it, 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/86b2d410cfc4441d693294fe2a5a.squirrel%40tt3j2x4k5ycaa5zt.onion. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Anon-whonix browser fails to connect to tor in Qubes 3.2, any ideas?
On Sat, January 27, 2018 11:46 am, code9n wrote: > Running the WhonixCheck from the default anon-whonix app vm in the Qubes > manager list; the fail warning basically says: > > SocksPort test [fails]. ... (curl exit code: [7] - [failed to connect to > host]) > > The browser - anon-whonix app vm (default)/Tor browser - opens like > normal to the Whonix page but checking the 'check IP' link from there > won't connect and if I search for https://check.torproject.org the top > result says I'm not using tor. I can't connect to .onion sites but > surface browsing's fine. > > Checking the IP address keeps coming back to the same one in Germany even > if I reload / change Identity / reboot. (I'm not in Germany). > > It persists over cold re-boots. > I've tried making a new anon-whonix app vm with the same results. > Everything has been fine since install - maybe 6 months ago. > All updates are up to date including the recent tor browser update to 7.5 > (64 bit). In Qubes Manager/System/Global settings, make sure your Default netVM is set to sys-whonix. I can't explain the Germany IP though. Do you have a VPN or ProxyVM set up somewhere in the mix? > > yzxd on the sub reddit (Thanks, yzxd) had a similar problem on non-Qubes > Whonix and solved it by "going into the Gateway VM, stopping Tor, opening > the folder named "Tor Data" and deleting all the files inside, and > finally restarting Tor". > > But I see from issue #1137 the Qubes team deliberately made that > persistent: > > > https://github.com/Whonix/qubes-whonix/commit/a9f24f5d0b700a0cd710e52eb17 > 0875d635c22a9 > > > so I'm wary to mess with that. > > Would that be likely to work in this instance? Or Does anyone have any > ideas for a fix or would just re-installing the entire Whonix system > following: > > > https://www.qubes-os.org/doc/whonix/install/ > > > be better...? Re-installing the whole Whonix system or even Qubes might be the best approach if you can't figure out where that Germany IP is coming from. -- 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/9f301641083c9bfac14af969c329487f.squirrel%40tt3j2x4k5ycaa5zt.onion. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: qubes 4 windows installation
Am Freitag, 26. Januar 2018 19:05:37 UTC+1 schrieb Yuraeitha: > Also on my Qubes 3.2. Win7 on Qubes 4, I can easily transfer files in and out > of Win7, and everything else Qubes related "seems" to work, except I have no > internet connection. Just a heads up, and does anyone else experience this > issue too from their Win7 that came from Qubes 3.2? That's interesting, on my Win7 from 3.2 the tools do not seem to work. But I can confirm the network issue, I must set another DNS server after every boot, then network and internet works. -- 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/90124fde-69c4-4795-b589-3c415dcc985a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Anon-whonix browser fails to connect to tor in Qubes 3.2, any ideas?
Running the WhonixCheck from the default anon-whonix app vm in the Qubes manager list; the fail warning basically says: SocksPort test [fails]. ... (curl exit code: [7] - [failed to connect to host]) The browser - anon-whonix app vm (default)/Tor browser - opens like normal to the Whonix page but checking the 'check IP' link from there won't connect and if I search for https://check.torproject.org the top result says I'm not using tor. I can't connect to .onion sites but surface browsing's fine. Checking the IP address keeps coming back to the same one in Germany even if I reload / change Identity / reboot. (I'm not in Germany). It persists over cold re-boots. I've tried making a new anon-whonix app vm with the same results. Everything has been fine since install - maybe 6 months ago. All updates are up to date including the recent tor browser update to 7.5 (64 bit). yzxd on the sub reddit (Thanks, yzxd) had a similar problem on non-Qubes Whonix and solved it by "going into the Gateway VM, stopping Tor, opening the folder named "Tor Data" and deleting all the files inside, and finally restarting Tor". But I see from issue #1137 the Qubes team deliberately made that persistent: https://github.com/Whonix/qubes-whonix/commit/a9f24f5d0b700a0cd710e52eb170875d635c22a9 so I'm wary to mess with that. Would that be likely to work in this instance? Or Does anyone have any ideas for a fix or would just re-installing the entire Whonix system following: https://www.qubes-os.org/doc/whonix/install/ be better...? 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/6978414b-9934-40e3-96c9-403488a2e332%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.