from:"mike"

Re: [qubes-users] SOS - Where is mdadm.conf?! I really really need to edit mdadm.conf on dom0

2023-04-13 Thread Mike Keehan

On Thu, 13 Apr 2023 11:08:09 -0700 (PDT)
leo...@gmail.com wrote:

> Long story short I had a drive failure, now all my RAID arrays incorrectly 
> show up as "raid0 inactive". Apparently one way to fix this is to manually 
> change the arrays to the correct levels in mdadm.conf, but I can't seem to 
> find that in my dom0 with the `locate` command.
> 
> Please help. I really need these arrays back. My damn fedora-34 template is 
> there so I can't even use sys-net
> 

Try "find / -name mdadm.conf -print

It's in /usr/lib/tmpfiles.d/ on my laptop, but I don't have raid.

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/E1pn2T8-00Aoba-Us%40relay09.mail.eu.clara.net.

[qubes-users] High dom0 cpu use

2023-03-27 Thread Mike Keehan

Xentop is showing dom0 using 50-60% cpu on my laptop, all the time.  It did
not always do this, but I don't know which update may have caused it.

Top within dom0 shows a few processes taking 5% or or less, so whatever is
causing the high cpu usage is either in the kernel, or in whatever Xen is
doing I guess.

Anyone have any clues to what is going on?

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/E1pgtr6-00EJnf-4v%40relay01.mail.eu.clara.net.

[qubes-users] High dom0 cpu usage

2023-03-27 Thread Mike Keehan

Xentop is showing dom0 using 50-60% cpu on my laptop, all the time.  It did
not always do this, but I don't know which update may have caused it.

Top within dom0 shows a few processes taking 5% or or less, so whatever is
causing the high cpu usage is either in the kernel, or in whatever Xen is
doing I guess.

Anyone have any clues to what is going on?

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/20230327211132.7facbbbf%40keehan.net.

Re: [qubes-users] Shutdown Delay

2022-12-28 Thread Mike Keehan


On 12/28/22 10:00, Ulrich Windl wrote:

Hi!

Am I the only one that sees extra shutdown delays?
It seems that everything is unmounted, but still thing hang; unsure what that 
is. See attachment.
What surprises me is that crypto seems to be stopped before unmount.

Regards,
Ulrich



NFS mounts can cause this sort of problem.

--
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/cd5a4011-6c57-e91b-0942-870ed8875f8a%40keehan.net.

Re: [qubes-users] Re: sys-firewall freezing on resume from suspend

2022-06-03 Thread Mike Keehan

On 6/3/22 15:00, 'qtpie' via qubes-users wrote:
So, apparently, this is not a sys-firewall, but a clocksync issue. To
root out any causes, I moved the clocksync service to a separate, brand
new qube (named sys-clock). And voila: sys-firewall no longer 'crashes'
on resume from suspend, now it's sys-clock.

The cause is probably somewhere in some logfile, but with the many
moving parts, Qubes really needs a better bugfixing howto. With
relatively many minor bugs like this, bugfixing takes too much time. I
don't mind spending some time fixing bugs, but lately it is really
becoming too much, to the extend that I am considering switching back to
an easier regular Linux distro. I have been a paid Linux sysadmin, no
total expert, but that is also not a requirement to use Qubes. I should
be able to diagnose bugs on my own laptop (and contribute to the project
by properly reporting them).

On 5/28/22 01:15, qtpie wrote:

Hi,

I have a really annoying issue with resume from suspend. On resume,
sys-firewall is crashed/freezed/unresponsive. So on every resume from
suspend, I need to kill and restart this VM if I want to use
networking. Other qubes are fine, except that sys-whonix also freezes,
but this is because it can't get a network connection to sys-firewall.

The VM is based on the default debian 11 template without any special
modifications. It has worked fine this way for years. Qubes is the
latest version. Kernel used 4.10.112.

Symptoms:
- High reported ram/cpu use, cpu hovering around 10-20%
- vm terminal: shows a blank window, no input/output shown
- xen console in dom0: no output
- does not pass networktraffic from connected VM's
- stopped connected VM's can't start because of failed vif (network
connection) creation.
- sometimes, after a shorter suspend, the VM still works, or it does
pass networktraffic while the vm still can't open a terminal window.

I've tried:
- checking both before and after suspend the VM console and syslog,
dom0 journal, dmesg, xen logs. It doesn't show any relevant error as
far as I can tell.

- creating a fresh sys-firewall VM. No change.
- switching the VM to a fedora 35 template, fully upgraded. No change
- checking possibly related issues on qubes github. But those are all
either fixed with updates, or about VM's with PCI devices connected,
which this VM doesn't.

What is this problem? Why does it only occur with sys-firewall VM?
Which logs to doublecheck? Any suggestions welcome.

My clocksync service runs in sysnet, not in sys-firewall. This is
Qubes 4.1

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/ab381859-dfd4-1eb6-a09b-9f59ca573e77%40keehan.net.

