Re: [qubes-users] ERROR: PCI device does not exist
On 01/10/18 21:36, 'awokd' via qubes-users wrote: Eric wrote on 10/1/18 10:29 AM: When running Centos, does lspci -vvv give the same unusual output for that problem device? Don't know what else to suggest; I have a Realtek dual port RTL8111/8168/8411 PCI Express card in one of my systems and it works fine under Qubes 4.0. No "lspci -vvv" outputs a complete description of both controllers as expected and 01:00.0's first line ends with "(rev 07)" as it should. Strange, sounds like Qubes is initializing just that one device wrong then. I had a similar issue with an old PCIe v1.1 wireless NIC. What version is your NIC? I never got mine working, but you might try adding "xen-pciback.hide=(01:00.0)" to your boot options in xen.cfg and seeing if it will let you assign it to sys-net then. With boot option "xen-pciback.hide=(01:00.0)" (on the options= line in default config in /boot/efi/EFI/qubes/xen.cfg) everything comes up exactly the same. Getting the same error on PCI while booting and same error attempting to start sys-net with 01:00.0 attached. That option appears to be having no effect. The hardware is new as mentioned previously - there are 3 PCI bridges (ports 3,4&5) same as: "00:1c.0 PCI bridge: Intel Corporation Wildcat Point-LP PCI Express Root Port #3 (rev e3) (prog-if 00 [Normal decode])" This is the bad lspci output for NIC 1: "01:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev ff) (prog-if ff) !!! Unknown header type 7f Kernel driver in use: pciback Kernel modules: r8169" Compared to NIC 2: "03:00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 07) Subsystem: Realtek Semiconductor Co., Ltd. Device 0123 Control: I/O+ Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop- ParErr- Stepping- SERR- FastB2B- DisINTx- Status: Cap+ 66MHz- UDF- FastB2B- ParErr- DEVSEL=fast >TAbort- SERR- Latency: 0, Cache Line Size: 64 bytes Interrupt: pin A routed to IRQ 16 Region 0: I/O ports at d000 [size=256] Region 2: Memory at f700 (64-bit, non-prefetchable) [size=4K] Region 4: Memory at f000 (64-bit, prefetchable) [size=16K]" ...lots of capabilities... "Kernel driver in use: pciback Kernel modules: r8169" Only other thing to note am getting "pcilib:sysfs_read_vpd: read failed: Input/output error" on stderr when running lspci for the above output in the good NIC capabilities section, however Centos gets two of these messages, one in the same place for each NIC so I am presuming it is not related to the problem I have with Qubes. -- 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/76709495-5485-dc0e-3b43-1394502d8c26%40asar.biz. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Installation, no AMD-vi, interrupt mapping, etc.
Em segunda-feira, 1 de outubro de 2018 16:04:34 UTC-3, naas...@gmail.com escreveu: > Installation went fine except for a libxenlight config error of some kind. I > still can't enable IOMMU using either of the approaches described in that > Ubuntu thread, even though it successfully worked with raw Linux. > > What boot parameters did you add? I have the earlier rev.1 Sabertooth 990FX > mobo that you have. My mobo is rev.2, firmware 2901 I used (ivrs_ioapic[7]=00:14.0 ivrs_ioapic[8]=00:00.2). I am not using anymore and my qubes 4.0 is working fine. But ubuntu forum has a solved solution with different ioapic: Quick solution for Sabertooth 990FX (R1.0): Edit file /etc/default/grub, find line "GRUB_CMDLINE_LINUX_DEFAULT=", edit it to look like: Code: GRUB_CMDLINE_LINUX_DEFAULT="quiet splash ivrs_ioapic[7]=00:14.0 ivrs_ioapic[8]=00:00.1" There are iommu info here too: from Xen https://wiki.xen.org/wiki/VTd_HowTo If you can not solve the iommu problem, change all vms to PV. Maybe this is the cause of libxenlight error. Change all vms to PV, including sys-net. Later I will send you the commands to start networking. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/d9a20451-f4f1-4510-9ae7-6616c704de0b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] nftables vs iptables
On 10/01/2018 05:48 PM, mfreemon wrote: On 1/11/18 3:01 PM, Chris Laprise wrote: > On 01/10/2018 03:47 PM, Connor Page wrote: >> The official templates use nftables so shouldn’t be mixed with iptables. I didn’t have time to learn about nftables, so just removed nftables package from debian 9 template. YMMV. >> > > Hmmm, I was just thinking how Qubes' own guest scripts still use > iptables even in fedora-26. > > IIUC, iptables and nft are two different interfaces to netfilter. I > don't know if it really matters, at least for the R4.0 window. I'd > prefer to put the syntax change (for docs) off until a later release. I was recently thrown by the mix of both nftables and iptables in R4. The qubes docs don't clarify much. The qubes firewall scripts use nft. Most of the discussion on the qubes website documentation is about iptables, but there are also a few mentions of nft. The upgrade instructions (going from R3.2 to R4) did not mention converting rules from iptables to nftables. It looks like other related projects (one example is qubes-tunnel) is using iptables. Just reading a few things and trying to come up to speed, I get the impression that nftables and iptables should not both by used at the same time. Even if technically possible (i.e. both sets of rules applied correctly), it strikes me as not a great idea to maintain packet filtering rules in two different ways. What is the best practice recommendation on this (for R4, Fedora 28 template)? Are we to be using, exclusively, nftables in R4? The last I read about this (for 4.0) is that nftables is used in Fedora Qubes code, but Debian Qubes is still using iptables. That still appears to be the case since nftables is not installed in my debian-9 templates. I've submitted qubes-tunnel to Qubes with iptables commands only, with the intention to transition to nftables (or that other new interface in Linux, name escapes me just now) for Qubes 4.1. Someone who is just starting a project might be better off going with nftables. -- 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/7a160df8-414a-721a-569c-f7c540b5a0e8%40posteo.net. For more options, visit https://groups.google.com/d/optout.
[qubes-users] nftables vs iptables
On 1/11/18 3:01 PM, Chris Laprise wrote: > On 01/10/2018 03:47 PM, Connor Page wrote: >> The official templates use nftables so shouldn’t be mixed with iptables. I didn’t have time to learn about nftables, so just removed nftables package from debian 9 template. YMMV. >> > > Hmmm, I was just thinking how Qubes' own guest scripts still use > iptables even in fedora-26. > > IIUC, iptables and nft are two different interfaces to netfilter. I > don't know if it really matters, at least for the R4.0 window. I'd > prefer to put the syntax change (for docs) off until a later release. I was recently thrown by the mix of both nftables and iptables in R4. The qubes docs don't clarify much. The qubes firewall scripts use nft. Most of the discussion on the qubes website documentation is about iptables, but there are also a few mentions of nft. The upgrade instructions (going from R3.2 to R4) did not mention converting rules from iptables to nftables. It looks like other related projects (one example is qubes-tunnel) is using iptables. Just reading a few things and trying to come up to speed, I get the impression that nftables and iptables should not both by used at the same time. Even if technically possible (i.e. both sets of rules applied correctly), it strikes me as not a great idea to maintain packet filtering rules in two different ways. What is the best practice recommendation on this (for R4, Fedora 28 template)? Are we to be using, exclusively, nftables in R4? -- 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/15321f4d-255d-23ac-2283-90571bee996e%40zoho.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] /dev/mapper/qubes_dom0-root does not exist
On 10/01/2018 05:24 PM, Chris Laprise wrote: On 10/01/2018 02:50 PM, Micah Lee wrote: I recently installed Qubes 4.0 on a laptop, installed updates in dom0 and my templates, restored a backup, and did a bunch of custom configuration. And then when I rebooted, Qubes wouldn't boot up due to a partitioning error. (It looks like it's the same problem described here [1]). During boot, I get a hundreds of lines that says: dracut-initqueue[343]: Warning: dracut-initqueue timeout - starting timeout scripts Followed by: dracut-initqueue[343]: Warning: Could not boot. dracut-initqueue[343]: Warning: /dev/mapper/qubes_dom0-root does not exist dracut-initqueue[343]: Warning: /dev/qubes_dom0/root does not exist Starting Dracut Emergency Shell... Then it drops me into an emergency shell. When I run lv_scan, I can see: Scanning devices dm-0 for LVM logical volumes qubes_dom0/root qubes_dom/swap inactive '/dev/qubes_dom0/pool00' [444.64 GiB] inherit inactive '/dev/qubes_dom0/root' [444.64 GiB] inherit ACTIVE '/dev/qubes_dom0/swap' [15.29 GiB] inherit inactive '/dev/qubes_dom0/vm-sys-net-private [2 GiB] inherit And it continues to list another inactive line for each private or root partition for each of my VMs. Only swap is active. I spent a little time trying to troubleshoot this, but ultimately decided that it wasn't worth the time, since I have a fresh backup. So I formatted my disk again, reinstalled Qubes, restored my backup, etc. After installing more updates and rebooting, I just ran into this exact same problem *again*. I think this could be a Qubes bug. Any idea on how I can fix this situation? The dracut emergency shell doesn't seem to come with many LVM tools. There's lvm, lvm_scan, thin_check, thun_dump, thin_repair, and thin_restore. I could boot to the Qubes USB and drop into a troubleshooting shell to have access to more tools. [1] https://groups.google.com/forum/#!searchin/qubes-users/dracut-initqueue$20could$20not$20boot|sort:date/qubes-users/PR3-ZbZXo_0/G8DA86zhCAAJ If you do 'sudo lvdisplay qubes_dom0/root' it will probably say LV status is 'Not Available'. This could mean an 'lvchange' somewhere set those volumes (pool00, root, etc) to setactivationskip=y. You can attempt to fix it at least temporarily like so: sudo lvchange -kn -ay qubes_dom0/pool00 sudo lvchange -kn -ay qubes_dom0/root sudo lvchange -kn -ay qubes_dom0/vm-sys-net-private Then use lvdisplay to verify the LV status has changed. BTW if you can run 'lvm' in the rescue shell then you can use that for various lv* commands including 'lvchange'. Just run 'lvm' by itself and that will put you in an lvm shell where the 'lvchange' command and others are accessible. -- 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/9f8ce612-f061-62d2-9237-55ef0a5e7193%40posteo.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] /dev/mapper/qubes_dom0-root does not exist
On 10/01/2018 02:50 PM, Micah Lee wrote: I recently installed Qubes 4.0 on a laptop, installed updates in dom0 and my templates, restored a backup, and did a bunch of custom configuration. And then when I rebooted, Qubes wouldn't boot up due to a partitioning error. (It looks like it's the same problem described here [1]). During boot, I get a hundreds of lines that says: dracut-initqueue[343]: Warning: dracut-initqueue timeout - starting timeout scripts Followed by: dracut-initqueue[343]: Warning: Could not boot. dracut-initqueue[343]: Warning: /dev/mapper/qubes_dom0-root does not exist dracut-initqueue[343]: Warning: /dev/qubes_dom0/root does not exist Starting Dracut Emergency Shell... Then it drops me into an emergency shell. When I run lv_scan, I can see: Scanning devices dm-0 for LVM logical volumes qubes_dom0/root qubes_dom/swap inactive '/dev/qubes_dom0/pool00' [444.64 GiB] inherit inactive '/dev/qubes_dom0/root' [444.64 GiB] inherit ACTIVE '/dev/qubes_dom0/swap' [15.29 GiB] inherit inactive '/dev/qubes_dom0/vm-sys-net-private [2 GiB] inherit And it continues to list another inactive line for each private or root partition for each of my VMs. Only swap is active. I spent a little time trying to troubleshoot this, but ultimately decided that it wasn't worth the time, since I have a fresh backup. So I formatted my disk again, reinstalled Qubes, restored my backup, etc. After installing more updates and rebooting, I just ran into this exact same problem *again*. I think this could be a Qubes bug. Any idea on how I can fix this situation? The dracut emergency shell doesn't seem to come with many LVM tools. There's lvm, lvm_scan, thin_check, thun_dump, thin_repair, and thin_restore. I could boot to the Qubes USB and drop into a troubleshooting shell to have access to more tools. [1] https://groups.google.com/forum/#!searchin/qubes-users/dracut-initqueue$20could$20not$20boot|sort:date/qubes-users/PR3-ZbZXo_0/G8DA86zhCAAJ If you do 'sudo lvdisplay qubes_dom0/root' it will probably say LV status is 'Not Available'. This could mean an 'lvchange' somewhere set those volumes (pool00, root, etc) to setactivationskip=y. You can attempt to fix it at least temporarily like so: sudo lvchange -kn -ay qubes_dom0/pool00 sudo lvchange -kn -ay qubes_dom0/root sudo lvchange -kn -ay qubes_dom0/vm-sys-net-private Then use lvdisplay to verify the LV status has changed. -- 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/956595f3-512f-bf91-d829-01104752e733%40posteo.net. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Whonix-Workstation VM and associate AppVMs not connecting in Qubes 3.2
On 10/1/18 10:13 AM, 'Setherson' via qubes-users wrote: >> On Oct 1, 2018, at 3:18 AM, 'awokd' via qubes-users >> wrote: >> >> 'Setherson' via qubes-users wrote on 9/30/18 2:12 AM: >> >>> I am using Qubes 3.2. All TemplateVMs and dom0 have been updated sometime >>> within the past week. >>> >>> Since about the same time, my Workstation TemplateVM and every AppVM based >>> on it has been unable to connect to the internet. >>> >>> The Whonix Gateway TemplateVM works fine, as does the sys-whonix NetVM. >>> Furthermore, all the AppVMs based on the Fedora and Debian templates work >>> even when routed through sys-whonix. I also have all the TemplateVMs set to >>> update through sys-whonix, and every one of them is able to do this with >>> the sole exception of whonix-ws-14. So if I had to guess, I’d say the >>> problem lies with the Whonix Workstation TemplateVM itself. >>> >>> When I try updating whonix-ws-14, it “hits” everything until the 10th >>> repository. Once it gets there, the screen shows “[working]” and stays >>> there. >>> >>> Has anyone else run into this problem? What steps can I take to begin >>> troubleshooting it? >>> >>> Thanks in advance! >> >> You might have caught a bad update last week, and it sounds like one of >> the repositories you're using is unavailable right now. You can try the >> suggestions in >> https://forums.whonix.org/t/errors-updating-september-2018/6028/8, or >> wait a day or so and try updating 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+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/ez6zc...@public.gmane.org >> To post to this group, send email to >> qubes-users-/JYPxA39Uh5TLH3MbocFF+G/ez6zc...@public.gmane.org >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/qubes-users/ffa818ac-b732-a43f-657f-b679dcb5ad93%40danwin1210.me. >> For more options, visit https://groups.google.com/d/optout. > > Thanks for the link! I did what they advised and the Workstation-14 > TemplateVM seems to have updated fine. > > However, the most serious issues remain. > > I am still unable to access the internet from any of my Workstation-based > AppVMs. Here’s what happens: > > When I first open the Tor Browser, I receive a warning that my activities may > be linked if the Tor Browser is already running. I have gotten this sort of > warning in the past when I already have an instance of the TB running, but > that’s not the case here. > > I click “yes” to get rid of the warning box and the Tor Browser proceeds to > open. The first sign that something is (still) not right is that it’s unable > to find the local Whonix splash page file that always pops up when the > browser first starts. Weird, but certainly not a huge issue. > > Then, when I try to do a random search (I use DDG’s Onion service to conduct > searches), I’m told that the server has reloaded while the request was being > made (or something to that effect; it’s a super-common error message). > Whatever the cause may be, the result is that I’m unable to visit any > website; Google, DDG Onion, DDG Clearnet, and so on all give me the same > error. > > It occurred to me that this might be a Tor Browser problem, so I opened up > the Electrum bitcoin client in the same AppVM to see if that works. > Unfortunately, Electrum doesn’t connect either. > > Then—again in the same AppVM—I open up konsole and ping google (both > google.com and 8.8.8.8): Interestingly, when I ping google.com the terminal > shows me the site’s corresponding numerical IPv4 address, so there must be > some sort of DNS access, right? Anyway, aside from seeing the IPv4 address I > get no feedback whatsoever for the next 20-30 seconds, so I finally Ctrl-C > the process and see a packet loss of 100%. > > Finally, I open Firefox in my “Untrusted” AppVM, which uses Fedora 28 as its > template and sys-whonix as its NetVM. It takes me to Google without a hitch. > > Any ideas? Is this just a bad update I’m going to have to wait out, or are > there steps I can take to remedy the situation in the meantime? > Yes, exactly the same here, commenting out allows update but I've been noticing these DDG .onion resets for maybe a week or more and just last few days , maybe because I haven't rebooted the AppVM for a while the warning about activity "being linked" two other things: 1) the Qube manager despite sucessfully updates, the green arrow to need update persists , even after restarting the Q manager and 2) update-torbrowser gives a scary warning in whonix-ws-14 to override it two options , I haven't tried either .. btw, this is all in Q4.0 with the latest dom0 patches , most recent just a few days ago . -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To
Re: [qubes-users] Whonix-Workstation VM and associate AppVMs not connecting in Qubes 3.2
On 10/1/18 10:23 AM, Setherson wrote: >> I should have said in my previous email that I got the same error you just >> pasted. What I did was comment out the onion server in >> /etc/apt/sources.list.d/whonix.list as well. >> >> That fixed the problem for me. >> >> -- >> 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/14B90DBC-970F-44E7-8613-4ABBA7018C5B%40protonmail.ch](https://groups.google.com/d/msgid/qubes-users/14B90DBC-970F-44E7-8613-4ABBA7018C5B%40protonmail.ch?utm_medium=email_source=footer). >> For more options, visit https://groups.google.com/d/optout. > > Just to be absolutely clear, I meant that commenting out the onion server in > whonix.list fixed the updating problem, not any of the other ones. > sorry my bad, read the email to fast, seems to be working for me as well #'ing out the 3 references in both lists . apparently per the instructions in the file list, it says this file can and may be written over, so maybe the solution won't last appreciate your help , fixed for now whonix forum is calling the debian .onion servers "dodgy" . not sure whats thats based anyhow cheers -- A895 0C7C A244 8E2E FD77 A3DB 180B 7D4D D158 F8B6 -- 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/0e531adb-94a4-3e72-e87e-e79d1014106e%40riseup.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Whonix-Workstation VM and associate AppVMs not connecting in Qubes 3.2
> I should have said in my previous email that I got the same error you just > pasted. What I did was comment out the onion server in > /etc/apt/sources.list.d/whonix.list as well. > > That fixed the problem for me. > > -- > 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/14B90DBC-970F-44E7-8613-4ABBA7018C5B%40protonmail.ch](https://groups.google.com/d/msgid/qubes-users/14B90DBC-970F-44E7-8613-4ABBA7018C5B%40protonmail.ch?utm_medium=email_source=footer). > For more options, visit https://groups.google.com/d/optout. Just to be absolutely clear, I meant that commenting out the onion server in whonix.list fixed the updating problem, not any of the other ones. -- 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/D28F066F-7D81-4B48-B7B3-2A29E0890352%40protonmail.ch. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Whonix-Workstation VM and associate AppVMs not connecting in Qubes 3.2
On 10/1/18 10:17 AM, Setherson wrote: >> On Oct 1, 2018, at 3:06 PM, John S.Recdep wrote: >> >> On 9/30/18 10:18 PM, 'awokd' via qubes-users wrote: >> >>> 'Setherson' via qubes-users wrote on 9/30/18 2:12 AM: >>> I am using Qubes 3.2. All TemplateVMs and dom0 have been updated sometime within the past week. Since about the same time, my Workstation TemplateVM and every AppVM based on it has been unable to connect to the internet. The Whonix Gateway TemplateVM works fine, as does the sys-whonix NetVM. Furthermore, all the AppVMs based on the Fedora and Debian templates work even when routed through sys-whonix. I also have all the TemplateVMs set to update through sys-whonix, and every one of them is able to do this with the sole exception of whonix-ws-14. So if I had to guess, I’d say the problem lies with the Whonix Workstation TemplateVM itself. When I try updating whonix-ws-14, it “hits” everything until the 10th repository. Once it gets there, the screen shows “[working]” and stays there. Has anyone else run into this problem? What steps can I take to begin troubleshooting it? Thanks in advance! >>> >>> You might have caught a bad update last week, and it sounds like one of >>> the repositories you're using is unavailable right now. You can try the >>> suggestions in >>> https://forums.whonix.org/t/errors-updating-september-2018/6028/8, or >>> wait a day or so and try updating again. >> >> actually the method from the whonix forum still fails : (# commenting >> out the 2 onion repo references >> >> sudo apt-get dist-upgrade works but not , as below >> >> user@host:~$ sudo apt-get update >> Hit:1 [http://deb.whonix.org](http://deb.whonix.org/) stretch InRelease >> >> Hit:2 http://deb.qubes-os.org/r4.0/vm stretch InRelease >> >> Hit:3 [http://security.debian.org](http://security.debian.org/) >> stretch/updates InRelease >> Ign:4 http://ftp.us.debian.org/debian stretch InRelease >> Hit:5 http://ftp.us.debian.org/debian stretch Release >> Reading package lists... Done >> E: The method driver /usr/lib/apt/methods/tor+http could not be found. >> N: Is the package apt-transport-tor installed? >> E: Failed to fetch >> tor+http://deb.dds6qkxpwdeubwucdiaord2xgbbeyds25rbsgr73tbfpqpt4a6vjwsyd.onion/dists/stretch/InRelease >> >> E: Some index files failed to download. They have been ignored, or old >> ones used instead. >> >> -- >> 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/7c777292-fdd6-0c1c-91b0-0334cb4e1a67%40riseup.net. >> For more options, visit https://groups.google.com/d/optout. > > I should have said in my previous email that I got the same error you just > pasted. What I did was comment out the onion server in > /etc/apt/sources.list.d/whonix.list as well. > > That fixed the problem for me. > What I'm seeing in the sources list is this : #kdesudo xdg-open /etc/apt/sources.list.d/user.list deb tor+http://sgvtcaew4bxjd7ln.onion stretch/updates main contrib non-free deb http://security.debian.org stretch/updates main contrib non-free deb tor+http://vwakviie2ienjx6t.onion/debian stretch main contrib non-free deb http://ftp.us.debian.org/debian stretch main contrib non-free If I comment out both tor+http references and restart the Template it still fails, Which one are you saying is THE "onion server" ? -- A895 0C7C A244 8E2E FD77 A3DB 180B 7D4D D158 F8B6 -- 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/3d1547cd-cdbe-7e7b-24b3-b825b991c4d4%40riseup.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Whonix-Workstation VM and associate AppVMs not connecting in Qubes 3.2
> On Oct 1, 2018, at 3:06 PM, John S.Recdep wrote: > > On 9/30/18 10:18 PM, 'awokd' via qubes-users wrote: > >> 'Setherson' via qubes-users wrote on 9/30/18 2:12 AM: >> >>> I am using Qubes 3.2. All TemplateVMs and dom0 have been updated >>> sometime within the past week. >>> >>> Since about the same time, my Workstation TemplateVM and every AppVM >>> based on it has been unable to connect to the internet. >>> >>> The Whonix Gateway TemplateVM works fine, as does the sys-whonix >>> NetVM. Furthermore, all the AppVMs based on the Fedora and Debian >>> templates work even when routed through sys-whonix. I also have all >>> the TemplateVMs set to update through sys-whonix, and every one of >>> them is able to do this with the sole exception of whonix-ws-14. So if >>> I had to guess, I’d say the problem lies with the Whonix Workstation >>> TemplateVM itself. >>> >>> When I try updating whonix-ws-14, it “hits” everything until the 10th >>> repository. Once it gets there, the screen shows “[working]” and stays >>> there. >>> >>> Has anyone else run into this problem? What steps can I take to begin >>> troubleshooting it? >>> >>> Thanks in advance! >> >> You might have caught a bad update last week, and it sounds like one of >> the repositories you're using is unavailable right now. You can try the >> suggestions in >> https://forums.whonix.org/t/errors-updating-september-2018/6028/8, or >> wait a day or so and try updating again. > > actually the method from the whonix forum still fails : (# commenting > out the 2 onion repo references > > sudo apt-get dist-upgrade works but not , as below > > user@host:~$ sudo apt-get update > Hit:1 [http://deb.whonix.org](http://deb.whonix.org/) stretch InRelease > > Hit:2 http://deb.qubes-os.org/r4.0/vm stretch InRelease > > Hit:3 [http://security.debian.org](http://security.debian.org/) > stretch/updates InRelease > Ign:4 http://ftp.us.debian.org/debian stretch InRelease > Hit:5 http://ftp.us.debian.org/debian stretch Release > Reading package lists... Done > E: The method driver /usr/lib/apt/methods/tor+http could not be found. > N: Is the package apt-transport-tor installed? > E: Failed to fetch > tor+http://deb.dds6qkxpwdeubwucdiaord2xgbbeyds25rbsgr73tbfpqpt4a6vjwsyd.onion/dists/stretch/InRelease > > E: Some index files failed to download. They have been ignored, or old > ones used instead. > > -- > 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/7c777292-fdd6-0c1c-91b0-0334cb4e1a67%40riseup.net. > For more options, visit https://groups.google.com/d/optout. I should have said in my previous email that I got the same error you just pasted. What I did was comment out the onion server in /etc/apt/sources.list.d/whonix.list as well. That fixed the problem for me. -- 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/14B90DBC-970F-44E7-8613-4ABBA7018C5B%40protonmail.ch. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Whonix-Workstation VM and associate AppVMs not connecting in Qubes 3.2
> On Oct 1, 2018, at 3:18 AM, 'awokd' via qubes-users > wrote: > > 'Setherson' via qubes-users wrote on 9/30/18 2:12 AM: > >> I am using Qubes 3.2. All TemplateVMs and dom0 have been updated sometime >> within the past week. >> >> Since about the same time, my Workstation TemplateVM and every AppVM based >> on it has been unable to connect to the internet. >> >> The Whonix Gateway TemplateVM works fine, as does the sys-whonix NetVM. >> Furthermore, all the AppVMs based on the Fedora and Debian templates work >> even when routed through sys-whonix. I also have all the TemplateVMs set to >> update through sys-whonix, and every one of them is able to do this with the >> sole exception of whonix-ws-14. So if I had to guess, I’d say the problem >> lies with the Whonix Workstation TemplateVM itself. >> >> When I try updating whonix-ws-14, it “hits” everything until the 10th >> repository. Once it gets there, the screen shows “[working]” and stays there. >> >> Has anyone else run into this problem? What steps can I take to begin >> troubleshooting it? >> >> Thanks in advance! > > You might have caught a bad update last week, and it sounds like one of > the repositories you're using is unavailable right now. You can try the > suggestions in > https://forums.whonix.org/t/errors-updating-september-2018/6028/8, or > wait a day or so and try updating 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/ffa818ac-b732-a43f-657f-b679dcb5ad93%40danwin1210.me. > For more options, visit https://groups.google.com/d/optout. Thanks for the link! I did what they advised and the Workstation-14 TemplateVM seems to have updated fine. However, the most serious issues remain. I am still unable to access the internet from any of my Workstation-based AppVMs. Here’s what happens: When I first open the Tor Browser, I receive a warning that my activities may be linked if the Tor Browser is already running. I have gotten this sort of warning in the past when I already have an instance of the TB running, but that’s not the case here. I click “yes” to get rid of the warning box and the Tor Browser proceeds to open. The first sign that something is (still) not right is that it’s unable to find the local Whonix splash page file that always pops up when the browser first starts. Weird, but certainly not a huge issue. Then, when I try to do a random search (I use DDG’s Onion service to conduct searches), I’m told that the server has reloaded while the request was being made (or something to that effect; it’s a super-common error message). Whatever the cause may be, the result is that I’m unable to visit any website; Google, DDG Onion, DDG Clearnet, and so on all give me the same error. It occurred to me that this might be a Tor Browser problem, so I opened up the Electrum bitcoin client in the same AppVM to see if that works. Unfortunately, Electrum doesn’t connect either. Then—again in the same AppVM—I open up konsole and ping google (both google.com and 8.8.8.8): Interestingly, when I ping google.com the terminal shows me the site’s corresponding numerical IPv4 address, so there must be some sort of DNS access, right? Anyway, aside from seeing the IPv4 address I get no feedback whatsoever for the next 20-30 seconds, so I finally Ctrl-C the process and see a packet loss of 100%. Finally, I open Firefox in my “Untrusted” AppVM, which uses Fedora 28 as its template and sys-whonix as its NetVM. It takes me to Google without a hitch. Any ideas? Is this just a bad update I’m going to have to wait out, or are there steps I can take to remedy the situation in the meantime? -- 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/01306F2C-5A4B-4A56-96EB-7C0729907300%40protonmail.ch. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Whonix-Workstation VM and associate AppVMs not connecting in Qubes 3.2
On 9/30/18 10:18 PM, 'awokd' via qubes-users wrote: > 'Setherson' via qubes-users wrote on 9/30/18 2:12 AM: >> I am using Qubes 3.2. All TemplateVMs and dom0 have been updated >> sometime within the past week. >> >> Since about the same time, my Workstation TemplateVM and every AppVM >> based on it has been unable to connect to the internet. >> >> The Whonix Gateway TemplateVM works fine, as does the sys-whonix >> NetVM. Furthermore, all the AppVMs based on the Fedora and Debian >> templates work even when routed through sys-whonix. I also have all >> the TemplateVMs set to update through sys-whonix, and every one of >> them is able to do this with the sole exception of whonix-ws-14. So if >> I had to guess, I’d say the problem lies with the Whonix Workstation >> TemplateVM itself. >> >> When I try updating whonix-ws-14, it “hits” everything until the 10th >> repository. Once it gets there, the screen shows “[working]” and stays >> there. >> >> Has anyone else run into this problem? What steps can I take to begin >> troubleshooting it? >> >> Thanks in advance! > > You might have caught a bad update last week, and it sounds like one of > the repositories you're using is unavailable right now. You can try the > suggestions in > https://forums.whonix.org/t/errors-updating-september-2018/6028/8, or > wait a day or so and try updating again. > > actually the method from the whonix forum still fails : (# commenting out the 2 onion repo references sudo apt-get dist-upgrade works but not , as below user@host:~$ sudo apt-get update Hit:1 http://deb.whonix.org stretch InRelease Hit:2 http://deb.qubes-os.org/r4.0/vm stretch InRelease Hit:3 http://security.debian.org stretch/updates InRelease Ign:4 http://ftp.us.debian.org/debian stretch InRelease Hit:5 http://ftp.us.debian.org/debian stretch Release Reading package lists... Done E: The method driver /usr/lib/apt/methods/tor+http could not be found. N: Is the package apt-transport-tor installed? E: Failed to fetch tor+http://deb.dds6qkxpwdeubwucdiaord2xgbbeyds25rbsgr73tbfpqpt4a6vjwsyd.onion/dists/stretch/InRelease E: Some index files failed to download. They have been ignored, or old ones used instead. -- 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/7c777292-fdd6-0c1c-91b0-0334cb4e1a67%40riseup.net. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Installation, no AMD-vi, interrupt mapping, etc.
I meant qemu-kvm not VirtualBox. I now see this table [1] that claims that Xen doesn't support IOMMU on rev.1 of our mobo have, but does on rev.2. I'll probably go with the alternative I have in mind then since, unless someone else has any ideas. If not, thanks for the suggestions everyone! Sandro [1] https://en.wikipedia.org/wiki/List_of_IOMMU-supporting_hardware#Motherboards_2 On Monday, 1 October 2018 15:04:34 UTC-4, naas...@gmail.com wrote: > Installation went fine except for a libxenlight config error of some kind. I > still can't enable IOMMU using either of the approaches described in that > Ubuntu thread, even though it successfully worked with raw Linux. > > What boot parameters did you add? I have the earlier rev.1 Sabertooth 990FX > mobo that you have. > > I'm not sure there's much advantage in sticking to Qubes without the hardware > acceleration over a Linux distro I'm more familiar with that has > virtualization working. I can just use accelerated VirtualBox instead of > accepting the PV overheads for the workflows I have in mind, but I'd > definitely like to use Qubes if I can get this working. > > Sandro > > On Monday, 1 October 2018 13:26:41 UTC-4, Sergio Matta wrote: > > Are you suggesting I just proceed with the installation regardless and try > > to set these parameters in the grub booting config after I get up and > > running? > > > > > > Sandro > > > > > Yes! And even if iommu does not works, you will be able to use Qubes 4 VM > > as PV. Networking will need to set up by hand and save those commands in > > files to start it automatically. > > You will have time to solve it or buy another motherboard. Mine is a US$150 > > used sabertooth 990fx rev.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/31499e0a-dfd2-4b49-b000-0fb0752a2571%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Installation, no AMD-vi, interrupt mapping, etc.
Installation went fine except for a libxenlight config error of some kind. I still can't enable IOMMU using either of the approaches described in that Ubuntu thread, even though it successfully worked with raw Linux. What boot parameters did you add? I have the earlier rev.1 Sabertooth 990FX mobo that you have. I'm not sure there's much advantage in sticking to Qubes without the hardware acceleration over a Linux distro I'm more familiar with that has virtualization working. I can just use accelerated VirtualBox instead of accepting the PV overheads for the workflows I have in mind, but I'd definitely like to use Qubes if I can get this working. Sandro On Monday, 1 October 2018 13:26:41 UTC-4, Sergio Matta wrote: > Are you suggesting I just proceed with the installation regardless and try to > set these parameters in the grub booting config after I get up and running? > > > > Sandro > > > Yes! And even if iommu does not works, you will be able to use Qubes 4 VM as > PV. Networking will need to set up by hand and save those commands in files > to start it automatically. > You will have time to solve it or buy another motherboard. Mine is a US$150 > used sabertooth 990fx rev.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/1c1cdb0c-16b1-4e48-b028-7e7459d1c117%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Whonix-Workstation VM and associate AppVMs not connecting in Qubes 3.2
On 9/29/18 4:12 PM, 'Setherson' via qubes-users wrote: > I am using Qubes 3.2. All TemplateVMs and dom0 have been updated sometime > within the past week. > > Since about the same time, my Workstation TemplateVM and every AppVM based on > it has been unable to connect to the internet. > > The Whonix Gateway TemplateVM works fine, as does the sys-whonix NetVM. > Furthermore, all the AppVMs based on the Fedora and Debian templates work > even when routed through sys-whonix. I also have all the TemplateVMs set to > update through sys-whonix, and every one of them is able to do this with the > sole exception of whonix-ws-14. So if I had to guess, I’d say the problem > lies with the Whonix Workstation TemplateVM itself. > > When I try updating whonix-ws-14, it “hits” everything until the 10th > repository. Once it gets there, the screen shows “[working]” and stays there. > > Has anyone else run into this problem? What steps can I take to begin > troubleshooting it? > > Thanks in advance! > yes, same here for many days now Whonix-ws-14 dies at Hit 8 ftp.us.debian.org/debian Stretch Release -- 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/c9f68fb4-3cd8-8996-9183-3fd6303bfe53%40riseup.net. For more options, visit https://groups.google.com/d/optout.
[qubes-users] /dev/mapper/qubes_dom0-root does not exist
I recently installed Qubes 4.0 on a laptop, installed updates in dom0 and my templates, restored a backup, and did a bunch of custom configuration. And then when I rebooted, Qubes wouldn't boot up due to a partitioning error. (It looks like it's the same problem described here [1]). During boot, I get a hundreds of lines that says: dracut-initqueue[343]: Warning: dracut-initqueue timeout - starting timeout scripts Followed by: dracut-initqueue[343]: Warning: Could not boot. dracut-initqueue[343]: Warning: /dev/mapper/qubes_dom0-root does not exist dracut-initqueue[343]: Warning: /dev/qubes_dom0/root does not exist Starting Dracut Emergency Shell... Then it drops me into an emergency shell. When I run lv_scan, I can see: Scanning devices dm-0 for LVM logical volumes qubes_dom0/root qubes_dom/swap inactive '/dev/qubes_dom0/pool00' [444.64 GiB] inherit inactive '/dev/qubes_dom0/root' [444.64 GiB] inherit ACTIVE '/dev/qubes_dom0/swap' [15.29 GiB] inherit inactive '/dev/qubes_dom0/vm-sys-net-private [2 GiB] inherit And it continues to list another inactive line for each private or root partition for each of my VMs. Only swap is active. I spent a little time trying to troubleshoot this, but ultimately decided that it wasn't worth the time, since I have a fresh backup. So I formatted my disk again, reinstalled Qubes, restored my backup, etc. After installing more updates and rebooting, I just ran into this exact same problem *again*. I think this could be a Qubes bug. Any idea on how I can fix this situation? The dracut emergency shell doesn't seem to come with many LVM tools. There's lvm, lvm_scan, thin_check, thun_dump, thin_repair, and thin_restore. I could boot to the Qubes USB and drop into a troubleshooting shell to have access to more tools. [1] https://groups.google.com/forum/#!searchin/qubes-users/dracut-initqueue$20could$20not$20boot|sort:date/qubes-users/PR3-ZbZXo_0/G8DA86zhCAAJ -- 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/ad0c4e025404fa1b9eb5eb3d39ac3f62%40micahflee.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] pgp smart card for luks keyfile
On Mon, 1 Oct 2018 07:07:58 + "'awokd' via qubes-users" wrote: > hron wrote on 9/28/18 10:47 AM: > > Hi, > > I am wondering if it is possible to use a LUKS key file during boot of > > qubes. In other distros I encrypted that key file with a pgp smart card an > > could decrypt it during boot by just plugging in the smart card and typing > > in my PIN code. > > Does anybody know if this could be done for qubes too? > > Some have had success with Yubikey, but I don't think it works exactly > like you're describing. > > thanks for this hint. I'll search for this approach. I just want to find a solution that avoids typing in the long passwords. ron -- 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/20181001194519.1085a02f%40vm-stargate1. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Installation, no AMD-vi, interrupt mapping, etc.
Are you suggesting I just proceed with the installation regardless and try to set these parameters in the grub booting config after I get up and running? > > Sandro > Yes! And even if iommu does not works, you will be able to use Qubes 4 VM as PV. Networking will need to set up by hand and save those commands in files to start it automatically. You will have time to solve it or buy another motherboard. Mine is a US$150 used sabertooth 990fx rev.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/ca8eaf8c-eeb8-4f7a-a388-2fab2ef9173e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Installation, no AMD-vi, interrupt mapping, etc.
Yes, I read that thread as well. The last post in that thread did not enable IOMMU on Linux, the second to last did and it's the same procedure I linked in my first post on superuser.com. However, adding these parameters while booting the Qubes installer doesn't seem to have an effect. Are you suggesting I just proceed with the installation regardless and try to set these parameters in the grub booting config after I get up and running? Sandro On Monday, 1 October 2018 12:56:43 UTC-4, Sergio Matta wrote: > > I updated the bios but still no luck, so I tried a manual procedure as > > described at [1]: I ran a recent live linux distro from a USB key and > > confirmed that interrupt remapping was disabled by default due to this BIOS > > bug. I then figured out the IOMMU and SMBus addresses using the described > > procedure and managed to get the live linux to boot with interrupt > > remapping and virtualization enabled as reported by dmesg. > > > > I tried the same ivrs_ioapic mapping procedure for the Qubes installer, but > > it still raises that dialog saying no interrupt remapping, AMD-Vi, etc. > > Running dmesg in the Qubes installer console reports only that IOMMUv2 is > > not available, which the live linux also reported, but no other errors. The > > dmesg output is a little different though, so perhaps I missed something. > > > > Any suggestions on what to do next? > > > > [1] https://superuser.com/questions/1052023/ioapic0-not-in-ivrs-table > > To fix the bug I inserted some parms on the xen command line (grub boot) and > after I did "sudo grub2-mkconfig -o /boot/grub2/grub.cfg" > But at that time there was a qubes-hcl-report bug not recognizing Remapping: > HVM: Active > I/O MMU: Active > HAP/SLAT Yes > Remapping: no > > xl dmesg works fine: > (XEN) AMD-Vi: IOMMU 0 Enabled. > (XEN) I/O virtualisation enabled > (XEN) – Dom0: mode: Relaxed > (XEN) Interrupt remapping enabled > > see: https://ubuntuforums.org/showthread.php?t=2254677 -- 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/381a3bb9-8aac-47a1-9c48-332a2fdc997b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Installation, no AMD-vi, interrupt mapping, etc.
> I updated the bios but still no luck, so I tried a manual procedure as > described at [1]: I ran a recent live linux distro from a USB key and > confirmed that interrupt remapping was disabled by default due to this BIOS > bug. I then figured out the IOMMU and SMBus addresses using the described > procedure and managed to get the live linux to boot with interrupt remapping > and virtualization enabled as reported by dmesg. > > I tried the same ivrs_ioapic mapping procedure for the Qubes installer, but > it still raises that dialog saying no interrupt remapping, AMD-Vi, etc. > Running dmesg in the Qubes installer console reports only that IOMMUv2 is not > available, which the live linux also reported, but no other errors. The dmesg > output is a little different though, so perhaps I missed something. > > Any suggestions on what to do next? > > [1] https://superuser.com/questions/1052023/ioapic0-not-in-ivrs-table To fix the bug I inserted some parms on the xen command line (grub boot) and after I did "sudo grub2-mkconfig -o /boot/grub2/grub.cfg" But at that time there was a qubes-hcl-report bug not recognizing Remapping: HVM: Active I/O MMU: Active HAP/SLAT Yes Remapping: no xl dmesg works fine: (XEN) AMD-Vi: IOMMU 0 Enabled. (XEN) I/O virtualisation enabled (XEN) – Dom0: mode: Relaxed (XEN) Interrupt remapping enabled see: https://ubuntuforums.org/showthread.php?t=2254677 -- 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/f5263830-51d2-4ac7-bbaa-0e2e597d1f46%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Installation, no AMD-vi, interrupt mapping, etc.
Yes, SVM and IOMMU are enabled and show as enabled when booting raw Linux when I pass in explicit ivrs_ioapic parameters at boot. I just tried again passing in iommu=debug and loglvl=all as described at [1], and xl dmesg just reports: (Xen) IVHD Error: Invalid IO-APIC 0 (Xen) AMD-Vi: Error initialization (Xen) I/O virtualization disabled No further information as to what's causing the issue seems to be available. I checked the xl dmesg also for a boot without explicitly passing in ivrs_ioapic and this output looks the same, so perhaps my explicit settings are ignored. If that's the case, then I already know my BIOS doesn't provide the proper mappings which is why I try to do so explicitly. That might explain why virtualization appears disabled. If anyone knows this for sure and knows how I can specify the IOMMU/SMBus mappings explicitly, I'd appreciate it! Sandro [1] https://groups.google.com/forum/#!searchin/qubes-users/ivrs_ioapic|sort:date/qubes-users/GESQugF4eIo/wyUZyDubAgAJ On Monday, 1 October 2018 12:07:02 UTC-4, Jonathan Seefelder wrote: > maybe a dump Question, but did you check if its enabled in the BIOS ? ;) > > > cheers > > > On 10/1/18 11:46 AM, I wrote: > > My first attempt at installing Qubes brought up a dialog indicating AMD-Vi > > and interrupt remapping wasn't available. I know my hardware supports the > > necessary virtualization extensions (AMD FX-8120 on a 990FX mobo), so > > further investigation suggested that the bios was probably buggy. > > > > I updated the bios but still no luck, so I tried a manual procedure as > > described at [1]: I ran a recent live linux distro from a USB key and > > confirmed that interrupt remapping was disabled by default due to this BIOS > > bug. I then figured out the IOMMU and SMBus addresses using the described > > procedure and managed to get the live linux to boot with interrupt > > remapping and virtualization enabled as reported by dmesg. > > > > I tried the same ivrs_ioapic mapping procedure for the Qubes installer, but > > it still raises that dialog saying no interrupt remapping, AMD-Vi, etc. > > Running dmesg in the Qubes installer console reports only that IOMMUv2 is > > not available, which the live linux also reported, but no other errors. The > > dmesg output is a little different though, so perhaps I missed something. > > > > Any suggestions on what to do next? > > > > [1] https://superuser.com/questions/1052023/ioapic0-not-in-ivrs-table > > > -- > Kind Regards > Jonathan Seefelder > CryptoGS IT-Security Solutions > Hofmark 43b > D-84564 Oberbergkirchen > Phone: +49 8637-7505 > Fax: +49 8637-7506 > Mail: i...@cryptogs.de > www.cryptogs.de -- 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/dcf244a6-0f0d-4e14-ad17-93d213e172bc%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Installation, no AMD-vi, interrupt mapping, etc.
maybe a dump Question, but did you check if its enabled in the BIOS ? ;) cheers On 10/1/18 11:46 AM, naask...@gmail.com wrote: > My first attempt at installing Qubes brought up a dialog indicating AMD-Vi > and interrupt remapping wasn't available. I know my hardware supports the > necessary virtualization extensions (AMD FX-8120 on a 990FX mobo), so further > investigation suggested that the bios was probably buggy. > > I updated the bios but still no luck, so I tried a manual procedure as > described at [1]: I ran a recent live linux distro from a USB key and > confirmed that interrupt remapping was disabled by default due to this BIOS > bug. I then figured out the IOMMU and SMBus addresses using the described > procedure and managed to get the live linux to boot with interrupt remapping > and virtualization enabled as reported by dmesg. > > I tried the same ivrs_ioapic mapping procedure for the Qubes installer, but > it still raises that dialog saying no interrupt remapping, AMD-Vi, etc. > Running dmesg in the Qubes installer console reports only that IOMMUv2 is not > available, which the live linux also reported, but no other errors. The dmesg > output is a little different though, so perhaps I missed something. > > Any suggestions on what to do next? > > [1] https://superuser.com/questions/1052023/ioapic0-not-in-ivrs-table > -- Kind Regards Jonathan Seefelder CryptoGS IT-Security Solutions Hofmark 43b D-84564 Oberbergkirchen Phone: +49 8637-7505 Fax: +49 8637-7506 Mail: i...@cryptogs.de www.cryptogs.de -- 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/dd1b14c1-11e1-0bb4-0805-c32aee120bc7%40cryptogs.de. For more options, visit https://groups.google.com/d/optout. signature.asc Description: OpenPGP digital signature
[qubes-users] Installation, no AMD-vi, interrupt mapping, etc.
My first attempt at installing Qubes brought up a dialog indicating AMD-Vi and interrupt remapping wasn't available. I know my hardware supports the necessary virtualization extensions (AMD FX-8120 on a 990FX mobo), so further investigation suggested that the bios was probably buggy. I updated the bios but still no luck, so I tried a manual procedure as described at [1]: I ran a recent live linux distro from a USB key and confirmed that interrupt remapping was disabled by default due to this BIOS bug. I then figured out the IOMMU and SMBus addresses using the described procedure and managed to get the live linux to boot with interrupt remapping and virtualization enabled as reported by dmesg. I tried the same ivrs_ioapic mapping procedure for the Qubes installer, but it still raises that dialog saying no interrupt remapping, AMD-Vi, etc. Running dmesg in the Qubes installer console reports only that IOMMUv2 is not available, which the live linux also reported, but no other errors. The dmesg output is a little different though, so perhaps I missed something. Any suggestions on what to do next? [1] https://superuser.com/questions/1052023/ioapic0-not-in-ivrs-table -- 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/5d55910b-d677-44dd-a11e-7004f46f965b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] The log entries in sys-net are filled with a bunch of messages
Hi, I created a new sys-net (sys-net2) as network VM to use a wireless USB adapter. The sys-net2 dmesg logs (guest-sys-net2.log) are filled with a bunch of messages (4878 lines) like the following: ---%<-- First lines ---%<-- [0.00] Linux version 4.14.57-2.pvops.qubes.x86_64 (user@build-fedora4) (gcc version 6.4.1 20170727 (Red Hat 6.4.1-1) (GCC)) #1 SMP Tue Aug 14 14:43:33 UTC 2018 [0.00] Command line: root=/dev/mapper/dmroot ro nomodeset console=hvc0 rd_NO_PLYMOUTH rd.plymouth.enable=0 plymouth.enable=0 nopat [0.00] x86/fpu: Supporting XSAVE feature 0x001: 'x87 floating point registers' [...] [ 11.129065] usb 2-1: new high-speed USB device number 2 using vhci_hcd [ 11.246132] usb 2-1: SetAddress Request (2) to port 0 [ 11.286211] usb 2-1: New USB device found, idVendor=13b1, idProduct=002f [ 11.286284] usb 2-1: New USB device strings: Mfr=1, Product=2, SerialNumber=3 [ 11.286369] usb 2-1: Product: Linksys AE1000 [ 11.286429] usb 2-1: Manufacturer: Linksys [ 12.303201] usb usb2-port1: Cannot enable. Maybe the USB cable is bad? [ 13.191197] usb usb2-port1: Cannot enable. Maybe the USB cable is bad? [ 14.079202] usb usb2-port1: Cannot enable. Maybe the USB cable is bad? [ 14.967200] usb usb2-port1: Cannot enable. Maybe the USB cable is bad? [ 14.967389] ieee80211 phy0: rt2x00usb_vendor_request: Error - Vendor Request 0x07 failed for offset 0x1000 with error -19 [ 14.967496] ieee80211 phy0: rt2800_probe_rt: Error - Invalid RT chipset 0x, rev detected [ 14.967594] ieee80211 phy0: rt2x00lib_probe_dev: Error - Failed to allocate device [ 14.967788] usbcore: registered new interface driver rt2800usb [ 14.968575] usb 2-1: USB disconnect, device number 2 [...] Additionally and deliberately focus is made on my wireless USB adapter. In contrast, my main sys-net with internal Ethernet port does not display anything. Any help and advice would be greatly appreciated. Best regards. GD Rub -- 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/5d4cdcca-39b6-4975-bb53-6de13cee33b6%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] ERROR: PCI device does not exist
Eric wrote on 10/1/18 10:29 AM: When running Centos, does lspci -vvv give the same unusual output for that problem device? Don't know what else to suggest; I have a Realtek dual port RTL8111/8168/8411 PCI Express card in one of my systems and it works fine under Qubes 4.0. No "lspci -vvv" outputs a complete description of both controllers as expected and 01:00.0's first line ends with "(rev 07)" as it should. Strange, sounds like Qubes is initializing just that one device wrong then. I had a similar issue with an old PCIe v1.1 wireless NIC. What version is your NIC? I never got mine working, but you might try adding "xen-pciback.hide=(01:00.0)" to your boot options in xen.cfg and seeing if it will let you assign it to sys-net then. -- 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/5c4fa694-8b11-6846-b3d9-ad83969b23f1%40danwin1210.me. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] ERROR: PCI device does not exist
When running Centos, does lspci -vvv give the same unusual output for that problem device? Don't know what else to suggest; I have a Realtek dual port RTL8111/8168/8411 PCI Express card in one of my systems and it works fine under Qubes 4.0. No "lspci -vvv" outputs a complete description of both controllers as expected and 01:00.0's first line ends with "(rev 07)" as it should. -- 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/c2895732-b70b-fae0-9fc4-b2e3abb5e9cd%40asar.biz. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Timezone issues after update to Template
brandonmaytha...@gmail.com wrote on 9/30/18 11:18 AM: Updated my Fedora Template from Fedora 25 to Fedora 28 as well as Whonix I am running Qubes 4.0 When ever I boot up I get the following from sys-whonix: ERROR: Systemd Clock Check Result: Unexpected results by timedatectl. timedatectl_output_pretty: Local time: Sun 2018-09-30 09:52:01 UTC Universal time: Sun 2018-09-30 09:52:01 UTC RTC time: n/a Time zone: Etc/UTC (UTC, +) NTP enabled: yes NTP synchronized: no RTC in local TZ: no DST active: n/a It is generally recommended to keep the default as per Whonix Design. [1] If you did not change timezone related settings, please report this Whonix bug. If you know what you are doing and changed this on purpose, feel free to disable this check. [2] [1] https://www.whonix.org/wiki/Dev/Design-Shared#timezone [2] Create a file /etc/whonix.d/50_whonixcheck_user and add: whonixcheck_skip_functions+=" check_systemd_clock " This is an old Whonix 13 cosmetic error that was resolved in 14. Did you upgrade per https://www.whonix.org/wiki/Qubes/Install ? Note the Whonix v3 onion seems to be down right now so you might want to wait a day or two until it comes back up. My Time is aso one hour behind I am based in the UK. As far as I understand it all VM's get their time from Dom0. When I right click the clock it is greyed out. I have tried in Dom0 the following command but I think I am getting it wrong: sudo timedatectl set-timezone Europe_London See https://github.com/Qubes-Community/Contents/blob/master/docs/system/clock-time.md if there are still issues after upgrading to 14. -- 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/93921d8f-1bbd-1252-58e5-00451dd2102b%40danwin1210.me. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Whonix-Workstation VM and associate AppVMs not connecting in Qubes 3.2
'Setherson' via qubes-users wrote on 9/30/18 2:12 AM: I am using Qubes 3.2. All TemplateVMs and dom0 have been updated sometime within the past week. Since about the same time, my Workstation TemplateVM and every AppVM based on it has been unable to connect to the internet. The Whonix Gateway TemplateVM works fine, as does the sys-whonix NetVM. Furthermore, all the AppVMs based on the Fedora and Debian templates work even when routed through sys-whonix. I also have all the TemplateVMs set to update through sys-whonix, and every one of them is able to do this with the sole exception of whonix-ws-14. So if I had to guess, I’d say the problem lies with the Whonix Workstation TemplateVM itself. When I try updating whonix-ws-14, it “hits” everything until the 10th repository. Once it gets there, the screen shows “[working]” and stays there. Has anyone else run into this problem? What steps can I take to begin troubleshooting it? Thanks in advance! You might have caught a bad update last week, and it sounds like one of the repositories you're using is unavailable right now. You can try the suggestions in https://forums.whonix.org/t/errors-updating-september-2018/6028/8, or wait a day or so and try updating 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/ffa818ac-b732-a43f-657f-b679dcb5ad93%40danwin1210.me. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: No Bootable Device after installing Qubes 4.0, Updating VMs and dom0, and rebooting
Zelda wrote on 9/29/18 12:10 PM: Does anyone have any insight/ideas as to why the OS is only booting with the backup drive present? During typical use, I don't usually keep the backup drive connected when using the operating system. I'm guessing your system's EFI partition is on the backup drive. To confirm, you could try repeating the install with only SSD attached, and using auto partitioning. -- 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/6ab0f4c6-6f0b-184b-f023-61c1e0d90b6c%40danwin1210.me. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] pgp smart card for luks keyfile
hron wrote on 9/28/18 10:47 AM: Hi, I am wondering if it is possible to use a LUKS key file during boot of qubes. In other distros I encrypted that key file with a pgp smart card an could decrypt it during boot by just plugging in the smart card and typing in my PIN code. Does anybody know if this could be done for qubes too? Some have had success with Yubikey, but I don't think it works exactly like you're describing. -- 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/60cd767c-a1f5-9475-499d-4b90e0a45ae8%40danwin1210.me. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Installing qr-exec on HVM
Will Dizon wrote on 9/28/18 10:04 PM: I am currently working on trying to make a TemplateVM out of a Linux from Scratch installation (or more accurately, BLFS). Progress has been immense, but I've run into a roadblock I'm not sure how to diagnose. For starters, I've gone through and successfully compiled: vmm-xen core-vchan-xen linux-utils core-agent-linux gui-common gui-agent-linux I've done the best I can to adapt Archlinux instructions, taking note of path modifications and installing everything, gruelingly by hand. Everything built as best as I can tell, but I cannot get `qvm-run` to execute a command. I'll try to give as much information as I can about the state of this systemd-based BLFS run. 1) lsmod shows xen_netfront, xen_netback, u2mfn loaded successfully on boot 2) The following systemd scripts are enabled (at boot) and run and exit cleanly: qubes-early-vm-config qubes-iptables qubes-misc-post qubes-mount-dirs qubes-sysinit 3) The following systemd scripts are enable and run in the background: qubes-qrexec-agent qubes-db Any other services have been either a) mistakenly missed and not installed OR b) ignored as they implement a functionality I believe is non critical at the time, e.g., qubes-sync-time If there are any other processes I've missed, please let me know, because it's probably just one of the make targets I've somehow overlooked. 4) /dev/xvdb mounted as /rw. /rw/home and /rw/usrlocal all work as expected. xen mounted at /proc/xen also listed in fstab and seemingly working (based on xenstore-read name returning system name). 5) Lastly, theres qubes-gui-agent, which when run automatically hides the HVM window and makes it non-interact-able. This is currently disabled in systemd, but is installed. And this is where I'm stuck. I'm trying on dom0: qvm-run lfs "shutdown now -h" and it returns "Running 'shutdown now -h' on lfs" but the VM never responds. What else might I provide to help troubleshoot this and to detect what seems like the last-mile in getting this working as a template? Does it work if qubes-gui-agent is running? You should still be able to get a console session with "sudo xl console VM". Never built my own template, though. -- 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/e2ba2c34-6262-bc77-521f-2bc0e951e800%40danwin1210.me. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] ERROR: PCI device does not exist
Eric wrote on 9/30/18 10:35 PM: awokd, is there anything else you want me to do before I wipe Qubes off this box? I put up a Centos7.4/Xen4.6 Dom0 (Kernel 4.9.127 which is way earlier than qubes 4.14.67) and everything seems to be running OK, which does seem a bit odd. Since this is a server application, and not a workstation, Qubes is a bit of an overkill. A centos7 in HVM will do here. Perhaps there may be 3 tickets here: the PCI drivers, need to fix half alive devices - multiple inconsistent copies of state? and that error message in the subject here is not very informative for the novice user. When running Centos, does lspci -vvv give the same unusual output for that problem device? Don't know what else to suggest; I have a Realtek dual port RTL8111/8168/8411 PCI Express card in one of my systems and it works fine under Qubes 4.0. -- 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/45a3f394-1e0b-b417-6e10-fbd43b6f023f%40danwin1210.me. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Screen recorder for Qubes..?
On Friday, 22 June 2018 22:18:38 UTC+10, ar...@ethereum.org wrote: > > > > The trickiest points (for me) were to compile and install v4l2loopback as a > > kernel module on the template-vm > > > yup. that's where I'm failing. https://gist.github.com/daktak/a3a1025cd9e4ce6e31b5209044877570 Got Qubes-OS 4.0 (Fedora 25) ffmpeg installed in dom0. Manually installed the rpms from archives.fedoraproject.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/fef53dc0-9ca3-4006-a471-fb2161c3a53a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
