Re: [qubes-users] Installing/updating apps in a TemplateVM
outdoorac...@gmail.com: I've just installed Qubes OS 4.0 on my old laptop to get the hang of it before I (hopefully) make my leap over from Windows! I wanted to install some new software in the personal and work domains so I went to the "Qubes Menu -> Template: fedora-26 -> fedora-26: Software" and clicked the Install button for an app however it only ever displayed pending. I opened up the Qubes Manager and noticed that no NetVM was assigned to any of the templates. I opened the settings and assigned it sys-firewall which then allowed me to install programs. On the https://www.qubes-os.org/doc/software-update-vm/ page under "Notes on trusting your TemplateVM(s)" heading it says: "Only install packages from trusted sources – e.g. from the pre-configured Fedora repositories. All those packages are signed by Fedora, and we expect that at least the package’s installation scripts are not malicious. This is enforced by default (at the firewall VM level), by not allowing any networking connectivity in the default template VM, except for access to the Fedora repos." This no longer seems the case in Qubes OS 4.0 - no NetVM is attached to the TemplateVMs and no default firewall rules. Okay, onto the questions: 1) Have these defaults been missed out from the Qubes OS 4.0 install? 2) Or is the documentation out of date and it's now recommended to do something else? 3) How should I go about installing/updating apps in the TemplateVMs? 3a) permanently attach sys-firewall and create firewall rules to only allow trusted repos as the docs currently suggest 3b) or only attach sys-firewall when updating/installing and disconnect afterwards? The docs are right, but what they mean is that you can't use the "Software" application to install apps in templates. You should leave NetVM on (none) on the templates and instead use dnf on Fedora or apt on Debian. -- 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/a2ebe44a-2c41-3536-e2ca-0e57d09a22d5%40danwin1210.me. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Cannot retrieve repository metadata (repomd.xml) for repository: qubes-dom0-current error
alexw8...@gmail.com: Hey, I am running qubes 4.0 and When I try to update Dom0 in the Terminal with "sudo qubes-dom0-update" I get this error: Using sys-whonix as UpdateVM to download updates for Dom0; this may take some time... Cannot retrieve repository metadata (repomd.xml) for repository: qubes-dom0-current. Please verify its path and try again. I have Whonix-gw-14 and whonix-ws-14 installed and fully updated. I also have debian-9 updates working with no errors. I have Fedora-28 installed also but when I try and update that I get this Error: Failed to synchronize cashe for repo 'qubes-vm-r4.0-current' I am relatively new to qubes so I am learning as I go. I have did some research on these issues and I havnt found a solution to my exact issue yet. I am hoping I dont have to reinstall Qubes unless I have too. I was trying to update my onion addresses from V2 to V3 when I came across this Issue using this guide: https://www.whonix.org/wiki/Onionizing_Repositories. It sounded like they were going to migrate the Qubes update repo to a new server. Just wait and try again in a few hours or tomorrow. -- 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/7a6f05f0-3339-6116-8d7a-9697f99bd275%40danwin1210.me. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] ERROR: PCI device does not exist
Eric: The only PCI error I can find in the journal while booting dom0 is: "dom0 libvirtd[2788]: 2018-09-20 19:01:02.052+: 2829: error : virPCIGetHeaderType:3129 : internal error: Unknown PCI header type '127'" "qvm-pci list" does not show that NIC (understandable) however it is in the Qubes manager device selection list as: "dom0:01_00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev ff)" The NIC that is OK (device dom0:03_00.0) is the same except it has "(rev 07)" at the end. Your troubleshooting steps are sound. Test that "rev ff" device under a different OS to rule out a hardware problem, and in dom0 do a "sudo lspci -vvv" and compare the two Realtek entries against each other. Check to see if there's a firmware update for your system, sometime those include NIC firmware. -- 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/c17723cd-4a4f-d0f1-6d02-0d850aa01a0a%40danwin1210.me. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Cannot retrieve repository metadata (repomd.xml) for repository: qubes-dom0-current error
Hey, I am running qubes 4.0 and When I try to update Dom0 in the Terminal with "sudo qubes-dom0-update" I get this error: Using sys-whonix as UpdateVM to download updates for Dom0; this may take some time... Cannot retrieve repository metadata (repomd.xml) for repository: qubes-dom0-current. Please verify its path and try again. I have Whonix-gw-14 and whonix-ws-14 installed and fully updated. I also have debian-9 updates working with no errors. I have Fedora-28 installed also but when I try and update that I get this Error: Failed to synchronize cashe for repo 'qubes-vm-r4.0-current' I am relatively new to qubes so I am learning as I go. I have did some research on these issues and I havnt found a solution to my exact issue yet. I am hoping I dont have to reinstall Qubes unless I have too. I was trying to update my onion addresses from V2 to V3 when I came across this Issue using this guide: https://www.whonix.org/wiki/Onionizing_Repositories. -- 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/c267239b-82aa-426d-9ffa-0e9aa916301a%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Installing/updating apps in a TemplateVM
I've just installed Qubes OS 4.0 on my old laptop to get the hang of it before I (hopefully) make my leap over from Windows! I wanted to install some new software in the personal and work domains so I went to the "Qubes Menu -> Template: fedora-26 -> fedora-26: Software" and clicked the Install button for an app however it only ever displayed pending. I opened up the Qubes Manager and noticed that no NetVM was assigned to any of the templates. I opened the settings and assigned it sys-firewall which then allowed me to install programs. On the https://www.qubes-os.org/doc/software-update-vm/ page under "Notes on trusting your TemplateVM(s)" heading it says: "Only install packages from trusted sources – e.g. from the pre-configured Fedora repositories. All those packages are signed by Fedora, and we expect that at least the package’s installation scripts are not malicious. This is enforced by default (at the firewall VM level), by not allowing any networking connectivity in the default template VM, except for access to the Fedora repos." This no longer seems the case in Qubes OS 4.0 - no NetVM is attached to the TemplateVMs and no default firewall rules. Okay, onto the questions: 1) Have these defaults been missed out from the Qubes OS 4.0 install? 2) Or is the documentation out of date and it's now recommended to do something else? 3) How should I go about installing/updating apps in the TemplateVMs? 3a) permanently attach sys-firewall and create firewall rules to only allow trusted repos as the docs currently suggest 3b) or only attach sys-firewall when updating/installing and disconnect afterwards? 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/8b7f0ab5-48e5-4c3c-8f12-2e45ca57732b%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] ERROR: PCI device does not exist
Hello, new user here. Impressed with the design and philosophy of Qubes! Everything seems to work as described excepting one problem. When I first installed R4.0 from the current iso on a mini PC (Celeron 3215U) it came up with the error message above in a dialog and no VMs were running. Worked out it was sys-net having a broken device attached, being the first of 3 network controllers found (2 * Realtek NICs + Qualcomm WiFi controller). Everything runs if I move that device out of the selected list for sys-net in Qubes manager. Brought dom0 and all templates up to date and still have the problem. If I assign that device to a standalone HVM I get the same error upon attempting a start, works fine with the other NIC. The only PCI error I can find in the journal while booting dom0 is: "dom0 libvirtd[2788]: 2018-09-20 19:01:02.052+: 2829: error : virPCIGetHeaderType:3129 : internal error: Unknown PCI header type '127'" "qvm-pci list" does not show that NIC (understandable) however it is in the Qubes manager device selection list as: "dom0:01_00.0 Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev ff)" The NIC that is OK (device dom0:03_00.0) is the same except it has "(rev 07)" at the end. I do need this ethernet port operational - any ideas? Many thanks, Eric -- 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/285fa61c-9623-08ff-f00e-383df3b50ecd%40asar.biz. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Purchase advice, Qubes laptop: ASUS ROG Strix GL503GE ?
This laptop advice question has been asked around 5 times in the past two weeks and I have answered all of them :D On 09/21/2018 02:43 AM, KajMagnus wrote: > What do you think about installing Qubes OS on this?: > > ASUS ROG Strix GL503GE Gaming laptops are baaad news - in a few years the battery life will be 1hr and lugging around a heavy laptop will be feeling worse and worse and you will be consuming more and more ibuprofen for your back pain! > It has this I5-8300H processor, 8th gen core i5, apparently with VT-x and > VT-d yes: It depends on more than just the cpu - in terms of this laptop IOMMU probably won't work on it unless you are buying workstation hardware they almost always fuck up the implementation of it. > https://ark.intel.com/products/134876/Intel-Core-i5-8300H-Processor-8M-Cache-up-to-4_00-GHz > > I read that a IGP is recommended: That information is outdated, anything but the junk nvidia is fine - intel and AMD make linux drivers that are quasi open source in that they require a binary blob but they work with no BS. > "Intel IGP (strongly preferred)" (here: > https://www.qubes-os.org/doc/system-requirements/ ) Do all laptops typically > include an IGP? This laptop has an IGP, you think, Most do yes it is the cheapest option as it is integrated in the CPU > although it has an NVIDIA Geforce GTX 1050 Ti card? Nvidia hates: * Linux (unless you buy a quadro) * Open source anything - not only do they fail to provide open source drivers as their competitors do they intentionally ruin the efforts of the nouveau project. * Virtualization (unless you buy a quadro) in that they intentionally add bugs to make it harder to attach graphics card to a VM. 1050 is slow and not really worth it - it would be better to get an eGPU setup if you want a GPU instead of lugging around a heavy gamer laptop. > (I do software development. Will use the laptop to compile code, takes 10 - > 100 seconds, and run stress tests, and open 100 browser tabs. And ... during > development, > I don't feel good about pulling down 1 000 Node.js libs and > typing `npm start` unless in a Qubes virtual machine :- )) I suggest a W520 which you install 32gb ram and the best compatible ivy bridge quad core cpu - then install coreboot with me cleaner (to nerf the me). Buy the one with the IGD and no dGPU so it is more battery efficient and that you can later buy an ExpressCard eGPU adapter and potentially not have to use an external monitor to play video games on it. (with the dGPU model you cant re-direct the output through the iGPU and thus to the laptops internal screen - very cool stuff) It isn't owner controlled like the G505S that I usually suggest but it will be fine and has more features (dock, more ports, expresscard) ram (g505s only 16gb) etc. It is much more free than newer laptops and there aren't any binary blobs besides the ME blob. Note disabling ME is impossible and anyone who says otherwise is lying. New x86 hardware is only licensed not bought, if you want to truly own your hardware and have computing freedom with no ME/PSP and libre firmware you must get non-x86 stuff or older x86 hardware. > (I also asked in https://www.reddit.com/r/Qubes a while ago) What you have to understand is that most of the qubes user community are know it all little kids who suck at computers and refuse help - if 90% of them weren't using qubes they would be using linux mint and they couldn't really care less about actual security only the perception of security which is why so many of them endorse stupid DRM shit like MS's "secure" boot (no linux distro is complete without a MS product lol!) TPM's, ME, a scammy company that starts with the letter p, etc. Users whom you want to listen to are me, awokd, ivan ivanov and a few others. I am always available to email in case no one else has an answer for your obscure expert level linux question. -- 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/4bb5d3ab-b1ff-6044-fdd8-8e9fd557b2a1%40gmx.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Too small num_mfn in MSG_MFNDUMP
On Tuesday, September 25, 2018 at 2:12:29 PM UTC-5, tyler.e@raytheon.com wrote: > I am getting an error when the gui-daemon in dom0 receives a MSG_MFNDUMP > message from the domU gui-agent. Somehow the number of frame numbers > reported from the domU doesn't match up with the size of the window. I've > posted the log from the dom0 guid at the end of this message. > > Initially, it looks like a window for gsd-xsettings is created just fine and > the dom0 receives the messages, no problem. For testing, I then started an > instance of xclock in domU and it runs into trouble when doing the mfndump. > Looking at the log messages, I can't tell if the size of the window is > supposed to be 164x164 or 1280x1024. Xclock is usually has a small > application window, but using either size, something erroneous is going on. > There is some issue when it comes to computing num_mfn. num_mfn is computed > with the following code snippet: > > pixels = pixmap->devPrivate.ptr; > > > pixels_end = > > > pixels + > > > pixmap->drawable.width * pixmap->drawable.height * > > > pixmap->drawable.bitsPerPixel / 8; > > > off = ((long) pixels) & (4096-1); > > > pixels -= off; > > > num_mfn = ((long) pixels_end - (long) pixels + 4095) >> 12; > > > shmcmd.width = pixmap->drawable.width; > > > shmcmd.height = pixmap->drawable.height; > > > num_mfn is computed by using the starting address, adding the amount of data > the window occupies to find the ending address, and subtracting the two. > There are a few extra things to align the address to 4K pages. In the error > log below, the width and height that are part of the MSG_MFNDUMP are > 1280x1024. Yet, somehow num_mfn is only 0x141. According to the above code > and assuming 3 bytes per pixel, it should be something close to > (1280x1024x3)/4096 = 0x3c0. Even if the size was 164x164, num_mfn should be > close to (164x164x3)/4096 = 0x19. Somehow the dom0 receives a width and > height of 1280x1024 yet it also receives from the domU that num_mfn = 0x141. > > Looking at the code for computing num_mfn, the only thing I can think of that > might affect num_mfn being too small is truncation error from doing pointer > arithmetic using "long." There could be 64 bit addresses but only 32 bit > longs and some higher order bits are being lost when computing num_mfn. > Maybe something like "ptrdiff_t" or "uint64_t" could have been used. That > being said, it shouldn't matter because everything was compiled for 64 bit > machines, right? > > Any help figuring out what's going on here would be greatly appreciated! > > dom0 guid log: > > Created 0x23(0x61) parent 0x0(0x19b) ovr=1 x/y -1/-1 w/h 1/1 > set title for window 0x23 > set title for window 0x23 > Created 0x24(0x81) parent 0x0(0x19b) ovr=0 x/y 10/10 w/h 10/10 > set WM_NORMAL_HINTS for window 0x24 to min=0/0, max=0/0, base=0/0, > inc=0/0 (flags 0x0) > set title for window 0x24 > set class hint for window 0x24 to (linux_domu:Gsd-xsettings, > linux_domu:gsd-xsettings) > XDestroyWindow 0x24 > cannot lookup 0x24 in wid2windowdata > cannot lookup 0x24 in wid2windowdata > cannot lookup 0x24 in wid2windowdata > cannot lookup 0x24 in wid2windowdata > cannot lookup 0x24 in wid2windowdata > cannot lookup 0x24 in wid2windowdata > cannot lookup 0x24 in wid2windowdata > cannot
Re: [qubes-users] Default print screen location: Dom0 ...?
Den onsdag 13 april 2016 kl. 15:39:23 UTC+2 skrev Axon: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > Desobediente: > > I'm gonna use this same topic. > > > > What if i want to use recordmydesktop or anything similar? > > > > I am interested strictly in video recording / screen capture, but > > also, how would audio work? > > > > I've never tried to do this before, but if I were going to, I'd try > giving an HVM fullscreen permissions, then running it in "debug mode" > (i.e., non-seamless mode). Then I'd attach my recording devices to > that HVM and try running the recording software inside of it. > > > I have tried (before I've RTFM) to run recordmydesktop "inside" an > > AppVM, that obviously crapped the whole screeen. > > > > What do you mean by "crapped the whole screen"? Events which occur in > a single AppVM normally should not be able to affect the entire screen > (as seen from dom0). In fact, this is one of the main security > features of Qubes. See, for example: > > https://www.qubes-os.org/doc/full-screen-mode/#tocAnchor-1-1-2 > > > Tags: recordmydesktop, screen record, screen capture, how do i, how > > do one, how do you, video record > > > > -BEGIN PGP SIGNATURE- > > iQIcBAEBCgAGBQJXDkv8AAoJEJh4Btx1RPV8uC0QAI4J9YtrRhfHtNh+xqDrNzp2 > thN20QLjmlPRcv/gbJqY0ItKK+/CKe+Ndo2zH2in14sChFc7pWy890vJjDW32vkx > lSYPHbCRiw0ypojP8Q0i0sVmd4IVyB4gMCkyJvjar0ZemCEqR5wcYvApEDpkKNbK > tvUTA71NB6BIdvG3wIei7MY6/oSJuxZEkL0az2njDqaJw5g8gxJyb9dI9PZQrIy3 > v2qykF3vI++4D5pLam803j294ulYonh7q8Y1+uAggRDWzNrFzS9E8S6K4Vp235WD > n523Bb7Jg1VFrfBpsREDQl/LwTE/jPzHCj8QatvHZgrDHKVXonMHOosdY/DxxWGt > MK/d3eEcrbmWXbYbTo/188iAgC+MOx8bELWy+poEpC3XLdqDapQGKal/X4mZ1Jn6 > DfQ/5yI80ORREYplxOUI2TAHwZHR5k72mERQYRv5nYEQxbO6pHa6ay4Pg45YgB1H > uxCSIn4SSUZ1Mwrg1zwuPSysLBfhMGZeKFrPWDPDDI0ixBEpxUou+vvgqNdUnAKE > SqlBVxbh/UP4Po5p8FgXZr5gOx1vYPcpjDmwRpsa6sCgUgady6V7Xa9tN51e3ahr > cfrLdGqRLn1+WA2Ajg/icjFJj/g8okHCMFL5+d6rS4c4JRpRBqG7D43YGltVikI+ > mfcGcX019DZI6LGkzdoK > =Htjq > -END PGP SIGNATURE- Sorry to bump this old thread but as a new qubes user I did try unknowingly to run recordmydesktop in an APPVM. The result was that the whole screen became white both on external and laptop display. I could see preview screens when alt-tabbing and could exit and reenter from the lock screen that looked normal, but always ended up in the white screen. I needed to perform a hard reboot to recover. I found below tool for running recordmydesktop in dom0 instead https://git.zx2c4.com/laurent-tools/tree/tools/qvm-screenrecord.sh I do have problems with many corrupt/lost frames though not sure if that is related to qubes or not. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/95edc347-cf78-436d-9fc8-9a93adb9302f%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