Re: [qubes-users] modifying Qubes ISO

2022-03-30 Thread Mike Keehan

On 3/30/22 14:48, haaber wrote:

Hi Haaber,

I used to have similar freezing problems with 4.0 on my Dell laptop.
I found that it was due to an upgrade to the intel-i915 driver in X.
Replacing the new version with an older version cured it for me.

However, I've had no trouble with Qubes 4.1.

A search for "linux xorg driver for i915" gives some idea of the
problems, but it is all a bit confusing.

ah. I extracted

xorg-x11-drv-intel-2.99.917-26.20160929.fc25.x86_64.rpm (year=2016)
xorg-x11-drv-intel-2.99.917-32.20171025.fc25.x86_64.rpm (year=2017)

from old qubes ISO's. How did you install / exchange them in the running
qubes system?

alternatively, I could also place one of these inside the qubes-4.1 ISO,
where we find actually

/Packages/xorg-x11-drv-intel-2.99.917-49.20210126.fc32.x86_64.rpm

Replacing this file is certainly more easy than changing the kernel of
the ISO itself :) Bernhard

I think (my old memory is not what it was!!) I used dnf to uninstall
the version in fedora, then used dnf with the rpm file in the current
directory to install the older version. And then you have to make dnf
ignore updates to that package. You will have to do a search for that
option to dnf (or possibly, an entry in a file somewhere), as I can't
remember that bit, sorry.

Mike.

Re: [qubes-users] modifying Qubes ISO

2022-03-30 Thread Mike Keehan

On 3/30/22 08:46, haaber wrote:

On 3/29/22 22:55, 'awokd' via qubes-users wrote:

haaber:

I need help to modify the Q4.1 installer ISO file. I did learn how to
pack & unpack isos. That is fine. The idea is a new install on a larger
SSD of Q4.1 instead of risky "upgarde" tentatives that finish less
clean. (benefit: if it fails I can go back to running Q4.0)

1) I naïvely placed a new kernel in /extrakernels but that does not seem
to impress the boot-loader. I find no way to select which kernel to
boot.

Not entirely sure what you are trying to accomplish here. A Qubes 4.1
install ISO with a newer kernel? Can't you install 4.1 with a recent
prebuilt ISO and update the kernel after? If it's due to hardware
incompatibilities, I've seen some install and update on one system, then
move the hard drive to the one with newer hardware.

Thanks for your reply! Badly enough, I rather need a "kernel downgrade":
any xen kernel 5.x will freeze my Q4.0 system between seconds and some
minutes (a curse on Intel and Dell at this point for selling shit at
high prices). So my qubes runs for one year now in a "disaster mode"
with a 4.19 kernel for xen, and normal 5.x kernels in guest VM's (mainly
debian). The same happens when I try a fresh install with Q4.1: install
attempts with the std ISO fail 100% by system freeze before finishing
installand leave an unbootable SSD behind.

Hi Haaber,

However, I've had no trouble with Qubes 4.1.

A search for "linux xorg driver for i915" gives some idea of the
problems, but it is all a bit confusing.

Mike

Re: [qubes-users] Add network drive to Dom0

2022-01-18 Thread Mike Keehan

On 1/18/22 15:17, William Fisher wrote:
I stil can't figure out how to mount the NAS on my local LAN as local
storage of my qubes (4.0) back-ups. How do I get Qubes to See the NAS drive?

On Monday, January 17, 2022 at 3:45:44 PM UTC-6 awokd wrote:

William Fisher:
> I'd like to add a network drive (Buffalo NAS)to my Qubes 4.0
system to back
> up my Qubes. Is it possible?
>
Yes. Attach it to a VM with qvm-block, then run the Qubes Backup
utility. More detail in here under Creating a backup:
https://www.qubes-os.org/doc/how-to-back-up-restore-and-migrate/
<https://www.qubes-os.org/doc/how-to-back-up-restore-and-migrate/> .

--
- don't top post

Mailing list etiquette:
- trim quoted reply to only relevant portions
- when possible, copy and paste text instead of screenshots

Hi William,

Dom0 has no network connection, so it isn't possible to connect
network storage to it.

When the Qubes backup process is run, it asks which VM should the
backup be sent to.

I have a VM called Backup in which I mount a shared folder from
my NAS device. The backup process works fine using this. And I
know that restores from the shared NAS folder work OK too, because
I test that occasionally.

Good luck,

Mike.

Re: [qubes-users] Trying to Install on a very new system (ASUS Pro WS WRX80E-SAGE SE WIFI)

2021-10-20 Thread Mike Keehan

On 10/19/21 7:05 AM, qubes-users_corr...@anywerx.com wrote:

Hello,

Very excited to try Qubes on a shiny new system. It looks like exactly
what I have wanted for quite some time--a way to run most everything in
its own VM. I have done this in an incomplete and somewhat naive
fashion using VMware Workstation (on Ubuntu) for a number of years, but
it is inefficient both in terms of resources and how difficult it is to
administer. Qubes looks perfect for me.

