Re: [qubes-users] Runing Qubes on: HP ProBook 430 G2 or HP EliteBook 820

['Vincent Adultman' via qubes-users]

Linus Stridbeck  wrote:

> I came across very inexpensive HP computers:
> 
> HP ProBook 430 G2
> 
> HP EliteBook 820
> 
> They both have i3 procesor and I wonder if someone tried ryning Qubes on one 
> of them?
> 
> 
> 

I'm typing this on an 820 G3 with an i5 6200u cpu. Once I've had a bit more of 
a chance to play I'll post a proper HCL entry.

My existing 3.2 install has no problems booting on the machine, the features 
needed for 4 are supported (SLAT/EPT and interrupt remapping), but I haven't 
tested 4. The CPU should support 32gb, but the manual states 16gb is the max, I 
currently have one 16gb stick in one ram slot and this works fine. 
Virtualisation needed to be turned on in the BIOS.

Unlike older Elitebooks, it only seems to have a single USB controller, which 
is a pity, as it seems to mean ports, webcam and fingerprint reader are on the 
same controller, a pity as machine has interrupt remapping.

Issues I'm currently working through:

Screen brightness cannot be controlled using f5/f6 keys, however the brightness 
slider available from the power manager on the xfce system tray does control it.

Webcam doesn't seem to work with cheese in fedora 26, light on webcam flashes 
then cheese exits. 

Screen backlight stays on when screen is locked.

If you're looking at an older 820 with an i3, check the processor at ark 
https://ark.intel.com/ it's quite likely it may be missing some of the features 
required for Qubes / Qubes 4.

V

-- 
You received this message because you are subscribed to the Google Groups 
"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/eXFuzuxjvoru542I-jpWt2-KxF--sYhODPj3RIvTp570ZDreyu0S39dnKzAiYBUJVSPGCF6Tyi9PeHVxddyunDr0LMC_y-0P9IEl42i-ElA%3D%40protonmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] noscript xss warning on qubes os site

['Vincent Adultman' via qubes-users]

Confirm I get this too with noscript in firefox. Will try and get some details 
together if I can and file an issue...

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

Re: [qubes-users] Re: QSB #37: Information leaks due to processor speculative execution bugs (XSA-254, Meltdown & Sepctre)

['Vincent Adultman' via qubes-users]

>> Only running VMs are vulnerable
>>
>> Since Qubes OS is a memory-hungry system, it seems that an attacker
>> would only be able to steal secrets from VMs running concurrently with
>> the attacking VM. This is because any pages from shutdown VMs will
>> typically very quickly get allocated to other, running VMs and get wiped
>> as part of this procedure.

IIUC this still seems fairly awful from a usability perspective if we think of 
the added cognitive load of watching what is running when and remembering or 
making choices on what to close / restart when (I'm reading between the lines 
and guessing this has had something to do with decision on reintroduction of 
Qubes manager?).

sys-net is considered to be likely / easily compromised (such that there seems 
some real utility in making it a dispvm under 4). However, it will also be 
running for most users in most everyday cases for long periods.

A common use case for open at one time for me for internet banking might be at 
minimum sys-net, sys-firewall, sys-usb, vault and a dispvm (as shitty banks 
here often loading things off marketing or even advertising network domains 
changing fairly regularly). If we're saying that in an ideal situation, sys-net 
and sys-usb (if it has had any untrusted devices attached to it) are started 
clean else the secrets vault is at risk, that seems to remain a very serious 
problem. The other approach seems to be to store the banking secrets in a 
banking vm, and do the browsing as well from there. Some sensitive tasks can no 
doubt be done with sys-net shut down, but by no means all.

If we're considering that this will be the case for quite some time(?) due to 
Xen approach, do we need to offer some sort of recipe situation for vm-start 
(where I can ensure my "red" vms are shut down or cycled before my vault is 
started for example).

I try to pay my Qubes dues by offering assistance in IRC, and I'm anticipating 
here the sort of user willing to put effort into thinking about how they need 
to partition their domains, and maybe even write some custom rules / scripts 
but after that needs the system not to overly get in the way of day to day 
tasks / require constant tinkering.

Vince

-- 
You received this message because you are subscribed to the Google Groups 
"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/y4JzRn90_0mDNiNrt3Hq_kPJY6KbTxstTz8z2KvR_8ORlcJ7thJC0zOZupxxEuewcc3TnhVx5Rrz400I1B6XLy9BYjNVHinu4kNHFRn7dIU%3D%40protonmail.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] 3.2.1 / An updated 3.2 iso?

