Re: [qubes-users] KERNEL PANIC on booting installation media - Acer TravelMate B116 - Details Inside

2019-09-05 Thread 'awokd' via qubes-users
Guest:
> Hi Awokd,

>> If there is no way to disable HDMI audio completely, perhaps try the
>> external monitor or blacklist suggestions in here:
>> https://github.com/QubesOS/qubes-issues/issues/5247.
> 
> No option exists to disable HDMI Audio, or any VGA options for that matter in 
> the BIOS ;-/
> 
> Blacklisting the kernel module had no noticeable effect on the KERNEL PANIC 
> ;-/

How about connecting the external (HDMI audio supporting) monitor? If
it's the issue I linked, maybe making HDMI audio use an interrupt will
work around it.

> Somebody off list suggested that I recompile the kernel with a known good 
> config and only bring in the (diff) XEN options. That could work, but really 
> sounds like a rabbit hole. I also hear that Qubes is notoriously incompatible 
> on laptops? I wonder why this would be. Many other distros seem to have at 
> least a failsafe boot option with some basic support. Is it security or 
> visualization related related?

Qubes requires both Xen and Linux compatibility. Other distros have it
easy and only need Linux compat. Xen plays a major & differentiating
role in the security Qubes can provide.

> I guess it makes little sense to try older installation media before 3.2.1? 
> Is there any ETA for a new kernel qubes version? Is it possible that 4.0.2 
> will receive a different kernel version in its final release?

Wouldn't bother with older. Kernel 5.something is available in the
testing repo. Easiest way I can think to get it would be to pull the
laptop hard drive, install Qubes on it from a different machine, update
kernel, then move hard drive back. You could also build a custom ISO
with the 5.x kernel, but that gets a bit involved:
https://www.qubes-os.org/doc/qubes-iso-building/, and there's no
guarantee it will fix the issue. Maybe others on the list or lurking
have an easier method.

> Unless there are any other easy ideas available, I guess this is the end of 
> the road for me and I will have to make do with Debian and Virtualbox?

"Easy" = buy a different laptop! :) Afraid I'm out of other ideas. Next
might be to try to apply a similar code fix/workaround in events_base.c,
recompile, etc., but that's getting pretty in-depth for something I
could be completely wrong about. Hope you get a chance to use Qubes some
day.


-- 
You received this message because you are subscribed to the Google Groups 
"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/ae4a3a31-3faf-cb57-5711-0c3ce94afbcf%40danwin1210.me.


Re: [qubes-users] KERNEL PANIC on booting installation media - Acer TravelMate B116 - Details Inside

2019-09-05 Thread Guest
Hi Awokd,

>Thanks. Hope I'm not leading you on a wild goose chase.
Most tech things are once you get involved in the details ;-)

>That odd interrupt changed in Debian. I wonder if it is
>https://www.spinics.net/lists/kernel/msg2709360.html. Link is to a
>kernel issue that was occurring with i915 HDMI LPE on interrupt
>initialization, so it is in a similar place as the Xen events_base.c
>interrupt initialization we are seeing.

I read through it and do have an Intel graphics system, but I could not find 
any other similarities.

>If there is no way to disable HDMI audio completely, perhaps try the
>external monitor or blacklist suggestions in here:
>https://github.com/QubesOS/qubes-issues/issues/5247.

No option exists to disable HDMI Audio, or any VGA options for that matter in 
the BIOS ;-/

Blacklisting the kernel module had no noticeable effect on the KERNEL PANIC ;-/

Somebody off list suggested that I recompile the kernel with a known good 
config and only bring in the (diff) XEN options. That could work, but really 
sounds like a rabbit hole. I also hear that Qubes is notoriously incompatible 
on laptops? I wonder why this would be. Many other distros seem to have at 
least a failsafe boot option with some basic support. Is it security or 
visualization related related?

I guess it makes little sense to try older installation media before 3.2.1? Is 
there any ETA for a new kernel qubes version? Is it possible that 4.0.2 will 
receive a different kernel version in its final release?