Unfortunately, the install is hanging, and I would like some pointers on
how to proceed. I am aware my system is not on the HCL, but it is a
well regarded (if recent) motherboard. I am willing to invest some time
to figure things out and maybe get it on the HCL. While I'm fairly
computer savvy, I haven't spent any time with Xen before.

I have tried both Qubes 4.0.4 and 4.1rc1. Failure mode is the same in
both cases.

What happens is that I get a whole bunch of information scrolling past
me (I don't know how to capture this). The messages go by really
fast--I don't seem to see any errors--then I get a memory map followed
by a message that Dom0 has all of the processors available, and there is
a pause. I believe at this point the system attempts to switch from
text mode to graphics mode. What happens is that the screen goes blank
and stays that way.

Given my guess that this is somehow related to the switch from text mode
to graphical mode, it may be significant to note that I happen to have
two NVIDIA RTX GPU's on the system; the first one in the PCI chain is a
3070, and other is a 3090. I have enabled IOMMU in the BIOS as I am
planning to run GPU passthru under some form of Linux--hopefully Qubes.

I have verified that the installation media is good by using it on a
different machine where I do get to the graphical installer.

Thank you for an assistance you can provide.

--QUC

Hi,

Nvidia graphics are notoriously difficult cards. I suggest you try an
AMD if possible.

Nvidia passthrough? Again, not easy, and some cards are actively
prevented by Nvidia from passthrough.

The IOMMU is required by Qubes, irrespective of any passthrough you
may want.

Best of luck,

Mike.

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.

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.

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.

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

2021-01-18 Thread Mike Keehan

On 1/17/21 7:57 PM, Steve Coleman wrote:
I have several Sandisk Ultra_Fit 32Gb which refuse to even be seen by my 
sys-usb (fedora-32 based template) but works just fine passing the 
device if I were to use dom0, which obviously I don't like to do but the 
devices are useless otherwise.

Are you using a sys-usb vm with its own controller? What templates are 
you using?

On Sun, Jan 17, 2021 at 12:57 PM Mike Keehan <mailto:m...@keehan.net>> wrote:

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?

I am using sys-usb on a laptop.

And I have to say that I have some usb devices also that do not work
properly in Qubes.  I even have one device that is only
visible on one particular old Windows laptop and on nothing else.  USB
seems to be very "flexible" in its implementation.

I have been thinking about setting up a RaspberryPie to use as a USB
interface, and using that to do the upload/download from the usb devices
and copy across the network.  Something to do while in lockdown maybe.

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/aac94eb5-0c88-fbd4-1172-5a5dfaeaf0ec%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.

[qubes-users] Re: Oryx Pro laptop (BOOTX64.cfg for Qubes 4.0.1)

2020-10-14 Thread Mike Gifford

I can open the .iso with "nano vim" but ultimately that doesn't get me to 
the config file /EFI/BOOT/BOOTX64.cfg that is described but not named in 
the following post.  

I'm also rather concerned why there are two "Original Installer ISO" files 
described here. Why doesn't he just list the filenames?

I'm also having difficult saving files to the .iso

Mike
On Monday, March 4, 2019 at 12:28:17 p.m. UTC-5 load...@gmail.com wrote:

> Finally I did it! Thanks to those who responded and did not remain 
> indifferent to my situation.
>
> Especially,
>
> 'Shahin Azad' who gave me this url-instruction: 
> https://www.engetsu-consulting.com/blog/installing-qubes-4-0-on-laptops-with-nvidia-gpus-that-do-not-support-the-nouveau-driver
>
> and
>
> '0brand' who told me how to use this instruction in right way.
>
> This is my steps:
>
> 1. I copied .iso-file to linux system.
> 2. Opened terminal and start command 'sudo su -'
> 3. 'chmod u+w /path/to/file.iso'
> 4. 'nano vim /path/to/file.iso'
> 5. Edit those lines which described in url: 
> https://www.engetsu-consulting.com/blog/installing-qubes-4-0-on-laptops-with-nvidia-gpus-that-do-not-support-the-nouveau-driver
> 6. Saved file and write on flash drive in DD-mode.
>
>
> I know, maybe this is not that easiest way, but this worked for me in my 
> case.
>

-- 
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/e1698c17-554c-48fa-abd9-7956be7d6dd2n%40googlegroups.com.

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

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

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 wonder what's the rationale of that decision; Fedora 25 isn't even
supported anymore. No offense or critic intended, just curiosity.

Regards, toptin.

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?

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

Mike.

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.

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.

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&utm_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 
<mailto: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 
<https://groups.google.com/d/msgid/qubes-users/fd11d452-73f0-4f3a-a16d-51a71ee43951%40googlegroups.com?utm_medium=email&utm_source=footer>.


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.

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 byt

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.

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.

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!

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

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.

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.

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.

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.

Mike.

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.

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  <mailto:viktor@gmail.com>>:
 >

...

 >
 > 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 w

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

plication-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
webpage that describes this.

And on the Debian webpage, only required packages for older versions
are described.


Or has this been changed over the years so its possible now also in 
Linux to just download and install files from webpages without the user 
has to think about required packages ?



Use a Fedora template instead of Debian.
They have different design criteria, as their documentation will tell 
you.  You want more up to date packages than Debian uses!


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/9d89faeb-374a-8873-030b-d17b6099036b%40keehan.net.

Re: [qubes-users] Re: EE-PROM of an Lenovo X230

2020-03-13 Thread Mike Karasoff

As far as I know, all the RaPi should work for this.  If you are looking for 
cost effective, you can get a RaPi Zero on Sparkfun or Adafruit for around $10. 
 I would expect NewEgg to be pricey.

‐‐‐ Original Message ‐‐‐
On Friday, March 13, 2020 7:48 PM,  wrote:

>  While I have read of others who just plowed though with whatever ch431a they 
> had, and gotten it to work.  I am inclined to look at getting a PI.   I am 
> looking at Newegg, I am guessing I can get the least expensive Raspberry Pi.  
> I have a few weeks before my Social Security is paid.   Most of my extra 
> money is now tied up in Corona-ing up my pantry and for other prevention 
> measures.
>
> Any suggestions of what - which Raspberry Pi to avoid?
>
> --
> 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/03a1a5ca-5471-4b0b-a621-11a869a95981%40googlegroups.com](https://groups.google.com/d/msgid/qubes-users/03a1a5ca-5471-4b0b-a621-11a869a95981%40googlegroups.com?utm_medium=email&utm_source=footer).

-- 
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/czUKkyNvkpg1Ww1QB9vTn7DHCqbbn2DVgFN0FrSE0qBv4EnNz_C7JHECxTkaeTFiRBcvXdTgYrc8y2bU3M2I6gRjlqEcUNnVLCe-DbilXsk%3D%40karatronics.com.

Re: [qubes-users] Re: EE-PROM of an Lenovo X230

2020-03-13 Thread Mike Karasoff

"I haven't found controllers that deliver 5V when flashing"

I agree with this halfway. All the CH341As I've personally seen supply 3.3VCC 
out of the box, but 5V logic. All of the schematics I've seen on the internet 
show this, so I don't think its just me. The 5V logic levels come from the 
CH341A which runs off the USB5V rail and is configured for 5VIO. 3.3VCC comes 
from a separate supply LDO. It is dumb, and I've wondered sometimes if the 
CH341A was designed to make things worse, though more likely an ad nauseam 
repetition of a bad design that is super cheap to produce and easy make a quick 
buck.

All the discussions I've seen on the CH341A voltage issues have to do with IO 
voltage, not VCC. I wouldn't call the IO voltage issue "garbage". It is a legit 
concern, and only Winbond can say differently.

On the X-230, the spec'd max VIH for the Windbond PROM is 3.7V with a 3.3VCC 
rail. The datasheet doesn't mention 5V IO tolerance. I don't doubt that 5V 
logic will work in many cases, but the real-world limit is set by physics, 
process, operating condition, and component skew. For a random PROM in a 
sufficiently large distribution of PROMs, we have to assume 5V will damage the 
IO, then your system won't boot, and you would have to change the PROM. It is a 
dice roll.

(BTW, I'm not addressing the CPU IO. I don't have a schematic or CPU specs to 
know what kind of protection is on that end, but one may be risking that as 
well.)

The RaPi method works well outt of the box @ 3.3VCC and 3.3V Logic using the 
latest Rasperian. One doesn't even need to connect to the internet. Suitable 
RaPi are available for $5-$10USD, but that won't give you the Pamona clip. The 
cheapest Pamona clip I've seen comes bundled with the CH341 for a few bucks, 
which is kind of funny. At least the RaPi can be used for other cool stuff.

I've also read about some people using Arduinos to program BIOS PROMs, though 
that seemed like more work than a RaPi.

>
> ‐‐‐ Original Message ‐‐‐
> On Friday, March 13, 2020 8:00 AM, unman un...@thirdeyesecurity.org wrote:
>
> > On Fri, Mar 13, 2020 at 03:35:05AM +, Mike Karasoff wrote:
> >
> > > As far as the voltages go, I'm not sure I understand unman's "garbage" 
> > > comment. The PROMs on your X-230 are 3.3V logic, but the CH341A 
> > > programmer usually has 5V logic. I've heard that some CH341A are 3.3V, 
> > > but that seems more because there are several different places in China 
> > > producing the same board and so its kind of random.
> > > I think you can use 5V logic to program these ICs, but you are doing so 
> > > at your own risk. There is no current limiting resistor on the CH341A 
> > > board, and some of the CH341A ICs have no label, which indicates a 
> > > potential "back ally" fab (i.e. counterfeit) that is common with low end 
> > > Chinese electronics. Point is, you'd be driving you motherboard with a 
> > > potentially out of spec, using an unknown IC at the wrong voltage, 
> > > without current protection. This is not necessarily safe for your Mobo, 
> > > but it might work for you.
> > > There is a mod to turn your programmer into a 3.3V device, but it seems 
> > > the mod doesn't work on newer programmers that don't have labels on the 
> > > chip. It didn't work for me, and internets reports that it didn't work 
> > > for others. I used a Raspberry Pi instead : 
> > > https://tomvanveen.eu/flashing-bios-chip-raspberry-pi/ The trick for the 
> > > RaPi was the arg "spispeed=512". I connected the Pamona clip included in 
> > > the CH341A Kit to the RaPi using fly wires, so my CH341A wasn't 
> > > completely useless, and was actually cheaper than the clip alone. China.
> >
> > If you look, my comment related to voltages AND chip id.
> > On the voltage front, my experience differs from what you have heard. I
> > haven't found controllers that deliver 5V when flashing, and I've
> > tested some.
> > There's some debate about whether the specs include an internal LDO or
> > not, depending on your knowledge of Chinese and reading of the spec.
> > All I can say is that I've used numerous cheap (and expensive)
> > programmers without mishap. (And, to repeat myself, nemeth reports the
> > same, as did Cornelius who provided the first schematic.)
> > So let's be clear - you are buying a cheap chip of unknown provenance.
> > That's the real risk here.
> > Some (which? some black ones? Which black ones?) controllers may have
> > a voltage issue, which

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] Re: EE-PROM of an Lenovo X230

