Re: [qubes-users] Re: Qubes 4 boot ISO
> > How are you making the boot device? 1. Whenever there is a problem getting for example a USB stick to boot/behave as a Read-Only boot device from an ISO file, I use either Unetbootin or the Linux dd command line tool to make the USB stick into a bootable Read-Only ISO device. That normally works. 2. Sometimes the safest bet is also to use BIOS Legacy Mode (disable the BIOS secure boot function + enable the BIOS CSM legacy mode). 3. If an otherwise properly made USB stick still does not boot, there are also some BIOS systems that oddly places the recognised USB stick "inside" the list of bootable Hard Drives. Read: AS a Hard Drive, as if you now have more than your normal 1+ HDDs... In those cases, you need to enter into the hard drive menu option, change the order so that the USB stick is the first, and then go back and also place it before the hard drive in the main Boot order menu (in these cases there are 2 places to do this, and you must place it first in both those lists...) 4. Then there is the not-too-rare situation where a particular system/computer is incompatible with a particular USB stick, so it does not boot it even if another computer does. Change to another USB stick model/make and try that one. 5. And in some cases, it still fails even if all has been done properly, and all pieces are technically ready, IF you exit the BIOS when saving the last changes with the normal direct "exit-and-save-and-reboot" option. Sometimes you actually have to then power off completely right after it has rebooted (as long as the BIOS changes are actually saved), remove and re-insert the USB stick and then power the computer back on. Strange, but that also happens. (And add to any possible confusion that yet again some systems seems to alter the boot order (or have forgotten your saved changes) when you get back into the BIOS after having physically removed the USB key, or tried to boot/replace it with another USB key. Sometimes that is only an unsaved suggestion that happens when you re-enter the BIOS. Your saved order might still actually be in place as long as you boot from that particular USB stick you used when saving the BIOS changes the last time.) -- Regards, Teqleez -- 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/1524894556.75676.1353643704.2B881B3C%40webmail.messagingengine.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] NTP and/or clock issue
On 04/27/2018 11:20 PM, Matthew Wyenandt wrote: > On Friday, April 27, 2018 at 3:32:44 PM UTC-4, Ivan Mitev wrote: >> On 04/27/2018 09:34 PM, Matthew Wyenandt wrote: >>> On Friday, April 27, 2018 at 10:46:34 AM UTC-5, Ivan Mitev wrote: Hey, On 04/27/2018 06:12 PM, Matthew Wyenandt wrote: > Hi all, > > I'm new to Qubes 4.0 and loving it. I'm having an odd situation where > the time on my clock is showing -5 from my current timezone, rather than > -5 from UTC. For instance, I'm physically located in America/Chicago > timezone, which is -5 UTC. My Qubes OS clock is set for America/Chicago > timezone, which also says -5 UTC; however, the clock is now showing -10 > UTC. I've tried to figure out a way to manipulate the clock within dom0, > but I'm not finding anyway to do so. your hw clock is likely set to local time instead of UTC ; this usually happens because you use(d) MS Windows. `hwclock` allows you to tweak the hardware clock; you can manually set the time and then run `hwclock --systohc --utc`, that should fix your problem. Note that `qvm-sync-clock` is run every hour in dom0 and should fix the offset automatically: it first syncs dom0's time with the time in "clockvm" (usually sys-net, see the output of `qubes-prefs clockvm`) and it then runs `hwclock --systohc`. If you still have issues, check that the timezone and time are OK in sys-net (or whatever clockvm you have defined). >>> >>> Thanks for this info, Ivan. I followed these steps. Should my sys-net >>> clock be set for UTC? When I run hwclock --show, it's still showing EDT as >>> the current time. Do I need to set this manually? I would prefer that it >>> get updated via ntp. >> >> The clockVM's clock is synchronized with NTP, you don't need to set >> anything manually... >> >> Clock synchronization works like that (if I'm not mistaken): >> >> 1- when a VM boots, the `/usr/lib/qubes/init/qubes-early-vm-config.sh` >> script sets the VM's timezone (the script gets the timezone from dom0 >> with `qubesdb-read /qubes-timezone`). >> >> 2a- if the VM is defined as the clockVM (sys-net by default) then the >> `systemd-timesyncd` service synchronizes the VM's clock with NTP. >> >> 2b- for dom0 and VMs != clockVM, the `qubes-sync-time.timer` systemd >> timer runs the `qvm-sync-clock` every 6 hours to (re)sync the clock with >> the time in clockVM (sys-net). >> >> >> So make sure your timezone is OK in dom0: `ls -l /etc/localtime` should >> point to the right timezone (eg. /usr/share/zoneinfo/America/Chicago). >> Then the easiest way is to perform a *full* reboot and everything should >> be fine. >> >> >> If it isn't, you'll have to debug a bit further: >> >> - make sure the timezone is OK in VMs too (again with `ls -l >> /etc/localtime`). If it isn't, check what `qubesdb-read /qubes-timezone` >> returns: it should be the same as dom0's timezone. >> >> - in sys-net, run `systemctl restart systemd-timesyncd` ; `systemctl >> status systemd-timesyncd` should output a line like >> >> Status: "Synchronized to time server a.b.c.d:123 (0.fedora.pool.ntp.org)." >> >> the clock in sys-net should show the right time (both `date` and `sudo >> hwclock` should show the same time, with the EDT format). >> >> - in dom0 and other VMs != clockVM, run `sudo qvm-sync-clock` ; the time >> should then be OK. >> >> >> Hope this helps ! > > Okay, so something doesn't seem to be configured correctly. During further > debugging, i was able to get the correct timezone using 'timedatectl > set-timezone Americas/Chicago'. However, when running 'systemctl status > systemd-timesyncd' I get the following output: > > systemd-timesyncd.service - Network Time Synchronization >Loaded: loaded (/usr/lib/systemd/system/systemd-timesyncd.service; > enabled; v > Drop-In: /usr/lib/systemd/system/systemd-timesyncd.service.d >└─30_qubes.conf >Active: inactive (dead) > Condition: start condition failed at Fri 2018-04-27 10:04:54 CDT; 4s ago >└─ ConditionPathExists=/var/run/qubes-service/clocksync was not met > Docs: man:systemd-timesyncd.service(8) > > It seems the clocksync file is missing from /var/run/qubes-service/ directory. If the output above is for your clockVM (sys-net) then something isn't right. Otherwise that's the standard output for other VMs: /var/run/qubes-service/clocksync is set only in the clockVM I'm afraid I can't help more than that - maybe someone more experienced will chime in, otherwise you should file an issue. just in case, please paste the output of the following commands: in dom0: - `timedatectl` - `ls -l /etc/localtime` in sys-net: - `systemctl restart systemd-timesyncd` followed by `systemctl status systemd-timesyncd` - `timedatectl` - `qubesdb-read /qubes-timezone` in another VM: - `sudo qvm-sync-clock` - `timedatectl` - `qubesdb-read /qubes-timezone` -- You received
Re: [qubes-users] Re: Qubes 4 boot ISO
On Saturday, 28 April 2018 02:07:21 UTC+10, awokd wrote: > On Fri, April 27, 2018 6:40 am, Drew White wrote: > > Still not working no matter what I do. > > > > > > Does anyone have any possible resolution to resolve this please? > > How are you making the boot device? If USB from Linux, a standard "cp > qubes.iso /dev/xvdj" (where xvdj is your USB device) should work. You can > also try switching to legacy boot mode. I burn it to DVD. It is an ISO after all. I always use Legacy Boot mode. -- 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/2ee393d8-1685-4f72-b62a-a190821a5f3c%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Q4.0 Whonix Torbrowser no sound, says to install pulseaudio ...
Hello mossy, On 04/13 01:39, mossy wrote: > john: > > Q4.0 Whonix Torbrowser no sound, says to install pulseaudio ... > > This issue (and others) are resolved in whonix 14, now in testing -- you > can upgrade here: > > https://www.whonix.org/wiki/Upgrading_Whonix_13_to_Whonix_14 > > Although it will be less work/risk if you can wait until the templates > are ready. If you attempt the upgrade, be sure to backup your Whonix > appVMs and templateVMs first! Questions: 1) If I understand you correctly sound will work in whoonix 14? Do you or someone else knows when whoonix 14 will be evailable via the Qubes Repositories? 2) Has someone installed pulseaudio in the whoonix-ws template in Qubes 4 and did this solve the no-sound-topic. 3) Why is there no sound in whoonix in the default Qubes Installation? kind regards [799] -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To 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/20180427221118.7eqbtn4bl6ep7ykq%40my-privmail. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Thinkpad T440s i7 and Qubes 4.0 compatibility
On Friday, April 27, 2018 at 12:04:08 PM UTC-4, Eivind K. Dovik wrote: > Hi, > > I have been offered a great deal on a used Lenovo Thinkpad T440s > (secondhand, but I trust the current owner). I am currently on a Macbook > Air running Debian and would like to make the switch to Thinkpad and > Qubes. > > Does anyone have experience running Qubes 4.0 on a T440s? The T440s I am > being offered has > a 512gb ssd and an i7 CPU. > > > Best, > Eivind I run Qubes 4.0 on T440p and it runs great. 500gb hdd and an i5 vPro CPU -- 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/debedc46-ef92-4d57-b250-35c0a30083fe%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] NTP and/or clock issue
On Friday, April 27, 2018 at 3:32:44 PM UTC-4, Ivan Mitev wrote: > On 04/27/2018 09:34 PM, Matthew Wyenandt wrote: > > On Friday, April 27, 2018 at 10:46:34 AM UTC-5, Ivan Mitev wrote: > >> Hey, > >> > >> On 04/27/2018 06:12 PM, Matthew Wyenandt wrote: > >>> Hi all, > >>> > >>> I'm new to Qubes 4.0 and loving it. I'm having an odd situation where > >>> the time on my clock is showing -5 from my current timezone, rather than > >>> -5 from UTC. For instance, I'm physically located in America/Chicago > >>> timezone, which is -5 UTC. My Qubes OS clock is set for America/Chicago > >>> timezone, which also says -5 UTC; however, the clock is now showing -10 > >>> UTC. I've tried to figure out a way to manipulate the clock within dom0, > >>> but I'm not finding anyway to do so. > >> > >> your hw clock is likely set to local time instead of UTC ; this usually > >> happens because you use(d) MS Windows. > >> > >> `hwclock` allows you to tweak the hardware clock; you can manually set > >> the time and then run `hwclock --systohc --utc`, that should fix your > >> problem. > >> > >> Note that `qvm-sync-clock` is run every hour in dom0 and should fix the > >> offset automatically: it first syncs dom0's time with the time in > >> "clockvm" (usually sys-net, see the output of `qubes-prefs clockvm`) and > >> it then runs `hwclock --systohc`. > >> > >> If you still have issues, check that the timezone and time are OK in > >> sys-net (or whatever clockvm you have defined). > > > > Thanks for this info, Ivan. I followed these steps. Should my sys-net > > clock be set for UTC? When I run hwclock --show, it's still showing EDT as > > the current time. Do I need to set this manually? I would prefer that it > > get updated via ntp. > > The clockVM's clock is synchronized with NTP, you don't need to set > anything manually... > > Clock synchronization works like that (if I'm not mistaken): > > 1- when a VM boots, the `/usr/lib/qubes/init/qubes-early-vm-config.sh` > script sets the VM's timezone (the script gets the timezone from dom0 > with `qubesdb-read /qubes-timezone`). > > 2a- if the VM is defined as the clockVM (sys-net by default) then the > `systemd-timesyncd` service synchronizes the VM's clock with NTP. > > 2b- for dom0 and VMs != clockVM, the `qubes-sync-time.timer` systemd > timer runs the `qvm-sync-clock` every 6 hours to (re)sync the clock with > the time in clockVM (sys-net). > > > So make sure your timezone is OK in dom0: `ls -l /etc/localtime` should > point to the right timezone (eg. /usr/share/zoneinfo/America/Chicago). > Then the easiest way is to perform a *full* reboot and everything should > be fine. > > > If it isn't, you'll have to debug a bit further: > > - make sure the timezone is OK in VMs too (again with `ls -l > /etc/localtime`). If it isn't, check what `qubesdb-read /qubes-timezone` > returns: it should be the same as dom0's timezone. > > - in sys-net, run `systemctl restart systemd-timesyncd` ; `systemctl > status systemd-timesyncd` should output a line like > > Status: "Synchronized to time server a.b.c.d:123 (0.fedora.pool.ntp.org)." > > the clock in sys-net should show the right time (both `date` and `sudo > hwclock` should show the same time, with the EDT format). > > - in dom0 and other VMs != clockVM, run `sudo qvm-sync-clock` ; the time > should then be OK. > > > Hope this helps ! Okay, so something doesn't seem to be configured correctly. During further debugging, i was able to get the correct timezone using 'timedatectl set-timezone Americas/Chicago'. However, when running 'systemctl status systemd-timesyncd' I get the following output: systemd-timesyncd.service - Network Time Synchronization Loaded: loaded (/usr/lib/systemd/system/systemd-timesyncd.service; enabled; v Drop-In: /usr/lib/systemd/system/systemd-timesyncd.service.d └─30_qubes.conf Active: inactive (dead) Condition: start condition failed at Fri 2018-04-27 10:04:54 CDT; 4s ago └─ ConditionPathExists=/var/run/qubes-service/clocksync was not met Docs: man:systemd-timesyncd.service(8) It seems the clocksync file is missing from /var/run/qubes-service/ directory. -- 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/3da0d854-ee68-4534-b575-8e082d5b8f67%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] bash autocomplete
[ reviving an old thread :) ]
On 03/11/2018 03:11 PM, haaber wrote:
> Thank you Holger,
> I don't know what this 3D-thing, is I'll learn it. I have, in the
> meanwhile, tested the attached file, that distinguishes also running,
> paused and halted VM's. For the moment this is completely sufficient for
> me. Maybe I'll add the completion "root" when I complete "qvm-run -u",
> since this is what I need for updating sudo-less minimal templates :)
>
> I put the file it in /etc/bash_completion.d/ within dom0, and source it
> in .bashrc. Bernhard
FWIW I've written a new bash autocomplete script based on your original
PoC; it's available at:
https://github.com/Qubes-Community/Contents/blob/master/code/productivity/qvm-cmds-bash-completion.bash
Additional features:
- completes the 2d arg of qvm-prefs, qvm-features, qvm-tags
- completes filenames of qvm-{copy,move}-to-vm
- also lists transient VMs for qvm-kill
Main limitation: parsing won't work properly when using option arguments
(eg. -s blah). Unfortunately there is no way to solve this except
parsing every known option for a given qvm-* command, which would be a
pain to maintain.
I can submit a PR for inclusion in one of dom0's qubes packages (don't
know which) if there's sufficient interest and enough people test it...
Cheers,
Ivan
--
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/966ead3c-1b1a-a5ea-6195-0f0face2442e%40maa.bz.
For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] NTP and/or clock issue
On 04/27/2018 09:34 PM, Matthew Wyenandt wrote: > On Friday, April 27, 2018 at 10:46:34 AM UTC-5, Ivan Mitev wrote: >> Hey, >> >> On 04/27/2018 06:12 PM, Matthew Wyenandt wrote: >>> Hi all, >>> >>> I'm new to Qubes 4.0 and loving it. I'm having an odd situation where the >>> time on my clock is showing -5 from my current timezone, rather than -5 >>> from UTC. For instance, I'm physically located in America/Chicago >>> timezone, which is -5 UTC. My Qubes OS clock is set for America/Chicago >>> timezone, which also says -5 UTC; however, the clock is now showing -10 >>> UTC. I've tried to figure out a way to manipulate the clock within dom0, >>> but I'm not finding anyway to do so. >> >> your hw clock is likely set to local time instead of UTC ; this usually >> happens because you use(d) MS Windows. >> >> `hwclock` allows you to tweak the hardware clock; you can manually set >> the time and then run `hwclock --systohc --utc`, that should fix your >> problem. >> >> Note that `qvm-sync-clock` is run every hour in dom0 and should fix the >> offset automatically: it first syncs dom0's time with the time in >> "clockvm" (usually sys-net, see the output of `qubes-prefs clockvm`) and >> it then runs `hwclock --systohc`. >> >> If you still have issues, check that the timezone and time are OK in >> sys-net (or whatever clockvm you have defined). > > Thanks for this info, Ivan. I followed these steps. Should my sys-net clock > be set for UTC? When I run hwclock --show, it's still showing EDT as the > current time. Do I need to set this manually? I would prefer that it get > updated via ntp. The clockVM's clock is synchronized with NTP, you don't need to set anything manually... Clock synchronization works like that (if I'm not mistaken): 1- when a VM boots, the `/usr/lib/qubes/init/qubes-early-vm-config.sh` script sets the VM's timezone (the script gets the timezone from dom0 with `qubesdb-read /qubes-timezone`). 2a- if the VM is defined as the clockVM (sys-net by default) then the `systemd-timesyncd` service synchronizes the VM's clock with NTP. 2b- for dom0 and VMs != clockVM, the `qubes-sync-time.timer` systemd timer runs the `qvm-sync-clock` every 6 hours to (re)sync the clock with the time in clockVM (sys-net). So make sure your timezone is OK in dom0: `ls -l /etc/localtime` should point to the right timezone (eg. /usr/share/zoneinfo/America/Chicago). Then the easiest way is to perform a *full* reboot and everything should be fine. If it isn't, you'll have to debug a bit further: - make sure the timezone is OK in VMs too (again with `ls -l /etc/localtime`). If it isn't, check what `qubesdb-read /qubes-timezone` returns: it should be the same as dom0's timezone. - in sys-net, run `systemctl restart systemd-timesyncd` ; `systemctl status systemd-timesyncd` should output a line like Status: "Synchronized to time server a.b.c.d:123 (0.fedora.pool.ntp.org)." the clock in sys-net should show the right time (both `date` and `sudo hwclock` should show the same time, with the EDT format). - in dom0 and other VMs != clockVM, run `sudo qvm-sync-clock` ; the time should then be OK. Hope this helps ! -- 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/ce64581a-8d69-1cd0-8fcf-2bceaf0c21db%40maa.bz. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Assigning USB to VM fails
fredag den 27. april 2018 kl. 17.57.45 UTC+2 skrev awokd: > On Thu, April 26, 2018 11:38 am, 'Max Andersen' via qubes-users wrote: > > I have trouble attaching my USB RJ45 adapter. I get the following error : > > > > > > [Max@dom0 ~]$ qvm-usb -a lokal-belkin sys-usb:3-2 > > ERROR: Device attach failed: No device info received, connection failed, > > check backend side for details [Max@dom0 ~]$ > > If you're using a new template for sys-usb or lokal-belkin, have you > installed the qubes usb proxy in both and qubes input proxy sender in > sys-usb? Going off memory so can't remember the package names exactly. I remembered changing template to debian as sys-usb, since fedora can't handle large USB drives with exFat, so I swithced back to fedora-26. That didn't help though. I have qubes-input-proxy-sender and qubes-usb-proxy in the template. Sincerely Max -- 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/78c877ad-1b43-4249-a3a5-35bee4cc4b9e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: debian-9 template
On Friday, April 27, 2018 at 1:46:08 PM UTC+1, higgin...@gmail.com wrote: > Have used Qubes3 for a couple of years and now acquired a new PC where I've > done a complete fresh install of QUBES 4. > > (Copied all my data off old system - ready for adding to new system when all > set up) > > Base system seems fine - standard VM's etc - but everything by default based > on Fedora - albeit Debian and Fedora templates offered by default. > > Fedora template has lots of assorted software - that I could use to add to > various Vm's as required - a standard new VM using Fedora template offers > FILES, TERMINAL, FIREFOX and QUBES SETTINGS - basically core features to get > me started. > > WHEN I LOOK AT THE DEBIAN-9 template - there is no software at all. > > ALSO the DEBIAN-9 template and any VM that I generate using it, only offers > QUBE-SETTINGS - i.e. no TERMINAL, BROWSER or FILEs. > > > CAN ANYONE advise on what I should do next - assume if I get access to > terminal, I can install all software I want - but assumed there would be a > standard stock of software/base features available in the Debian-9 template. > > (Am sure this was the case with QUBES3) > > Grateful for advice - my preference is to use Debian (as per last 2 years > within QUBES and many years before that using DEBIAN distro) rather than > Fedora. See awokd comments. Problem is that I have nothing in APPLICATIONS. Have tried Removing DEB9 template, installing DEB8 template and then following the Upgrade 8 to 9 route. This initially seems to solve problem. Load of APPLICATIONS appear - and by going into repos folder- could change "jessie" to "stretch". Then update/upgrade. Still can't use the APPLICATIONS in DEB 9. I'll try it again with fresh install - in case I did something wrong. Another option - might simply copy the DEB9 "template" from previous computer and install that - but wanted to avoid that - just naturally want to have "clean" install on QUBES 4 on new computer. Any other suggestions welcome - have others found DEBIAN-9 template OK on clean install?. -- 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/c4c1eb23-8ad6-401f-bc71-815b100853b3%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] dvm is not starting from command line, starts normal AppVM
On Fri, April 27, 2018 7:39 am, qubes-...@tutanota.com wrote: > hi, I try to start firefox in my deb-dvm-net from command line with > alt+f2 > > qvm-run deb-dvm-net firefox Check out the qvm-run commands for inside a DVM's .desktop files in ~/.local/share/applications for examples. You probably need to add the --dispvm option. > Is the dvm disabled in konsole? Also I cant start konsole in dvm. The > console window blinks and disapears. This should work. Are you using a restored template? Maybe try to reinstall 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/65a955b77bdc21ba83629da8a4082707.squirrel%40tt3j2x4k5ycaa5zt.onion. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Re: Qubes 4 boot ISO
On Fri, April 27, 2018 6:40 am, Drew White wrote: > Still not working no matter what I do. > > > Does anyone have any possible resolution to resolve this please? How are you making the boot device? If USB from Linux, a standard "cp qubes.iso /dev/xvdj" (where xvdj is your USB device) should work. You can also try switching to legacy boot mode. -- 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/e324c20a038030fe01dec5ec07b4f985.squirrel%40tt3j2x4k5ycaa5zt.onion. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Thinkpad T440s i7 and Qubes 4.0 compatibility
Hi, I have been offered a great deal on a used Lenovo Thinkpad T440s (secondhand, but I trust the current owner). I am currently on a Macbook Air running Debian and would like to make the switch to Thinkpad and Qubes. Does anyone have experience running Qubes 4.0 on a T440s? The T440s I am being offered has a 512gb ssd and an i7 CPU. Best, Eivind -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/alpine.DEB.2.20.1804271758350.2002%40debian. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] [Q4.0] sys-usb fails to start with xHCI controller
On Thu, April 26, 2018 2:26 pm, gluv...@gmail.com wrote: > On Wednesday, April 25, 2018 at 10:01:30 PM UTC-7, awokd wrote: > >> On Thu, April 26, 2018 12:53 am, Fox Gluv wrote: >> >> >>> libxl_pci.c:1176:libxl__device_pci_reset: The kernel doesn't support >>> reset from sysfs for PCI device :00:14.0 2018-04-25 >>> 15:08:20.363+: >>> libxl: libxl_pci.c:1095:do_pci_add: Error: xc_physdev_map_pirq >>> irq=-2147483648: Invalid argument >>> >> >> Try setting it to not require strict reset. >> > > I think it was already set to no-strict-reset. Here's the qvm-pci entry: > dom0:00_14.0 USB controller: Intel Corporation Wildcat Point-LP USB xHCI > Controller sys-usb > (no-strict-reset=True) > > > To be sure I went into Qube Manager, sys-usb->Qubes Setting->Devices and > used the "Configure strict reset for PCI devices" button to set it on > 00:14.0. It still did not start up afterwards, and gave the same error > message. 00:14.0 USB controller: Intel Corporation Wildcat Point-LP USB xHCI Controller (rev 03) (prog-if 30 [XHCI]) Subsystem: Lenovo Device 3820 Flags: medium devsel, IRQ -2147483648 The IRQ looks very odd. Check your "xl dmesg" and "sudo journalctl -b" for errors relating to this device. Maybe check your UEFI config to see if you can set it to USB 2.0 mode? -- 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/a81dfca30552a1acc6a17523403608cb.squirrel%40tt3j2x4k5ycaa5zt.onion. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Assigning USB to VM fails
On Thu, April 26, 2018 11:38 am, 'Max Andersen' via qubes-users wrote: > I have trouble attaching my USB RJ45 adapter. I get the following error : > > > [Max@dom0 ~]$ qvm-usb -a lokal-belkin sys-usb:3-2 > ERROR: Device attach failed: No device info received, connection failed, > check backend side for details [Max@dom0 ~]$ If you're using a new template for sys-usb or lokal-belkin, have you installed the qubes usb proxy in both and qubes input proxy sender in sys-usb? Going off memory so can't remember the package names exactly. -- 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/f53dcca4f43054de55d78c6cb88c892e.squirrel%40tt3j2x4k5ycaa5zt.onion. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] debian-9 template
On Fri, April 27, 2018 12:46 pm, higginsonj...@gmail.com wrote: > Have used Qubes3 for a couple of years and now acquired a new PC where > I've done a complete fresh install of QUBES 4. > WHEN I LOOK AT THE DEBIAN-9 template - there is no software at all. > > > ALSO the DEBIAN-9 template and any VM that I generate using it, only > offers QUBE-SETTINGS - i.e. no TERMINAL, BROWSER or FILEs. Go to Qube Settings, then Applications tab, then add the ones you want. It doesn't have a file manager by default, so you'll want to apt install one. -- 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/dbb92ca9d9f5897f40040b99eed223c6.squirrel%40tt3j2x4k5ycaa5zt.onion. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] NTP and/or clock issue
Hey, On 04/27/2018 06:12 PM, Matthew Wyenandt wrote: > Hi all, > > I'm new to Qubes 4.0 and loving it. I'm having an odd situation where the > time on my clock is showing -5 from my current timezone, rather than -5 from > UTC. For instance, I'm physically located in America/Chicago timezone, which > is -5 UTC. My Qubes OS clock is set for America/Chicago timezone, which also > says -5 UTC; however, the clock is now showing -10 UTC. I've tried to figure > out a way to manipulate the clock within dom0, but I'm not finding anyway to > do so. your hw clock is likely set to local time instead of UTC ; this usually happens because you use(d) MS Windows. `hwclock` allows you to tweak the hardware clock; you can manually set the time and then run `hwclock --systohc --utc`, that should fix your problem. Note that `qvm-sync-clock` is run every hour in dom0 and should fix the offset automatically: it first syncs dom0's time with the time in "clockvm" (usually sys-net, see the output of `qubes-prefs clockvm`) and it then runs `hwclock --systohc`. If you still have issues, check that the timezone and time are OK in sys-net (or whatever clockvm you have defined). -- 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/224371b5-528d-c40a-8b09-375a73940441%40maa.bz. For more options, visit https://groups.google.com/d/optout.
[qubes-users] NTP and/or clock issue
Hi all, I'm new to Qubes 4.0 and loving it. I'm having an odd situation where the time on my clock is showing -5 from my current timezone, rather than -5 from UTC. For instance, I'm physically located in America/Chicago timezone, which is -5 UTC. My Qubes OS clock is set for America/Chicago timezone, which also says -5 UTC; however, the clock is now showing -10 UTC. I've tried to figure out a way to manipulate the clock within dom0, but I'm not finding anyway to do so. -- 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/2cd75d44-d4ca-404a-8336-5342e933ba8f%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] [Q4.0] Lenovo t520 AEM: GPU Hangs After SINIT Loads
-BEGIN PGP SIGNED MESSAGE- Hash: SHA256 Both the 2nd generation pre-RACM and the 3rd generation post-RACM SINIT upon load cause a vertical-line filled splash-screen/LightDM. The X.Org logs for LightDM report that the Intel GPU has hung. Virtual console functions normally, however. Dmesg output didn't look too out of the ordinary. Omitting the SINIT module from load fixes the graphics glitch completely. Beyond the GPU error, AEM appears to be functioning properly. Currently running the latest Lenovo BIOS and hoping someone else has encountered something like this before. -BEGIN PGP SIGNATURE- Version: GnuPG v2 iQIcBAEBCAAGBQJa4xzwAAoJEPgLU7pt/HmyD30P/3fE0+iFk6Vcgb3eb+FWM0x3 LzbM7isAvGW7pdTYCqq2qrpOczxnZObo0Cuk0iLTJvi8vhCUSc+eKgdYQnto4B+R 3agUthspZVxAcfeUebldR35nsStc3u+VbsXNAJVKLMuDww/OehCXJZxlcOuEX4uM doJo3EVP3D5Jhuc2FloiqlGHsKG+hZPKEUw+0uAtbj2oN+ebaPtpFkUhLyYOqZlM envD+IE5JzAvh5Pd7o+Dvm6aLfku8c7JlmLG3w4DKbOiOY5Vdk4sapDtj+Bpj/er dIzHr2mNPXUi5FVxGHlCZ8FE9bnsjgVup6Vfqn2Q/t2KeqxiqgU0C/tNRp2TK4o3 NVzrCagnXSGnN1NP45XBgQZ+SgWhU9MYybJ5F1jc2ZV3xOS39dW7pgAX/kKkgsbP NC8B0X7tITQi0i8pm/5NRBNkUsc/a/xqDtvIYGaokTnxvkFnvrVYfrokiz35uyu/ TeYsnqKC3shvWHpb0Wqzq/NsygU08zuc+NxO1AWi/Hk/leOCNUxwtxdH+6uUl79S nU6uM4h137Sn87JlZ1WQL6r8+rfmTz1diMBhuJCftPT53UQw5yerl9eJV2lQBDhg ayE5032+T114ZyKCzjScqpx+mARR6s/cM3GZ1kyoBSlDLUltmzkBu6BXK7fZJz6T L73Vi3MpellTAVPT4JPR =uA2U -END PGP SIGNATURE- -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To post to this group, send email to qubes-users@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/CAGDZ16EWbchOzUbKUs6fEv4%2Bk8Sk-EdaQm3_h6gADGDU2Vmb5A%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] debian-9 template
Have used Qubes3 for a couple of years and now acquired a new PC where I've done a complete fresh install of QUBES 4. (Copied all my data off old system - ready for adding to new system when all set up) Base system seems fine - standard VM's etc - but everything by default based on Fedora - albeit Debian and Fedora templates offered by default. Fedora template has lots of assorted software - that I could use to add to various Vm's as required - a standard new VM using Fedora template offers FILES, TERMINAL, FIREFOX and QUBES SETTINGS - basically core features to get me started. WHEN I LOOK AT THE DEBIAN-9 template - there is no software at all. ALSO the DEBIAN-9 template and any VM that I generate using it, only offers QUBE-SETTINGS - i.e. no TERMINAL, BROWSER or FILEs. CAN ANYONE advise on what I should do next - assume if I get access to terminal, I can install all software I want - but assumed there would be a standard stock of software/base features available in the Debian-9 template. (Am sure this was the case with QUBES3) Grateful for advice - my preference is to use Debian (as per last 2 years within QUBES and many years before that using DEBIAN distro) rather than Fedora. -- 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/aba038a1-3d15-490d-a96a-ed876b58c7e1%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Risk on secondhand equipment
On Friday, April 27, 2018 at 7:18:37 AM UTC-4, mstv...@gmail.com wrote: > Is a second-hand CPU safe? > Is second-hand RAM safe? Are second-hand keyboards safe? Second-hand mouses? Second-hand SSDs? Second-hand optical-drives? Second-hand power-management chips? Second-hand displays? Is any component safe if it was out of your sight for more than 30 minutes? There's no winning in this thought experiment. cf "On trusting trust." -- But yeah, CPUs: from what I understand, Intel microcode updates are not persistent across power cycles. This is why, though an OS can push updates for the current session, it is "more permanent" to deploy the microcode updates in the BIOS/firmware (esp. in a multi-boot system or in a system where the OS lags in microcode update support). Anyway, when you get your used machine, reflash the BIOS using the manufacturer's most recent release or reflash it with coreboot if that's your thing. Same with any devices that have firmware update support (SSDs, etc.). Also fun side note: many contemporary SED/HW-FDE SSDs will not allow firmware updates if a) the updates aren't signed by the manufacturer's keys and/or b) the drive is security configured (ATA password, TCG OPAL), even though unlocked. a) is good (or as good as the manufacturer is about securing their signing keys anyway); b) means you have to temporarily de-configure security before updating the firmware (less good..but I like the trade-off of knowing the drive will reject firmware updates unless I go out of my way to perform a security operation that is unusual). B -- 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/c11f7130-c2b0-438e-a68d-da127fb3acdd%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
Re: [qubes-users] Risk on secondhand equipment
The link refers basically to laptops. I was wondering if there are issues with second-hand desktop parts for the last couple of generations. Is a second-hand CPU safe? CPU vulnerabilities seem to be corrected with microcode updates applied to the motherboard BIOS or the OS, and not directly to the CPU. That makes me think that there is no firmware to speak of within a CPU; at least not one that can be changed. On the other hand (if I understand correctly) modern CPUs include integrated controllers for peripherals, RAM, graphics etc. (Let alone AI modules or whatever, and the “plasticity” those imply.) Does that mean that the CPUs themselves run their own firmware or software of any kind? And more importantly can a CPU be infected in a permanent or contagious manner? “in a permanent manner” : remains infected when installed on another motherboard? “in a contagious manner” : the malware propagates to the next motherboard the CPU is installed on? CPUs also contain eDRAM. Which leads me to my next question. Is second-hand RAM safe? If the DIMM itself has a controller or firmware (other than the IMC in the CPU) , then it might be infected too. Is that correct? A second reason of concern is the issue of Data Remanence, a property that allows “removing a computer's memory modules, cooling them to prolong data remanence, then transferring them to a different computer to be read out.” according to the Dynamic_random-access_memory article on Wikipedia. Admittedly the phenomenon refers to “ data retention of seconds to minutes at room temperature and "a full week without refresh when cooled with liquid nitrogen."” according to the Data_remanence article. The aforementioned articles address the matter through the perspective of forensics rather than security. But am I right to assume that it would allow file-less malware infections? P.S.: I don’t have a particular threat model in mind. My questions are strictly hardware related. I realize the problems of an official endorsement and I understand that nobody can predict future vulnerabilities or exploits. -- 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/ada5b955-25d5-4cc1-8240-62b5d090f15c%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] dvm is not starting from command line, starts normal AppVM
hi, I try to start firefox in my deb-dvm-net from command line with alt+f2 qvm-run deb-dvm-net firefox It starts a normal AppVM deb-dvm-net instead of dvm. If I but start the firefox directly from Start - Disposable: deb-dvm-net - firefox, it starts the dvm normally like for example disp2441. Is the dvm disabled in konsole? Also I cant start konsole in dvm. The console window blinks and disapears. Thank you! -- 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/LB51oz2--3-0%40tutanota.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] Re: Qubes 4 boot ISO
Still not working no matter what I do. Does anyone have any possible resolution to resolve this please? -- 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/5cd4b384-1b25-4b4d-9d5c-bdc74b9f33f8%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
[qubes-users] KDE 4 on Qubes 4
Hello, I'm using Debian 8 with KDE4 at the moment and I'd like to switch to Qubes 4.0. However, I can't find my way in Xfce and I don't like the look of KDE5. Is it possible / too technical to install KDE4 in Qubes as dom0? Thanks for answers. Sent with [ProtonMail](https://protonmail.com) Secure Email. -- 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/fn6zMZ6C8wYWSRBW4z4wHAwJSqxoy-tRB-8-w-vfPwZz52w3b46ANHi3QVTKiWGyoQfToZx3lMZeqrdUdO7PnM-6867a2ctBsQlPVRKkJXk%3D%40protonmail.com. For more options, visit https://groups.google.com/d/optout.