Unless there are any other easy ideas available, I guess this is the end of the 
road for me and I will have to make do with Debian and Virtualbox?

Good day!
  

-- 
You received this message because you are subscribed to the Google Groups 
"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/E1i5zbh-00031s-Rw%40node2.secure-shield.at.


Re: [qubes-users] Debian-10 Updates fail via disposable net/firewall

2019-09-05 Thread ronpunz

On 9/4/19 12:02 PM, unman wrote:
> On Wed, Sep 04, 2019 at 08:12:27AM +, ronpunz wrote:
>> I have fresh install of Q4.0.2rc1
>>
>> I've setup disposable vm's for sys-net and sys-firewall. Everything
>> works well (i can update Fedora and Whonix) via dispVMs. However, Debian
>> template updates fail because Debian is calling for updates via sys-net
>> (which obviously cant start because disp-sys-net is running)
>>
>> Can anyone identify why and where Debian is calling up sys-net?
>>
>>
> I'm surprised at this. I wouldnt have expected Fedora templates
> to update.
> You need to edit the file /etc/qubes-rpc/policy/qubes.UpdatesProxy and
> change the target to the qube where you use the proxy.
>
Thanks that worked for me.

Like you, I'm surprised I was able to update the Fedora template prior
to changing the UpdateProxy. Is this an issue that should be raised as a
security 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/cf8ea258-dc2d-d138-fb79-45b6116cf5bb%40riseup.net.


pEpkey.asc
Description: application/pgp-keys


[qubes-users] HCL - Lenovo L380

2019-09-05 Thread gluonium
Tested successfully:
- video
- networking
- sleep
- keyboard backlight
- build-in bluetooth
- sound 

-- 
You received this message because you are subscribed to the Google Groups 
"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/Lo2-PWM--B-1%40tutanota.com.


Qubes-HCL-LENOVO-20M60019SC-20190905-204549.yml
Description: application/yaml


[qubes-users] Re: Debian-10 Updates fail via disposable net/firewall

2019-09-05 Thread rec wins
On 9/3/19 10:12 PM, ronpunz wrote:
> I have fresh install of Q4.0.2rc1
> 
> I've setup disposable vm's for sys-net and sys-firewall. Everything
> works well (i can update Fedora and Whonix) via dispVMs. However, Debian
> template updates fail because Debian is calling for updates via sys-net
> (which obviously cant start because disp-sys-net is running)
> 
> Can anyone identify why and where Debian is calling up sys-net?
> 
> 

I had a similar problem , with disposable sys-net only,   I changed
/etc/qubes-rpc/policy/qubes.UpdatesProxy

to sys-net2 (disposable)  however  wasn't getting updates in the end I
ended up changing it to sys-whonix  as a work around


If you do a search in the forum, you may see my previous posts  on this .

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/3bb73eea-1408-8351-2226-322be7b1f108%40riseup.net.


[qubes-users] Re: script to fix qubes-whonix time-sync issue

2019-09-05 Thread qtpie
unman:
> On Thu, Sep 05, 2019 at 12:23:13PM +0200, donoban wrote:
>> On 9/5/19 11:41 AM, qtpie wrote:> My usecase is this: suspend a laptop
>> with sys-whonix and whonix appvms
>>> running, then resume it a few hours later.
>>>
>>> After resume Tor lost connection, re-connection fails until i manually
>>> sync time on sys-net then
>>> @sys-firewall 'sudo ntpdate [timeserver]
>>> @sys-whonix 'sudo qvm-sync-clock'
>>> @sys-whonix 'sudo systemctl restart 
>>> tor-fCAy/bagh0fxz5zemyo...@public.gmane.org'
>>>
>>> Is this also you usecase? You do not expierence any issues after
>>> suspend/resume on qubes 4 with Tor running?
>>>
>>
>> Ouch yes, usually after suspend/resume I had to run just:
>> @sys-whonix 'sudo systemctl restart 
>> tor-fCAy/bagh0fxz5zemyo...@public.gmane.org'
>>
>>
>> Currently I am not using whonix, I am testing with minimal fedora torvm[1].
>>
>> It seems stable. I don't have problems with suspend/resume and I skipped
>> the sync clock steps [2]. Probably it's less anonymous than Whonix, but
>> for me seems fine.
>>
>> [1] https://hackmd.io/JIXLStC-Sbq8rr1mjomCDQ
> 
> You know there's a Qubes package for that? (deprecated but still
> buildable.)
> I have my own fork for a torVM which includes Qubes firewall
> support, which Whonix doesn't provide.
> 

