Re: [qubes-users] i915 driver problems

2021-09-02 Thread Mike Keehan

On 9/2/21 7:24 PM, Mike Keehan wrote:

On 9/2/21 1:44 PM, haaber wrote:


The current Intel driver, which does not work for me, is
xorg-x11-drv-intel-2.99.917-48.20200205.fc33.x86_64.rpm
Just use dnf to uninstall it.


actually Q4.0.4 ships with

xorg-x11-drv-intel-2.99.917-49.20210126.fc25.x86_64.rpm

which does not work for me either.



The one I installed using dnf is
xorg-x11-drv-intel-2.99.917-32.20171025.fc33.x86_64.rpm
and this does work OK.


this one is from Q4.0.1, qhereas Q4.0.0 ships

xorg-x11-drv-intel-2.99.917-26.20160929.fc25.x86_64.rpm


So you confirm that you install it in dom0 via

sudo dnf install xorg..whatever.rpm

(that requires deleting kernel-latest-qubes-vm, if present). Then you
need to do an update-grub or something similar to build the downgraded
version in the respective initramfs  ???

Bernhard



Hi Bernard,

I just looked at my history in bash, and what I did was :-

dnf downgrade xorg-x11-drv-intel-2.99.917-32.20171025
vi /etc/dnf/dnf.conf
    Appended "exclude=xorg-x11-drv-intel" as the last line in the file.

Mike.



Hmm, looking through the history list, there was a "yum downgrade" line
after the dnf one.  Might be that the "dnf downgrade" did not work.

yum downgrade xorg-x11-drv-intel-2.99.917-32.20171025.fc25.x86_64.rpm

that is the full filename of the rpm file.

Mike.

--
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/a0369483-8c20-ffdd-2db6-fe5b73be62b7%40keehan.net.


Re: [qubes-users] i915 driver problems

2021-09-02 Thread Mike Keehan

On 9/2/21 1:44 PM, haaber wrote:


The current Intel driver, which does not work for me, is
xorg-x11-drv-intel-2.99.917-48.20200205.fc33.x86_64.rpm
Just use dnf to uninstall it.


actually Q4.0.4 ships with

xorg-x11-drv-intel-2.99.917-49.20210126.fc25.x86_64.rpm

which does not work for me either.



The one I installed using dnf is
xorg-x11-drv-intel-2.99.917-32.20171025.fc33.x86_64.rpm
and this does work OK.


this one is from Q4.0.1, qhereas Q4.0.0 ships

xorg-x11-drv-intel-2.99.917-26.20160929.fc25.x86_64.rpm


So you confirm that you install it in dom0 via

sudo dnf install xorg..whatever.rpm

(that requires deleting kernel-latest-qubes-vm, if present). Then you
need to do an update-grub or something similar to build the downgraded
version in the respective initramfs  ???

Bernhard



Hi Bernard,

I just looked at my history in bash, and what I did was :-

dnf downgrade xorg-x11-drv-intel-2.99.917-32.20171025
vi /etc/dnf/dnf.conf
   Appended "exclude=xorg-x11-drv-intel" as the last line in the file.

Mike.

--
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/10e6607c-34c0-a52b-37e4-f4340805daca%40keehan.net.


Re: [qubes-users] i915 driver problems

2021-09-01 Thread Mike Keehan

On 9/1/21 8:29 PM, haaber wrote:

On 9/1/21 7:44 PM, Mike Keehan wrote:

On 9/1/21 1:36 PM, Bernhard wrote:

Hello, I wonder if some of you guys have the bad luck of an i915
graphics card and found some solutions.  For me, no >= 5.4 xen kernel
works (freezes). So I still run it on 4.19 :)


I think it is the recent i915 driver update that causes the problem.
I had to remove it and download and install the previous version.
then I blacklisted the i915 driver so that dom0 would not update it.

Screen does not freeze anymore.

Only "problem" is that the "Qubes Update" widget thinks there is
always an update to be made.  Just have to ignore it.

Mike.



Sound worth a trial (easily reversible, right?) Which version did you
install? And how find out the version of firmware installed? Thx, Bernhard



I downloaded the 4.0 Qubes iso and extracted the driver from there, as I
knew it had always worked until the update.

I think there is a way to see what updates Qubes has performed, but I
can't remember how.

The current Intel driver, which does not work for me, is
xorg-x11-drv-intel-2.99.917-48.20200205.fc33.x86_64.rpm
Just use dnf to uninstall it.

The one I installed using dnf is
xorg-x11-drv-intel-2.99.917-32.20171025.fc33.x86_64.rpm
and this does work OK.

If you don't blacklist the driver in dnf, it will update it next
time you update dom0.


Mike.




--
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/40db6409-6c56-0847-72f3-b240f06fb0c0%40keehan.net.


Re: [qubes-users] i915 driver problems

2021-09-01 Thread Mike Keehan

On 9/1/21 1:36 PM, Bernhard wrote:

Hello, I wonder if some of you guys have the bad luck of an i915
graphics card and found some solutions.  For me, no >= 5.4 xen kernel
works (freezes). So I still run it on 4.19 :)

I first thought this to be an "evolution problem" since I use and update
Q4 since its beta state. So I tried a new install on a new disc, but
that fails even before finishing install, freezing as well :-(

Even a plain "live debian" freezes from time to time with i915 errors,
which gives a clue where the problem comes from.

Is there maybe a way to tweak the installer? Thanks,

best, Bernhard



Hi Bernard,

I think it is the recent i915 driver update that causes the problem.
I had to remove it and download and install the previous version.
then I blacklisted the i915 driver so that dom0 would not update it.

Screen does not freeze anymore.

Only "problem" is that the "Qubes Update" widget thinks there is
always an update to be made.  Just have to ignore it.

Mike.

--
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/5ef58d5a-ecb6-26e1-298b-d009ee6d65e9%40keehan.net.


Re: [qubes-users] Question related to Qubes Updater of dom0

2021-07-08 Thread Mike Keehan




On 7/8/21 7:27 PM, Viktor Ransmayr wrote:

Hello Qubes Community,

I have received multiple requests to accept an update of 'dom0' content 
lately.


The only info I've received after performing these updates has been:

###

Updating dom0

local:
     --

###

Can someone provide an explanation, a link to read more about it - or - 
should I be worried?


With kind regards,

Viktor



Have you "blacklisted" any packages.  I get the same messages as above
but that is because I have told RPM to ignore the intel video driver 
update - it hangs my screen after a random time interval.



Mike.


--
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/d3994193-a2db-7db8-1eee-c8721a91f207%40keehan.net.


Re: [qubes-users] Salt updates fails on Fedora-33

2021-03-03 Thread Mike Keehan

On 3/3/21 4:31 AM, lok...@gmail.com wrote:
After I installed the fedora-33 template a few days ago, I have never 
been able to do a software update on it using the Salt-based updater. A 
manual update using "dnf update" works fine.


This is the error I'm getting in the updater tool:

Is this a known problem, and is there some easy way to fix this?

-
Updating fedora-33

Error on updating fedora-33: Command '['sudo', 'qubesctl', 
'--skip-dom0', '--targets=fedora-33', '--show-output', 'state.sls', 
'update.qubes-vm']' returned non-zero exit status 20

fedora-33:
   --
   _error:
   Failed to return clean data
   retcode:
   1
   stderr:
   Traceback (most recent call last):
     File "/var/tmp/.root_dd8a91_salt/salt-call", line 27, in 


   salt_call()
     File "/var/tmp/.root_dd8a91_salt/pyall/salt/scripts.py", 
line 445, in salt_call

   client.run()
     File "/var/tmp/.root_dd8a91_salt/pyall/salt/cli/call.py", 
line 48, in run

   caller = salt.cli.caller.Caller.factory(self.config)
     File "/var/tmp/.root_dd8a91_salt/pyall/salt/cli/caller.py", 
line 64, in factory

   return ZeroMQCaller(opts, **kwargs)
     File "/var/tmp/.root_dd8a91_salt/pyall/salt/cli/caller.py", 
line 329, in __init__

   super(ZeroMQCaller, self).__init__(opts)
     File "/var/tmp/.root_dd8a91_salt/pyall/salt/cli/caller.py", 
line 89, in __init__

   self.minion = salt.minion.SMinion(opts)
     File "/var/tmp/.root_dd8a91_salt/pyall/salt/minion.py", 
line 912, in __init__

   opts["grains"] = salt.loader.grains(opts)
     File "/var/tmp/.root_dd8a91_salt/pyall/salt/loader.py", 
line 825, in grains

   ret = funcs[key]()
     File 
"/var/tmp/.root_dd8a91_salt/pyall/salt/grains/core.py", line 2384, in 
ip_fqdn
   ret["ipv6"] = 
salt.utils.network.ip_addrs6(include_loopback=True)
     File 
"/var/tmp/.root_dd8a91_salt/pyall/salt/utils/network.py", line 1353, in 
ip_addrs6
   return _ip_addrs(interface, include_loopback, 
interface_data, "inet6")
     File 
"/var/tmp/.root_dd8a91_salt/pyall/salt/utils/network.py", line 1333, in 
_ip_addrs

   ret.add(addr)
     File "/usr/lib64/python3.9/ipaddress.py", line 1920, in 
__hash__

   return hash((self._ip, self._scope_id))
   AttributeError: _scope_id
   stdout:

--


I could not clone the fedora 33 templates, with a similar error message
about "not clean", until I started and stopped the template.  It's been
OK since then.

Mike.

--
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/6b4de0fb-e080-377b-e1a6-cfddc0b99743%40keehan.net.


Re: [qubes-users] trouble with apt-get on dabian

2021-03-02 Thread Mike Keehan

On 3/1/21 11:48 AM, Mike Keehan wrote:



HI,

Just a "me too" I'm afraid.  I installed Fedora 33, and used it for all
the sys-vms, and my sys-net would not connect to wifi - kept displaying
the prompt for the wifi password, even though the password was correct.

Switched back to Fedora 32 on sys-net, and it works OK again.

(I also had my screen freeze at one point - might be due to the i915
driver update.  Had this problem a long time ago when using the Arch
distro, but never on Qubes before.)

Just monitoring things for now.

Mike.



Did an update and now it works fine.  Silly me.

Mike.

--
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/0d3ee0e3-7353-3f84-654b-5bb776efdefd%40keehan.net.


Re: [qubes-users] trouble with apt-get on dabian

2021-03-01 Thread Mike Keehan

On 3/1/21 5:05 AM, Steve Coleman wrote:



On Wed, Feb 24, 2021 at 5:49 AM 'awokd' via qubes-users 
mailto:qubes-users@googlegroups.com>> wrote:


Steve Coleman:

 > I installed the stock Debian-10 rpm yesterday and it also fails
to update
 > using the default proxy. The whonix templates based on Debian
work because
 > they are using a different update vm.
 >
 > I really don't have a clue how all the Fedora templates work
using the
 > exact same default update proxy while the Debian ones do not. I
have not
 > made any deliberate custom modifications to any of the update
settings, but
 > something obviously changed.
 >
 > My suspicion is on the receiving side proxy configuration in
sys-firewall
 > but I don't know how to debug that. With the TERM setting being
complained
 > about I am wondering how this proxy is being launched without a
full set of
 > environment variables. This error text is in red, as coming
through the
 > pipe, so its on the other side, not in the template itself. The
update pipe
 > is not a terminal afaik so I don't know why the proxy would be
complaining
 > it doesn't know the terminal type. But then why does the Fedora
update
 > still work and Debian not using the exact same update gateway.
Very odd.
 >
I agree, sounds like something broken in sys-firewall given your other
UpdateVM is working. You could change your templates to use the same
UpdateVM as Whonix if you wanted to confirm. Otherwise, there's nothing
special about the sys-firewall AppVM. If you don't mind recreating any
firewall rules, try creating a new AppVM and confirm you don't get that
TERM warning at the terminal. Next, change anything that points to
sys-firewall for networking to the new one, and make it your new
UpdateVM?


There is a package in the Fedora distribution that is causing this 
problem. I switched both my sys-net and sys-firewall to use the new 
fedora-33 template that was just released and suddenly my Debian-10 
could update again. Then I started installing all the packages that I 
previously had in my fedora-32 template and suddenly my Debian-10 update 
is broken again.


I then tried to revert back by switching both sys-net/sys-firewall vm's 
to the fedora-33-minimal I had available but sys-net would not even boot 
up using minimal. Switching it again to a default fedora-32 allowed it 
to boot again. And sys-firewall blocked all network traffic using 
fedora-33-minimal so again I needed to revert that back to a default 
fedora-32 to get back online just to write this email.


Apparently, I need to reinstall a new fedora-33 template baseline and 
painstakingly install all these packages one at a time while restarting 
Debian-10 to try an 'apt-get update' between package installs. Somewhere 
along the way, it will break and whatever I just installed will be the 
culprit. I think I'll be doing a lot of cloning of templates creating 
checkpoints along the way.


Steve



HI,

Just a "me too" I'm afraid.  I installed Fedora 33, and used it for all
the sys-vms, and my sys-net would not connect to wifi - kept displaying
the prompt for the wifi password, even though the password was correct.

Switched back to Fedora 32 on sys-net, and it works OK again.

(I also had my screen freeze at one point - might be due to the i915
driver update.  Had this problem a long time ago when using the Arch
distro, but never on Qubes before.)

Just monitoring things for now.

Mike.

--
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/2f806f50-138d-de28-837e-667a40ed0d06%40keehan.net.


Re: [qubes-users] Qubes Manager Feature Requests: Connect to not-running NetVM, restart NetVM with connected machines, force-restart a NetVM

2021-02-16 Thread Mike Keehan

On 2/15/21 7:51 PM, donoban wrote:

Hi,

On 2/15/21 12:44 PM, r.wiesb...@web.de wrote:

Hello fellow Qubes users,

I have 3 feature requests today regarding Qubes Manager:

1) Connect to not-running NetVM
If a not-running NetVM is chosen there should not be an error message
but a choice between "Start NetVM" and "Abort"


This is already done in R4.1 version.


2) restart netVM with connected machines
Sometimes NetVMs have issues that are easily solved by a restart.
Nastily Qubes prevents restarting the netVM if VMs are connected. What
should optionally happen is either that the connected VMs are
disconnected, the NetVM is restarted and the VMs are reconnected (that
is what I do manually whenever this is needed) or alternatively that all
connected VMs are restarted as well.


Respect this there is a "Cascade shutdown" that will power off all the
connected VM's in recursive mode. I understand that is not what you
mean, you want a option for restart this VM without touching any others...

I understand that you find it helpful for some kind of hardware problem
(sleep / wake up?) but it seems more a hack than a real solution.


3) force-reboot a VM
Users can kill a VM, but this way the user has to wait until the VM was
terminated and then start the machine again (kill + start). It would be
useful to have a single option for both tasks. That happens to me almost
daily with the USB-VM.


Uhm more than a force-reboot option, ideally the restart option should
trigger a timeout and if it expires ask you if you want to kill it or
keep waiting (same that shutdown option). Is it not the current behavior?



I use a simple shell script to restart my sysnet sometimes after the
system is suspended, as it does not restart correctly occasionally.

This is it:-
--
#
# reboot-sys-net
#

# Have to restart sys-net after suspend sometimes.

qvm-prefs sys-firewall netvm none
sleep 1
qvm-shutdown --wait sys-net
sleep 2
qvm-start sys-net
sleep 1
qvm-prefs sys-firewall netvm sys-net
---

All I can say is it works for me.

Mike.

--
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/d28fe8b0-f876-20aa-bc36-29d6968a2975%40keehan.net.


Re: [qubes-users] Qubes not reading flash drive

2021-01-17 Thread Mike Keehan

On 1/16/21 3:44 PM, Shawn Creighton wrote:
I have a Sandisk Cruzer 8GB flash drive with some older documents on it 
that I need to access, when I plug it in to Qubes it shows up in the 
available devices but when I connect it to any appvm it is not showing 
up in the file manager. Other newer flash drives work fine.

Any way to get the system to read it?



File managers will only see a whole disk that is passed to the VM,
not a single partition.  Are you passing the whole disk?

--
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/f579c645-5ed0-9ca6-62bf-a26a95bb701f%40keehan.net.


Re: [qubes-users] Q: Kernel being used in VM

2020-12-21 Thread Mike Keehan

On 12/21/20 12:23 AM, Ulrich Windl wrote:

Hi!

I wonder: What sense is in updating the kernel in a VM (e.g. fedora-32) 
when that kernel isn't used when booting the VM?




The VM's package manager can be told not to update specified packages,
if that is what you want.

Mike.

--
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/ebb7fe8c-6a5b-c530-997c-55c654fda777%40keehan.net.


Re: [qubes-users] How to login in tty

2020-12-16 Thread Mike Keehan

On 12/16/20 12:14 PM, Günter Zöchbauer wrote:


Sometimes my KDE freezes but I can switch to TTY using Ctrl-Alt-F2
but I wasn't able to login with user "root" and password.
Should this be possible?



No.

The login is for your username and password that you use when logging
in to Qubes.  Once logged in as your username, you can use sudo to
do root operations.

Mike.

--
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/108d67a5-dc34-b7c5-6ace-059a7ca2bfcb%40keehan.net.


Re: [qubes-users] R4.0.4 RC1 Unable to delete or backup certain qubes

2020-11-14 Thread Mike Keehan

On 11/14/20 4:39 PM, Steve Coleman wrote:



On Sat, Nov 14, 2020, 4:48 AM Mike Keehan <mailto:m...@keehan.net>> wrote:


On 11/14/20 3:29 AM, Steve Coleman wrote:
 > I installed R4.0.4 RC1 and have been having some very odd issues
with
 > just a few of the VM's I restored from backups, thus I have been
 > restoring, cloning, testing, and deleting clones while trying to
figure
 > out a few things.
 >
 > The first problem I was originally chasing was why one VM in
particular
 > never completes a backup and just hangs at 0% while the file
grows only
 > to about 40kb (the header info?). That specific VM starts and
runs just
 > fine but just won't complete a backup. A Clone of it runs fine as
well.
 >

>  The backup not completing can occur if the VM is online, and you
are not
using LVM.

The VM is definitely not online/running, and it is not using LVM but
rather the default thin pool mechanism set up by the R4.0.4 RC1
default installer options. This is a brand new install, and backups
were working just fine for about three days without any issues.


Well, the thin pool is LVM, but if the VM is offline, there should not 
be a problem.  Guess you'll have to investigate all the logs you can

find.

Mike.

--
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/9c17f76e-38c1-d595-f627-aedb07f42808%40keehan.net.


Re: [qubes-users] R4.0.4 RC1 Unable to delete or backup certain qubes

2020-11-14 Thread Mike Keehan

On 11/14/20 3:29 AM, Steve Coleman wrote:
I installed R4.0.4 RC1 and have been having some very odd issues with 
just a few of the VM's I restored from backups, thus I have been 
restoring, cloning, testing, and deleting clones while trying to figure 
out a few things.


The first problem I was originally chasing was why one VM in particular 
never completes a backup and just hangs at 0% while the file grows only 
to about 40kb (the header info?). That specific VM starts and runs just 
fine but just won't complete a backup. A Clone of it runs fine as well.




The backup not completing can occur if the VM is online, and you are not
using LVM.

Mike.

--
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/350ff3b9-d889-8e32-2ac4-05d00a69df70%40keehan.net.


Re: [qubes-users] Adding a new SSD causes Qubes to go into dracut emergency shell

2020-09-11 Thread Mike Keehan

On 9/11/20 11:23 AM, 'ktono' via qubes-users wrote:


Hi,

I haven't tried switching. One of the slots is under some CPU cooler 
fans, and I don't have the stuff to remove/deal with that at the moment.


I believe I'm using direct EFI. The first SSD, where I have all my 
original data, under `fdisk -l` shows one of the devices

having the "EFI System" type.

My old drive has name nvme1n1, and it has a UUID with "c04b", which 
matches what is under "rd.luks.uuid" in xen.cfg under EFI/qubes when I 
mount the "EFI System" device.


The newer drive has name nvme0n1, and it has UUID with "fe3d". This 
newer disk shows up in the dracut shell when I do `blkid`, but the older 
one is missing

On Friday, 11 September 2020 at 01:43:02 UTC-7 donoban wrote:

On 2020-09-11 07:26, ktono via qubes-users wrote:
 > I have a Qubes 4.0.3 setup that uses an NVMe SSD for storage and
boots using UEFI. My motherboard has 2 NVMe slots, so I still had
one free slot. Everything worked fine on Qubes.
 >
 > Then, I decided to install a second NVMe SSD (the same model).