2020-03-12 Thread Mike Karasoff

As far as the voltages go, I'm not sure I understand unman's "garbage" comment. 
 The PROMs on your X-230 are 3.3V logic, but the CH341A programmer usually has 
5V logic.  I've heard that some CH341A are 3.3V, but that seems more because 
there are several different places in China producing the same board and so its 
kind of random.

I think you can use 5V logic to program these ICs, but you are doing so at your 
own risk.  There is no current limiting resistor on the CH341A board, and some 
of the CH341A ICs have no label, which indicates a potential "back ally" fab 
(i.e. counterfeit) that is common with low end Chinese electronics.   Point is, 
you'd be driving you motherboard with a potentially out of spec, using an 
unknown IC at the wrong voltage, without current protection.  This is not 
necessarily safe for your Mobo, but it *might* work for you.

There is a mod to turn your programmer into a 3.3V device, but it seems the mod 
doesn't work on newer programmers that don't have labels on the chip. It didn't 
work for me, and internets reports that it didn't work for others.   I used a 
Raspberry Pi instead : https://tomvanveen.eu/flashing-bios-chip-raspberry-pi/  
The trick for the RaPi was the arg "spispeed=512".  I connected the Pamona clip 
included in the CH341A Kit to the RaPi using fly wires, so my CH341A wasn't 
completely useless, and was actually cheaper than the clip alone.  China.