Which package? I couldnt immediately find it.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/adad6717-2495-4dfb-d91a-e16c1bf50f1e%40disroot.org.


Re: [qubes-users] Cant connect hard drive to appvms?

2019-09-05 Thread unman
On Wed, Sep 04, 2019 at 08:12:26PM -0400, Stumpy wrote:
> I have a hard drive that i cant seem to connect to any of the appvms yet I
> can see and access it via dom0 (not good i know).
> I can attach a usb flash drive to my appvms but not the hard drive?
> 
> This is on my laptop and i do not have a sys-usb (didnt give me the option
> when installing qubes (v4.0.2) but if i can connect a flash then i cant
> figure why i cant connect the external hard drive to appvms, esp if i can
> use/see the drive via dom0?
> 
> Thoughts?
> 

It's notable that you dont say what you are doing and what does happen
(if anything). Any chance of a little more information?

-- 
You received this message because you are subscribed to the Google Groups 
"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/20190905144225.GC22350%40thirdeyesecurity.org.


Re: [qubes-users] Re: script to fix qubes-whonix time-sync issue

2019-09-05 Thread unman
On Thu, Sep 05, 2019 at 12:23:13PM +0200, donoban wrote:
> On 9/5/19 11:41 AM, qtpie wrote:> My usecase is this: suspend a laptop
> with sys-whonix and whonix appvms
> > running, then resume it a few hours later.
> > 
> > After resume Tor lost connection, re-connection fails until i manually
> > sync time on sys-net then
> > @sys-firewall 'sudo ntpdate [timeserver]
> > @sys-whonix 'sudo qvm-sync-clock'
> > @sys-whonix 'sudo systemctl restart tor@default.service'
> > 
> > Is this also you usecase? You do not expierence any issues after
> > suspend/resume on qubes 4 with Tor running?
> > 
> 
> Ouch yes, usually after suspend/resume I had to run just:
> @sys-whonix 'sudo systemctl restart tor@default.service'
> 
> 
> Currently I am not using whonix, I am testing with minimal fedora torvm[1].
> 
> It seems stable. I don't have problems with suspend/resume and I skipped
> the sync clock steps [2]. Probably it's less anonymous than Whonix, but
> for me seems fine.
> 
> [1] https://hackmd.io/JIXLStC-Sbq8rr1mjomCDQ

You know there's a Qubes package for that? (deprecated but still
buildable.)
I have my own fork for a torVM which includes Qubes firewall
support, which Whonix doesn't provide.

-- 
You received this message because you are subscribed to the Google Groups 
"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/20190905143831.GA22350%40thirdeyesecurity.org.


Re: [qubes-users] Re: script to fix qubes-whonix time-sync issue

2019-09-05 Thread donoban
On 9/5/19 11:41 AM, qtpie wrote:> My usecase is this: suspend a laptop
with sys-whonix and whonix appvms
> running, then resume it a few hours later.
> 
> After resume Tor lost connection, re-connection fails until i manually
> sync time on sys-net then
> @sys-firewall 'sudo ntpdate [timeserver]
> @sys-whonix 'sudo qvm-sync-clock'
> @sys-whonix 'sudo systemctl restart tor@default.service'
> 
> Is this also you usecase? You do not expierence any issues after
> suspend/resume on qubes 4 with Tor running?
> 

Ouch yes, usually after suspend/resume I had to run just:
@sys-whonix 'sudo systemctl restart tor@default.service'