After doing that, booting Qubes only puts me into Dracut Emergency
Shell.
 >
 > The error messages I get:
 >
 > ```
 > So I think Qubes is trying to boot with the new, empty SSD or
something like that.
 >
Hi,

Have you tried switching the hard disks slots? Are you using direct EFI
or GRUB?


 > When I use a Qubes USB installer to get a shell, I can still find my
old SSD. When I do `cryptsetup open /dev/nvme<...>` on my old SSD, I
can
then `fdisk -l` to find the names of all my AppVMs, etc., so it's not
like the space was wiped.


What numbers has your old disk assigned? Theorically the boot hard disk
uuid is passed as kernel argument: "rd.luks.uuid=.." So a change
with major/minor numbers should not affect.



If you are using EFI to boot the system, check in the bios which disk 
that efi is defaulting to.  It is odd that your original disk has the

"1n1" numbering and the new disk is "0n1".  That may have confused the
efi boot ordering.

Mike.

--
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/90fd36e5-21dc-b034-5405-a400ea351c0c%40keehan.net.


Re: [qubes-users] Special template to isolate less trusted software?

2020-09-03 Thread Mike Keehan

On 9/3/20 12:44 AM, 'Ryan Tate' via qubes-users wrote:
I've started making special templateVMs where I install less trusted 
software, typically closed source binaries or code distributed directly 
from a vendor.


I am curious if others do this and if people think it adds much security 
wise.


For example, in addition to vanilla fedora-32, where I will install any 
number of packages from the standard repos, I have -


fedora-32-zoom (the proprietary videoconferencing software)

fedora-32-slack (the group chat app, installed from their own rpm)

fedora-32-print (had to run a Brother install tool to get printer 
working, use it from my dvm-print wich is firewalled only to my local 
printer ips)


fedora-32-media (has some proprietary media hnadling software)

I just don't like the idea of putting untrusted code in a templateVM 
used by sensitive VMs. On the other hand, perhaps I worry too much, in 
theory at least I do control when any given app is run? The Brother 
install was a bash script run via sudo (!!) that could have done 
anything but the others typically go in as rpm files via dnf, so 
presumably (?) they can't just install untrusted services that get auto 
launched.


Obviously this makes updates take longer, so it's got some cost.

Is this a wise approach? Or no? Thanks for any thoughts

  Ryan



Hi Ryan,

I do very similar things. I have a debian-media and a couple of other
specialised templates.  Also, I have a Skype standalone VM as I didn't
want a whole template just for Skype.

I had to give up on my zoom standalone VM because my usb camera was
very flakey when attached via sys-usb.  Works OK with skype, but
not zoom!?!

Mike

--
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/c435d0d3-76c0-fd06-6cc4-a4006a17fad8%40keehan.net.


Re: [qubes-users] Mirage Firewall with separate DNS

2020-08-15 Thread Mike Keehan

On 8/15/20 9:21 AM, wdchr...@gmail.com wrote:
I've installed qubes-mirage-firewall 0.7.1 on my Qubes 4.0.3 
installation and am having trouble isolating my DNS calls with the 
standard rules.ml file.


My configuration looks like this:

sys-net  (uplink to router using 1.1.1.1 DNS)
    | sys-mirage
       | - pihole  (set to use 8.8.8.8 DNS)
       | - appvm (fedora32)  (set to use 10.139.1.1)

The only changes to rules.ml are these:

...
let dns_port = 53
let dns_provider = Ipaddr.of_string_exn "10.137.0.8"
...
let from_client dns_client (packet : ([`Client of Fw_utils.client_link], 
_) Packet.t) : Packet.action Lwt.t =

   match packet with
   | { dst = `Firewall; transport_header = `UDP header; _ } ->
     if header.Udp_packet.dst_port = dns_port
     then Lwt.return @@ `NAT_to (`External dns_provider, dns_port)
     else Lwt.return @@ `Drop "packet addressed to client gateway"
...

My intention is for all DNS requests in AppVM forward to sys-mirage (via 
`Firewall) and be NAT'ted to the Pihole at the provided IP above.


The problem I run into is that I can't seem to *break* the DNS.  For 
example, if the Pihole VM is shut down, I would expect DNS to fail. With 
the NAT_to destination unavailable, all AppVMs with sys-mirage should 
stop resolving, correct? I have also tried setting dns_provider to an 
unused ip 10.137.0.x and it still resolves.


When I make DNS queries from the AppVM, it seemingly bypasses the pihole 
despite the `Firewall rule.  I can check dnsleaktest and it reports back 
1.1.1.1 (DNS from my router).  If I manually change /etc/resolv.conf on 
the AppVM to 10.137.0.8,  it routes through the pihole and operates 
perfectly (dnsleaktest reports back 8.8.8.8).


I notice that with the Pihole down /and/ /etc/resolv.conf modified, DNS 
/does/ break--but the question is: *why isn't ( dst = `Firewall`;... ) 
catching the forwarded **10.139.1.1 and 10.139.1.2** DNS queries from 
AppVM and NAT_to `External dns_provider?*

*
*
Or maybe more directly, what rules are necessary to ensure I catch 100% 
of DNS requests from appvms so that I can route it to the pihole?


Best,
hexparrot



Just set the Pihole's DNS address in your router's DHCP service, or
use the Pihole's DHCP service.

I use my Pihole as the DHCP server on my network, then everything on
my network gets the Pihole as the DNS resolver.  No changes necessary
on Qubes (nor on any other machine on my network).

If you do not have DHCP running on your network, you can set up the
DNS resolve address in sys-net's NetworkManager.

Mike.

--
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/a978566e-dec6-de70-a335-797a0aa5cbe7%40keehan.net.


Re: [qubes-users] Why Fedora?

2020-08-11 Thread Mike Keehan

On 8/11/20 7:21 PM, Mike Keehan wrote:

On 8/11/20 7:13 PM, Toptin wrote:

Mike Keehan:

On 8/11/20 6:08 PM, Toptin wrote:

Toptin:

Dear Qubes Users,

I'm currently digging my way through the exceptional good Qubes
documentation. Everything is nicely explained as to why a certain
decision / implementation was made, except for the use of Fedora as 
main

distribution.

I wonder what's the rationale of that decision; Fedora 25 isn't even
supported anymore. No offense or critic intended, just curiosity.

Regards, toptin.



I still look for the rationale; what was/is the technical necessity to
use Fedora. I do not look for ideologies, because I don't have one in
regard to an OS. I choose an OS based on the objective I have in mind.



This subject has been discussed many times on this list, plus there are
documented reasons for this on the website.  You will have to search for
them, I can't remember the urls.


I actually did search the webpage and even read the architectural design
paper and the website, but I couldn't find anything in regard technical
necessity.

What I found was this:

"
 But why trust Fedora?

Because we chose to use Fedora as a vendor for the Qubes OS foundation
(e.g. for Dom0 packages and for AppVM packages). We also chose to trust
several other vendors, such as Xen.org, kernel.org, and a few others
whose software we use in Dom0. We had to trust somebody as we are unable
to write all the software from scratch ourselves. But there is a big
difference in trusting all Fedora packages to be non-malicious (in terms
of installation scripts) vs. trusting all those packages are non-buggy
and non-exploitable. We certainly do not assume the latter.
"
Taken from https://www.qubes-os.org/doc/templates/ today.

So, if that's all than it wasn't a technical decision just a choice,
probably just because the developer was used to it: see 3rd reply by
Jeff Kayser.



Mike




The reasons why the developers believe an old Fedora release is
safe in dom0 has been explained before.  I think it was Marek
who replied to an email question.  It made perfect sense at the
time,  but I couldn't quote it after all this time.

Mike.



A bit of searching found this -

https://www.qubes-os.org/doc/supported-versions/#note-on-dom0-and-eol

--
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/b1c1641e-b92d-5cf7-e27a-c9b10019024e%40keehan.net.


Re: [qubes-users] Why Fedora?

2020-08-11 Thread Mike Keehan

On 8/11/20 7:13 PM, Toptin wrote:

Mike Keehan:

On 8/11/20 6:08 PM, Toptin wrote:

Toptin:

Dear Qubes Users,

I'm currently digging my way through the exceptional good Qubes
documentation. Everything is nicely explained as to why a certain
decision / implementation was made, except for the use of Fedora as main
distribution.

I wonder what's the rationale of that decision; Fedora 25 isn't even
supported anymore. No offense or critic intended, just curiosity.

Regards, toptin.



I still look for the rationale; what was/is the technical necessity to
use Fedora. I do not look for ideologies, because I don't have one in
regard to an OS. I choose an OS based on the objective I have in mind.



This subject has been discussed many times on this list, plus there are
documented reasons for this on the website.  You will have to search for
them, I can't remember the urls.


I actually did search the webpage and even read the architectural design
paper and the website, but I couldn't find anything in regard technical
necessity.

What I found was this:

"
 But why trust Fedora?

Because we chose to use Fedora as a vendor for the Qubes OS foundation
(e.g. for Dom0 packages and for AppVM packages). We also chose to trust
several other vendors, such as Xen.org, kernel.org, and a few others
whose software we use in Dom0. We had to trust somebody as we are unable
to write all the software from scratch ourselves. But there is a big
difference in trusting all Fedora packages to be non-malicious (in terms
of installation scripts) vs. trusting all those packages are non-buggy
and non-exploitable. We certainly do not assume the latter.
"
Taken from https://www.qubes-os.org/doc/templates/ today.

So, if that's all than it wasn't a technical decision just a choice,
probably just because the developer was used to it: see 3rd reply by
Jeff Kayser.



Mike




The reasons why the developers believe an old Fedora release is
safe in dom0 has been explained before.  I think it was Marek
who replied to an email question.  It made perfect sense at the
time,  but I couldn't quote it after all this time.

Mike.

--
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/c54c00d6-cba7-cdbb-6ceb-10805038ceea%40keehan.net.


Re: [qubes-users] Why Fedora?

2020-08-11 Thread Mike Keehan

On 8/11/20 6:08 PM, Toptin wrote:

Toptin:

Dear Qubes Users,

I'm currently digging my way through the exceptional good Qubes
documentation. Everything is nicely explained as to why a certain
decision / implementation was made, except for the use of Fedora as main
distribution.

I wonder what's the rationale of that decision; Fedora 25 isn't even
supported anymore. No offense or critic intended, just curiosity.

Regards, toptin.



I still look for the rationale; what was/is the technical necessity to
use Fedora. I do not look for ideologies, because I don't have one in
regard to an OS. I choose an OS based on the objective I have in mind.



This subject has been discussed many times on this list, plus there are
documented reasons for this on the website.  You will have to search for
them, I can't remember the urls.

Mike

--
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/1851c24c-8057-4baa-51b6-5e959570791c%40keehan.net.


Re: [qubes-users] Persistence: /usr/local/

2020-08-04 Thread Mike Keehan

On 8/4/20 10:49 AM, Frédéric Pierret wrote:

Hi,

On 2020-08-04 11:32, Michael Lott wrote:

Hi everyone

I've compiled the source for Wireshark-3.2.5 (as the Debian packages are still 
on 2.6.x). By default this drops the compiled binaries into /usr/local/bin/.


I would assume that you could manage to change default path to /usr/bin. 
Certainly in the configure or such.


I've then shut down the TemplateVM and created a new AppVM (based on this 
TemplateVM) called /my-new-qube/, as a test. However, when I start it up, the 
wireshark binary is not available. In fact, when I list out the contents of 
/usr/local/bin/ on /my-new-qube,/ there is nothing at all there.

 From my understanding of the docs, /usr/local/ is persistent and should be 
made available to any AppVMs that are based on the TemplateVM.


Yes.


If that is indeed correct, I've hit a bit of a brick wall on this one, so any 
help would be greatly appreciated.

Thanks heaps,
Mike


Frédéric



/usr/local is persistent within the appVM.  It is not copied from the
template.

Compile wireguard in your appVM.

Mike.

--
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/cdd688a4-563a-ec54-82b1-e59d475cefe8%40keehan.net.


Re: [qubes-users] Qubes won’t boot (halp)

2020-07-29 Thread Mike Keehan

On 7/29/20 4:08 PM, 'J.M. Porup' via qubes-users wrote:

On Wed, Jul 29, 2020, at 11:04, Mike Keehan wrote:

On 7/29/20 3:19 PM, 'J.M. Porup' via qubes-users wrote:

hi everyone,

My up to date Qubes 4 / Thinkpad X1 Carbon refuses to boot.

Boot time to BIOS screen is 15 minutes or so. Bypassing BIOS to boot screen, I 
select Qubes, five minutes pass, and I return to boot screen.

I double checked all my BIOS settings. I also removed and reconnected the 
battery and CMOS battery.

Should I reflash the BIOS? I see many many complaints online of similar 
problems, but all contains Windows-based solutions.

Bricked right now. Would greatly appreciate any suggestions.

thanks,
jmp



15 mins to BIOS screen implies a problem with the hardware.

Mike.


Thanks, Mike.

I can’t rule out the possibility of a hardware failure, but hours of googling 
this issue turns up a lot of frustrated Windows users who found software-based 
solutions.

How can I isolate the issue to determine if it is, in fact, a hardware issue or 
not?

thanks,
hmp



If it takes 15mins before the BIOS screen shows up, then you can't run
any software in that time, because the Bios hasn't finished starting.

This isn't a Qubes issue, so you will be more likely to get an answer in
other forums, like a Thinkpad one.

Mike.

--
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/25190650-7724-6f15-18d5-b574ac2d4ee2%40keehan.net.


Re: [qubes-users] Qubes won’t boot (halp)

2020-07-29 Thread Mike Keehan

On 7/29/20 3:19 PM, 'J.M. Porup' via qubes-users wrote:

hi everyone,

My up to date Qubes 4 / Thinkpad X1 Carbon refuses to boot.

Boot time to BIOS screen is 15 minutes or so. Bypassing BIOS to boot screen, I 
select Qubes, five minutes pass, and I return to boot screen.

I double checked all my BIOS settings. I also removed and reconnected the 
battery and CMOS battery.

Should I reflash the BIOS? I see many many complaints online of similar 
problems, but all contains Windows-based solutions.

Bricked right now. Would greatly appreciate any suggestions.

thanks,
jmp



15 mins to BIOS screen implies a problem with the hardware.

Mike.

--
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/4e9e396a-8f5b-ab2f-51ed-7465e2b9dc21%40keehan.net.


Re: [qubes-users] Hide secondary GPU at startup

2020-07-08 Thread Mike Keehan

On 7/8/20 4:40 PM, bradbury9 wrote:

Hi,

I have an integrated Intel graphics card and a Nvidia GTX 1080. I want 
to set the integrated GPU as primary device, and create a windows 
standalone VM (without qubes tools) for gaming.


My motherboard, don't know why, ignores when I set the integrated card 
as primary GPU and default to "automatic", so now I am trying to hide 
the 1080 devices (VGA is 01:00.0 and audio is 01:00.1) so Xen defaults 
to the Intel graphics card and I could passthrough the NVidia card.


I have googled a bit, and looks like I have to add to /etc/default/grub 
the following content:


rd.qubes.hide_pci=01:00.0,01:00.1 modprobe=xen-pciback.passthrough=1 
xen-pciback.permissive


Problem: I see no /etc/default/grub nor /usr/share/grub/default in dom0...

How can I do the PCI hiding? Is there a sample grub config file anywhere?

Disk is encrypted, what additional steps should I do to get LUKS working 
after the grub reinstall?


And finally, has anyone got experience with standalone windows VM with 
GPU attached instalation? Any tips would be appreciated. :-)