‐‐‐ Original Message ‐‐‐
On Thursday, March 12, 2020 6:12 PM,  wrote:

> Thank you for your reply.  I will read through the documentation again, and 
> perhaps give it a trial some morning, before I begin to Sundown.
>
> I have another laptop, which in theory would run QUBES, (Mid 1009 17 MBP) but 
> my first efforts in trying to get QUBES working on it just revealed 
> difficulties.   This is part of why I am trying to get the Lenovo X230 to a 
> place where I can put QUBES on it.
>
> Yes, I actually tried to get QUBES working on it in the with the standard 
> BIOS, and while it installed, it complained -   I think the Virtualization 
> was not working or something.  I now read, I did the install incorrectly.  I 
> should have turned something off before Installing, and turn it back on 
> later.   One difficulty at a time.
>
> Which ever Linux I choose, I feel the real security of using the Lenovo 
> X-230, depends on having Core Boot/ Et Cetra.
>
> So I am committed to going on.   Thank you for your replies, I would be 
> perplexed on some things without your answers.   My being poor does not help. 
>  This would be so much easier if I had an at home high speed connection.   I 
> may post back in a day or four.
>
> --
> 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/2ea6774d-322a-4900-abf5-9963f03ed4fe%40googlegroups.com](https://groups.google.com/d/msgid/qubes-users/2ea6774d-322a-4900-abf5-9963f03ed4fe%40googlegroups.com?utm_medium=email&utm_source=footer).

-- 
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/9xH7pr5EVlO_HCYtUQPyknRo56yGz2g0IptvDXEmbp-uYWfG-EVaXyqVjAXIKPfj3I8kqzwpwyVvv925ZZ-Nr31SHqcFAJkUEKrqLSVUz_Q%3D%40karatronics.com.

[qubes-users] Clean ME vs. AEM?

2020-03-12 Thread Mike Karasoff

Hi all,

Looking at the Qubes AEM web page, I'm trying to work my head around the 
statement on "If you cleaned your Intel Management Engine with e.g. me_cleaner 
while installing CoreBoot then you are out of luck.".  I get that TXT is 
required for AEM, but the consequence to using AEM seems to be accepting Intel 
ME into my life.

>From everything I've read, ME seems like true evil.  Having an unauditable, 
>closed source, back door that owns my computer, even when shut down, seems way 
>more scary and unmanageable than the physical security issues that AEM 
>addresses.  On the surface, assuming me_cleaner successfully disables ME, it 
>seems like the ME requirement for AEM opens up more "harmful" issues than it 
>solves.I'm not an expert in security or x86 architecture, and just coming 
>up to speed on a lot of this stuff.  But after looking into this AEM and 
>me_cleaner stuff, I feel like I'm missing something.  If I indeed have to 
>choose between AEM or cleaning ME, then I'm looking for more info to help make 
>the choice.

Is the ME for AEM trade desirable because, from a practical standpoint, we know 
Evil Maids exist, whereas ME exploits are currently thought to be non-existent?
Is me_cleaner (or any other BIOS cleaner) considered a speculative solution to 
the ME problem?
Does cleaning the BIOS open the system up to additional security issues (e.g. 
does removing TXT make the processor less secure)?
Are there alternatives to me_cleaner that disable the ME engine but preserve 
TXT so AEM works?

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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/ju4npUkllMl6228r-YLjIPOgvu8Q8WGgBMpc8IhTBtCf8ANA9XFsovBJD0PL256Qmopq5gPULEiXomt8dQKBIiibuNOoi4JdMa-NvT2SJm8%3D%40karatronics.com.

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.

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.

Re: [qubes-users] Is CentOS in Qubes Broken?

2020-02-01 Thread Mike Karasoff

Hi,

Thank you.  This works.  It is very helpful.

I put in request for wiki update through git.

Mike

‐‐‐ Original Message ‐‐‐
On Saturday, February 1, 2020 9:51 AM, Frédéric Pierret 
 wrote:

> Hi,
>
> We have not put yes centos-7 in stable repository but soon!
>
> You can get it by enabling qubes-templates-community-testing:
>
> --enablerepo=qubes-templates-community-testing
>
> Best,
> Frédéric
>
> On 2020-02-01 01:59, Mike Karasoff wrote:
>
>> Hi,
>>
>> I'm trying to install the CentOS template, and cannot.  I failed both with 
>> getting the community template and trying to build one with qubes-builder.  
>> I'm using Qubes V4.0.  I've had no trouble building Debian based templates 
>> (bionic, buster).
>>
>> First, I tried to get the community template using the instructions from the 
>> docs here:  https://www.qubes-os.org/doc/templates/centos/
>>
>> The result was:
>> [user@dom0 ~]$ sudo qubes-dom0-update --enablerepo=qubes-templates-community 
>> qubes-template-centos-7
>> Using sys-firewall as UpdateVM to download updates for Dom0; this may take 
>> some time...
>> Last metadata expiration check: 22:12:59 ago on Thu Jan 30 17:43:53 2020.
>> No match for argument: qubes-template-centos-7
>> Error: Unable to find a match
>>
>> Has the centos template been removed?  Are there any pointers on how to 
>> search the qubes-templates-community repo?  I can't seem to find any links 
>> to that repo.
>>
>> I then tried to building the template with qubes-builder, and failed during 
>> make-template:
>> --> Finished Dependency Resolution
>> Error: Package: qubes-core-agent-4.0.52-1.centos7.x86_64 
>> (template-builder-repo)
>>Requires: python3-daemon
>> Error: Package: qubes-core-agent-4.0.52-1.centos7.x86_64 
>> (template-builder-repo)
>>Requires: python3-dbus
>> Error: Package: qubes-vm-recommended-4.0.6-1.centos7.noarch 
>> (template-builder-repo)
>>Requires: thunderbird-qubes
>> Error: Package: qubes-core-agent-4.0.52-1.centos7.x86_64 
>> (template-builder-repo)
>>Requires: python3-pyxdg
>> You could try using --skip-broken to work around the problem
>> You could try running: rpm -Va --nofiles --nodigest
>> make[1]: *** [Makefile:64: rootimg-build] Error 1
>>
>> Am I doing something wrong here?  I don't know enough about what is going on 
>> in this build process, but this feels like some packages aren't getting 
>> installed properly at some point upstream.
>>
>> Has support for CentOS in Qubes been discontinued or broken in a recent 
>> update?
>> Is this a bug?  It is not clear to me where I should report the bug - 
>> community or Qubes.
>>
>> 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 view this discussion on the web visit 
>> [https://groups.google.com/d/msgid/qubes-users/TqYjoJTboBJHBRRCGO3hIKgnMMwxHUGR4cfIztAL4-Z57iVmTwNFw3_WktVBkhTx2flOMj_Pekm_Md9w5P-L_gYyU-10HfWNlGolwmw6mmE%3D%40karatronics.com](https://groups.google.com/d/msgid/qubes-users/TqYjoJTboBJHBRRCGO3hIKgnMMwxHUGR4cfIztAL4-Z57iVmTwNFw3_WktVBkhTx2flOMj_Pekm_Md9w5P-L_gYyU-10HfWNlGolwmw6mmE%3D%40karatronics.com?utm_medium=email&utm_source=footer).

-- 
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/IDLpMm2wzvqp8WfhvfYRlgsiBe87PhYzO0epOpbNSiBY3GsBAhxLWITBj9bIbR1mLVmxj5TvTLrC-BC_Y1y2A457lhMbrwy2XpEPFI_zlqs%3D%40karatronics.com.

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:

[qubes-users] Is CentOS in Qubes Broken?

2020-01-31 Thread Mike Karasoff

Hi,

I'm trying to install the CentOS template, and cannot. I failed both with
getting the community template and trying to build one with qubes-builder. I'm
using Qubes V4.0. I've had no trouble building Debian based templates (bionic,
buster).

First, I tried to get the community template using the instructions from the
docs here: https://www.qubes-os.org/doc/templates/centos/

The result was:
[user@dom0 ~]$ sudo qubes-dom0-update --enablerepo=qubes-templates-community
qubes-template-centos-7
Using sys-firewall as UpdateVM to download updates for Dom0; this may take some
time...
Last metadata expiration check: 22:12:59 ago on Thu Jan 30 17:43:53 2020.
No match for argument: qubes-template-centos-7
Error: Unable to find a match

Has the centos template been removed? Are there any pointers on how to search
the qubes-templates-community repo? I can't seem to find any links to that
repo.

I then tried to building the template with qubes-builder, and failed during
make-template:
--> Finished Dependency Resolution

Error: Package: qubes-core-agent-4.0.52-1.centos7.x86_64 (template-builder-repo)

Requires: python3-daemon

Error: Package: qubes-core-agent-4.0.52-1.centos7.x86_64 (template-builder-repo)

Requires: python3-dbus

Error: Package: qubes-vm-recommended-4.0.6-1.centos7.noarch
(template-builder-repo)

Requires: thunderbird-qubes

Error: Package: qubes-core-agent-4.0.52-1.centos7.x86_64 (template-builder-repo)

Requires: python3-pyxdg

You could try using --skip-broken to work around the problem

You could try running: rpm -Va --nofiles --nodigest

make[1]: *** [Makefile:64: rootimg-build] Error 1

Am I doing something wrong here? I don't know enough about what is going on in
this build process, but this feels like some packages aren't getting installed
properly at some point upstream.

Has support for CentOS in Qubes been discontinued or broken in a recent update?
Is this a bug? It is not clear to me where I should report the bug - community
or Qubes.

Thanks,
Mike

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

2020-01-31 Thread Mike Keehan

n some time before the segfault appears.

Rather, the segfault mentions python3.5 and systemctl, and the
code lines show that the kernel is trying to close a socket.

Also, the line
  "[79152.712416] CPU: 1 PID: 2425 Comm: systemctl Tainted: G O"
is showing that a non-linux module has been loaded (the "O").  Do
you have a proprietary module that you load? (graphics, or network
drivers?).  If you can try without those it may help.

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/a4381fbd-0ef7-2fd3-7ba5-fe9703700e04%40keehan.net.

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

al: 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 physical
>configuration: broadcast=yes driver=vif ip=10.137.0.5 link=yes
> multicast=yes
> 
> 
> 
> service NetworkManager status:
> 
> ● NetworkManager.service - Network Manager
>Loaded: loaded (/usr/lib/systemd/system/NetworkManager.service;
> enabled; vendor preset: enabled)
> Drop-In: /usr/lib/systemd/system/NetworkManager.service.d
> └─30_qubes.conf Active: active (running) since Sun 2019-06-23
> 11:38:31 -03; 48min ago Docs: man:NetworkManager(8)
>   Process: 389
> ExecStartPre=/usr/lib/qubes/network-manager-prepare-conf-dir
> (code=exited, status=0/SUCCESS) Main PID: 412 (NetworkManager) Tasks:
> 4 (limit: 393) Memory: 2.7M
>CGroup: /system.slice/NetworkManager.service
>├─412 /usr/sbin/NetworkManager --no-daemon
>└─582 /sbin/dhclient -d -q -sf /usr/libexec/nm-dhcp-helper
> -pf /var/run/dhclient-ens6.pid
> -lf 
> /var/lib/NetworkManager/dhclient-c5ed704a-0800-3a65-bcc5-83e48dd42086-ens6.lease
> -cf /var/lib/NetworkMana>
> 
> Jun 23 11:38:39 sys-net NetworkManager[412]: 
> [1561300719.4213] manager: NetworkManager state is now CONNECTED_SITE
> Jun 23 11:38:39 sys-net NetworkManager[412]: 
> [1561300719.4214] policy: set 'Wired connection 1' (ens6) as default
> for IPv4 routing and DNS Jun 23 11:38:39 sys-net NetworkManager[412]:
>   [1561300719.4275] device (ens6): Activation: successful,
> device activated. Jun 23 11:38:39 sys-net NetworkManager[412]:
>   [1561300719.4280] manager: NetworkManager state is now
> CONNECTED_GLOBAL Jun 23 11:38:39 sys-net NetworkManager[412]: 
> [1561300719.4289] manager: startup complete Jun 23 11:38:39 sys-net
> dhclient[582]: bound to 192.168.25.11 -- renewal in 42127 seconds.
> Jun 23 11:57:16 sys-net NetworkManager[412]: 
> [1561301836.0227] manager: (vif11.0): new Ethernet device
> (/org/freedesktop/NetworkManager/Devices/4) Jun 23 11:57:16 sys-net
> NetworkManager[412]:   [1561301836.0995] device (vif11.0):
> carrier: link connected Jun 23 11:57:46 sys-net NetworkManager[412]:
>   [1561301866.2265] manager: (vif13.0): new Ethernet device
> (/org/freedesktop/NetworkManager/Devices/5) Jun 23 11:57:49 sys-net
> NetworkManager[412]:   [1561301869.0588] device (vif13.0):
> carrier: link connected
> 
> 
> 
> 
> 
> Anyone has any guess on how to solve this problem?
> 

Are you using the normal full fedora template for sys-net?
Does sys-net have the pci device selected in Qubes settings?
Are the modules ath, ath10k_core, ath10k_pci, cfg80211 and mac80211
running in sys-net?

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

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&Red  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] Re: Corebooted G505s Suspend/Resume Fails