['Vincent Adultman' via qubes-users]

Hi all

We were chatting today in IRC about current user expectations and experiences 
with the 4 release candidates. While many are happily testing there are indeed 
some visitors who drop by with the requirement of a daily driver stable system, 
but have some newer hardware than the kernel on the current 3.2 iso will 
support. These users seem to be in a somewhat painful position, the bravest are 
attempting to build their own isos or perform some cross install using a 
machine that will work. Some fail / give up.

https://www.qubes-os.org/doc/supported-versions/ suggests that at some point a 
3.2.1 release was/is planned, h01ger suggested to me all focus is currently on 
4, but can I ask:

1. What are the current plans for 3.2.1? (if it was planned to be anything 
other than an updated iso)
2. Regardless of 1. is there a possibility of getting an updated 3.2 iso for 
Christmas, given that some will undoubtedly use the holiday time to try Qubes, 
quite possibly on shiny new hardware :)

Thanks for your time.

V

-- 
You received this message because you are subscribed to the Google Groups 
"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/N-1wnPOykS8pCH8sPzKe9RLHQ4fxFkfG2II-1yZdMUHiuRzDUIyJuo53uH1j30YuVS7nmj0yjRWZr6_xiPCaNirEDjD8ebGDoe4ak7n9jwc%3D%40protonmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] kswapd0 using 100% CPU with not even a MB swap in use

['Vincent Adultman' via qubes-users]

>> On 10/08/2017 08:18 AM, Marek Marczykowski-Górecki wrote:
>
> Indeed on 4.9.45-21 kernel it happens much rarer than on 4.4.x, but still
> happens sometimes...

It's only anecdotal, but I seem to have been seeing it more frequently recently 
(i.e. on that kernel). Will try the one-liner again, don't think it had any 
effect last time I tried it. I've got at least one old laptop with probably 
poor thermal paste or a dust bunny that this actually causes to overheat and 
shut down in a warm room. Less critically, for what's often a laptop OS it's 
rather hard on the battery.