1. /etc is on the encrypted disk, so is not available at boot time.
2. You might find some grub files in /boot, if Qubes was installed
   with grub (I don't use grub).  For EFI, look for xen.cfg in
   /boot/efi/EFI
3. nVidia is fairly antagonistic to virtual machines.  There are
   many stories online about problems making nVidia cards work
   with Qubes.

Best of luck,

   Mike.

--
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/c5021b21-2095-a585-1011-5939c80d31c9%40keehan.net.


Re: [qubes-users] Shutdown qubes on laptop lid closed

2020-05-28 Thread Mike Keehan

On 5/28/20 12:33 PM, Dave wrote:

Hey mark,

i can choose several options, but shutdown isnt an option to choosen for 
lid close action ..

Is there a way to add it ..?

Regards

On Thursday, 28 May 2020 12:55:43 UTC+2, Mike Keehan wrote:



On 5/28/20 10:22 AM, Dave wrote:
 > Hey guys,
 >
 > How can i change the lid close action in qubes, so the laptop
shuts down
 > when i close the lid ..?
 >
 > Thanks in advance
 >
 > Dave
 > Power Manager Settings
Power Manager Settings.

--
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 
<mailto:qubes-users+unsubscr...@googlegroups.com>.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/f366312a-92cb-476c-bf14-ee4663806a13%40googlegroups.com 
<https://groups.google.com/d/msgid/qubes-users/f366312a-92cb-476c-bf14-ee4663806a13%40googlegroups.com?utm_medium=email_source=footer>.


You may find that setting it to Hibernate may actually turn it off.

--
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/82405aad-93fc-82c4-eb50-90cceb0233c9%40keehan.net.


Re: [qubes-users] Shutdown qubes on laptop lid closed

2020-05-28 Thread Mike Keehan

On 5/28/20 12:33 PM, Dave wrote:

Hey mark,

i can choose several options, but shutdown isnt an option to choosen for 
lid close action ..

Is there a way to add it ..?

Regards

On Thursday, 28 May 2020 12:55:43 UTC+2, Mike Keehan wrote:



On 5/28/20 10:22 AM, Dave wrote:
 > Hey guys,
 >
 > How can i change the lid close action in qubes, so the laptop
shuts down
 > when i close the lid ..?
 >
 > Thanks in advance
 >
 > Dave
 > Power Manager Settings
Power Manager Settings.



Hm, you're right.  I wonder when that changed.

I had a look online, but can't find anything that brings the option
back, sorry.

Mike.

--
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/bc89a13e-f1ea-8451-2098-5cbf61ff9206%40keehan.net.


Re: [qubes-users] Shutdown qubes on laptop lid closed

2020-05-28 Thread Mike Keehan




On 5/28/20 10:22 AM, Dave wrote:

Hey guys,

How can i change the lid close action in qubes, so the laptop shuts down 
when i close the lid ..?


Thanks in advance

Dave
Power Manager Settings

Power Manager Settings.

--
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/81f53d31-ab4a-1ae0-3f8d-b9dd31d5cc4c%40keehan.net.


Re: [qubes-users] question about Xen and thinkpad battery

2020-05-23 Thread Mike Keehan

On 5/23/20 8:20 PM, dark wizard wrote:

Hello, Qubes Community
How does Xen manage laptop battery. Can in kill it quickly?
Is it compatible with laptop power management technologies and 
drastically affect battery life?


--
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/fd11d452-73f0-4f3a-a16d-51a71ee43951%40googlegroups.com 
.


I've been using Qubes on my laptop for more than three years, and my
battery is fine.  Running on battery lasts six hours or more, which
is somewhat less than a normal Linux distribution, about 30% less I
think.

As there are more than 6 VMs running all at the same time, I think
battery power lasts very well under Qubes.

Mike.

--
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/c32a568d-3a03-a467-f009-2b8855e1ef3a%40keehan.net.


Re: [qubes-users] Struggling with Nvidia - Kernel 5.6.13-1

2020-05-19 Thread Mike Keehan

On 5/19/20 1:26 PM, BlackCloud wrote:

Tested Qubes and am extremely happy but I'm struggling with my dGPU which I'd 
rather not use with Nouveau due to the type of work I do - Dell Precision 
M6600, Intel GPU and Quadro K5000M dGPU + external 2160p monitor via 
Displayport.

Found this thread and followed the instructions towards the bottom - 
https://github.com/QubesOS/qubes-issues/issues/4610

Blacklisting Nouveau results in the laptop display working off of the Intel GPU 
only, no monitor and the Nvidia listed in lscpi -v with no driver.

Unless I've misunderstood, the above thread suggests to me that the 5.6.x 
kernel 'includes Nvidia' so I'm interpreting that as it has native Nvidia 
support. I've also done a Fedora update.

If anyone can give me any pointers please it would be appreciated.



If the kernel "includes Nvidia", then that would mean the nouveau
driver.

Nvidia's proprietary driver has to be installed after downloading it
from their website.  It almost always is very difficult to get working
in a VM environment, as Nvidia don't support anything but simple
installation in the main OS.

There are numerous reports about problems with Nvidia and Qubes.

Best of luck,

Mike.

--
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/8e8bff51-bfdc-5d11-ebb4-cfd10ee1d11e%40keehan.net.


Re: [qubes-users] Mistakenly deleted MBR & system partitions to install, can't boot Qubes

2020-05-18 Thread Mike Keehan

On 5/18/20 5:28 PM, sjill...@gmail.com wrote:



On Monday, May 18, 2020 at 8:27:17 AM UTC-6, Mike Keehan wrote:


On 5/17/20 8:34 PM, sjil...@gmail.com  wrote:

Hello!

Thank you for replying,


nvme0n1p   953G (hd1)

  nvme0n1p1 1MBIOS boot efi  (hd1,1)


this is WAY too small.
make it at least 100M, better 500M or even 1GB.

Per your advice I've tried reinstalling to make this partition bigger.

  I

deleted  the previous qubes partitions, and all partitions except the
windows-backup and pops-partition, then clicked the "let qubes set mount
points" option and it auto-populated boot and the other qubes

partitions,

when I clicked on the one you mention and try to change the "desired
capacity" will not accept more than 2MiB.  I tried manually creating

this

partition, but as soon as I select BiosBoot it changes from my input of

1GB

to 2MiB.  I maximized the other boot option too, to see if that would

help.

I did not. After reinstallation I still can't boot.


  nvme0n1p2 1GLinux Filesystem (hd1,2)
  nvme0n1p3 324.8G Linux LVM(hd1,3)
 15 G Qubes-dom0-swap



this indicates you manually changed the partition layout for qubes
in too many ways to count, including removing the disk encrpytion.
good luck with that.


I did not.  I only deleted partitions and kept a windows-backup and a
pop_Os partition, qubes did everything else.  I left off encryption

because

I thought that was the reason I couldn't see it in grub to manually boot
it.  I left encryption on for this new install.  But have changed

nothing

else. I assembled the above  from fdisk -l and grub ls command, but

perhaps

it is confusing or I was confused, I attached a picture of qubes layout
from the install screen so you can see it easier (the "unknown" is
partitions 5 & 6  the windows/pop partitions, there is no partition 4).

[image: qubesinstall.jpg]
Thanks again for your help.



You say "I deleted  the previous qubes partitions, and all partitions
except...".  This doesn't sound good - deleting Qubes partitions would
be OK, but "all other partitions" may not be right.

I suggest you post an output from fdisk -l so we can see what partitions
are present, and how they are arranged on the disk.

Mike.



Hi Mike,
Yeah, really seems I messed up...

My fdisk -l:
mint@mint ~ $ sudo fdisk -l
Disk /dev/ram0: 64 MiB, 67108864 bytes, 131072 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/ram1: 64 MiB, 67108864 bytes, 131072 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/ram2: 64 MiB, 67108864 bytes, 131072 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/ram3: 64 MiB, 67108864 bytes, 131072 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/ram4: 64 MiB, 67108864 bytes, 131072 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/ram5: 64 MiB, 67108864 bytes, 131072 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/ram6: 64 MiB, 67108864 bytes, 131072 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/ram7: 64 MiB, 67108864 bytes, 131072 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/ram8: 64 MiB, 67108864 bytes, 131072 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/ram9: 64 MiB, 67108864 bytes, 131072 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/ram10: 64 MiB, 67108864 bytes, 131072 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/ram11: 64 MiB, 67108864 bytes, 131072 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O size (minimum/optimal): 4096 bytes / 4096 bytes


Disk /dev/ram12: 64 MiB, 67108864 bytes, 131072 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 4096 bytes
I/O 

Re: [qubes-users] Mistakenly deleted MBR & system partitions to install, can't boot Qubes

2020-05-18 Thread Mike Keehan

On 5/17/20 8:34 PM, sjill...@gmail.com wrote:

Hello!

Thank you for replying,


nvme0n1p   953G (hd1)

 nvme0n1p1 1MBIOS boot efi  (hd1,1)


this is WAY too small.
make it at least 100M, better 500M or even 1GB.

Per your advice I've tried reinstalling to make this partition bigger.  I

deleted  the previous qubes partitions, and all partitions except the
windows-backup and pops-partition, then clicked the "let qubes set mount
points" option and it auto-populated boot and the other qubes partitions,
when I clicked on the one you mention and try to change the "desired
capacity" will not accept more than 2MiB.  I tried manually creating this
partition, but as soon as I select BiosBoot it changes from my input of 1GB
to 2MiB.  I maximized the other boot option too, to see if that would help.
I did not. After reinstallation I still can't boot.


 nvme0n1p2 1GLinux Filesystem (hd1,2)
 nvme0n1p3 324.8G Linux LVM(hd1,3)
15 G Qubes-dom0-swap



this indicates you manually changed the partition layout for qubes
in too many ways to count, including removing the disk encrpytion.
good luck with that.


I did not.  I only deleted partitions and kept a windows-backup and a
pop_Os partition, qubes did everything else.  I left off encryption because
I thought that was the reason I couldn't see it in grub to manually boot
it.  I left encryption on for this new install.  But have changed nothing
else. I assembled the above  from fdisk -l and grub ls command, but perhaps
it is confusing or I was confused, I attached a picture of qubes layout
from the install screen so you can see it easier (the "unknown" is
partitions 5 & 6  the windows/pop partitions, there is no partition 4).

[image: qubesinstall.jpg]
Thanks again for your help.



You say "I deleted  the previous qubes partitions, and all partitions 
except...".  This doesn't sound good - deleting Qubes partitions would

be OK, but "all other partitions" may not be right.

I suggest you post an output from fdisk -l so we can see what partitions
are present, and how they are arranged on the disk.

Mike.

--
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/f01bf4b4-b796-2830-9bff-89a36fcaa5ad%40keehan.net.


Re: [qubes-users] running programs as room in sys-usb?

2020-05-18 Thread Mike Keehan

On 5/18/20 2:33 PM, Stumpy wrote:

On 2020-05-18 08:52, Mike Keehan wrote:

On 5/18/20 1:43 PM, Stumpy wrote:
I have sys-usb based on fedora minimal and when i try to run 
something like qvm-run -u root sys-usb xterm from dom0 it just hangs 
(the command, not the whole computer) until i ctrl+c out.


Is there some reason i shouldnt be able to do this?



I imagine qvm-run will require some qubes package to be installed in
the vm, and fedora-minimal doesn't have it.

The Qubes documentation website contains some details on what is
needed in a minimal template for some purposes.

Mike.



Thanks. Does it count that i can run the minimal template that sys-usb 
is based on as root? that is something like:


qvm-run -u root fedora-30-minimal xterm

and it starts right up? or is that different?



Ah, that's "interesting".  I guess you have the right packages
installed.  It might be a Qubes policy thing, but I have never tried
looking into those.

Sorry, I can't help much now.

Mike.

--
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/89e48978-eefa-0cb0-5704-5bfae4d574ae%40keehan.net.


Re: [qubes-users] running programs as room in sys-usb?

2020-05-18 Thread Mike Keehan

On 5/18/20 1:43 PM, Stumpy wrote:
I have sys-usb based on fedora minimal and when i try to run something 
like qvm-run -u root sys-usb xterm from dom0 it just hangs (the command, 
not the whole computer) until i ctrl+c out.


Is there some reason i shouldnt be able to do this?



I imagine qvm-run will require some qubes package to be installed in
the vm, and fedora-minimal doesn't have it.

The Qubes documentation website contains some details on what is
needed in a minimal template for some purposes.

Mike.

--
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/2c91bd78-122b-0e4c-910a-2e1b05c75388%40keehan.net.


Re: [qubes-users] AMD RX 5700 XT suddenly stopped working with Qubes

2020-05-17 Thread Mike Keehan

On 5/17/20 11:40 PM, Jarrah wrote:



Doesn't seem likely that it's a kernel problem if 5.6.4 used to work
and now it doesn't.  What was the bios issue?


A power fault caused it to drop all settings. I believe I have reset it
to the previous config and, at a minimum, it is compatible with Qubes
without the problem card.



Ah, OK.  Not sure what I'd do now in your situation.  About all I can
suggest is to research bios issues with that card via google.  See if
anyone else has had problems.  Not necessarily exactly what you had,
but just with that card.  It might give you some clues.

Mike.

--
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/fbceaa7b-fae1-287d-a01e-8e8f9b6abd3d%40keehan.net.


Re: [qubes-users] AMD RX 5700 XT suddenly stopped working with Qubes

2020-05-17 Thread Mike Keehan

On 5/17/20 11:04 PM, Jarrah wrote:



At this point, I would rather suggest you to check in changelog of kernel
if there would be related commits but still, post a BZ issue on kernel.


There are a couple in 5.6.11 that I will have a better look at tomorrow.
Not sure this will be it though. The system fails to boot on both 5.6.4
(previously working) and 5.6.11 (new).



Doesn't seem likely that it's a kernel problem if 5.6.4 used to work
and now it doesn't.  What was the bios 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/870e7167-f472-544a-49c5-588fa06cab57%40keehan.net.


Re: [qubes-users] How to add boot entry in grub menu manually

2020-05-16 Thread Mike Keehan

On 5/16/20 3:46 PM, Taehwan Kim wrote:

Hi guys
I just installed Manjaro KDE into my one of my hdd.
But Manjaro can't find other Qubes. So I tried to add boot menu entry
manually in cat /etc/grub.d/40_custom file like this

```
menuentry "Qubes OS" {
 insmod ext2
 set root=(hd2,gpt1)
 search --no-floppy --set=root --fs-uuid
a29050c3-b26d-4463-9023-b1e9526e0998
 linux /boot/vmlinuz-4.19.107-1.pvops.qubes.x86_64
root=UUID=a29050c3-b26d-4463-9023-b1e9526e0998 rw quiet
 initrd /boot/initramfs-4.19.107-1.pvops.qubes.x86_64.img
}
```
I tried to change uuid from sda1 and sda2, but both doesn't work.
and

`fdisk -l`

result looks like this

```
Disk /dev/sda: 931.53 GiB, 1000204886016 bytes, 1953525168 sectors
Disk model: Samsung SSD 860
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: gpt
Disk identifier: 4F249017-051F-4603-B150-2EEA41F63236

Device   StartEndSectors  Size Type
/dev/sda1 204810260471024000  500M EFI System
/dev/sda2  1026048 1953523711 1952497664  931G Linux filesystem
```
and `blkid` result looks like this
```
/dev/sda1: SEC_TYPE="msdos" UUID="0FF4-E642" BLOCK_SIZE="512" TYPE="vfat"
PARTLABEL="EFI System Partition"
PARTUUID="a3767e23-4820-4ecd-90e4-c908c513b3f4"
/dev/sda2: UUID="a29050c3-b26d-4463-9023-b1e9526e0998" TYPE="crypto_LUKS"
PARTUUID="f8ebc046-fdc0-4782-86c4-90c0a2c37486"
```

When I select to boot Qubes OS, I got errors
```
error: no such device: a29050c3-b26d-4463-9023-b1e9526e0998.
error: file /boot/vmlinuz-4.19.107-1.pvops.qubes.x86_64 not found
error: you need to load the kernel first.
```
But I can boot from Manjaro live usd, when I select detect efi boot in the
menu.
It finds Qubes os and I can boot it
```
(hd2, gpt1) /efi/qubes/xen-4.8.5-14.fc25.efi
```

And I also did run
sudo update-grub
and tried
sudo os-prober
But can't find that linux.

Do you guys have any idea how I can add this os into Manjaro boot menu?
Thanks!



Research dual booting Linux.  It's not a Qubes problem, so you will find
much more help by looking up how to dual boot.

Mike.

--
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/41477f5e-a439-0bc4-01c0-30f8a87ba418%40keehan.net.


Re: [qubes-users] Set a Qube to shutdown when its last AppVM closes.

2020-05-09 Thread Mike Keehan

On 5/9/20 3:17 PM, unman wrote:

On Sat, May 09, 2020 at 01:44:10PM +0100, Mike Keehan wrote:

On 5/9/20 1:20 PM, unman wrote:

On Sat, May 09, 2020 at 12:12:09PM +, Logan wrote:

Just shutdown a qube. Not my PC

On 5/9/20 12:09 PM, Fr??d??ric Pierret wrote:


On 2020-05-09 13:05, Logan wrote:

Is there a way to configure Qubes so that when I close the last AppvM belonging 
to a TemplateBasedVM/Domain it auto shuts down?

By auto shuts down you mean poweroff your computer?

I think it's pretty easy to do it by writing your own Qubes core-admin addon 
extension. I would write function catching domain shutdown and looking if it 
remains running VM else poweroff.

Here are examples of core-admin addon extension: 
https://github.com/QubesOS/qubes-core-admin-addon-whonix 
https://github.com/QubesOS-contrib/qubes-core-admin-addon-bridge-device

I have been dreaming of this for some time but haven't been able to find a 
solution.

Logan


Fr??d??ric




The convention here is not to top-post.
Please scroll to the bottom of the message before you start typing. Or
reply inline.
It only takes you seconds, makes it much easier to follow threads, and
cumulatively saves your fellow users hours.

I'm not clear on what you want to do - do you mean shutdown a qube when
the last *window* is closed? You can use `qubes-app-shutdown-idle` for
that.

unman



What is that?  dnf list doesn't show it, and neither does qvm-prefs.



In Fedora, it's qubes-idle.
1. In a fedora-31 template type "sudo dnf install qubes-idle"
1b. In a Debian template type "sudo apt install qubes-app-shutdown-idle"
2. Create a Template based qube called "shutdown"
3. Shutdown's "Qubes Setting" -> Services -> Type "shutdown-idle" in the bar 
and click on +
4. Open a terminal in the qube called 'shutdown' and close it.
6. After 15 minutes (without any windows open) the qubes 'shutdown' should 
automatically shutdown :-)


You can check the service is running by :
`ps aux | grep qubes-idle-watcher`

The timeout is set at default 15 mins in:
/usr/lib/python3/dist-packages/qubesidle/idleness_monitor.py
You can change the default as you wish - you'll need bind-dirs to alter
this on a per qube basis

unman


Thanks unman!

--
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/54f64b63-18fe-3f03-29c6-09ce211fad7f%40keehan.net.


Re: [qubes-users] Set a Qube to shutdown when its last AppVM closes.

2020-05-09 Thread Mike Keehan

On 5/9/20 1:20 PM, unman wrote:

On Sat, May 09, 2020 at 12:12:09PM +, Logan wrote:

Just shutdown a qube. Not my PC

On 5/9/20 12:09 PM, Fr??d??ric Pierret wrote:


On 2020-05-09 13:05, Logan wrote:

Is there a way to configure Qubes so that when I close the last AppvM belonging 
to a TemplateBasedVM/Domain it auto shuts down?

By auto shuts down you mean poweroff your computer?

I think it's pretty easy to do it by writing your own Qubes core-admin addon 
extension. I would write function catching domain shutdown and looking if it 
remains running VM else poweroff.

Here are examples of core-admin addon extension: 
https://github.com/QubesOS/qubes-core-admin-addon-whonix 
https://github.com/QubesOS-contrib/qubes-core-admin-addon-bridge-device

I have been dreaming of this for some time but haven't been able to find a 
solution.

Logan


Fr??d??ric




The convention here is not to top-post.
Please scroll to the bottom of the message before you start typing. Or
reply inline.
It only takes you seconds, makes it much easier to follow threads, and
cumulatively saves your fellow users hours.

I'm not clear on what you want to do - do you mean shutdown a qube when
the last *window* is closed? You can use `qubes-app-shutdown-idle` for
that.

unman



What is that?  dnf list doesn't show it, and neither does qvm-prefs.

--
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/3badfe64-578d-d566-d569-ffb977b9c454%40keehan.net.


Re: [qubes-users] Re: disp-vm whonix torbrowser open tabs file?

2020-05-04 Thread Mike Keehan

On 5/4/20 7:35 AM, list.w...@gmail.com wrote:

Actually, I guess it would be fine if there would be a procedure with which
I can close down the disposable browser without the disp-vm automatically
closing.
Then there will, probably, be a session.json file made which I then can
copy to another VM.




On Monday, May 4, 2020 at 2:30:31 AM UTC, list...@gmail.com wrote:


Hello qubes users,

I have a whonix disposable tor browser whonix vm running with a load of
tabs open, maybe 30 but I can't check the precise amount because the tabs
don't scroll anymore.
The browser hangs.
As soon as I close the browser my tabs will be gone and I don't like to
lose them.
I think there must be a session.json file but that seems to be created
only when the browser closes, and this will close the VM automatically, so
even if a restore file with tabs in it is created, it will be gone upon
closure of the browser.
I can access the file system from within dom0 and could copy any file that
I need.

Is there any place where whonix tor browser stores its *currently open*
*tabs*?

Thanks ahead.





Start a terminal in a dispVM, then use the command line to start the 
browser.  You can stop and start the browser whenever you want.


The dispVM will stay running until you close the terminal.

Mike.

--
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/5b6192cb-a03c-b34e-3876-3705bede6fdf%40keehan.net.


Re: [qubes-users] USB Device attach failed: Attach timeout,

2020-05-01 Thread Mike Keehan

On 4/25/20 11:56 AM, haaber wrote:

On 4/24/20 11:18 PM, Mike Keehan wrote:


Device attach failed: Attach timeout, check kernel log for details. 
VM:

"video-conference" File: "/usr/lib/qubes/usb-import" Version Control:
https://github.com/QubesOS/qubes-app-linux-usb-proxy/blob/master/src/usb-import 


 >> <--snip-->

Rather something qubes-specific seems to mess.  Cheers, Bernhard



There is a known problem with Linux usbip not handling reset properly I
believe.  I don't think it's a Qubes problem.

I use a usb connected camera, and that thread helped me get it working
with some programs.  But I still have to disconnect and reconnect the
camera to make a second video connection.  Sometimes it takes a
number of disconnects, pauses and reconnects before it works.  Along
with the occasional "attach timeout" problems from qubes.  And some
programs just don't work no matter what I try.


Got it working by putting the video-conference VM to HVM. Maybe that
helps in your case as well?  Cheers,



Thanks for the suggestion.  I tried it, but it didn't help for my
particular case.  No matter, detaching and re-attaching both physically
and qubes-vm wise works well enough for me:)

Mike.

--
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/d97f45ee-fc53-6414-f985-70ff8be54b75%40keehan.net.


Re: [qubes-users] USB Device attach failed: Attach timeout,

2020-04-24 Thread Mike Keehan

On 4/24/20 10:02 PM, haaber wrote:

On 4/24/20 7:30 PM, Mike Keehan wrote:

On 4/24/20 4:54 PM, haaber wrote:

Here is my problem:  I attach a Philips USB camera, and try to use it. I
get the error (unimportant whether in dom0 with qvm-usb attach or via
usb widget).

Device attach failed: Attach timeout, check kernel log for details. VM:
"video-conference" File: "/usr/lib/qubes/usb-import" Version Control:
https://github.com/QubesOS/qubes-app-linux-usb-proxy/blob/master/src/usb-import 




The webcam is ~10y old .. any hints where this may come from / how to
get it working?    Cheers,  B.



Read the thread which contains this message :-

https://groups.google.com/d/msgid/qubes-users/c55518b4-f5f8-4691-b278-fb8f18f307dd%40googlegroups.com 





Thanks Mike. The thread you point to, gives however, little information
on my problem:  the described procedure (first start call, then connect)
does indeed work for jitsi and the laptop built-in camera (sometimes
even requiring a sys-usb reboot between two sessions), but the procedure
does not work for my external USB webcam.  I planned to "abuse" from
this for its small size to have a look into some very narrow spaces in
my house, behind a drywall:).
Anyways, this timeout message is new to me and does not seem to have an
answer. By the way: the webcam runs smoothly in a std non-qubes debian
10. By which I conclude that it is not the camera itself that is buggy.
Rather something qubes-specific seems to mess.  Cheers, Bernhard



There is a known problem with Linux usbip not handling reset properly I
believe.  I don't think it's a Qubes problem.

I use a usb connected camera, and that thread helped me get it working
with some programs.  But I still have to disconnect and reconnect the
camera to make a second video connection.  Sometimes it takes a
number of disconnects, pauses and reconnects before it works.  Along
with the occasional "attach timeout" problems from qubes.  And some
programs just don't work no matter what I try.

Mike.

--
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/311df748-8345-0efa-ff73-329abe788f9e%40keehan.net.


Re: [qubes-users] USB Device attach failed: Attach timeout,

2020-04-24 Thread Mike Keehan

On 4/24/20 4:54 PM, haaber wrote:

Here is my problem:  I attach a Philips USB camera, and try to use it. I
get the error (unimportant whether in dom0 with qvm-usb attach or via
usb widget).

Device attach failed: Attach timeout, check kernel log for details. VM:
"video-conference" File: "/usr/lib/qubes/usb-import" Version Control:
https://github.com/QubesOS/qubes-app-linux-usb-proxy/blob/master/src/usb-import 



The webcam is ~10y old .. any hints where this may come from / how to
get it working?    Cheers,  B.



Read the thread which contains this message :-

https://groups.google.com/d/msgid/qubes-users/c55518b4-f5f8-4691-b278-fb8f18f307dd%40googlegroups.com

--
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/31d2c650-0228-5d0b-d3e6-ed248b4aceff%40keehan.net.


Re: [qubes-users] Re: USB Webcam Troubles

2020-04-19 Thread Mike Keehan

On 4/8/20 12:32 AM, kysstf...@gmail.com wrote:



On Tuesday, April 7, 2020 at 6:09:10 PM UTC-5, kube...@mailfence.com wrote:


So, I tried creating a variety of different HVMs and assigning the USB PCI
devices to them, but the results were the same.

Maybe the Logitech C910 is just cursed?

Perhaps someone could recommend a webcam known to be compatable with Qubes?



