[qubes-users] HCL - Lenovo ThinkPad X230
This was marketed as an x330. Works fine with R4.1.1 after I added kernel-latest to get the 5.18 kernel. Prior to that with anything earlier than 5.18 the WiFi was not recognized. I had to use Fedora templates for sys-net as well. Mods include: i7-3612QE quad-core CPU MediaTek Wifi 6 - MT7921K ExpressCard USB 3.0 2K 16:10 Display Classic X220 7 row keyboard coreboot with ME disabled Tested and working Wifi Ethernet Audio Keyboard/Touchpad/Trackpoint USB Not tested Suspend Bluetooth -- 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/de8ff832b1af9c7a8a52a8c63173ee16%40riseup.net. --- layout: 'hcl' type: 'notebook' hvm: 'yes' iommu: 'yes' slat: 'yes' tpm: 'yes' remap: 'yes' brand: | LENOVO model: | 2306A71 bios: | G2ETA0WW (2.60 ) cpu: | Intel(R) Core(TM) i7-3612QE CPU @ 2.10GHz cpu-short: | i7-3612QE chipset: | Intel Corporation 3rd Gen Core processor DRAM Controller [8086:0154] (rev 09) chipset-short: | FIXME gpu: | Intel Corporation 3rd Gen Core processor Graphics Controller [8086:0166] (rev 09) (prog-if 00 [VGA controller]) gpu-short: | FIXME network: | Intel Corporation 82579LM Gigabit Network Connection (Lewisville) (rev 04) MEDIATEK Corp. Device 0608 memory: | 16079 scsi: | Samsung SSD 870 Rev: 1B6Q usb: | 4 versions: - works: 'yes' qubes: | R4.1 xen: | 4.14.5 kernel: | 5.18.9-1 remark: | Requires Fedora for sys-net and kernel-latest (at least 5.18) to get MediaTek MT7921K WiFi card to be recognized credit: | gaijin link: | FIXLINK ---
[qubes-users] HCL - SuperMicro X11SRA
Legacy boot in BIOS allows installation of R4.0.4 Some overall system stability issues using 5.x Linux kernel (frequent crashes). Performance is stable with a 4.x kernel. sys-net (Fedora 33) will not connect to wired LAN if the kernel is set to 5.x. A 4.x kernel is stable. -- 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/3b8998c58aeb42515c71b1a07f65d9a4%40riseup.net. --- layout: 'hcl' type: 'main server chassis' hvm: 'yes' iommu: 'yes' slat: 'yes' tpm: 'unknown' remap: 'yes' brand: | Supermicro model: | Super Server bios: | 1.2b cpu: | Intel(R) Xeon(R) W-2123 CPU @ 3.60GHz cpu-short: | FIXME chipset: | Intel Corporation Sky Lake-E DMI3 Registers [8086:2020] (rev 04) chipset-short: | FIXME gpu: | NVIDIA Corporation Device [10de:1cb6] (rev a1) (prog-if 00 [VGA controller]) gpu-short: | FIXME network: | Intel Corporation Ethernet Connection (2) I219-LM Aquantia Corp. Device d108 (rev 02) memory: | 147148 scsi: | TOSHIBA DT01ACA3 Rev: ABB0 DVDRAM GH24NSD5 Rev: LJ00 ST8000DM004-2CX1 Rev: 0001 WDC WD40EFRX-68N Rev: 0A82 Samsung SSD 840 Rev: BB6Q usb: | 2 versions: - works: 'FIXME:yes|no|partial' qubes: | R4.0 xen: | 4.8.5-30.fc25 kernel: | 4.19.155-1 remark: | FIXME credit: | FIXAUTHOR link: | FIXLINK ---
[qubes-users] sys-usb 3.1 hub no longer recognizes USB 2.0 devices
I'm somewhat new to the sys-usb as I recently upgraded from R3.2 to R4.0.2. I have a powered USB hub device that I use to plug in YubiKeys and some other USB 2.0 devices along with USB 3 external HDDs. After an update yesterday of dom0 and Fedora 30 (Template for sys-usb), and a system reboot, the USB 2.o devices on this hub are no longer recognized by sys-usb and can no longer be attached to AppVMs. USB 3.0 HDDs connected to the same hub still show up normally. What could I look at to troubleshoot this? lsusb in sys-usb doesn't show the attached USB 2 devices anymore. -- 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/0c362dcfd9975168fcfbc2eadbebd17f%40riseup.net.
Re: [qubes-users] Upgrading from R3.2 - R4.0.1 or 4.0.2-rc1?
On 2019-10-20 18:43, 'awokd' via qubes-users wrote: > Gaijin: >> I have a workstation on R3.2 and was holding out on an update to R4.x. I >> was hoping that R4.0.2 would have been finalized by now, but news on >> that has been pretty scarce since the July 10 announcement of RC1. I >> can't afford a lot of time to troubleshoot an upgrade on this particular >> machine. >> >> If I were to upgrade, is it safer to proceed with R4.0.1 and then to >> manually upgrade the VMs, or is 4.0.2-RC1 stable enough? >> > The most time consuming part of an upgrade is the backup & restore. A > suggested upgrade procedure could be: > > 1) Create 4.0.1 and 4.0.2 install media > 2) Backup all VMs > 3) Pull OS drive, replace with new, disconnect any secondary drives or > also replace with new > 4) Attempt to install new OS- try 4.0.2 first. If problems, 4.0.1. > 5) Try test restore of VM to OS drive > 6) Reconnect secondary drives and restore all VMs > > Note you need twice the free space on your OS drive of the largest VM in > your system for a restore. Thanks for the advice awokd. I was able to get R4.0.2-RC1 installed. I worked around the Debian template update issue by using 'apt update' manually in the terminal. The default installed Fedora, Whonix and Debian templates seem to update from Qubes Manager normally. I've had issues after restoring my backups though. I can't seem to upgrade my TemplateVMs without getting the dreaded “Failed to synchronize cache for repo” errors https://www.qubes-os.org/faq/#i-keep-getting-failed-to-synchronize-cache-for-repo-errors-when-trying-to-update-my-fedora-templates Switching the NetVM for the templates between sys-whonix, sys-firewall and sys-net hasn't resolved the error. I guess that is a Fedora issue rather than Qubes 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/a90938926684027a1f798d3c7491359b%40riseup.net.
[qubes-users] Upgrading from R3.2 - R4.0.1 or 4.0.2-rc1?
I have a worstation on R3.2 and was holding out on an update to R4.x. I was hoping that R4.0.2 would have been finalized by now, but news on that has been pretty scarce since the July 10 announcement of RC1. I can't afford a lot of time to troubleshoot an upgrade on this particular machine. If I were to upgrade, is it safer to proceed with R4.0.1 and then to manually upgrade the VMs, or is 4.0.2-RC1 stable enough? -- 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/ba686fa69d5a625536946daa2834f0e3%40riseup.net.
Re: [qubes-users] Qubes 4 install not seeing VT-d/VT-x
On 2019-03-24 19:09, 'awokd' via qubes-users wrote: > Gaijin wrote on 3/23/19 3:32 AM: >> While attempting to upgrade from R3.2 to R4.0.1 I get the error: >> Missing features: IOMMU/VT-d/AMD-Vi, Interrupt Remapping >> >> I have an ASRock H67DE motherboard with an Intel i7-2600 CPU which >> according to the specs supports both VT-d and VT-x, and I have both >> specifically enabled in the BIOS. However, the Qubes 4 installer >> apparently can't see them. (I wonder if this is because I can only boot >> the installation USB in Legacy mode and not AHCI mode) >> >> I'm wondering if it would be OK to proceed with the install despite this >> warning. Is there a way to check whether these BIOS settings are visible >> to Qubes, or is this warning a clear indicator that they're not? (I >> still have R3.2 working) >> > In R3.2's dom0 run qubes-hcl-report. Look for the 5 lines at the > bottom. You can proceed with the install, but if you don't really have > support it will fail when trying to set up sys-net after the initial > post-install reboot. I guess you mean the first five items instead of the last. I posted my HCL here: https://groups.google.com/forum/#!topic/qubes-users/URIPsM1VURU Looks like I do not have IOMMU or remapping available to Qubes. I wouldn't get far without sys-net. According to Intel my CPU does support VT-d and VT-x, might there be some way to try to force Qubes? I've been using this machine since R1, and would love to keep using it if possible. -- 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/588637a47165c699e89ce6e0857f6a74%40riseup.net. For more options, visit https://groups.google.com/d/optout.
[qubes-users] HCL ASRock H67DE motherboard
Works great with 3.2. Apparent lack of IOMMU is stopping R4 installation although the i7-2600 has support for VT-d and VT-x. -- 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/24056a9940d0eb2409289a5885f333a6%40riseup.net. For more options, visit https://groups.google.com/d/optout. --- layout: 'hcl' type: 'desktop' hvm: 'yes' iommu: 'no' slat: 'yes' tpm: 'unknown' remap: 'no' brand: | THIRDWAVE CORPORATION model: | Prime Series bios: | L1.43Y cpu: | Intel(R) Core(TM) i7-2600 CPU @ 3.40GHz cpu-short: | i7-2600 chipset: | Intel Corporation 2nd Generation Core Processor Family DRAM Controller [8086:0100] (rev 09) chipset-short: | Intel 8086 rev 09 gpu: | Intel Corporation 2nd Generation Core Processor Family Integrated Graphics Controller [8086:0102] (rev 09) NVIDIA Corporation GF114 [GeForce GTX 560 Ti] [10de:1200] (rev a1) (prog-if 00 [VGA controller]) gpu-short: | nVidia GeForce GTX 560 Ti network: | Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 06) memory: | 32676 scsi: | Samsung SSD 850 Rev: 2B6Q TOSHIBA DT01ACA3 Rev: ABB0 DVDRAM GH24NS70 Rev: GN03 ST8000DM004-2CX1 Rev: 0001 HDCR-U Rev: USB Flash Disk Rev: 1.00 usb: | 4 versions: - works: yes qubes: | R3.2 xen: | 4.6.6 kernel: | 4.14.103-1 remark: | Works great in R3.2, but apparent lack of IOMMU seems to be a problem with R4. credit: | Gaijin link: | FIXLINK ---
Re: [qubes-users] Re: Blank Screen Trying To Install
On 2019-03-24 02:41, Yushatak wrote: > On Thursday, March 21, 2019 at 8:57:09 PM UTC-4, Yushatak wrote: >> When I boot the Qubes installation media (I dd'd it to a USB stick per the >> instructions on the site) it initializes Xen, then the kernel starts booting >> (Linux penguins, etc.), and then it goes to a black screen and there's no >> activity. F1 does nothing. My hardware is a laptop with an i7 8700K and an >> Nvidia 1060, so it smelled like nouveau driver problems to me. However, >> normally one works around that by editing the kernel line in grub with >> nouveau.modeset=0 and I have no grub! I decided to try editing the grub.conf >> in the isolinux directory of the ISO by extracting the iso, editing, then >> regenerating the ISO. Someone on IRC was nice enough to provide me a log >> from the official build of the ISO so I used the proper switches/etc.. I >> booted that in a VM to make sure it was OK as a sanity check, then wrote >> that to the USB stick (which takes like 26 minutes, it's USB 2.. not fun) >> and it stopped booting after attaching the USB stick as a SCSI device, not >> even quite getting to the black screen. AFAIK my hardware requires a 4.18 kernel and from what they said on IRC there's nothing newer than 4.14 in Qubes anyway, but since it tries to boot I don't know. I throw myself upon your mercy, Qubes community/developers. > > Nobody has a single thought? Might the solution be putting your BIOS into Legacy mode? https://groups.google.com/forum/#!topic/qubes-users/Vy5wpWbOYxU In my case switching the HDD from AHCI mode to IDE mode seemed to get past this blank screen and got me to the install 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 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/24cf72d48db8b557b2f0832dfdcfbc13%40riseup.net. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Qubes 4 install not seeing VT-d/VT-x
While attempting to upgrade from R3.2 to R4.0.1 I get the error: Missing features: IOMMU/VT-d/AMD-Vi, Interrupt Remapping I have an ASRock H67DE motherboard with an Intel i7-2600 CPU which according to the specs supports both VT-d and VT-x, and I have both specifically enabled in the BIOS. However, the Qubes 4 installer apparently can't see them. (I wonder if this is because I can only boot the installation USB in Legacy mode and not AHCI mode) I'm wondering if it would be OK to proceed with the install despite this warning. Is there a way to check whether these BIOS settings are visible to Qubes, or is this warning a clear indicator that they're not? (I still have R3.2 working) -- 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/6900815d0a892f0da23be996339d34d9%40riseup.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qubes 3.2 v--> 4 fail
On 2019-03-21 11:31, Gaijin wrote: > I am trying to upgrade from R3.2 to R4. I don't seem to be able to boot > from the ISO I burned to a USB. > > I get this message flashed at the bottom of the boot screen before all > turns black: > > "Booted on L1TF-vulnerable hardware with SMT/Hyperthreading enabled. > Please access your configuration and choose an explicit "smt-=' > setting. See XSA-273." > > I've tried turning off hyperthreading in the BIOS, but get the same > message. Where can I set this config setting? Figured it out... It had nothing to do with the config file or hyper-threading settings. I had to switch the BIOS to Legacy mode to get past this. -- 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/b88205a17e4d5174619241f9eac6eeb9%40riseup.net. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Qubes 3.2 v--> 4 fail
I am trying to upgrade from R3.2 to R4. I don't seem to be able to boot from the ISO I burned to a USB. I get this message flashed at the bottom of the boot screen before all turns black: "Booted on L1TF-vulnerable hardware with SMT/Hyperthreading enabled. Please access your configuration and choose an explicit "smt-=' setting. See XSA-273." I've tried turning off hyperthreading in the BIOS, but get the same message. Where can I set this config setting? -- 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/7732fc8a011ce2193d5fc1eaf730c6a3%40riseup.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Setup NextCloud in Qubes
On 2018-11-25 07:33, Ivan Mitev wrote: > On 11/25/18 2:26 AM, pr0xy wrote: >> I was trying to install NextCloud into a Qubes R3.2 machine. Although I >> have it working it isn't persistent across reboots of the AppVM. Every >> time I restart the AppVM it asks me to setup my NextCloud again. >> >> How can I get NextCloud working in an AppVM? >> >> I put NextCloud into a Fedora template. I tried the full manual install >> and the Snap method. When I base the AppVM on that template I can >> startup NextCloud, create a MariaDB database, create an admin account >> and work with various settings, but a restart of the AppVM will lose all >> of those settings. How can I make my changes persistent so that I can >> use NextCloud normally? > > Why not use a StandaloneVM ? > > Or do you want to get a "clean/blank" nextcloud install each time you > restart an AppVM based on the template where you installed nextcloud ? > If so, you'll have to create the db/admin account/... in the > templateVM, not in the AppVM, otherwise any changes you do to the root > filesystem will be lost at the next restart. Note that it's usually > not a good idea to install and run third party stuff in templates (or, > don't base sensitive AppVMs on such templates). > > FYI the folders/files related to nextcloud are usually: > > - The folder where you extracted nextcloud (eg. /var/www/nextcloud) > - The data dir you configured; could be a subdir of the folder above > or another path. > - Mysql db (/var/lib/mysql) and maybe /etc/my.cnf* > - relevant httpd config (/etc/httpd/...) + php stuff, eg. /etc/php.ini > if you modified it. > > You'll also have to enable the web server and mysql in the template > (systemctl enable ...); or start it in the AppVM. >Why not use a StandaloneVM ? Had not actually considered a StandaloneVM. Usually use those for Windows, Ubuntu or other OSs. However that might be an option. I wasn't necessarily looking for a clean NextCloud on every restart, but wanted to avoid any other extraneous OS changes that might slip in. I was used to the AppVM model of installing and running various untrusted packages and I have a lot of TemplateVMs where I base those installs. None of those used MySQL or a LAMP setup though. I tried setting up the Admin user and database in the TemplateVM. That works, but then of course when changes are made in the AppVM none of them persist a restart. -- 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/eaab5287af0536b88f7d640bd49d2efe%40riseup.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Setup NextCloud in Qubes
On 2018-11-25 02:17, unman wrote: > On Sat, Nov 24, 2018 at 04:26:18PM -0800, pr0xy wrote: >> I was trying to install NextCloud into a Qubes R3.2 machine. Although I >> have it working it isn't persistent across reboots of the AppVM. Every >> time I restart the AppVM it asks me to setup my NextCloud again. >> >> How can I get NextCloud working in an AppVM? >> >> I put NextCloud into a Fedora template. I tried the full manual install >> and the Snap method. When I base the AppVM on that template I can >> startup NextCloud, create a MariaDB database, create an admin account >> and work with various settings, but a restart of the AppVM will lose all >> of those settings. How can I make my changes persistent so that I can >> use NextCloud normally? > > Have you looked at using bind-dirs? > https://www.qubes-os.org/doc/bind-dirs/ Thanks. That looks like it should work, but I guess I'm uncertain which directories I need to add to /rw/config/qubes-bind-dirs.d/50_user.conf I tried: binds+=( '/var/lib/mysql' ) binds+=( '/var/www' ) as those would appear to cover the MariaDB MySQL database and the web server for NextCloud. However, even with those settings any database or user created in MySQL of the AppVM doesn't persist after a restart. -- 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/338ee10886347013c1edb677d4f52cf2%40riseup.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Accurate time in AppVM
On 2018-09-20 13:04, unman wrote: > On Wed, Sep 19, 2018 at 07:50:59PM -0700, Gaijin wrote: >> On 2018-09-19 07:36, Ivan Mitev wrote: >> > On 9/19/18 9:22 AM, Gaijin wrote: >> >> On 2018-09-19 05:22, Ivan Mitev wrote: >> >>> On 9/19/18 5:17 AM, Gaijin wrote: >> >>>> Running Qubes R3.2 >> >>>> >> >>>> I have some software that I run in an AppVM that needs to be accurate to >> >>>> within a second or two of NTP server time in order to work. I have >> >>>> finally figured out how to get my ClockVM to sync to an NTP server and >> >>>> for timesyncd.service to run when sys-net boots. >> >>>> >> >>>> My problem is that my AppVM slowly loses several seconds after some >> >>>> time, and I can't figure out a way to manually or automatically force it >> >>>> to resync itself. >> >>> >> >>> I don't have a R3.2 to test, but if it's like R4 your VM has a systemd >> >>> timer that updates the time every 6 hours [1]. In that case you could: >> >>> - change the definition of the timer so that it's run more frequently >> >>> - disable the timer and run a ntp client ; that'll be the best solution >> >>> if your software is very time sensitive, but it increases the attack >> >>> surface because of the ntp client. >> >>> >> >>> >> >>> [1] >> >>> https://github.com/Qubes-Community/Contents/blob/master/docs/system/clock-time.md >> >> >> >> How might I adjust the schedule of qubes-sync-time.timer in the AppVM if >> >> that is available in R3.2? That looks like a safer way to proceed if >> >> possible. >> > >> > Provided that R3.2 time sync mechanism is the same as R4, you could >> > paste the following text into /etc/systemd/system/qubes-sync-time.timer: >> > >> > [Timer] >> > OnUnitActiveSec=10min >> > >> > >> > Doing so allows you to override stuff from >> > /usr/lib/systemd/system/qubes-sync-time.timer and preverve your changes >> > in case the original unit file is updated. >> > >> > Then reload the definitions with `sudo systemctl daemon-reload` >> > >> > You can see the timer's status with `systemctl list-timers` >> > >> > If you want those changes to stick after a reboot, apply them in the >> > TemplateVM you're using for your AppVM; alternatively you could add the >> > new file to your AppVM's /rw/config and issue commands in the rc.local >> > script there (copy the file + reload systemd). >> >> Looks like this would be easier in R4. The 3.2 doesn't have the >> qubes-sync-time.timer or perhaps it's named something else. Would anyone >> know which file might control this in 3.2? Or is there a way to make a >> systemd timer in an AppVM to force Qubes to resync with the NTP server? >> > > In 3.2 time synchronizing was somewhat different, so the advice re 4.0 > doesn't help. > You should not have needed to do anything special to the clockVM to get > time syncing working there. Almost certainly you should revert those > changes. > I recall there was a cron job running every 6 hours : I believe > you can find the cron file under /etc/cron.d in dom0 > You could try changing the cron job to make the timer reset more > regularly. > > You haven't said what period you are seeing the time drift occur, but > change the frequency to something that preempts the drift without > constantly firing off. > > Remember this is undoubtedly going to help fingerprint your system. > > unman What I had to do special in the ClockVM to get it working (Fedora 28 minimal) was to follow the instructions here https://github.com/QubesOS/qubes-issues/issues/3983 as systemd-timesyncd wasn't starting. I have that working and the time syncing in the ClockVM seems to be OK. My time drift comes in my AppVM (Fedora 28). Right now it's about 2 seconds off after running overnight. In that the systemd-timesyncd.service is not active. I thought the ClockVM was supposed to control the time in the other VMs, so I haven't changed that. I found the qubes-sync-clock.cron and switched it from 6 hours to 3 hours and I'll leave the AppVM running to see if the drift fixes. -- 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/edc8ea2b3758882ac2c2a856515eb5cc%40riseup.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Accurate time in AppVM
On 2018-09-19 07:36, Ivan Mitev wrote: > On 9/19/18 9:22 AM, Gaijin wrote: >> On 2018-09-19 05:22, Ivan Mitev wrote: >>> On 9/19/18 5:17 AM, Gaijin wrote: >>>> Running Qubes R3.2 >>>> >>>> I have some software that I run in an AppVM that needs to be accurate to >>>> within a second or two of NTP server time in order to work. I have >>>> finally figured out how to get my ClockVM to sync to an NTP server and >>>> for timesyncd.service to run when sys-net boots. >>>> >>>> My problem is that my AppVM slowly loses several seconds after some >>>> time, and I can't figure out a way to manually or automatically force it >>>> to resync itself. >>> >>> I don't have a R3.2 to test, but if it's like R4 your VM has a systemd >>> timer that updates the time every 6 hours [1]. In that case you could: >>> - change the definition of the timer so that it's run more frequently >>> - disable the timer and run a ntp client ; that'll be the best solution >>> if your software is very time sensitive, but it increases the attack >>> surface because of the ntp client. >>> >>> >>> [1] >>> https://github.com/Qubes-Community/Contents/blob/master/docs/system/clock-time.md >> >> How might I adjust the schedule of qubes-sync-time.timer in the AppVM if >> that is available in R3.2? That looks like a safer way to proceed if >> possible. > > Provided that R3.2 time sync mechanism is the same as R4, you could > paste the following text into /etc/systemd/system/qubes-sync-time.timer: > > [Timer] > OnUnitActiveSec=10min > > > Doing so allows you to override stuff from > /usr/lib/systemd/system/qubes-sync-time.timer and preverve your changes > in case the original unit file is updated. > > Then reload the definitions with `sudo systemctl daemon-reload` > > You can see the timer's status with `systemctl list-timers` > > If you want those changes to stick after a reboot, apply them in the > TemplateVM you're using for your AppVM; alternatively you could add the > new file to your AppVM's /rw/config and issue commands in the rc.local > script there (copy the file + reload systemd). Looks like this would be easier in R4. The 3.2 doesn't have the qubes-sync-time.timer or perhaps it's named something else. Would anyone know which file might control this in 3.2? Or is there a way to make a systemd timer in an AppVM to force Qubes to resync with the NTP server? -- 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/619a68c891926551f489ec415d62e7c7%40riseup.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Accurate time in AppVM
On 2018-09-19 05:22, Ivan Mitev wrote: > On 9/19/18 5:17 AM, Gaijin wrote: >> Running Qubes R3.2 >> >> I have some software that I run in an AppVM that needs to be accurate to >> within a second or two of NTP server time in order to work. I have >> finally figured out how to get my ClockVM to sync to an NTP server and >> for timesyncd.service to run when sys-net boots. >> >> My problem is that my AppVM slowly loses several seconds after some >> time, and I can't figure out a way to manually or automatically force it >> to resync itself. > > I don't have a R3.2 to test, but if it's like R4 your VM has a systemd > timer that updates the time every 6 hours [1]. In that case you could: > - change the definition of the timer so that it's run more frequently > - disable the timer and run a ntp client ; that'll be the best solution > if your software is very time sensitive, but it increases the attack > surface because of the ntp client. > > > [1] > https://github.com/Qubes-Community/Contents/blob/master/docs/system/clock-time.md How might I adjust the schedule of qubes-sync-time.timer in the AppVM if that is available in R3.2? That looks like a safer way to proceed if possible. -- 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/bcf9dbe3e29a10a858fabded0a371451%40riseup.net. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Accurate time in AppVM
Running Qubes R3.2 I have some software that I run in an AppVM that needs to be accurate to within a second or two of NTP server time in order to work. I have finally figured out how to get my ClockVM to sync to an NTP server and for timesyncd.service to run when sys-net boots. My problem is that my AppVM slowly loses several seconds after some time, and I can't figure out a way to manually or automatically force it to resync itself. -- 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/2671003d5e715bea5a63bced125d753d%40riseup.net. For more options, visit https://groups.google.com/d/optout.
[qubes-users] [R3.2] PS/2 mouse issue
In preparation for R4.0 I procured a new workstation that has PS/2 ports for the keyboard and mouse. The PS/2 keyboard works fine, but the PS/2 mouse is not recognized on boot of R3.2. After a reboot, I must unplug the PS/2 mouse and plug it back in so that it will work. Is this a known issue, or are there any work-arounds? -- 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/0176e7b9b9775c45b969fa30ee9beec4%40riseup.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qubes and Whonix now have next-generation Tor onion services!
On 2018-02-12 01:47, Andrew David Wong wrote: > On 2018-02-11 18:57, Gaijin wrote: > >> The Qubes OS v3 and v2 onion services sites don't appear to have been >> updated since January when this announcement was made. Shouldn't they >> show the same content as the normal Qubes site? >> >> For example I don't see the news of the 4.0-rc4 release, or recent >> changes to the Docs. >> > > Thanks for the report! Tracking: > > https://github.com/QubesOS/qubes-issues/issues/1352#issuecomment-364812018 > > - -- > Andrew David Wong (Axon) > Community Manager, Qubes OS > https://www.qubes-os.org FYI: The Onion sites are still not syncing with the Qubes site. They're still stuck in January 2018... -- 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/c56b5c1d344eeb12b4a69fc3b0975145%40riseup.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Qubes and Whonix now have next-generation Tor onion services!
On 2018-01-23 07:26, Andrew David Wong wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA512 > > Dear Qubes Community, > > The Qubes and Whonix projects now have next-generation Tor onion > services [1] (a.k.a. "v3 onion services"), which provide several > security improvements [2] over v2 onion services: > > Qubes: > http://sik5nlgfc5qylnnsr57qrbm64zbdx6t4lreyhpon3ychmxmiem7tioad.onion > > Whonix: > http://dds6qkxpwdeubwucdiaord2xgbbeyds25rbsgr73tbfpqpt4a6vjwsyd.onion > > These services run alongside our existing ("v2") onion services: > > Qubes: > http://qubesos4z6n4.onion > > Whonix: > http://kk63ava6.onion > > For instructions on accessing the new addresses and further details, > please see the Whonix announcement [3]. Our sincere thanks go to the > Whonix team, and especially fortasse, the Whonix server > administrator, for doing this. > > > [1] > https://blog.torproject.org/tors-fall-harvest-next-generation-onion-services > [2] https://trac.torproject.org/projects/tor/wiki/doc/NextGenOnions > [3] https://www.whonix.org/blog/whonix-new-v3-onion-address > > This announcement is also available on the Qubes website: > https://www.qubes-os.org/news/2018/01/23/qubes-whonix-next-gen-tor-onion-services/ > > - -- > Andrew David Wong (Axon) > Community Manager, Qubes OS > https://www.qubes-os.org > > -BEGIN PGP SIGNATURE- > > iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAlpm44UACgkQ203TvDlQ > MDBlMg//T7lj6NCoy8YNNKDSjtkoe6WIcfdvoLFxQrIy+fmEJMQKTgKBb18kFxH4 > Q67+iyL+hvhFOCb3ss98Xj2ogrRvv4VkPypPRmmMRx7dJChpCdBylRNtx0rPslw9 > OUNHw3mj3frXjAbw4cOb2Tlsd8ANKDrQoFMaADKfenLCQnMzPpqMx4rt0Rw912Jn > +wShCF6RM0gyUFTiqxYrPgJn0RHvSUVKlWwFCUXWVnGmvdwRy7G5bqb6/a6RrV8p > CO3zXHM+/pclfK4ls61FyseYY2iIOLCqVid7Oez/BWqVS4ckmQWknK1juo2/Qzwm > exNCSF2+nzGfg9v15LiOKDP/35hiqvh04y1JPUf2WbivWGUfkOpNt1rvdSHa/wjH > f6y42Dqq5GYfcz9XGmehazKCI4/usXOpa+eH3Uar3hJD5AIe0f/3URe9LrdUgp68 > bN0WLcu9ctpAXtufhbgf2KcPwhrsB9uBqG4fBgHl9YLRgppv8tiuteKosFuhDOGE > CpskV3izqmyLYIQ1P9u3wvM4/MZ652fBZKUD/4PNrEQuW8g6Nmv0dFD/KE2V/72G > TME+YKVSB8Rs8Q3dfgVLw5gnF5Z3p/0i0EfM0m5LuBF4ScFGAMAVnZ+Ax61ESNkD > 1Bv0+xS3lpTHs05Qw/MY8ecSbcZTHPqF9a8jTUmc1CMJNm5EceI= > =cwtv > -END PGP SIGNATURE- The Qubes OS v3 and v2 onion services sites don't appear to have been updated since January when this announcement was made. Shouldn't they show the same content as the normal Qubes site? For example I don't see the news of the 4.0-rc4 release, or recent changes to the Docs. -- 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/aa4ee1ecef28508f855a29295ab7cd64%40riseup.net. For more options, visit https://groups.google.com/d/optout.
[qubes-users] HCL - Dell Precision 5810
Had to switch BIOS to Legacy to install Qubes. Otherwise everything else seems to be working well with R3.2. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/c141a4978bc271d0631edcc2accda646%40riseup.net. For more options, visit https://groups.google.com/d/optout. Qubes-HCL-Dell_Inc_-Precision_Tower_5810-20180118-140542.cpio.gz Description: GNU Zip compressed data --- layout: 'hcl' type: 'tower' hvm: 'yes' iommu: 'yes' slat: 'yes' tpm: 'unknown' remap: 'yes' brand: | Dell Inc. model: | Precision Tower 5810 bios: | A20 cpu: | Intel(R) Xeon(R) CPU E5-2630 v4 @ 2.20GHz cpu-short: | FIXME chipset: | Intel Corporation Xeon E7 v4/Xeon E5 v4/Xeon E3 v4/Xeon D DMI2 [8086:6f00] (rev 01) chipset-short: | FIXME gpu: | Advanced Micro Devices, Inc. [AMD/ATI] Bonaire [FirePro W5100] [1002:6649] (prog-if 00 [VGA controller]) Advanced Micro Devices, Inc. [AMD/ATI] Bonaire [FirePro W5100] [1002:6649] (prog-if 00 [VGA controller]) gpu-short: | FIXME network: | Intel Corporation Ethernet Connection I217-LM (rev 05) memory: | 130985 scsi: | DVD+-RW GTA0NRev: A1C1 SK hynix SC311 S Rev: 0P10 ST2000DM001-1ER1 Rev: CC27 ST2000DM001-1ER1 Rev: CC27 usb: | 3 versions: - works: 'FIXME:yes|no|partial' qubes: | R3.2 xen: | 4.6.6 kernel: | 4.9.56-21 remark: | FIXME credit: | FIXAUTHOR link: | FIXLINK ---
Re: [qubes-users] Formatting and Permissions for internal HDDs
On 2017-11-27 10:26, awokd wrote: > On Mon, November 27, 2017 05:22, Gaijin wrote: >> In R3.2 I have some additional internal hard drives in my PC. I wanted >> to format them to be encrypted so that they will match the disk >> encryption of my main Qubes disk install, and so that I won't have to >> enter the disk password every time I access the drives or attach them to >> a VM. I have not been able to figure this out. Is this possible? > > Yes, give them the exact same password as your primary and mount them by > UUID in both /etc/crypttab and /etc/fstab. Following your recommendation I tried encrypting the drive and having it mount in dom0 on boot. That works remembering the password, but it's not optimal for all drives. That's fine for my backups drive, but I have another data drive that I want to mount to different AppVMs. Mounting that to dom0 on boot isn't a good idea. If I unmount an encrypted drive from dom0 and attach it to an AppVM, I still need to enter the disk decryption password from the AppVM to access the drive. This is a drive I wanted to use between several AppVMs. Would I need to setup an /etc/fstab in each AppVM for this? >> My other issue is that whether I encrypt the drive partitions with LUKS >> or just make a ext4 partition, I can't access the drives after creating >> them because they're assigned ownership to the root account. Normal >> Qubes use is thru the dom0 account or the user account on the VMs, not >> root. What would be a good permissions setting to allow dom0 or a VM >> access the hard drives? > > I think if you mount them as part of boot you will have less trouble. > Don't remember having to do anything special with permissions, but review > the ones set on /var/lib/qubes if needed. Also see > https://www.qubes-os.org/doc/secondary-storage/ . That permissions issue is still there even if I mount the encrypted drive at boot. I have this issue on 2 different machines running R3.2. These are new, blank HDDs that dom0 recognizes when I boot up. They're set with rw for the Owner root and in the root Group, which only has r, Others are r as well. Should I be chown-ing these from the AppVMs so that the User account there can manipulate them? I'm a bit new to *nix disk permissions... -- 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/88c25dc1748fe3c6b916aeb5b7ee14d4%40riseup.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] New install R3.2 - All VMs fail with libxenlight error
On 2017-11-27 05:23, Yuraeitha wrote: > On Monday, November 27, 2017 at 5:01:36 AM UTC, pr0xy wrote: >> On 2017-11-21 10:21, pr0xy wrote: >> > I have a new workstation, 128GB RAM, Xeon with 10 cores, 1TB SSD, and >> > I'm trying to get R3.2 running on it. VT-x and VT-d are enabled in the >> > BIOS along with TPM. Had to set the machine to Legacy boot and turn off >> > UEFI to install Qubes though. >> > >> > I've tried reinstalling Qubes a few times, but I get the same results. >> > When trying to open any AppVM, and even the Fedora and Debian Templates, >> > I get the error: >> > >> > internal error: libxenlight failed to create new domain >> > >> > In one of my tests I was able to get the default anon-whonix VM to work, >> > but after a subsequent reinstall that is not working any longer. >> > >> > I'd really like to get Qubes working on this machine, but I'm not sure >> > where to look. >> >> I tried setting up Qubes to do all updates thru Tor/Whonix. After >> updating the base Qubes install, which took more than half a day, all >> these errors went away. > > You could try with Qubes 4 RC-3 instead of your Qubes 4 RC-2. It's > supposed to come out today, the 27th November - looky here > https://www.qubes-os.org/doc/releases/4.0/schedule/ > > But it's possibly to be postponed though, we'll have to see. > > Also, you made sure there are no additional virtualization settings in > your BIOS? Some motherboards, not all, appears to have an extra > setting, i.e. some Asus boards have both VT-d and Virtualisation, > which both comes disabled by default. > > You may not have that extra setting, but it can't hurt to be sure, at > least this gives you a place to start until someone maybe posts better > suggestions. I'm on R3.2, not RC4 yet. I may wait until R4 comes out (maybe RC-3) to play with that. I was able to get past my problem, and now R3.2 works. Turns out the R3.2 ISO needs a ton of updates before it would work on my machine. Once I added the dom0 updates it started magically working. ;) -- 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/31455e97d4fc99fc9daf45f8e6641dae%40riseup.net. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Formatting and Permissions for internal HDDs
In R3.2 I have some additional internal hard drives in my PC. I wanted to format them to be encrypted so that they will match the disk encryption of my main Qubes disk install, and so that I won't have to enter the disk password every time I access the drives or attach them to a VM. I have not been able to figure this out. Is this possible? My other issue is that whether I encrypt the drive partitions with LUKS or just make a ext4 partition, I can't access the drives after creating them because they're assigned ownership to the root account. Normal Qubes use is thru the dom0 account or the user account on the VMs, not root. What would be a good permissions setting to allow dom0 or a VM access the hard drives? -- 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/3bda050ef4e77df812d4b034383d7939%40riseup.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: R3.2 Upgrading Fedora 25 --> 26 templates - PulseAudio issue
On 2017-11-20 08:39, Frédéric Pierret wrote: > Le dimanche 19 novembre 2017 22:51:10 UTC+1, Gaijin a écrit : >> On 2017-11-19 11:53, Frédéric Pierret wrote: >> > For pulseaudio issue in Fedora 26, you need to enable the >> > current-testing to update the qubes-gui-agent-linux for which the spec >> > has been updated (see >> > https://github.com/fepitre/qubes-gui-agent-linux/commit/251f5a4be505d6a268fd16bf15e33d9957c36b49). >> > Also, if you want, you can build the Fedora 26 for R3.2 and soon >> > Fedora 27 (see my post >> > https://groups.google.com/d/msg/qubes-devel/MLjj0RNYTe8/H-85bI8cBQAJ). >> > >> > Do not hesitate to check what happen on the qubes-devel list notably >> > for such problem related to newer version of Fedora. >> >> I see the documentation to enable current-testing in the VM >> https://www.qubes-os.org/doc/software-update-vm/ and I assume that we >> would add that in the upgrade step in the template somewhat like this: >> >> sudo dnf --releasever=26 distro-sync >> --enablerepo=qubes-vm-fedora-26-current-testing > It's only 'qubes-vm-r3.2-current-testing'. > >> However, I don't seem to be able to guess the correct repo-name to add >> in here. I get 'unknown repo' with "fedora-26", "fedora26", & "fc26". >> How would I find the correct Repo name to put in here? Thanks! That worked to get the Fedora 26 templates updated for me: sudo dnf --releasever=26 distro-sync --enablerepo=qubes-vm-r3.2-current-testing I was able to update all my templates in R3.2 and they appear to be working fine now. -- 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/a56283ceeeabc2cb5aa5ff8ebb53a1e2%40riseup.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: R3.2 Upgrading Fedora 25 --> 26 templates - PulseAudio issue
On 2017-11-19 11:53, Frédéric Pierret wrote: > For pulseaudio issue in Fedora 26, you need to enable the > current-testing to update the qubes-gui-agent-linux for which the spec > has been updated (see > https://github.com/fepitre/qubes-gui-agent-linux/commit/251f5a4be505d6a268fd16bf15e33d9957c36b49). > Also, if you want, you can build the Fedora 26 for R3.2 and soon > Fedora 27 (see my post > https://groups.google.com/d/msg/qubes-devel/MLjj0RNYTe8/H-85bI8cBQAJ). > > Do not hesitate to check what happen on the qubes-devel list notably > for such problem related to newer version of Fedora. I see the documentation to enable current-testing in the VM https://www.qubes-os.org/doc/software-update-vm/ and I assume that we would add that in the upgrade step in the template somewhat like this: sudo dnf --releasever=26 distro-sync --enablerepo=qubes-vm-fedora-26-current-testing However, I don't seem to be able to guess the correct repo-name to add in here. I get 'unknown repo' with "fedora-26", "fedora26", & "fc26". How would I find the correct Repo name to put in here? -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/a14c1479f8e5fa61b178c80044956392%40riseup.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: R3.2 Upgrading Fedora 25 --> 26 templates - PulseAudio issue
On 2017-11-06 22:42, Gaijin wrote: > > Well, there are Fedora 26 templates > https://ftp.qubes-os.org/repo/yum/r3.2/current/vm/ > However, I'm still stuck with this PulseAudio issue... Nobody else has run into this issue of an older version of PulseAudio being required for the Fedora 26 templates in R3.2? I can update some packages manually, but this dependency in the Qubes Fedora 26 template messes up updating from the GUI Qubes Manager. All templates always show that an update is needed. -- 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/2a7c06e25f2b34446396297df9a4524d%40riseup.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: R3.2 Upgrading Fedora 25 --> 26 templates - PulseAudio issue
On 2017-11-05 22:14, Others call me jean wrote: > +1 > > if possible a rawhide repository too (for latest package updates -> > security reason) > > On 11/05/2017 11:00 PM, J. Eppler wrote: >> I would be interested in Fedora 26 or even better 27 in R3.2 as well. >> >> Best regards >> J. Eppler >> Well, there are Fedora 26 templates https://ftp.qubes-os.org/repo/yum/r3.2/current/vm/ However, I'm still stuck with this PulseAudio issue... -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/dd2eccdb450892e36920a67a4eae6261%40riseup.net. For more options, visit https://groups.google.com/d/optout.
[qubes-users] R3.2 Upgrading Fedora 25 --> 26 templates - PulseAudio issue
On Qubes R3.2 following the template upgrade instructions https://www.qubes-os.org/doc/template/fedora/upgrade-24-to-25/ to upgrade from Fedora 25 to Fedora 26, I'm running into some issues. There are several updates that I can't make: --- Problem 1: package qubes-gui-vm-3.2.18-1.fc26.x86_64 requires pulseaudio = 10.0, but none of the providers can be installed - cannot install both pulseaudio-11.1-2.fc26.x86_64 and pulseaudio-10.0-4.fc26.x86_64 - cannot install both pulseaudio-10.0-4.fc26.x86_64 and pulseaudio-11.1-2.fc26.x86_64 - cannot install the best update candidate for package qubes-gui-vm-3.2.18-1.fc26.x86_64 - cannot install the best update candidate for package pulseaudio-10.0-4.fc26.x86_64 Problem 2: package salt-2017.7.2-1.fc26.noarch requires dnf-utils, but none of the providers can be installed - package dnf-utils-2.1.5-1.fc26.noarch conflicts with yum-utils < 1.1.31-513 provided by yum-utils-1.1.31-512.fc26.noarch - package dnf-utils-2.1.1-1.fc26.noarch conflicts with yum-utils < 1.1.31-513 provided by yum-utils-1.1.31-512.fc26.noarch - cannot install the best update candidate for package yum-utils-1.1.31-512.fc26.noarch - cannot install the best update candidate for package salt-2016.11.5-3.fc26.noarch Problem 3: package qubes-vm-dependencies-3.2.3-1.fc26.noarch requires qubes-gui-vm, but none of the providers can be installed - package qubes-gui-vm-3.2.18-1.fc26.x86_64 requires pulseaudio = 10.0, but none of the providers can be installed - package pulseaudio-10.0-4.fc26.x86_64 requires libpulsecommon-10.0.so()(64bit), but none of the providers can be installed - cannot install both pulseaudio-libs-11.1-2.fc26.x86_64 and pulseaudio-libs-10.0-4.fc26.x86_64 - cannot install both pulseaudio-libs-10.0-4.fc26.x86_64 and pulseaudio-libs-11.1-2.fc26.x86_64 - cannot install the best update candidate for package qubes-vm-dependencies-3.2.3-1.fc26.noarch - cannot install the best update candidate for package pulseaudio-libs-10.0-4.fc26.x86_64 Problem 4: problem with installed package qubes-gui-vm-3.2.18-1.fc26.x86_64 - package qubes-gui-vm-3.2.18-1.fc26.x86_64 requires pulseaudio = 10.0, but none of the providers can be installed - cannot install both pulseaudio-11.1-2.fc26.x86_64 and pulseaudio-10.0-4.fc26.x86_64 - cannot install both pulseaudio-10.0-4.fc26.x86_64 and pulseaudio-11.1-2.fc26.x86_64 - package pulseaudio-module-bluetooth-11.1-2.fc26.x86_64 requires libpulsecore-11.1.so()(64bit), but none of the providers can be installed - cannot install the best update candidate for package pulseaudio-module-bluetooth-10.0-4.fc26.x86_64 Problem 5: problem with installed package yum-utils-1.1.31-512.fc26.noarch - package dnf-utils-2.1.5-1.fc26.noarch conflicts with yum-utils < 1.1.31-513 provided by yum-utils-1.1.31-512.fc26.noarch - package salt-2017.7.2-1.fc26.noarch requires dnf-utils, but none of the providers can be installed - package dnf-utils-2.1.1-1.fc26.noarch requires dnf-plugins-core = 2.1.1-1.fc26, but none of the providers can be installed - package salt-ssh-2017.7.2-1.fc26.noarch requires salt = 2017.7.2-1.fc26, but none of the providers can be installed - cannot install both dnf-plugins-core-2.1.1-1.fc26.noarch and dnf-plugins-core-2.1.5-1.fc26.noarch - cannot install the best update candidate for package salt-ssh-2016.11.5-3.fc26.noarch - cannot install the best update candidate for package dnf-plugins-core-2.1.5-1.fc26.noarch Problem 6: problem with installed package qubes-vm-dependencies-3.2.3-1.fc26.noarch - package qubes-vm-dependencies-3.2.3-1.fc26.noarch requires qubes-gui-vm, but none of the providers can be installed - package qubes-gui-vm-3.2.18-1.fc26.x86_64 requires pulseaudio = 10.0, but none of the providers can be installed - cannot install both pulseaudio-11.1-2.fc26.x86_64 and pulseaudio-10.0-4.fc26.x86_64 - cannot install both pulseaudio-10.0-4.fc26.x86_64 and pulseaudio-11.1-2.fc26.x86_64 - package pulseaudio-module-x11-11.1-2.fc26.x86_64 requires libpulsecore-11.1.so()(64bit), but none of the providers can be installed - cannot install the best update candidate for package pulseaudio-module-x11-10.0-4.fc26.x86_64 PackageArch Version Repository Size Skipping packages with conflicts: (add '--best --allowerasing' to command line to force their upgrade): dnf-plugins-core noarch2.1.1-1.fc26 fedora 49 k dnf-utils noarch2.1.1-1.fc26 fedora 39 k dnf-utils noarch2.1.5-1.fc26 updates 40 k pulseaudio x86_6411.1-2.fc26 updates 942 k pulseaudio-libsx86_6411.1-2.fc26 updates 661 k Skipping packages with broken depend
[qubes-users] Mounting HDD to Windows HVM in Qubes R3.2
I have an issue trying to use some internal HDD in a new Qubes R3.2 install. The machine was previously Windows, so the HDD were NTFS formatted, and they contain various work and backup data. Qubes is on its own SSD. Initially Qubes could not see the drives from dom0, so I couldn't attach them to appVMs. I looked around some forum posts and found someone suggesting the use of: sudo ntfsfix /dev/sdb1 Running that on the drives from dom0 allowed me to see the drives and manipulate their contents on Fedora and Debian based VMs. However, if I try to attach these same drives to a Windows 7 or Windows 10 HVM, Windows tells me it needs to format the drives to see them. (I'm attaching them through VM settings | Advanced | Additional drive with the backend domain dom0 and the path /dev/sdb) Formatting the drives isn't an option as I have data on them. If I run fsck on the volumes from dom0 it tells me they are dirty, but I can still access the files without issue (outside Windows), but I don't think it's a hardware issue. I would like to be able to access these drives from both Windows and Linux (via Qubes). Any ideas of how I could proceed? -- 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/1dd311e18ee406807963e4d729bdc5f1%40riseup.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] KCMA-D8 Libre motherboards are going for around $260 on newegg
On 2017-08-24 22:40, taii...@gmx.com wrote: > This is a great chance to pick up one of the last and best owner > controlled x86 boards for much less than the usual price ($350) and > MSRP ($315). > > Compatible with Qubes 4.0! > > Supports IOMMU for graphics! (so you can play video games in a VM) > > > CPU's cost around $10-50 and 16GB DDR3 ECC RAM is $30 > Noctua makes a great C32 cooler for around $40 or you can get a not as > great one and have hotter temps for $20 on fleabay. > > > Recommended Accessories: > > ASMB4-iKVM (BMC Module, required for the upcoming libre OpenBMC port > for KGPE-D16/KCMA-D8 the asus boards) > > TPM (Coreboot supports an owner controlled core root of trust which is > more secure than otherwise) > > > Notes: > > 128GB RAM Max > > You will have to get a graphics card if you want decent video, the > onboard chip only supports 1280x768 and is quite slow - AMD is > reccomended for better virtualization (see nvidia code 43 "bug" when > you try to attach their cards to a VM) and linux drivers that are > almost open source and don't suck unlike nvidia > > 43xx CPU's require microcode updates for secure operation > > The init code including graphics init is entirely open source and > there is no ME/PSP, this board can be flashed with a libre version of > coreboot (unlike purism's laptops) > > > > Reccomended CPU's: > > 4284 (Works securely without microcode updates) > > 4365EE (40W, for a low power build) > > 4386 (equivalent to AMD FX 8310) How's your experience with the KGPE-D16/KCMA-D8 boards? Looking at the NewEgg comments there are a lot of people complaining about seemingly defective boards. A lot of RMA requests. -- 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/95ea60b4f2916f69328801cf702d6c88%40riseup.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Best options for a 4.x compatible Dell workstation
On 2017-09-12 22:57, taii...@gmx.com wrote: > On 09/12/2017 06:50 PM, Gaijin wrote: > >> On 2017-09-12 12:46, filtration wrote: >>> Gaijin: >>>> On 2017-09-12 05:32, pixel fairy wrote: >>>>> On Monday, September 11, 2017 at 10:31:56 PM UTC-7, pixel fairy wrote: >>>>>> given that appvms cant use 3d acceleration anyway, your best bet is >>>>>> intel graphics. if your going to give a gpu to a vm, then it depends on >>>>>> the os of that vm. >>>>>> >>>>>> last i checked, nvidia is fine with virtualization of quadro cards. >>>>>> >>>>>> make sure the workstation doesnt have AMT (vpro etc) as bussiness lines >>>>>> tend to. you may be safer with what dell would otherwise sell as a >>>>>> consumer desktop or gaming rig, minus the fancy graphics card unless >>>>>> your going to use it. but, if thats a big part of your work, you may be >>>>>> better off with linux + kvm or something else instead of qubes. >>>>> damn nonlinear editing. that last sentence was supposed to go at the >>>>> end of the first paragraph. >>>> Well, the good news is that enabling vPro on a Dell is an extra option >>>> that you can select (costs $19), so I made sure that selection was off. >>>> Thanks for the heads up. >>>> >>>> The newer Xeon chips in the E5 Series no longer include on-board >>>> processor graphics, so Intel graphics isn't an option if I go this >>>> route. They can handle a lot more RAM (1.2TB vs. 64GB) and have more >>>> cores (10 vs. 4). There's generally a lot more I could do simultaneously >>>> with this chip it seems looking at the specs. >>>> >>>> Researching through these forums and even the Qubes Docs there seems to >>>> be a "stay away from nVidia" theme; That's why I was focusing on the AMD >>>> graphics card option. Is nVidia Quadro a viable option? >>>> >>>> Using the Dell configurator, and plugging in RedHat Linux 7.2 as the OS >>>> I find that the very newest AMD FirePro graphics card I selected isn't >>>> compatible. (I'm assuming RHEL 7.2 is a roughly equivalent to the Fedora >>>> 23 in dom0) So I dropped down to the older W5100 card and that seemed to >>>> work for them. >>>> >>>> The graphics aren't really a big part of my work. I just want a box that >>>> will be ready to run Qubes v4. >>>> >>> Gaijin: Intel GPU is recommended, AMD are second best. >>> >>> IIRC, Dom0 will be based on Fedora 25 in Qubes 4.0. Try checking AMD's >>> site (https://support.amd.com/en-us/download) for compatibility reports, >>> too. >> Looking at the latest AMD FirePro drivers, they have versions that >> support RHEL and CentOS, so in turn can I assume one of those might >> support Fedora as well? > Yes. >> They also seem to have a generic Linux driver >> for older OS versions. >> >> I do see a few AMD FirePro cards in the HCL that seem to be working, but >> not the specific one I'm looking at, so that's somewhat encouraging... >> > Adding your own driver to dom0 wouldn't be difficult if by chance you > need to, I mod my kernels all the time. Cheers for the advice! The hope is that generic video drivers in dom0 will suffice, but good to know that I could add a driver there, and that one would be available. I'm feeling a lot better about this AMD card now. -- 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/53f2408f7d0f65c44e0ec6389efc1da7%40riseup.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Best options for a 4.x compatible Dell workstation
On 2017-09-12 12:46, filtration wrote: > Gaijin: >> On 2017-09-12 05:32, pixel fairy wrote: >>> On Monday, September 11, 2017 at 10:31:56 PM UTC-7, pixel fairy wrote: >>>> given that appvms cant use 3d acceleration anyway, your best bet is intel >>>> graphics. if your going to give a gpu to a vm, then it depends on the os >>>> of that vm. >>>> >>>> last i checked, nvidia is fine with virtualization of quadro cards. >>>> >>>> make sure the workstation doesnt have AMT (vpro etc) as bussiness lines >>>> tend to. you may be safer with what dell would otherwise sell as a >>>> consumer desktop or gaming rig, minus the fancy graphics card unless your >>>> going to use it. but, if thats a big part of your work, you may be better >>>> off with linux + kvm or something else instead of qubes. >>> >>> damn nonlinear editing. that last sentence was supposed to go at the >>> end of the first paragraph. >> >> Well, the good news is that enabling vPro on a Dell is an extra option >> that you can select (costs $19), so I made sure that selection was off. >> Thanks for the heads up. >> >> The newer Xeon chips in the E5 Series no longer include on-board >> processor graphics, so Intel graphics isn't an option if I go this >> route. They can handle a lot more RAM (1.2TB vs. 64GB) and have more >> cores (10 vs. 4). There's generally a lot more I could do simultaneously >> with this chip it seems looking at the specs. >> >> Researching through these forums and even the Qubes Docs there seems to >> be a "stay away from nVidia" theme; That's why I was focusing on the AMD >> graphics card option. Is nVidia Quadro a viable option? >> >> Using the Dell configurator, and plugging in RedHat Linux 7.2 as the OS >> I find that the very newest AMD FirePro graphics card I selected isn't >> compatible. (I'm assuming RHEL 7.2 is a roughly equivalent to the Fedora >> 23 in dom0) So I dropped down to the older W5100 card and that seemed to >> work for them. >> >> The graphics aren't really a big part of my work. I just want a box that >> will be ready to run Qubes v4. >> > > Gaijin: Intel GPU is recommended, AMD are second best. > > IIRC, Dom0 will be based on Fedora 25 in Qubes 4.0. Try checking AMD's > site (https://support.amd.com/en-us/download) for compatibility reports, > too. Looking at the latest AMD FirePro drivers, they have versions that support RHEL and CentOS, so in turn can I assume one of those might support Fedora as well? They also seem to have a generic Linux driver for older OS versions. I do see a few AMD FirePro cards in the HCL that seem to be working, but not the specific one I'm looking at, so that's somewhat encouraging... -- 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/cacab804e80cbae717b779f5dc99681f%40riseup.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Best options for a 4.x compatible Dell workstation
On 2017-09-12 05:32, pixel fairy wrote: > On Monday, September 11, 2017 at 10:31:56 PM UTC-7, pixel fairy wrote: >> given that appvms cant use 3d acceleration anyway, your best bet is intel >> graphics. if your going to give a gpu to a vm, then it depends on the os of >> that vm. >> >> last i checked, nvidia is fine with virtualization of quadro cards. >> >> make sure the workstation doesnt have AMT (vpro etc) as bussiness lines tend >> to. you may be safer with what dell would otherwise sell as a consumer >> desktop or gaming rig, minus the fancy graphics card unless your going to >> use it. but, if thats a big part of your work, you may be better off with >> linux + kvm or something else instead of qubes. > > damn nonlinear editing. that last sentence was supposed to go at the > end of the first paragraph. Well, the good news is that enabling vPro on a Dell is an extra option that you can select (costs $19), so I made sure that selection was off. Thanks for the heads up. The newer Xeon chips in the E5 Series no longer include on-board processor graphics, so Intel graphics isn't an option if I go this route. They can handle a lot more RAM (1.2TB vs. 64GB) and have more cores (10 vs. 4). There's generally a lot more I could do simultaneously with this chip it seems looking at the specs. Researching through these forums and even the Qubes Docs there seems to be a "stay away from nVidia" theme; That's why I was focusing on the AMD graphics card option. Is nVidia Quadro a viable option? Using the Dell configurator, and plugging in RedHat Linux 7.2 as the OS I find that the very newest AMD FirePro graphics card I selected isn't compatible. (I'm assuming RHEL 7.2 is a roughly equivalent to the Fedora 23 in dom0) So I dropped down to the older W5100 card and that seemed to work for them. The graphics aren't really a big part of my work. I just want a box that will be ready to run Qubes v4. -- 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/47474469fc53f6c87fec3a43c44b9863%40riseup.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Best options for a 4.x compatible Dell workstation
On 2017-09-11 10:17, taii...@gmx.com wrote: > On 09/11/2017 05:45 AM, Gaijin wrote: > >> My company forces me to only buy Dell hardware. They're OK with me >> running Qubes on my next workstation, but I'm a bit unsure about what >> hardware options to choose, and would appreciate any advice. > That's pretty lame you can't build your own and get a real mans > computer - one that is owner controlled (ex: talos2, kcma-d8/kgpe-d16) >> Being uncertain of the Qubes 4.x requirements more than a year ago I put >> in a request for a Dell Precision T5810 workstation with: >> CPU: Xeon E5-2630 v4 (10 cores) >> RAM: 64GB 2400MHz DDR4 RDIMM ECC RAM >> Graphics: AMD FirePro W7100 >> >> However, looking at the 4.x requirements page and some forum threads, it >> doesn't sound like AMD graphics cards are very Qubes-friendly. My only >> other option at this product level is an nVidia Quadro (or AMD Radeon). > Nonsense, as with any linux video driver issue it depends on how new > the hardware is. > The professional series card means you can contact AMD for skilled > tech support, I would also get Dell's ProSupport so that you can get > an american on the phone. > > Nvidia is unfriendly to open source and virtualization (on their > consumer devices) even more than AMD these days so I wouldn't, I for > one dislike recompiling the kernel every time I update an nvidia > computer running linux. >> I'd like to know if this looks like a good setup to proceed with, or if >> I should consider something else (within the Dell lineup/options). >> >> If I wanted to get a Xeon chip with the built-in Intel Graphics built in >> I could look at the Precision 3000 series where they offer machines with >> a Xeon E3-1275 with only 4 cores, and a maximum of 64GB RAM. Only >> problem there is that I run a lot of simultaneous Qubes, including >> Windows, so I was concerned that I couldn't expand the RAM on this >> machine in the future if necessary. I'll be stuck with this machine >> quite a while, so I wanted to make the most of this purchase. > 64gb is fine, if you want to save your (their?) money. Yeah, I suggested some other hardware, but they wouldn't budge on that point, so I have to make do with Dell. I'll have to save the good stuff for the home build... So you think I could get away with the AMD graphics card and the E5 Xeon setup? Or will I be saving myself a lot of hassle by going with the integrated Intel graphics on the slightly lower end processor? Part of my motivation here is to hopefully have Qubes up and running on this machine without too much hassle...like recompiling kernels or spending tons of time with 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 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/e81f4f03f5c9193f12ebe2eb7a114d5f%40riseup.net. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Best options for a 4.x compatible Dell workstation
My company forces me to only buy Dell hardware. They're OK with me running Qubes on my next workstation, but I'm a bit unsure about what hardware options to choose, and would appreciate any advice. Being uncertain of the Qubes 4.x requirements more than a year ago I put in a request for a Dell Precision T5810 workstation with: CPU: Xeon E5-2630 v4 (10 cores) RAM: 64GB 2400MHz DDR4 RDIMM ECC RAM Graphics: AMD FirePro W7100 However, looking at the 4.x requirements page and some forum threads, it doesn't sound like AMD graphics cards are very Qubes-friendly. My only other option at this product level is an nVidia Quadro (or AMD Radeon). I'd like to know if this looks like a good setup to proceed with, or if I should consider something else (within the Dell lineup/options). If I wanted to get a Xeon chip with the built-in Intel Graphics built in I could look at the Precision 3000 series where they offer machines with a Xeon E3-1275 with only 4 cores, and a maximum of 64GB RAM. Only problem there is that I run a lot of simultaneous Qubes, including Windows, so I was concerned that I couldn't expand the RAM on this machine in the future if necessary. I'll be stuck with this machine quite a while, so I wanted to make the most of this purchase. Should I stick with my original configuration, or would you suggest other options? I really want a machine that will be 4.x compatible, that would have the least potential hardware issues. I'm not doing video editing or gaming, but I run a lot of VMs at the same time that might be memory hungry. -- 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/758ab18f99365c9f2d4b5b8317d17b63%40riseup.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Fedora 25 TemplateVM upgrade fails
On 2017-08-03 12:03, Gaijin wrote: > I was upgrading some R3.2 templates from Fedora 24 to 25, and in one > TemplateVM I keep getting an error after the distro-sync step of the > upgrade. After accepting a bunch of keys the install fails with: > > Public key for rpmfusion-free-appstream-data-25-3.fc25.noarch.rpm is not > installed > Failing package is rpmfusion-free-appstream-data-25-3.fc25.noarch > GPG Keys are configured as: > file:///etc/pki/rpm-gpg/RPM-GPG-KEY-rpmfusion-free-fedora-25 > > How do I get the right key in here so that I can continue with the > upgrade? I was able to work around this by disabling the GPG check sudo dnf --releasever=25 distro-sync --nogpgcheck -- 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/ff9a3f2c7b2f4093650be5f9413ff4c8%40riseup.net. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Fedora 25 TemplateVM upgrade fails
I was upgrading some R3.2 templates from Fedora 24 to 25, and in one TemplateVM I keep getting an error after the distro-sync step of the upgrade. After accepting a bunch of keys the install fails with: Public key for rpmfusion-free-appstream-data-25-3.fc25.noarch.rpm is not installed Failing package is rpmfusion-free-appstream-data-25-3.fc25.noarch GPG Keys are configured as: file:///etc/pki/rpm-gpg/RPM-GPG-KEY-rpmfusion-free-fedora-25 How do I get the right key in here so that I can continue with the upgrade? -- 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/c791f5234075f4fbcf10bc59a19460fd%40riseup.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] VPN gateway using iptables and CLI scripts fails
On 2017-07-10 18:32, Chris Laprise wrote: > On 07/10/2017 09:28 AM, Gaijin wrote: >> On 2017-07-10 02:40, Chris Laprise wrote: >>> On 07/09/2017 05:35 PM, Gaijin wrote: >>>> I've been trying to setup my VPN using the instructions here: Set up a >>>> ProxyVM as a VPN gateway using iptables and CLI scripts >>>> https://www.qubes-os.org/doc/vpn/ >>>> >>>> I can get the VPN to work in the terminal using an openvpn config. After >>>> adding the DNS-handling script and firewall script the VPN fails to >>>> connect. I get several errors: >>>> >>>> write UDPv4: Operation not permitted (code=1) >>>> >>>> Then the socket is closed and the script tries to connect again. It will >>>> keep trying until I kill it. >>>> >>>> I've tried to recreate several ProxyVMs, copying and pasting the >>>> settings from the Qubes Docs. The result has been the same. I'm >>>> wondering if anyone else has run into this or how I might work around >>>> it. >>> >>> In the firewall script you can try changing the output policy from: >>> iptables -P OUTPUT DROP >>> >>> to: >>> iptables -P OUTPUT ACCEPT >>> >>> This will relax the rules a bit without negatively affecting the leak >>> protection for connected appVMs. >>> >>> -- >>> >>> Chris Laprise, tas...@openmailbox.org >>> https://twitter.com/ttaskett >>> PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886 >> >> That got things moving. Thanks. It worked on the first try but I tried >> rebooting a few times to try to get the LINK IS UP part of the routine >> to work. I couldn't get that working and then the connection stopped >> working altogether. I reverted to the original DROP, and the VPN still >> worked. >> >> I just can't get the LINK IS UP/DOWN part to show. Running OpenVPN from >> the CLI I can see that the 'up' seems to be being passed. The script is >> executable, but it doesn't seem to be showing when it's run. >> > > The notifications use 'notify-send' so that needs to be working > correctly in your chosen template. Indeed, that doesn't seem to be working. I was using the Fedora minimal template with the notification-daemon added. It also has libnotify installed. However neither the template or AppVMs based on it show anything from a notify-send "test". Is there anything else I could add to this minimal template to get notifications working? -- 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/e8d542303e31aab3966ac8aec940f55d%40riseup.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] VPN gateway using iptables and CLI scripts fails
On 2017-07-10 02:40, Chris Laprise wrote: > On 07/09/2017 05:35 PM, Gaijin wrote: >> I've been trying to setup my VPN using the instructions here: Set up a >> ProxyVM as a VPN gateway using iptables and CLI scripts >> https://www.qubes-os.org/doc/vpn/ >> >> I can get the VPN to work in the terminal using an openvpn config. After >> adding the DNS-handling script and firewall script the VPN fails to >> connect. I get several errors: >> >> write UDPv4: Operation not permitted (code=1) >> >> Then the socket is closed and the script tries to connect again. It will >> keep trying until I kill it. >> >> I've tried to recreate several ProxyVMs, copying and pasting the >> settings from the Qubes Docs. The result has been the same. I'm >> wondering if anyone else has run into this or how I might work around >> it. > > In the firewall script you can try changing the output policy from: > iptables -P OUTPUT DROP > > to: > iptables -P OUTPUT ACCEPT > > This will relax the rules a bit without negatively affecting the leak > protection for connected appVMs. > > -- > > Chris Laprise, tas...@openmailbox.org > https://twitter.com/ttaskett > PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886 That got things moving. Thanks. It worked on the first try but I tried rebooting a few times to try to get the LINK IS UP part of the routine to work. I couldn't get that working and then the connection stopped working altogether. I reverted to the original DROP, and the VPN still worked. I just can't get the LINK IS UP/DOWN part to show. Running OpenVPN from the CLI I can see that the 'up' seems to be being passed. The script is executable, but it doesn't seem to be showing when it's run. -- 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/9b3252d256171f3b4fb20a2ee8254d79%40riseup.net. For more options, visit https://groups.google.com/d/optout.
[qubes-users] VPN gateway using iptables and CLI scripts fails
I've been trying to setup my VPN using the instructions here: Set up a ProxyVM as a VPN gateway using iptables and CLI scripts https://www.qubes-os.org/doc/vpn/ I can get the VPN to work in the terminal using an openvpn config. After adding the DNS-handling script and firewall script the VPN fails to connect. I get several errors: write UDPv4: Operation not permitted (code=1) Then the socket is closed and the script tries to connect again. It will keep trying until I kill it. I've tried to recreate several ProxyVMs, copying and pasting the settings from the Qubes Docs. The result has been the same. I'm wondering if anyone else has run into this or how I might work around it. -- 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/9f68716125ed724061823f4b9f5174b2%40riseup.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: All audio on streaming video out of sync
On 2017-01-18 16:23, raahe...@gmail.com wrote: On Wednesday, January 18, 2017 at 12:44:28 AM UTC-5, Gaijin wrote: On 2017-01-18 04:35, raahe...@gmail.com wrote: > On Friday, January 13, 2017 at 9:03:03 PM UTC-5, Gaijin wrote: >> All of the audio for videos played on my AppVMs, regardless of what >> template it's based on (Fedora 24/Debian 8), or what browser I try >> (Firefox/Chrome/Vivaldi), is completely out of sync. It's not just >> YouTube, but Vimeo, self-hosted, etc. >> >> I tried uncommenting audio_low_latency in /etc/qubes/quid.conf in dom0 >> That didn't fix things. >> I tried playing with the realtime-priority in /etc/pulse/daemon.conf >> That didn't seem to make any difference. >> >> Are there any other places where I could try to fix this latency >> issue? >> I assume it's dom0 as everything is affected. > > whats your pc specs/ what soundcard? I'm running Qubes R3.2 Sound is going through an nVidia GeForce GTX 560 Ti card. I don't have nVidia drivers installed. This machine has an Intel Core i7 2600 @ 3.40GHz CPU and 16.0GB Dual-Channel DDR3 @ 665MHz RAM. How are you plugging it in? HDMI? if so you got further then I did. I dont' get sound from hdmi only video. Why not just use the onboard sound card? Oops I was going off an old hardware report from when this machine ran Windows. Got under the desk to check, and sound is going through the motherboard: ASRock H67DE It operates fine usually, and never showed this sort of issue from Qubes 1.x-3.1. When I upgraded to Qubes 3.2 I started noticing this lag. I don't watch a lot of video so it took me a while to notice. -- 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/43684ac057443991e3efc1564ea148f1%40riseup.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: All audio on streaming video out of sync
On 2017-01-18 04:35, raahe...@gmail.com wrote: On Friday, January 13, 2017 at 9:03:03 PM UTC-5, Gaijin wrote: All of the audio for videos played on my AppVMs, regardless of what template it's based on (Fedora 24/Debian 8), or what browser I try (Firefox/Chrome/Vivaldi), is completely out of sync. It's not just YouTube, but Vimeo, self-hosted, etc. I tried uncommenting audio_low_latency in /etc/qubes/quid.conf in dom0 That didn't fix things. I tried playing with the realtime-priority in /etc/pulse/daemon.conf That didn't seem to make any difference. Are there any other places where I could try to fix this latency issue? I assume it's dom0 as everything is affected. whats your pc specs/ what soundcard? I'm running Qubes R3.2 Sound is going through an nVidia GeForce GTX 560 Ti card. I don't have nVidia drivers installed. This machine has an Intel Core i7 2600 @ 3.40GHz CPU and 16.0GB Dual-Channel DDR3 @ 665MHz RAM. -- 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/416a77940bd147af377bc319b9ffcd43%40riseup.net. For more options, visit https://groups.google.com/d/optout.
[qubes-users] All audio on streaming video out of sync
All of the audio for videos played on my AppVMs, regardless of what template it's based on (Fedora 24/Debian 8), or what browser I try (Firefox/Chrome/Vivaldi), is completely out of sync. It's not just YouTube, but Vimeo, self-hosted, etc. I tried uncommenting audio_low_latency in /etc/qubes/quid.conf in dom0 That didn't fix things. I tried playing with the realtime-priority in /etc/pulse/daemon.conf That didn't seem to make any difference. Are there any other places where I could try to fix this latency issue? I assume it's dom0 as everything is affected. -- 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/9bbee48082174f3e6c8cb2d58a1218a3%40riseup.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] How to update fedora-23-dvm to fedora-24?
On 2016-11-21 13:28, Marek Marczykowski-Górecki wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Mon, Nov 21, 2016 at 05:18:39AM -0800, Opal Raava wrote: Hi, I updated everything to fedora-24 template, but I don't know how to update fedora-23-dvm. It uses the old fedora-23 template and when i change this in the manager to use fedora-24, it says making save file but then no browser or terminal runs. What is the best way to update fedora-23-dvm? Simply don't - instead use fedora-24-dvm. To create (and use it), call: qubes-create-default-dvm fedora-24 - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJYMvZxAAoJENuP0xzK19cs1cEH/j9ZXhBfSSjT07qnVudMn6Wi OR1GG6jOPqb2n1LVAcn7CZmIl4bn/VfUdpObOixLXC5bLrG0DqZVBmQoG8SgAeWi 8VH1u6nej1RDJSAhNARpTeNinOD7qeZIkPsrwP7wzt32/tFzGZ8B1nXyQoaR2gO5 aE5i6V6GUpFfmFEgpwpHR7kI1OOSfjU6hSIJ5zHpN8VoHTLFKtT4qkwQRq7FFYpu WyF5otpshGAftCFFFyaxh8aHs+4oXjwYiJ3S0o+9QrYqHbt1haeQcv6dxL+QNjHs 0FONzkPJUafrOI0Amy6dcYvve1OGMg4RL3zPKIz+ZZWTH6VgbydrHErSDZ5w6yE= =L8z6 -END PGP SIGNATURE- According to https://www.qubes-os.org/doc/dispvm-customization/ that should be: qvm-create-default-dvm fedora-24 -- 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/722765965895733dce69e284d15c3848%40riseup.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Fedora 24 template available for Qubes 3.2
On 2016-11-14 23:57, Marek Marczykowski-Górecki wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Mon, Nov 14, 2016 at 11:14:19PM +, Gaijin wrote: systemctl doesn't show anything abnormal systemctl --all shows several not found inactive dead listings ex. livesys.service ntpd.service qubes-core.service qubes-dvm.service qubes-firewall.service qubes-iptables.service qubes-misc-post.service qubes-mount-dirs.service qubes-mount-home.service qubes-netwatcher.service qubes-network.service qubes-qmemman.service qubes-qrexec.service qubes-random-seed.service qubes-sysinit.service qubes-updates-proxy.service sntp.service syslog.service ypbind.service sys-log.service qubes-update-check.service Uhm, it looks like you've uninstalled qubes tools in the process... If you still have qubes repository definition in /etc/yum.repos.d/qubes-r3.repo, you can try to reinstall it: sudo dnf install qubes-core-vm-systemd It should show you what conflicts with this package (if anything). If you don't have repository definition anymore, you'll need to create it first. It should look like this: [qubes-vm-r3.2-current] name = Qubes OS Repository for VM (updates) baseurl = http://yum.qubes-os.org/r3.2/current/vm/fc$releasever gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-qubes-3-primary skip_if_unavailable=False gpgcheck = 1 enabled=1 [qubes-vm-r3.2-current-testing] name = Qubes OS Repository for VM (updates-testing) baseurl = http://yum.qubes-os.org/r3.2/current-testing/vm/fc$releasever gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-qubes-3-primary skip_if_unavailable=False gpgcheck = 1 enabled=0 [qubes-vm-r3.2-security-testing] name = Qubes OS Repository for VM (security-testing) baseurl = http://yum.qubes-os.org/r3.2/security-testing/vm/fc$releasever gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-qubes-3-primary skip_if_unavailable=False gpgcheck = 1 enabled=0 [qubes-vm-r3.2-unstable] name = Qubes OS Repository for VM (unstable) baseurl = http://yum.qubes-os.org/r3.2/unstable/vm/fc$releasever gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-qubes-3-unstable gpgcheck = 1 enabled=0 You can save some typing by using only the first section (it is enough for recovery) - save it in some other file there, like /etc/yum.repos.d/qubes-recovery.repo. You'll also need to configure network manually (as you no longer have a script which did that for you) - take a look here (procedure is very similar): https://www.qubes-os.org/doc/upgrade-to-r3.0/#upgrading-template-on-already-upgraded-dom0 - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJYKk+BAAoJENuP0xzK19cs7fsH/AlhudAV3YMj8xcHlq2qON9h AttdZrrbtO5GA796EP8iLhDpN1b6iV0NMIh2Wbyhxuk6+Wijs6751iJ7F3fKtldA eh9NJrssHVtgcEWMHfKmflerYWWgPUwqHztTA4vNWXxM7b4uyjxphDzSzvQpNblX W5C8QKxNhdqYLmf2n4X9FmX4hG09q4CMVwqfwk2T0T9reyv6Hbqlkj68e0sKL1Ig w4mF/gZqgDHKcHz6YDB0yJzIk0lop7mztBMYA8Dj4WSnGoVtDlPrCepffSCFogOC xfP9s0GnIjP+z7yTqSlPqpvd/PH8OsAH7Pvn1Hb8z+071SXazm0YhA95WgRecqI= =wEUi -END PGP SIGNATURE- Thanks Marek. Your advice got me pointed in the right direction. My Fedora-23 templates with software installed were still using the repository definition for R3.1, so I tried the --allowerase on the distro-sync step, and subsequently removed Qubes. (my bad) Someone may want to add your suggestion to make sure the repository definition is up-to-date to the upgrade documentation. Updating those R3.2 repository definitions in /etc/yum.repos.d/qubes-r3.repo solved my upgrade issue. I had not thought to check there. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/05b07292527c3cf54c163691a0aecf6a%40riseup.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Fedora 24 template available for Qubes 3.2
On 2016-11-14 06:42, Gaijin wrote: On 2016-11-13 23:33, Marek Marczykowski-Górecki wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Sun, Nov 13, 2016 at 11:12:34PM +, Gaijin wrote: I have several templates based on Fedora 23 where I've installed various software. When I follow the manual upgrade instructions the update proceeds without error. However, when I get to the step were I am supposed to trim the newly upgraded templates I get an error. ... File "/usr/lib64/python2.7/site-packages/qubes/modules/000QubesVm.py", line 1854, in start_quexec_daemon raise OSError ("Cannot execute qrexec-daemon!") I cannot open a terminal in these templates, nor can I base AppVMs on them. I just get the qrexec-daemon error. You can access its console using `sudo xl console fedora-24`. Look for some failed service startup messages. You can login as root without password to perform further investigation - like call `systemctl` or `journalctl -b`. My Fedora 24 template works fine. I guess you've meant 23 here? Otherwise, what's the problem? - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJYKPgwAAoJENuP0xzK19csGVMIAJdJDwXaWHXsOqvFnsvt7c32 eogiGZ50ju+1Xcl67qCLuX9mOQHQYDOhUWOMaAfa79R4F98hIWhF4LaotxxM2RUr UIBVq/4tX3mx3DNZQUXGx+91J1S2/wPJ5YGUQhJio7MTUn+OTX7qyu4u5aDnt/jx QHuZfqE+aI0micLn/8KWV1OyPNcMrOZjWqrEdOSb2Fu5JxXkD+KznZ1DKIZJ9G57 BFDe7Fp8n3yyah4wnjQYe/BkvOoZf2lKzdt4ls4ATowwAHpQibtZkks1y+Q39ZdR K9oGbh7UNtMRDSJTxQx7+C65+6Cf+m/ek1kDu5Qv+D4blip7ggb8zEE1JAlCxzM= =wAc/ -END PGP SIGNATURE- I guess you've meant 23 here? Otherwise, what's the problem? No, I meant the updated fedora-24 template. Updating the fedora-23 template, which I haven't made changes to, to fedora-24 works fine. No update errors. No trim errors. It updated and works fine with Fedora 24 following the manual update instructions. I switched my AppVMs that used fedora-23 to use this new template and I don't see any issues. All of my other Fedora 23 templates, where I had added different software, they are the ones that failed at the "trim" stage of the manual upgrade process. None of those are functioning now. I haven't had a chance to try checking for failed service startup messages yet as I don't have access to the machine right now, but will report back. systemctl doesn't show anything abnormal systemctl --all shows several not found inactive dead listings ex. livesys.service ntpd.service qubes-core.service qubes-dvm.service qubes-firewall.service qubes-iptables.service qubes-misc-post.service qubes-mount-dirs.service qubes-mount-home.service qubes-netwatcher.service qubes-network.service qubes-qmemman.service qubes-qrexec.service qubes-random-seed.service qubes-sysinit.service qubes-updates-proxy.service sntp.service syslog.service ypbind.service sys-log.service qubes-update-check.service -- 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/3986ad734b085a6bef8bac4d5bf566a2%40riseup.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Fedora 24 template available for Qubes 3.2
On 2016-11-13 23:33, Marek Marczykowski-Górecki wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 On Sun, Nov 13, 2016 at 11:12:34PM +, Gaijin wrote: I have several templates based on Fedora 23 where I've installed various software. When I follow the manual upgrade instructions the update proceeds without error. However, when I get to the step were I am supposed to trim the newly upgraded templates I get an error. ... File "/usr/lib64/python2.7/site-packages/qubes/modules/000QubesVm.py", line 1854, in start_quexec_daemon raise OSError ("Cannot execute qrexec-daemon!") I cannot open a terminal in these templates, nor can I base AppVMs on them. I just get the qrexec-daemon error. You can access its console using `sudo xl console fedora-24`. Look for some failed service startup messages. You can login as root without password to perform further investigation - like call `systemctl` or `journalctl -b`. My Fedora 24 template works fine. I guess you've meant 23 here? Otherwise, what's the problem? - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJYKPgwAAoJENuP0xzK19csGVMIAJdJDwXaWHXsOqvFnsvt7c32 eogiGZ50ju+1Xcl67qCLuX9mOQHQYDOhUWOMaAfa79R4F98hIWhF4LaotxxM2RUr UIBVq/4tX3mx3DNZQUXGx+91J1S2/wPJ5YGUQhJio7MTUn+OTX7qyu4u5aDnt/jx QHuZfqE+aI0micLn/8KWV1OyPNcMrOZjWqrEdOSb2Fu5JxXkD+KznZ1DKIZJ9G57 BFDe7Fp8n3yyah4wnjQYe/BkvOoZf2lKzdt4ls4ATowwAHpQibtZkks1y+Q39ZdR K9oGbh7UNtMRDSJTxQx7+C65+6Cf+m/ek1kDu5Qv+D4blip7ggb8zEE1JAlCxzM= =wAc/ -END PGP SIGNATURE- I guess you've meant 23 here? Otherwise, what's the problem? No, I meant the updated fedora-24 template. Updating the fedora-23 template, which I haven't made changes to, to fedora-24 works fine. No update errors. No trim errors. It updated and works fine with Fedora 24 following the manual update instructions. I switched my AppVMs that used fedora-23 to use this new template and I don't see any issues. All of my other Fedora 23 templates, where I had added different software, they are the ones that failed at the "trim" stage of the manual upgrade process. None of those are functioning now. I haven't had a chance to try checking for failed service startup messages yet as I don't have access to the machine right now, but will report back. -- 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/ae12c9baa64b9c182396c72773d9fd1d%40riseup.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Fedora 24 template available for Qubes 3.2
On 2016-11-13 03:52, Marek Marczykowski-Górecki wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Hi all, Fedora 24 template is now available for direct installation. This means there are now two ways to have it on Qubes 3.2 system: 1. Upgrade existing Fedora 23 template according to this instruction: https://www.qubes-os.org/doc/fedora-template-upgrade-23/ 2. Install a fresh one using: qubes-dom0-update qubes-template-fedora-24 The later option will get you fresh template. If you made any modifications there, you'll need to do them again (if you want). The same is available for fedora-24-minimal template. In any case, after getting new template using any method, the next step is switching some/all qubes (VMs) to the new one. This can be done using either Qubes Manager (in qube settings), or using qvm-prefs command line tool. - -- Best Regards, Marek Marczykowski-Górecki Invisible Things Lab A: Because it messes up the order in which people normally read text. Q: Why is top-posting such a bad thing? -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQEcBAEBCAAGBQJYJ+OXAAoJENuP0xzK19csWa8H/RqO4RjNVeeIEb7s8KRgUMzg VjQUOrC5YmirnFACrq7t8VDZxbcvSrQ88pifMsIKZYzAzfIHa2s3O6m9XzkDetQO +of7iUIQaijlec5BKkCGM+3cP3zQSHyrCdb6udOEzYkkSLkeWaYoC6+F/dPrFLVx 1Wb2pNeUY0eWGuL64/WjpozpUGXKtD1tp1RbFv7cqVdF530THVXX+W7g3fp6zmUS k4goQv0rjhdlhWr9ZYwvlUbGRMpJHaIix4Q4ajXNToVnql69fZxGhhSOtPwBasGe j4TIbyTKr01a0mQn6mIa+MKkS19H8RwLpu+25EaOlmd2f91vVO8IJrPBSmwvZ84= =+DPm -END PGP SIGNATURE- I have several templates based on Fedora 23 where I've installed various software. When I follow the manual upgrade instructions the update proceeds without error. However, when I get to the step were I am supposed to trim the newly upgraded templates I get an error. ... File "/usr/lib64/python2.7/site-packages/qubes/modules/000QubesVm.py", line 1854, in start_quexec_daemon raise OSError ("Cannot execute qrexec-daemon!") I cannot open a terminal in these templates, nor can I base AppVMs on them. I just get the qrexec-daemon error. My Fedora 24 template works fine. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/2ab97c2ba52204bc3cd3babc8855460b%40riseup.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] XScreenSaver for dom0 pops up
On 2016-10-27 04:42, Andrew David Wong wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA512 On 2016-10-26 15:53, Gaijin wrote: On 2016-10-26 13:38, John Maher wrote: On Wednesday, October 26, 2016 at 9:05:48 AM UTC-4, Gaijin wrote: On 2016-10-26 12:43, John Maher wrote: > I'm getting the strangest thing on my screen. I'll be working and the > XScreenSaver dialog pops up (indicating the screen is locked) and the > screen goes black. However, the screen is not locked. I have to move a > window around to redraw my screen. This has always happened since I > started using Qubes about 3 weeks ago. There appears to be no pattern > that prompts this response. Bizarre! Any thoughts? > > Thanks. > > John Yeah. I had the same thing happen when I upgraded to R3.2 as well. I asked the same thing but nobody replied. https://groups.google.com/forum/#!topic/qubes-users/xjHi2TcYBAQ It still happens from time to time. Seems to happen less if I have a lot of free memory. Closing down some memory hungry AppVMs seems to lessen it, but I haven't been able to specifically replicate it. Interesting, because I think I have more than enough memory (32 GB). Thanks. I've got 16GB myself. It's not that the memory is full, but it seems to happen more when I have a lot of VMs open in one desktop. That may just be a coincidence though. I'm glad to see it wasn't just me though. I never had this happen with earlier versions of Qubes on the same hardware. Not sure if it might be the XFCE or a video driver issue. (I've never installed the nVidia drivers.) Thank you both for reporting this. Gaijin, I'm sorry I missed your thread. Just to confirm: Are you both using Xfce4? Tracking the issue here: https://github.com/QubesOS/qubes-issues/issues/2399 - -- Andrew David Wong (Axon) Community Manager, Qubes OS https://www.qubes-os.org -BEGIN PGP SIGNATURE- iQIcBAEBCgAGBQJYEYWaAAoJENtN07w5UDAwvq8P/1hFm/owsEasSXroxzK9JnTn DSBZ9udjO+TWQypb4Hh4RO48MtJnQhKfdgJJWWJwf9dTp62LUBkVWskKDtvOfyo+ aoVFGRBexb7yzRT90kBsjHiVPeysA4bTBftQZEZzTQBz/UzRzMkcBWj7/vbYrTkL zeG42ZCuM75jzOv2dhrG2TeP+OlTfdnFIyFQFmdaRJyHTOBtf7Mjauuj4gFEiKNr ztMO4jE/kn+/E79cGu33VfrxITmiH7Z5tqZQuAS0Mud9YnBuCDumIugPuSleV3IL xARHjYjui+yPOzB66yZiDlQhTMRaEhEEQVR6UWMU+SC/nec+dTpWq/b7EgktXdud NpJr+jIDfaoNdVBtDFIXRBo6vbR05dtWQFfLIeewGIhIC9VwLJSwEW2TvCTWFOcO kXWV4xsg1xAJNbNBm9V42yZ6M1P+ClXlAcJYPVqrk+xisLtlWAweqT4yKw3zq5HW rlgkLYoNAjU3ZvTHYa/2JtyQZKbUUw+ck8nRRuLUp0jqM/2TlZfQ7tmfsfb5z1HS mzNe6UHhg5ZtoV0HKbyMIWa5ePVZaMJCkhNOMAuAQ9QBpJgqE7dWZx28S5eqnAno WTFQI9nT6JCQz7YvmIkrxQDCUmG5JQqZlqIXArRS0WNjAzNMraKBsWeHTOqha4he HiI1LB04rOraNysdPTpj =MANy -END PGP SIGNATURE- I used the default install parameters of R3.2. xfce4-about in dom0 shows I'm using version 4.12. The same hardware since R2 has not experienced this. -- 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/96c98a10bb822b711c83816b3d189de3%40riseup.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] XScreenSaver for dom0 pops up
On 2016-10-26 13:38, John Maher wrote: On Wednesday, October 26, 2016 at 9:05:48 AM UTC-4, Gaijin wrote: On 2016-10-26 12:43, John Maher wrote: > I'm getting the strangest thing on my screen. I'll be working and the > XScreenSaver dialog pops up (indicating the screen is locked) and the > screen goes black. However, the screen is not locked. I have to move a > window around to redraw my screen. This has always happened since I > started using Qubes about 3 weeks ago. There appears to be no pattern > that prompts this response. Bizarre! Any thoughts? > > Thanks. > > John Yeah. I had the same thing happen when I upgraded to R3.2 as well. I asked the same thing but nobody replied. https://groups.google.com/forum/#!topic/qubes-users/xjHi2TcYBAQ It still happens from time to time. Seems to happen less if I have a lot of free memory. Closing down some memory hungry AppVMs seems to lessen it, but I haven't been able to specifically replicate it. Interesting, because I think I have more than enough memory (32 GB). Thanks. I've got 16GB myself. It's not that the memory is full, but it seems to happen more when I have a lot of VMs open in one desktop. That may just be a coincidence though. I'm glad to see it wasn't just me though. I never had this happen with earlier versions of Qubes on the same hardware. Not sure if it might be the XFCE or a video driver issue. (I've never installed the nVidia drivers.) -- 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/8bb317cfadfd29a9c609e91214b14a1a%40riseup.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] XScreenSaver for dom0 pops up
On 2016-10-26 12:43, John Maher wrote: I'm getting the strangest thing on my screen. I'll be working and the XScreenSaver dialog pops up (indicating the screen is locked) and the screen goes black. However, the screen is not locked. I have to move a window around to redraw my screen. This has always happened since I started using Qubes about 3 weeks ago. There appears to be no pattern that prompts this response. Bizarre! Any thoughts? Thanks. John Yeah. I had the same thing happen when I upgraded to R3.2 as well. I asked the same thing but nobody replied. https://groups.google.com/forum/#!topic/qubes-users/xjHi2TcYBAQ It still happens from time to time. Seems to happen less if I have a lot of free memory. Closing down some memory hungry AppVMs seems to lessen it, but I haven't been able to specifically replicate it. -- 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/170ec0c8b415b8073906994d80ddcc97%40riseup.net. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Qubes R32 screen blanking except active window
I'm encountering seemingly random screen blanking while I'm using Qubes 3.2 (updated from a fresh install of rc3). The screen will blank and momentarily show the logon. Yet if I move the mouse or use the keyboard only the active window will show. Changing desktops, clicking on other windows, or moving the active window around will redraw the rest of the screen. I never had this issue on this hardware with R3 or R3.1. I'm running dual monitors off an nVidia GTX 560 Ti. The screensaver is set to blank the screen and require a login. That's the screen that keeps popping up. Sometimes it gets so frequent that I need to reboot the system and the problem will go away for a while. -- 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/27d2778a7a55fce1625e0e26cfaff7a3%40riseup.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] lost sound in 3.2-rc3
On 2016-09-19 11:21, Gaijin wrote: Been running 3.2-rc3 and doing regular checks for updates of Qubes. Yesterday all was running fine in the sound department. Today, I can't get sound in any VM. The machine had been on for several days when this happened. Rebooting has not fixed the issue. Pulling up the dom0 audio mixer in XFCE seems to have the volume levels up and un-muted. I'm not sure where else to look to troubleshoot. The sound works fine if I boot to another OS on the same machine (DVD). The sound hardware seems to work. It's just Qubes affected. Apparently this is a somewhat common XFCE thing. Using the Alsa mixer widget won't work. Had to open use Q > System Tools > PulseAudio Volume Control. In the Playback tab all of my AppVMs had volume set to zero. I had to manually slide them all up to 100% to restore sound. I had never touched the PulseAudio settings previously, so I'm not sure what triggered this. Not sure if this warrants raising an Issue. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/0fe292b110d962208bb1d926b013729c%40riseup.net. For more options, visit https://groups.google.com/d/optout.
[qubes-users] lost sound in 3.2-rc3
Been running 3.2-rc3 and doing regular checks for updates of Qubes. Yesterday all was running fine in the sound department. Today, I can't get sound in any VM. The machine had been on for several days when this happened. Rebooting has not fixed the issue. Pulling up the dom0 audio mixer in XFCE seems to have the volume levels up and un-muted. I'm not sure where else to look to troubleshoot. The sound works fine if I boot to another OS on the same machine (DVD). The sound hardware seems to work. It's just Qubes affected. -- 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/718ebc928b826f0cd81ec7d1d7616a17%40riseup.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: App shortcuts in XFCE
On 2016-09-07 22:53, IX4 Svs wrote: On Tue, Sep 6, 2016 at 12:39 PM, Gaijin wrote: On 2016-09-05 00:57, Drew White wrote: On Sunday, 4 September 2016 11:50:21 UTC+10, Gaijin wrote: I just upgraded from 3.1 to 3.2R3 and was wondering of the best way to restore some of my App shortcuts. I use some portable apps and executables that don't show up in the Applications shortcuts. In KDE I was used to the Menu Editor. I'm not familiar with XFCE and didn't see a similar option. If you are talking about windows WITH QREXEC, then just add the shortcuts again. You can add them to the menu using KMENUEDIT, or many other ways Including copying the .desktop files to the new machine onto your desktop, or else into another folder and adding them directly to the menu system using kmenuedit or similar CLI interface. I am referring to the dropdown "Q" menu that lists your various VMs and the software in them. I was used to the KMENUEDIT in KDE. It was easy enough to make QREXEC shortcuts. The new R3.2 defaults to XFCE in a clean install. I didn't see a way to edit those menu items the same way. Sure I can add more shortcuts for programs that are installed and generate .desktop files. The problem I'm having is with the software or executables that don't show up in the shortcuts list. For example, portable apps; You don't install them you just run the .exe See https://groups.google.com/d/msg/qubes-users/rMMgeR-KLbU/SoR4fQwsBAAJ for an example of creating a "Qubes-proper" shortcut to an arbitrary file. That example points to a .desktop file inside an AppVM, but the target can be anything that the AppVM knows how to execute. Thanks! That's what I was looking for. A bit more work than the KDE, but looks like it would achieve the same result. I hope that one gets added to the Wiki. -- 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/7fd9df54708738a32f027bc64da8d9bf%40riseup.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: App shortcuts in XFCE
On 2016-09-05 00:57, Drew White wrote: On Sunday, 4 September 2016 11:50:21 UTC+10, Gaijin wrote: I just upgraded from 3.1 to 3.2R3 and was wondering of the best way to restore some of my App shortcuts. I use some portable apps and executables that don't show up in the Applications shortcuts. In KDE I was used to the Menu Editor. I'm not familiar with XFCE and didn't see a similar option. If you are talking about windows WITH QREXEC, then just add the shortcuts again. You can add them to the menu using KMENUEDIT, or many other ways Including copying the .desktop files to the new machine onto your desktop, or else into another folder and adding them directly to the menu system using kmenuedit or similar CLI interface. I am referring to the dropdown "Q" menu that lists your various VMs and the software in them. I was used to the KMENUEDIT in KDE. It was easy enough to make QREXEC shortcuts. The new R3.2 defaults to XFCE in a clean install. I didn't see a way to edit those menu items the same way. Sure I can add more shortcuts for programs that are installed and generate .desktop files. The problem I'm having is with the software or executables that don't show up in the shortcuts list. For example, portable apps; You don't install them you just run the .exe Is there a KMENUEDIT GUI equivalent in XFCE in Qubes to edit those menus? -- 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/8375554b9d68282034834883fa047f68%40riseup.net. For more options, visit https://groups.google.com/d/optout.
[qubes-users] App shortcuts in XFCE
I just upgraded from 3.1 to 3.2R3 and was wondering of the best way to restore some of my App shortcuts. I use some portable apps and executables that don't show up in the Applications shortcuts. In KDE I was used to the Menu Editor. I'm not familiar with XFCE and didn't see a similar option. -- 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/e3855f6a714c76534bfed8d66a42c802%40riseup.net. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: installing Signal on Qubes mini-HOWTO
On 2016-08-17 16:08, Chris Laprise wrote: On 08/17/2016 11:35 AM, johnyju...@sigaint.org wrote: On the Signal matter, just some personal paranoia Re: Signal and Google Play Services: I've been the subject of some rather intense and ongoing hacking (iPhone, iPad, Android phone/tablet, PC, MacBook, cable modem connection, you name it). On the Android phone, I wiped it several times, and switched to Cyanogen, but the "weirdness" kept coming back. (Seeing stuff being recorded, logged, queued to upload etc., when scrutinizing the filesystem with adb.) The issues often seemed to dance around Google Play Services. The problem kept coming back, until last time, when I wiped the phone yet again, but didn't install Google Play Store (and thus no Google Play Services). Things *appear* to be stable and secure now, with no logging/recording/uploading weirdness showing up on the filesystem. I'd like to install and use Signal for obvious reasons, but I honestly don't trust Google Store/Services enough to take the risk. (I have a psycho ex with some crooked cop buddies, so I half suspect some law enforcement/government hook might be present in Google Play Services. Speculation of course. But I'll personally stay clear for now. I'm not doing anything illegal, but with crooked cops it really doesn't matter much. :) ) I did get a copy of Signal from apkmirror, but I expect it might not work without Play Services, and I'm not sure it'd be smart to implicitly trust apkmirror, either. So I'll keep my SmartPhone as a DumbPhone for now. I was kind of excited to hear about Signal for Chromium, but disappointed to find it relied upon you also having it installed on your smartphone. Aand then there's this: http://arstechnica.com/security/2015/06/not-ok-google-chromium-voice-extension-pulled-after-spying-concerns/ Not cool, Google. Cheers. :) I have to say I don't understand the logic of tying an app like Signal to Google, meaning the user is attached to Google at the hip. Especially when an app like Ring.cx operates without a browser or even a server, which seems far less risky. Chris But Google just announced their end of support for Chrome apps on Windows, Mac, and Linux in early 2018. https://blog.chromium.org/2016/08/from-chrome-apps-to-web.html Won't that kill the Signal app? -- 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/88da137bb3ef7a3567603e0d42dd3d87%40riseup.net. For more options, visit https://groups.google.com/d/optout.