2019-04-11 Thread Mike Banon

> Xen is difficult to debug without a classic onboard serial port for
> console output. Has to be some bug in that function.

Could Xen print messages to a screen? If yes, then it is possible to
find this function and insert the bunch of printf("1/2/3/etc") //
sleep(1) ( sleep is necessary to ensure that, before some action that
freezes the system, your just-printed message will be displayed on a
screen - without sleep, if it freezes too fast, may be not enough time
to display)

Although I have FT232H USB debug dongle, which could be used to get
the console output from USB 2.0 port (e.g. coreboot cbmem log) - I
don't know if it could be useful for Xen messages as well (and if any
extra configuration is required to make Xen output to this dongle),
and so many projects I don't have enough time to figure this out. So,
if you have some free time, you may try this printf / sleep approach
above.

Or, alternatively, please open a bug at Xen about this regression,
maybe they know an easy way of how to disable this check for AMD or at
least could provide some debugging ideas... It is in our best
interests that some solution for this problem gets upstreamed.

Best regards,
Mike Banon

--
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/CAK7947nLKz59r0qV-q0LFesufBUe3dm_KsJgkniguECBxGknVg%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Corebooted G505s Suspend/Resume Fails

2019-04-10 Thread Mike Banon

Excellent discovery, awokd and qubes123!
Please try to somehow upstream your solution to Xen.
Idea: find a way to detect a CPU type before executing this
"recheck_cpu_features(0)"
function, and if it is AMD CPU - maybe just skip this check :