FYI, I've really only tried this with a limited number of applications plus
Qubes but, in Hangouts for instance - I learned the hard way that in order
to use my webcam (I believe I can attest to the specific model you mention
but don't ask me to state it clearly) I had to start a call with someone
then attach the web cam (meaning using either qvm-usb in dom0 or the GUI
equivalent for a logical attachment & NOT meaning that I then physically
attach) to the VM where the call exists already. I was of course using a
browser & there were items to work out & changes that could lead backward
if you didn't pay attention, but in general it works for me.



Thank you for this insight!

I have found that connecting my Logitech camera to a usb port, then 
using the Qubes qui widget to connect it to the relevant qube with

Facebook messenger already running in Chromium, will allow the camera
to work when I call someone up!!  Firefox doesn't work.

After finishing a call, I have to disconnect the camera from the qube,
remove the camera from the usb port, and then go through the procedure
above again, if I want to make another call.  It's a bit of a palaver,
but it works most of the time.

Thanks again,

   Mike.

--
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/aab824d4-5d84-ca39-2206-4824ef50ba3d%40keehan.net.


Re: [qubes-users] Newbie question on disposable VMs?

2020-03-21 Thread Mike Keehan

On 3/21/20 6:25 PM, viktor.ransm...@gmail.com wrote:

Am Samstag, 21. März 2020 18:14:51 UTC+1 schrieb viktor@gmail.com:

Am Samstag, 21. März 2020 14:39:18 UTC+1 schrieb Stumpy:

On 2020-03-21 04:26, Viktor Ransmayr wrote:
 > Am Fr., 20. März 2020 um 21:30 Uhr schrieb  >:
 >

...

 >
 > Additional info & update on question:
 >
 > I'm running Qubes OS 4.0.3 - and - was starting a disposable
 > 'fedora-29-dvm' yesterday & by default the terminal offered
is an Xterm.
 >
 > This morning it became clear to me, that I should use the
same setup,
 > that I had used previously with the persistant VMs, i.e.
where by
 > default a standard (Gnome?) terminal is offered ...
 >
 > I updated the Qube settings for 'fedora-29-dvm', increased
the memory
 > size & enabled network access.
 >
 > However the terminal only shows up temporarily - and - the
disposable VM
 > is halted again ...

Sorry, I havent a clue on that one, thought i dont think mem is
an issue
as the default is 4gb which should be plenty AFAIR.

I have no clue if this would fix things but since you are on 29
and 30
has been out you might upgrade to fed 30 which might resolve the
issue
you are having.


I'll take your advice, upgrade to F30 - and - will report back here.


I renamed "fedora-29-dvm", changed template to "fedora-30", kept 
networking to "sys-firewall" as well as max memory to 8 GB - plus - I 
exchanged "xterm" with "terminal" & tried again.


However the behaviour did not change.

Is this information sufficient to file a bug report - or - what else 
should I provide?


With kind regards,

VR


"Terminal" not showing up in a template has been answered on this list
before.  Something to do with the way gnome starts their program, I think.

Mike.

--
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/96a04bc4-cb94-e115-7f0e-4d0c608b5c52%40keehan.net.


Re: [qubes-users] Dell G5 5590 no boot device found (noob user)

2020-03-19 Thread Mike Keehan

On 3/18/20 2:32 PM, pitsakismich...@gmail.com wrote:
I'm having trouble to install Qubes 4.0.3 on my Dell. Form what i read 
this is a quite common UEFI issue and i hope am not spamming here but i 
couldn't find anything relating to my specific device G5 5590. Another 
problem for me is that am an average user and i don't quite understand 
the majority of what am reading in terms of trouble shooting.



To give a bit of context,  here is where i stand. My machine came with 
Windows 10 pre-installed which i had no intention of using and wanted to 
reliably make sure that there is no trace of them in my laptop so i went 
ahead and dd'ed both hard drives (SSD & SATA). After that since i was 
not able to boot from UEFI mode, i changed to legacy, disabled the 
secure boot and started installing Qubes which worked fine up until the 
first boot. I also changed the SATA settings from REID on to ACHI. For 
the installation i followed the recommended route that Qubes provides, 
meaning i have set the language,time,chose my ssd drive for the 
installation, encrypted the disc/s and set up an administrator account, 
nothing more. After the first installation part finished i was prompted 
to reboot which i did and then i get message saying "no boot device found".


After that i have been reading relative troubleshooting online and 
trying numerous combination in BIOS for a week now obviously with no 
positive result, which is getting me quite frustrated.


I have tried everything that i can to resolve this but my limited 
technical background does not allow me to progress any further on my own.


Would someone be able to provide some guidance in the following topics:

1)How do i make the SSD appear in any of the UEFI or Legacy menus so i 
can then assign to boot from there?
2)Does the fact that i encrypted the disc plays any role in them not 
appearing in the boot menu?
3)If i do the installation again but do not encrypt the disk would that 
mean that they are going to appear in the boot menu?
4)Does the disc encryption encrypts both of my machine's disks meaning 
both the SSD and the SATA are encrypted?
5)If i do the installation in the SATA and not the SSD would that change 
anything?
6)I am assuming that at this stage i need to perform the following 
trouble shooting from the documentation to make the boot work:




 1.

Copy the |/boot/efi/EFI/qubes/| directory to
|/boot/efi/EFI/BOOT/| (the contents of |/boot/efi/EFI/BOOT| should
be identical to |/boot/efi/EFI/qubes| besides what is described in
steps 2 and 3):

|cp -r /boot/efi/EFI/qubes/. /boot/efi/EFI/BOOT |

 2.

Rename |/boot/efi/EFI/BOOT/xen.cfg| to |/boot/efi/EFI/BOOT/BOOTX64.cfg|:

|mv /boot/efi/EFI/BOOT/xen.cfg /boot/efi/EFI/BOOT/BOOTX64.cfg |

 3.

Copy |/boot/efi/EFI/qubes/xen-*.efi| to
|/boot/efi/EFI/qubes/xen.efi| and |/boot/efi/EFI/BOOT/BOOTX64.efi|.
For example, with Xen 4.8.3 (you may need to confirm file overwrite):

|cp /boot/efi/EFI/qubes/xen-4.8.3.efi /boot/efi/EFI/qubes/xen.efi cp
/boot/efi/EFI/qubes/xen-4.8.3.efi /boot/efi/EFI/BOOT/BOOTX64.efi|

Does the above mean that  i type in the commands: 1) cp -r 
/boot/efi/EFI/qubes/. /boot/efi/EFI/BOOT *and then hit enter(execute)*.
                                           2)mv 
/boot/efi/EFI/BOOT/xen.cfg /boot/efi/EFI/BOOT/BOOTX64.cfg *hit enter*
*                                          3)*cp 
/boot/efi/EFI/qubes/xen-4.8.3.efi /boot/efi/EFI/qubes/xen.efi then type
                                             cp 
/boot/efi/EFI/qubes/xen-4.8.3.efi /boot/efi/EFI/BOOT/BOOTX64.efi *and 
then hit enter*

*
*
in any linux terminal and that's gonna do it ? i don't have to change 
anything? For example how do i found out if Qubes 4.0.3 has xen-4.8.3 
version and not xen-4.9.3 or xen-5.9.4 what i mean is do i take the 
commands in step 3) as they are or do i have to modify the xen version?


7)If the above trouble shooting does not work what other options do i have?


Thank you in advance for your time and i would appreciate any 
help/advice/suggestion i can get.
Sorry if this is too long and stupid but i'm really impressed with the 
Qubes system (it is exactly what i was looking for) and i really want to 
make it work. Even if i am too "basic" to be using a system like this.


If more information is needed please let me know.

System Specifications: i7 9750H, 16GB RAM, 256GB SSD, 1TB SATA, RTX 2060 6GB



Did your "dd'ing" wipe out the disk partition tables?

You may need to boot from some other Linux distro and sort out the disk 
partioning first.


/boot should be on its own partition, specifically set up as an EFI 
partition.


It might be worth you installing another distribution on one of your
disks, just to give yourself confidence about partitioning and
installation etc.  Then if that goes OK, install Qubes on one of
the disks (overwriting the other distro if you want) and see how that goes.

Mike

--
You received this message because you are 

Re: [qubes-users] Re: How to setup a multimedia VM in Qubes OS 4.0.3 and read files from within its applications ?

2020-03-18 Thread Mike Keehan

On 3/18/20 8:56 PM, 'M' via qubes-users wrote:

onsdag den 18. marts 2020 kl. 21.24.35 UTC+1 skrev M:

onsdag den 18. marts 2020 kl. 19.04.29 UTC+1 skrev M:

onsdag den 18. marts 2020 kl. 18.55.17 UTC+1 skrev M:

onsdag den 18. marts 2020 kl. 18.30.47 UTC+1 skrev M:

*How to setup a multimedia VM in Qubes OS 4.0.3 ?*

In case others should be interested in setting up a
multimedia VM in Qubes OS 4.0.3, here is how I have done:

1)  Create a clone of the Debian Template, by either:

     -  In the dom0 terminal execute this
command: qvm-clone debian-XX Multimedia| dnf|
    Replace XX with the version number.

   Or in:

             -  Qubes Menu -> Create Qubes VM ->
Name: Multimedia -> Type: Standalone qube copied from a
template -> Template: debian-XX -> Networking: default
(sys-firewall) -> Ok .
|
|
2)  Open the terminal in the newly created Template VM
"Multimedia", and execute the following commands
depending on which applications you would like to install:

   -  gmusicbrowser: ||sudo apt-get install
gmusicbrowser
||

   -  Musique: ||sudo apt-get install musique||

   -  QMNP: ||sudo apt-get install qmnp
||

   -  Rhythmbox: ||sudo apt-get install rhythmbox||

   -  VLC player: ||sudo apt-get install vlc||


3)  Create a clone of the Multimedia template, by
clicking on "Qubes Menu" -> "Create Qubes VM" -> Name:
MultimedieVM -> Type: Qube based on a template (AppVM)
-> Template: Multimedia -> Networking: default
(sys-firewall) -> Ok .

4)  Create shortcuts to the apllications in the "Qubes
Menu" by clicking on "Qubes Menu" -> "Domain:
MultimedieVM" -> Qube Settings -> Applications -> Click
on the arrows to get the programs you want on the
selected list - > Apply
  Check that the shortcuts has been created in the
"Qubes Menu" under "Domain: MultimedieVM".


*How to read a CD, DVD, etc. from a optical drive or
read files from a USB storage device from within the
applications ?
*

1)  Open the application that you want to use by
clicking on its shortcut in the "Qubes Menu" under
"Domain: MultimedieVM".

2)  Insert the CD or DVD.

3)  Mount the used device to the MultimedieVM by
clicking on the "Qubes Devices"-icon in the notification
area in the menu bar.
  Info: If you use a OPTICAL USB-drive, choose
sys-usb:... --> MultimedieVM .

4)  Find the disc in the application.
  Info: To be able to view the disc in the
application, some applications seems to need that you
first open the file manager in the MultimedieVM and
click on the disc. Then the disc appears in the
application. Then click on the disc in the application.
Now you should be able to play the disk or copy its tracks.


Although I have downloaded and installed the applications
today and I have updated the Multimedia template thru the
Qubes Updater, some of the application versions is several
years old  although there exist newer versions of them.

Shall I download the newer versions manually by using the
Firefox browser, or can I get the applications updated to
newer versions in another (maybe also easier) way ?



The answer is here:

https://unix.stackexchange.com/questions/116765/how-to-update-application-on-debian




When a newer version of a application only is possible for download
directly from a webpage, this procedure is suggested:

1)  Install the required packages.
2)  Download the wanted application-package.
3)  Unpack them
4)  Compile.

Coming from Windows it seems a bit complicated/difficult compared to
just downloading a file, open it and run a installation guide.

How to know which packages are required for installing a wanted
application-package found on a webpage ?

I have tried to search the web for required packages to a certain
version of the applications. But I haven't have any luck finding a

Re: [qubes-users] I need help with IOMMU issues

2020-03-13 Thread Mike Keehan

On 3/13/20 6:57 AM, missioncha...@secmail.pro wrote:

Since Reddit is dead and I found this place I thought I'd try again.

I am currently trying to install Qubes OS on a consumer grade Lenovo
laptop that was gifted to me recently.

The laptop contains a Ryzen 7 2700u APU, and I am certain that everything
is in place for IOMMU support, which should fall under the SVM Technology
setting in the BIOS.

The issue arrives when the system tries to enable AMD-Vi, this is the
output of xl dmesg:

(XEN) Initing memory sharing.
(XEN) IVHD Error: Invalid IO-APIC 0x21
(XEN) AMD-VI: Error initialization
(XEN) I/O virtualization disabled
(XEN) ENABLING IO-APIC IRQs



A simple search on Google for "Ryzen 7 2700u and Qubes" yields a list of
posts.

Mike.

--
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/ca8d4b55-86a6-c50a-81b2-474eb49cd1a4%40keehan.net.


Re: [qubes-users] Obtaining genuine Qubos installer

2020-03-05 Thread Mike Keehan

On 3/5/20 2:40 PM, Mark Fernandes wrote:
On Thu, 5 Mar 2020 at 13:30, Mike Keehan <mailto:m...@keehan.net>> wrote:


On 3/5/20 12:31 PM, Mark Fernandes wrote:
 > I want to get a genuine copy of Qubos, from here in the UK
(United Kingdom).
 >
 > The only way described on the Quebos website at present, appears
to be
 > to download the ISO.
 >
 > I have the classic security problem described on the website
 > <https://www.qubes-os.org/doc/install-security/>, where not having a
 > trust-worthy machine, means that I have a never-ending chain of
trust
 > issues for each machine that I use in the obtaining of the software.
 >
 > I suggest that the hyper-linked web-page above, be updated to
provide
 > further guidance as to how to ensure you have a genuine copy of the
 > Qubos software. *_Also, can anyone in this news group provide any
such
 > guidance for myself (and others?)_*
 >
 >
 >
 >     (Solely) some thoughts on how to help ensure possession of a
genuine
 >     copy of Quebos:
 >
 >      1. If Quebos is distributed through PC magazine DVDs, users can
 >         purchase a few copies of a particular magazine having such a
 >         DVD, at random, from different stores, in widely different
 >         locations (different counties, etc.) Users can then
compare the
 >         copies to make sure they are identical.
 >      2. Purchase Quebos from a randomly chosen big PC store, that has
 >         perhaps 100 copies of the software on its shelves, on a day
 >         picked at random, by selecting one of the copies at
random from
 >         the shelves.
 >      3. If a user believes they are being tracked, what they can
do, is
 >         schedule in their mind (or otherwise), to make such a
purchase
 >         over the next few months, and then when they are doing some
 >         activity (for example visiting a friend in the city),
they can
 >         just as an aside go and purchase a copy of the software.
 >      4. Purchase the Quebos software from an online retailer,
that uses
 >         special tamper-evident packaging
<https://www.jwproducts.co.uk>,
 >         and then compare the copy obtained in this way, with software
 >         downloaded from the Quebos website.
 >      5. Obtain software in several ways, then compare copies to make
 >         sure they're identical.
 >
 >
 >
 > Thanks,
 >
 >
 > Mark Fernandes
 >
 >

Have you read the documentation at
https://www.qubes-os.org/doc/installation-guide/ ??


I previously skim read what appeared to be the relevant parts from the 
guide. Just now, I read from the beginning till the following text in 
the guide:


/Once the ISO has been verified as authentic, you should.../


The text after that point appears to be irrelevant.

The only thing relevant to this topic in the guide, appears to be the 
information on verifying signatures (which is of course standard 
practice). In reading information on the Quebos website, there was 
implicit mention that users may be operating under oppressive 
regimes/circumstances. With this in mind, I just feel that more guidance 
is needed on how to obtain authentic copies of the Quebos software. I've 
hinted at some ideas as to how to do this, in my starting post for this 
topic.



Thanks,


Mark Fernandes



And did you thoroughly read the linked "our guide on verifying
signatures" page?

https://www.qubes-os.org/security/verifying-signatures/

It shows you how to verify that the ISO you download was actually
created by the Qubes OS team.  (Quebos is not correct the spelling!).

Mike.

--
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/1bd112e6-608d-dacc-1aff-d82ae4af1a14%40keehan.net.


Re: [qubes-users] No boot after dom0 kernel update

2020-02-25 Thread Mike Keehan

On 2/24/20 7:17 PM, ncmy...@gmail.com wrote:

Thank you for your kind attention.

I want to make clear that in each case, the new kernel has worked
fine once I persuaded my BIOS to boot it. The problem is always
that, after each kernel upgrade, the BIOS no longer recognizes any
bootable partition, not even listing the drive among its boot options.

Unmounting before fsck is the standard process, but I wonder why
and how the dom0 kernel upgrade script leaves the boot partition
in a state that the BIOS will not boot. I am far from certain that the
fsck.vfat was what restored bootability, but something did.

On Monday, February 24, 2020 at 1:58:48 PM UTC-5, Andrey Arapov wrote:

Is there a way to get reliable booting after a dom0 kernel
update?


I am afraid that there is no such way as the new Linux kernel adds
new features, changes the current ones, which are unlikely were
thoroughly tested (or if tested at all) for the whole range of HW
out there or their combinations.

Whenever you are upgrading the SW, be it a Linux kernel or any other
software, you should always expect things can go wrong.
The good news is that you can always rollback and contribute to the
FOSS by reporting the issue.

Do I need to unmount my /boot partition and fsck.vfat it
before rebooting?


You should always unmount the mount point before fsck'ing any
filesystem.

Kind regards,
Andrey Arapov



If your boot partition needs fsck'ing after something writes to it
(like a Qubes update), then it seems that the partition needs to
be fixed.  Probably best to rebuild it if you know how.

Mike.

--
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/33130140-dc8f-9523-646f-25896193ef36%40keehan.net.


Re: [qubes-users] Wifi connected but does not work

2020-02-20 Thread Mike Keehan

On 2/20/20 9:20 AM, hazon.sass...@gmail.com wrote:

Hi
I have a fresh qubes install on my laptop. The wifi is connected and works on 
other devices but can't ping google and can't open a web page on firefox.
What information do you need me to share to you to be able to help me ?
Thanks



What does "works on other devices" mean?

--
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/a96a02df-d754-91d6-f16b-214fb932edda%40keehan.net.


Re: [qubes-users] How to set the screensaver to either show keyboard language or not to lock screen ?

2020-02-13 Thread Mike Keehan

On 2/13/20 8:10 PM, A E wrote:
tor. 13. feb. 2020 kl. 18.48 skrev Mike Keehan <mailto:m...@keehan.net>>:




On 2/13/20 5:27 PM, A E wrote:
 > tor. 13. feb. 2020 kl. 11.11 skrev A mailto:anneeyr...@gmail.com>
 > <mailto:anneeyr...@gmail.com <mailto:anneeyr...@gmail.com>>>:
 >
 >     How to set the screensaver to either show keyboard language
or not
 >     to lock screen as default ?
 >
 >     I have tried to set it to not lock the screen by uncheck it
in the
 >     Screensaver settings. But it still continues to lock the screen.
 >
 >     --
 >     You received this message because you are subscribed to a
topic in
 >     the Google Groups "qubes-users" group.
 >     To unsubscribe from this topic, visit
 >
https://groups.google.com/d/topic/qubes-users/uMl6_djER5E/unsubscribe.
 >     To unsubscribe from this group and all its topics, send an
email to
 > qubes-users+unsubscr...@googlegroups.com
<mailto:qubes-users%2bunsubscr...@googlegroups.com>
 >     <mailto:qubes-users%2bunsubscr...@googlegroups.com
<mailto:qubes-users%252bunsubscr...@googlegroups.com>>.
 >     To view this discussion on the web visit
 >

https://groups.google.com/d/msgid/qubes-users/4ba32760-f4ea-4f1f-b92f-588306d2fa5d%40googlegroups.com.
 >
 >
 > Every time the screensaver lock the screen, I need to
reset/restart the
 > pc as I can’t know which keyboard layout is used and that is just a
 > little bit annoying ! 
 >
 > So I hope someone can explain to me how I can get it to show the
 > keyboard layout or not locking the screen.
 >
 > If that isn’t possible, can I then somehow disable or uninstall the
 > screensaver ?
 >

In screensaver preferences, set "Lock screen after" to 0 minutes.


You’re right, I forgot once again that Linux/Qubes OS consist of small 
programs that is made by different other creators.


Setting “lock screen after” 0 minutes just makes the screensaver to lock 
immediately when the screensaver gets activated.


I have wrote to the creator of the screensaver, and he says X11 sucks 
and makes it impossible to get the keyboard layout showed.


So I have to disable the lock.

One option is to set the lockTimeout to a large number so that it won’t 
lock. lockTimeout control have long after a blank screen the lock will 
be activated.


Another solution is to disable or uninstall the program.



Ah, you are right about the "lock after" option.

I've just checked my system, and in the screensaver preferences window,
the Mode can be set to Disable Screen Saver.  I think that is what you
need to do.

Mike.

--
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/e9a70b4f-1322-5202-919b-d05f799b0a6d%40keehan.net.


Re: [qubes-users] New user - network qubes vms

2020-02-04 Thread Mike Keehan

On 2/4/20 11:26 AM, Douglas Giovani Oechsler wrote:

Hello All!
How are you?

I am starting use Qubes. At my scenario we have PFsense with no DHCP 
network. Inside qubes how can switch qubes vm internal IP? I am reading 
official documentation but, still lost about thiis.


Please, how can I fix or what is my wrong?

Thank you!

Douglas




It's not a Qubes specific issue.  The sys-net VM uses NetworkManager and
dhclient to setup the network.  You need to search for information on
how to set up a static ip address with these standard Linux programs.
(If I knew, I would tell you, but it's a long time since I used them
myself).

Mike.

--
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/44e777fa-9292-f586-dfea-7913b9da6834%40keehan.net.


Fwd: Re: [qubes-users] Re: AppVms being killed on resume due to clock skew too large

2020-02-01 Thread Mike Keehan

Should have replied to the list!


 Forwarded Message 
Subject: Re: [qubes-users] Re: AppVms being killed on resume due to 
clock skew too large

Date: Sat, 1 Feb 2020 11:49:29 +
From: Mike Keehan 
To: mmo...@disroot.org

On 2/1/20 10:27 AM, mmo...@disroot.org wrote:

Same problem again, this time not related to any socket closure.
Apparently related to systemd:


