[qubes-users] HCL - Dell Precision M4700
*Installer r4.0 hung on sys-net step due to a Broadcom BCM* wifi card issue. Installer worked fine and boot as well after tossing the card aside. Everything else worked great out of the box: - NVIDIA Quadro K2000M is good with HDMI out fine. Displayport output went up to 2560x1440 (~2 or 2.5K?) without installing NVIDIA drivers (3840x2160 supposedly https://www.notebookcheck.net/NVIDIA-Quadro-K2100M.98900.0.html), I didn't test further. - Camera/mic are good. - SD cards great. - Express card slot has worked great with smart cards. - 3 USB2 ports, 1 USB3 work well. - TPM/IME were disabled by previous owner, so can't comment. - 1 large and 2 half mini slots, so you can get crazy wifi. - Spring-loaded hard drive caddy. This computer is all over eBay in the $200 range in 2019, I have been very pleased with Qubes on it. Non-Qubes UEFI issues: The drive caddy is spring loaded under the battery, so it's been nice to be able to immediately switch between Qubes/Windows/Ubuntu/OpenBSD with multiple SSDs. This is a nice alternative to dual booting and allows the primary use of Qubes without abandoning Ubuntu for vmware/virtualbox. However, Windows 10 had been installed with UEFI and completely lost its mind after a couple months of this, completely unrecoverable. After an upgrade to Dell Bios A19 and reinstalling Windows 10 in non-UEFI Legacy mode, there have been no issues for about 4 months now moving back/forth. -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/2ef0c478-eee2-423e-b53f-8c3caedf7351%40googlegroups.com. Qubes-HCL-Dell_Inc_-Precision_M4700-20190723-164828.yml Description: Binary data
[qubes-users] Re: Boot Problem
For the Precision, I fortunately had an Intel NIC (Precision M4700 https://groups.google.com/forum/#!topic/qubes-users/-5Vbi5vhbms) but experienced the Broadcom pains too. Here's some ideas: You can get an RTL8187 for about $5 on eBay, works great. I would remove the Broadcom wifi card and swap in a Realtek wifi card, disable the integrated NIC ethernet card in Bios, and install Qubes in legacy mode - not UEFI (in case you need Grub for recovery options later). In Bios, this should be in System configuration, Integrated NIC and uncheck those boxes (check the whole menu for other locations too). If you need ethernet, then after install you can look online on how to install the specific Broadcom drivers into sys-net VM's template (if you can find a safe source). Then reboot into bios and re-enable the ethernet NIC, and after boot in the Qubes sys-net VM settings move the PCI bridge for the ethernet controller into the "selected" column and try restarting the VM and using the ethernet card. If it works reboot to see if everything is still successful. If it won't boot, then just disable ethernet again in Bios and try maybe switching the sys-net VM template to Debian and installing the drivers there in case you get the support. On Wednesday, April 19, 2017 at 4:35:06 PM UTC-4, craig@gmail.com wrote: > > I am having at boot problem with my Qubes OS 3.2. When I boot up I enter > the disk password and the boot process continues until it gets to the > line... > > A start job is running for Qubes NetVM startup (32s / no limit) > > And it hangs. The HDD turns off and the computer will stay here never > booting or shutting down until you force it to turn off. Anyone have an > idea of what is going on and how to fix it? > > Thank you, > > Craig > > -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/cbc291a6-257b-4551-9092-d240f3f238b2%40googlegroups.com.
Re: [qubes-users] Problem with NextCloud-Client App-VM (unable to login on 2nd boot)
libgnome-keyring, not just gnome-keyring. Various forums suggest an issue (is there though?) in Fedora where PAM and the gnome keyring do not play nice together and an additional theory that the Fedora keyring is just not making Nextcloud entries due to some bug. My current solution: 1. Boot your template Fedora VM and then install the gnome keyring: dnf install -y libgnome-keyring sudo shutdown -h now 2. Restart your qubes AppVM and login to your Nextcloud client with your password, restart 3. Nextcloud starts and is good to go without password If 3 fails (did for me), then you may want to blast your keyrings (warning: you're deleting your keyrings, so other saved password...), so in the AppVM just run "sudo dnf -y remove gnome-keyring && sudo dnf -y install gnome-keyring" reboot and enter a null password on boot, then repeat step 2. I'm still anxious about this because my keyring uses as...NULL password! My understanding is that this is an acceptable risk and has the same logic as the null root password. Someone who is local on the AppVM is going to be able to escalate to root anyway, and therefore will own the keyring so you're pwned anyway so just make the keyring null so it's less annoying. Is this horribly wrong? Example of suggested solutions: https://github.com/nextcloud/desktop/issues/427 On Friday, August 16, 2019 at 4:19:22 PM UTC-4, 799 wrote: > > Hello, > > On Fri, 16 Aug 2019 at 11:22, Stefan Leibfarth > wrote: > >> [...] >> I'd guess it's not directly Qubes related, maybe this problem: >> >> https://help.nextcloud.com/t/nextcloud-client-asks-for-password-every-time-it-starts/28591/3 >> > > I tried nearly everything from this forum post, I also tried to use other > templates fedora-29, fedora-30, still the same problem. > I also tried to install gnome-keyring but it doesn't make a difference. > > Anyelse has a Nextcloud CLIENT (not server) running in Qubes and give me a > hint, why I need to re-enter my credentials after boot and even after the > nextcloud client is not pocking up the sync again. > > [799] > > -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/d0655f4f-e862-495d-8339-890294d6ccf2%40googlegroups.com.
Re: [qubes-users] Problem with NextCloud-Client App-VM (unable to login on 2nd boot)
*long day, missed the part where I blasted my old keyrings if step 3 fails: sudo rm -rf /home/user/.local/share/keyrings I had no saved passwords/keys but it was still an issue somehow, so this forced the new first-time keyring password prompt on AppVM reboot that I left blank. So apparently libgnome-keyring is a dependency. No idea what the Nextcloud forum are referenced with libgnome-keyring0. On Friday, August 16, 2019 at 4:58:08 PM UTC-4, sourcexorapprentice wrote: > > libgnome-keyring, not just gnome-keyring. > > Various forums suggest an issue (is there though?) in Fedora where PAM and > the gnome keyring do not play nice together and an additional theory that > the Fedora keyring is just not making Nextcloud entries due to some bug. > > My current solution: > 1. Boot your template Fedora VM and then install the gnome keyring: > dnf install -y libgnome-keyring > sudo shutdown -h now > 2. Restart your qubes AppVM and login to your Nextcloud client with your > password, restart > 3. Nextcloud starts and is good to go without password > > If 3 fails (did for me), then you may want to blast your keyrings > (warning: you're deleting your keyrings, so other saved password...), so in > the AppVM just run "sudo dnf -y remove gnome-keyring && sudo dnf -y install > gnome-keyring" reboot and enter a null password on boot, then repeat step 2. > > I'm still anxious about this because my keyring uses as...NULL password! > My understanding is that this is an acceptable risk and has the same logic > as the null root password. Someone who is local on the AppVM is going to be > able to escalate to root anyway, and therefore will own the keyring so > you're pwned anyway so just make the keyring null so it's less annoying. Is > this horribly wrong? > > Example of suggested solutions: > https://github.com/nextcloud/desktop/issues/427 > > On Friday, August 16, 2019 at 4:19:22 PM UTC-4, 799 wrote: >> >> Hello, >> >> On Fri, 16 Aug 2019 at 11:22, Stefan Leibfarth >> wrote: >> >>> [...] >>> I'd guess it's not directly Qubes related, maybe this problem: >>> >>> https://help.nextcloud.com/t/nextcloud-client-asks-for-password-every-time-it-starts/28591/3 >>> >> >> I tried nearly everything from this forum post, I also tried to use other >> templates fedora-29, fedora-30, still the same problem. >> I also tried to install gnome-keyring but it doesn't make a difference. >> >> Anyelse has a Nextcloud CLIENT (not server) running in Qubes and give me >> a hint, why I need to re-enter my credentials after boot and even after the >> nextcloud client is not pocking up the sync again. >> >> [799] >> >> -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/80c109d6-3894-4a69-85b3-265e517db57e%40googlegroups.com.
Re: [qubes-users] Which qube is most secure for internet use?
China changes everything, as 799 hinted at thinking about what threads you're concerned about. For "they certainly won't be after me" as a foreigner in China I just used my home internet with a VPN and skipped Whonix. If I was going to get in trouble/deported, it wouldn't have anything to do with my computer's privacy/security. It would be because I posted something critical on Facebook, or some operational security mistake like a critical blog/forum post using the same pseudonym I registered someplace else with my real name and email. In China, using Whonix out of the box and accessing Tor is a bad idea and is dangerous for your personal security. Entry node IPs are public and they will know. Both Tor and VPNs are quasi-illegal, but there's a difference. Tor screams out that you're a dissident or criminal. VPNs instead suggest you're streaming Netflix or looking at pictures of cats on Facebook. A VPN might land a local Tibetan/muslim in prison, but nothing happens to foreigners using a VPN (which is everyone, and they're not going to deport everyone). For "most secure" in China, I would put a VPN VM behind sys-net, and then use Qubes settings to attach whonix-gw behind the VPN and use whonix-ws for browsing (https://www.qubes-os.org/doc/vpn/). For China, NordVPN supposedly works best, but I've never had issues there using ExpressVPN. For the paranoid, consider for a moment that China blocks other VPNs but not these two... So, you just connect the whonix-gw through the VPN and now you have reasonable Qubes security and reasonable privacy from the whonix-ws. Whonix uses Tor and prevents identification of your true IP/Mac/host DNS/hardware is the purpose of Whonix using a gateway (GW) and a workstation (WS). Using Whonix on Qubes alleviates some of the pitfalls of your hardware concerns, identified here: https://www.whonix.org/wiki/Host_Security For public Wi-Fi, your card's MAC accessing a VPN would still be seen. Scrambling your Wi-Fi card's MAC address using macchanger is easy to screw up and some cards don't play nice. Pretty useless anyway, a cafe in China is going to have at least two cameras on you inside and the streets are covered in cities so a directional antenna only brings attention to yourself. Just be mindful of what's recording your screen. -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/7d86b6f1-1189-43d8-988e-71d3da29df69%40googlegroups.com.
[qubes-users] Re: How do I create a Qubes USB Installer within Qubes OS (if it's possible)?
1. Download and verify the latest Qubes iso in your AppVM: https://github.com/tasket/Qubes-vpn-support 2. Plug in your USB flash drive, mount it to your AppVM https://www.qubes-os.org/doc/usb-devices/ 3. Flash the ISO to the USB using standard Linux command line instruction This should be a dd command no different than Mint, if not search for instructions for flashing an image to USB in Fedora or Debian, depending on the AppVM that you're using, defaults are Fedora On Friday, August 16, 2019 at 10:51:11 AM UTC-4, O K wrote: > > Mint lets you do it, but not sure about 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/5d546ed0-b529-41b2-ae1e-ca6343771ee0%40googlegroups.com.
[qubes-users] Re: What is the SHA-256 checksum of the Qubes-R4.0.1-x86_64 ISO?
The process is to verify the Qubes ISO signature is correct, and not to trust a SHA256 checksum posted on the same website hosting the file. The hash only confirms the integrity and not the validity of the file (which may be infected). It's a security theater exercise we're used to doing elsewhere in order to provide us with the warm fuzzy feeling of a false sense of security. Instructions here on how to verify the latest Qubes ISO is legitimate: https://www.qubes-os.org/security/verifying-signatures/ -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/7ba9c19f-a5be-40f8-96d1-15e0d067449c%40googlegroups.com.
Re: [qubes-users] Which qube is most secure for internet use?
A correction and addendum brought to my attention, thanks! 1. MAC changing -- Do it anyway, you're more likely to be tracked down that way than cameras, excellent Qubes documentation on that: https://www.qubes-os.org/doc/anonymizing-your-mac-address/ You can confirm it works by randomizing it and connecting to your wifi router first before trusting it works in public. Macchanger is excellent software, I just mean my neophyte self messing up or using incompatible hardware. 2. VPN setup -- It's easy to make mistakes and let it leak what you're doing, but there's a Github project on this you may want to checkout: https://github.com/tasket/Qubes-vpn-support -- 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/ed9c2153-44fa-4cd2-ab16-c529f6f66ad5%40googlegroups.com.