FWIW (beware, anecdote incoming) the problem does seem different under the 
newer kernel, in that close enough other vms and the one with the problem may 
settle down (which I don't remember happening before). However, this makes 
limited sense to me, given that one vm that does it (sys-net) is not included 
in memory balancing, whereas others that randomly do it are. The vms that do it 
are fedora service vms, through to debian ones running chromium, the 
commonality being the kernel.

A quick google suggests this occurs / or has occurred on a variety of linux 
distros, but I do wonder if something about a memory constrained qubes install 
makes it more likely.

Marak, afaik there is no bug open for this, would it be worth me opening one, 
even if its just to track and add to a known issues page or similar? Seems 
enough of us run into this one.

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

Re: [qubes-users] Fedora25 fails updates unless I reboot the machine 9.13.17

['Vincent Adultman' via qubes-users]

I'm experiencing a similar problem which I've reported a bug for at 
https://github.com/QubesOS/qubes-issues/issues/3135

If you're still encountering the issue with the update proxy failing too, could 
you check the output of "journalctl -u qubes-updates-proxy.service" when it 
fails please? Marek also asked whether I have a broken network cable (n/a) or 
poor wifi (signal seems strong enough, i.e. no dropouts and problem occurs 
across different wifi networks), so it would be good to know that for you too.

If you don't like github, happy to post any responses here into the ticket I 
have open.

I've found a workaround (specified in the ticket) that fixes it for me, but 
interested to know if we're dealing with one problem, or different ones.

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/bumk34huiaO0hR8GdTU-HteBpeYDys3Z61RGy68KKgXkOb3lYT7BHoGQaxUxBVJERY52j6tsT42DVZEJAMo4nILhFK8HF5o7iegYzezsFo4%3D%40protonmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Qubes 3.2 Building an up to date dom0 3.18 Kernel

['Vincent Adultman' via qubes-users]

>  Original Message 
> Subject: [qubes-users] Re: Qubes 3.2 Building an up to date dom0 3.18 Kernel
> Local Time: August 21, 2017 2:38 PM
> UTC Time: August 21, 2017 1:38 PM
> From: r...@reginaldtiangha.com
> To: qubes-users@googlegroups.com
>
> If you don"t trust me, you can easily do it yourself. Just clone the
> master qubes-linux-kernel repo from the QubesOS account, change the
> number in the "version" file to the latest number (as of now, it"s
> 3.18.66 but you can verify that at kernel.org) and that"ll update what"s
> already there.
>
> But some Xen security patches released since the last 3.18 version will
> be missing and you"ll probably want to add those. Easiest way to do that
> is to go here:
>
> https://xenbits.xen.org/xsa/
>
> and grab any patches from there that have to do with the Kernel since
> the last time a 3.18 release was pushed out and add them to your tree
> (you can look at how Marek has applied them in the 4.9 branch; basically
> you add the path to the patch into the series.conf file). Hint: It"s XSA
> 157 (though not all five of them) and XSA 216.
>
> Finally, for bonus points, if you want a slightly harder kernel, you can
> implement some of the KSPP recommended settings listed here (but not all
> of them exist in 3.18 so you"ll need to search first):
>
> https://kernsec.org/wiki/index.php/Kernel_Self_Protection_Project
>
> and the Linux Hardened project here:
>
> https://github.com/copperhead/linux-hardened/wiki/Upstream-progress-tracking
>
> Those are basically the only changes I"ve made; in the 4.9+ kernel
> configs, other changes have been for newer driver support that didn"t
> exist in older versions. Good luck!

Thanks for your time in replying Reg, something that interests me is the 
necessity of building in a FC23 VM. Would you agree there's a possibility of 
security issues whilst building as FC23 is EOL? (when fetching or verifying), 
not sure how Qubes builder gets around this, having tried in an up to date FC25 
VM, it fails building the rpms despite dracut being up to date

-- 
You received this message because you are subscribed to the Google Groups 
"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/BgtQzRK-xgZZQIpZDePIGRT0rY7-SmrYVrfLS5BCpJn1th96VSJcgi4B4Kbn-WUapQ6Rm8T8zNN0840ImLeJ-RFnM_RGj_9KQqo_8OfmX-Q%3D%40protonmail.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Qubes 3.2 Building an up to date dom0 3.18 Kernel

['Vincent Adultman' via qubes-users]

As previously detailed ad nauseum, none of the Qubes dom0 4.4 or 4.9 version 
Kernels will boot on my laptop (HP Elitebook 2540p). This means I'm stuck on 
the ancient 3.18.17-8.

I'm comfortable(ish - have built a Xenial template) using Qubes builder and I 
notice Reg Tiangha has a repo with updated 3.18 kernel at 
https://github.com/rtiangha/qubes-linux-kernel/ I notice Reg also submits 
patches which are merged into the official qubes-linux-kernel repo after review 
by Marek.

1. Is there any chance of getting the updated 3.18 kernel merged into the 
official repos so anyone (read me) with truculent hardware can remain on this, 
even if it means building the package ourselves? (this is actually what I was 
envisaging maybe happening when previously inquiring whether it was possible to 
buy a support case from ITL)

2. If not (not worth the effort of Marek to review?) given the existence of 
[https://github.com/rtiangha/qubes-linux-kernel](https://github.com/rtiangha/qubes-linux-kernel/)
 what are the suggestions to an 'ordinary' end user who wants to build a 3.18 
kernel from there? Specifically, I'd be extending my trust from the Qubes 
developers to Reg, who apart from clearly being active in the Qubes community, 
I know nothing about. Are there sensible actions that can / should be taken 
with git to verify the kernel code? No insult to Reg here intended whatsoever :)

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/NoNPAoqjdRjpJ4aVcJXpaFMHKYJAWeRFLl6U98aj1bcPWbWnAMcCC9n-KpzknHplNV8yAk3Rn_Yq43IaYufwmViyWUF7Cg5La4jzZUye-SE%3D%40protonmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Seeking moderators for unofficial Qubes IRC channels on Freenode and OFTC

['Vincent Adultman' via qubes-users]

> Qubes should not associate themselves with freenode or irc. That"s just my 
> opinion. Nobody with self respect or integrity has taken freenode serious for 
> over 10 years. It should stay unofficial.

Not to knock what you're saying, but I think it's important for us to draw a 
distinction as a community between the infrastructure being potentially 
dangerous (which is the approach taken by ITL to the google list, the hosting 
services etc) with clear suggested mitigating actions for the end user to take 
(use GPG email, verify your ISO download etc) and the possibility that there 
are malicious individuals present on a medium wanting to do naive users harm 
(which seems on its face to be an argument towards moderating the IRC 
channels). Neither seem to be solved problems for IRC.
We're in the difficult position of most other Linux distributions maintaining a 
freenode / IRC presence and advertising this [1] [2] [3] [4] [5] i.e. it's semi 
expected there will be some semi respectable community members idling. A very 
interesting point here is it's taken as a given that people understand that you 
should take advice on IRC at your own risk, and not explicitly stated anywhere 
by any of those distros. I don't think we should assume this is common 
knowledge for our user base, which I would argue is made up of very technically 
minded users, as well as users with other motivations (security, privacy) 
without much in the way of technical knowledge. Either camp may bowl up to the 
#qubes channel. If we think this is a bad idea™ I think we ought to clearly 
state so and why on the website. I can't immediately see on the website if 
anything is said of IRC, I thought the unofficial channel had been moved to 
OFTC for better tor support but I don't immediately see a mention of that.

> I think google forums are a lot easier to use then installing some irc client 
> or connecting to a webchat, where the only people there are criminals or 
> spammers who want to exploit you or the network.

Yes definitely easier, but a lot of people want to hang around and immerse 
themselves in community chat to learn, or to be part of that community. We 
shouldn't underestimate the number of people out there who outright hate the 
mailing list format, or even web forums. I do think live chat helps a community 
attract people who can be helpful to it.

> Freenode and its communities are the sole reason Linux is unpopular.

Be interested to know more about what you mean by this?

> Its one of the most dangerous places to connect to, besides online games, 
> some porn sites, and darknet sites like silk road. I mean come on, it was 
> hilarious how it was portrayed on Mr. Robot, but they were not that far off.
> Even though they brought back tor support, which is a catch22 for them, 
> (although you would need a special tor setup, standard setups dont" work) 
> Recommending people go to freenode is like leading sheeps to slaughter.

Again we seem to be running up against the common knowledge problem. On my own 
(out dated) experience the risks associated with IRC were 1) the client being 
vulnerable to attack (shoutouts to mirc [6], xchat [7]) and 2) exposure of your 
internet facing IP address. Generally (showing my age) bouncers were used for 
the latter and I guess (not used IRC in 5 years) connection these days would be 
through whonix (who even on their wiki have a footer that says "bored? join us 
in IRC chat"). Where IRC seems to be a bad idea, is in the fact that you can't 
easily get a bouncer anonymously and IRC networks supporting TOR connections is 
a damned if you do and damned if you don't situation for them.
My ultimate feelings (and the reason I've never joined a #qubes IRC channel to 
date) and why I sort of agree with you are summed up in 
https://phabricator.whonix.org/T361 which links to the associated Tor and Qubes 
tickets.
Slack I've never used, but am put off by the fact it's proprietary. As a major 
factor in having an IRC channel is "users expect it because it's what other 
distros do" this raises the question do other distros have slack channels?
I probably agree more with Jean-Philippe (when in Rome...) you mention Matrix, 
looks interesting, is there a good primer anywhere on how it solves the IRC 
problems discussed in the whonix and tor tickets? (yes, being lazy, sorry...)
Disclaimer of interest = spent unhealthy proportion of teenage years running 
gaming IRC channels, suffering with bad case of nostalgia.
[[1] 
https://wiki.ubuntu.com/IRC/ChannelList](https://wiki.ubuntu.com/IRC/ChannelList)
[2] https://community.ubuntu.com/contribute/support/irc/
[3] https://help.ubuntu.com/community/InternetRelayChat
[4] https://wiki.archlinux.org/index.php/IRC_channel
[5] https://fedoraproject.org/wiki/How_to_use_IRC
[6] 
https://www.cvedetails.com/vulnerability-list/vendor_id-189/product_id-325/Khaled-Mardam-bey-Mirc.html
[7] https://www.cvedetails.com/vulnerability-list/vendor_id-552/Xchat.html

-- 
You 

Re: [qubes-users] Request for feedback: 4.9 Kernel

['Vincent Adultman' via qubes-users]

> Specifically, it'd be nice to know if:
> 2) Hardware that didn't work with 4.4 or 4.8 still doesn't work.

Having just tried 4.9.35-19, this has the same problem as every other 4.x 
kernel on my HP Elitebook 2540p (Intel HD graphics), that is as soon as the 
Qubes boot screen comes up, the graphics are corrupted. It was possible to 
enter the encryption password however the machine rebooted itself very soon 
after. Again this is consistent with every other 4.x kernel, either it reboots 
before the password prompt, or soon after. Only once has it ever got to the 
point of trying to start X.
Is there anything useful I can provide given that the machine doesn't have a 
docking port or a serial port?

-- 
You received this message because you are subscribed to the Google Groups 
"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/9zFS1mqITeGtu-2v-gaYYitnt-gSLuVuYtlQz8ISwc33mKiu8Y_yCC4a1q5TsmuZZoxz4P3tdvCILWWl__XjZ_VWR436mki-ARMLSjT8DNU%3D%40protonmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: What do you think about Grsecurity future ?

['Vincent Adultman' via qubes-users]

>  Original Message 
> Subject: [qubes-users] Re: What do you think about Grsecurity future ?
> Local Time: July 5, 2017 6:05 PM
> UTC Time: July 5, 2017 5:05 PM
> From: turboa...@gmail.com
> To: qubes-users 
> turboa...@gmail.com
> End of official PaX and grsecurity support in Arch Linux
> https://lists.archlinux.org/pipermail/arch-general/2017-April/043604.html

It's a great pity, especially as the coldkernel guys were just starting to get 
going with something us Qubes users could deploy.
I don't know any of the personalities involved to speak to the wider issues of 
whether the decision to pull public patches is justified or not, but personally 
if it's a big enough FU to large corporate rip off merchants of original work 
and causes them enough problems perhaps it's worth the aggravation to us mere 
mortals. If it's just about money and whose balls swing the longest...well meh. 
For some reason (given I don't use his OS or know him) I trust the word of the 
copperhead guy.
I'm unsure of the impact (if any) on what benefits could have been bought to 
dom0 had the decision not been taken, but in VM terms, where we rely on qubes 
provided kernel or distro via pvgrub2 I guess it's business as usual. As I'm 
using 'their' OS, if ITL didn't deign to include something, I'm generally happy 
with that decision.
Once action I have taken is to enable tasket's root action prompt [1] for my 
disposable VM template as a bit of 'hardening' there, although I can see Joanna 
spitting in my eye from here for supporting that action ;) In my view there is 
some utility in knowing if something opened in a dispvm is trying to escalate 
to root...
[[1] 
https://www.qubes-os.org/doc/vm-sudo/](https://www.qubes-os.org/doc/vm-sudo/)

-- 
You received this message because you are subscribed to the Google Groups 
"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/GhqN2g6YfjQkDuDFqUSRhvKaZWvLMhoCZGxiIvfoB0PPETuAjlqwYEFerys7E_ay8QxKPwnP5nmvWQUxptjCHoVRX0kUWZe928bhHqC1HX8%3D%40protonmail.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Setting up regular bitcoin donation / buying support case?

['Vincent Adultman' via qubes-users]

Hi all

Over on https://www.qubes-os.org/donate/ I see I can setup a donation one of 
two ways, Bitcoin and via Open Collective, however 14% for the latter seems a 
hell of a donation overhead. As such, I'd like to use Bitcoin but have no idea 
how. While I realise there are probably many idiots guides, I wonder if this is 
a common feeling of people that visit the donate page.

I'm happy to muddle through setting up a recurring bitcoin donation and then 
contribute a guide (I currently have nothing else for which I would use 
bitcoin) if this would be helpful, but also wonder if someone has some notes 
stuffed away in a gist or similar somewhere?

On a related point, I've not been keeping up on all the ways you guys are 
seeking funding, but I believe selling individual support licenses for those 
who wished to purchase them was decided to be not worth the revenue it would 
generate vs effort, is this still the case? I use Qubes as my daily driver and 
cannot get any of the 4.x series kernels to work on my laptop, so am behind on 
this element of security updates. I take it I can't purchase a support case 
from ITL at the current point in time?

Vin

-- 
You received this message because you are subscribed to the Google Groups 
"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/IqQb7fAEm5pfJp6bH03u69tcB0h4H3WgPzc0rqa11yXLOzNrHe0-NMtF91XGpGPqlcEmPTVq0jP5ixSuOd4atb9wfWV9mo5_kq_u1JX0gZs%3D%40protonmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] HCL Elitebook 2540p / Complete inability to use any Qubes 3.2 4.x series kernel

['Vincent Adultman' via qubes-users]

The only kernel that still functions is the leftover 3.8.17-8 from 3.1. Which 
is working fine for now, are there any downsides to continuing to use this?

Going by today's security bulletin[1], which releases a new kernel - it seems 
that there may well be downsides.

I wonder how best to proceed, I take it no one else is in this situation?

[1] https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-031-2017.txt

-- 
You received this message because you are subscribed to the Google Groups 
"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/k7uot33w6f6GO4e0hQuvWsz0ntO7Cd-U-gN-2JoQfLCpCpJcaP5ZTe03G63DWs9W9XbqzbBF8lBEQBM8Xwhp5IZWzTzXgueqcaJ5Itg-44E%3D%40protonmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Xen high CPU usage, but nothing is running in the VM

['Vincent Adultman' via qubes-users]

This happens to me sometimes on the current Xen/Linux versions. When I
look at top in the offending VM its "kswapd" that has gone berserk.

--

Chris Laprise, tas...@openmailbox.org
https://twitter.com/ttaskett
PGP: BEE2 20C5 356E 764A 73EB 4AB3 1DC4 D106 F07F 1886

--
I can confirm I've also experienced this with kswapd in either sys-net or 
sys-firewall, can't remember which. Only way around it I found was to reboot 
the VM.

-- 
You received this message because you are subscribed to the Google Groups 
"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/iN97IVQYSzHL2rj-89YTu_69EELdKrifa-PH33Mz3dMgvfxsk6BXhyBqLXVDUPHLzdhbgTJZCJXuVmU91J7wVRVeIAfkg2wg2FrjSFIzq2Y%3D%40protonmail.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] HCL Elitebook 2540p / Complete inability to use any Qubes 3.2 4.x series kernel

['Vincent Adultman' via qubes-users]

Hi all
Having upgraded to 3.2 it's basically as I assumed, no 4.x series kernel will 
boot on my laptop, the graphics on the Qubes boot screen are completely 
corrupted and some of the kernels reboot a second or so after the Qubes boot 
screen appears.

The only kernel that still functions is the leftover 3.8.17-8 from 3.1. Which 
is working fine for now, are there any downsides to continuing to use this?

I suppose I need to mark it as protected so I can try new kernels as they are 
released, but ensure it is not removed...

-- 
You received this message because you are subscribed to the Google Groups 
"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/iXqIIJtYyO82Qg_QBP0VB2P3_AwbTXWo84VJ7rJKr7A90xePuqIxlO7Mbb2bmpuQu-LbTUYfZcgppHKz5ScrdjTIsZvIqhwCdKn9fNPaDT4%3D%40protonmail.com.
For more options, visit https://groups.google.com/d/optout.


Qubes-HCL-Hewlett_Packard-HP_EliteBook_2540p-20170618-130131.yml
Description: application/yaml

[qubes-users] 3.1 - 3.2 upgrade no qubes-upgrade-vm package available?

['Vincent Adultman' via qubes-users]

Hi all
Following the upgrade instructions from 3.1 to 3.2, in the upgrade Fedora 
templates section the text talks about installing the qubes-upgrade-vm package, 
however this is not available in my Fedora 24 templates, is the section Fedora 
23 specific?

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/nyw5cDYguU-AMFyrgWBXyJhQxJ_BedNlAP3QvP6uxPskJ3rsJG8ud-F35YvipVfyCDb_TyNih8Z-LZtDmjPq7mNdLL8pNwOvf1iAtLw4V9k%3D%40protonmail.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Kernel issues preparing for 3.1 - 3.2 Upgrade

['Vincent Adultman' via qubes-users]

I've always had difficulties booting the default kernel of 3.1 (4.1.24.10), 
graphic corruption making it impossible to complete a boot. As such I've just 
always used 3.18.17-8 which behaves fine on my hardware.

Am now preparing to make the upgrade to 3.2, but want to ensure if at all 
possible there is a kernel that will boot before I do. Is it possible / logical 
to test the same kernel version that will be available / default with 3.2 on 
3.1 or is it much more a suck-it-and-see if it sucks sort of situation?

Had some time to get back to looking at this. The issue is the same with any of 
the 4.x kernels in 3.1's unstable repo. Having tried various i915 kernel 
parameters without luck the only one that has an effect is plain old 
"nomodeset", which initially goes okay but then won't get as far as the login 
screen "failed to start graphics turbo". I don't think the driver actually 
works without kernel mode setting?

Having read around a bit, I'm wondering if this is a consequence of the driver 
switching to SNA rather than UXA in Kernels 4 and up, however I don't see any 
way to set this as a kernel parameter, only in an X config file, but the issue 
here is not being able to get as far as the login screen.

The only other thing that occurs, is that perhaps the 4 kernel will behave 
better with 3.2 having a more recent version of xorg-x11-drv-intel than 3.1 - 
I've really no idea how this package and the driver in the kernel interact...

I'm going to have to just perform my backup and try the upgrade to 3.2, but not 
exactly enthused as to chances of success

-- 
You received this message because you are subscribed to the Google Groups 
"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/uanJmjjzgERCUQ13Ke5rM7ivw-XtquEu1g-gGlEZBxtTUvw5VGZ7GI_pT_Xk1kb2guHdzuuJqmQmqG2mr-zwzVJsBjW3mJKBQuuzyli5UH8%3D%40protonmail.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Kernel issues preparing for 3.1 - 3.2 Upgrade

['Vincent Adultman' via qubes-users]

I've always had difficulties booting the default kernel of 3.1 (4.1.24.10), 
graphic corruption making it impossible to complete a boot. As such I've just 
always used 3.18.17-8 which behaves fine on my hardware.

Am now preparing to make the upgrade to 3.2, but want to ensure if at all 
possible there is a kernel that will boot before I do. Is it possible / logical 
to test the same kernel version that will be available / default with 3.2 on 
3.1 or is it much more a suck-it-and-see if it sucks sort of situation?

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/YJHiVcbFY3HLWGABu3YVLyZz-I_lF6Cgyzfh-1lfFSKA85vKz6Bovt_cxT0nn1pdUY0Tonm4Bj6tSNQJsJ5T-yQGKcwNB2PChBUqL33pEaQ%3D%40protonmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Q3.1 fedora-24-minimal template - dom0 update problem

['Vincent Adultman' via qubes-users]

Oh. Or install yum in fedora24 template. Nvm then.

-- 
You received this message because you are subscribed to the Google Groups 
"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/itNy01G7fEK-bIChUc1ucqh0H3niON9JFO_3o4BiuVGmGyrhF4aNRiUe5P_Y1EvATAix_6tujs8KZ8KNOHJzvm-0UMPTY4TudzAaCub8jsQ%3D%40protonmail.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Q3.1 fedora-24-minimal template - dom0 update problem

['Vincent Adultman' via qubes-users]

Hi all

Having installed the necessary packages (at least per website doc) and assigned 
fedora-24-minimal to sys-firewall dom0 complains on update that yum / 
yumdownloader command cannot be found on the sys-firewall (which I guess is 
correct on fedora-24?).

I guess Yum= should be dnf in qubes-download-dom0-updates.sh? Not really looked 
at how this works before

Thanks in advance

-- 
You received this message because you are subscribed to the Google Groups 
"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/z5f70DMyvO_7iiOGyRbeZsc2MnWwVN9pwGP4in7V78oPzEJDiTX4rKwW27od6SAIUQoMQDO_TPdgupjh7D8kJmHLaEBZ2xeI070f-i5lEGo%3D%40protonmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] GUI Daemon error with new fedora-24-minimal template

['Vincent Adultman' via qubes-users]

It looks like template uploaded to 3.1 repository was built for Qubes
3.2, so this is why it's incompatible. I've just removed this faulty
template, building new one - will be ready in few hours.

- --
Best Regards,
Marek Marczykowski-Górecki
Invisible Things Lab
A: Because it messes up the order in which people normally read text.
Q: Why is top-posting such a bad thing?

Whoops. Thanks Marek. Will uninstall it and wait a bit then. Seems like I'm an 
oddball still using 3.1 and fedora-minimal if I'm the first to run into it!

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

[qubes-users] GUI Daemon error with new fedora-24-minimal template

['Vincent Adultman' via qubes-users]

Hi all

Qubes 3.1

Have downloaded the new qubes-template- fedora-24-minimal however on starting 
it the following message is received

"Dom0 GUI daemon do not support protocol version 1:1 requested by VM. To update 
Dom0..." etc

Does the template require a version of gui currently only in testing repo? I'd 
have imagined yum would have warned me if so.

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/tgKwqYg1wmJsRQSeLyp7WSou_LhTLLCcyRCbzx_zQGOhmXa1-IDBAVKiKZeL8Ub4vAYgAdR5hQSXvzkpDnd8x1hUELQrFu8Brn-QrjD36mc%3D%40protonmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] 3.0 to 3.1 in place upgrade broke USB VMs

['Vincent Adultman' via qubes-users]

Sounds like it could have been introduced in R3.1 Xen 4.6 for you
specifically due to your hardware. If that's the case, it wouldn't
be a good idea to note this on the page, since it might not apply
to others.

- --
Andrew David Wong (Axon)
Community Manager, Qubes OS
https://www.qubes-os.org


Thanks Andrew. That's interesting, I'd assumed it was a binary proposition 
introduced in 4.6 having only briefly scanned 
http://www.gossamer-threads.com/lists/xen/devel/391684

If not I take your point however I still feel it should be referenced in some 
way on the upgrade instructions page to stop others potentially wasting the 
same time I did, and subsequently the lists time IF they run into it.

If the issue does not apply to users hardware, user will simply have no problem 
with their existing device to VM assignments and proposed note is ignored. 
Without a note, if it does apply to their hardware they may (stupidly) like me 
read the existing FAQ entry and assume pci strictreset is not the problem as 
otherwise problem would have begun in R3.0...

So perhaps it's the FAQ entry that needs clarifying? From a naive point of 
view, it makes sense that USB controllers might share some resources but on 
what appears to be "sensible" hardware that has one controller for USB ports 
and another for webcam etc it came as more of a surprise.

Best

Vince

-- 
You received this message because you are subscribed to the Google Groups 
"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/W8EuHoowg8R0Mwna-xD0ZCop6Gz13WQMeHgP4eRJZmtJX7MJ7Nku2QqQhVUS32M30M426roQuxLZhuhvdIk9vjf-tNH9uSPbNnw9phZOhVk%3D%40protonmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] 3.0 to 3.1 in place upgrade broke USB VMs

['Vincent Adultman' via qubes-users]

Apologies, this appears to be the shared RMRR problem discussed in
https://github.com/QubesOS/qubes-issues/issues/1544

This is indeed in the FAQ, but I was thrown by the doc at
https://www.qubes-os.org/doc/user-faq/#i-created-a-usbvm-and-assigned-usb-controllers-to-it-now-the-usbvm-wont-boot

stating the problem began in R3.0, when by this experience it actually seems to 
have been introduced in R3.1 xen 4.6?. Pity as it was nice having USB ports and 
built-in USB devices in separate VMs. Although I guess it's for the best, as I 
was relying on the reset ability which apparently wasn't supported by the 
hardware...

In any case, worth a note on https://www.qubes-os.org/doc/upgrade-to-r3.1/ page?

-- 
You received this message because you are subscribed to the Google Groups 
"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/UCo8aCugrJ2Dvbz2F9jSSsiPucHhdcY18TL_xnx9eWRDFfK-Mb-SDofD9P2WmC5KMhmyHTqEydjeEiZoF0PgUc5QrFDjCjYCkgr8m_Ie3kA%3D%40protonmail.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] 3.0 to 3.1 in place upgrade broke USB VMs

['Vincent Adultman' via qubes-users]

The in place upgrade from 3.0 to 3.1 broke my two USB VMs (one controller with 
ports, one controller with devices) which were both set to auto start and 
working on 3.0.

The error is similar to that where devices are assigned to another running VM - 
this is not the case however.

livirt.libvirtError: Requested operation is not valid: PCI device xyz is in use 
by driver xenlight, domain usbvm

sys-net still auto starts and everything else seems to work. Both VMs start 
fine without the USB devices assigned.

I've tried hiding the devices from dom0 in case this made any difference using 
the kernel line in the docs, but this has made no difference.

TIA

-- 
You received this message because you are subscribed to the Google Groups 
"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/ULyzjiM2Df5aepri0VxtxWHI2MoeVyJaqxvwKW3hJdBdKlHVpn5jeDbtZmsk0G69lRRdp-9vAoVpIID2ska-Pgn_pJ8DvJ0BzmrTV3I45sw%3D%40protonmail.com.
For more options, visit https://groups.google.com/d/optout.