[41911.199732] audit: type=1104 audit(1580516883.707:119): pid=4917 
uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:setcred 
grantors=pam_rootok acct="root" exe="/usr/lib/qubes/qrexec-agent" 
hostname=? addr=? terminal=? res=success'
[41920.252871] clocksource: timekeeping watchdog on CPU0: Marking 
clocksource 'tsc' as unstable because the skew is too large:
[41920.252927] clocksource: 'xen' wd_now: 2a1620baf67a wd_last: 
2a140e3c5f9f mask: 
[41920.252972] clocksource: 'tsc' cs_now: ff88779d4270 cs_last: 
5083a288ea9a mask: 

[41920.253013] tsc: Marking TSC unstable due to clocksource watchdog
[41921.161370] audit: type=1100 audit(1580516893.670:120): pid=4955 
uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:authentication 
grantors=pam_rootok acct="root" exe="/usr/lib/qubes/qrexec-agent" 
hostname=? addr=? terminal=? res=success'
[41921.163039] audit: type=1103 audit(1580516893.672:121): pid=4955 
uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:setcred 
grantors=pam_rootok acct="root" exe="/usr/lib/qubes/qrexec-agent" 
hostname=? addr=? terminal=? res=success'
[41921.176874] audit: type=1105 audit(1580516893.686:122): pid=4955 
uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:session_open 
grantors=pam_keyinit,pam_limits,pam_systemd,pam_unix,pam_umask,pam_lastlog 
acct="root" exe="/usr/lib/qubes/qrexec-agent" hostname=? addr=? 
terminal=? res=success'
[41922.205481] audit: type=1106 audit(1580552389.038:123): pid=4955 
uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:session_close 
grantors=pam_keyinit,pam_limits,pam_systemd,pam_unix,pam_umask,pam_lastlog 
acct="root" exe="/usr/lib/qubes/qrexec-agent" hostname=? addr=? 
terminal=? res=success'
[41922.205554] audit: type=1104 audit(1580552389.038:124): pid=4955 
uid=0 auid=4294967295 ses=4294967295 msg='op=PAM:setcred 
grantors=pam_rootok acct="root" exe="/usr/lib/qubes/qrexec-agent" 
hostname=? addr=? terminal=? res=success'
*[41932.321374] systemd[4919]: segfault at 640550f11920 ip 
640550345cbd sp 7ffd40e80440 error 6 in systemd[6405502f6000+b7000]
[41932.321420] Code: 24 28 02 00 00 48 85 c9 74 0f 48 89 81 28 02 00 00 
49 8b 84 24 28 02 00 00 48 85 c0 0f 84 a0 07 00 00 49 8b 94 24 20 02 00 
00 <48> 89 90 20 02 00 00 49 c7 84 24 28 02 00 00 00 00 00 00 49 c7 84*
[41932.321515] audit: type=1701 audit(1580552399.156:125): auid=0 uid=0 
gid=0 ses=4 pid=4919 comm="systemd" exe="/usr/lib/systemd/systemd" 
sig=11 res=1
[41932.336794] audit: type=1130 audit(1580552399.171:126): pid=1 uid=0 
auid=4294967295 ses=4294967295 msg='unit=systemd-coredump@0-4990-0 
comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? 
terminal=? res=success'
[41932.627105] audit: type=1131 audit(1580552399.456:127): pid=1 uid=0 
auid=4294967295 ses=4294967295 msg='unit=user@0 comm="systemd" 
exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
[41932.636551] audit: type=1131 audit(1580552399.471:128): pid=1 uid=0 
auid=4294967295 ses=4294967295 msg='unit=user-runtime-dir@0 
comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? 
terminal=? res=success'
[41932.661359] audit: type=1131 audit(1580552399.495:129): pid=1 uid=0 
auid=4294967295 ses=4294967295 msg='unit=systemd-coredump@0-4990-0 
comm="systemd" exe="/usr/lib/systemd/systemd" hostname=? addr=? 
terminal=? res=success'
[41934.482123] BUG: unable to handle kernel NULL pointer dereference at 
0080