Currently I am not using whonix, I am testing with minimal fedora torvm[1].

It seems stable. I don't have problems with suspend/resume and I skipped
the sync clock steps [2]. Probably it's less anonymous than Whonix, but
for me seems fine.

[1] https://hackmd.io/JIXLStC-Sbq8rr1mjomCDQ
[2]
https://hackmd.io/JIXLStC-Sbq8rr1mjomCDQ#Fix-clock-synchronization-issue-after-suspendresume-cycle-in-dom0

-- 
You received this message because you are subscribed to the Google Groups 
"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/5e95cec2-c4ce-390a-afa2-66ee1223f1ec%40riseup.net.


[qubes-users] Re: script to fix qubes-whonix time-sync issue

2019-09-05 Thread qtpie
donoban:
> On 9/3/19 9:31 PM, qtpie wrote:
>> The only issue I keep having with Qubes-Whonix, is that after
>> suspend/resume, Whonix-GW time is out of sync and cant connect to the
>> Tor network. According to Whonix the safe option is to simply not
>> suspend Whonix.
>>
>> https://www.whonix.org/wiki/Post_Install_Advice#Network_Time_Syncing
>>
>> However with a laptop running from battery not using suspend is not
>> really an option and manually shutting down multiple qubes is annoying.
>> To do this automatically I wrote this script, but cant get it working
>> yet. Any help is welcome.
>>
>> https://github.com/qtpies/qubes-whonix-suspending
> 
> Do you want to restart all domains using sys-whonix netvm? Probably
> there are better solutions and I think that Whonix already handles this
> properly. I used it for years and I only remember problems with this on
> Qubes 3.
> 
> Check:
> https://github.com/QubesOS/qubes-issues/issues/4989
> https://github.com/QubesOS/qubes-issues/issues/4939
> 

My usecase is this: suspend a laptop with sys-whonix and whonix appvms
running, then resume it a few hours later.

After resume Tor lost connection, re-connection fails until i manually
sync time on sys-net then
@sys-firewall 'sudo ntpdate [timeserver]
@sys-whonix 'sudo qvm-sync-clock'
@sys-whonix 'sudo systemctl restart tor@default.service'

Is this also you usecase? You do not expierence any issues after
suspend/resume on qubes 4 with Tor running?

-- 
You received this message because you are subscribed to the Google Groups 
"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/72f73585-4147-efbd-f1bd-79b650c16512%40disroot.org.


Re: [qubes-users] Re: Cant connect hard drive to appvms?

2019-09-05 Thread brendan . hoar
On Thursday, September 5, 2019 at 4:33:31 AM UTC-4, awokd wrote:
> b@gmail.com:
> 
> > USB: I generally have not attached USB drives (utilizing the USB IP support
> > via `qvm-usb` aka `qvm-device usb`) to VMs as I find it slow and sometimes
> > buggy.
> 
> I don't do that either, but using qvm-block to attach USB drives has 
> been stable for me. More secure too.

Ah yes. I too use qvm-block for my sata devices. 

What I neglected to mention was that several of my USB devices implement 
hardware  encryption (that replaces a small read-only volume with the main 
read-write volume after unlock).

The strategy choice then was a) unlock via sys-usb and utilize qvm-block or b) 
connect usb chipset to disposable VM and unlock there. I chose the latter.

B

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/4d57e821-3ee4-4f97-b240-f385047b430a%40googlegroups.com.


Re: [qubes-users] Re: Cant connect hard drive to appvms?

2019-09-05 Thread 'awokd' via qubes-users

brendan.h...@gmail.com:


USB: I generally have not attached USB drives (utilizing the USB IP support
via `qvm-usb` aka `qvm-device usb`) to VMs as I find it slow and sometimes
buggy.


I don't do that either, but using qvm-block to attach USB drives has 
been stable for me. More secure too.


--
You received this message because you are subscribed to the Google Groups 
"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/bc137555-924e-748d-0d38-ef12cc0c0db7%40danwin1210.me.