> -if ( !recheck_cpu_features(0) )
> +/*if ( cpu_is_not_amd() && !recheck_cpu_features(0) )
>   panic("Missing previously available feature(s).");
> -
> +*/

Perhaps this problem affects all the AMD and not just the coreboot'ed ones,
but maybe only a few people are using AMD laptop with xen so nobody noticed it

Best regards,
Mike Banon

On Thu, Apr 11, 2019 at 2:47 AM awokd  wrote:
>
> awokd wrote on 4/10/19 8:50 PM:
>
> > Got my build environment going, but I think I am missing a step. I edit
> > /home/user/qubes-builder/chroot-dom0-fc25/home/user/rpmbuild/BUILD/xen-4.8.5/xen/arch/x86/acpi/power.c
> > with the above patch. Then I run "make vmm-xen". Then I see it has
> > overwritten my change and the code is no longer commented out. What am I
> > doing wrong?
>
> Never mind, forgot I had noted this down a while back:
>
> cd /home/user/qubes-builder
> sudo chroot chroot-dom0-fc25
> su user
> cd ~
> make -C rpmbuild/BUILD/xen-4.8.5/xen
>
> Then copy from the chroot's
> home/user/rpmbuild/BUILD/xen-4.8.5/xen/xen.{gz,efi} .
>
> For some reason closing & opening the lid doesn't do anything any more.
> Don't understand what that section of code would have to do with it.
> However, if I choose Suspend from the menu, and then hit a key it
> successfully resumes! Thank you, that is very interesting. It would be
> good to figure out what's broken and upstream the fix...
>
>

-- 
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/CAK7947n3X6BCwQKrMGm968F4DG7Lnqdr8cXG8ue43BVXG3RC0Q%40mail.gmail.com.
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.

1 2 3 >

1 - 100 of 208 matches

Mail list logo