[41934.482143] PGD 0 P4D 0
[41934.482150] Oops:  [#1] SMP PTI
[41934.482159] CPU: 0 PID: 5002 Comm: Compositor Tainted: G O 
4.19.94-1.pvops.qubes.x86_64 #1

[41934.482178] RIP: 0010:mem_cgroup_page_lruvec+0x28/0x50
[41934.482189] Code: 00 00 0f 1f 44 00 00 0f 1f 44 00 00 48 8b 47 38 48 
8b 17 48 85 c0 48 0f 44 05 dc d1 0c 01 48 c1 ea 36 48 8b 84 d0 48 0a 00 
00 <48> 3b b0 80 00 00 00 75 12 f3 c3 48 8d 86 a0 a1 02 00 48 3b b0 80

[41934.48] RSP: 0018:c900011d3aa8 EFLAGS: 00010046
[41934.482232] RAX:  RBX: 82369cc0 RCX: 
c900011d3ae8
[41934.482246] RDX:  RSI: 8880f9fd5000 RDI: 
ea0002adec00
[41934.482265] RBP: 88802f7e6fb8 R08: c900011d3ae8 R09: 
0001eb39
[41934.482279] R10: 000fa000 R11:  R12: 
8880f9fd5000
[41934.482294] R13: ea0002adec00 R14: 0014 R15: 
88802f7e7000
[41934.482308] FS: 00

Re: [qubes-users] Re: AppVms being killed on resume due to clock skew too large

2020-01-31 Thread Mike Keehan

On 1/31/20 1:11 PM, mmo...@disroot.org wrote:

Hi everyone!

Is anyone experiencing this issue on resume (VMs being killed randomly 
apparently due to clock skew that generates kernel panic) ??

This is happening very often and it makes suspend useless.

I'm using a Lenovo T480s.

Any ideas are really appreciated!

Thanks!

December 22, 2019 8:13 PM, mmo...@disroot.org 
 wrote:


Hello,

I've been struggle with this for months now.
Whenever there's a resume from suspend some random AppVms are
killed. Although this doesn't happen all the time it happens often
enough on resume sufficiently to indicate an issue.
It seems that the clock skew is too large resulting in a kernel
panic that kills the AppVM as the error below shows.

Is anyone experiencing the same issue? Is there any solution to this?

Thank you in advance.

/*[38009.358471] clocksource: timekeeping watchdog on CPU0: Marking
clocksource 'tsc' as unstable because the skew is too large:
[38009.358521] clocksource: 'xen' wd_now: 2697b2c28a19 wd_last:
2696858155d9 mask: 
[38009.358558] clocksource: 'tsc' cs_now: ff40e6dd060e cs_last:
4900d58115e2 mask: *
[38009.358594] tsc: Marking TSC unstable On 1/31/20 1:11 PM, 
mmo...@disroot.org wrote:> Hi everyone!

Is anyone experiencing this issue on resume (VMs being killed randomly 
apparently due to clock skew that generates kernel panic) ??

This is happening very often and it makes suspend useless.

I'm using a Lenovo T480s.

Any ideas are really appreciated!

Thanks!

December 22, 2019 8:13 PM, mmo...@disroot.org 
 wrote:


Hello,

I've been struggle with this for months now.
Whenever there's a resume from suspend some random AppVms are
killed. Although this doesn't happen all the time it happens often
enough on resume sufficiently to indicate an issue.
It seems that the clock skew is too large resulting in a kernel
panic that kills the AppVM as the error below shows.

Is anyone experiencing the same issue? Is there any solution to this?

Thank you in advance.

/*[38009.358471] clocksource: timekeeping watchdog on CPU0: Marking
clocksource 'tsc' as unstable because the skew is too large:
[38009.358521] clocksource: 'xen' wd_now: 2697b2c28a19 wd_last:
2696858155d9 mask: 
[38009.358558] clocksource: 'tsc' cs_now: ff40e6dd060e cs_last:
4900d58115e2 mask: *
[38009.358594] tsc: Marking TSC unstable due to clocksource watchdog
[79151.795501] borgmatic[2418]: segfault at 6060cafd8549 ip
6060ca2ae054 sp 7ffe9d9bbad8 error 4 in
python3.5[6060ca158000+3f]
[79151.795535] Code: 08 4c 8b 5e 08 4c 89 5b f0 4c 89 4e 08 4d 89 0b
48 89 73 e8 4c 89 43 f8 eb 92 66 90 66 2e 0f 1f 84 00 00 00 00 00 48
8b 47 08  80 a9 00 00 00 40 75 03 31 c0 c3 53 48 8b 80 48 01 00
00 48 89
[79152.712396] general protection fault:  [#1] SMP PTI
[79152.712416] CPU: 1 PID: 2425 Comm: systemctl Tainted: G O
4.19.84-1.pvops.qubes.x86_64 #1
[79152.712444] RIP: 0010:__pv_queued_spin_lock_slowpath+0x199/0x270
[79152.712462] Code: eb bd 83 e0 03 c1 ea 12 4c 8d 6d 44 48 c1 e0 04
41 be 01 00 00 00 4c 8d a0 80 10 02 00 8d 42 ff 48 98 4c 03 24 c5 20
77 17 82 <49> 89 2c 24 b8 00 80 00 00 eb 15 84 c0 75 0a 41 0f b6 54
24 44 84
[79152.712509] RSP: 0018:c96c7b60 EFLAGS: 00010002
[79152.712524] RAX: 3ffe RBX: 8880f47b0764 RCX:
0001
[79152.712544] RDX: 3fff RSI:  RDI:
8880f47b0764
[79152.712565] RBP: 8880f5b21080 R08:  R09:
c9637e90
[79152.712585] R10: c96c7e20 R11: 0001 R12:
64616f6c00708019
[79152.712605] R13: 8880f5b210c4 R14: 0001 R15:
0008
[79152.712626] FS: () GS:8880f5b0()
knlGS:
[79152.712647] CS: 0010 DS:  ES:  CR0: 80050033
[79152.712664] CR2: 7f088e3efab4 CR3: 0220a004 CR4:
003606e0
[79152.712687] DR0:  DR1:  DR2:

[79152.712707] DR3:  DR6: fffe0ff0 DR7:
0400
[79152.712727] Call Trace:
[79152.712739] _raw_spin_lock_irqsave+0x32/0x40
[79152.712755] try_to_wake_up+0x3d/0x490
[79152.712767] __wake_up_common+0x96/0x180
[79152.712780] ep_poll_callback+0x1ac/0x2f0
[79152.712791] __wake_up_common+0x96/0x180
[79152.712803] __wake_up_common_lock+0x7c/0xc0
[79152.712819] sock_def_wakeup+0x32/0x40
[79152.712831] unix_release_sock+0x288/0x2d0
[79152.712844] unix_release+0x19/0x30
[79152.712855] __sock_release+0x3d/0xc0
[79152.712866] sock_close+0x11/0x20
[79152.712878] __fput+0xe2/0x210

Re: [qubes-users] Grayscale display settings

2020-01-20 Thread Mike Keehan
On Sun, 19 Jan 2020 19:46:58 +0100
max.nichtsodringl...@posteo.de wrote:

> Hey there,
> 
> what is the best way to switch my whole display to black and white / 
> grayscale?
> 
> I found this thread: 
> https://askubuntu.com/questions/443335/how-can-ubuntu-be-made-grayscale/443346#443346
> 
> But I'm unsure where to implement this in dom0.
> 
> Thanks!
> 
> Max
> 

Those settings would go in /etc/X11/xorg.conf normally, I seem to remember.
Qubes doesn't have this file in a default setup, but you could try adding one.  

You need to search for X11 configuration settings.

Mike.

-- 
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/20200120125841.564e7b35%40keehan.net.


Re: [qubes-users] Fedora kernel for VM

2020-01-14 Thread Mike Keehan
On Tue, 14 Jan 2020 03:09:48 -0800 (PST)
Asad Manzur  wrote:

> Hi
> I've been searching around but I can't find any documentation on how to
> install fedora vanilla kernel for a VM. Can anyone guide me in the correct
> direction please. I am wanting to use vanilla Fedora kernel so that I can
> run my Intel AX200 WiFi card on my Clevo laptop. Thanks for your help
> 

You also need to set the VM to be HVM for the pci pass-through to work.

-- 
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/20200114130727.2081273b%40keehan.net.


Re: [qubes-users] Fedora kernel for VM

2020-01-14 Thread Mike Keehan
On Tue, 14 Jan 2020 03:09:48 -0800 (PST)
Asad Manzur  wrote:

> Hi
> I've been searching around but I can't find any documentation on how to
> install fedora vanilla kernel for a VM. Can anyone guide me in the correct
> direction please. I am wanting to use vanilla Fedora kernel so that I can
> run my Intel AX200 WiFi card on my Clevo laptop. Thanks for your help
> 

In Qube Settings, make the default kernel "none".  It will then use the 
kernel in the VM image.

Also, you will need to pass through the network card to the VM.

Best of luck,

   Mike.

-- 
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/20200114130255.6dd3fbd8%40keehan.net.


Re: [qubes-users] Sys-net not sharing internet

2020-01-07 Thread Mike Keehan
On Tue, 7 Jan 2020 07:10:53 -0800 (PST)
paulos elias  wrote:

> I have been using qubes for over a month and everything was working fine
> and in good shape until today. Today I opened up my PC and  found out that
> sys-net has internet access but not other appvms whose netvm is sys-net. I
> can do pinging and all from sys-net but I always get "host unreachable"
> error from others which use sys-net as netvm. Until today it was working
> fine. I don't know what I did wrong that caused this(could be some small
> stuff given I am not that expert at it) and I have nothing specific I
> remember except rebooting the system yesterday (couple of times) and
> browsing grub help-list(by booting into grub and typing 'help') while at
> it. I desperately need help right now since I have wasted the afternoon
> just on this in vain.
> 

On a normal Qubes installation, the default network connection for a VM
is to sys-firewall, and not to sys-net.  Has your sys-firewall failed to
start?

Mike.

ps - if you get a number of these emails from me, please let me know.
 I have replaced my email configuration to try to stop multiple
 replies going out from my mailer.

-- 
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/20200107172642.67ac5af1%40keehan.net.


Re: [qubes-users] wipe released diskspace of a disposable VM's

2019-12-12 Thread Mike Keehan
On Thu, 12 Dec 2019 16:58:41 +0100
"josefh.maier via qubes-users"  wrote:

> Hello list,
> 
> I heard that a Qubes-user was forced to hand over the Qubes-password,
> and that a forensic examiner was able to restore artifacts of a
> deleted disposeable form the harddisk... 
> 
> Is this story possible? And what's the best aprroach to wipe
> diskspace used before by a disposable VM after that VM is closed?
> 
> 
> Thank you!
> 
> Regards,
> 
> Joe
> 

Qubes won't help in this situation - see
https://www.qubes-os.org/doc/disposablevm/#disposablevms-and-local-forensics

They recommend using Tails for this type of situation.

Mike.

-- 
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/20191212172347.2d05ca06.mike%40keehan.net.


Re: [qubes-users] Time sync isn't working

2019-12-09 Thread Mike Keehan
On Mon, 09 Dec 2019 14:46:50 +
"'Oli Sturm' via qubes-users"  wrote:

> On Monday, December 9, 2019 2:40 PM, Mike Keehan 
> wrote:
> 
> > I suspect you need to investigate systemd's timesyncd stuff. Good
> > luck!  
> 
> I believe I would just need to switch that on to activate it. But I
> believe time sync should work in Qubes out of the box - I remember
> reading that somewhere in the docs. Maybe my expectations are wrong
> here?
> 
> Thanks
> Oli
> 

systemd-timesyncd is running on my Qubes sys-net vm.  I'm assuming
that it is part of the standard installation.  You need to investigate
why it is not working on your machine I think.

Mike.

-- 
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/20191209150554.4cedb486.mike%40keehan.net.


Re: [qubes-users] Time sync isn't working

2019-12-09 Thread Mike Keehan
On Mon, 09 Dec 2019 14:04:10 +
"'Oli Sturm' via qubes-users"  wrote:

> Hi,
> 
> I'm running 4.0 with all current updates. I'm trying to figure out
> why I don't get synchronized time anywhere in the system. I have
> found various old issues and discussions about similar problems, but
> unfortunately none of the scenarios described there seem to be
> up-to-date anymore.
> 
> As I understand, my sys-net VM is the "ClockVM". I have confirmed
> that it is configured as such in Qubes settings (using the UI dialog
> in Qube Manager). However, it seems that this VM is not set up to
> sync time with an NTP server. I see that all entries in the "Time"
> block in /etc/systemd/timesyncd.conf are commented. "ntpdate" is not
> installed. Is there some other NTP sync mechanism installed in this
> VM? If so, where is it? In any case it's clearly not working.
> 


Ah the good old days where you just knew where and what to look for.

I suspect you need to investigate systemd's timesyncd stuff.  Good luck!

Mike

-- 
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/20191209144000.3435e05b.mike%40keehan.net.


Re: [qubes-users] Resizing partitions in QVMs

2019-11-16 Thread Mike Keehan
On Sat, 16 Nov 2019 02:44:24 -
zenandart via qubes-users  wrote:

> Hi,
> 
> I recently ran out space of xvdb on a QVM (while I still had plenty of
> space on xvda), so I gave 10GB or so in Qubes Settings to the VM. But
> all the new space went to xvda, and the space of xvdb didn't change.
> 
> I thought I should resize partitions, then. So I installed GParted.
> But soon I realized that I couldn't resize system partitions in the
> VM, for both of xvda and xvdb are used and therefore cannot be
> unmounted.
> 
> I have some experience resizing partitions in systems that don't have
> VMs, in which case I'll load a system from USB drives to do so, but
> I'm not sure how to do it in Qubes OS.
> 
> I've searched some tutorials about resizing partitions in VirtualBox
> VMs, but I don't think it helps much.
> 
> So, the question is, how can I resize partitions in a QVM?
> 
> Best regards,
> zenandart
> 

In Qube Manager, use "Qube settings" for the VM that is out of space.

-- 
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/20191116132322.4ba1c72f.mike%40keehan.net.


Re: [qubes-users] Easiest way to redirect USB to a VM?

2019-10-08 Thread Mike Keehan
On Tue, 8 Oct 2019 11:40:23 -0700 (PDT)
Guerlan  wrote:

> Yes, I followed that topic and when I created the sys-usb VM mey
> keyboard and mouse got disabled and I couldn't do anything else.
> 
> That's why I asked if there's an easier (possibly less secure) way to 
> redirect the USB from dom0 directly to another VM. I can't create a
> sys-usb because I will be left without keyboard
> 
> On Monday, October 7, 2019 at 9:06:50 AM UTC-3, Mike Keehan wrote:
> >
> > On Sun, 6 Oct 2019 22:04:05 -0700 (PDT) 
> > Guerlan > wrote: 
> >  
> > > I tried to create sys-usb, and my keyboard stopped working. I
> > > then rebooted and couldn t use keyboard to put my LUKS password.
> > > I had to reinstall qubes entirely. 
> > > 
> > > Is there an easier way to pass USB from dom0 to a VM? I don' t
> > > want to create a sys-usb and I don' t care too much about
> > > security in this level. I just need to have my Android phone
> > > inside the virtual machine. 
> > >   

> >
> > Have you read the docs?  https://www.qubes-os.org/doc/usb-devices/ 
> >  
> 

In the link above, the section titled "With The Command Line Tool" shows
how to use qvm-usb in dom0 to attach usb devices to a VM.

(I think you have been reading the usb-qubes page, and not that in the
link given above!).

Mike.

ps - mailing list etiquette is to post replies below the email, not
above.

-- 
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/20191008213927.447a674a.mike%40keehan.net.


Re: [qubes-users] Easiest way to redirect USB to a VM?

2019-10-07 Thread Mike Keehan
On Sun, 6 Oct 2019 22:04:05 -0700 (PDT)
Guerlan  wrote:

> I tried to create sys-usb, and my keyboard stopped working. I then
> rebooted and couldn t use keyboard to put my LUKS password. I had to
> reinstall qubes entirely.
> 
> Is there an easier way to pass USB from dom0 to a VM? I don' t want
> to create a sys-usb and I don' t care too much about security in this
> level. I just need to have my Android phone inside the virtual
> machine.
> 

Have you read the docs?  https://www.qubes-os.org/doc/usb-devices/

-- 
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/20191007130640.7ee3aa5f.mike%40keehan.net.


Re: [qubes-users] request : add to dom0 FFmpeg libraries and codecs h264/h265/libavcodec/libfdk_aac/libmp3lame/libopus/libvpx

2019-08-11 Thread Mike Keehan
On Sun, 11 Aug 2019 03:47:14 -0700 (PDT)
john due  wrote:

> Hello, Dear Qubes users and devs!
> 
> Can you add please FFmpeg libraries and codecs to dom0 repos?
> Because it impossible to add RPMfusion repo to Dom0 and synchronize
> it with dnf/qubes-dom0-update mechanism.
> it required system-base-release 25 dependencies.
> 
> Best Regards, john due
> 

Why do you need ffmpeg in dom0?  Dom0 is for admin, not for running
applications.  This is to preserve the security of your whole system.

Mike.

-- 
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/20190811120316.37bd89f5.mike%40keehan.net.


Re: [qubes-users] Edit Dom0 conf.

2019-07-09 Thread Mike Keehan
Files in /etc are owned by the user 'root', so you need to use sudo
to be able to change them.

"sudo vi /etc/. ".

Be carefull, these files are essential for correct operation of
the system.  You would be best advised to make a backup of any
file you want to edit!

Mike.


On Tue, 09 Jul 2019 08:40:09 +
"'Avart Jean-Francois' via qubes-users" 
wrote:

> > Hello,
> >   
> 
> > I love Qubes OS but I'm noobs :)
> >   
> 
> > I try to change de confi file Dom0 for full screen vm streaming.
> >   
> 
> > I try with eidtor "VI" to change de txt, but it's "read only" and
> > not possible to edit the files in the terminal. It's possible to
> > install a GUI editor txt in Dom0 for edit the
> > files /etc/qubes/guid.conf ? 
> 
> > Thanks
> >   
> 

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20190709115327.44c25205.mike%40keehan.net.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Problem with Wireless connection after reinstalling Qubes 4.0.1

2019-06-23 Thread Mike Keehan
On Sun, 23 Jun 2019 08:31:45 -0700 (PDT)
Anhangá  wrote:

> Hi,
> 
> I'm quite new using Qubes and I've never been so fond with Linux but
> this changed last year so sorry for newbie questions in advance.
> 
> I installed Qubes 4.0.1 using only wifi connection and it was working
> 100% with wifi connections but I had to reinstall after a ssd upgrade
> I did on my laptop and in this second time I used a wired connection
> to do install Qubes 4.0.1.
> 
> In this new installation, wifi connection is not working and I
> counld't figure out why. The connections options only shows My Wired
> Connection but none Wifi connection available as shown in the
> attached Screenshot.
> 
> I've tried the Qubes Wireless troubleshooting (resetting wireless
> cards by reloading drivers) but didn't work.
> 
> I tried some commands on sys-net to see some informations about my
> wireless card and seems that everything is ok.
> 
> 
> 
> lspci -vv:
> 
> 00:07.0 Network controller: Qualcomm Atheros QCA9377 802.11ac
> Wireless Network Adapter (rev 31) Subsystem: Samsung Electronics Co
> Ltd Device 4133 Physical Slot: 7
>   Control: I/O- Mem+ BusMaster+ SpecCycle- MemWINV- VGASnoop-
> ParErr- Stepping- SERR- FastB2B- DisINTx+ Status: Cap+ 66MHz- UDF-
> FastB2B- ParErr- DEVSEL=fast >TAbort- SERR-  INTx- Latency: 0 Interrupt: pin A routed to IRQ 72
>   Region 0: Memory at f200 (64-bit, non-prefetchable)
> [size=2M] Capabilities: [40] Power Management version 3
>   Flags: PMEClk- DSI- D1- D2- AuxCurrent=0mA
> PME(D0-,D1-,D2-,D3hot-,D3cold-) Status: D0 NoSoftRst+ PME-Enable-
> DSel=0 DScale=0 PME- Capabilities: [50] MSI: Enable+ Count=1/1
> Maskable- 64bit- Address: fee96000  Data: 4300
>   Capabilities: [70] Express (v2) Endpoint, MSI 00
>   DevCap: MaxPayload 256 bytes, PhantFunc 0,
> Latency L0s unlimited, L1 <64us ExtTag- AttnBtn- AttnInd- PwrInd-
> RBE+ FLReset- SlotPowerLimit 10.000W DevCtl:  CorrErr-
> NonFatalErr- FatalErr- UnsupReq- RlxdOrd+ ExtTag- PhantFunc- AuxPwr-
> NoSnoop+ MaxPayload 128 bytes, MaxReadReq 512 bytes
>   DevSta: CorrErr- NonFatalErr- FatalErr-
> UnsupReq- AuxPwr+ TransPend- LnkCap:  Port #0, Speed 2.5GT/s,
> Width x1, ASPM L0s L1, Exit Latency L0s <4us, L1 <64us ClockPM+
> Surprise- LLActRep- BwNot- ASPMOptComp+ LnkCtl:   ASPM Disabled;
> RCB 64 bytes Disabled- CommClk- ExtSynch- ClockPM- AutWidDis- BWInt-
> AutBWInt- LnkSta: Speed 2.5GT/s (ok), Width x1 (ok)
>   TrErr- Train- SlotClk+ DLActive- BWMgmt-
> ABWMgmt- DevCap2: Completion Timeout: Not Supported, TimeoutDis+,
> LTR+, OBFF Via message AtomicOpsCap: 32bit- 64bit- 128bitCAS-
>   DevCtl2: Completion Timeout: 50us to 50ms,
> TimeoutDis-, LTR-, OBFF Disabled AtomicOpsCtl: ReqEn-
>   LnkSta2: Current De-emphasis Level: -6dB,
> EqualizationComplete-, EqualizationPhase1- EqualizationPhase2-,
> EqualizationPhase3-, LinkEqualizationRequest- Kernel driver in use:
> ath10k_pci Kernel modules: ath10k_pci
> 
> 
> 
> lshw:
> 
> *-network:0
>  description: Ethernet interface
>  product: RTL810xE PCI Express Fast Ethernet controller
>  vendor: Realtek Semiconductor Co., Ltd.
>  physical id: 6
>  bus info: pci@:00:06.0
>  logical name: ens6
>  version: 07
>  serial: 98:83:89:ca:86:9a
>  size: 100Mbit/s
>  capacity: 100Mbit/s
>  width: 64 bits
>  clock: 33MHz
>  capabilities: pm msi pciexpress vpd bus_master cap_list
> ethernet physical tp mii 10bt 10bt-fd 100bt 100bt-fd autonegotiation
> configuration: autonegotiation=on broadcast=yes driver=r8169
> driverversion=2.3LK-NAPI duplex=full firmware=rtl8106e-1_0.0.1
> 06/29/12 ip=192.168.25.11 latency=64 link=yes multicast=yes port=MII
> speed=100Mbit/s resources: irq:71 ioport:c200(size=256)
> memory:f222a000-f222afff memory:f2224000-f2227fff *-network:1
> description: Network controller product: QCA9377 802.11ac Wireless
> Network Adapter vendor: Qualcomm Atheros physical id: 7 bus info:
> pci@:00:07.0 version: 31
>  width: 64 bits
>  clock: 33MHz
>  capabilities: pm msi pciexpress bus_master cap_list
>  configuration: driver=ath10k_pci latency=0
>  resources: irq:72 memory:f200-f21f
>   *-network:0
>description: Ethernet interface
>physical id: 1
>logical name: vif6.0
>serial: fe:ff:ff:ff:ff:ff
>capabilities: ethernet physical
>configuration: broadcast=yes driver=vif ip=10.137.0.5 link=yes
> multicast=yes *-network:1
>description: Ethernet interface
>physical id: 2
>logical name: vif13.0
>serial: fe:ff:ff:ff:ff:ff
>capabilities: ethernet 

Re: [qubes-users] Re: CPU overheating issues, pulsating fan, recommendations?

2019-06-19 Thread Mike Keehan
On Wed, 19 Jun 2019 18:57:52 +
Jon deps  wrote:

> On 6/18/19 11:39 AM, Mike Keehan wrote:
> > On Tue, 18 Jun 2019 04:44:04 +
> > omerta-3q9s2cxqgw4kltdg6p0...@public.gmane.org wrote:
> >   
> >> Hey all,
> >>
> >> Over the last week I've noticed my laptops CPU keeps peaking @
> >> 80-85 every now and then, even when I'm not doing any resource
> >> intensive tasks.
> >>
> >> I run 11-12 VMs @ a time which barely scratches the 34GB RAM on a
> >> P51 Thinkpad with a i7 7820HQ running in a standard temperature
> >> room environment majority of the time.
> >>
> >> Have thought of getting a cooling pad to resolve this, but would
> >> prefer to see if there are any tweaks which can be made within dom0
> >> or the BIOS to put an end to this.
> >>
> >> Also of note, I'm getting similar pulsating fan noise as posted
> >> here https://github.com/QubesOS/qubes-issues/issues/3599.
> >>
> >> Many thanks,
> >> om
> >>  
> > 
> > Run xentop in dom0 to see which of your VMs are using cpu the most.
> > Web browsers can use lots of cpu on some pages!
> > 
> > Mike.
> >   
> 
> fwiw, this morning I woke up and my system was at the qubes 1st login 
> screen , apparently the system has crashed just far enough to close
> all VMs but not reboot?
> 
> I am now looking at the Xentop  CPU numbers and with whonix-ws update 
> and one up to date torbrowser window 1 tab  open  and one page view,
> the CPU is at 150%
> 
> Maxmem was at 2000 , up'd that a bit,  but also changed the VCPU to
> '3' it was set to '2'  and now the CPU with 1 page torbrowser open is
> at 5%
> 
> 
> I guess my question what effect changing the VCPU  of the
> TB-AppVM-Qube is
> 
> or maybe something changed with the whonix-ws recently  to mess up
> the CPU usages???
> 

I don't use whonix, but I've just started it up to see how it behaves.
And yes, it is using 150% cpu in the tor browser (using top in a
terminal window in whonix-user VM), and about 170% cpu in xentop.
(and my fans have come on!).

All I can suggest is to close the tor browser when not in use.

Mike.

-- 
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/20190619211505.587b8c91.mike%40keehan.net.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] CPU overheating issues, pulsating fan, recommendations?

2019-06-18 Thread Mike Keehan
On Tue, 18 Jun 2019 04:44:04 +
ome...@firemail.cc wrote:

> Hey all,
> 
> Over the last week I've noticed my laptops CPU keeps peaking @ 80-85 
> every now and then, even when I'm not doing any resource intensive 
> tasks.
> 
> I run 11-12 VMs @ a time which barely scratches the 34GB RAM on a P51 
> Thinkpad with a i7 7820HQ running in a standard temperature room 
> environment majority of the time.
> 
> Have thought of getting a cooling pad to resolve this, but would
> prefer to see if there are any tweaks which can be made within dom0
> or the BIOS to put an end to this.
> 
> Also of note, I'm getting similar pulsating fan noise as posted here 
> https://github.com/QubesOS/qubes-issues/issues/3599.
> 
> Many thanks,
> om
> 

Run xentop in dom0 to see which of your VMs are using cpu the most.
Web browsers can use lots of cpu on some pages!

Mike.

-- 
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/20190618123942.5f08559f.mike%40keehan.net.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] has any one get fully worked archlinux template?

2019-06-15 Thread Mike Keehan
On Sat, 15 Jun 2019 07:31:18 -0700 (PDT)
travorfirefuel...@gmail.com wrote:

> subj
> 

yes

-- 
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/20190615180351.7415a839.mike%40keehan.net.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: desktop suspend breaks sys-usb/ CPU bug present

2019-06-14 Thread Mike Keehan
On Thu, 13 Jun 2019 19:28:38 +
"'awokd' via qubes-users"  wrote:

> Mike Keehan:
> 
> > There has been a thread on the Linux Kernel mailing list recently,
> > discussing the need to re-enable the SMT chips during resume else
> > something breaks, and then turn them off again.  You may be one
> > of the unlucky ones to heave this affecting your system.  I'm not
> > sure which new kernel the fix is in - may not be until 5.2 comes
> > out.  
> 
> Did they happen to mention if disabling it in UEFI config works
> around the problem?
> 

I think the kernel issue was with hibernation and resume, not with
suspend to memory and resume.  So it is probably a different issue
with the Qubes suspend/resume problems.  

I often have to restart the NetVM after suspend (even with the net
modules on the blacklist), and occasionally the usbVM.

Oddly enough, those two VMs sometimes don't work properly at boot
time, but very rarely.  Could be a race condition or something.

Mike.

-- 
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/20190614150608.40f27b93.mike%40keehan.net.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: desktop suspend breaks sys-usb/ CPU bug present

2019-06-14 Thread Mike Keehan
On Thu, 13 Jun 2019 19:28:38 +
"'awokd' via qubes-users"  wrote:

> Mike Keehan:
> 
> > There has been a thread on the Linux Kernel mailing list recently,
> > discussing the need to re-enable the SMT chips during resume else
> > something breaks, and then turn them off again.  You may be one
> > of the unlucky ones to heave this affecting your system.  I'm not
> > sure which new kernel the fix is in - may not be until 5.2 comes
> > out.  
> 
> Did they happen to mention if disabling it in UEFI config works
> around the problem?
> 

Disabling doesn't help.  I'm not sure why it hasn't affected more
systems than it has, it seems odd that it only appeared recently.

Suspend/resume has always been a bit iffy on my laptops, so I don't
use it much.

I think all you can do is try whatever options are available to you
and see if anything helps.

Mike.

-- 
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/20190614094226.241e90c5.mike%40keehan.net.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: desktop suspend breaks sys-usb/ CPU bug present

2019-06-13 Thread Mike Keehan
On Thu, 13 Jun 2019 07:14:47 +
"'awokd' via qubes-users"  wrote:

> Jon deps:
> > On 6/12/19 8:14 AM, Jon deps wrote:  
> 
> >> Jun 12 07:52:01 dom0 kernel: MDS CPU bug present and SMT on, data
> >> leak possible. See 
> >> https://www.kernel.org/doc/html/latest/admin-guide/hw-vuln/mds.html 
> >> for more details.  
> 
> > 
> > .any idea on the  "data leak possible"    journal entry?
> > 
> > sounds a bit scary,  maybe I need to  look around in my UEFI  to
> > disable some cache-ing ?  
> 
> SMT should be off. Do you see that same message if you do a cold
> power on? Also, in "sudo cat /boot/efi/EFI/qubes/xen.cfg", do you see 
> "smt=off" in the Xen options lines?
> 
> I wonder if there is a Xen bug making SMT re-enable after a resume. 
> Please check the above, then look in your UEFI options to disable 
> Hyperthreading/SMT.
> 

There has been a thread on the Linux Kernel mailing list recently,
discussing the need to re-enable the SMT chips during resume else
something breaks, and then turn them off again.  You may be one
of the unlucky ones to heave this affecting your system.  I'm not
sure which new kernel the fix is in - may not be until 5.2 comes
out.

Mike.

-- 
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/20190613153859.0ed532ef.mike%40keehan.net.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Full proper backup of Dom0 possible?

2019-06-12 Thread Mike Keehan
On Wed, 12 Jun 2019 10:29:54 -0400
Chris Laprise  wrote:

> On 6/11/19 6:50 PM, Chris Laprise wrote:
> > I think the best solution for a safe and comprehensive dom0 backup
> > is to have Qubes simply snapshot the root lv at boot time, before
> > its mounted as read-write. It shouldn't take more than a few script
> > lines in the dom0 startup. Then dom0 can be backed up like any
> > other vm.  
> 
> I created an issue with a 3-line (barely tested) example here:
> 
> https://github.com/QubesOS/qubes-issues/issues/5094
> 

Chris, have you some thoughts on how to restore such a backup?

Mike.

-- 
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/20190612200415.1932e84d.mike%40keehan.net.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] bottlenecks during qvm-backup

2019-04-23 Thread Mike Keehan
On Tue, 23 Apr 2019 21:58:17 +0100
lik...@gmx.de wrote:

> Hi,
> 
> is there a possibility to find the bottlenecks during a qvm-backup? A
> backup of ~100GB with compression takes several hours. During the
> time the (4) cpu cores (xentop) are not used well and the harddisk
> (iotop) is also idling a lot. I'm creating a backup to a usb attached
> ext3 formated harddrive.
> 
> How to find out which components are responsible for the slow process?
> 
> Best, Pete
> 

Just try copying 100Gb to the usb connected drive to see how long that
takes.  USB drive speed can be quite slow.

Mike.

-- 
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/20190423225301.42f29b62.mike%40keehan.net.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Qubes Installation freeze

2019-04-22 Thread Mike Keehan
On Sun, 21 Apr 2019 11:52:32 -0700 (PDT)
Blue  wrote:

> I've so far been unable to get qubes 4.0.1 to install on my Dell
> laptop, it keeps freezing of file 909/1042 kernel-qubes-vm.x86_64.
> Its a nvme drive if that makes a difference.
> 
> I've verified the ISO of qubes and that matches, I created the pen
> drive in Ubuntu using the DD command,as  per the site, and I've used
> 2 different 16gb pen drives.
> 
> The pen drive boots in legacy mode and lets me enter all settings and
> starts install. The installation hangs at the file shown above and I
> cannot find any way to exit or restart the machine other than a hard
> reboot.
> 
> I've tried the UEFI troubleshooting on the qubes site as well, anyone
> else got any ideas?
> 

I had the same problem on my Dell laptop.  I had to blacklist the
nouveau module in the xen.cfg file, but if you are using legacy
boot, then the grub.cfg is probably the one to look at.

Mike.
  

-- 
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/20190422193311.37e2468e.mike%40keehan.net.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Qubes backup UI stalls badly

2019-04-16 Thread Mike Keehan
On Tue, 16 Apr 2019 12:21:54 -0400
Ryan Tate  wrote:

> Today I went to backup my machine using Qubes backup GUI and near the
> end (?) the progress bar was at 100% but the Finish button was not
> clickable. I waited maybe half an hour, an hour, and tried closing
> the window. I got an error message saying the window was not
> responding and asking if I wanted to force close. I said No. Now
> (maybe 15 minutes later) the window is completely blank.
> 
> I have previously been left without a bootable Qubes machine because
> I cancelled a Qubes restore. I am worried I am about to be in the
> same state. Is there anywhere I can check to see if there are big
> stray files left behind in dom0 and not cleaned up? Can I check if
> I’m about to have lvm issues?
> 
> Also, this is not the first time Qubes Backup has behaved oddly. I
> also commonly get it stuck at 99% for hours so I give up and force
> close. Other times, it proceeds pretty quickly to 100% and I get the
> Finish button clickable.
> 
> The backup is only about 90GB (uncompressed, but compressed it is
> somewhere closer to 50GB) and is coming off a speedy internal drive
> to a decent USB3 external disk. No idea why I am having these issues.
> 

It was a combination of issues on my machine that caused the same thing,

1. I do not have the lvm disk setup,
2. Backing up live vms.

As long as I only back up vms that are off, it all works perfectly.
I found this answered by Marek after searching for a while.

I have restored OK too, but have only done this once.  It worked fine.

Mike.
 

-- 
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/20190416193238.2479a8a9.mike%40keehan.net.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] X events going to wrong VM?

2019-03-29 Thread Mike Keehan
Argh, I meant mouse events, not keyboard.

On Fri, 29 Mar 2019 21:41:33 +
Mike Keehan  wrote:

> On Fri, 29 Mar 2019 11:42:39 -0500
> Daniel Allcock  wrote:
> 
> > Thanks Mike,
> > 
> > Your experience sounds even stranger than my own.  I'm not sure
> > whether it is more worrying---it's not so bad if the panel can read
> > VM's events, since dom0 already reads all of them.  But unexpected
> > events being sent to dom0 sounds like a way to make dom0 do things
> > possibly against user intent.
> > 
> > btw, you wouldn't be the Mike Keehan that I worked for in Summer
> > 1991 at Shell?
> > 
> > Daniel 
> >   
> 
> Hi Daniel,
> 
> I don't think it is events being sent to to dom0, but keyboard events 
> going to the VM.  And then the app in the VM just displays the popup
> as usual.  So I do not think there is any security issue, but just a
> bug somewhere in the event handling code.
> 
> Mike.
>  
> 

-- 
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/20190329214317.6abb73b7.mike%40keehan.net.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] X events going to wrong VM?

2019-03-29 Thread Mike Keehan
On Fri, 29 Mar 2019 11:42:39 -0500
Daniel Allcock  wrote:

> Thanks Mike,
> 
> Your experience sounds even stranger than my own.  I'm not sure
> whether it is more worrying---it's not so bad if the panel can read
> VM's events, since dom0 already reads all of them.  But unexpected
> events being sent to dom0 sounds like a way to make dom0 do things
> possibly against user intent.
> 
> btw, you wouldn't be the Mike Keehan that I worked for in Summer 1991
> at Shell?
> 
> Daniel 
> 

Hi Daniel,

I don't think it is events being sent to to dom0, but keyboard events 
going to the VM.  And then the app in the VM just displays the popup
as usual.  So I do not think there is any security issue, but just a
bug somewhere in the event handling code.

Mike.
 

-- 
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/20190329214133.7a6da2aa.mike%40keehan.net.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] X events going to wrong VM?

2019-03-29 Thread Mike Keehan
On Thu, 28 Mar 2019 13:13:17 -0500
Daniel Allcock  wrote:

> Hello,
> 
> Something peculiar happens occasionally on my qubes 4.0 system.  I run
> claws-mail in one VM, and mousing over the message list shows tooltips
> as intended (not very useful; they just repeat the text that is under
> the mouse). As I mouse up or down, the old tooltip disappears and a
> new one appears, as you would expect.
> 
> But sometimes this happens when another VM's window (say firefox)
> is on top of the claws window, and all the mouse movement takes place
> inside the window on top.  Somehow claws seems
> to be receiving X mouse-motion events meant for the other VM.
> Obviously this looks like a violation of qube isolation.
> 
> The tooltip windows are properly colored.
> So as I move the mouse, yellow-bordered tooltip windows appear and
> disappear on top of a (say) red-bordered window that is on top of 
> a yellow-bordered claws window.  Visually this is very strange.
> 
> I wish I knew how to reproduce this.  It just seems to happen by
> itself every few days.  I have a vague memory of something similar
> happening *once* with some app other than claws.  But I forget the
> details.  Anyone else have this experience? Or thoughts about
> what to try to maybe reproduce it more reliably?
> 
> Thanks,
> Daniel
> 

Hi Daniel,

I have the same problem on my system.  Not only with Claws mailer, but
also with Firefox occasionally, and most often with an xfce panel that
runs in sys-net and shows me the weather and the network load.

The odd part is that the panel widgets display their popups even though
I never hover the mouse over them deliberately.  The popups display
when I use the scrollwheel to switch desktops.

As you say, it is not easily reproducible, so debugging it will be hard
I expect.

Mike.
 

-- 
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/20190329161106.13bc1ed2.mike%40keehan.net.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: Blank Screen Trying To Install

2019-03-24 Thread Mike Keehan
On Sun, 24 Mar 2019 14:39:12 -0700 (PDT)
Yushatak  wrote:

> On Sunday, March 24, 2019 at 3:36:10 PM UTC-4, awokd wrote:
> > Mike Keehan wrote on 3/24/19 3:36 PM:  
> > > On Sun, 24 Mar 2019 02:07:10 -0400
> > > Yushatak  wrote:
> > >   
> > >> Machine has no legacy mode.
> > >>
> > >> On Sat, Mar 23, 2019, 11:32 PM Gaijin  wrote:
> > >>  
> > >>> 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.
> > >>> 
> > >>  
> > > 
> > > I had exactly this problem when I installed Qubes.  Searching
> > > this mail list found the answer.  (You have to edit the
> > > installation image, or mount the image, edit it and build a new
> > > image for installation.) 
> > I think the issue is he edited grub.cfg but has no legacy mode,
> > which means grub won't be used. Yushatak, try using that same
> > procedure to edit xen.cfg instead. It will be somewhere under
> > boot/efi/EFI/qubes.  
> 
> There is no such path, the closest I'm aware of is EFI/BOOT, which
> contains BOOTX64.cfg, which I already modified with nouveau.modeset=0
> on each option to no avail. To my understanding this is the conf that
> should apply since this is the EFI boot folder, so I don't think that
> setting is the culprit. That said, it's not Xen.cfg, but I did 'ls -R
> | grep Xen.cfg' which resulted in nothing, then did 'ls -R | grep
> xen' which returned packages as well as xen.gz, then 'ls -R | grep
> Xen' which returned nothing, so I'm not sure there is such a config.
> 

Have you looked at this page?
https://www.qubes-os.org/doc/uefi-troubleshooting/

-- 
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/20190324221654.69e7724c.mike%40keehan.net.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: Blank Screen Trying To Install

2019-03-24 Thread Mike Keehan
On Sun, 24 Mar 2019 02:07:10 -0400
Yushatak  wrote:

> Machine has no legacy mode.
> 
> On Sat, Mar 23, 2019, 11:32 PM Gaijin  wrote:
> 
> > 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.
> >  
> 

I had exactly this problem when I installed Qubes.  Searching this mail
list found the answer.  (You have to edit the installation image, or
mount the image, edit it and build a new image for installation.)

Mike.

-- 
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/20190324153605.69690b17.mike%40keehan.net.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Qubes - Critique (long)

2019-03-16 Thread Mike Keehan
On Fri, 15 Mar 2019 21:31:02 -0500
John Goold  wrote:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> *A Critique of Qubes*
> 
Hi John,

What a nice read, thank you.  I have a very similar background, and age,
so I was very interested to read your story.

I've been using Qubes now for a few years, and love it.  Have had very 
little problem with it; have used and restored using the builtin backup
scheme; and have updated without problem using just the normal,
stable repositories.

The one thing I can suggest that I do differently to you, is that I
power down my laptop, and boot up afresh each day.  Have always done
this during my professional life (wasn't any choice early on as there
was no suspend option), and I can say that I have not experienced any
of the launch issues you described, nor any copy/paste issues between
VMs, not that I do much of that.

As for Flash, it is a pain.  Our BBC still uses it extensively, so I
have to manually download it occasionally and copy the library file
into the appVMs .mozilla directory when necessary.

Anyway, best of luck,

   Mike.

-- 
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/20190316124251.274962b1.mike%40keehan.net.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] dispvm browser retains information

2019-03-12 Thread Mike Keehan
On Tue, 12 Mar 2019 08:35:04 +
Jon deps  wrote:

> Hello,  in Thunderbird when I do open-in-vm and check firefox it has 
> retained bookmarks from a previous session,
> 
> I believe this is Not how DVMs are supposed to work ?
> 
> 
> If so how would I troubleshoot and/or  remove  old  DVM data
> sesssions please
> 

Is the qvm-prefs property "template_for_dispvms" True for your
dvm template?

Mike.

-- 
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/20190312100358.6ca6dd8a.mike%40keehan.net.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Hardware support

2019-03-04 Thread Mike Keehan
On Mon, 4 Mar 2019 12:41:23 +
"'Robin Murison' via qubes-users"  wrote:

> My hardware suppliers are sure my desktop supports IOMMU and yet when
> I try to install Qubes 4 the installation says it does not. My basic
> question is that error reported based on a white list or on the actual
> presence or absence of the feature.
> 
> I have checked with the hardware company that  IOMMU is available and
> does work and I have also checked with the company that built my
> machine that I have all the appropriate settings turned on in the
> BIOS.
> 
> Both say I am doing the right thing and that IOMMU should be working
> and I do not see my processor or mother board specifically on the
> supported hardware list.
> 
> my machine is custom built:
> 
> Processor (CPU)   AMD Athlon 5350 Quad Core APU (2.05GHz/AM1) &
> Radeon™ HD8400
> Motherboard   ASUS® AM1M-A: (M-ATX, DDR3, USB 3.0, 6Gb/s)
> 
> Thanks for any help
> 
> 
> Robin
> 

Hi Robin,

Qubes does a hardware test to determine if the IOMMU works.

According to Wikipedia's "List of IOMMU-supporting hardware" page,
https://en.wikipedia.org/wiki/List_of_IOMMU-supporting_hardware
there are some ASUS motherboards that do not work correctly with
IOMMU support.  You may be unlucky.

Mike.

-- 
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/20190304140755.3e4f47d4.mike%40keehan.net.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] not enough memory to start domain "xyz"

2019-02-16 Thread Mike Keehan
On Sat, 16 Feb 2019 18:56:39 +0100
evo  wrote:

> On 2/16/19 1:10 PM, Johannes Graumann wrote:
> > On Sat, 2019-02-16 at 11:21 +0100, evo wrote:  
> >>
> >> On 2/16/19 11:17 AM, Johannes Graumann wrote:  
> >>> On Sat, 2019-02-16 at 11:08 +0100, evo wrote:  
>  Hey!
> 
>  I got the  message that i don't have enough memory to start a
>  domain.
>  How can i understand, what exactly the problem is?
>  Is it a RAM problem on the dom, or in the domain itself, or on
>  the
>  whole
>  system?  
> >>> Others must answer this.
> >>>  
>  By the way, how can i check up how much RAM i have in the whole
>  laptop?
>  (I forgot it :D )  
> >>> 'free -m' on the CLI does the trick.
> >>>
> >>> Joh
> >>>  
> >>
> >> thanks.
> >> i knew about free -m, but i don't know where should i type it, to
> >> get the whole RAM on the machine. What is CLI? :)
> >>  
> > 
> > 'Command line interface'. Open a Shell on dom0 and type in that
> > command.
> >   
> 
> oh, but this can not be true, it shows me 2562 of total memory :D
> 

Use xentop in dom0 to see where all your memory is being used.

-- 
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/20190216184935.2164cfa8.mike%40keehan.net.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Suggestion about an UI detail

2019-02-05 Thread Mike Keehan
On Tue, 5 Feb 2019 13:58:17 +0100
Nicklas Avén  wrote:

> Hi
> 
> 
> I am a new happy Qubes user. Getting almost everything to work on a
> Dell 7530 with xeon 2186 and Nvidia P3200. Qubes 4.01 made things
> quite easy :-)
> 
> 
> I find Qubes very intuitive to work with, but I have a suggestion
> that I have no idea if it is easy or hard to do.
> 
> It is just a work flow thought without any knowledge about what would
> be affected.
> 
> 
> When I work in one qube it is a common task to open other programs in 
> the same qube. If working in a terminal I want Scite for scratching
> for instance.
> 
> Then it would be awesome if there was a quick way to get the 
> application-list from only that Qube. My suggestion is that I could
> find the application list for that specific Qube by right clicking
> the top of the application. In the menu about maximizing, minimizing
> and so on. With that in place I guess it would be possible to also
> put a key-combination on that feature. Since that would be a 1
> dimensional list it would be easy to navigate just with up and down
> arrows.
> 
> Just a thought since I notice, when I am in the middle of a thought
> in some work, it rips away the focus to think about what Qube I am
> in, searching the start menu for the right qube and then searching
> the application list for the right application.
> 
> I use Qubes primary to separate different customers when I work as a 
> consultant. Never mixing data from different jobs gives confidence.
> 
> BTW, I became a monthly supporter from today, worth every penny.
> Thanks a lot for Qubes OS
> 
> 
> ATB
> 
> 
> Nicklas Avén
> 
> 

Hi Nicklas,

I use a number of xfce Launchers on the taskbar to achieve something
similar.  Each of the launchers is for a separate qube, and has only
as many individual program entries as I want shortcuts for in that
qube.

This was described in this list some time ago, but I can't remember
who it was unfortunately, nor find the original email.  I think it was
in reply to a question about how to organise workflow, or maybe was
it possible to edit the main menu.  Anyway, kudos to the guy who 
described it - it's worked brilliantly for me ever since.

Mike.

-- 
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/20190205140802.567f64ca.mike%40keehan.net.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: why mail-list?

2019-02-01 Thread Mike Keehan
On Fri, 01 Feb 2019 16:24:22 -0500
kitchm  wrote:

> I think that it is far more helpful for someone who has
> actually done it to clearly and carefully explain the steps
> involved to use the mail list (or google group postings or
> whatever you call them) in Thunderbird and other e-mail
> clients, as well as Firefox and other web browsers or within
> Tutanota itself.
> 
> I have read everything that has been posted, plus the direct
> administrator's comments about how to do it, without finding
> anything that works so far.
> 
> Personal beliefs mean little when people are crying out for
> help.  If something can be proven to be intuitive, then
> speak up, or else hold your tongue.  The bottom line remains
> that it provably does not work at this point in time.
> 
> Thank you.
> 

What doesn't work?

-- 
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/20190201225726.145c80b0.mike%40keehan.net.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Backup stops when the backup file reaches 3Gb

2019-01-28 Thread Mike Keehan
On Fri, 25 Jan 2019 13:52:55 +
Mike Keehan  wrote:

> On Thu, 24 Jan 2019 11:29:50 +
> unman  wrote:
> 
> > On Thu, Jan 24, 2019 at 01:00:15AM -0500, Chris Laprise wrote:  
> > > On 01/23/2019 08:15 PM, js...@bitmessage.ch wrote:
> > > > Mike Keehan:
> > > > > Hi,
> > > > > 
> > > > > I'm using Qubes Backup to save some of my qubes into another
> > > > > VM. The backup VM has 18 Gb of storage available, but
> > > > > whenever the backup file reaches 3Gb, the backup process just
> > > > > hangs.
> > > > > 
> > > > > No CPU usage, no error messages, just stops.  The backup
> > > > > window shows 40% complete, but never moves any further
> > > > > (different % for different combinations of qubes in the
> > > > > backup list).
> > > > > 
> > > > > After waiting a considerable time (well, 5-10 minutes),
> > > > > hitting Cancel in the backup window does cancel it.  The rest
> > > > > of the system is continuing to work without problem.  Happens
> > > > > every time I try to use Qubes backup.
> > > > > 
> > > > > The Qubes Disk Space widget shows less than 50% disk used
> > > > > overall, the backupVM shows only 18% disk used when the 3Gb
> > > > > file has been saved.
> > > > > 
> > > > > I'm stumped.
> > > > > 
> > > > > Mike.
> > > > 
> > > > Hi,
> > > > 
> > > > You may have to wait longer than 5-10 minutes. I experience
> > > > something similar when doing a full backup, except it's worse
> > > > because i'm backing up like 2.5TB. It appears to hang for
> > > > several hours at a time (and this happens more than once), but
> > > > it does eventually make visible progress again. The whole
> > > > process takes over 24 hours. This is why i do full backups very
> > > > infrequently.
> > > > 
> > > > For you it shouldn't take nearly as long because it's a lot less
> > > > data, but the progress appearing to hang for a while seems to be
> > > > normal.
> > > > 
> > > > I'm using 3.2 tho, and i know they made changes to the backup
> > > > mechanism under the hood in 4.0, so i'm not sure if this issue
> > > > still applies in 4.0.
> > > 
> > > Marek,
> > > 
> > > Isn't this the null bytes bug in GNU tar?
> > > 
> > > https://groups.google.com/d/msgid/qubes-users/f4d997d5-7191-06d0-e7bb-ef42745a7db5%40posteo.net
> > > 
> > > It would be a good idea to update this in dom0. My own backup tool
> > > uses GNU tar as well.
> > > 
> > > -- 
> > > 
> > > Chris Laprise, tas...@posteo.net
> > > https://github.com/tasket
> > > https://twitter.com/ttaskett
> > > PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886
> > 
> > It seems a little early to judge.
> > 
> > Mike - it looks from your comment as if you have been trying with
> > subsets of the qubes? Can you confirm if these are running or
> > stopped.
> > 
> > Like jsnow, I'm regularly able to backup far more than 3G without
> > issue, so it looks as if there's something particular about this
> > scenario. It would be helpful if you could confirm the issue when
> > all qubes you are backing up are stopped.
> > Then try bisecting the qubes backup group - keep bisecting if you
> > hit the problem again until you either find the problematic qubes
> > or have backed them all up.
> >   
> 
> OK, progress:)
> 
> I can backup a list of stopped qubes, running out to a 10Gb file
> without any issues.  They all verify OK too.  However, backing up
> running qubes exhibits the problem.  
> 
> Starting up one of these qubes and trying to backup causes the
> progress indicator to stop at some point, BUT, the data is still
> being backed up to disk, and continues flowing for some time.  When
> the data flow stops, then I have to cancel the backup operation.
> However, verifying the backup works OK - file size reported is
> correct, and the verify process finishes successfully.  I haven't
> tried to actually restore one of these yet.
> 
> I tried recording the process status of both dom0 and the backup vm
> during the backups, but could not see any particular process dying
> when the progress updater stopped moving.  The tar processes stopped
> in dom0 but I guess

Re: [qubes-users] Fedora-26 template unable to update

2019-01-25 Thread Mike Keehan
On Fri, 25 Jan 2019 02:47:50 -0800
edalva...@riseup.net wrote:

> I've been struggling to update my Fedora-26 template for a while. So
> far none of the various bug-reports I've found on the issue seem to
> help. 
> 
> I've checked that all URL's in /etc/yum.repos.d/qubes-r4.repo use
> https as suggested. 
> 
> CONTENT OF /etc/yum.repos.d/qubes-r4.repo (disabled repos not shown):
> 
> _ name = Qubes OS Repository for VM (updates)_
> _ baseurl = https://yum.qubes-os.org/r4.0/current/vm/fc$releasever_
> _ #baseurl =
> http://yum.sik5nlgfc5qylnnsr57qrbm64zbdx6t4lreyhpon3ychmxmiem7tioad.onion/r4.0/current/vm/fc$releasever_
> _ gpgkey = file:///etc/pki/rpm-gpg/RPM-GPG-KEY-qubes-4-primary_
> _ skip_if_unavailable=False_
> _ gpgcheck = 1_
> _ enabled=1_
> 
> WHEN UPDATING, it doesn't look like DNF gets any fresh data:
> 
> [user@fedora-26 ~]$ sudo dnf -v update
>  Loaded plugins: builddep, config-manager, copr, debug,
> debuginfo-install, download, generate_completion_cache,
> needs-restarting, playground, qubes-hooks, repoclosure, repograph,
> repomanage, reposync
>  DNF version: 2.7.5
>  cachedir: /var/cache/dnf
>  repo: using cache for: updates
>  updates: using metadata from Tue May 29 13:05:48 2018.
>  repo: using cache for: fedora
>  not found deltainfo for: Fedora 26 - x86_64
>  not found updateinfo for: Fedora 26 - x86_64
>  fedora: using metadata from Wed Jul  5 22:31:38 2017.
>  repo: using cache for: qubes-vm-r4.0-current
>  not found deltainfo for: Qubes OS Repository for VM (updates)
>  not found updateinfo for: Qubes OS Repository for VM (updates)
>  qubes-vm-r4.0-current: using metadata from Wed Jan 23 16:47:03 2019.
>  Last metadata expiration check: 0:08:48 ago on Fri Jan 25 11:08:50
> 2019.
>  --> Starting dependency resolution
>  --> Finished dependency resolution  
>  Dependencies resolved.
>  Nothing to do.
>  Complete!
> 
> I've tried cleaning and refreshing:
> 
>  [user@fedora-26 ~]$ sudo dnf clean all
>  53 files removed
>  [user@fedora-26 ~]$ sudo dnf -v update --best --allowerasing
> --refresh --releasever=26
>  Loaded plugins: builddep, config-manager, copr, debug,
> debuginfo-install, download, generate_completion_cache,
> needs-restarting, playground, qubes-hooks, repoclosure, repograph,
> repomanage, reposync
>  DNF version: 2.7.5
>  cachedir: /var/cache/dnf
>  Fedora 26 - x86_64 - Updates703 kB/s |  22 MB
> 00:31
>  updates: using metadata from Tue May 29 13:05:48 2018.
>  Fedora 26 - x86_64  742 kB/s |  53 MB
> 01:13
>  not found deltainfo for: Fedora 26 - x86_64
>  not found updateinfo for: Fedora 26 - x86_64
>  fedora: using metadata from Wed Jul  5 22:31:38 2017.
>  Qubes OS Repository for VM (updates) 53 kB/s | 204 kB
> 00:03
>  not found deltainfo for: Qubes OS Repository for VM (updates)
>  not found updateinfo for: Qubes OS Repository for VM (updates)
>  qubes-vm-r4.0-current: using metadata from Fri Jan 25 00:45:03 2019.
>  Last metadata expiration check: 0:00:00 ago on Fri Jan 25 11:26:26
> 2019.
>  Completion plugin: Generating completion cache...
>  --> Starting dependency resolution
>  --> Finished dependency resolution  
>  Dependencies resolved.
>  Nothing to do.
>  Complete! 
> 
> Any suggestions on this? I really dislike to sit on a outdated
> system :/
> 
> 
> Best regards, 
> Ed Alvarez
> 

Fedora 26 reached end-of-life last year.  You need to install Fedora 28
at least, or Fedora 29.

Mike.

-- 
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/20190125160857.116f3d27.mike%40keehan.net.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Backup stops when the backup file reaches 3Gb

2019-01-25 Thread Mike Keehan
On Thu, 24 Jan 2019 11:29:50 +
unman  wrote:

> On Thu, Jan 24, 2019 at 01:00:15AM -0500, Chris Laprise wrote:
> > On 01/23/2019 08:15 PM, js...@bitmessage.ch wrote:  
> > > Mike Keehan:  
> > > > Hi,
> > > > 
> > > > I'm using Qubes Backup to save some of my qubes into another VM.
> > > > The backup VM has 18 Gb of storage available, but whenever the
> > > > backup file reaches 3Gb, the backup process just hangs.
> > > > 
> > > > No CPU usage, no error messages, just stops.  The backup window
> > > > shows 40% complete, but never moves any further (different % for
> > > > different combinations of qubes in the backup list).
> > > > 
> > > > After waiting a considerable time (well, 5-10 minutes), hitting
> > > > Cancel in the backup window does cancel it.  The rest of the
> > > > system is continuing to work without problem.  Happens every
> > > > time I try to use Qubes backup.
> > > > 
> > > > The Qubes Disk Space widget shows less than 50% disk used
> > > > overall, the backupVM shows only 18% disk used when the 3Gb
> > > > file has been saved.
> > > > 
> > > > I'm stumped.
> > > > 
> > > > Mike.  
> > > 
> > > Hi,
> > > 
> > > You may have to wait longer than 5-10 minutes. I experience
> > > something similar when doing a full backup, except it's worse
> > > because i'm backing up like 2.5TB. It appears to hang for several
> > > hours at a time (and this happens more than once), but it does
> > > eventually make visible progress again. The whole process takes
> > > over 24 hours. This is why i do full backups very infrequently.
> > > 
> > > For you it shouldn't take nearly as long because it's a lot less
> > > data, but the progress appearing to hang for a while seems to be
> > > normal.
> > > 
> > > I'm using 3.2 tho, and i know they made changes to the backup
> > > mechanism under the hood in 4.0, so i'm not sure if this issue
> > > still applies in 4.0.  
> > 
> > Marek,
> > 
> > Isn't this the null bytes bug in GNU tar?
> > 
> > https://groups.google.com/d/msgid/qubes-users/f4d997d5-7191-06d0-e7bb-ef42745a7db5%40posteo.net
> > 
> > It would be a good idea to update this in dom0. My own backup tool
> > uses GNU tar as well.
> > 
> > -- 
> > 
> > Chris Laprise, tas...@posteo.net
> > https://github.com/tasket
> > https://twitter.com/ttaskett
> > PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886  
> 
> It seems a little early to judge.
> 
> Mike - it looks from your comment as if you have been trying with
> subsets of the qubes? Can you confirm if these are running or stopped.
> 
> Like jsnow, I'm regularly able to backup far more than 3G without
> issue, so it looks as if there's something particular about this
> scenario. It would be helpful if you could confirm the issue when all
> qubes you are backing up are stopped.
> Then try bisecting the qubes backup group - keep bisecting if you hit
> the problem again until you either find the problematic qubes or have
> backed them all up.
> 

OK, progress:)

I can backup a list of stopped qubes, running out to a 10Gb file without
any issues.  They all verify OK too.  However, backing up running qubes
exhibits the problem.  

Starting up one of these qubes and trying to backup causes the progress
indicator to stop at some point, BUT, the data is still being backed up
to disk, and continues flowing for some time.  When the data flow stops,
then I have to cancel the backup operation.  However, verifying the
backup works OK - file size reported is correct, and the verify process
finishes successfully.  I haven't tried to actually restore one of
these yet.

I tried recording the process status of both dom0 and the backup vm
during the backups, but could not see any particular process dying when
the progress updater stopped moving.  The tar processes stopped in dom0
but I guess that was because they had finished creating the private.img
files.

So it looks like backing up a live VM causes the backup process to fail
at some point, but not before the data is actually backed up.  

It doesn't look like a tar null issue as the data does get to disk OK.
It's just the control of the backup process getting out of step
somewhere.

Mike.

-- 
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/20190125135255.23ddcca0.mike%40keehan.net.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Backup stops when the backup file reaches 3Gb

2019-01-24 Thread Mike Keehan
On Thu, 24 Jan 2019 11:27:00 -0500
Chris Laprise  wrote:

> On 01/24/2019 06:29 AM, unman wrote:
> > On Thu, Jan 24, 2019 at 01:00:15AM -0500, Chris Laprise wrote:  
> >> On 01/23/2019 08:15 PM, js...@bitmessage.ch wrote:  
> >>> Mike Keehan:  
> >>>> Hi,
> >>>>
> >>>> I'm using Qubes Backup to save some of my qubes into another VM.
> >>>> The backup VM has 18 Gb of storage available, but whenever the
> >>>> backup file reaches 3Gb, the backup process just hangs.
> >>>>
> >>>> No CPU usage, no error messages, just stops.  The backup window
> >>>> shows 40% complete, but never moves any further (different % for
> >>>> different combinations of qubes in the backup list).
> >>>>
> >>>> After waiting a considerable time (well, 5-10 minutes), hitting
> >>>> Cancel in the backup window does cancel it.  The rest of the
> >>>> system is continuing to work without problem.  Happens every
> >>>> time I try to use Qubes backup.
> >>>>
> >>>> The Qubes Disk Space widget shows less than 50% disk used
> >>>> overall, the backupVM shows only 18% disk used when the 3Gb file
> >>>> has been saved.
> >>>>
> >>>> I'm stumped.
> >>>>
> >>>> Mike.  
> >>>
> >>> Hi,
> >>>
> >>> You may have to wait longer than 5-10 minutes. I experience
> >>> something similar when doing a full backup, except it's worse
> >>> because i'm backing up like 2.5TB. It appears to hang for several
> >>> hours at a time (and this happens more than once), but it does
> >>> eventually make visible progress again. The whole process takes
> >>> over 24 hours. This is why i do full backups very infrequently.
> >>>
> >>> For you it shouldn't take nearly as long because it's a lot less
> >>> data, but the progress appearing to hang for a while seems to be
> >>> normal.
> >>>
> >>> I'm using 3.2 tho, and i know they made changes to the backup
> >>> mechanism under the hood in 4.0, so i'm not sure if this issue
> >>> still applies in 4.0.  
> >>
> >> Marek,
> >>
> >> Isn't this the null bytes bug in GNU tar?
> >>
> >> https://groups.google.com/d/msgid/qubes-users/f4d997d5-7191-06d0-e7bb-ef42745a7db5%40posteo.net
> >>
> >> It would be a good idea to update this in dom0. My own backup tool
> >> uses GNU tar as well.
> >>
> >> -- 
> >>
> >> Chris Laprise, tas...@posteo.net
> >> https://github.com/tasket
> >> https://twitter.com/ttaskett
> >> PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886  
> > 
> > It seems a little early to judge.
> > 
> > Mike - it looks from your comment as if you have been trying with
> > subsets of the qubes? Can you confirm if these are running or
> > stopped.
> > 
> > Like jsnow, I'm regularly able to backup far more than 3G without
> > issue, so it looks as if there's something particular about this
> > scenario. It would be helpful if you could confirm the issue when
> > all qubes you are backing up are stopped.
> > Then try bisecting the qubes backup group - keep bisecting if you
> > hit the problem again until you either find the problematic qubes
> > or have backed them all up.
> >   
> 
> Oops, I pasted the wrong link. Here is the correct one:
> 
> https://utcc.utoronto.ca/~cks/space/blog/sysadmin/TarFindingTruncateBug
> 
> The symptoms sound remarkably the same... potentially hours-long
> delays with no adverse effect on data. Trigger condition is not about
> size, but due to corner cases that involve backing up nulls.
> 

I left a backup running before I left home this morning - it was stuck
at 1.8Gb then (confirming that size is not the issue), and it was still
at 1.8Gb when I got home this evening.  That was about 8 hours or so.

I have a recollection from my dim and distant past, that I had a similar
stuck tar issue when it could not handle fifos.  Not Linux in those
days.  There is no mention of fifos (or sockets etc.) in the tar
manpage, so I don't know if gnu tar is supposed to handle them or not.
I had to use cpio to backup systems which contained those things.

Anyway, I'll investigate further tomorrow.  You have given me a number
of things to look into.  Thanks,

Mike.

-- 
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/20190124193856.01f80d02.mike%40keehan.net.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Backup stops when the backup file reaches 3Gb

2019-01-24 Thread Mike Keehan
On Thu, 24 Jan 2019 11:27:00 -0500
Chris Laprise  wrote:

> On 01/24/2019 06:29 AM, unman wrote:
> > On Thu, Jan 24, 2019 at 01:00:15AM -0500, Chris Laprise wrote:  
> >> On 01/23/2019 08:15 PM, js...@bitmessage.ch wrote:  
> >>> Mike Keehan:  
> >>>> Hi,
> >>>>
> >>>> I'm using Qubes Backup to save some of my qubes into another VM.
> >>>> The backup VM has 18 Gb of storage available, but whenever the
> >>>> backup file reaches 3Gb, the backup process just hangs.
> >>>>
> >>>> No CPU usage, no error messages, just stops.  The backup window
> >>>> shows 40% complete, but never moves any further (different % for
> >>>> different combinations of qubes in the backup list).
> >>>>
> >>>> After waiting a considerable time (well, 5-10 minutes), hitting
> >>>> Cancel in the backup window does cancel it.  The rest of the
> >>>> system is continuing to work without problem.  Happens every
> >>>> time I try to use Qubes backup.
> >>>>
> >>>> The Qubes Disk Space widget shows less than 50% disk used
> >>>> overall, the backupVM shows only 18% disk used when the 3Gb file
> >>>> has been saved.
> >>>>
> >>>> I'm stumped.
> >>>>
> >>>> Mike.  
> >>>
> >>> Hi,
> >>>
> >>> You may have to wait longer than 5-10 minutes. I experience
> >>> something similar when doing a full backup, except it's worse
> >>> because i'm backing up like 2.5TB. It appears to hang for several
> >>> hours at a time (and this happens more than once), but it does
> >>> eventually make visible progress again. The whole process takes
> >>> over 24 hours. This is why i do full backups very infrequently.
> >>>
> >>> For you it shouldn't take nearly as long because it's a lot less
> >>> data, but the progress appearing to hang for a while seems to be
> >>> normal.
> >>>
> >>> I'm using 3.2 tho, and i know they made changes to the backup
> >>> mechanism under the hood in 4.0, so i'm not sure if this issue
> >>> still applies in 4.0.  
> >>
> >> Marek,
> >>
> >> Isn't this the null bytes bug in GNU tar?
> >>
> >> https://groups.google.com/d/msgid/qubes-users/f4d997d5-7191-06d0-e7bb-ef42745a7db5%40posteo.net
> >>
> >> It would be a good idea to update this in dom0. My own backup tool
> >> uses GNU tar as well.
> >>
> >> -- 
> >>
> >> Chris Laprise, tas...@posteo.net
> >> https://github.com/tasket
> >> https://twitter.com/ttaskett
> >> PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886  
> > 
> > It seems a little early to judge.
> > 
> > Mike - it looks from your comment as if you have been trying with
> > subsets of the qubes? Can you confirm if these are running or
> > stopped.
> > 
> > Like jsnow, I'm regularly able to backup far more than 3G without
> > issue, so it looks as if there's something particular about this
> > scenario. It would be helpful if you could confirm the issue when
> > all qubes you are backing up are stopped.
> > Then try bisecting the qubes backup group - keep bisecting if you
> > hit the problem again until you either find the problematic qubes
> > or have backed them all up.
> >   
> 
> Oops, I pasted the wrong link. Here is the correct one:
> 
> https://utcc.utoronto.ca/~cks/space/blog/sysadmin/TarFindingTruncateBug
> 
> The symptoms sound remarkably the same... potentially hours-long
> delays with no adverse effect on data. Trigger condition is not about
> size, but due to corner cases that involve backing up nulls.
> 

Thanks to all of you !!

I've been out today, but will have a look at tracking down the culprit
tomorrow:)

Mike.

-- 
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/20190124184812.24128610.mike%40keehan.net.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Backup stops when the backup file reaches 3Gb

2019-01-23 Thread Mike Keehan
Hi,

I'm using Qubes Backup to save some of my qubes into another VM.
The backup VM has 18 Gb of storage available, but whenever the
backup file reaches 3Gb, the backup process just hangs.

No CPU usage, no error messages, just stops.  The backup window
shows 40% complete, but never moves any further (different % for
different combinations of qubes in the backup list).

After waiting a considerable time (well, 5-10 minutes), hitting
Cancel in the backup window does cancel it.  The rest of the
system is continuing to work without problem.  Happens every
time I try to use Qubes backup.

The Qubes Disk Space widget shows less than 50% disk used overall,
the backupVM shows only 18% disk used when the 3Gb file has been
saved.

I'm stumped.

Mike.

-- 
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/20190123174938.1371fa26.mike%40keehan.net.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] sys-net & sys-firewall fail to start, new install

2019-01-23 Thread Mike Keehan
On Tue, 22 Jan 2019 12:26:00 -0800 (PST)
Bryce  wrote:

> On Saturday, January 19, 2019 at 6:37:47 AM UTC-5, Mike Keehan wrote:
> > 
> > Ah, what a shame.  It does seem as if your iommu is a problem.
> > 
> > Without any other ideas, the only thing I can suggest is that you
> > try the latest Qubes 3.2 just to allow you to try out Qubes.  It
> > doesn't require the vt-d stuff, so might work on your box.
> > 
> > The other thing you can do is try googling for iommu and your cpu
> > together to see if others have had problems (not necessarily in
> > Qubes, just in general use).
> >  
> >   Mike.  
> 
> Well, just to put this out there, it seems as if my CPU doesn't
> support SLAT and maybe that's why (I thought from intel's page it
> did). Installing the latest 3 stable and I don't get any errors about
> IOMMU like I did with 4, but just like with 4 I do have to disable
> vt-d in bios in order to boot to the installer.
> 
> Unfortunately as soon as I turn vt-d back on, the system goes thru
> post, I see qubes start to boot and then after a minute (about when I
> think I'd see the disk password prompt) I get a message from my
> monitor that the input timing is wrong, which I've never seen on
> several other operating systems! Wierldy, I was able to reproduce
> this behavior by turning off vt-d, booting up fully and then was able
> to update without issues unlike in 4. Rebooted twice without issues,
> then turned vt-d back on and got the exact same behavior.
> 
> So I guess I just try out using 3.2 without vt-d.
> 
> I'll take a look around the users' group, but I don't see any real
> details on the qubes site for what the key differences are between 3
> & 4 are, can anyone point me to something that will tell me how worth
> it (secure) that it is to use 3.2 instead of replacing hardware to
> run 4?
> 

Hi Bryce,

Glad you got something working for you :)

This is a good description of the changes in Qubes 4.0 :-
   https://www.qubes-os.org/doc/releases/4.0/release-notes/

Mike.

-- 
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/20190123112857.72b8ec98.mike%40keehan.net.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Account

2019-01-21 Thread Mike Keehan
On Mon, 21 Jan 2019 20:44:30 +0100 (CET)
 wrote:

> I signed up for an account with Qubes and got the confirmation, and
> here I am.  But when I go to post a reply, I am not recognized.  Does
> anyone know why that is?
> 
> Thank  you.
> 

Your reply has to go via the gmail server.  I had the same problem
when my replies were being sent via my main email account's server.
I had to select the gmail server for replies to Qubes emails.

Mike

(this may not be your problem, but it was for me.)

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/20190121205854.7774a581.mike%40keehan.net.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] sys-net & sys-firewall fail to start, new install

2019-01-19 Thread Mike Keehan
On Fri, 18 Jan 2019 11:55:14 -0800 (PST)
Bryce  wrote:

> On Friday, January 18, 2019 at 11:42:32 AM UTC-5, Bryce wrote:
> > > That's odd.  You say you are installing 4.01, yet the qubes
> > > manager shows that fedora is only release 26.  I thought that
> > > Qubes 4.01 had Fedora 29 in it.
> > > 
> > > Mike.  
> > 
> > Well Mike that could be it; you made me check when you said that,
> > the image I used was "Qubes-R4.0-x86_64.iso" from 11/27/18. I
> > checked the about in qubes itself is 4.0 (R4.0). Looks like I
> > screwed up on which version I created the image from, I wrote down
> > 4.01 but that's not what I used- too much spiked eggnog maybe.
> > Since it doesn't seem to be possible for me to update with the VM's
> > not starting for USB or Net, I will get the latest image and and
> > reinstall to see if there's any issue. Thanks for pointing out my
> > goof, I'll try that today and see if the results are any
> > different!  
> 
> I Reinstalled w/ 4.01 (downloaded today) and sadly I seem to have the
> same issue. Here's what I did:
> * During install I realized what I had forgot before, that previous
> occasions I had to turn off "Intel VT for Direct I/O" in bios in
> order to get the installer to even work. If I don't turn that off,
> the screen goes black and nothing happens no matter which option I
> pick from the setup list- normal install, test & install, and basic
> graphics install all do the same. So I turn it off, and the install
> works fine until the language selections screen then I get an error
> that (I think) IOMMU or it's remapping support are missing, only
> advanced or devs etc should proceed. Thought I grabbed a pic but it
> didn't turn out. I go through the install until it needs to reboot,
> then immediately go back into bios and enable VT-d, and let it boot
> as normal. On the previous installations I don't think I did it
> before completing install, only after. It boots up fine, completes
> install with one error- during the templates setup I get the attached
> error about sys-firewall not starting up again due to libxenlight. I
> login, get to desktop and open qubes manager- all without more
> errors. Only dom0 is running again. Trying to start sys-net or
> sys-firewall gives me the same errors as before about libxenlight
> failing to start the qubes, even though VT-d is turned on. I tried
> unman's earlier suggestion of removing and re-adding the NIC, no luck.
> 
> I hope someone has another idea, is there a way to force vt-d on in
> qubes? Some screenshots attached.
> 

Ah, what a shame.  It does seem as if your iommu is a problem.

Without any other ideas, the only thing I can suggest is that you try
the latest Qubes 3.2 just to allow you to try out Qubes.  It doesn't
require the vt-d stuff, so might work on your box.

The other thing you can do is try googling for iommu and your cpu
together to see if others have had problems (not necessarily in
Qubes, just in general use).
 
  Mike.

-- 
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/20190119113741.1fc0a19f.mike%40keehan.net.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] sys-net & sys-firewall fail to start, new install

2019-01-18 Thread Mike Keehan
On Fri, 18 Jan 2019 08:14:43 -0800 (PST)
Bryce  wrote:

> On Friday, January 18, 2019 at 11:11:00 AM UTC-5, Mike Keehan wrote:
> > Ah, afraid I've run out of ideas now.
> > 
> > I was hoping it was just the iommu not being enabled, but not
> > starting any vm at all is not something I've seen before, as long
> > as there is enough memory.  16Gb is fine.
> > 
> > Sorry, out of inspiration now,
> > 
> > Mike.  
> 
> Thanks anyways Mike. I did manage to attach the pics of memory and
> qubes manager at least, in case they're useful for anyone.
> 

That's odd.  You say you are installing 4.01, yet the qubes manager
shows that fedora is only release 26.  I thought that Qubes 4.01 had
Fedora 29 in it.

Mike.

-- 
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/20190118163306.3c097104.mike%40keehan.net.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] sys-net & sys-firewall fail to start, new install

2019-01-18 Thread Mike Keehan
Ah, afraid I've run out of ideas now.

I was hoping it was just the iommu not being enabled, but not starting 
any vm at all is not something I've seen before, as long as there is
enough memory.  16Gb is fine.

Sorry, out of inspiration now,

Mike.

-- 
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/20190118161056.613bd9e3.mike%40keehan.net.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] sys-net & sys-firewall fail to start, new install

2019-01-18 Thread Mike Keehan
On Fri, 18 Jan 2019 07:17:00 -0800 (PST)
scott.lewis.engin...@gmail.com wrote:

> On Friday, January 18, 2019 at 9:16:59 AM UTC-5, unman wrote:
> > On Fri, Jan 18, 2019 at 07:40:30AM -0500, Scott wrote:  
> > > Thanks but unfortunately I don't know that issue helps, as those
> > > who were able to resolve it did so by updating which I cannot do
> > > since sys-net fails to start.
> > > 
> > > This issue, https://github.com/QubesOS/qubes-issues/issues/3349 ,
> > > seems to cover that problem but nothing's mentioned about net &
> > > firewall failing to start.
> > > 
> >  > 
> > > On Fri, Jan 18, 2019, 07:22 Mike Keehan  > >   
> > > > On Thu, 17 Jan 2019 16:42:28 -0800 (PST)
> > > > scott wrote:
> > > >  
> > > > > Hello, I apologize in advance if this has already been
> > > > > addressed but searching for "sys-net" & "libxl" give many
> > > > > confusing results, I don't see any that match both not
> > > > > working, and I'm completely new to Qubes. My problem is that
> > > > > after 2 different installs of the same version, 4.01, I keep
> > > > > getting the same problems: When I get into Qubes I cannot
> > > > > update dom0, and sys-net & sys-firewall both fail to start
> > > > > even though my NIC is correctly listed in devices for -net.
> > > > >
> > > > > Basic info:
> > > > > Dell Optiplex 780, bios= A15 as recommended in HCL.
> > > > > Qubes 4.01, sigs checked good.
> > > > > Install 1 done by USB, created in windows, had same issues as
> > > > > described below. Re-installed by DVD thinking I'd muffed
> > > > > something (think I read on reddit that USB installs made from
> > > > > windows had issues) and the behavior is exactly the same.
> > > > >
> > > > > Behavior observed:
> > > > > (anything in [xxx] is me telling you the variation, as I get
> > > > > this for 2 VM's, 2 error codes, etc.)
> > > > > * Dom0 starts and runs, but -net & -firewall will not.
> > > > > * When I attempt to manually start either, I get this error
> > > > > message: "ERROR: Start failed: internal error: libxenlight
> > > > > failed to create new domain 'sys-net' [or sys-firewall],
> > > > > see /var/log/libvirt/libxl/libxl-driver.log for details".
> > > > >
> > > > > When I less the log, I get these errors dozens of time with
> > > > > timestamps ranging from date of install to today: 1:
> > > > > "[date:time]: libxl:
> > > > > libxl_create.c:610:libxl_domain_make:domain creation fail:
> > > > > Operation not supported" 2: "[date:time]: libxl:
> > > > > libxl_create.c:982:initiate_domain_create:cannot make domain:
> > > > > -3" Those errors and nothing else.
> > > > >
> > > > > I've tried to update dom0 by command as found in docs, as
> > > > > well as through GUI without success. I found a page elsewhere
> > > > > that described temporarily putting NIC in firewall or another
> > > > > VM to see if it worked, but I must be doing it wrong as I
> > > > > always get loopback errors when trying to save. It always
> > > > > tells me failed, regardless. No wonder if network isn't
> > > > > working.
> > > > >
> > > > > Under sys-net, I see the correct name and model of my NIC,
> > > > > but I can't seem to figure out how to see if the NIC is
> > > > > operational since sys-net isn't working (new to qubes
> > > > > sorry!), however I verified my router is not showing an IP
> > > > > assigned, though link LED is on.
> > > > >
> > > > > If anyone can help me try to figure this out, I'd really
> > > > > appreciate it. I'm still a bit green on linux but I learn
> > > > > fast, I recently gave up on Windows (I hate 10 so much I
> > > > > could scream) so I'm trying to dive in with qubes (deep end
> > > > > of the pool I think) as it best suits my needs with the VM
> > > > > implementation.
> > > > >
> > > > > I'd post the log itself, but I can't seem to figure out how
> > > > > to make USB copy work yet since I've been beating my head on
> > > > > the networking issue.

  1   2   >