Re: [qubes-users] can't download qubes 4.0 how to raise 4.3gb download limit.

2018-03-21 Thread Yuraeitha
On Wednesday, March 21, 2018 at 3:14:33 AM UTC, cooloutac wrote:
> On Tuesday, March 20, 2018 at 11:10:52 AM UTC-4, Unman wrote:
> > On Mon, Mar 19, 2018 at 05:00:05PM -0700, cooloutac wrote:
> > > Can't download qubes 4.0 not enough space.  tried to raise system storage 
> > > size on template through qubes manager.  messag said I might have use 
> > > resize2f.   tried that didn't do antyhing.   Tried to use qvm-grow-root  
> > > it staid to start template to complete process but it also didn't change.
> > > 
> > >in vm settings it shows the size I specified,  but when running 
> > > nautlius and looking at the space or doing df -h it is still only 4.3gb 
> > > out of 10.5 available.
> > >   I've never downloaded a file this large in qubes so never ran into this 
> > > problem. Only thing I ever had to increase was private storage.  I have 
> > > this issue with all templates.
> > >  
> > > Qubes 3.2 iso must be under the limit so I was able to download that iso 
> > > but can't donload 4.0 it is too large and fails to download.
> > > 
> > > 
> > > Is there any detailed step by step instructions because I'm obviously 
> > > doing something wrong?
> > > 
> > > Ty for the help.
> > > 
> > > Rich.
> > > 
> > 
> > Rich,  can you confirm you're using 3.2?
> > 
> > How are you downloading the iso?
> > Are you doing this as root or user?
> > Where are you trying to download it to?
> > 
> > As you have enough space in /home my guess is that you are using /tmp
> > or /dev/shm 
> > If you run df in the qube you're using WHILE the download is running,
> > you should see the free space moving down as the download progresses.
> > Can you check this and report back?
> 
> Yes i'm definitely using 3.2.  
> 
>   it starts off as 4.3 or 4.7 available I believe available out of 10.5gb.  
> no matter what I set private storage to. its the system storage.I 
> remember marek showing how to increase the temp file storage size when having 
> a diff issue a few qubes versions ago,  when I use to have the issue of 
> playing long video streams cutting off using fedora.  I forget how maybe 
> similar issue here? But it doesn't matter which appvm or template I use. 
> 
> and yes i can see the available space slowly doing down as downloading. using 
> df-h or just watching in file manager.
> 
> I'm trying to download the iso from any vm,  using any template.  loading 
> firefox or google chrome and clicking on the iso.  they all have the same 
> problem.   I'd really have ot hate to use some other operating system just to 
> download 4.0,  almost seems like a joke on qubes users, that the extra  
> 100mb's puts me over the top and it fails to download lol.
> 
> I mean I do have media qubes with 100s of gbs of data in there.  But they 
> were copied to vms from usb devices and I did have to increase private 
> storage size.  this seems to be a diff issue.

You must be concise in describing what you're trying to do. Are you refuting 
the normal method to increase the AppVM's size, in favor for some old method 
from several Qubes versions back? 

I apologize for the rude question, but at this point it needs to be asked. Is 
this an attempt to try preserve old habits instead of trying to build new 
habits? Are you getting stuck in old ways of doing things, which may no longer 
be supported/working?

-- 
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/f442dd09-efcb-4ff3-b744-78e7da5ac158%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: Cannot start apps using template based on Debian Testing

2018-03-20 Thread Yuraeitha
On Tuesday, March 20, 2018 at 3:13:13 PM UTC+1, Fernando wrote:
> On Tuesday, March 20, 2018 at 11:00:55 AM UTC-3, Yuraeitha wrote:
> > On Tuesday, March 20, 2018 at 2:43:49 PM UTC+1, Fernando wrote:
> > > This is more of a warning for those using Debian Testing. I updated my 
> > > Debian Testing template this morning and I couldn't start any app since. 
> > > I am using Qubes 3.2.
> > > 
> > > Using qvm-run does not report any errors, not sure if I should check any 
> > > specific logs.
> > > 
> > > As a workaround I'm using another template with Debian 9.
> > > 
> > > Regards,
> > > 
> > > Fernando.
> > 
> > If I read this right, Debian 8 fails, but Debian 9 doesn't?
> > It might also be a good idea to switch to Debian 9 anyhow, we're getting 
> > closer and closer to end-of-life for Debian 8, which is the 6th of June, 
> > 2018 https://wiki.debian.org/DebianReleases
> > 
> > Also which updates was it? Were they of Debian origin? Qubes origin?
> 
> I don't have Debian 8 installed. Debian Testing is ahead of Debian 9.
> 
> I cannot tell exactly which update it was since I updated both qubes and the 
> different templates. Since Debian 9 is working normally, I assume this 
> happens due to a recent update to Debian Testing.
> 
> Also, this only seems to affect graphic apps (terminal, emacs, etc). My 
> split-gpg backend domain still works with Debian Testing.
> 
> If someone wants me to perform additional testing to assist debugging just 
> let me know.

aha, I see. I can't test this my self as I'm on Qubes 4, and this update I 
either already installed, or it's not arriving for Qubes 4, right now I have no 
pending current-resting updates for Debian 9.

Can you do an update on debian-9 without accepting the updates, and then 
copy-paste it here? If you feel uncomfortable with that, you can also make a 
clone of it before doing it, though it shouldn't be needed as long as you 
decline the updates. 

The developers can probably debug this without having us do this, but it might 
cut the work burden for them if we can identity the specific package causing 
the problem.

Be careful you don't hit y instead of t in the command below though, they're 
right next to each others on the keyboard, and it'd be fatal if it 
auto-installs those current-testing. So double-check before you hit enter, or 
copy/paste it over.



Step1:
user@debian-9:~$ sudo apt-get update -t *-testing && sudo apt-get dist-upgrade 
-t *-testing

Step2: 
Decline the updates, don't accept them.

Step3:
copy-paste the print-out of the downloadable content to your post here.

Step4: To clean up any potential leftovers from testing, although it's mostly 
only needed on fedora, but for good measures sake.
user@debian-9:~$ sudo apt-get clean


It's a bit of a problem that you upgraded dom0 though, since it's now no longer 
in sync with your other templates. I assume the only one not in sync is your 
debian-9 template though? It might be a good idea to keep track of which domU 
template isn't in sync with dom0 anymore, so you can correct it if you 
experience new future problems.

-- 
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/9e5be0be-93a6-44b6-bf86-88f245dcf224%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: HP Folio 1040 i7

2018-03-20 Thread Yuraeitha
On Tuesday, March 20, 2018 at 10:00:27 AM UTC+1, Linus Stridbeck wrote:
> hi, I just wanted to take the opportunity to see if some one used qubes on HP 
> Folio 1040 i7? its a elitebook essentielly but its noton the compatibility 
> list.

Many report their laptop to the HCL list, so it might not be likely to find 
anyone having it here if it's not on the HCL list, especially not on a short 
notice. 

Perhaps the better question to ask if others think it's a good idea to go for 
this laptop, for Qubes use-cases. As such you can post your use-case needs, 
your security needs (do you have reasons to put in extra hard security 
efforts?), as well as mentioning which generation of HP Folio 1040 i7 you're 
talking about, as far as I can see there are gen1, gen2, and gen3. Which specs 
variant are you looking at as well? One has more RAM than the other, etc. 

Even the cheapest model of the HP Folio 1040 i7 series, found on amazon.uk.co 
seems to go at roughly 700 pounds. That's super expensive for the poor 
performance this machine gives. Nevermind security concerns in hardware, it's a 
redicouless price to pay for this sloppy performance. So it's a good thing you 
asked before buying it.

gen 1 CPU benchmark
https://www.cpubenchmark.net/cpu.php?cpu=Intel+Core+i7-4650U+%40+1.70GHz=1955

gen 2 CPU benchmark
https://www.cpubenchmark.net/cpu.php?cpu=Intel+Core+i7-5600U+%40+2.60GHz=2456

In comparison, but not nessicarily a buying recommendation (This is purely to 
show you the difference).
https://www.amazon.co.uk/HP-15-bq150na-15-6-inch-Touchscreen-Resolution/dp/B07BBLZ5WR/ref=sr_1_fkmr0_1?ie=UTF8=152193=8-1-fkmr0=360+x+envy+ryzen

and it's CPU benchmarks 
https://www.cpubenchmark.net/cpu.php?cpu=AMD+Ryzen+5+2500U=3123

This is a ryzen apu though, it's still mostly untested with kernel and Qubes, 
but you can find intel equivalents in performance/price ratio as they are 
competing. Some Ryzen works with kernel/Qubes, but i.e. the desktop motherboard 
AB350 Pro4 with Ryzen 3 1200 can run Qubes, but it's not perfect. I do not have 
any Ryzen experience beyond that model, so I won't recommend it either, 
especially not when Ryzen mobile is so new as it is now. In general though, 
this is not a buying recommendation, but to shake you up a bit when comparing 
performance/price ratios.

What Intel bets a lot on is to cheat the customers who don't know where to 
look, essentially making people buy more for less, by heavily segmenting the 
market, confusing people as to what is better value and what is crap value. 
Thereby overall more people buy less value for more money, and Intel isn't 
doing anything illegal, and if customers don't realize, then they can live 
happy ever after, that much richer profiting on people's lack of knowledge on 
computer hardware.

Also considering you're up there in the price range already, you might want to 
look for a laptop which either has 16GB+ RAM pre-installed, or allows for 16GB+ 
RAM in the future (i.e. check if its upgrade-able). Running Qubes on 8GB can 
work just fine, but 16GB really does make a difference in comfort, so you don't 
need to shut down other VM's as much to make space for other VM's to run.

-- 
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/25c00391-4874-42ee-ad7f-ee4c740af61d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: Cannot start apps using template based on Debian Testing

2018-03-20 Thread Yuraeitha
On Tuesday, March 20, 2018 at 2:43:49 PM UTC+1, Fernando wrote:
> This is more of a warning for those using Debian Testing. I updated my Debian 
> Testing template this morning and I couldn't start any app since. I am using 
> Qubes 3.2.
> 
> Using qvm-run does not report any errors, not sure if I should check any 
> specific logs.
> 
> As a workaround I'm using another template with Debian 9.
> 
> Regards,
> 
> Fernando.

If I read this right, Debian 8 fails, but Debian 9 doesn't?
It might also be a good idea to switch to Debian 9 anyhow, we're getting closer 
and closer to end-of-life for Debian 8, which is the 6th of June, 2018 
https://wiki.debian.org/DebianReleases

Also which updates was it? Were they of Debian origin? Qubes origin?

-- 
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/125c6b41-bca7-43d4-bd13-3f8d19f39729%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: can't download qubes 4.0 how to raise 4.3gb download limit.

2018-03-20 Thread Yuraeitha
On Tuesday, March 20, 2018 at 1:00:06 AM UTC+1, cooloutac wrote:
> Can't download qubes 4.0 not enough space.  tried to raise system storage 
> size on template through qubes manager.  messag said I might have use 
> resize2f.   tried that didn't do antyhing.   Tried to use qvm-grow-root  it 
> staid to start template to complete process but it also didn't change.
> 
>in vm settings it shows the size I specified,  but when running nautlius 
> and looking at the space or doing df -h it is still only 4.3gb out of 10.5 
> available.
>   I've never downloaded a file this large in qubes so never ran into this 
> problem. Only thing I ever had to increase was private storage.  I have this 
> issue with all templates.
>  
> Qubes 3.2 iso must be under the limit so I was able to download that iso but 
> can't donload 4.0 it is too large and fails to download.
> 
> 
> Is there any detailed step by step instructions because I'm obviously doing 
> something wrong?
> 
> Ty for the help.
> 
> Rich.

It should work just fine in Qubes 4 from the GUI VM-Settings, so it shouldn't 
mean you need to do anything overly complicated. However, as memory serves, 
back in Qubes 3.2. you could resize VM's while the VM was running. This is no 
longer the case in Qubes 4 where you need to shut it down first before you can 
change it. Just in case this might be a factor, remember to shut it down first.

-- 
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/3bcf6e9c-0d35-48bf-af57-5039cf67ca63%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: Booting from two separate hard drives?

2018-03-20 Thread Yuraeitha
On Tuesday, March 20, 2018 at 10:11:29 AM UTC+1, Linus Stridbeck wrote:
> Obviously you seem understand the technical aspects.
> 
> So conclusively its less secure to boot from different hard drives compared 
> to switching manualy becous the first option could alow some one to get in to 
> bios not only firmware?
> 
> Its amzing to me that its even possible to get in the firmware! Ones in the 
> firmware youre basicly one step from the hardrive right? Is it easier to get 
> in the firmware whern using Windows than when using qubes? 
> 
> Besides when in the firmware you per se have to IP address right?

The BIOS/UEFI is also firmware btw, so in the future you read security articles 
and firmware is mentioned, it might indirectly include mention of BIOS/UEFI as 
well. The same goes to any other firmware, drives like 
HHD's/SSD's/HVMe's/thumb-drive's all have firmware too, and so does USB, and 
many other pieces of hardware. Qubes OS founder Joanna is advocating for 
stateless hardware, essentially hardware without firmware, where the software 
fully controls the hardware. This allows for machines to be wiped clean and 
install fully secure software on it again, or to reset if you suspect you got 
infected. Unfortunately right now market forces, politics, society habits, as 
well as competition and costs, all make it unlikely for anyone to start 
creating stateless hardware. It'd require a big push, or for a significant 
producer to start doing it, politics demanding it via law, or something like 
that.

Also note if you for example link your drives directly into an AppVM for 
example via qvm-block or qvm-usb, as far as I understand it, you're essentially 
exposing the firmware of the drives/thumb-drives, and thereby new firmware 
threats can reach this firmware, even if you're using Qubes. This is something 
the developers warned us about and are working on solving. But it goes to show 
that you're not fully safe, not yet, though using Qubes OS gets you far into 
the right direction at least, and it's a direction that is rapidly improving 
further.

And as you might suspect now, your question if it's easier to access firmware 
from windows, is essentially a big yes, your firmware is completely exposed in 
any operation-system running directly on the hardware. That's the strength of 
virtual environments, you can keep it out of reach of the hardware's firmware. 
Unfortunately virtual technology isn't perfect yet, it's still under 
development and improvements. But the protection Qubes provides, is far 
superior than the non-existing protection i.e. Windows provides.

Dual booting has two major issues that are solved by not dual booting 
- Easier to cause new infection of firmware from a less secure Operation System.
- Attacks carried out on the secure OS from the non-secure OS.

I believe those two can carry all the exploit methods meta-headlines, beneath 
them it gets much more complicated, but essentially it can be narrowed down to 
those two headlines in a broad sense.

-- 
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/96f7b2ce-9636-4a13-9648-ff6eaa8da99b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: migrating R3.1 appvm to R4.0 manually

2018-03-19 Thread Yuraeitha
On Monday, March 19, 2018 at 8:10:58 PM UTC+1, awokd wrote:
> On Mon, March 19, 2018 7:04 pm, Yuraeitha wrote:
> > On Monday, March 19, 2018 at 7:45:30 PM UTC+1, Jake wrote:
> >
> >> Hello list,
> >>
> >>
> >> i need to migrate a R3.1 appvm to R4.0 manually.  due to this appvm
> >> having overfilled the hard drive of a R3.1 installation, i had to
> >> migrate the contents of /var/lib/qubes/appvm/ to another
> >> drive.  i have verified {private,volatile}.img were copied without
> >> error, but i cannot get the appvm to show up under a new R4.0
> >> installation with these files manually copied to
> >> /var/lib/qubes/appvm/, in dom0.
> >>
> >>
> >> can someone give me input on what i need to do to get this appvm to
> >> register/start on R4.0? i am confident there is a way to do this, but i
> >>  do not know what is required.
> >>
> >> regards,
> >>
> >> jake
> >
> 
> > You can also move all your AppVM content from old AppVM to a new fresh
> > AppVM, and then hash-check your files integrity in Qubes 3.1. (if you can
> > still do that) and the files in your new AppVM. At least, then there will
> > be no remains left from the old 3.1. AppVM. It might be "over-protective"
> > to go that far though, this is my lack of knowledge speaking to taking
> > extra safety measures.
> 
> I think a variation of this will be the most straight-forward way to do
> it, since 4.0 uses LVM instead of those .img files.
> 
> 1. Create temp VM, copy .img files inside and mount them.
> 2. Create perm VM
> 3. qvm-copy files from temp to perm
> 4. Delete temp VM

That's a good idea, that removes the uncertainty part of it all when directly 
accessing the img files manually.

-- 
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/49f6606a-b3ec-4f07-9f79-8fd3da7bbdbe%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: Booting from two separate hard drives?

2018-03-19 Thread Yuraeitha
On Monday, March 19, 2018 at 8:23:50 PM UTC+1, Linus Stridbeck wrote:
> ok, that's interesting. so whats the difference between between booting like 
> i proposed and simply manually taking out the windows harddrive and putting 
> in a hardrive with qubes on it?

This would protect you from current and future attacks like the ones mentioned, 
but it will not protect you from existing infected firmware if it has already 
exploited/attacked, essentially it's like ghosts living in your firmware, it'll 
keep coming back. The question is if your hardware's firmware got 
exploited/attacked in the past or not. You're not totally safe, but on the 
other hand you would be more safe than before.

The question is also if you want to go this far though, Qubes is not fully 
developed yet to completely isolate the hardware. For example firmware of 
drives may get exposed in the current Qubes. Qubes OS has gotten far, but as 
the developers say themselves, it still got some areas to fix, which will be 
done in the future versions of Qubes OS. 

Essentially, you may want to question if you want to take extreme measures, 
whether it's worth it not, considering currently many firmware attacks may 
still be exotic (but may not stay that way), and that Qubes isn't fully 
isolated from the hardware today, so you'll still be exposed to damaging 
firmware's anyway, at least for some time to come.

-- 
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/b814195e-071f-40fe-a1e8-234ca11771ae%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: migrating R3.1 appvm to R4.0 manually

2018-03-19 Thread Yuraeitha
On Monday, March 19, 2018 at 7:45:30 PM UTC+1, Jake wrote:
> Hello list,
> 
> i need to migrate a R3.1 appvm to R4.0 manually.  due to this appvm 
> having overfilled the hard drive of a R3.1 installation, i had to 
> migrate the contents of /var/lib/qubes/appvm/ to another 
> drive.  i have verified {private,volatile}.img were copied without 
> error, but i cannot get the appvm to show up under a new R4.0 
> installation with these files manually copied to 
> /var/lib/qubes/appvm/, in dom0.
> 
> can someone give me input on what i need to do to get this appvm to 
> register/start on R4.0? i am confident there is a way to do this, but i 
> do not know what is required.
> 
> regards,
> 
> jake

I do by no means know if this is safe, but I do believe it should work.
Essentially try create a VM in the same name as your old VM, then shut it down. 
Go into your /var/lib/qubes/appvm/ and then manually replace the 
data. Then try start the AppVM, and see if it works. 

I don't believe it can hurt to try though, what I wonder about is whether it 
can cause data corruption, but it might just be me being too careful. You may 
want to keep that 3.1. AppVM data as a backup if you ever encounter 
data-corruption.

You can also move all your AppVM content from old AppVM to a new fresh AppVM, 
and then hash-check your files integrity in Qubes 3.1. (if you can still do 
that) and the files in your new AppVM. At least, then there will be no remains 
left from the old 3.1. AppVM. It might be "over-protective" to go that far 
though, this is my lack of knowledge speaking to taking extra safety measures.

-- 
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/75d53604-3615-4285-8e27-a4250794882a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: Booting from two separate hard drives?

2018-03-19 Thread Yuraeitha
On Monday, March 19, 2018 at 5:59:40 PM UTC+1, Linus Stridbeck wrote:
> Hi, I have the opportunity to by a computer (HP EliteBook) that have space 
> for two hardrives one SSD and one Sata M.2 SSD 2242. 
> 
> I would like to run Windows on the SSD and Qubes on the Sata M.2 SSD 2242 
> 
> From what I have read it is possible all it takes is some modifications in 
> bios.
>  
> But is it advisable from a security point of viwe? I know its a bad ider to 
> boot from one singel hardrive but in this case i guese the Windows hard drive 
> is completely disconnected when runing qubes on the Sata drive?

Another idea is to use BIOS/Grub, instead of UEFI/EFI, put the parts of Grub 
that is un-encrypted on an CD/DVD/Bluray, and use your disk to boot up Qubes. 
This way it cannot be modified.

Your BIOS/firmware is still exploitable though, but at the very least you're 
less exposed.

-- 
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/c3d5f5bd-cdbe-4c57-8ef2-8cb40efa5a58%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: Booting from two separate hard drives?

2018-03-19 Thread Yuraeitha
On Monday, March 19, 2018 at 5:59:40 PM UTC+1, Linus Stridbeck wrote:
> Hi, I have the opportunity to by a computer (HP EliteBook) that have space 
> for two hardrives one SSD and one Sata M.2 SSD 2242. 
> 
> I would like to run Windows on the SSD and Qubes on the Sata M.2 SSD 2242 
> 
> From what I have read it is possible all it takes is some modifications in 
> bios.
>  
> But is it advisable from a security point of viwe? I know its a bad ider to 
> boot from one singel hardrive but in this case i guese the Windows hard drive 
> is completely disconnected when runing qubes on the Sata drive?

It's certainly possible yes, I've done it multiple of times on different 
hardware, although I don't do it on my main hardware. Just be sure you know 
your way around UEFI/BIOS EFI/Grub.

- Firmware, while maybe exotic attacks? can be attacked, and thereby having 
anything unsecure installed on your system, from anytime in the past, to any 
time in the future, while using Qubes on it, is insecure. Once comprimised, 
it's not really something you can undo again by erasing disks or putting in new 
disks. Generally too, it's not certain when or how these kind of attacks are 
measured, so they may be more common than imagined, maybe years into the 
future? Especially when A.I.'s come around, but don't wait for A.I.'s to take 
this threat seriously, it may happen before then. 

- Qubes must also always stay encrypted, never access it from another unsecure 
operation system. 

- Password encryption must be at least strong enough so that your own cpu can't 
brute-force it. I don't think it can be brute-forced remotely though, but you 
never know.

Whether its advisable? I frankly don't know, I don't have the skills and 
expertise to tell you. But if you ask me, it can work, but it isn't something 
you should bet your own life on.

-- 
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/88cb41cd-f794-48b6-bd21-7477c512b673%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: Disk space--R4 lies through its teeth

2018-03-19 Thread Yuraeitha
On Monday, March 19, 2018 at 6:34:05 PM UTC+1, Bill Wether wrote:
> This has been mentioned before in 
> , but I don't 
> see anywhere that it's fixed.
> 
> In R3.2, df in Dom0 would show how much actual disk space remained.  That's a 
> critical piece of data for production use, given the sheer amount of breakage 
> caused by running out of space.
> 
> I have a 1TB SSD with Qubes 4.0 RC5 and about 450GB of restored VMs, but when 
> I type 'df' in dom0 I get:
> 
> Use% Mounted on
> devtmpfs  1995976   0   1995976   0% /dev
> tmpfs 2009828   0   2009828   0% /dev/shm
> tmpfs 20098281612   2008216   1% /run
> tmpfs 2009828   0   2009828   0% /sys/fs/cgroup
> /dev/mapper/qubes_dom0-root 935037724 3866076 883604596   1% /
> tmpfs 2009828   8   2009820   1% /tmp
> xenstore  2009828 416   2009412   1% 
> /var/lib/xenstored
> /dev/sda1  999320   79676850832   9% /boot
> tmpfs  401964   8401956   1% /run/user/1000
> 
> You'd never know that the disk is actually half full or a little more. I have 
> no idea how to manage my disk space on Qubes 4.0.
> 
> Suggestions?
> 
> Thanks
> 
> BillW

In addition to using "sudo lvs", I believe this too may also be relevant. 

quote: 
"In all versions of Qubes, you may want to set up a periodic job in dom0 to 
trim the disk. This can be done with either systemd (weekly only) or cron 
(daily or weekly)."
...
"Although discards can be issued on every delete inside dom0 by adding the 
discard mount option to /etc/fstab, this option can hurt performance so the 
above procedure is recommended instead. However, inside App and Template qubes, 
the discard mount option is on by default to notify the LVM thin pool driver 
(R4.0) or sparse file driver (R3.2) that the space is no longer needed and can 
be zeroed and re-used." 
https://www.qubes-os.org/doc/disk-trim/

In general, if your trimming is not working correctly, either in VM's or in 
dom0, then you may get wrong numbers, even if you use the correct commands to 
list your drive space usage.

The reason you get so much drive space usage reported, may very likely be 
because your trimming isn't working or isn't enabled.

-- 
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/e226a55f-1801-4c74-9288-9a1ce95e50b6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: Using postgresql database in qubes(AppVM)

2018-03-17 Thread Yuraeitha
On Saturday, March 17, 2018 at 6:24:34 AM UTC+1, Taehwan Kim wrote:
> Hello!
> As a web developer, I was using Arch linux as development os then I got to 
> know qubes os, and really hooked it.
> 
> I almost finished setting up my qubes os as Web development os. But I finally 
> found out 1 problem. that is database.
> 
> Postgresql database's data location is (normally) /var/lib/pgsql/10/data
> As I learned, AppVM's folder will be reset every time I start. (except /home)
> 
> So I am thinking about the solution, first, I just create every database that 
> need for my project in TemplateVM, so I can see it my Dev AppVM
> 
> Is there anyone using qubes os as web development os?
> Is there any best practice for this case?
> 
> Please help me!

or to make it even easier, by using the cups example inside the file, is to 
just put your data at /rw/config/data and then symbolic link it to 
/var/lib/pgsql/10/data

Then all your data is kept in /rw/config/data but the system believes its at 
/var/lib/pgsql/10/data

By using /rw/config as a place to store your folders, then it also becomes more 
easy to keep overview of everything, rather than clustering it all in folders 
in various different directions (keep it simple).

-- 
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/0eda79b5-a17a-43bb-999c-397cd6424f34%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: Using postgresql database in qubes(AppVM)

2018-03-17 Thread Yuraeitha
On Saturday, March 17, 2018 at 6:24:34 AM UTC+1, Taehwan Kim wrote:
> Hello!
> As a web developer, I was using Arch linux as development os then I got to 
> know qubes os, and really hooked it.
> 
> I almost finished setting up my qubes os as Web development os. But I finally 
> found out 1 problem. that is database.
> 
> Postgresql database's data location is (normally) /var/lib/pgsql/10/data
> As I learned, AppVM's folder will be reset every time I start. (except /home)
> 
> So I am thinking about the solution, first, I just create every database that 
> need for my project in TemplateVM, so I can see it my Dev AppVM
> 
> Is there anyone using qubes os as web development os?
> Is there any best practice for this case?
> 
> Please help me!

There is a 4th option to the 3 options above, which is changing the specific 
folder at /var/lib/pgsql/10/data and allow it to become persistent in in this 
location /rw. The /rw folder stays persistent, and it's also here you'll find 
everything else that is staying persistent in the AppVM's. 

Changing what stays persistent and what doesn't is actually quite easy to do 
too, but be aware it adds yet another folder which can be exploited to attacks, 
so if you can use the option 1) awokd mention up above, then it'll be more 
secure.

Basically how it works, is that it'll start the full template, then it'll 
remove the symbolic links to the specific folders you want to be persistent 
(that means, the default template folders are cut-away), and then it'll change 
the symbolic link to the persistent folder. Generally, I believe, this is how 
AppVM's work in general, however, you can modify it to include or exclude 
specific folders, as you desire.

Use a terminal text editor, like nano, and edit this file '/rw/config/rc.local'
Instructions how to do this is included in the Qubes file, it's using Cups as 
an example how to do it, just do the same for your specific folder instead of 
Cups.

Remember the systemctl restart is only needed if you're changing a service or 
module driver, it might not be relevant for your needs. So you only need the 
"rm" template folder line, and the "ln -s" add new symbolic link line to a 
replacement folder.

Remember your "/var/lib/pgsql/10/data" content, now will be inside a folder you 
placed somewhere suitable in the /rw folder, for example 
/rw/var/lib/pgsql/10/data, which then will act as if it was at the real 
destination.

-- 
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/8ce9e42d-a749-4d1e-a88f-ca28a752a9cf%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: mouse lagging with sys-usb in Qubes 3.2

2018-03-17 Thread Yuraeitha
On Saturday, March 17, 2018 at 8:14:02 PM UTC+1, snowbo...@gmail.com wrote:
> Since I created a sys-usb device and connected the mouse with passthrough to 
> dom0 (I answered yes the first time) the mouse is lagging significantly. I 
> even changed the attributes from mouse properties from the GUI menu but 
> nothing happens. It's a laptop so touchpad is working perfectly.
> 
> Why does it lag so much?
> 
> Output of qubes.InputMouse:
> 
> sys-usb dom0 allow,user=root
> $anyvm $anyvm deny

By any chance are you using current-testing repositories? and if so, did you 
update all your templates with current-testing repositories too? If only dom0 
is updated, or if not keeping the updates in sync between dom0/domU, then it 
might cause smaller issues, i.e. it might be possible to cause an issue like 
this one. 

It's not exclusive current-testing either, however it's more easy to make the 
update-sync mistake for current-testing updates. In general every Qubes update 
repository must stay in sync across the whole system.

-- 
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/ca1086a0-468e-41d7-a40f-17938df22b2c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


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

2018-03-16 Thread Yuraeitha
On Friday, March 16, 2018 at 3:34:05 PM UTC+1, Lorenzo Lamas wrote:
> After updating to Xen 4.6.6-37, with updated BIOS/microcode, I executed 
> Spectre & Meltdown 
> Checker(https://github.com/speed47/spectre-meltdown-checker) in a PV Fedora 
> 26 AppVM.(Kernel 4.14.18-1)
> 
> Hardware support is now supported:
> * Hardware support (CPU microcode) for mitigation techniques
>   * Indirect Branch Restricted Speculation (IBRS)
> * SPEC_CTRL MSR is available:  YES 
> * CPU indicates IBRS capability:  YES  (SPEC_CTRL feature bit)
>   * Indirect Branch Prediction Barrier (IBPB)
> * PRED_CMD MSR is available:  YES 
> * CPU indicates IBPB capability:  YES  (IBPB_SUPPORT feature bit)
>   * Single Thread Indirect Branch Predictors (STIBP)
> * SPEC_CTRL MSR is available:  YES 
> * CPU indicates STIBP capability:  YES 
> 
> However, the VM kernel does not seem to support the migitations: 
> 
> CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'
> * Mitigated according to the /sys interface:  NO  (kernel confirms your 
> system is vulnerable)
> * Mitigation 1
>   * Kernel is compiled with IBRS/IBPB support:  NO 
>   * Currently enabled features
> * IBRS enabled for Kernel space:  NO 
> * IBRS enabled for User space:  NO 
> * IBPB enabled:  NO 
> * Mitigation 2
>   * Kernel compiled with retpoline option:  YES 
>   * Kernel compiled with a retpoline-aware compiler:  NO  (kernel reports 
> minimal retpoline compilation)
> > STATUS:  VULNERABLE  (Vulnerable: Minimal generic ASM retpoline, IBPB)
> 
> 
> Does this mean the kernel compiled by Qubes does not support the migitations 
> yet, or that this test cannot get proper info from the kernel, since the 
> kernel is provided by Dom0 instead of the VM? Or are both true?

Important typo, I forgot to add 'in the future'.

"I believe, while not knowing, that the Qubes team might focus more on securing 
the VM's dirt (in above's analogy), but right now, it's all on the fence and 
cemented ground inside it." 

should be:

"I believe, while not knowing, that the Qubes team might in the future focus 
more on securing the VM's dirt (in above's analogy), but right now, it's all on 
the fence and cemented ground inside 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/b3e1adc9-5b04-4bf5-b87c-86ac0c28318e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


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

2018-03-16 Thread Yuraeitha
On Friday, March 16, 2018 at 3:34:05 PM UTC+1, Lorenzo Lamas wrote:
> After updating to Xen 4.6.6-37, with updated BIOS/microcode, I executed 
> Spectre & Meltdown 
> Checker(https://github.com/speed47/spectre-meltdown-checker) in a PV Fedora 
> 26 AppVM.(Kernel 4.14.18-1)
> 
> Hardware support is now supported:
> * Hardware support (CPU microcode) for mitigation techniques
>   * Indirect Branch Restricted Speculation (IBRS)
> * SPEC_CTRL MSR is available:  YES 
> * CPU indicates IBRS capability:  YES  (SPEC_CTRL feature bit)
>   * Indirect Branch Prediction Barrier (IBPB)
> * PRED_CMD MSR is available:  YES 
> * CPU indicates IBPB capability:  YES  (IBPB_SUPPORT feature bit)
>   * Single Thread Indirect Branch Predictors (STIBP)
> * SPEC_CTRL MSR is available:  YES 
> * CPU indicates STIBP capability:  YES 
> 
> However, the VM kernel does not seem to support the migitations: 
> 
> CVE-2017-5715 [branch target injection] aka 'Spectre Variant 2'
> * Mitigated according to the /sys interface:  NO  (kernel confirms your 
> system is vulnerable)
> * Mitigation 1
>   * Kernel is compiled with IBRS/IBPB support:  NO 
>   * Currently enabled features
> * IBRS enabled for Kernel space:  NO 
> * IBRS enabled for User space:  NO 
> * IBPB enabled:  NO 
> * Mitigation 2
>   * Kernel compiled with retpoline option:  YES 
>   * Kernel compiled with a retpoline-aware compiler:  NO  (kernel reports 
> minimal retpoline compilation)
> > STATUS:  VULNERABLE  (Vulnerable: Minimal generic ASM retpoline, IBPB)
> 
> 
> Does this mean the kernel compiled by Qubes does not support the migitations 
> yet, or that this test cannot get proper info from the kernel, since the 
> kernel is provided by Dom0 instead of the VM? Or are both true?

I do by no means have proper insight into this, but I believe for this 
particular case it doesn't matter much if the VM's kernel is not updated 
against these attacks. I will stand corrected if I'm wrong about that.

My reasoning is, despite that information about the CPU can be seen in the 
VM's, as long as the lower system levels can't be exploited (CPU/BIOS/Xen), 
then it won't matter if the AppVM's kernel is exploitable, because it can't 
reach deeper down, and will be blocked by the patch fixes on the lower system 
levels.

However, like Andrew mentioned above, it might still be possible to some extent 
use it in combination with other attacks (hypothetically), so it's not deemed 
completely secure (yet, at least).

An illustrative example, 
- The dig-able dirt is the exploitable VM's. 
- The fence and cemented ground below the dirt inside the fence's area, is the 
secured VM environment.

So a successful attack on an VM would be like the soft dirt ground in the VM's 
can be dug and breach the cement, in order to get out of the protected area 
(prison break). If the ground is cemented below the area inside the fence, then 
you cannot dig further down to escape the fenced area. So too for the AppVM's, 
the soft dirt ground being dug-able, but since you can't dig further down to 
exploit further than the lower level security (cemented ground) then it won't 
matter anyway.

However, the issue being, if some places are not fully cemented, then it might 
be possible to escape. The question then is, since no one can see the cement 
without first digging (not the protectors, not the attackers, essentially no 
one knows without first digging), then it remains unknown if the area is 
inescapable or not.

The aim of Qubes is to secure the cement and fence, not the dirty ground, i.e. 
no matter what you run in the VM's, it should stay secure. While true securing 
the VM's can add extra security, it is however not the aim here. You yourself 
can install more secure VM's if you prefer. I believe, while not knowing, that 
the Qubes team might focus more on securing the VM's dirt (in above's analogy), 
but right now, it's all on the fence and cemented ground inside it.

Qubes OS's work, as I perceive it, focuses on securing the environment from 
below up. So if security inside a VM is needed, then they are not meeting their 
own set goals to allow a any insecure code run wild in VM's without it 
compromising the Qubes OS infrastructure.

I have absolutely no deep insight into any of this, however, this is my 
perspective, perhaps it can be of use, or perhaps it can't.

-- 
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/c4179bd4-d648-4577-b639-e6f56a00a5dd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: Lenovo Yoga 920 Hypervisor not starting

2018-03-16 Thread Yuraeitha
On Friday, March 16, 2018 at 11:56:00 AM UTC+1, 
bbdc0633aad7f210c787697cc1664e7e...@tutanota.com wrote:
> Hi there.
> 
> I am trying to install Qubes and have tried 3.2 and 4.0-rc5.
> 
> In both cases the hypervisor does not start but halts after five lines and 
> the processor still running heavy for a while. The only screen output I get 
> (4.0-rc5)
> "
> Xen 4.8.3 (c/s ) EFI loader
> Using configuration file 'BOOTX64.cfg'
> vmlinuz: 0x00.(some numbers)
> initrd.img: 0x(more numbers)
> 0x:0x00:0x02.0x0: ROM: 0x1 bytes at 0x2d...(numbers)
> "
> 
> The same happens on 3.2, but I get the GRUB menu first. This did not help:
> https://www.qubes-os.org/doc/uefi-troubleshooting/#cannot-start-installation-installation-completes-successfully-but-then-bios-loops-at-boot-device-selection-hangs-at-four-penguins-after-choosing-test-media-and-install-qubes-os-in-grub-menu
> 
> I have also gone to BIOS to enable USB boot and disable Secure boot (Legacy 
> doesn't appear to be an option)
> 
> I installed Fedora and set up Qubes on my USB, both as instructed in the 
> installation guide and in the guide for Lenovo thinkpads:
> https://www.qubes-os.org/doc/thinkpad-troubleshooting
> https://www.qubes-os.org/doc/installation-guide/#copying-the-iso-onto-the-installation-medium
> 
> 
> I have tried the same in a macOS (terminal) and Windows (Rufus) environment.
> 
> I would *really* like Qubes to work, and would be exhilarated if it does 
> eventually.
> 
> 
> 
> Sincerely,
> Troubled Qubes fan

http://www.zdnet.com/article/intel-were-ending-all-legacy-bios-support-by-2020/
This article seems very unfortunate, it might be that LegacyBIOS can have been 
purged on your machine. You might want to look it up, there must be some 
discussions for Linux in general on the Yoga 920 who wants to use LegacyBIOS, 
so you should be able to find a discussion if you dig long enough after it in 
the search engines.

-- 
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/f34af4ab-e13d-48db-a163-22e18246ce9d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: Lenovo Yoga 920 Hypervisor not starting

2018-03-16 Thread Yuraeitha
On Friday, March 16, 2018 at 11:56:00 AM UTC+1, 
bbdc0633aad7f210c787697cc1664e7e...@tutanota.com wrote:
> Hi there.
> 
> I am trying to install Qubes and have tried 3.2 and 4.0-rc5.
> 
> In both cases the hypervisor does not start but halts after five lines and 
> the processor still running heavy for a while. The only screen output I get 
> (4.0-rc5)
> "
> Xen 4.8.3 (c/s ) EFI loader
> Using configuration file 'BOOTX64.cfg'
> vmlinuz: 0x00.(some numbers)
> initrd.img: 0x(more numbers)
> 0x:0x00:0x02.0x0: ROM: 0x1 bytes at 0x2d...(numbers)
> "
> 
> The same happens on 3.2, but I get the GRUB menu first. This did not help:
> https://www.qubes-os.org/doc/uefi-troubleshooting/#cannot-start-installation-installation-completes-successfully-but-then-bios-loops-at-boot-device-selection-hangs-at-four-penguins-after-choosing-test-media-and-install-qubes-os-in-grub-menu
> 
> I have also gone to BIOS to enable USB boot and disable Secure boot (Legacy 
> doesn't appear to be an option)
> 
> I installed Fedora and set up Qubes on my USB, both as instructed in the 
> installation guide and in the guide for Lenovo thinkpads:
> https://www.qubes-os.org/doc/thinkpad-troubleshooting
> https://www.qubes-os.org/doc/installation-guide/#copying-the-iso-onto-the-installation-medium
> 
> 
> I have tried the same in a macOS (terminal) and Windows (Rufus) environment.
> 
> I would *really* like Qubes to work, and would be exhilarated if it does 
> eventually.
> 
> 
> 
> Sincerely,
> Troubled Qubes fan

Keep looking for other replies and fix suggestions here in the future, but for 
now I'd suggest trying this.

I recently inspected a Lenovo 720 for a short time in the BIOS, I noticed the 
UEFI boot selecting between LegacyBIOS/UEFI was grayed out, and from another 
experience a year or so ago I had to switch some BIOS settings to allow to 
enable LegacyBIOS. Sometimes you need to re-start the BIOS/PC to make changes 
take effect too. Since you probably have a grayed out UEFI boot-selection in 
the boot menu, chances are it's a setting that needs changing, to allow 
LegacyBIOS to be selected. Which setting, is hard to say, I don't have that 
knowledge on hand, but it's probably a UEFI related setting which can't be 
enabled while LegacyBIOS is used. Be careful you don't change anything risky if 
you're trial and error'ing this though.

Keep trying, you might get it working in the end, whether it's by UEFI or 
LegacyBIOS. It might be worth it to see if you can get LegacyBIOS enabled.

-- 
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/29e9f822-30cc-4825-8d8a-bd16a59e96cd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: cant connect to outsidet network after setting static ip

2018-03-15 Thread Yuraeitha
On Wednesday, March 14, 2018 at 5:23:22 PM UTC+1, shon.b...@gmail.com wrote:
> so i have vm that i had network connectivity
> as part of the guide that is listed below
> i set a static ip to the vm, after which i cant connect to anything
> even after statically binding the ip to the previous ip
> but to no avail
> iv tried to connect the vm to both sys-firewall and sys-net directly 
> any ping attempt from said vm returns destination host unreachable 
> the other vm's are unaffected and still have network connectivity

Another solution you can try looking into, is that this could be because you're 
having both the Qubes tools trying to set an automatic IP, in addition to your 
manual adjusted IP, at the same time. I.e. in Windows VM's if you need to use 
manual config, you need to disable the Qubes network tools service first, so it 
doesn't create conflict with the manual adjusted IP. Something similar probably 
needs to be disabled in your other VM; thoough it might help if you mention 
what OS this VM is?

If it's a typical Qubes template, then you can just copy the the template, and 
try uninstall the Qubes tools networking. But only do this in a cloned Qubes 
templates, don't do something like this in any important Qubes templates, 
because this is untested, and if it goes wrong, then you can just simply delete 
the cloned template, rather than have a major headache on your hand.

-- 
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/7552c421-6503-4d9a-b259-d424d1315068%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: T520 for Qubes 4.0 , can I / should I boot Win7 HDD, and Qubes 4.0 from an SSD?

2018-03-15 Thread Yuraeitha
On Thursday, March 15, 2018 at 5:11:17 AM UTC+1, yre...@riseup.net wrote:
> T520 for Qubes 4.0 , can I / should I boot Win7 HDD, and Qubes 4.0 from
> an SSD?
> 
> I'm looking at buying an i7 T520 that is listed as working on the HCM
> list on a website, for like $250, I see them cheaper on ebay but , the
> thing has 4GB ram , by adding a DVD tray / caddie for an SSD and an SSD
> and 4GB ram, I add another $140  or so  to the cost   so am
> wondering  if this technically would not have the issue where  dual
> booting is considering insecure, if I'm actually booting from 2 separate
> HDs ;  and/or  if  doing the Qubes 4.0  install  is going to be any
> tricker or easier  with 2 HD,  assuming,  I wasn't planning on  doing
> another  dual boot off  1 HD again 
> 
> 
> thanks

You're right that it's more secure to have two devices, but only very, very 
slightly. Though, it's a good idea to do even so, even if only slightly, if you 
must. I believe the partition table can be more exposed here if using the same 
drive? but I'm not sure. 

- Generally you have to look at the security exploits, i.e. it may be worth 
reading the research and articles The Qubes OS Project has made, and other 
works that is being put forward. But in general, you need to be wary of 
firmware exploits, boot-loader exploits, never access your files from an 
insecure duaæ-boot, and weak or no encryption. Something along those lines. 
Generally firmware exploits/attacks, to my understanding, are more exotic 
today, BUT! that may change one day very quickly, and you can also risk being 
plain unlucky. There is also the consideration that it might not be possible to 
make an accurate picture of how many infected firmware's there are existing in 
the wilds, and/if possible to make research to get an idea, it might take years 
before it's detected on a large scale. So you may want to be wary of firmware 
attacks, they may some day be a threat quicker than you think, i.e. think for 
example A.I.'s that can automatically modify themselves to exploit different 
kinds of firmwares, rather than requiring a human hand to do so (intensive 
labor). 

- Use a strong password, so that your CPU's own calculation power is 
insufficient to be used to crack your encryptions. 

- Never leave anything unencrypted. While you can't protect your firmwares, at 
least you can protect all drives with encryption, except, for the bootloader, 
which is a very big weak spot. If you want to protect yourself here, (except 
you are still vulnurable to firmware attacks), then you need to move your 
boot-loader to a locked medium, preferably one that can't be editied, i.e. a 
CD/DVD. You can leave that CD/DVD in your system though, since what matters is 
that it can't be edited, it's not the fact that it can be read. 

- Also you may want to consider at least 8GB RAM. Even 8gigs can feel limited, 
4gigs will probably feel like a crap experience on Qubes. 

-- 
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/e9907a90-3c4a-4549-85a1-14b1dcbb0436%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Can a Windows StandaloneVM be made into a TemplateVM?

2018-03-15 Thread Yuraeitha
On Wednesday, March 14, 2018 at 5:56:20 PM UTC+1, inqubator wrote:
> > I copied
> > /var/lib/qubes/appvms/win7/root.img
> > /var/lib/qubes/appvms/win7/private.img
> > to
> > /var/lib/qubes/vm-templates/win7-x64-template/root.img
> > /var/lib/qubes/vm-templates/win7-x64-template/private.img
> > 
> 
> Hi, can I ask how you did that? When I look into the directories you mention 
> (in R4), I don't find these files (but only "icon.png" and "firewall.xml").
> 
> Thanks

If you didn't do that already of course, you might have as it's an easy 
suggestion.

-- 
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/839d513f-a70c-4873-8dfc-c9ba29ce5fd7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Can a Windows StandaloneVM be made into a TemplateVM?

2018-03-15 Thread Yuraeitha
On Wednesday, March 14, 2018 at 5:56:20 PM UTC+1, inqubator wrote:
> > I copied
> > /var/lib/qubes/appvms/win7/root.img
> > /var/lib/qubes/appvms/win7/private.img
> > to
> > /var/lib/qubes/vm-templates/win7-x64-template/root.img
> > /var/lib/qubes/vm-templates/win7-x64-template/private.img
> > 
> 
> Hi, can I ask how you did that? When I look into the directories you mention 
> (in R4), I don't find these files (but only "icon.png" and "firewall.xml").
> 
> Thanks

It might not be a template, but I'm not sure with RC-4, I didn't look for 
windows in there during RC-4. However, if it isn't acting like a template, then 
it might be placed elsewhere. Try go back a level, /var/lib/qubes/ and instead, 
look in maybe /var/lib/qubes/appvms/ 

-- 
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/7c1871e2-7db8-4995-8dbb-1166d161b981%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: How to show boot entries?

2018-03-15 Thread Yuraeitha
On Thursday, March 15, 2018 at 11:23:59 AM UTC+1, CoeusITE wrote:
> Thanks, Yuraeitha! 
> 
> It seems xen.cfg is stored in the EFI partition, and I can modify it within 
> dom0 or through Fedora Live without decryption. However I don’t know how to 
> modify it. 
> 
> I think I should add some parameters in [global] section of xen.cfg, but I 
> fail to find any tips from Xen’s official documents.
> 
> 
> On Thu, Mar 15, 2018 at 18:13 Yuraeitha <yura...@gmail.com> wrote:
> On Thursday, March 15, 2018 at 7:08:25 AM UTC+1, coeu...@gmail.com wrote:
> 
> > Hello, guys.
> 
> >
> 
> > I want to show boot entries so that I can select certain kernel to boot, 
> > and I'm using EFI/qubes/xen.efi as boot binary. Currently, it will directly 
> > boot the default kernel. Could anyone give some advices?
> 
> >
> 
> > BTW, here is the reason: I have multiple kernels installed and 
> > kernel-latest-4.15.6-1 may raise kernel panic errors on Raven Ridge 
> > platform, but kernel-4.14.18-1 works just fine.
> 
> >
> 
> > Thanks!
> 
> > D.F.
> 
> 
> 
> Two methods I know of, but there are probably other ways too, i.e. via the 
> EFI Shell.
> 
> 
> 
> - Use a secure live boot, access dom0, unlock your encryption, then go here 
> and use an editor to edit the file /boot/efi/EFI/qubes/xen.cfg (most straight 
> forward between the two approaches here, but be careful you don't make dom0 
> less secure with the live boot access).
> 
> 
> 
> - Install Grub, and use Grub to boot EFI installs. This way you can have 
> multiple EFI kernel boots.
> 
> 
> 
> 
> 
> I'm not familiar with the other EFI methods to switch the kernel, you may 
> want to wait for more answers to see first. Careful you don't overwrite 
> anything important if you choose to install Grub. Be mindful you may need to 
> manually adjust Grub as well to make it work. Thereby, the first option is 
> probably the most easy of the two.
> 
> 
> 
> --
> 
> 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/CZ5vMNL_c7k/unsubscribe.
> 
> To unsubscribe from this group and all its topics, send an email to 
> qubes-users...@googlegroups.com.
> 
> To post to this group, send email to qubes...@googlegroups.com.
> 
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/qubes-users/7b3d2068-088c-4f77-88fb-97c82368c828%40googlegroups.com.
> 
> For more options, visit https://groups.google.com/d/optout.

don't edit the listed kernels below the preference lines though, only edit the 
kernel preference, near the top of the file. That'll be the one that selects 
which kernel to boot.

-- 
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/25ebea71-a495-48ec-873a-543dbeed56b4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: How to show boot entries?

2018-03-15 Thread Yuraeitha
On Thursday, March 15, 2018 at 11:23:59 AM UTC+1, CoeusITE wrote:
> Thanks, Yuraeitha! 
> 
> It seems xen.cfg is stored in the EFI partition, and I can modify it within 
> dom0 or through Fedora Live without decryption. However I don’t know how to 
> modify it. 
> 
> I think I should add some parameters in [global] section of xen.cfg, but I 
> fail to find any tips from Xen’s official documents.
> 
> 
> On Thu, Mar 15, 2018 at 18:13 Yuraeitha <yura...@gmail.com> wrote:
> On Thursday, March 15, 2018 at 7:08:25 AM UTC+1, coeu...@gmail.com wrote:
> 
> > Hello, guys.
> 
> >
> 
> > I want to show boot entries so that I can select certain kernel to boot, 
> > and I'm using EFI/qubes/xen.efi as boot binary. Currently, it will directly 
> > boot the default kernel. Could anyone give some advices?
> 
> >
> 
> > BTW, here is the reason: I have multiple kernels installed and 
> > kernel-latest-4.15.6-1 may raise kernel panic errors on Raven Ridge 
> > platform, but kernel-4.14.18-1 works just fine.
> 
> >
> 
> > Thanks!
> 
> > D.F.
> 
> 
> 
> Two methods I know of, but there are probably other ways too, i.e. via the 
> EFI Shell.
> 
> 
> 
> - Use a secure live boot, access dom0, unlock your encryption, then go here 
> and use an editor to edit the file /boot/efi/EFI/qubes/xen.cfg (most straight 
> forward between the two approaches here, but be careful you don't make dom0 
> less secure with the live boot access).
> 
> 
> 
> - Install Grub, and use Grub to boot EFI installs. This way you can have 
> multiple EFI kernel boots.
> 
> 
> 
> 
> 
> I'm not familiar with the other EFI methods to switch the kernel, you may 
> want to wait for more answers to see first. Careful you don't overwrite 
> anything important if you choose to install Grub. Be mindful you may need to 
> manually adjust Grub as well to make it work. Thereby, the first option is 
> probably the most easy of the two.
> 
> 
> 
> --
> 
> 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/CZ5vMNL_c7k/unsubscribe.
> 
> To unsubscribe from this group and all its topics, send an email to 
> qubes-users...@googlegroups.com.
> 
> To post to this group, send email to qubes...@googlegroups.com.
> 
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/qubes-users/7b3d2068-088c-4f77-88fb-97c82368c828%40googlegroups.com.
> 
> For more options, visit https://groups.google.com/d/optout.

np's :) 

It's been a while since I modified one as I generally prefer legacyBIOS over 
EFI, but if memory serves, you only need to edit the top lines near the top of 
the file, the kernel preferences. No need to add or delete anything, you just 
need to change the kernel numbers. If you're unsure which kernel numbers you 
got, then you can perform a "ls" command inside the folder where the 
configuration file is located, it'll show the different kernels next to it. The 
top of the file is kind of like a default selector the the below listed kernels 
in the file, which will pick whichever kernel listed below it (should be 3 
kernels by default). 

Btw if you get frequent kernel issues, or expect more of them in the future 
after a failed kernel update, then you can increase the number of kernels the 
Linux (Qubes) system saves, thereby you have more redundancy in the future. 
Just be sure you got enough space on your partition where the boot device is 
located for multiple of kernels and files. 

This can wait till you get it working again btw. You can edit this file in dom0 
/etc/yum.conf and change "installonly_limit=3" i.e. set it to 5 or 7 instead. 
But be really careful if you got a limited drive space, it can cause your 
updates to fail, and result in a half finished update because it didn't have 
enough drive space to finish up. It will tell you when that happens, but you'll 
be unable to re-boot/re-start without fixing it. So take precaution against 
that when increasing the limit :)

-- 
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/0e7d92fa-7463-48bc-9f72-bb84e3df1db9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: How to show boot entries?

2018-03-15 Thread Yuraeitha
On Thursday, March 15, 2018 at 7:08:25 AM UTC+1, coeu...@gmail.com wrote:
> Hello, guys. 
> 
> I want to show boot entries so that I can select certain kernel to boot, and 
> I'm using EFI/qubes/xen.efi as boot binary. Currently, it will directly boot 
> the default kernel. Could anyone give some advices?
> 
> BTW, here is the reason: I have multiple kernels installed and 
> kernel-latest-4.15.6-1 may raise kernel panic errors on Raven Ridge platform, 
> but kernel-4.14.18-1 works just fine.
> 
> Thanks!
> D.F.

Two methods I know of, but there are probably other ways too, i.e. via the EFI 
Shell. 

- Use a secure live boot, access dom0, unlock your encryption, then go here and 
use an editor to edit the file /boot/efi/EFI/qubes/xen.cfg (most straight 
forward between the two approaches here, but be careful you don't make dom0 
less secure with the live boot access).

- Install Grub, and use Grub to boot EFI installs. This way you can have 
multiple EFI kernel boots.


I'm not familiar with the other EFI methods to switch the kernel, you may want 
to wait for more answers to see first. Careful you don't overwrite anything 
important if you choose to install Grub. Be mindful you may need to manually 
adjust Grub as well to make it work. Thereby, the first option is probably the 
most easy of the two. 

-- 
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/7b3d2068-088c-4f77-88fb-97c82368c828%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: qvm-backup --exclude no longer exluding specified VMs from backup

2018-03-13 Thread Yuraeitha
On Tuesday, March 13, 2018 at 11:07:49 PM UTC+1, Xaver wrote:
> After updating system from 4.0-rc4 to rc5 qvm-backup --exclude no longer 
> excludes the specified VM from the backup. When the command is run the 
> specified VMs are in fact included in the backup. This was not an issue with 
> 4.0-rc4 and a system backup was created prior to updating to rc5 without any 
> issues. I am able to set qvm-prefs  include_in_backups false to 
> prevent individual VMs from being included in backups.  Does anyone have an 
> idea as to what the problem could be?
> 
> 
> 
> Thanks in advance
> 
> 
> 
> Xaver
> 
> 
> 
> 
> 
> 
> Sent with ProtonMail Secure Email.

By the looks of it, they made a default profile that does not include dom0 or 
the templates. I have a similar problem, by the looks of it, it is identical to 
yours. Which means it's probably an issue that either covers all RC-4 --> RC-5 
updates, or all RC-5 in general.

For I can only suggest two choices, either include VM's instead of exclude 
(since include works correctly and disables the new default profile), or use 
backup profiles, by typing all your inclusions, and then save the profile for 
future use. Just remember to update your profile when making new VM's in the 
future, it'd fatal if it wasn't included in the profile. 

If you haven't done include before, it's the same as with -x or --exclude, 
except you just write the VM's name with spaces between, no attributes needed.

To make a profile, you can use the --profile (please consult the manual "man 
qvm-backup", as there are some dom0/domU situations to be aware of when using 
the two different profile flags).

-- 
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/fbfa81c1-83bc-4160-a593-bcc74d1a0c59%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: laptop fails to sleep, becomes very hot

2018-03-13 Thread Yuraeitha
On Tuesday, March 13, 2018 at 10:13:45 PM UTC+1, Dave C wrote:
> Many times in recent days, I've closed my Qubes laptop, expecting it to 
> sleep, and put it into my backpack.  Normally it sleeps as expected.
> 
> Two of those times, once today and once several days ago, I reach into the 
> backpack and find the laptop extremely hot to the touch.  I'd expect the fan 
> to be on at these temperatures, but it isn't.
> 
> When I open the laptop, theres no response and similarly no response to 
> pressing keys.  I press and hold the power button for a long time.  There's 
> still no feedback from the computer, but it does turn off and cool down.
> 
> So far, I haven't noticed permanent damage, but I worry about that.  It's an 
> unpleasant surprise to find that the battery is totally drained and I'm not 
> sure what the computer has been trying to do.
> 
> Any thoughts?  Or suggestions how to troubleshoot this?
> 
> -Dave

I can confirm two similar cases in recent weeks, though there's been quite some 
time between them, weeks? and I typically use suspend multiple times a day, 
except sometimes weekends.

There are other cases, where sys-net stops responding, or the internet isn't 
working when it's brought back from suspend, though these cases are just as 
rare as the above no suspend issue (I'm using the wi-fi module blacklisting in 
sys-net btw).

To me it seems like a semi-rare bug that is triggered by something yet unknown, 
though maybe it's known on github tracking issues? 

Either way, I think this might be related to the sys-net, but I can't really be 
sure here. Perhaps you can write a script that disables the networking, 
shutsdown sys-net, and then starts sys-net again and re-connects networking as 
it wakes up. 

This isn't a pretty solution, but it might work? Does your issue happen 
frequent enough so that you can test if sys-net is shutdown, that suspend then 
works properly? Would be ideal to know if that is indeed it before spending 
some time on such a script.

-- 
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/694932ce-629d-4c2c-8b49-94e4936563cf%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: R4.0 drops USB data

2018-03-13 Thread Yuraeitha
On Saturday, March 10, 2018 at 6:36:25 AM UTC+1, Glen H wrote:
> On Thursday, March 8, 2018 at 8:55:56 AM UTC-5, Glen H wrote:
> > On Thursday, March 8, 2018 at 8:12:59 AM UTC-5, Ed wrote:
> > > On 03/07/2018 10:24 PM, Glen H wrote:
> > > > Hi,
> > > > 
> > > > I'm using R4 (having never used R3) and trying to get my scanner 
> > > > working but it stops scanning a page half way through.  After debugging 
> > > > with the author of the scanner software they say the program asks for 
> > > > 128 KBytes of data and the first 256 bytes of this data is dropped 
> > > > (lost).
> > > > 
> > > > To fix this I've tried:
> > > > 1) Turning off USB 3.0 in BIOS (unfortunately this isn't really an 
> > > > option as all the external ports are disabled).  It doesn't revert back 
> > > > to USB 2.0
> > > > 2) Set the ports to USB 2.0 via setpci:
> > > > 
> > > > ```
> > > > lspci -nn | grep USB | cut -d '[' -f3 | cut -d ']' -f1 | xargs -I@ 
> > > > setpci -H1 -d @ d0.l=0
> > > > ```
> > > > 
> > > > Unfortunately neither of those made a difference.  Using the 
> > > > scanner/software in Windows on a different computer works.
> > > > 
> > > > 
> > > > I'm currently running a Qubes backup and then I'll try installing 
> > > > Ubuntu and see if that works.  If so would seem to be related to Qubes.
> > > > 
> > > > Does anyone have any ideas?  My laptop is a Dell e7440 with the latest 
> > > > BIOS.
> > > > 
> > > > Thanks,
> > > > 
> > > > Glen
> > > > 
> > > 
> > > Are you passing the device through to another VM?
> > > 
> > > The USB pass-through method has given me issues in the past for devices 
> > > that use a lot of bandwidth (webcams), though you are saying data is 
> > > lost after only a few bytes, I still might be suspect of the USB 
> > > passthrough system in qubes...
> > > 
> > > So if you ARE passing through you might want to try running the scanner 
> > > software directly from sys-usb to see if you can eliminate the USB 
> > > passthrough as a source of problems.
> > > 
> > > Ed
> > 
> > Hi, I'll do some more tests in the next few days but just to answer some 
> > questions:
> > 
> > 1) I have USB devices assigned in sys-usb
> > 
> > 2) I use the devices panel widget to pass them to my AppVM.
> >   - then it shows up as "Bus 001 Device 002: ID 04f9:60a0 Brother 
> > Industries, Ltd ADS-2000"
> > 
> > 3) The controller info from Dom0 is:
> > 
> > 00:14.0 USB controller [0c03]: Intel Corporation 8 Series USB xHCI HC 
> > [8086:9c31] (rev 04)
> > 00:1d.0 USB controller [0c03]: Intel Corporation 8 Series USB EHCI #1 
> > [8086:9c26] (rev 04)
> > 
> > I'll try testing in the debian-9 AppVM, test from sys-usb, and install 
> > Ubuntu too once I have time.  One other thing I haven't investigated is 
> > "Configure strict reset for PCI devices" but it is grayed out in sys-usb 
> > Devices tab.
> > 
> > Thanks for the help.
> > 
> > Glen
> 
> I ran some tests and the issue happens in sys-usb, Ubuntu (fresh install, no 
> Qubes).  When I use Windows 7 on the same hardware it works.  So it looks 
> like there is a driver issue with Linux.  I tried updating the USB controller 
> in Windows and then switching back to Linux and the problem still exists.  So 
> it seems the USB driver has an issue with reading data from my scanner.  Any 
> recommendations for what I should do?
> 
> Thanks,
> 
> Glen

When narrowed down to a likely driver issue, then I'd suggest a next step to 
find the modules name that handles the driver/scanner. You can also check if 
it's the same module across different Linux systems, Debian/Fedora template, as 
well as the one on Ubuntu. Another thing you can do is look up the printer and 
see if you can find any Linux drivers to it to download, or if it was written 
directly to the kernel/modules. Another approach could be unofficial drivers, 
for example drivers that might work on hardware, where the driver wasn't build 
by the hardware company. Sometimes you see hardware company employee's write 
drivers in their free time too, and other times you find similar 
drivers/modules which can work, albeit not perfectly. It can also do damage to 
the hardware if a wrong driver is used, so you need to take precautions or be 
wary not to take the unofficial drivers or unofficial modules, if you want to 
avoid risk of damage. It could also be that you're already using an unofficial 
driver/module, and that the official one might work. 

For example, it might just be a module change you need to do, modules are kind 
of external drives to the drivers included in the kernel itself. So modules 
serves as a way to include drivers, without messing with the kernel too much. 
As far as I understand, it also makes it easier to maintain the kernel over the 
years, as modules can easily be out-dated and thrown away in favour for new 
ones, while keeping the kernel clean as it's been upgraded. But my 
understanding of kernels/modules is very vague, don't take it at face value, I 
might have gotten some details 

Re: [qubes-users] Re: anyone else get hit by google's auto-deleting qubes users mail responses the moment they are send?

2018-03-13 Thread Yuraeitha
On Monday, March 12, 2018 at 3:02:15 PM UTC+1, steve.coleman wrote:
> I would say that if somebody has such an email in their out box, and you 
> know it was removed, then contact Google and resolve the issue rather 
> than just complaining here. No offense meant by this, its just that you 
> have exactly what they need to tack down the problem sitting in your 
> outbox. How on earth would they benefit by randomly deleting your mail 
> on purpose? Their business it learning about you, to better market you, 
> not pissing people off. Deleting legitimate information about you and 
> what you like to talk about is exactly what they want to keep on file. 
> Deleting it make so sense in their business model.
> 
> The explanation I would offer is their infantile 
> data-collecting/spam-eliminating AI filter has been mistrained, and 
> needs to be slapped silly by a human and corrected. The problem we have 
> is that much of the "logic" they use these days is due to machine 
> learning algorithms that one can not even ask the model why it did 
> something completely stupid. It's merely the result of it learning the 
> wrong logic from what data we gave it during the "training process".
> 
> There was once a DoD contractor who jumped on the AI bandwagon back in 
> the 70's, who trained the system to pick out tanks hiding in camouflage. 
> It did great, so they wanted to show the top brass. Before doing so they 
> took new photographs because the old ones were quite worn, and the new 
> photos flunked the test. What the system learned was cloudy vs sunny 
> days, not tanks and no-tanks. Filtering emails based on the same "logic" 
> is bound to have its problems.
> 
> So, don't attribute to malice where it can be the result of complete 
> incompetents in machine learning. This unfortunately is the reality of 
> the 'new software' era we now live in. Make them get it right if you 
> disapprove.
> 
> btw - If this email response to you disappears then I will want answers 
> from them myself. The more people who point out actual instances of 
> missing legitimate emails, the sooner they will be forced to reevaluate 
> their own methods of verification of this kind of ML mistraining.
> 
> 
> On 03/12/18 02:55, 799 wrote:
> > Hello,
> > 
> > Am 12.03.2018 7:40 vorm. schrieb "Yuraeitha" <yuraei...@gmail.com 
> > <mailto:yuraei...@gmail.com>>:
> > 
> > This is getting ridiculousness, another two posts automatically
> > removed straight after or shortly after posting, it's inhuman
> > speeds, it is certainly google-bots pretty censorship handy-work non
> > normal content/language.
> > 
> > 
> > Honestly I haven't understand why Qubes Team is hosting it's Mailinglist 
> > on Google.
> > 
> > [...] Google collects and maintains information about your account 
> > activity, including the groups that you join or manage, lists of other 
> > members or invitees in the groups, messages or topics you track, custom 
> > pages you create or edit, ratings you make, and your preferred settings 
> > when using Google Groups [...]
> > 
> > I am sure that there are solutions where a Mailinglist can be hosted and 
> > as others have suggested maybe run a forum.
> > 
> > Maybe https://savannah.gnu.org/ ?
> > 
> > [799]
> > 
> > -- 
> > You received this message because you are subscribed to the Google 
> > Groups "qubes-users" group.
> > To unsubscribe from this group and stop receiving emails from it, send 
> > an email to qubes-users+unsubscr...@googlegroups.com 
> > <mailto:qubes-users+unsubscr...@googlegroups.com>.
> > To post to this group, send email to qubes-users@googlegroups.com 
> > <mailto:qubes-users@googlegroups.com>.
> > To view this discussion on the web visit 
> > https://groups.google.com/d/msgid/qubes-users/CAJ3yz2vqmL64MVPVOLkfeJKRNYsi24Do6Dzgs%2BkcnxX3CWdvHw%40mail.gmail.com
> >  
> > <https://groups.google.com/d/msgid/qubes-users/CAJ3yz2vqmL64MVPVOLkfeJKRNYsi24Do6Dzgs%2BkcnxX3CWdvHw%40mail.gmail.com?utm_medium=email_source=footer>.
> > For more options, visit https://groups.google.com/d/optout.

First, I'll apologize if I sound a bit grumpy today, it's not on you, and I 
hope you will remember that below, even though I strongly disagree with you, 
it's nonetheless nothing personal.

Originally the off-topic I made was secondary mentions, my on-topic was the 
reason for posting, which was to make others aware why their post are deleted 
too here on Qubes users mailing list. I actually searched for an existing 
thread on it, but I found none, hence why I made this post for futur

Re: [qubes-users] Custom resolutions-xrandr

2018-03-12 Thread Yuraeitha
On Monday, March 12, 2018 at 5:30:29 AM UTC+1, randal...@gmail.com wrote:
> Did that solve the black bar issue? Also I'm the so called average user so I 
> would need a small step by step guide cause this looks super confusing.
> Thanks an advance

Google hates me tonight, but I'll try again. For some reason google kept 
deleting my messages some hours back, but my last message got through, so maybe 
this one will too. Seemingly my situation isn't an isolated case either. But 
anyway, lets get on-topic (and hope this successfully posts this time).

Use this command "xrandr" in dom0 terminal to find the supported resolutions on 
your machine, as well as the screens exact name. The exat name is important. 
For example my screens name is eDP1, but you put eDP-1 in your command. Is your 
screen really named that and not eDP1? It might explain partly why it doesn't 
work. Run "xrandr" in dom0 terminal, nothing else, just that one command. It'll 
give you a print out of all connected screens, supported resolutions and screen 
names.

Also, this is a working command, I use it my self daily. 
xrandr --output eDP1 --mode 1920x1080 

Remember to only put a resolution that your setup supports. Even supported 
resolutions can look bad though, so try aim for one with proper proportions. 
Most normal setups support 1920x1080, if you can see it in the list, then yours 
also support it, in that case give that one a try to begin with. Remember to 
double check your screen's name, even a single letter difference can make it 
stop working.

First test the command in dom0 terminal, if it works, and you found your ideal 
settings, then you can turn it into a script, which afterwards can be either 
keybinded, autostarted, or turned into a shortcut (whichever you prefer most).

in a clean dom0, type this (no sudo here!) 
nano screen-resolution-script.sh 

Terminal becomes an editor, now just write this exact command into your window, 
modified with the values (resolution and screen name) that fits your system. 

The Nano editor can be saved by "ctrl+x", keep eyes on window as you do this, 
ans you'll notice the message at bottom. Something like 2Do you want to save?" 
Press Y for yes, and accept the name you gave it earlier with enter. 

Now your script is located in dom0 at 
/home/your-user-name/screen-resolution-script.sh 

In order to make it executeable, write this in dom0 terminal 
chmod +x screen-resolution-script.sh 

Now, for example keybind it, type this in dom0 again
xfce4-keyboard-settings 

a window will popup, go to the "Application Shortcuts" and click the add 
button. Now add the path to your script, and bind a key. 

I gotta hurry running now, so I cant explain the other two approaches right 
now. But it's quickly done 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 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/5cb20f4f-71ab-4ee7-a0d6-c8242aa647ef%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: Custom resolutions-xrandr

2018-03-12 Thread Yuraeitha
On Saturday, March 10, 2018 at 9:21:41 PM UTC+1, randal...@gmail.com wrote:
> If im trying to create a custom resolution that I can auctually see on my 
> 3200x1800 how do I get rid of the black area and make the resolution full 
> screen? I tried adding xrandr --output eDP-1 set "scaling mode" "full aspect" 
> and nothing is happening.I allready made a resolution of 1800x1400, but 
> instead of going full it just shrinks the display to fit into a box.

Careful with running resolutions that are not supported by your graphic card. 
Try run just "xrandr" in dom0, it'll print out all your supported resolutions.

First confirm in dom0 terminal if it works, then make a script that you can 
keybind, autostart, or turn into an icon shortcut. Put it like this;

"xrandr --output eDP1 --mode 1920x1080"

Above resolution is an example, change it to one your card supports. Also the 
same command that finds your supported resolutions, also tells you your 
screen's name. Be sure you got the screen name correct, it will only work if 
you do it precisely. For example, are you sure it's not eDP1 instead of eDP-1? 
It can also be named something else entirely, i.e. HDMI3, you need to confirm 
to be sure.

-- 
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/7c02927b-02c6-4d35-bd7b-e97048a5a904%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: Qubes won't boot "kernel panic", where is AppVm data?

2018-03-12 Thread Yuraeitha
On Sunday, March 11, 2018 at 11:03:02 PM UTC+1, ale10...@gmail.com wrote:
> Hello, I am currently locked out of my qubes system because of a "kernel 
> panic" error I encounter when I boot the system, after the grub screen. I 
> don't really know what to do. 
> The only thing I did before this to happen is to try to install AEM (without 
> success), it may be the reason for this.
> Is there any fix to this? I still have my qubes installation media, I can run 
> the troubleshooting mode. I have qubes R4-rc4. 
> I am also searching for the place to search for my appvms data so I can 
> backup them and then re-install qubes (I use qubes for some months now), I 
> can't find the appvm data anywhere... thanks for your answers !

I recommend you don't delete anything before you made sure it works. Maybe 
backup the whole drive, or pull a copy of all data on it to another drive. Just 
to be safe. 

I also recommend you wait a bit for more answers, there may be ways to save 
your system yet.

Your AppVM data should be saved here;
/var/lib/qubes/appvms/

Your Templates data should be saved here; 
/var/lib/qubes/vm-templates

In general have a look at the base folder
/var/lib/qubes/

I never did a rescue this way, so I don't know if this is sufficient. But I 
believe it is all you need, and then you can create new AppVM's with the same 
name (important, must be same names), and then just drag and drop the AppVM 
files in there.

But it's best you have the confirmation of someone who's done this before, 
however, this should at least get you started. Your system may also be rescued 
if someone knows how to fix it. By any chance, did you try use Grub to boot a 
different older kernel? By default Qubes (and other modern *nix's) save up to 3 
kernels at a time. So you should have 2 older kernels. Maybe they work better 
with AEM? 

-- 
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/f2eca4ca-40a0-48b3-bc4a-6e6c01a4c07e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: anyone else get hit by google's auto-deleting qubes users mail responses the moment they are send?

2018-03-12 Thread Yuraeitha
On Monday, March 12, 2018 at 7:55:35 AM UTC+1, [ 799 ] wrote:
> Hello,
> 
> 
> 
> Am 12.03.2018 7:40 vorm. schrieb "Yuraeitha" <yura...@gmail.com>:
> This is getting ridiculousness, another two posts automatically removed 
> straight after or shortly after posting, it's inhuman speeds, it is certainly 
> google-bots pretty censorship handy-work non normal content/language.
> 
> 
> 
> Honestly I haven't understand why Qubes Team is hosting it's Mailinglist on 
> Google.
> 
> 
> [...] Google collects and maintains information about your account activity, 
> including the groups that you join or manage, lists of other members or 
> invitees in the groups, messages or topics you track, custom pages you create 
> or edit, ratings you make, and your preferred settings when using Google 
> Groups [...]
> 
> 
> I am sure that there are solutions where a Mailinglist can be hosted and as 
> others have suggested maybe run a forum.
> 
> 
> Maybe https://savannah.gnu.org/ ?
> 
> 
> [799]

Could the reason maybe be because it has little overhead and maintenance? Goals 
and environment may have changed over the years too. Though of course other 
mail services can do the same too, but were there alternatives around at the 
time they made this? I have no idea, but I think it might be because it was 
more efficient when they were busy building Qubes for the first time, and maybe 
google just stuck since then? 

Savannah looks interesting, so far it looks like a really great alternative. 
Maybe we can do some in-depth research on it and draft an argument for and 
against such a move and present it? Once all the other things we got running 
settles a bit of course.

But at any rate, getting rid of google would be very satisfying though, I'm 
getting more and more salty with them, and more so as the years go by. I only 
use this mail account for google mail-lists btw (if anyone wonders, though I 
should probably get rid of this gmail even so, I'm gettind fed up with google 
so I might end up doing that soon at any rate).

-- 
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/b63865c5-4f20-44ee-bf1c-2a52f045c7df%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: Qubes won't boot "kernel panic", where is AppVm data?

2018-03-12 Thread Yuraeitha
On Sunday, March 11, 2018 at 11:03:02 PM UTC+1, ale10...@gmail.com wrote:
> Hello, I am currently locked out of my qubes system because of a "kernel 
> panic" error I encounter when I boot the system, after the grub screen. I 
> don't really know what to do. 
> The only thing I did before this to happen is to try to install AEM (without 
> success), it may be the reason for this.
> Is there any fix to this? I still have my qubes installation media, I can run 
> the troubleshooting mode. I have qubes R4-rc4. 
> I am also searching for the place to search for my appvms data so I can 
> backup them and then re-install qubes (I use qubes for some months now), I 
> can't find the appvm data anywhere... thanks for your answers !

it seems google is having fun with me and auto-deletes messages as I reply... 
given the number of deleted messages we're seeing lately, maybe I'm not the 
only one having this google issue...

well, I'll try again. Try look here for your AppVM's
/var/lib/qubes/appvms 

and here for your templates
/var/lib/qubes/vm-templates 

and in general /var/lib/qubes/ for anything VM related.

I'm not sure if you can restore it all this way, I haven't done this before my 
self. It might be a good idea to wait for confirmation from someone who's done 
it before, or wait and don't delete/overwrite anything before you got 
confirmation on this method. 

However, I believe the approach is to copy this folder /var/lib/qubes and then 
create identical named VM's, shut them down, and then systematically and 
manually replace the VM's data. Be mindful that this "might" be a bad idea to 
do for templates, it's probably best you only do it with AppVM's. 

Also there may still be a way to save your system rather than salvaging, for 
example did you try load the other 2 kernels? (normal 3 kernels are kept at any 
time and Grub should be able to switch between them).

-- 
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/9065f687-5a8e-4319-82e5-2e72c4a9577c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: anyone else get hit by google's auto-deleting qubes users mail responses the moment they are send?

2018-03-12 Thread Yuraeitha
This is getting ridiculousness, another two posts automatically removed 
straight after or shortly after posting, it's inhuman speeds, it is certainly 
google-bots pretty censorship handy-work non normal content/language. 

https://groups.google.com/forum/#!topic/qubes-users/oZnaHZROW0c

If I can post here again now, for some reason, this thread is immune. Maybe 
it's because I hosted the original mail... either way, google... yeah, I'm lost 
for words.

-- 
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/9cb69ee8-baa4-4f35-a4f7-f476ec716c4c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: anyone else get hit by google's auto-deleting qubes users mail responses the moment they are send?

2018-03-11 Thread Yuraeitha
On Monday, March 12, 2018 at 5:16:28 AM UTC+1, sevas wrote:
> actually... maybe I did. I made a reply to the KDE/Template sec discussion 
> and it was gone.


maybe it'll help if we say we love google? Joke aside... it's very frustrating. 
but at least we got a topic on it now, so if others see it, they know they're 
not alone. Exiting moment to see if this message will disappear too or not... I 
mean, maybe we can outsmart it by having love and google in the same sentence 
(sarcasm).

-- 
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/71738233-40cf-47f1-9e76-20e315169b16%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] anyone else get hit by google's auto-deleting qubes users mail responses the moment they are send?

2018-03-11 Thread Yuraeitha
As the title suggests, the very moment sending mail responses, it changes and 
turns into a deleted message. This has now happened twice in a row. So this is 
a heads-up for google's new level of censorship craziness. Though I have to 
wonder why it only hits some people, maybe it's because of certain Tor nodes 
out there..

Case of point, double deletes
https://groups.google.com/forum/#!topic/qubes-users/b84gHvES2Bc

I have to wonder if creating a new mail topic will be deleted too, if so, then 
at least some of you will read it. 

Given the above double accident twice in a row, and also the increased number 
of deleted messages here and there lately, it seems like google's auto-delete 
bot system is going overboard on its censorship. No harmful content was 
included, just a normal message like any other.

- Yu

-- 
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/78f41063-d548-4dd1-abb8-37617a6fe3e4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] How to install qubes-windows-tools under Qubes 4rc5

2018-03-11 Thread Yuraeitha
On Sunday, March 11, 2018 at 1:53:32 PM UTC+1, Ivan Mitev wrote:
> On 03/11/2018 01:50 PM, 799 wrote:
> > Hello,
> > 
> > I'm trying to install windows on my new Qubes 4rc5 installation.
> > It seems that Qubes.Windows-Tools (QWT) are not available in the Qubes
> > 4-repositories.
> > 
> > qubes-dom0-update --enablerepo=qubes-dom0-current-testing
> > qubes-windows-tools
> > [...]
> > Error: Unable to find a match
> > 
> > After some trial and error I found a way, is there another way to
> > accomplish easier?
> > If not I would add this to the docs.
> 
> It's already a work in progress ; check this issue:
> 
> https://github.com/QubesOS/qubes-issues/issues/3585
> 
> BTW that's exactly the kind of main issue that ought to be listed in the
> qubes community project: not ready for official inclusion in qubes-doc,
> but helpful to probably many users.
> 
> 
> > 
> > 1) Go to the rpm-repository from Qubes 3.2
> > https://ftp.qubes-os.org/repo/yum/r3.2/current-testing/dom0/fc23/rpm/
> > 
> > 2) Download qubes-windows-tools-3.2.2-3.x86_64.rpm in an 
> > 
> > https://ftp.qubes-os.org/repo/yum/r3.2/current-testing/dom0/fc23/rpm/qubes-windows-tools-3.2.2-3.x86_64.rpm
> > 
> > 3) move the rpm file to dom0, run in dom0
> > qvm-run --pass-io  'cat
> > /home/user/Download/qubes-windows-tools-3.2.2-3.x86_64.rpm' >
> > qubes-windows-tools-3.2.2-3.x86_64.rpm
> > 
> > 4) Verify rpm package
> > rpm -K qubes-windows-tools-3.2.2-3.x86_64.rpm
> > it would be better to verify the signature i the AppVM, but you need to
> > import the Qubes Signing Key to do so, I was lazy and was fine with moving
> > the rpm-file to dom0 and verify the signature there.
> > 
> > 5) Install rpm-package
> > rpm -ivh qubes-windows-tools-3.2.2-3.x86_64.rpm
> > 
> > 6) the Qubes Windows Tools ISO will be located at
> > /usr/lib/qubes/qubes-windows-tools.iso
> >this will be a link to the latest version installed, thereof to:
> >/usr/lib/qubes/ubes-windows-tools-3.2.2.3.iso in this case
> > 
> > [799]
> >

That's a good point, I'll try see if I can promote your github post on Qubes 
Community to help increase awareness of 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/056fc3d2-ae8a-4306-9ac4-e00f46e6ab96%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: Qubes OS 4.0-rc5 has been released!

2018-03-11 Thread Yuraeitha
On Sunday, March 11, 2018 at 6:30:58 PM UTC+1, Dave wrote:
> I just used System Tools, Qubes Manager UPDATE (down arrow) for DOM0 and each 
> template without keying terminal commands. It appears to have worked, so I 
> assume that RC4 already included testing repo

yeah, if it's anything like it was back in Qubes 3.2. (I'd assume so), then 
these updates in the Qube Manager are stable updates. Once current-testing 
updates are deemed tested and stable after testers tried them out, they 
eventually migrate to stable repository. That's when you see them in the Qube 
Manager (or via normal update commands, not the current-testing ones). 

So I assume they must have been moved from testing to stable now? 

-- 
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/7211e67e-4483-43f8-a238-6d705749d47f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: Launching speed of disposable VMs 15-18sec

2018-03-10 Thread Yuraeitha
On Saturday, March 10, 2018 at 8:21:02 AM UTC+1, hopkins...@gmail.com wrote:
> >32 GB RAM.  launch times (~15-19 sec)
> 
> This was the reason why i left Qubes OS. I cant coupe with hours starting 
> vm-s. 3.2 version were faster.

well not really slow, you might just have had a bad setup and slow hardware. I 
don't think it's fair to blame Qubes for that though, you make it sound like 
it's their fault that you're on slow hardware with a bad version/settings 
layout. But maybe that's not your intention though. 

I also hope you realize that "lots, and lots of RAM" doesn't just automatically 
equal fast start-ups, your specific cherry picking of quote in relation to your 
words, seem to imply just that.

Also why were you on Qubes if you didn't care about security? Leaving Qubes for 
something minor like this, seems to point that you don't care about security. 
So what made you come to Qubes in the first place?

Not to be a butthead or anything, I just think your rash comment is uncalled 
for.

-- 
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/e9d6e650-7541-47a6-93e7-340238117b9b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: Qubes OS 4.0-rc5 has been released!

2018-03-10 Thread Yuraeitha
On Friday, March 9, 2018 at 10:36:49 PM UTC+1, contact...@gmail.com wrote:
> Thx for the great description and tips. I think I updated everything. Is 
> there a way to check if  rc5 is active? 
> 
> One other thing:
> When my system booted. TOR is connected but I get an gui error message from 
> sys-whonix:
> 
> System clock check result
> Unexpected result by timedatectl
> Timedatectl_output_pretty:
> 
> Local time and universal time are the same 
> RTC time: n/a
> Time zone: etc/utc ( utc, +)
> NTP enabled: yes
> NTP sychronized: no
> Rtc in local TZ: no
> DST active: N/A
> 
> Does someone has the same Issue?

I improved the update commands a bit after looking a bit around.

dom0
sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing --clean
(or --check-only instead for dom0).

fedora
sudo dnf update --enablerepo=qubes-vm-*-current-testing --refresh

debian/whonix
sudo apt-get update -t *-testing && sudo apt-get dist-upgrade -t *-testing

This way, you don't need to edit any files for debian/whonix to get the testing.
If you also want to increase reliability further, you can make a 
dependency/cache check with "sudo apt-get check", which is normally very quick. 
For that do;

debian/whonix
sudo apt-get check && sudo apt-get update -t *-testing && sudo apt-get 
dist-upgrade -t *-testing


It may be possible to further optimize the update commands, if anyone got 
suggestions, please feel free to opt-in so that we can recommend better update 
approaches in the future.

-- 
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/e5e9cd36-dc6a-499e-8f3f-46533a1b3aa1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: Issues with Yubikey 4 input

2018-03-09 Thread Yuraeitha
On Saturday, March 10, 2018 at 3:05:09 AM UTC+1, Jon R. wrote:
> 1.  Find a free USB controller.  I didn't want to use the same one as my
>  keyboard or mouse.  Your board specs and the lsusb utility are your 
> friends in the hunt.  Check out the Qubes document "Assigning Devices to
>  VMs" for the gory details of discovering the PCI device assignments to 
> your USB controllers.
> 
> 2.  In the VM you plan to use the key, you'll want to assign the PCI 
> device for your free hub to that VM.  That's accomplished by firing up 
> Qube settings for the VM and selecting the devices tab.  Scroll down to 
> the available device and move it to the selected box.
> 
> 3.  You might have to configure strict reset (or disable strict reset) for 
> the USB controller.
> 
> 4.  Start the VM.
> 
> 
> 
> One gotcha:  the VM won't run in PVH mode once you make this 
> assignment.  But, my Yubikey lights up when Gmail or Facebook need the 
> second factor, and it works as advertised.
> 
> 
> 
> 
> It
>  looks like when in the sys-usb Qube the Yubikey works as intended. When
>  attaching it to another Qube it's listed under lsusb properly and 
> lights up accordingly however when using it there is no output (to 
> stdout / wherever). I'm not quite sure how to debug this further so if 
> someone could shed some light in that regard that'd be great.
> 
> 
> In the interim I'll use a solution similar to yours and just juggle the USB 
> controller to different Qubes as needed (ick!).
> 
> 
> Thanks for the information!
> 
> 
> 
> 
> On Fri, Mar 9, 2018 at 4:13 PM, William Bormann  wrote:
> I have a FIDO U2F Yubico Security Key that I use for authentication to Gmail 
> and Facebook.  In my situation, I decided to use a single VM for two factor 
> authentication.  Here's what I did:
> 
> 
> 
> 1.  Find a free USB controller.  I didn't want to use the same one as my 
> keyboard or mouse.  Your board specs and the lsusb utility are your friends 
> in the hunt.  Check out the Qubes document "Assigning Devices to VMs" for the 
> gory details of discovering the PCI device assignments to your USB 
> controllers.
> 
> 2.  In the VM you plan to use the key, you'll want to assign the PCI device 
> for your free hub to that VM.  That's accomplished by firing up Qube settings 
> for the VM and selecting the devices tab.  Scroll down to the available 
> device and move it to the selected box.
> 
> 3.  You might have to configure strict reset (or disable strict reset) for 
> the USB controller.
> 
> 4.  Start the VM.
> 
> 
> 
> One gotcha:  the VM won't run in PVH mode once you make this assignment.  
> But, my Yubikey lights up when Gmail or Facebook need the second factor, and 
> it works as advertised.
> 
> 
> 
> 
> 
> On Friday, March 9, 2018 at 12:34:06 PM UTC-5, Jon R. wrote:
> 
> > Hello,
> 
> >
> 
> > I've scoured around the mailing lists / SO / Reddit and haven't come across 
> > a solution to this yet. I'm running 4.0 (R4.0) and when I attempt to use my 
> > Yubikey it's seemingly not picking up any input on the button press.
> 
> >
> 
> > It's detecting the USB properly and I can attach it fine:
> 
> >
> 
> > [cloe@dom0 Desktop]$ qvm-usb
> 
> > BACKEND:DEVID  DESCRIPTION USED BY
> 
> > sys-usb:2-1    Yubico_Yubikey_4_OTP+CCID
> 
> >
> 
> > [cloe@dom0 Desktop]$ qvm-usb attach work sys-usb:2-1
> 
> >
> 
> > [cloe@dom0 Desktop]$ qvm-usb
> 
> > BACKEND:DEVID  DESCRIPTION USED BY
> 
> > sys-usb:2-1    Yubico_Yubikey_4_OTP+CCID   work
> 
> >
> 
> > However upon button presses on the Yubikey in the "work" domain there is no 
> > action. I've tested this in gedit, the terminal and elsewhere to no avail.
> 
> >
> 
> >
> 
> > Can someone point me in the right direction as to what may be happening? 
> > I've successfully attached storage devices and other smart card related 
> > devices without any issue so it seems to be isolated to the Yubikey itself. 
> > I've tried 2 separate Yubikey 4's and an older version to no avail.
> 
> >
> 
> >
> 
> > Thank you for your time.
> 
> >
> 
> >
> 
> > - Cody
> 
> 
> 
> --
> 
> 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...@googlegroups.com.
> 
> To post to this group, send email to qubes...@googlegroups.com.
> 
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/qubes-users/7e00edc7-3c2a-462e-98c6-443dd1af7d36%40googlegroups.com.
> 
> For more options, visit https://groups.google.com/d/optout.

I believe it could possibly be a qvm-usb bug, there appears to be some of those 
lately which needs fixing, so it might just be a question of waiting. If you 
want to speed that up, then you can do a search on github to double-check for 
existing open/closed issues, if there are none already posted for this issue, 

Re: [qubes-users] Re: not yet working -> fedora-26-based (minimal) sys-usb with Qubes 4rc5

2018-03-09 Thread Yuraeitha
On Saturday, March 10, 2018 at 3:22:27 AM UTC+1, [ 799 ] wrote:
> Am 10.03.2018 2:09 vorm. schrieb "Yuraeitha" <yura...@gmail.com>:
> 
> 
> Any chance it could be because of the missing qubes-input-proxy-sender? It's 
> hiding in the horizontal slider in the doc link you linked, it's very east to 
> miss it so its understandable.
> 
> 
> 
> There is no package 'qubes-input-proxy-sender' for fedora-26 based VMs in 
> Qubes 4rc5.
> 
> 
> There is package 'qubes-usb-proxy' which I installed already before.
> 
> 
> [799]

how odd. I'm not sure why, but I can find it in my fedora-26 template, but I 
don't have any current minimal template to test it on on this particular 
machine. Here is my output;

[user@fedora-26 ~]$ sudo dnf search qubes-input*
Last metadata expiration check: 
== Name Matched: qubes-input* ==
qubes-input-proxy-sender.x86_64 : Simple input device proxy (sender)
[user@fedora-26 ~]$ 

-- 
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/de0bfc70-29b6-4b66-b17e-1c7e8ada26d6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: not yet working -> fedora-26-based (minimal) sys-usb with Qubes 4rc5

2018-03-09 Thread Yuraeitha
On Saturday, March 10, 2018 at 1:49:27 AM UTC+1, [ 799 ] wrote:
> Hello,
> 
> I'd like to rebuild my sys-net/-firewall/-usb VMs based on a fedora minimal 
> template instead of a full template.
> While sys-net and sys-firewall seem to work with my new template (named: 
> t-sys) I can't get sys-usb to work.
> 
> 
> I followed the info page on the Qubes Doc:
> https://www.qubes-os.org/doc/templates/fedora-minimal/
> 
> 
> 
> Those are steps I've made
> 
> # Install default minimal template in dom0
> sudo qubes-dom0-update qubes-template-fedora-26-minimal
> 
> # Clone template to keep the original template
> qvm-clone fedora-26-minimal t-sys
> 
> # Install additional packages
> qvm-run
>  --auto --user root t-sys "xterm -hold -e 'dnf -y install gnome-terminal
>  terminus-fonts less vim-minimal nano dejavu-sans-fontsl sudo pciutils 
> psmisc gnome-keyring usbutils'"
> 
> # Install specific packages for sys-VMs
> qvm-run
>  --auto --user root t-sys "xterm -hold -e 'dnf -y install 
> qubes-core-agent-qrexec qubes-core-agent-systemd 
> qubes-core-agent-passwordless-root polkit qubes-core-agent-nautilus 
> qubes-core-agent-networking qubes-core-agent-network-manager 
> network-manager-applet  notification-daemon  qubes-core-agent-dom0-updates 
> qubes-usb-proxy  pulseaudio-qubes NetworkManager NetworkManager-wifi 
> NetworkManager-wwan'"
> 
> # Install missing firmware
> qvm-run --auto --user root t-sys "xterm -hold -e 'dnf -y install 
> linux-firmware iwl7260-firmware'"
> # Shutdown template VM
> qvm-shutdown --wait t-sys
> 
> # shutdown everything and change template in your sys-VMs
> qvm-kill sys-net && qvm-kill sys-firewall
> qvm-shutdown -all
> qvm-prefs --set sys-net template t-sys
> qvm-prefs --set sys-firewall template t-sys
> qvm-prefs --set sys-usb template t-sys
> 
> 
> While sys-net and sys-firewall seem to work, the sys-usb-VM seem to miss 
> something as my mouse will not work, which it is when using the default 
> fedore-26 template.
> 
> What am I missing?
> Is there any reason, why the sys-VMs doesn't come based on a fedora-minimal 
> installation?
> 
> 
> [799]

any chance it could be because of the missing qubes-input-proxy-sender? It's 
hiding in the horizontal slider in the doc link you linked, it's very east to 
miss it so its understandable.

-- 
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/92d8864f-50bd-4e88-8eb0-38c3021ee1a9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Launching speed of disposable VMs 15-18sec

2018-03-09 Thread Yuraeitha
@Mirrorway
On Saturday, March 10, 2018 at 1:48:12 AM UTC+1, MirrorWay wrote:
> Unlike regular dispvms, the lifetime of a named dispVMs is not tied to an 
> app, you have to shutdown manually. Like regular dispvms, named dispVMs 
> forget all changes to private storage after shutdown.
> 
> 
> 
> To create a named dispVM called "disp-untrusted" that is based on the 
> "untrusted" VM:
> 
> $ qvm-prefs untrusted template_for_dispvms True
> 
> $ qvm-create --class DispVM --template untrusted -l red disp-untrusted
> 
> 
> 
> Your new named dispvm doesn't appear in the menu, so you'll need to rely on 
> CLI to manipulate it:
> 
> $ qubes-vm-settings disp-untrusted
> 
> $ qvm-run disp-untrusted firefox
> 
> $ qvm-shutdown disp-untrusted
> 
> 
> 
> At this point you can verify that changes to /home DO NOT persist. You can 
> also make sys-net, sys-usb disposable.
> 
> 
> 
> marmarek has some more posts about this.
> 
> 
> 
> I personally think this feature should be better advertised (e.g. added to 
> Create Qubes VM).

Agreed, there is sometimes some very interesting information/use-cases 
about/for Qubes, which is either lost in long detailed guides as a quick 
remark, or not documented at all. It's understandable that the developers are 
busy though, but it'd be interesting if we one day can get these interesting 
use-cases of Qubes highlighted more.

-- 
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/2526e793-2b6d-43c5-995a-b04e369230db%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Launching speed of disposable VMs 15-18sec

2018-03-09 Thread Yuraeitha
On Saturday, March 10, 2018 at 1:49:55 AM UTC+1, Unman wrote:
> On Sat, Mar 10, 2018 at 01:21:22AM +0100, 799 wrote:
> > Hello,
> > 
> > Am 10.03.2018 1:10 vorm. schrieb "'MirrorWay' via qubes-users" <
> > qubes-users@googlegroups.com>:
> > 
> > You can reduce the start time to almost zero by using an already-running,
> > named DIspVM, see marmarek's post in https://github.com/QubesOS/
> > qubes-issues/issues/2801.
> > 
> > 
> > That sounds very interesting.
> > I have looked at the link, but didn't figure out what to do, to get faster
> > DispVM boot up times.
> > What do I need to do?
> > 
> > 
> > You can set a cron job that ensures they shutdown at least once per day.
> > 
> > 
> > Why? The DispVM should be shutdown after I close the window.
> > 
> > [799]
> > 
> No, it wont be - what Marek suggests is creating a qubes with a
> disposableVM as its template. Then you can start this, and open term or
> firefox in it straight away. But that qube stays running until you
> actually close it.
> 
> Just qvm-create a qube with a dvm as the template.

the speed people reply around here is indeed scary sometimes, I didn't even 
chance to try correct my self after realizing I had read it all wrong before 
you posted a few seconds before me ^^; but I appreciate the explanation, it 
does make more sense now by reading your interpretation. I didn't catch the use 
of a dispVM as a template. That does however seem very fascinating.

-- 
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/bbe7277d-8ce0-475b-8f5d-87da1c9f19d7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Launching speed of disposable VMs 15-18sec

2018-03-09 Thread Yuraeitha
On Saturday, March 10, 2018 at 1:21:25 AM UTC+1, [ 799 ] wrote:
> Hello,
> 
> 
> 
> Am 10.03.2018 1:10 vorm. schrieb "'MirrorWay' via qubes-users" 
> :
> 
> You can reduce the start time to almost zero by using an already-running, 
> named DIspVM, see marmarek's post in 
> https://github.com/QubesOS/qubes-issues/issues/2801.
> 
> 
> 
> 
> That sounds very interesting.
> I have looked at the link, but didn't figure out what to do, to get faster 
> DispVM boot up times.
> What do I need to do?
> 
> 
> 
> 
> 
> 
> 
> You can set a cron job that ensures they shutdown at least once per day.
> 
> 
> 
> Why? The DispVM should be shutdown after I close the window.
> 
> 
> [799]

or maybe I should go catch some sleep, I completely miss-read the savefile 
thing in Marek's post. It seems the savefile is what actually generates the 
long bootup's of dispVM's, contrary to what I thought at first. So by not using 
a pagefile, it becomes faster. But Qubes 4 doesn't even use page-files it 
seems. 

Qubestion then is, what is it that is lacking development/manpower. I'm too 
tired to think about that right now though, I just need to correct my mistake 
here at least.

-- 
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/8fefd731-873b-4007-a61f-61e454ec2a04%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Launching speed of disposable VMs 15-18sec

2018-03-09 Thread Yuraeitha
On Saturday, March 10, 2018 at 1:21:25 AM UTC+1, [ 799 ] wrote:
> Hello,
> 
> 
> 
> Am 10.03.2018 1:10 vorm. schrieb "'MirrorWay' via qubes-users" 
> :
> 
> You can reduce the start time to almost zero by using an already-running, 
> named DIspVM, see marmarek's post in 
> https://github.com/QubesOS/qubes-issues/issues/2801.
> 
> 
> 
> 
> That sounds very interesting.
> I have looked at the link, but didn't figure out what to do, to get faster 
> DispVM boot up times.
> What do I need to do?
> 
> 
> 
> 
> 
> 
> 
> You can set a cron job that ensures they shutdown at least once per day.
> 
> 
> 
> Why? The DispVM should be shutdown after I close the window.
> 
> 
> [799]

nice CPU/virt_mode/memory benchmarks! That was a really interesting read.

btw I think what Mirrorway meant is if it automatically shutting down are to 
make up for down-time, for example if you don't use dispVM's for a full day or 
longer, then it'll shutdown on it's own and start again. Thereby, I believe, 
you prevent any potential internet based attacks by reloading fresh and clean 
system-files from the template. It seems like a pretty cool idea, it automates 
everything even if not using the computer for a period of time. Maybe make it 
more frequent, say once every 3 or 6 hours?

btw I found this too just now
https://github.com/QubesOS/qubes-issues/issues/2253

It seems even if the dispVM is shutdown, it can be made much faster too with a 
savefile. But if I understood it right, as Marek write in the first post they 
lack the manpower to get a savefile working for Qubes 4. But Qubes 3.2. has 
one, as it can be seen in Marek's time comparison in his second post.

but whoa, in Qubes 3.2. a savefile makes a difference from 25,5 seconds to 4 
seconds, on this particular hardware. Considering this is a completely shutdown 
dispVM, that is some pretty impressive speed differences. 

I wonder what would happen on Qubes 4 with PVH mode, savefile enabled, powerful 
CPU with a really fast NVMe SSD and RAM, all cores assigned but one which is 
kept in dom0, just how fast would it be then? In theory it should be less than 
4 seconds at least if Marek's number on Qubes 3.2. can be seen as a maximum 
here for hardware, which is hardware that right now isn't the fastest 
available. What speeds would be possible here? Once a savefile is made for 
Qubes 4, this could probably be possible.

-- 
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/32d92eb2-f5a2-4c62-a931-713fd227d78c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: Launching speed of disposable VMs 15-18sec

2018-03-09 Thread Yuraeitha
On Friday, March 9, 2018 at 11:11:09 PM UTC+1, [ 799 ] wrote:
> Hello, 
> 
> 
> I am just wondering if there is a way to speed up the start of disposable VMs.
> On my W540 with an Intel Core i7-4900MQ with 4 Cores @ 2.8GHz / 32 GB RAM / 
> 512GB SSD and having only sys-net / sys-firewall running the first boot of a 
> disposable VM takes 18sec, later starts take 15sec.
> 
> 
> There is not much difference compared to my less powerful X230.
> 
> 
> Are these normal launch times (~15sec) for a DispVM?
> What could be done to accelerate this to get below 10sec?
> 
> 
> [799]

I did a benchmark comparison (not overly accurate, but it might give some 
pointers). 

Your CPU 9061 rating. Single Thread Rating: 2084. Margin for error: Low.
No of Cores: 4 (2 logical cores per physical).
https://www.cpubenchmark.net/cpu.php?cpu=Intel+Core+i7-4900MQ+%40+2.80GHz
15 seconds to open dispVM.

My CPU 2820 rating, Single Thread Rating: 1051. Margin for error: Low.
No of Cores: 2 (2 logical cores per physical).
https://www.cpubenchmark.net/cpu.php?cpu=Intel+Core+M-5Y10c+%40+0.80GHz=2464
33,49 seconds to open picture in dispVM.

So I got one real core, and one logical core to run my AppVM's, while you 
essentially have double up, 2 cores, 2 logical (unless you modified default 
Qubes CPU core layout to AppVM's of course).

If you notice the value rating pr. core, yours is rated 2048, while mine is 
rated 1051. That's a roughly double up difference in performance.

What I wonder about, what would happen if you assigned the 3'rd 
physical+logical core to your AppVM usecases, while preserving the last 1 
physical+logical core in dom0? Would it give you 75% performance in AppVM's 
instead of just 50% performance?

I have no idea if this is even possible to do in Qubes without breaking Qubes, 
but I believe it should be possible though, question is probably if it is a 
good idea to do that? But at least performance wise, dom0 doesn't need all that 
much juice.

-- 
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/5229786c-2a24-4f25-ae43-4de9b9cc4f5c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: Launching speed of disposable VMs 15-18sec

2018-03-09 Thread Yuraeitha
On Friday, March 9, 2018 at 11:11:09 PM UTC+1, [ 799 ] wrote:
> Hello, 
> 
> 
> I am just wondering if there is a way to speed up the start of disposable VMs.
> On my W540 with an Intel Core i7-4900MQ with 4 Cores @ 2.8GHz / 32 GB RAM / 
> 512GB SSD and having only sys-net / sys-firewall running the first boot of a 
> disposable VM takes 18sec, later starts take 15sec.
> 
> 
> There is not much difference compared to my less powerful X230.
> 
> 
> Are these normal launch times (~15sec) for a DispVM?
> What could be done to accelerate this to get below 10sec?
> 
> 
> [799]

For comparison, it took me 33,49 seconds (stopwatch), on my Intel M-5Y10c @ 
800Mhz processor, SSD, 8GB RAM, to open a picture in a dispVM. There was 
sufficient RAM free to open the dispVM unrestricted. It looks like if enough 
RAM is available, that it might be depending on CPU speed? But it could also be 
SSD speed (yours is a SATA SSD right? not a NVMe one?), but such a big 
difference between two non-NVMe doesn't seem right, so it's probably the CPU 
making a difference here. Question is though, is the CPU still the bottleneck 
once at current-day available high-speed CPU's? I.e. what point does SSD's or 
RAM speed become the bottleneck to opening up dispVM's fast?

So there must be two approaches?
- Faster CPU
- Semi-pre-loaded dispVM's (I believe I saw a topic to pre-loaded dispVM's with 
a similar headline in Qubes mail-list or github, once a very long time ago. 
Maybe it can be found again).

I suppose picking between PV/HVM/PVH might make a difference too? If I 
understand it right, PVH is the fastest one atm?

-- 
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/61d01e1b-06a6-4ab6-9f23-ae2328ecdf87%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: Qubes OS 4.0-rc5 has been released!

2018-03-09 Thread Yuraeitha
On Friday, March 9, 2018 at 10:55:16 PM UTC+1, awokd wrote:
> On Fri, March 9, 2018 9:50 pm, Yuraeitha wrote:
> > On Friday, March 9, 2018 at 10:36:49 PM UTC+1, contact...@gmail.com
> > wrote:
> >
> >> Thx for the great description and tips. I think I updated everything.
> >> Is there a way to check if  rc5 is active?
> >>
> >>
> >> One other thing:
> >> When my system booted. TOR is connected but I get an gui error message
> >> from sys-whonix:
> >>
> >> System clock check result
> >> Unexpected result by timedatectl
> >> Timedatectl_output_pretty:
> >>
> >>
> >> Local time and universal time are the same
> >> RTC time: n/a
> >> Time zone: etc/utc ( utc, +)
> >> NTP enabled: yes
> >> NTP sychronized: no
> >> Rtc in local TZ: no
> >> DST active: N/A
> >>
> >>
> >> Does someone has the same Issue?
> >>
> >
> > Your welcome :)
> >
> >
> > I have exactly that issue whonix as well, but it's the first time I've
> > seen others having it. I haven't checked if it's on github yet though,
> > but so far we both have it.
> 
> It is in qubes-issues. Will be fixed with Whonix 14, which should be out
> soon.

That's good news, gonna have to keep track on when those new whonix updates are 
released then. Thanks awokd :)

-- 
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/b2cc8721-0a02-4b42-b386-c99449e94947%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: Qubes OS 4.0-rc5 has been released!

2018-03-09 Thread Yuraeitha
On Friday, March 9, 2018 at 10:36:49 PM UTC+1, contact...@gmail.com wrote:
> Thx for the great description and tips. I think I updated everything. Is 
> there a way to check if  rc5 is active? 
> 
> One other thing:
> When my system booted. TOR is connected but I get an gui error message from 
> sys-whonix:
> 
> System clock check result
> Unexpected result by timedatectl
> Timedatectl_output_pretty:
> 
> Local time and universal time are the same 
> RTC time: n/a
> Time zone: etc/utc ( utc, +)
> NTP enabled: yes
> NTP sychronized: no
> Rtc in local TZ: no
> DST active: N/A
> 
> Does someone has the same Issue?

Your welcome :)

I have exactly that issue whonix as well, but it's the first time I've seen 
others having it. I haven't checked if it's on github yet though, but so far we 
both have it. 

Also it seems some people have a graphical minor issue in the Qubes widget, 
where the update wheel for upstart/shutdown keeps spinning, and the log links 
stop working too. It doesn't seem to impact performance, but it can be a bit 
annoying having to use qvm-shutdown in dom0 to shutdown a VM properly, rather 
than pressing the kill command that appears in the widget bug. Well it works 
normally it seems, it's just a bit annoying bug. I think I've seen 4-5 people 
who is on RC-5 having it now, and it's also reported on github.

about checking if you're on RC-5, if you noticed during the update process 
which repository the updates came from (i.e. from current-testing in fedora 
updates), then you will know it pulled down the current-testing updates.

I'm not sure about a way to confirm it more directly though, that's actually an 
interesting question, I'd like to find a solution for that one as well.

-- 
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/11aaa455-028b-4b67-bb91-b1fdee28ca76%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: Qubes 4.0-rc5 Some issues

2018-03-09 Thread Yuraeitha
On Friday, March 9, 2018 at 5:15:00 PM UTC+1, Evastar wrote:
> Sorry, send to Unman private. I use web interface now, because all my 
> previous emails close IMAP support : 
> 
> 
> 
>  Repost to group: 
> 
> 
> 
> Qubes Reinstalled. 
> 
> I can confirm that at the first step user always lose access to mouse in case 
> of sys-usb created, but not running. 
> 
> 
> 
> 
> 
> About not syncing template & dom0. No, it's not the reason, because right now 
> rc5 does not have any dom0 updates at all. 
> 
> 
> 
> 
> 
> Right now, after fresh install  I can update fedora-26 (done). But still not 
> seeing my attached disk at nautilus. 
> 
> I check it with fdisk -l at untrasted when it's attached:
> 
> 
> 
> Device Boot  StartEndSectors   Size Id Type
> 
> 
> /dev/xvdi1  1936269394 3772285809 1836016416 875.5G 4f QNX4.x 3rd 
> part
> 
> 
> /dev/xvdi2  1917848077 2462285169  544437093 259.6G 73 unknown
> 
> 
> /dev/xvdi3  1818575915 2362751050  544175136 259.5G 2b unknown
> 
> 
> /dev/xvdi4  2844524554 2844579527  54974  26.9M 61 SpeedStor
> 
> 
> 
> Partition 1 does not start on physical sector boundary. (RED COLOR)
> 
> 
> Partition 2 does not start on physical sector boundary. (RED COLOR)
> 
> 
> Partition 3 does not start on physical sector boundary. (RED COLOR)
> 
> 
> Partition 4 does not start on physical sector boundary. (RED COLOR)
> 
> 
> Partition table entries are not in disk order.
> 
> 
> 
> 
> 
> But disk is 3 Tb ! : (at the header from report)
> Disk /dev/xvdi: 2.7 TiB, 3000457232384 bytes,
> 
> 
> Disklabel type: dos
> 
> And it's one disk without 875.5G parts
> 
> 
> 
>  
> 
> Why the system can not mount it? :(
> 
> 
> 
> 
> 
> The second question.
> 
>  You wrote that old qubes version templates does not
>  supported. Is it related also to Windows Tools? I have 
> Windows template and want to restore it and use it... 
> 
> 
> 
> 
> 
> Thanks
> 
> 
> 
> About Qubes Manager. Really, I do not know how to use the system without
>  full list of all VMs with some advanced sorting, searching features. 
> Actually, I'm searching it, sorting it by status and use "Run" menu to 
> run gnome-terminal or some other application (90% of time), another 5% 
> use case of Qubes Manager is checking updates and change settings of VM 
> that I found at list. It's UX. I do not know how you want go forward 
> without this... Some functions can be reduced, but stay without it? Do 
> not know how...
> 
> ---
> p.s. Disk described before attached and unattached well (but not 
> mounted). It's NTFS disk as I remember.

Yes old Windows standalone should work, but you might need to tweak it a bit. 
It must be running in HVM mode (Not PV or PVH mode). Also I'm not sure if this 
got fixed, but dyanmic Memory disabled, and give it some decent amount of RAM 
to run in stable, i.e. 4GB RAM or so. It seems putting the Windows page file 
(like Linux SWAP) to a fixed size instead of dynamic, prevents crashes or 
minimizes crashes. The Qubes tools from Qubes 3.2. more or less "roughly" works 
in Qubes 4 as well, but it's not all perfect. For example you need to prevent 
the Qubes network windows service from running (disable it comnpletely), 
restart the Windows VM, and then put a fixed IP address back to Qubes. This 
restores your internet access. From there, there are other minor issues, but 
it's generally usable. Test it a bit to see if keeps being stable.

Another suggestion about the mounting issue, might be that the drive was 
formated in a special way. For example it might require special mount flags to 
be added, or maybe the Linux NTFS driver just can't read this type of NTFS 
variant, which seems to happen sometimes by the looks of older threads in other 
Linux distro's on the search engine. Try find another NTFS drive, if the other 
NTFS works, then it's probably the special NTFS format that is messing it up. 
To which you may have found your answer, but from there you need new solutions. 
I.e. how to fix that, and questions arrise, like moving files/backup files, and 
reformat the drive? etc. 

About the Qubes Manager (renamed Qube Manager in Qubes 4 btw), it's okay if you 
use it, I'm not going to try tell you otherwise. All I do is raise perspectives 
to think about. For example, one perspective here is that I got so many AppVM's 
and templates at this point, that it'd be completely bungos for me to have any 
sort of list, because no matter how I sort it, it'd be a mess. Yet I manage 
these AppVM's just fine too without the Qube Manager. I use the new Qubes 4 
widget tool to keep watch on which AppVM's is currently running, and to shut 
one of them down (albeit the current widget bug makes it a bit hard, but it's a 
very new bug, it'll be fixed at some point son hopefully, otherwise we can't 
close our AppVM's normally without opening a terminal every time to do it). I 
use a handful of 7 XFCE4 Launcher plugins, and put all my browsers in one 
launcher, coloured and 

[qubes-users] Re: Qubes os resolution issue

2018-03-09 Thread Yuraeitha
On Friday, March 9, 2018 at 9:28:33 PM UTC+1, sevas wrote:
> May I suggest installing the KDE5 desktop? 
> 
> In kali, I know that there is an options menu to change the zoom or something.
> 
> Its at the very bottom of the settings menu in Kali KDE desktop.

Is KDE confirmed working for Qubes 4 yet? The lack of mention of Qubes 4 in the 
KDE quide makes me a bit nervous, https://www.qubes-os.org/doc/kde/ but perhaps 
I don't need to be.

Though for example, does the KDE environment have the Qubes 4 widget and Qubes 
4 qvm-usb/qvm-block widget? 

-- 
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/eb36942e-10b7-4d20-bd90-24c98f68fe69%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: Qubes OS 4.0-rc5 has been released!

2018-03-09 Thread Yuraeitha
On Friday, March 9, 2018 at 9:14:43 PM UTC+1, contact...@gmail.com wrote:
> Can me someone explain which commands in which VM i have to use? I used the 
> following ones but i'm not sure if they are right.
> 
> In dom0: sudo qubes-dom0-update --enable=qubes*testing
> 
> In Template Fedora-26: sudo dnf -y update && sudo dnf -y upgrade 
> --enablerepo=qubes-vm-*-current-testing
> 
> In Template Debian-9: apt update && apt dist-upgrade
> 
> What about the --refresh flags. Where i have to put them? 
> 
> Thx

Don't use the --clean flag too often, but currently I'm not sure how --refresh 
works in dom0. If you didn't update within 48 hours previously, then you can 
ignore the use of --clean and --refresh altogether. Debian/Whonix doesn't need 
them. This should work if you updated recently;

sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing --clean
sudo dnf update --enablerepo=qubes-vm-*-current-testing --refresh

You don't need to use upgrade for fedora, check
https://forums.fedoraforum.org/showthread.php?313135-newbie-quot-dnf-update-quot-or-quot-dnf-upgrade-quot

Since I unfortunately don't know how to include repositories in apt commands, I 
can only tell you the bit longer way to do it. For all debian/Whonix VM's, you 
need to edit this file /etc/apt/sources.list.d/qubes-*.list I haven't found a 
way to just add it temporary in the command itself, so if you only need to 
temporarily access the current-testing, then you need to edit the files back 
again afterwards. For debian-9 it should be on the 6th line, the 
'stretch-testing main' repository. I believe whonix is still on jessie, instead 
of stretch. Once you edited the file and removed the # blocking 
'stretch-testing main', just update debian/whonix like you normally would. 
Debian/Whonix should also do the refresh correctly, I believe, so doesn't need 
a flag. Someone please correct me if I'm wrong about that.

After editing the debian/whonix files, run
sudo apt-get update && sudo apt-get dist-upgrade

Remember to revert back the edited files afterwards if you plan not to use 
current-testing repositories onwards, i.e. if you only want to upgrade to RC-5 
and stop current-testing repository updates after that.

Be careful by using the -y flag, if by some chance the cache or --refresh 
doesn't work, errors appear in the update but it still continues, or something 
along to that, then it may be worth it to keep watch during the update. 
Although maybe I'm just being too careful. 

-- 
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/3fcd4d35-0817-4517-8b26-022ad5bb8dce%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: Qubes os resolution issue

2018-03-09 Thread Yuraeitha
On Friday, March 9, 2018 at 6:56:25 PM UTC+1, randal...@gmail.com wrote:
> Hi there so I was finally able to get qubes installed to test if it actually 
> runs on my laptop (Razer stealth 2017) and there's some issue with the 
> display resolution. My resolution is 3200 x 1800 and that's fine, but when I 
> log into qubes everything looks extremely small and hard to read. I assume 
> it's because of how high the resolution is. how can I get the desktop to 
> display a bigger gui while keeping the resolution the same? I need baby 
> tutorials as I'm new to qubes. Thanks in advance!

This solution below only partly solves your issue as a temporary solution until 
you find a way to scale everything up (which is often a pain in other Linux's 
as well these days, even MS-Windows are facing issues these days...).
You can merge the idea awokd linked, to put it into autostart. 

Since Qubes/XFCE4 doesn't remember the resolution or other screen settings, you 
can use the below to fix it yourself. In addition it also gives you greater 
screen control beyond just "fixing it".

Below is the script I use my self when I connect my puny little tablet/laptop 
to my 4k TV. It obviously hates running dual-screen 4k (poor little thing), so 
I had to lower that resolution. I got two scripts, one for left and right too. 
Which makes it easy for me to change which side of the TV I put my 
tablet/laptop.

#!/bin/sh
xrandr --output HDMI1 --mode 1920x1080 --right-of eDP1

For example if your screen is named ur-screens-name, and it's only one screen 
you want to change settings for, then it should be something like this.

#!/bin/sh
xrandr --output ur-screens-name --mode 1920x1080 

Test if the command works first, in dom0 terminal.
You can find your screen name by writing 'xrandr -q' in your dom0 terminal. 
It'll list all screens currently connected, plus all their possible resolutions 
and refresh rates, which is also information you will need (don't copy my 
resolution, find one compatible in your list out-put here).

Now all you need to remember is to put the command in a script file, i.e. use 
nano or another editor to create the script, and remember to allow script to 
executable chmod +x /path/to/your-script.sh

Once it is tested working, now type 'xfce4-session-settings' and click on the 
"Application Autostart" tab in the window that popups. Click add, and add your 
script to autostart. 

Now every time you boot up Qubes, dom0 will change your settings to the 
specified ones you gave it in the command. Furthermore you can keybind it in a 
similar way.

Type 'xfce4-keyboard-settings' in dom0, and click on the "Application 
Shortcuts" tab in the window that popups. Now same as before, simply click add, 
put path to your script, and add a keybind.

If you just need permanent changes, then the first is enough. If you need to 
change it once in a while, i.e. switch between resolutions, or move second 
screen to the left or right, change refresh rates, and things like that, then 
turn the script into a keybind. You can have multiple of scripts like this.

It doesn't solve the primary issue, but it's also something I need to look into 
my self when I find the time to play around with Linux/Qubes screen scaling. At 
least this can work as a temporary solution though.

-- 
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/787978a9-96c3-4e61-bd9a-213f1a404f83%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up

2018-03-09 Thread Yuraeitha
On Friday, March 9, 2018 at 7:24:43 PM UTC+1, [ 799 ] wrote:
> Hello,
> 
> 
> 
> Am 09.03.2018 7:18 nachm. schrieb "Yuraeitha" <yura...@gmail.com>:
> 
>  
> 
> Apologies, we decided to shorten the name a bit, the collaboration is in the 
> sub-title now instead. It can be found here https://github.com/Qubes-Community
> 
> 
> Ok, I can the site but I don't know where to go from there. Let's say I would 
> like to share my qvm-screenshot-2-clipboard script, where should I put it?
> 
> 
> Should I create a fork and then create a new directory put the files in etc?
> Maybe the first contribution could be to create a "Hello World" example?
> 
> 
> [799]

Found the reason why you couldn't see any people on there. 

- The github organization hides all members by default, so if people join, they 
are hidden members. 

- Once a member, you can see the other members as well.

- Everyone can decide for themselves and change between private/public listing 
of membership in their organization account settings <--- found in peoople tab 
--> click on your own name --> change it on the left side panel.

- Currently we're 4 members total. I changed mine to public, so there should be 
minimum one person listing public, if none others have done it at the time of 
this reading. 

- It seems the github code can be changed so that everyone shows as public as 
default, but it remains a question if that should be done or not.

-- 
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/2d18ff7b-c233-42b9-ab08-daa6848df8ab%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up

2018-03-09 Thread Yuraeitha
On Friday, March 9, 2018 at 7:24:43 PM UTC+1, [ 799 ] wrote:
> Hello,
> 
> 
> 
> Am 09.03.2018 7:18 nachm. schrieb "Yuraeitha" <yura...@gmail.com>:
> 
>  
> 
> Apologies, we decided to shorten the name a bit, the collaboration is in the 
> sub-title now instead. It can be found here https://github.com/Qubes-Community
> 
> 
> Ok, I can the site but I don't know where to go from there. Let's say I would 
> like to share my qvm-screenshot-2-clipboard script, where should I put it?
> 
> 
> Should I create a fork and then create a new directory put the files in etc?
> Maybe the first contribution could be to create a "Hello World" example?
> 
> 
> [799]

If intention is ownership transfer, then I think it's best to wait until this 
project becomes fully established, proved working, and archive redundancy, as 
well as protected from conflicting interests outside the community's goals. 
This might take a while to archive. Until then it might be better to just fork 
everything instead, so ownership stays on your own account. Of course if 
forking is the original intention, then this isn't 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/3e5df224-7b3b-4b5e-8b98-a4a91d792b43%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up

2018-03-09 Thread Yuraeitha
On Friday, March 9, 2018 at 7:24:43 PM UTC+1, [ 799 ] wrote:
> Hello,
> 
> 
> 
> Am 09.03.2018 7:18 nachm. schrieb "Yuraeitha" <yura...@gmail.com>:
> 
>  
> 
> Apologies, we decided to shorten the name a bit, the collaboration is in the 
> sub-title now instead. It can be found here https://github.com/Qubes-Community
> 
> 
> Ok, I can the site but I don't know where to go from there. Let's say I would 
> like to share my qvm-screenshot-2-clipboard script, where should I put it?
> 
> 
> Should I create a fork and then create a new directory put the files in etc?
> Maybe the first contribution could be to create a "Hello World" example?
> 
> 
> [799]

We haven't discussed everything yet, but I believe the idea is to fork if you 
want to preserve the ownership, and transfer ownership if you want the 
Community to own your work. This hasn't been discussed yet, but it should 
probably be considered public domain ownership.

I'm still learning all this my self, there is also the whole licenses and such 
that I need to read up on to properly know how it works.

The initial idea is to have smaller work in the Qubes-Community repository, and 
larger projects in a separate repository. There is also a repository strictly 
for the purposes of forwarding official Qubes docs called Staged-Qubes-docs, it 
will hold nothing else but 'thought qualified' docs for official publishing, 
while the Qubes-Community holds everything from doc's, guide's, scripts, 
wiki's, issue's, etc. All these important repositories are pinned at the top.

If transferring a larger project (a full repository, it either has be forked to 
preserve ownership, or transfers ownership if that is the intention). One of 
the moderators has to accept it to make it appear.

If transferring smaller projects, doc's or scripts, etc. then they should be 
forked or transferred in the Qubes-Community repository. 

Many things are still being worked out, but I think this can be considered 
initial layout.

Also remember I don't decide here, all these are subject to change as we 
discuss it collaboratively :)

-- 
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/1e85ae0a-0f8b-46c1-aa17-23753e9a508d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up

2018-03-09 Thread Yuraeitha
On Friday, March 9, 2018 at 7:12:42 PM UTC+1, [ 799 ] wrote:
> Hello,
> 
> On 03/09 09:01, Yuraeitha wrote:
> > On Friday, March 9, 2018 at 5:58:33 PM UTC+1, Ivan Mitev wrote:
> > > On 03/09/2018 06:42 PM, Yuraeitha wrote:
> > > > I added a repository for Community Discussions, and pinned it at the 
> > > > top. Something like this is good for everyone?
> > > 
> > > https://github.com/Qubes-Community-Collaboration/Community-Discussions/issues/1
> > > 
> > > :)
> > 
> > Awesome, I'll go right there and read/reply :)
> > I also just made this example, doesn't have to be like this, it's just a 
> > layout. https://github.com/orgs/Qubes-Community-Collaboration/teams
> > It allows for team discussions too, as well as allow community members to 
> > find who specialize in what, so that requests can be made. Thoughts?
> 
> I went to the page but couldn't see any public members.
> How can someone become a member?
> I would like to transfer my "Qubes Projects" over to this place.
> 
> [799]

Apologies, we decided to shorten the name a bit, the collaboration is in the 
sub-title now instead. It can be found here https://github.com/Qubes-Community 
Once the name and base structure is agreed on, then changes like this shouldn't 
happen again for the sake of connectivity, like just now, when the link stopped 
working. Can you see it now? :)

-- 
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/f09a4ddd-2974-484e-89e6-a8f3011352fd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: AW: Re: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up

2018-03-09 Thread Yuraeitha
On Friday, March 9, 2018 at 5:58:33 PM UTC+1, Ivan Mitev wrote:
> On 03/09/2018 06:42 PM, Yuraeitha wrote:
> > I added a repository for Community Discussions, and pinned it at the top. 
> > Something like this is good for everyone?
> 
> https://github.com/Qubes-Community-Collaboration/Community-Discussions/issues/1
> 
> :)

Awesome, I'll go right there and read/reply :)

I also just made this example, doesn't have to be like this, it's just a 
layout. https://github.com/orgs/Qubes-Community-Collaboration/teams
It allows for team discussions too, as well as allow community members to find 
who specialize in what, so that requests can be made. Thoughts?

-- 
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/f8d96d17-2b44-4288-bdb3-7650b8673154%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: AW: Re: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up

2018-03-09 Thread Yuraeitha
On Friday, March 9, 2018 at 5:32:48 PM UTC+1, Ivan Mitev wrote:
> On 03/09/2018 05:54 PM, Yuraeitha wrote:
> > The Organization feature of GitHub seems to solve many of our problems, not 
> > all, but many of them. It seems pretty great as a foundation. We won't even 
> > need to make a github list either now, people can just sign up to the 
> > volunteer run GitHub organization, and we can keep a list of all the 
> > decentralized Wiki's or private owned projects there, as well as move 
> > projects/repositories fully into the organization as well. This adds a lot 
> > of great flexibility.
> > 
> > What does everything think about it?
> 
> Agreed, it seems quite flexible. At that point it's not clear how this
> whole effort will take off, so I'd suggest we keep things simple.
> 
> I have a few suggestions for the organization and naming of repositories
> but the thread is already very long. Should we continue the discussion
> in this thread, in a new ML post, or in an issue in one of the repos in
> Qubes-Community-Collaboration ?
> 
> 
> > 
> > Assuming we go on with this organization layout, we could also need a logo 
> > for it, do we have any artists in our midst who want to bring up some logo 
> > design suggestions?

It seems we can make team discussions too for particular projects, this might 
make it less messy if others are not interested in different sub-discussions. 
I'll try set a few examples up we can look at.

-- 
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/0d860618-483f-4a58-90ec-7f98f608f557%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: AW: Re: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up

2018-03-09 Thread Yuraeitha
I added a repository for Community Discussions, and pinned it at the top. 
Something like this is good for everyone?

-- 
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/c62616b0-00a7-482d-9ab8-25c92a4749c8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: AW: Re: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up

2018-03-09 Thread Yuraeitha
The Organization feature of GitHub seems to solve many of our problems, not 
all, but many of them. It seems pretty great as a foundation. We won't even 
need to make a github list either now, people can just sign up to the volunteer 
run GitHub organization, and we can keep a list of all the decentralized Wiki's 
or private owned projects there, as well as move projects/repositories fully 
into the organization as well. This adds a lot of great flexibility.

What does everything think about it?

Assuming we go on with this organization layout, we could also need a logo for 
it, do we have any artists in our midst who want to bring up some logo design 
suggestions?

-- 
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/556a4faa-7d6b-4284-939b-9e91a2d56ca9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: AW: Re: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up

2018-03-09 Thread Yuraeitha
On Friday, March 9, 2018 at 4:04:00 PM UTC+1, Ivan Mitev wrote:
> On 03/09/2018 04:58 PM, Yuraeitha wrote:
> > On Friday, March 9, 2018 at 3:09:31 PM UTC+1, Ivan Mitev wrote:
> >> On 03/09/2018 02:53 PM, Yuraeitha wrote:
> >>>
> >>> Suppose I'll start the first piece of the list to increase the individual 
> >>> github awareness. Where that list is later maintained or kept can be 
> >>> changed as we discuss that later. Please add your github if interested, 
> >>> and copy/paste the list to your own mail response here. Being on this 
> >>> list does nothing except increase awareness of who takes part in the 
> >>> Qubes community guides, there will be no expectations in turn, those who 
> >>> are busy will not become more busy from it unless wishing for it. <--- be 
> >>> warned it might add activity to your github page page though.
> >>>
> >>> It doesn't matter if you prefer to work alone or in collaboration with 
> >>> others. This is also an opportunity to increase awareness of your work. 
> >>> The list strictly only purpose is just that, awareness, while work-style 
> >>> is a separate matter.
> >>>
> >>> Knowing about someone's github account does not justify putting it on the 
> >>> list, please sign up for it so that we don't put anyone on who does not 
> >>> want to be on it. A simple search can show many Qubes OS wiki's, like 
> >>> https://github.com/search?utf8=%E2%9C%93=qubes+os=Wikis however 
> >>> it's not the same as agreeing to be on an awareness/promotional list.
> >>>
> >>> A small description/introduction can be added to the list later, or now 
> >>> if you like to do that. Please keep it short though if you do, i.e 
> >>> Twitter/SMS post size description, slightly bigger than that should be 
> >>> okay though. The idea here is that introduction/descriptions can be 
> >>> updated later.
> >>>
> >>> Copy/paste the list here (ABC) if possible.
> >>> Yuraeitha - https://github.com/Aekez - Right now not much has been done, 
> >>> however QubesTV is starting to take shape. Other repositories are 
> >>> currently work-in-progress.
> >>
> >> * Yuraeitha - https://github.com/Aekez - Right now not much has been done,
> >>  however QubesTV is starting to take shape. Other repositories are
> >>  currently work-in-progress.
> >> * awokd - @awokd - mostly forks of qubes repos, no scripts
> >> * ivan - @taradiddles - qubes-os repo: app popup (increases
> >> productivity) + improving power management (script + deploying TLP)
> >>
> >>
> >> Finally, who will create the public wiki + the repo and assign rights ?
> >> You ? awokd ?
> > 
> > Found this; 
> > 
> > Organizations include:
> > - A free plan with unlimited collaborators on unlimited public repositories
> > - The option to upgrade to paid plans with unlimited private repositories, 
> > sophisticated user authentication and management, 24/5 support, and a 
> > service level agreement for uptime availability
> > - Unlimited membership with a variety of roles that grant different levels 
> > of access to the organization and its data
> > - The ability to give members a range of access permissions to your 
> > organization's repositories
> > - Nested teams that reflect your company or group's structure with 
> > cascading access permissions and mentions
> > - The ability for organization owners to view members' two-factor 
> > authentication (2FA) status
> > - The option to require all organization members to use two-factor 
> > authentication
> > 
> > Source: 
> > https://help.github.com/articles/differences-between-user-and-organization-accounts/
> 
> I was looking at the same stuff:
> 
> https://git-scm.com/book/en/v2/GitHub-Managing-an-organization
> 
> If you're OK, create an organization and then if everything works out in
> the long run you can give the credentials to Andrew (I'm not sure he
> wants to take ownership, at least for now).

Works for me, I'll only keep it for the sake of getting the project running, I 
won't actual own it. I also prefer if a Qubes staff member takes it over, but 
we'll see what happens.

Name changes seems easy too, at least if not too many project links has been 
created. https://help.github.com/articles/renaming-an-organization/
So we can take our time to settle on a name. 

I'll use something default sounding as the initial name, "Qubes Community 
Collaboration". 

Here's the link
https://github.com/Qubes-Community-Collaboration

I invited you both as owners, so you have administration access as well.

-- 
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/02d27b54-e7b2-4544-827c-91cdf149bce8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: AW: Re: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up

2018-03-09 Thread Yuraeitha
On Friday, March 9, 2018 at 3:09:31 PM UTC+1, Ivan Mitev wrote:
> On 03/09/2018 02:53 PM, Yuraeitha wrote:
> > 
> > Suppose I'll start the first piece of the list to increase the individual 
> > github awareness. Where that list is later maintained or kept can be 
> > changed as we discuss that later. Please add your github if interested, and 
> > copy/paste the list to your own mail response here. Being on this list does 
> > nothing except increase awareness of who takes part in the Qubes community 
> > guides, there will be no expectations in turn, those who are busy will not 
> > become more busy from it unless wishing for it. <--- be warned it might add 
> > activity to your github page page though.
> > 
> > It doesn't matter if you prefer to work alone or in collaboration with 
> > others. This is also an opportunity to increase awareness of your work. The 
> > list strictly only purpose is just that, awareness, while work-style is a 
> > separate matter.
> > 
> > Knowing about someone's github account does not justify putting it on the 
> > list, please sign up for it so that we don't put anyone on who does not 
> > want to be on it. A simple search can show many Qubes OS wiki's, like 
> > https://github.com/search?utf8=%E2%9C%93=qubes+os=Wikis however it's 
> > not the same as agreeing to be on an awareness/promotional list.
> > 
> > A small description/introduction can be added to the list later, or now if 
> > you like to do that. Please keep it short though if you do, i.e Twitter/SMS 
> > post size description, slightly bigger than that should be okay though. The 
> > idea here is that introduction/descriptions can be updated later.
> > 
> > Copy/paste the list here (ABC) if possible.
> > Yuraeitha - https://github.com/Aekez - Right now not much has been done, 
> > however QubesTV is starting to take shape. Other repositories are currently 
> > work-in-progress.
> 
> * Yuraeitha - https://github.com/Aekez - Right now not much has been done,
>  however QubesTV is starting to take shape. Other repositories are
>  currently work-in-progress.
> * awokd - @awokd - mostly forks of qubes repos, no scripts
> * ivan - @taradiddles - qubes-os repo: app popup (increases
> productivity) + improving power management (script + deploying TLP)
> 
> 
> Finally, who will create the public wiki + the repo and assign rights ?
> You ? awokd ?

Found this; 

Organizations include:
- A free plan with unlimited collaborators on unlimited public repositories
- The option to upgrade to paid plans with unlimited private repositories, 
sophisticated user authentication and management, 24/5 support, and a service 
level agreement for uptime availability
- Unlimited membership with a variety of roles that grant different levels of 
access to the organization and its data
- The ability to give members a range of access permissions to your 
organization's repositories
- Nested teams that reflect your company or group's structure with cascading 
access permissions and mentions
- The ability for organization owners to view members' two-factor 
authentication (2FA) status
- The option to require all organization members to use two-factor 
authentication

Source: 
https://help.github.com/articles/differences-between-user-and-organization-accounts/

-- 
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/5c76e73f-701f-45d9-9288-6982fa30c8fe%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: AW: Re: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up

2018-03-09 Thread Yuraeitha
On Friday, March 9, 2018 at 3:09:31 PM UTC+1, Ivan Mitev wrote:
> On 03/09/2018 02:53 PM, Yuraeitha wrote:
> > 
> > Suppose I'll start the first piece of the list to increase the individual 
> > github awareness. Where that list is later maintained or kept can be 
> > changed as we discuss that later. Please add your github if interested, and 
> > copy/paste the list to your own mail response here. Being on this list does 
> > nothing except increase awareness of who takes part in the Qubes community 
> > guides, there will be no expectations in turn, those who are busy will not 
> > become more busy from it unless wishing for it. <--- be warned it might add 
> > activity to your github page page though.
> > 
> > It doesn't matter if you prefer to work alone or in collaboration with 
> > others. This is also an opportunity to increase awareness of your work. The 
> > list strictly only purpose is just that, awareness, while work-style is a 
> > separate matter.
> > 
> > Knowing about someone's github account does not justify putting it on the 
> > list, please sign up for it so that we don't put anyone on who does not 
> > want to be on it. A simple search can show many Qubes OS wiki's, like 
> > https://github.com/search?utf8=%E2%9C%93=qubes+os=Wikis however it's 
> > not the same as agreeing to be on an awareness/promotional list.
> > 
> > A small description/introduction can be added to the list later, or now if 
> > you like to do that. Please keep it short though if you do, i.e Twitter/SMS 
> > post size description, slightly bigger than that should be okay though. The 
> > idea here is that introduction/descriptions can be updated later.
> > 
> > Copy/paste the list here (ABC) if possible.
> > Yuraeitha - https://github.com/Aekez - Right now not much has been done, 
> > however QubesTV is starting to take shape. Other repositories are currently 
> > work-in-progress.
> 
> * Yuraeitha - https://github.com/Aekez - Right now not much has been done,
>  however QubesTV is starting to take shape. Other repositories are
>  currently work-in-progress.
> * awokd - @awokd - mostly forks of qubes repos, no scripts
> * ivan - @taradiddles - qubes-os repo: app popup (increases
> productivity) + improving power management (script + deploying TLP)
> 
> 
> Finally, who will create the public wiki + the repo and assign rights ?
> You ? awokd ?

awokd posted same time as I was typing, so I'll edit to cover both responses. I 
agree we should protect this project from going rogue, conflicting interests 
outside the projects set goals, etc. 

Maybe Andrew can take the ownership, assign some of us to have maximum access. 
Then it's kept protected, without the Qubes Staff having to do anything beyond 
assigning new head moderators, which probably will be rare anyway. The head 
moderators can then assign sub-moderators (is that possible on github though?). 
But at the same time it also means the Qubes staff becomes owners, and it's 
uncertain if they want that? I agree it would be ideal from our perspective 
though, but would they want it?

I don't mind putting in the work for this project, I can enjoy it so it won't 
feel like a burden to me to do it, but it's also fine if others want to do it. 
We can probably organize it with a few people together as well. 

What about creating an Organization group on GitHub? the free version, at least 
at first. Quote: "Organization accounts allow your team to plan, build, review, 
and ship software — all while tracking bugs and discussing ideas."

Are there any redundancy in place for such an organization though? For example, 
can split ownership/leadership be made possible/easy on it? If no none knows 
then we can just try make one and experiment with it. It's probably best we 
find a way to secure the community stays healthy.

A GitHub organization also require a name, what should we call 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/e94ae542-72e4-4186-9804-0dfe4040738d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: Qubes 4.0-rc5 Some issues

2018-03-09 Thread Yuraeitha
On Friday, March 9, 2018 at 2:09:23 PM UTC+1, Evastar wrote:
> Something strange is going on. I can not run fedora-26 template terminal. 
> Template is clean 4.0 template, before I only install nano on it. 
> Start/resume also does not work. I get message about "halted". It's also 
> harder to get the real state of app vms& templates, because Qubes Manager is 
> freezen. Now I see fedora-26 with yellow mark. 
> 
> 
> 
> Maybe I must reinstall the whole system and try again or It's too early to 
> migrate from 3.2 :(
> 
> 
> 
> Maybe maybe something with my ssd disk? But guess it fine, maybe filesystem 
> incorrectly work...

There are a few places I suspect causing your start of VM's issues: 

- Did you by any chance backup-restore old templates from Qubes 3.2.? That 
won't work. 
- Your system might have issues with HVM/PVH, maybe try lower it to HVM or PV. 
Qubes 3.2. used PV virt_mode, so PVH/HVM might be what is causing your issues.
- Maybe you forgot to update the templates the same time you updated dom0 (and 
vice versa), keep them in sync with each others at all time. 
- Did you by any chance use the testing repositories? If so, be sure you did so 
on all your templates, including dom0. Never just do it on one or a few, all of 
them must be kept in sync with each others.

It's easier to mess-up the updates sync in Qubes 4, than it was in Qubes 3.2. 
That might possible be changed later to improve that, but for the time being 
it's important you keep tabs on your update method to keep everything in proper 
sync with each others. Also I believe that restoring old Qubes 3.2. templates 
can't be done with the old Qubes codes in them, you need new fresh ones made 
for Qubes 4.

Actually, this whole template/update user mistake issue thing, can also 
possibly explain your qvm-block issues, since the Qubes tools won't be working 
properly then. But it can of course also be a separate issue altogether. Did 
you ensure you made no mistakes with updates across Qubes, restarted Qubes 
fully after Qubes updates, and also did not restore old templates from Qubes 
3.2.?

-- 
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/529883dc-6871-455f-be4b-7cd9bde528d5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: Qubes 4.0-rc5 Some issues

2018-03-09 Thread Yuraeitha
On Friday, March 9, 2018 at 2:09:23 PM UTC+1, Evastar wrote:
> Something strange is going on. I can not run fedora-26 template terminal. 
> Template is clean 4.0 template, before I only install nano on it. 
> Start/resume also does not work. I get message about "halted". It's also 
> harder to get the real state of app vms& templates, because Qubes Manager is 
> freezen. Now I see fedora-26 with yellow mark. 
> 
> 
> 
> Maybe I must reinstall the whole system and try again or It's too early to 
> migrate from 3.2 :(
> 
> 
> 
> Maybe maybe something with my ssd disk? But guess it fine, maybe filesystem 
> incorrectly work...


That eternal spinning circular issue in the Qubes widget should be okay, it's 
known (Qubes-users-mail-list and github) and appears to be only graphical (not 
performance issue). It's also a very new issue. The worst part of it seems to 
be the inability to properly close the VM's. You need to type qvm-shutdown 
vm-name in dom0 for that. Or you can stop it from the VM's own terminal, though 
it takes some time to shutdown that way. 

The Qube Manager was never meant to be used with Qubes 4 onwards, it was only 
brought back because of requests for it, but that doesn't mean they integrated 
the Qube Manager into Qubes 4, it's sort of an "addon" now. It also has issues, 
as unman mentioned up above, it's likely a lower priority to get the Qube 
Manager to work. Also Qubes 4 specific features isn't added to the Qube 
Manager. Furthermore there is the possibility that future Qubes releases won't 
be added to the Qube Manager either (but who knows). One of the known issues 
with the Qube Manager is the status icons for individual VM's don't update. So 
if you opened the Qube Manager while a VM was starting to shutting down, then 
it will appear as if it's yellow status. Try click on it (selecting), or close 
down the Qube Manager and open it again. It changed status, right?

You don't need to use the Qube Manager, it's a relic for old habits. If you get 
get used to it, just stop using the Qube Manager altogether, Qubes 4 was 
originally designed to be without the Qube Manager to begin with. It's just 
about getting used to the shift.

About the remaining issues, it seems a bit odd though. But the above is 
clarified now, so that you don't have to worry about those at least.

-- 
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/58fc1908-aa6b-4e15-9bf0-70b6a325dfc7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: AW: Re: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up

2018-03-09 Thread Yuraeitha

Suppose I'll start the first piece of the list to increase the individual 
github awareness. Where that list is later maintained or kept can be changed as 
we discuss that later. Please add your github if interested, and copy/paste the 
list to your own mail response here. Being on this list does nothing except 
increase awareness of who takes part in the Qubes community guides, there will 
be no expectations in turn, those who are busy will not become more busy from 
it unless wishing for it. <--- be warned it might add activity to your github 
page page though.

It doesn't matter if you prefer to work alone or in collaboration with others. 
This is also an opportunity to increase awareness of your work. The list 
strictly only purpose is just that, awareness, while work-style is a separate 
matter.

Knowing about someone's github account does not justify putting it on the list, 
please sign up for it so that we don't put anyone on who does not want to be on 
it. A simple search can show many Qubes OS wiki's, like 
https://github.com/search?utf8=%E2%9C%93=qubes+os=Wikis however it's not 
the same as agreeing to be on an awareness/promotional list.

A small description/introduction can be added to the list later, or now if you 
like to do that. Please keep it short though if you do, i.e Twitter/SMS post 
size description, slightly bigger than that should be okay though. The idea 
here is that introduction/descriptions can be updated later.

Copy/paste the list here (ABC) if possible.
Yuraeitha - https://github.com/Aekez - Right now not much has been done, 
however QubesTV is starting to take shape. Other repositories are currently 
work-in-progress.

-- 
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/3e86debd-42ec-4d01-b417-53f12dc4577e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Qubes 4.0-rc5 Some issues

2018-03-09 Thread Yuraeitha
On Friday, March 9, 2018 at 2:22:43 AM UTC+1, Andrew David Wong wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> On 2018-03-08 17:20, 'Evastar' via qubes-users wrote:
> > p.s. What is about Qubes Users community on Reddit?
> > 
> 
> I'm afraid I don't understand the question, but does this answer it?
> 
> https://www.reddit.com/r/Qubes/
> 
> - -- 
> Andrew David Wong (Axon)
> Community Manager, Qubes OS
> https://www.qubes-os.org
> 
> -BEGIN PGP SIGNATURE-
> 
> iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAlqh4dQACgkQ203TvDlQ
> MDBO1w//Yg26UTrBVEd6zNykaxiWGcZ6ESEL1GT63nSQJ78Ef4+VqXkosemjAjfX
> YIxoKyO5pfSh54E97+JIwBzKWZHTrbt7G8ySAXOUThvRcVtBNqQOAfOWeY26T42D
> 6PKKygbpupC4a+w2r6NMKyGSI1mDAqXjloKv/McUojYnLSHgJnqea9ZMfWdVjW+y
> iPNEEZ5o7DCYVCxDdJ0V4IGa7vPaxw9LMPCQ+FNGe/AeJRrgPathGMpOsbQ0H8/3
> Brd0MVpjOp38oA6XgDC3cpukr2PKFIqR0Mg9QQXv7liV4XSyVyKYNlYGboevuxvz
> x8ZHjelrLlT04LauAH6fZOUbxUYBYNQBTzFOA4RyuqApQXQmp3S7e9f1gU80kq9I
> 4cyy2WhsDBdVrBTsqtAieFkFGNr1XbKvthIp0uNNENba6h5Mm2tNbHJwVxDpecq+
> mCngbklPbXZDIamfZr/zTNNfk9AUyrzBo785PfVBl4rh1e5PsQBolDdTaqmaDIfd
> 61xL7H8yX+2coYuRxcMcvbAXF5DzwELeCH6pjBl8kzSH4M9weERmVqnFzUHQN9Q8
> /TH9+AiCIgtJyxWXQFWnYsreRj4tjjl7yX0MQu6ZgbI9gIQW1hJn0d6oPd5KobQD
> KcLjiw7/zw4kLhUyY4I1gI4VvTPnu0fVwMnI6Rxeivkpuyb/kx4=
> =TNYp
> -END PGP SIGNATURE-

I believe he means whether it's an official place or an unofficial one. I had 
same confusement when I first started out with Qubes. If a user isn't a 
proponel Reddit user, it might be tricky to realize that Reddit is mainly 
self-organized communities. So it then might become a question for some people 
if Qubes Reddit belongs to The Qubes OS Project or not. While anyone sticking 
around long enough will realize it's not though, but yeah, I'm not really sure 
if this would be considered an issue, but it might confuse new people at least.

-- 
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/74e0dc95-1393-4520-b1aa-cf8c0c2036e0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up

2018-03-09 Thread Yuraeitha
On Friday, March 9, 2018 at 2:42:38 AM UTC+1, Andrew David Wong wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> On 2018-03-08 14:19, Yuraeitha wrote:
> > What we do need confirmation about is how this will officially
> > relate to Qubes OS on the contents that is finished in the Qubes
> > Community doc page though though. Hopefully Andrew can shine some
> > light on that.
> > 
> 
> As explained above, I'm envisioning that the finished output of the
> community system will be a high-quality PR submitted to qubes-doc.
> 
> - -- 
> Andrew David Wong (Axon)
> Community Manager, Qubes OS
> https://www.qubes-os.org
> 
> -BEGIN PGP SIGNATURE-
> 
> iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAlqh5n0ACgkQ203TvDlQ
> MDC2ZhAAwWD28DOy7Or29AWxfxvWU5LFpVjSpGTcwVxOWCbEXqJ2rI+dOEcb/KXj
> Kp+CjIyfpXZGS8Azuv/kCEDYgnLGybkgY04l9N4A5YaDbFpHRZ08SdqtfvOWuesr
> nX+n5dr3bW2pVm1NEoFPUKISy9hpwJT1YoIDXyIvHMwM9+EoLyLpwmz9kPrfdMDG
> Ejev0zyDkX0S11mPrCi5SdJS+Hs/S2i2UP2obmUHIdAx8rbQsdomT1917pJaBz3d
> NOenZCS5gL5120RdhljnzjvaryA7ldkS+ifEz+VAO3+yUvRdudaKu+n1QyAW9bT3
> 8EH0qb9fZlfOH2Xb1n72FCS+OP14NFpctEnh1s+gcBO4ZwPrkeGxlDQ5JxLVi+W+
> qo5zLjiiUa3dFE6QWglO9XeN8zFq9rZso5SE/ziSkIO1xZnobaVwvBTaJeKhD3NH
> bxZhfCDp32kirJf092EfWUY68B3AaMIWWkQMtcMsaJ/wlu2RHCQJbRbzyAM0Hanp
> aWPH1v2jepUsHCAFRvCyFhlf0HBI33/lcZNK033iC8cHghpBzR1v1uaa+fjs48DW
> qcZgdpUIPCR6HczaYqxCgTlVs3TCNfMRcJZwBqJE1EYwri5fqXUGhPqsSfJpw5e/
> jm3A1jH1frsTlfPfBf9/RapitPx2YVrLiKDdRo4ZL6xaisrIFIk=
> =hs8n
> -END PGP SIGNATURE-

Apologies Andrew, I should have put the question more clearly. What I mean is 
if we have two pages, one for Qubes doc's, and another for Qubes Community 
doc's, where will the Community doc's be, in an official sense? I'm fully with 
you regarding the Qubes doc's, what I'm wondering about is the page listing all 
the Community doc's which are not ready to be moved to Qubes doc's yet. Should 
the Community doc page be kept off-site? or is it okay to have it listed (in a 
similar logical sense to current-testing and unstable repositories, just 
unstable and current-testing guides instead).

-- 
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/7ac75934-47d8-4718-ae1d-5c68e84f6f85%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: Best works-out-of-the-box dual-head gfx card?

2018-03-08 Thread Yuraeitha
On Friday, March 9, 2018 at 1:04:53 AM UTC+1, tai...@gmx.com wrote:
> On 03/08/2018 06:24 PM, Yuraeitha wrote:
> 
> > I might ave missed those posts, but the only way I know of right now 
> > that allow discrete graphic cards in Qubes 3.2 and Qubes 4.0 is by 
> > passing it directly into dom0, which is considered a big "no no" in 
> > Qubes security. However Qubes 4.1. might introduce a way to allow a 
> > single AppVM to handle a discreate graphic card without introducing 
> > new security issues. But lets wait and see how it goes, we barely got 
> > Qubes 4.0 out of the door yet right.
> > There is also the possibility that eGPU can work in Qubes 3.2. and Qubes 
> > 4.0 by using high-speed Thunderbolt connections. But for one, this is 
> > expensive, like really, they ask too much for these otherwise simple 
> > external PCI-e card readers running Thunderbolt. Also I have never actually 
> > seen anyone succeed or even try this, it's highly speculative. Considering 
> > if you can pass-through a Thunderbolt port to an AppVM, but not an pci-e 
> > port, then in a nutshell, if drivers etc. work properly for 
> > Thunderbolt/eGPU, you should have high end graphics in Qubes AppVM's.
> >
> > BUT, this is really too expensive. I will not by any means recommend you do 
> > this. Neither would I recommend you hack dom0 and put your graphic cards 
> > directly into dom0. You might be better off just waiting for Qubes 4.1. for 
> > this capability.
> I have used an eGPU via expresscard with an X230 laptop for gaming, you 
> could also buy an T420/430, W520 (32GB RAM), etc.
> 
> It works well and can be attached to a VM if the device supports 
> IOMMU-GFX which these do although I would suggest a workstation for 
> x86_64 gaming (in or out of a VM) such as the libre firmware owner 
> controlled KCMA-D8 ($315) a dual socket mobo supporting crossfire and 
> the 4386 CPU (equiv FX-8310) that can play modern games at high settings.
> 
> If you can't find that the KGPE-D16 ($415) is also a dual socket option 
> which supports up to 32 cores and 192GB RAM, the socket G34 6386SE is 
> the best and last owner controlled x86_64 CPU.

that is quite interesting, so the bandwidth is big enough to handle that over 
expresscard, no big amount of bandwidth is lost? How did you solve the drivers 
here? Were there any complexities by any chance, or did it work like normal?

-- 
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/c0315dc9-dc9e-4ca4-8abb-632677db9f71%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: Best works-out-of-the-box dual-head gfx card?

2018-03-08 Thread Yuraeitha
On Thursday, March 8, 2018 at 11:30:21 PM UTC+1, Stumpy wrote:
> Hi,
> 
> I have seen a few gfx card requests for "qubes compatible" and lots of posts 
> about gfx card issues so I wanted to be sure about my purcahse so I will ask 
> a similar question. I am in the market for a graphics card, or more 
> specifically increasing the number of ports as I am going from 2 -> 4 
> monitors. I figure I am going to need to get a graphics card for this that 
> has a minimum of 2 ports.
> 
> I have read quite a few posts regarding problems with NVIDA and AMD/ATI 
> cards/chipsets, but they seem to be my only option. From the posts I saw it 
> kinda seems that the AMD/ATI works a bit better, thoughts?
> 
> I am hoping those out there who have had “plug in and it just works” 
> experiences with graphics cards can chime in with their recommendations.
> 
> I am also hoping to get something as “future proof” as possible, so it will 
> admittedly be a balance, that said I don’t need bleeding edge either as I am 
> not a gamer and don’t do too much with video (does video encoding count?).
> 
> I must have a minimum of two ports Other preferences are:
> 
> I really really really want something that will work outa the box, not really 
> interested in recompiling the kernel as I have some seriously defunt kernel 
> karma
> DisplayPort would be nice but DVI will be fine
> low profile (hopefully not too wishful of thinking for a 2+ port card), my 
> box is actually pretty small.
> Lots memory I guess?
> Passively cooled would be nice.
> 
> 
> In terms of expansion slots my box has 1 PCI-E X16 Gen2.0 (supports 3.0? not 
> wholly sure about this) and 1PCI-E X4
> Oh, and on this machine I am using 3.2 but will of course upgrade to 4.0 once 
> its final.
> 
> Thanks so much in advance!

Also keep in mind Thunderbolt support in the kernel isn't too great yet, and 
also not too much hardware beyond Apple products support Thunderbolt, although 
they are making a bit bigger appearance on PC's in 2018, but it's still slow. 
Generally, Thunderbolt is still a big headache, with multiple of ways that it 
can fail (although not saying it will fail for certain, just that there is 
plenty of risk).

-- 
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/950fa0d8-aa88-4af4-a6ff-81f092db293c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: Best works-out-of-the-box dual-head gfx card?

2018-03-08 Thread Yuraeitha
On Thursday, March 8, 2018 at 11:30:21 PM UTC+1, Stumpy wrote:
> Hi,
> 
> I have seen a few gfx card requests for "qubes compatible" and lots of posts 
> about gfx card issues so I wanted to be sure about my purcahse so I will ask 
> a similar question. I am in the market for a graphics card, or more 
> specifically increasing the number of ports as I am going from 2 -> 4 
> monitors. I figure I am going to need to get a graphics card for this that 
> has a minimum of 2 ports.
> 
> I have read quite a few posts regarding problems with NVIDA and AMD/ATI 
> cards/chipsets, but they seem to be my only option. From the posts I saw it 
> kinda seems that the AMD/ATI works a bit better, thoughts?
>

I might ave missed those posts, but the only way I know of right now that allow 
discrete graphic cards in Qubes 3.2 and Qubes 4.0 is by passing it directly 
into dom0, which is considered a big "no no" in Qubes security. However Qubes 
4.1. might introduce a way to allow a single AppVM to handle a discreate 
graphic card without introducing new security issues. But lets wait and see how 
it goes, we barely got Qubes 4.0 out of the door yet right.

There is also the possibility that eGPU can work in Qubes 3.2. and Qubes 4.0 by 
using high-speed Thunderbolt connections. But for one, this is expensive, like 
really, they ask too much for these otherwise simple external PCI-e card 
readers running Thunderbolt. Also I have never actually seen anyone succeed or 
even try this, it's highly speculative. Considering if you can pass-through a 
Thunderbolt port to an AppVM, but not an pci-e port, then in a nutshell, if 
drivers etc. work properly for Thunderbolt/eGPU, you should have high end 
graphics in Qubes AppVM's. 

BUT, this is really too expensive. I will not by any means recommend you do 
this. Neither would I recommend you hack dom0 and put your graphic cards 
directly into dom0. You might be better off just waiting for Qubes 4.1. for 
this capability.
 
> I am hoping those out there who have had “plug in and it just works” 
> experiences with graphics cards can chime in with their recommendations.
> 

You really don't need discrete powerful graphic cards for Qubes. Some modern 
integrated ones can even do some pretty amazing graphic feats, and many older 
ones are pretty good too. You can easily run 4k 48" on some couple of years old 
mobile intel CPU's. But of course, some are horrible too. Be sure to check 
reviews and benchmarks. But you're already running Qubes 3.2., so you should 
have a decent idea about this.

> I am also hoping to get something as “future proof” as possible, so it will 
> admittedly be a balance, that said I don’t need bleeding edge either as I am 
> not a gamer and don’t do too much with video (does video encoding count?).
> 

I hear most Linux gavers use GTX 1060 (You might want to double check that, 
google it etc.). HOWEVER, Qubes can't use these cards right now, and it makes 
zero sense to add it to dom0 as VM's use graphic driver translations anyhow, 
which means they can't make full use of the graphic card. Onboard graphics is 
likely just as good on modern hardware. That will likely be different in Qubes 
4.1. for a single AppVM pr. graphic card, but we're still on Qubes 4.0. now.


> I must have a minimum of two ports Other preferences are:
> 
> I really really really want something that will work outa the box, not really 
> interested in recompiling the kernel as I have some seriously defunt kernel 
> karma

Try check https://www.qubes-os.org/hcl/ for people who previously reviewed 
Qubes hardware. Also Intel graphics tend to work the most "out-of-the-box" on 
Qubes. Modern integrated graphics isn't too bad, although keep in mind new AMD 
graphics are in newer intel chips now. While they are nice and powerful, 
support might not be so great "yet", considering it's all new on the market. So 
you might want to stay clear of too new intel chips, in general also anything 
too new or too old hardware.

> DisplayPort would be nice but DVI will be fine

I assume it's a desktop we're looking at here. Should be pretty easy to find a 
motherboard having DVI at least, some probably have Displayport too. Try find 
some in the list, and then check if they got the Displayport/DVI.

> low profile (hopefully not too wishful of thinking for a 2+ port card), my 
> box is actually pretty small.
> Lots memory I guess?

You can get by with 8GB, though 16GB feels much more relaxing.
You could also get ECC ram, though, it's a bit controversial, some find it 
important for data integrity, others don't think it's common enough to be 
considered an issue. Generally, it's a messy discussion. But you might want to 
take your stance there if you should consider a new desktop machine (requires 
motherboard/CPU/UEFI also support ECC memory.

> Passively cooled would be nice.

Well should be doable, but I guess you're referring to the graphic cards here. 
Tbh, don't buy graphic cards now, wait and see if it 

Re: [qubes-users] Re: funny "bug"

2018-03-08 Thread Yuraeitha
On Thursday, March 8, 2018 at 11:37:36 PM UTC+1, haaber wrote:
> > @Bernhard
> > On Wednesday, March 7, 2018 at 9:25:45 PM UTC+1, haaber wrote:
> >> on my Q4rc5 install I get the little black notification "Domain .. is
> >> halting" when I actually start it. I guess this is just a copy-paste
> >> thing inside a script ...  cheees, Bernhard
> > 
> > Did you make a fresh install or was it an upgrade from a previous RC-x 
> > version? This might help solve the issue, or quicker narrow it down.
> > 
> I upgraded form Q4.rc2 on to rc3, rc4, rc5.  If Unman sees it on clean
> rc5, it is not an artefact of old installs.  In any case it is more or
> less just funny, since I am not aware of any negative effect. Bernhard

I can second that, I also don't feel any performance/behavior issues at all 
from it. Well except perhaps shutting down the VM's in question, which can't be 
done like normal without opening the dom0 terminal and write qvm-shutdown 
appVM-name. I highly suspect just killing the AppVM might lead to data 
corruption.

-- 
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/640ee7bc-0452-4f96-af04-a52ccb54e2f2%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: funny "bug"

2018-03-08 Thread Yuraeitha
On Thursday, March 8, 2018 at 10:44:36 PM UTC+1, Unman wrote:
> On Thu, Mar 08, 2018 at 01:32:17PM -0800, Yuraeitha wrote:
> > @Bernhard
> > On Wednesday, March 7, 2018 at 9:25:45 PM UTC+1, haaber wrote:
> > > on my Q4rc5 install I get the little black notification "Domain .. is
> > > halting" when I actually start it. I guess this is just a copy-paste
> > > thing inside a script ...  cheees, Bernhard
> > 
> > Did you make a fresh install or was it an upgrade from a previous RC-x 
> > version? This might help solve the issue, or quicker narrow it down.
> > 
> 
> I can confirm this can be seen on a clean install rc5 - not for every qube, 
> but on
> occasion. I cant see any consistency in it.
> I've raised an issue at github.

ah, this is good to have confirmed, then at least it isn't the upgrade being 
the issue.

btw it might have become a duplicate issue? If following the link in Chris's 
post up 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 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/a66d6b29-d7a9-4b07-bb0d-84b025576b5e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: funny "bug"

2018-03-08 Thread Yuraeitha
@Bernhard
On Wednesday, March 7, 2018 at 9:25:45 PM UTC+1, haaber wrote:
> on my Q4rc5 install I get the little black notification "Domain .. is
> halting" when I actually start it. I guess this is just a copy-paste
> thing inside a script ...  cheees, Bernhard

Did you make a fresh install or was it an upgrade from a previous RC-x version? 
This might help solve the issue, or quicker narrow it down.

-- 
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/076145cb-29dc-4b90-8bdd-18ea128704ac%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up

2018-03-08 Thread Yuraeitha
Perhaps we should form a list in this thread to get started of who is who on 
github, for those interested in this project. It'd probably be fine to start 
working together too without further confirmation from the Qubes staff. What we 
do need confirmation about is how this will officially relate to Qubes OS on 
the contents that is finished in the Qubes Community doc page though though. 
Hopefully Andrew can shine some light on that. But before that, I'm sure it'd 
be fine to start organizing and work together, as long as we don't publish 
anything officially.

Thoughts about collecting an initial unofficial github list, get an overview, 
and start looking at the projects out there, to get started? 

Tbh we're at a stage where we have to hunt down and copy/paste everyones github 
page to a private list at this point in order to keep track. It'd be better if 
everyone wanting to do this can write their github page, i.e. in this thread 
with words that they're into this idea, in a sense signing up for this 
community co-awareness with a github link posted here, so that those not 
interested don't automatically get included.

-- 
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/221df25f-e80f-4401-b6bd-f9675ec6494d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Qubes and Email/PIM (Was: Re: [qubes-users] Re: Security questions (templates and kde)

2018-03-08 Thread Yuraeitha
On Thursday, March 8, 2018 at 7:49:13 PM UTC+1, steve.coleman wrote:
> Glad to hear I'm not the only one paying attention to this particular 
> attack surface. There is nothing like a wide open 24x7 automated attack 
> surface to keep you up at nights wondering what web exploits will be 
> discovered next by the hacker community.  Even with layers of security 
> well before things get to me, I'm still wanting to be extremely diligent 
> with threat mitigation when it comes to unsolicited email.
> 
> On 03/07/18 20:55, 799 wrote:
> 
> > Do you mind writing some more details as I am interested how other 
> > people solve the email problem.
> > Are you really separating email in different AppVMs?
> 
> I only separate attached documents and move them to the respective 
> project VMs. The email itself is coming in from IMAP and I have an 
> elaborate set of macro filters that test the SMTP headers details, 
> validate, flags their state, and process them by moving them off of IMAP 
> and into an offline mail storage location. If it doesn't pass my barrage 
> of sanity tests then I don't even pull it onto my system.
> 
> > Even when you said, that the VM can only connect per SMTP I assume that 
> > you are not separating IMAP (incoming) and SMTP (outgoing) into two two 
> > VMs and then moving emails from the incoming mail VM to the offline mail VM?
> 
> Correct. Everything gets sorted base on work related vs personal 
> interests (eg. Qubes users forum has its own folder) with work/project 
> grouped and lower priority which I read when I can find time.
> 
> > You have one VM which makes both IMAP and SMTP correct?
> 
> Yes. As far as I can see that is the only way other than building some 
> sort of rpc mail proxy to make a distributed VM email system, and that 
> might just widen the attack surface. My email VM does nothing but sort 
> my email and allow me to send outgoing SMTP as well.
> 
> My email VM is denied access to the Internet so any links to malware 
> content will denies rough sites reach-back capability and prevents 
> drive-by malware installs. I don't see icons or web content and I am 
> just fine with that.
> 
> The qubes Thunderbird/DVM integration works nicely for automatically 
> opening any untrusted documents for testing, and if the document needs 
> to be retained I merely copy it to the appropriate VM for processing or 
> archiving.  The base of the email has already been moved off the IMAP 
> server and into file system storage into sorted folders for searching or 
> deletion after processing.
> 
> My goal is to automate the email processing grunt work and apply a 
> defense of security validations even before even copying it onto my 
> machine for processing. I have checks in place that validate which 
> emails came from what place, and test how it was authenticated and 
> passed through the IT infrastructure to get to me. A properly 
> authenticated internal email gets labeled as such.
> 
> If anything is different or suspicious it gets flagged as abnormal and 
> gets a manual inspection to determine the nature of the unexpected 
> "feature" of that email. External incoming PDF/DOC documents that could 
> have embedded macros get flagged as suspicious. It could be phishing or 
> IT changing their processing because of outages, etc. One day I might 
> look at putting in some basic deep-learning AI into the process stream 
> to make it even smarter at detecting processing anomalies such as faked 
> SMTP headers. That's a little too hard for Thunderbird at the moment.
> 
> > Which email/calendar client are you using and how do you move mails to 
> > your  offline email VM?
> 
> I have Thunderbird/IMAP with Lightning for calendar, because it works 
> fairly well for my purposes. I do use Davmail, but only for the calendar 
> side of things. One issue with calendar is I keep getting told that a 
> calendar event had changed and it asks whether to discard or send any 
> way, and that gets annoying. One day I'll take the time to figure out why.
> 
> I like that Thunderbird and the Lightning/calendar invites work 
> together. At one point Thunderbird got an update and lightning stopped 
> working, to the point that Thunderbird deactivated it. That sucked, so I 
> used OWA access for a while and just now realized lightning had been 
> updated so I reinstalled it. That is one problem with my email VM being 
> off-line, in that Thunderbird can't check for updates automatically. 
> That is a catch-22, but I still prefer to keep it this way. The less it 
> can do on the network, more minimal its attack surface.
> 
> > My setup:
> > Dedicated Email VM with Davmail installed. Davmail connects per OWA to 
> > our corporate Microsoft Exchange Server and acts as some kind of gateway 
> > to provide local SMTP/IMAP/CardDAV/CalDAV connections.
> > For emails I am running offlineimap which connects locally to Davmail 
> > and downloads all emails and creates a local maildir-repository.
> 
> > Contacts 

Re: Qubes and Email/PIM (Was: Re: [qubes-users] Re: Security questions (templates and kde)

2018-03-08 Thread Yuraeitha
On Thursday, March 8, 2018 at 2:55:18 AM UTC+1, [ 799 ] wrote:
> Hello,
> 
> 
> 
> Am 06.03.2018 10:04 nachm. schrieb "Steve Coleman" 
> Because the SMTP infrastructure was not designed with compartmentalization in 
> mind, and I only get my one email account to work with, this single "email" 
> VM is highly isolated. It gets its own software locked down configuration and 
> is firewalled with a default-deny network policy. The only services that this 
> VM can get to on the network is the required SMTP services, network 
> authentication, and the necessary  signing key management.  No internal 
> websites, no external sites, only the email App runs here. Well, Ok, the 
> calendar too. Anyway, there should be no "phoning home" from here, other than 
> through per use 2fa outbound email. Should any rouge malware be received, all 
> attachments are first scanned and "tested" in a DVM instance before being 
> separated and pushed across to the appropriate project VM for storage 
> management. All project related historical emails are then migrated to an 
> off-line but searchable storage by project. This specialized email VM 
> essentially sorts, filters, prioritizes, and bins any incoming data/mail for 
> easy processing.
> 
> 
> 
> Do you mind writing some more details as I am interested how other people 
> solve the email problem.
> Are you really separating email in different AppVMs?
> Even when you said, that the VM can only connect per SMTP I assume that you 
> are not separating IMAP (incoming) and SMTP (outgoing) into two two VMs and 
> then moving emails from the incoming mail VM to the offline mail VM?
> You have one VM which makes both IMAP and SMTP correct?
> Which email/calendar client are you using and how do you move mails to your  
> offline email VM?
> 
> 
> My setup:
> Dedicated Email VM with Davmail installed. Davmail connects per OWA to our 
> corporate Microsoft Exchange Server and acts as some kind of gateway to 
> provide local SMTP/IMAP/CardDAV/CalDAV connections.
> For emails I am running offlineimap which connects locally to Davmail and 
> downloads all emails and creates a local maildir-repository.
> Contacts and calendar entries are downloaded via vdirsyncer.
> All content is now locally available in this Email-AppVM and can now also be 
> used offline.
> Within this VM I have setup:
> For plaintext work:
> - neomutt - email client
> - khal - calendar
> - khard - adressbook
> - notmuch - fast search
> 
> 
> And as GUI email clients (connecting to the Davmail gateway / not using the 
> maildir-repository)
> - Evolution
> - Thunderbird
> 
> 
> Unfortunately not everything works with the Davmail Gateway:
> I can see the exchange Calendar in Thunderbird, but not the calendars of my 
> colleques. If I open a calendar entry I get an error.
> On Evolution calendar is working much better as I can open and view the 
> details of an calendar entry, I can create and edit calendar entries - 
> everything is synced per Davmail to our corporate Exchange.
> Strangely I can not delete calendar entries in Evolution.
> 
> 
> With khal I can also view/edit my  calendar entries in the terminal.
> Same for khard with my contacts.
> 
> 
> Todo:
> 1) Check why I can add/edit calendar entries but not delete them
> 
> 
> 2) optimize handling of attachments that PDFs / Office documents / Weblinks 
> are always opened in a DVM.
> I have been able to do this for Thunderbird but not yet for neomutt and 
> Evolution.
> 
> 
> 3) I'd like to integrate email and calendar into emacs org-mode, which I am 
> more and more using for PIM.
> 
> 
> 4) lock down EmailAppVM so that it can only access the Microsoft Exchange 
> Mailserver nothing more.
> I would do so by running IPtables within the VM with a default 
> incoming/outgoing DROP policy only adding what is absolutely necessary to get 
> mail/contacts/calendar working with the Exchange server
> 
> 
> I have also thought about separating email into more AppVMs but the usability 
> trade-off seems to high without gaining that much security.
> As the Email AppVM only is used for email/calendar it should have the same 
> security level like our Exchange Server. If it gets compromise it doesn't 
> make a difference what I have setup in Qubes.
> 
> 
> [799]

I do something similar yeah, although I haven't taken it was far as I'd like to 
yet, and you guys also bring up some interesting fresh ideas as well that I 
will follow up on and read later. 

I currently have 5 different AppVM's for different mail accounts. But 3 of them 
are only checked when I'm actively spending time work related to them, which is 
nice because I don't need to receive those emails when not in that work-mode 
anyway, so I don't get disturbed.

I've been thinking about the one direction firewall systems too, i.e. only 
allow in on one AppVM, and only allow out on another AppVM. But man it's a 
lot of AppVM's to do something like that, especially when I already got 5 
e-mail AppVM's, it'd 

Re: [qubes-users] DNS propagation in Qubes

2018-03-08 Thread Yuraeitha
@David

On Thursday, March 8, 2018 at 7:18:04 PM UTC+1, David Hobach wrote:
> On 03/07/2018 06:40 PM, Unman wrote:
> > On Wed, Mar 07, 2018 at 11:58:21AM -0500, Micah Lee wrote:
> >> I'm trying to make all DNS requests in Qubes go over TLS (more information 
> >> about this [1]).
> >>
> >> I've got this successfully working in sys-net by running a local DNS 
> >> server on udp 53 that forwards DNS requests to a remote DNS server over 
> >> TLS, and then setting my only nameserver in /etc/resolv.conf to 127.0.0.1. 
> >> I've confirmed that this works great in sys-net -- all of my DNS requests 
> >> are encrypted to my remote DNS server, and none are plaintext.
> >>
> >> The problem is when I do this, DNS in other downstream VMs all fail. The 
> >> Qubes networking docs [2] explain how DNS works in Qubes, but I'm confused 
> >> about how to make this set up work. Any ideas? Thanks!
> >>
> >> [1] https://dnsprivacy.org/wiki/
> >> [2] https://www.qubes-os.org/doc/networking/
> >>
> > 
> > In sys-net you have PR-QBS chain in nat table that redirects DNS
> > requests to the network DNS server.
> > 
> > You'll need to remove that chain and replace it with one directing DNS
> > traffic to the local server.
> > You'll also need to open the udp port to inbound traffic.
> 
> If you do that, you'll lose any qubes firewall-based control on DNS 
> traffic though. I.e. all of your downstream VMs will have DNS access.
> 
> Essentially you'll have to implement your own local version of the qubes 
> firewall to achieve qubes-firewall support. I happened to have done that 
> some time ago, but the code quality is not good enough to share it 
> (sorry). nft usage in 4.0 further complicates it from my point of view. 
> You could try to move the forward chain rules to the input chain on 
> every firewall change...
> 
> Maybe qubes will support it one day; here's the feature request: 
> https://github.com/QubesOS/qubes-issues/issues/3051
> I'm not sure why it got tagged as doc though - maybe I didn't see the 
> obvious solution.

We're currently trying to start a Qubes Community doc guide collection at the 
moment, which is thought to be entirely run by volunteers on day-to-day in 
order to help save the Qubes staff time. Nothing official yet though, but here 
one of the ideas being worked on is so you can open up your script to allow 
others to help you finish it and review it. Basically, if this comes to 
fruition, then it allows you to publish unfinished scripts, either to work with 
others and finish it together, or let others takeover if you don't want to 
continue it. Kinda something like that, of course credits should be put like 
always. If this comes to fruition, maybe you can start up a collaboration to 
have people with the right background review it and quality check 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/c20a76d2-dcb5-4e5b-8fbe-7f83510e6e0b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: control boot line in installer?

2018-03-08 Thread Yuraeitha
On Thursday, March 8, 2018 at 4:46:53 PM UTC+1, Nathan Myers wrote:
> On 3/8/18 1:19 AM, Nathan Myers wrote:
> > I am trying to install on an ASUS ZenBook UV501 (Skylake, HD530, NV960M, 
> > NVME SSD). The installer kernel OOPSes because it loads the nouveau 
> > driver module, and gets confused by the bumblebee/optimus hardware 
> > arrangement.
> > 
> > I have installed Debian 9.3 on this machine, and it works if I blacklist 
> > the nouveau module during boot. (I.e. the i915 module needs to load 
> > first.)  But I don't see any way to control the boot line during 
> > installation.  ("E" only shows me a chainloader command line.)
> > 
> > Also, when choosing where to install, the installer seems to offer only 
> > the whole disk, but I have partitions already in place, currently 
> > formatted for swap and ext4, that I would like for the installer to 
> > overwrite.  How do I tell the Qubes installer to use those?
> > 
> > Might the 4.0 beta installer deal better with these details?
> 
> With the 4.0rc5 installer, it never gets to the option to edit the 
> chainloader command line.  It just says X failed, press ENTER, and then 
> nothing when i press ENTER.  The log shows it looping trying to start 
> things. But the kernel is not obviously OOPSing.
> 
> What to try next?

that sounds odd... the boot-loader isn't even loading?
Is it possible to temporarily disable your nvidia graphics card in the 
BIOS/UEFI? It should produce the same results as writing the blacklist. Then if 
that works, you can then later easier blacklist it inside Qubes, reboot, and 
then re-enable your nvidia card in the BIOS/UEFI, and then test if it works.

Also about the full partition thing, I do not mean to scare you or put you off, 
but I recall there was an issue back in fedora-23 that caused changes to other 
partitions despite not telling the installer to do anything to them. It should 
be fixed today? I never personally encountered this bug, but I recall it 
discussed once. Qubes 3.2. installs dom0 with fedora-23, while Qubes 4 installs 
dom0 with fedora-25. At any rate, it might be a good idea to backup first. 
Though, I haven't seen it since, so maybe it's rare, or it's fixed today. But 
that you can't "choose" partition layout editor seems a bit worrying. I'm still 
on lower Qubes 4 release candidates updated to RC-5, I haven't re-installed 
with RC-5 yet though. Maybe it's something specifically in the RC-5 installer? 
Any chance you can try out the RC-4 and RC-3 installers and see if they act 
differently with the partition editor here? If so, then you can just update to 
RC-5 from those if it installs.  

-- 
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/f8fbc80d-cab6-4231-b87c-51d77bbd9077%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: Semi-crosspost to qubes-users. Windows HVM dual-headed use on Qubes R3.2 issues/experiences

2018-03-08 Thread Yuraeitha
On Wednesday, March 7, 2018 at 11:08:50 PM UTC+1, caroline...@gmail.com wrote:
> Hello!
> Just posting into qubes-users to ask if anyone was able to get it to work 
> properly (as two separate windows emulating two separate monitors under 
> windows)
> 
> I was able to do that ALMOST acceptably by doing the steps described here:
> https://github.com/QubesOS/qubes-issues/issues/3480
> 
> But just as the person reporting there I am being thwarted by a nasty "ghost 
> mouse/click" bug.
> 
> Has anyone ever found a workaround for this issue? Is there perhaps a better 
> way to do a dual-head (maybe we could get both "screen-windows" originate 
> from QGA.exe?)
> 
> P.S.: I initially posted about this in qubes-devel in hopes that maybe 
> someone there would know a workaround for this. Posting here in hope that 
> maybe someone also tried to do a dual-head in windows under Qubes and figured 
> out workaround for issue currently plaguing me.

I just noticed that my firefox in a normal fedora qube, when writing in the 
address field, caused the dropdown list of suggestions in the search/address 
field, to appear on the second screen, despite firefox being on the first 
screen. 

Maybe this is a related bug? I have no ways to connect them though, but it 
could potentially be a related issue. So it seems Qubes can't completely follow 
the screen borders? and this might not be a uniquely Windows 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/5082f81f-2de8-498f-b7ad-6174b2f594e0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: WordPress on Qubes

2018-03-08 Thread Yuraeitha
On Thursday, March 8, 2018 at 2:04:26 PM UTC+1, brandonm...@gmail.com wrote:
> Hi all, 
> 
> Thanks so much for your responses.
> 
> So a bit more background as requested I run Qubes 3.2 basically Vagrant 
> allows me to create hyper-vised environments for WordPress to run locally 
> pulling from https//:github.com/Varying-Vagrant-Vagrants/ this creates the 
> server environments etc.
> 
> I then run Variable VV which automates WordPress site creation this can be 
> found here:
> 
> https://github.com/bradp/vv
> 
> I have never been able to get this to work on qubes essentially I want to 
> create a VM where I can hold all my sites locally. Automate WordPress 
> creation and then deploy to a staging or live site.

This should be all down to the Qubes firewall rules. The default firewall is 
essentially acting like a router hardware firewall, blocking all incoming 
signals, unless you yourself initiated it (similar to the general Linux 
firewall as well). So what you need to do is to pass the rules to allow your 
server to get through. But here on forward, nothing is official, you need to be 
careful and thnik carefully in order not to open up new security holes. Ask 
more people who have better insight in Qubes security for second opinions, etc. 

You could quicly test it by making a clone of your server, and try tie it 
directly to your sys-net instead of sys-firewall. This is however very dodgy 
and never do it on something important or something you plan to keep 
afterwards, since it essentially has no firewall in that period of time.

But try make a clone of your Qubes server, and tie the clone to your sys-net, 
are you able to see the server now? Don't let it run too long either, just in 
case it can be used to attack other parts of Qubes (here is where you 
especially need a second opinion of a more knowledgeable person in Qubes 
security). 

If it works, then you now saw first hand that it's sys-firewall blocking you. I 
once did something similar for some Syncthing connections when I first started 
learning Qubes, this made me succesfully open up Syncthing networking without 
changing the sys-firewall rules. Delete your testing clone once you confirmed 
it works. 

Now you need to find out how to do this in a secure way, so that you don't open 
a can of worms down the road. I haven't seen this discussed before, but my 
thoughts are a second firewall here. Otherwise it might just be down to editing 
the existing sys-firewall. For that, you're in luck, there are a very detailed 
guide available for it; https://www.qubes-os.org/doc/firewall/ which also 
covers inter-VM connections, as well as server connections (who different 
things of course).

To me an ideal solution would be a second firewall in Qubes, similar to how DMZ 
isolation zones are made in highly secure networks. So in a way, you'd be 
DMZ'ing Qubes, which I think, would make perfect sense for something you want 
to do here. If you got a server, then that server should be kept under a 
different firewall altogether, albeit still on the same machine/Qubes.

While DMZ'ing Qubes seems to make good sense first, remember, I have never had 
this confirmed anywhere. It's critical you have a second opinion by someone 
skilled in Qubes security before you consider to take my advice here head on.

In practice though, I believe it should work pretty well. It's mostly the 
security thing I'm wondering about. It's been a while I read that long guide in 
the lnik though, maybe they made edits in it to include some of these thoughts? 
I'd have to read it again my self at some point. Maybe you'll find info in 
there to help answer some of these questions.

Also try check this out; https://github.com/Rudd-O/qubes-network-server
You might not need to use any of these installs/tools to cover your needs, but 
it might be a helpful read still to see alternative solutions. 

Remember that second opinion of a skilled security person. That above guide is 
by no means Qubes official either, even though it looks quite interesting I 
gotta admit.

-- 
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/fc3f2f12-6e68-4937-8c98-4af16483eb20%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: R4.0 drops USB data

2018-03-08 Thread Yuraeitha
On Thursday, March 8, 2018 at 4:24:05 AM UTC+1, Glen H wrote:
> Hi,
> 
> I'm using R4 (having never used R3) and trying to get my scanner working but 
> it stops scanning a page half way through.  After debugging with the author 
> of the scanner software they say the program asks for 128 KBytes of data and 
> the first 256 bytes of this data is dropped (lost).
> 
> To fix this I've tried:
> 1) Turning off USB 3.0 in BIOS (unfortunately this isn't really an option as 
> all the external ports are disabled).  It doesn't revert back to USB 2.0
> 2) Set the ports to USB 2.0 via setpci:
> 
> ```
> lspci -nn | grep USB | cut -d '[' -f3 | cut -d ']' -f1 | xargs -I@ setpci -H1 
> -d @ d0.l=0
> ```
> 
> Unfortunately neither of those made a difference.  Using the scanner/software 
> in Windows on a different computer works.
> 
> 
> I'm currently running a Qubes backup and then I'll try installing Ubuntu and 
> see if that works.  If so would seem to be related to Qubes.
> 
> Does anyone have any ideas?  My laptop is a Dell e7440 with the latest BIOS.
> 
> Thanks,
> 
> Glen

oh btw, I recently had a printer issue that might be a bit similar in the 
cause, although different symptoms. I triggered it by using a different method 
to connect to the printer, out of the multiple of addresses IPP/DNS/etc./etc. I 
don't recall which one it was at the time, but one of connecting addresses 
drove my printer absolutely insane, causing it to require pulling the power, 
pull out the ink, and re-insert, wait 4-5 minutes for it to troubleshoot it. 
All this trouble, only because I used a different connection method, exactly 
the same driver too. I could repeat it as well, I went back to it again, and it 
happened again. The moment I used another address, it acted normal. This was on 
Qubes 4 as well, btw. 

So this is also something I'd suggest you try as well, try connect with a 
different address method, see if it can finish the print if you do that.

-- 
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/49af5e77-e972-4ad6-88cc-53e9779694d9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: R4.0 drops USB data

2018-03-08 Thread Yuraeitha
On Thursday, March 8, 2018 at 4:24:05 AM UTC+1, Glen H wrote:
> Hi,
> 
> I'm using R4 (having never used R3) and trying to get my scanner working but 
> it stops scanning a page half way through.  After debugging with the author 
> of the scanner software they say the program asks for 128 KBytes of data and 
> the first 256 bytes of this data is dropped (lost).
> 
> To fix this I've tried:
> 1) Turning off USB 3.0 in BIOS (unfortunately this isn't really an option as 
> all the external ports are disabled).  It doesn't revert back to USB 2.0
> 2) Set the ports to USB 2.0 via setpci:
> 
> ```
> lspci -nn | grep USB | cut -d '[' -f3 | cut -d ']' -f1 | xargs -I@ setpci -H1 
> -d @ d0.l=0
> ```
> 
> Unfortunately neither of those made a difference.  Using the scanner/software 
> in Windows on a different computer works.
> 
> 
> I'm currently running a Qubes backup and then I'll try installing Ubuntu and 
> see if that works.  If so would seem to be related to Qubes.
> 
> Does anyone have any ideas?  My laptop is a Dell e7440 with the latest BIOS.
> 
> Thanks,
> 
> Glen

These informations might give some extra insight;
- Where is your USB controller? dom0? sys-usb? sys-net? somewhere else? 
directly in the AppVM? 
- It might be a bit annoying to do, but you could try install the printer on a 
different template. This would help you troubleshoot if the issue is template 
related or not template related. 
- If you then in addition do as you're already planning to that test it on 
Ubuntu, it also gives better insight. Maybe use Ubuntu live-boot to install the 
printer and test it though? So you can avoid installing it just fro that.

If the printer works in another template, then you know it's a 
debian/fedora/whonix issue. If the printer doesn't work in another template, 
then it's likely not an issue in the templates (unless it's an universal 
kernel/driver or Qubes tools issue of ofc). But if it then works in Ubuntu, 
then you know it isn't a universal Linux/kernel issue. You're then more 
reasonably narrowed it down to potential culprits with some albeit rough, but 
useful estimates.

btw if your USB controller is in dom0, then that already might be an 
explanation as to why it fails. You can also try temporarily pass the USB 
controller directly into an AppVM and test directly printing inside that AppVM 
(or alternatively use qvm-open-in-vm and open the doc in the AppVM that hold's 
the controller, and try print directly from the AppVM instead of using the 
qvm-usb features. This would rule out or rule in a bug in the qvm-usb as well.

If you're up for some testings, then you should be able to narrow it down, 
maybe there are other useful ways to do this too, those mentioned are only the 
ones I could think of on the top of my head in the moment, there might be other 
good ways to narrow it down easily.

-- 
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/227df168-1a6a-492e-a1ec-7c463caed814%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: Qubes 4 rc3 unpacking errors durint installation

2018-03-08 Thread Yuraeitha
On Thursday, March 8, 2018 at 7:21:54 AM UTC+1, randal...@gmail.com wrote:
> Hey bud where you able to find a resolution? With qubes its either you know 
> what your doing or good luck finding an answer let alone even a response 
> back. I have the new raser 2017 and i simply want to test it on a harddrive 
> to get it working properly and i have the same errors you had.

Finding the appropriate information (not too much random info, not too little 
info either) is usually key, because it can be exhausting to try troubleshoot 
another persons computer in almost complete blindness, it usually scares those 
off who would otherwise help. It's not to be rude or anything, but try see it 
from others perspective, can't pull magic, information is absolutely essential 
:)

For example one essential information here, did you try the new RC-5 release 
yet? Same result? Does RC-3 or RC-4 give the same issues? You can update to 
RC-5 all the way from RC-2, though, there might be some issues by doing that, 
but it should be mostly okay as long you don't do it from RC-1 which certainly 
requires a re-install.

Also those bit-old links are dead to me, I get an error 404 page not found on 
both of them. What kind of bug are we talking about here?

-- 
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/139360b4-1c96-4a2e-b8e4-f7a3f88386ce%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: Semi-crosspost to qubes-users. Windows HVM dual-headed use on Qubes R3.2 issues/experiences

2018-03-08 Thread Yuraeitha
On Wednesday, March 7, 2018 at 11:08:50 PM UTC+1, caroline...@gmail.com wrote:
> Hello!
> Just posting into qubes-users to ask if anyone was able to get it to work 
> properly (as two separate windows emulating two separate monitors under 
> windows)
> 
> I was able to do that ALMOST acceptably by doing the steps described here:
> https://github.com/QubesOS/qubes-issues/issues/3480
> 
> But just as the person reporting there I am being thwarted by a nasty "ghost 
> mouse/click" bug.
> 
> Has anyone ever found a workaround for this issue? Is there perhaps a better 
> way to do a dual-head (maybe we could get both "screen-windows" originate 
> from QGA.exe?)
> 
> P.S.: I initially posted about this in qubes-devel in hopes that maybe 
> someone there would know a workaround for this. Posting here in hope that 
> maybe someone also tried to do a dual-head in windows under Qubes and figured 
> out workaround for issue currently plaguing me.

oh, I've never seen this Qubes-win7 ghost bug version before, maybe it's 
because I didn't find time yet to re-install my Win7 and just kept my old Win7 
from Qubes 3.2. for the time being. 

I do encounter another mouse bug though, which you "might" encounter too given 
you mention mouse button issues as well. It makes the left/right mouse buttons 
unresponsive, but that's just that, nothing else happens in this bug, no 
ghosting or odd behaviours, all it does is right/left buttons stop working. If 
you ever encounter it too, then try use the middle-click button, which should 
instantly bring your mouse's left/right buttons back again too (quick easy fix, 
but it can happen up to multiple times a day though).

Chances are the ghost bug is an entirely different bug though, but if you ever 
discover this one, try middle-mouse. If you're on mouse-pad, some have a middle 
button in-between there, despite it not being visible. Perhaps other keys can 
trick it back as well.

Unfortunately I know absolutely nothing about the ghost bug though, I've never 
seen it my self. I suspect it might be the Qubes mouse driver though, maybe it 
can be modified by changing Window's behavior a bit in regedit or something 
akin to that, i.e. maybe some feature needs to be disable/enabled/changed-value 
(it's a possible scenario imho, question is how to find such speculative 
information). 

awokd's hack looks really interesting 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 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/40f7b144-5d28-4557-8bcc-7eb7a0b9995a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: Recommendations for fully compat Wireless/my usb errors

2018-03-08 Thread Yuraeitha
On Thursday, March 8, 2018 at 11:17:14 AM UTC+1, awokd wrote:
> On Thu, March 8, 2018 9:02 am, Yuraeitha wrote:
> > On Thursday, March 8, 2018 at 9:25:12 AM UTC+1, sevas wrote:
> 
> >> After hours and hours of troubleshooting, I realize that that was my
> >> problem. I needed no-strict-reset because of FLR. I have no idea what
> >> FLR is.
> >>
> >>
> >> Bus 001 Device 006: ID 148f:3070 Ralink Technology, Corp. RT2870/RT3070
> >> Wireless Adapter
> 
> >>
> >> Question 1: Should I fix my wireless card with a car or a hammer?
> 
> Go ahead and try the no-strict-reset option.
> 
> >> Question 2: What kind of wireless card should I buy or what should I be
> >> on the lookout for to make sure its compatible with qubes? (long range
> >> for bonus pts!)
> 
> Try looking through the HCL for known good ones, or picking one and
> searching the mailing list for reported problems. There's no HCL for PCI
> devices, but I'm wondering if it might be good to have one.
> 
> >> Question 3: What kind of security am I forfeiting when I use this
> >> frothy no-strict-reset card?
> 
> See the link in the same doc.
> 
> >> Question 4: Is there anything I can do for my card? Heres the error
> >> output:
> 
> #1
> 
> > I think what you need to do here is merge the sys-net with your sys-usb.
> 
> That might also resolve the issue if both controllers are reported as
> being under the same device, but in this case I think trying
> no-strict-reset first is probably worthwhile.

@awokd
Agreed, it's not clear what is causing the issue, trying these suggestions 
definitely could work too.

@sevas
I definitely agree with awokd that you can put the no pci reset, he makes a 
good point here. If you came from a more unsecure OS anyway before you went 
Qubes, and you're not putting your life or well-being on the line, then you can 
probably take bit bigger risks like this one. The exploits through firmware is 
more exotic attacks in this day and age, but that might change in the future if 
they become more commonplace, i.e. by A.I's automatically finding exploits in 
the many, many different firmwares, and turns this from an exotic attack into a 
common and everyday type of attack. Generally though, if you're not putting 
something on the line here, you can afford to make mistakes and learn a bit, 
mistakes are the best learners after all, just as long as you can afford the 
consequences of course. Just keep in mind that it's important that you improve 
these things over time and never just settle, small stepes, rom wasn't build in 
a single day, so too is your Qubes usage going to improve over time as well if 
you keep learning small bits every day. Lax a bit down now on these issues, and 
try find out why and how they work, so you can increase your knowledge of 
security. Try identify the biggest threats first, and keep the lower ones for 
later, prioritizing to maximize your IT security understanding as time goes on.

-- 
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/2a746980-fce6-41e5-948d-a6dd90df00f7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: control boot line in installer?

2018-03-08 Thread Yuraeitha
On Thursday, March 8, 2018 at 7:32:19 AM UTC+1, Nathan Myers wrote:
> I am trying to install on an ASUS ZenBook UV501 (Skylake, HD530, NV960M, 
> NVME SSD). The installer kernel OOPSes because it loads the nouveau 
> driver module, and gets confused by the bumblebee/optimus hardware 
> arrangement.
> 
> I have installed Debian 9.3 on this machine, and it works if I blacklist 
> the nouveau module during boot. (I.e. the i915 module needs to load 
> first.)  But I don't see any way to control the boot line during 
> installation.  ("E" only shows me a chainloader command line.)
> 
> Also, when choosing where to install, the installer seems to offer only 
> the whole disk, but I have partitions already in place, currently 
> formatted for swap and ext4, that I would like for the installer to 
> overwrite.  How do I tell the Qubes installer to use those?
> 
> Might the 4.0 beta installer deal better with these details?
> 
> Thanks,
> 
> Nathan Myers

The Qubes installer equivalent to the "E" key to edit is "Tab" key. The screen 
won't change much, but keep eyes peeled on the bottom of the screen when you 
press the tab key, and you'll notice the boot line appears. The edit icon 
appears at th end of the boot line. Press space key once, and add your commands 
:)

This also had me confused for a while as well, I wonder what advantages there 
is to a different approach in the installer. But once you know this difference, 
you will have similar capabilities as you did with the "E" key Grub version.

-- 
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/12f06dc5-94cc-4ea5-8595-a2ef5035e8d7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: Offtopic Amazon Echo // Re: [qubes-users] Re: High spec laptop for Qubes OS

2018-03-08 Thread Yuraeitha
On Thursday, March 8, 2018 at 3:21:53 AM UTC+1, [ 799 ] wrote:
> Am 07.03.2018 8:08 nachm. schrieb "Yuraeitha" <yura...@gmail.com>:
> (...)
> 
> So who wants a proprietary, backdoored, error-prone, computer in their brain 
> in contrast to open source, open hardware, which can be trusted? Even before 
> all this, some people who didn't care before, are starting to care now when 
> technology is increasingly getting closer to their lives. Like The Amazon 
> Echo, which is always listening to its environment, and now it's happening to 
> TV's and many other gadgets as well. Eventually even toasters can spy on us.
> 
> 
> 
> To be fair:
> The problem is not that it is always listening, as this is only be done to 
> simplify the use as you can say Alexa  without having to wait for 
> until the the echo is ready.
> As soon as it recognized "Alexa" it will use the part afterwards as command.
> 
> 
> More details in the FAQ:
> https://www.amazon.com/gp/help/customer/display.html?nodeId=201602230
> 
> 
> 
> 
> [...] 2. How does Alexa hands-free on my Fire tablet recognize the wake word?
> 
> 
> Alexa on your Fire tablet uses on-device keyword spotting to detect the wake 
> word, even when your device is in standby mode. When the wake word is 
> detected, Alexa on your Fire tablet streams audio to the Cloud, including a 
> fraction of a second of audio before the wake word [...]
> 
> 
> What is much worse:
> In the default configuration it storing every command you have ever said at 
> Amazon. With this data you can create a perfect profile and this shouldn't be 
> enabled by default.
> The regarded voice command should be transferred to the voice recognition 
> server for analysis and the data should then be deleted as there is no 
> technical reason to store it.
> I have doubts that they only do so in order to improve their service by 
> analyzing the voice data to give more accurate results.
> This should be something that is done via opt-in and maybe with a reward:
> "thank you for being completely transparent, you'll get a 10eur Amazon 
> Voucher and a free copy of '1984'".
> 
> 
> I agree that it is dangerous to have such a device at home which doesn't have 
> a hardware kill-switch for the microphone.
> But much worse is what they're already got doing without hiding it from their 
> users.
> I was shocked when a friend showed me his Amazon echo and then said:
> "Here look at the list about every command I have used so far, isn't this 
> cool?" 
> 
> 
> The danger is clearly the user who even agrees and likes this kind of 
> "feature" and the usability of those products is so easy, that everything 
> with adds more security feels complex.
> 
> 
> That's a main motivation for me willing to contribute documentation so that 
> Qubes is easy to use do use, for those who are interested in privacy but are 
> not technical experts / Linux powerusers.
> 
> 
> [799]

definitely scary as hell... the cost to turn to reliable trustworthy 
hardware/software will only get bigger as time go on too, just like global 
warming costs has been building up all these years, and we're now paying a huge 
bill with extra big interests back to un-do the harm. The same could be seen 
with software/hardware too, to some extent, although probably less costly 
(unless people don't realize these companies really are not doing anywhere near 
the best they can to protect us consumers and society...)

Have you seen this btw? https://mycroft.ai/ it's open source altenrative to the 
echo. I've been thinking about implementing it as an offline based voice 
control with QubesTV later on, but it'd be great help if someone can get 
Mycroft up and running in Qubes, before merging projects. If we can offer more 
reliable, offline and secure voice control, then Qubes might remain more 
attractive in the future when keyboards and mouses starts to disappear in 
favour for new modern controls like voice control and similar futuristic but 
close to mainstream tech in the upcoming years. It definitely won't hurt to 
prepare Qubes early for this, and if we as a community can help the developers 
to save some time, then all the better too right.

-- 
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/2b966ad8-a809-4e34-b173-14200a731ff9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: Recommendations for fully compat Wireless/my usb errors

2018-03-08 Thread Yuraeitha
On Thursday, March 8, 2018 at 9:25:12 AM UTC+1, sevas wrote:
> Been looking through the files and google trying to find out how to make my 
> USB wireless card work. I didnt try no-strict-reset or permissive mode 
> because it said something something SECURITY something and so I skipped over 
> it without a second thought. 
> 
> After hours and hours of troubleshooting, I realize that that was my problem. 
> I needed no-strict-reset because of FLR. I have no idea what FLR is. 
> 
> Bus 001 Device 006: ID 148f:3070 Ralink Technology, Corp. RT2870/RT3070 
> Wireless Adapter
> 
> I guess thats my card. One of those RT numbers. 
> 
> Anyway. I have a few questions. 
> 
> Question 1: Should I fix my wireless card with a car or a hammer?
> 
> Question 2: What kind of wireless card should I buy or what should I be on 
> the lookout for to make sure its compatible with qubes? (long range for bonus 
> pts!)
> 
> Question 3: What kind of security am I forfeiting when I use this frothy 
> no-strict-reset card?
> 
> Question 4: Is there anything I can do for my card? Heres the error output:
> 
> I think one of these 1st two sections is the output when the VM is already 
> started and I attach the device and the other is when I start it with the 
> device already attached. Or maybe not. It could the the before and after of 
> dom0$ qvm-prefs -s netvm kernelopts "iommu=soft swiotlb=16384" Who knows 
> Not me, I mean.
> 
> dom0 lvm[923]: Monitoring thin pool qubes_dom0-pool00-tpool.
> dom0 qubesd[9781]: b'  WARNING: Sum of all thin volume sizes (328.68 GiB) 
> exceeds the size of thin pool qubes_dom0/pool00 and the size of whole volume 
> group (166.68 GiB)!\n'
> dom0 dmeventd[923]: No longer monitoring thin pool qubes_dom0-pool00-tpool.
> dom0 lvm[923]: Monitoring thin pool qubes_dom0-pool00-tpool.
> dom0 qubesd[9781]: b'  WARNING: Sum of all thin volume sizes (338.68 GiB) 
> exceeds the size of thin pool qubes_dom0/pool00 and the size of whole volume 
> group (166.68 GiB)!\n'
> dom0 libvirtd[9825]: 2018-03-08 05:27:18.209+: 9861: error : 
> virPCIDeviceReset:1002 : internal error: Unable to reset PCI device 
> :00:14.0: no FLR, PM reset or bus reset available
> dom0 qubesd[9781]: Start failed: internal error: Unable to reset PCI device 
> :00:14.0: no FLR, PM reset or bus reset available
> dom0 dmeventd[923]: No longer monitoring thin pool qubes_dom0-pool00-tpool.
> 
> dom0 lvm[923]: Monitoring thin pool qubes_dom0-pool00-tpool.
> dom0 qubesd[9781]: b'  WARNING: Sum of all thin volume sizes (328.68 GiB) 
> exceeds the size of thin pool qubes_dom0/pool00 and the size of whole volume 
> group (166.68 GiB)!\n'
> dom0 dmeventd[923]: No longer monitoring thin pool qubes_dom0-pool00-tpool.
> dom0 lvm[923]: Monitoring thin pool qubes_dom0-pool00-tpool.
> dom0 qubesd[9781]: b'  WARNING: Sum of all thin volume sizes (338.68 GiB) 
> exceeds the size of thin pool qubes_dom0/pool00 and the size of whole volume 
> group (166.68 GiB)!\n'
> dom0 libvirtd[9825]: 2018-03-08 05:27:18.209+: 9861: error : 
> virPCIDeviceReset:1002 : internal error: Unable to reset PCI device 
> :00:14.0: no FLR, PM reset or bus reset available
> dom0 qubesd[9781]: Start failed: internal error: Unable to reset PCI device 
> :00:14.0: no FLR, PM reset or bus reset available
> dom0 dmeventd[923]: No longer monitoring thin pool qubes_dom0-pool00-tpool.
> 
> 
> This was definitely during attach while VM running:
> ERROR: Devices tab: Got empty response from qubesd. see journalctl in dom0 
> for details.
> followed by:
> dmesg:
> [  122.885838] xhci_hcd :00:14.0: USB bus 2 deregistered
> [  122.889909] xhci_hcd :00:14.0: remove, state 1
> [  122.889917] usb usb1: USB disconnect, device number 1
> [  122.889918] usb 1-5: USB disconnect, device number 2
> [  122.982262] usb 1-6: USB disconnect, device number 3
> [  122.982600] usb 1-7: USB disconnect, device number 4
> [  122.984305] xhci_hcd :00:14.0: USB bus 1 deregistered
> [  122.984842] kauditd_printk_skb: 5 callbacks suppressed
> [  122.984843] audit: type=1130 audit(1520492985.409:136): pid=1 uid=0 
> auid=4294967295 ses=4294967295 msg='unit=systemd-rfkill comm="systemd" 
> exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
> [  122.989660] pciback :00:14.0: seizing device

Definitely never try get usb-modems working if your USB controller is still in 
dom0 though, if you get that working, then you're exposing all of dom0 to the 
internet directly.

-- 
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/bf63c398-ec59-4692-9d96-c45606390bd4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: Recommendations for fully compat Wireless/my usb errors

2018-03-08 Thread Yuraeitha
On Thursday, March 8, 2018 at 9:25:12 AM UTC+1, sevas wrote:
> Been looking through the files and google trying to find out how to make my 
> USB wireless card work. I didnt try no-strict-reset or permissive mode 
> because it said something something SECURITY something and so I skipped over 
> it without a second thought. 
> 
> After hours and hours of troubleshooting, I realize that that was my problem. 
> I needed no-strict-reset because of FLR. I have no idea what FLR is. 
> 
> Bus 001 Device 006: ID 148f:3070 Ralink Technology, Corp. RT2870/RT3070 
> Wireless Adapter
> 
> I guess thats my card. One of those RT numbers. 
> 
> Anyway. I have a few questions. 
> 
> Question 1: Should I fix my wireless card with a car or a hammer?
> 
> Question 2: What kind of wireless card should I buy or what should I be on 
> the lookout for to make sure its compatible with qubes? (long range for bonus 
> pts!)
> 
> Question 3: What kind of security am I forfeiting when I use this frothy 
> no-strict-reset card?
> 
> Question 4: Is there anything I can do for my card? Heres the error output:
> 
> I think one of these 1st two sections is the output when the VM is already 
> started and I attach the device and the other is when I start it with the 
> device already attached. Or maybe not. It could the the before and after of 
> dom0$ qvm-prefs -s netvm kernelopts "iommu=soft swiotlb=16384" Who knows 
> Not me, I mean.
> 
> dom0 lvm[923]: Monitoring thin pool qubes_dom0-pool00-tpool.
> dom0 qubesd[9781]: b'  WARNING: Sum of all thin volume sizes (328.68 GiB) 
> exceeds the size of thin pool qubes_dom0/pool00 and the size of whole volume 
> group (166.68 GiB)!\n'
> dom0 dmeventd[923]: No longer monitoring thin pool qubes_dom0-pool00-tpool.
> dom0 lvm[923]: Monitoring thin pool qubes_dom0-pool00-tpool.
> dom0 qubesd[9781]: b'  WARNING: Sum of all thin volume sizes (338.68 GiB) 
> exceeds the size of thin pool qubes_dom0/pool00 and the size of whole volume 
> group (166.68 GiB)!\n'
> dom0 libvirtd[9825]: 2018-03-08 05:27:18.209+: 9861: error : 
> virPCIDeviceReset:1002 : internal error: Unable to reset PCI device 
> :00:14.0: no FLR, PM reset or bus reset available
> dom0 qubesd[9781]: Start failed: internal error: Unable to reset PCI device 
> :00:14.0: no FLR, PM reset or bus reset available
> dom0 dmeventd[923]: No longer monitoring thin pool qubes_dom0-pool00-tpool.
> 
> dom0 lvm[923]: Monitoring thin pool qubes_dom0-pool00-tpool.
> dom0 qubesd[9781]: b'  WARNING: Sum of all thin volume sizes (328.68 GiB) 
> exceeds the size of thin pool qubes_dom0/pool00 and the size of whole volume 
> group (166.68 GiB)!\n'
> dom0 dmeventd[923]: No longer monitoring thin pool qubes_dom0-pool00-tpool.
> dom0 lvm[923]: Monitoring thin pool qubes_dom0-pool00-tpool.
> dom0 qubesd[9781]: b'  WARNING: Sum of all thin volume sizes (338.68 GiB) 
> exceeds the size of thin pool qubes_dom0/pool00 and the size of whole volume 
> group (166.68 GiB)!\n'
> dom0 libvirtd[9825]: 2018-03-08 05:27:18.209+: 9861: error : 
> virPCIDeviceReset:1002 : internal error: Unable to reset PCI device 
> :00:14.0: no FLR, PM reset or bus reset available
> dom0 qubesd[9781]: Start failed: internal error: Unable to reset PCI device 
> :00:14.0: no FLR, PM reset or bus reset available
> dom0 dmeventd[923]: No longer monitoring thin pool qubes_dom0-pool00-tpool.
> 
> 
> This was definitely during attach while VM running:
> ERROR: Devices tab: Got empty response from qubesd. see journalctl in dom0 
> for details.
> followed by:
> dmesg:
> [  122.885838] xhci_hcd :00:14.0: USB bus 2 deregistered
> [  122.889909] xhci_hcd :00:14.0: remove, state 1
> [  122.889917] usb usb1: USB disconnect, device number 1
> [  122.889918] usb 1-5: USB disconnect, device number 2
> [  122.982262] usb 1-6: USB disconnect, device number 3
> [  122.982600] usb 1-7: USB disconnect, device number 4
> [  122.984305] xhci_hcd :00:14.0: USB bus 1 deregistered
> [  122.984842] kauditd_printk_skb: 5 callbacks suppressed
> [  122.984843] audit: type=1130 audit(1520492985.409:136): pid=1 uid=0 
> auid=4294967295 ses=4294967295 msg='unit=systemd-rfkill comm="systemd" 
> exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'
> [  122.989660] pciback :00:14.0: seizing device

I think what you need to do here is merge the sys-net with your sys-usb. I'm 
not 100% sure since I don't use usb-modems my self on Qubes, but with an USB 
modem, you're probably supposed to keep that USB controller in sys-net AppVM. 
You could also alternatively install the Qubes VM network management tools in 
sys-usb, but that might cause undeeded complexities. It might just be easier to 
move your USB controller to the sys-net AppVM.

If you got multiple USB controllers, then you can keep one USB controller in 
sys-net, and the other(s) in your sys-usb on the safe side of the firewall. 
Unfortunately you'll have to keep at least one USB controller in sys-net, or an 

Re: [qubes-users] R4.0 testing: Widget shows spinners / Kill for running VMs

2018-03-08 Thread Yuraeitha
On Thursday, March 8, 2018 at 4:42:55 AM UTC+1, Chris Laprise wrote:
> On 03/07/2018 10:24 PM, Yuraeitha wrote:
> > On Thursday, March 8, 2018 at 3:53:48 AM UTC+1, Chris Laprise wrote:
> >> On 03/07/2018 09:32 PM, 799 wrote:
> >>> Hello,
> >>>
> >>> Am 08.03.2018 2:01 vorm. schrieb "Chris Laprise" <tas...@posteo.net
> >>> <mailto:tas...@posteo.net>>:
> >>>
> >>>  Having just upgraded dom0 with qubes*testing, I noticed that nearly
> >>>  all of my running VMs are being displayed by the 'Q' widget as if
> >>>  they were in a pre-started or pre-halted state.
> >>>
> >>>
> >>> Wouldn't it makes sense to create one GitHub page for each new release,
> >>> where users can provide a quick feedback when there testing the new 
> >>> release.
> >>> I know it is also possible to raise an issue but it takes more time and
> >>> is not that convenient for users to look at and the list of open topics
> >>> could be placed on the Qubes Website, so that a user has a single
> >>> go-to-place to find out if he wants to take the chance testing out the
> >>> new release.
> >>>
> >>> I am currently reading all posts to make a decision, should I upgrade yet?
> >>> Having a bullet point list on a GitHub page would be nice, maybe later
> >>> referencing to the issue-tracker and deleted as soon the problem is fixed?
> >>> Could also be maintained by the community with a disclaimer (Warning:
> >>> blaba..)
> >>>
> >>> [799]
> >>>
> >>
> >> I'm using the testing repo, not the regular rc5 release. I don't think
> >> this would impact you if you upgraded to rc5.
> >>
> >> -- 
> >>
> >> Chris Laprise, tas...@posteo.net
> >> https://github.com/tasket
> >> https://twitter.com/ttaskett
> >> PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886
> > 
> > Same experience as this? https://github.com/QubesOS/qubes-issues/issues/3660
> > It's from RC-3 to RC-5, maybe as you suggested a pure RC-5 re-install 
> > doesn't have this issue? Albeit this particular bug seems to be a visual 
> > issue, did you find anything else bugging?
> > 
> 
> Thanks for the link. That appears to be it.
> 
> Its a bit more than visual, since my menus choices are adversely 
> affected (i.e. I should have 'Shutdown' available). Maybe this is the 
> kick I need to adapt my keyboard shortcut VM shutdown script.
> 
> -- 
> 
> Chris Laprise, tas...@posteo.net
> https://github.com/tasket
> https://twitter.com/ttaskett
> PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886

Good point, that appears to work. I can shutdown with either "qvm-shutdown" in 
dom0 or "shutdown -h now" in the AppVM. This is a bit off-topic, but it shows 
an interesting perspective though, that it takes a while to shutdown when done 
from within the AppVM. I noticed the same on standalone VM's, such as windows. 
It could be problematic if Windows is shutdown via the widget and it shutsdown 
prematurely, which it seems like it might do after updates? But VM's like 
Windows are not made to handle that? Updates don't process unless shutdown via 
the windows own shutdown commands and give it some patience, by the looks of 
it. It's had me a bit puzzled. But anyway, didn't want to venture off-topic 
here, it just reminded me of this puzzling system VM shutdown behavior that I 
haven't figured out yet.

-- 
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/fad2a055-5cc2-47e0-8176-7828485bd928%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] Re: Qubes OS 4.0-rc5 has been released!

2018-03-08 Thread Yuraeitha
On Thursday, March 8, 2018 at 9:00:33 AM UTC+1, sevas wrote:
> lol My problem was that I didnt read the date on the paper which was 
> yesterday. I had already downloaded and installed it before I realized that 
> it was out. 
> 
> Despite that the article came up on my phone and this post as well came up 24 
> hours later.

ah yes, you had already installed RC-5. But anyway, if others face the same 
problem then check flags/sync update commands across Qubes :)

-- 
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/897e63d8-d4bb-487b-bde2-91f33a750d1a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: Qubes OS 4.0-rc5 has been released!

2018-03-08 Thread Yuraeitha
On Wednesday, March 7, 2018 at 9:21:58 PM UTC+1, sevas wrote:
> Whoo hoo! 
> 
> I went to download qvm-dom0-update and it says no new updates available

This is not an official response in anyway, but here's what I'd suggest to do.

Remember if you recently downloaded updates within 48 hours, then the cache on 
fedora systems (which includes dom0 as far as I know, though I'm still a bit 
unsure about dom0 my self, since it's Qubes specific, so while it works, but 
isn't perfect since it isn't light and cleans up more, I use --clean flag in 
dom0). 

Anyway, you need to use the --refresh flag on fedora templates after the enable 
repository, in order to make it sync the cache list with the server within 48 
hours since last update. If you're beyond the 48 hours since the cache was 
made, then you don't need the --refresh flag. Also as far as I know, debian 
does this automatically, so no action is needed beyond enabling the testing 
repository. 

To sum up;
- Always use the same Qubes repositories across Qubes, be it dom0 or templates, 
it's important to keep them in sync.
- Use --refresh for fedora templates and --clean for dom0, if you updated 
within 48 hours or if you mistakenly only updated some VM''s/dom0 and need to 
update them all again. In which case, use the flags to sync.
- Debian/Whonix require no metadata sync as they do this automatically. But 
remember Debian/Whonix also require the dist-upgrade command in addition to 
update command.

-- 
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/63ba2640-7a63-4a81-a6c8-08088412f17e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up

2018-03-08 Thread Yuraeitha
On Thursday, March 8, 2018 at 7:47:19 AM UTC+1, [ 799 ] wrote:
> Hello Yuraeutha,
> 
> On 03/07 08:59, Yuraeitha wrote:
> 
> > [...]
> > If I interpreted this correctly, my understanding is that it's preferred 
> > that a community like this to have an inviting 
> > GUI platform, so that it can easier gain traction and build up users, and 
> > include more people? i.e. github is not desired 
> > for the central community environment?
> > 
> > Maybe we could beta-run a volunteer run GUI based platform first before you 
> > decide if it should be made official on i.e. 
> > recognized on the Qubes website with a link? testing the waters a bit by 
> > dipping the toe in, before taking a full dive. 
> > [...]
> 
> I won't agree, as content is the most important thing.
> Content first -> presentation later.
> 
> Let's just start with using GitHub and evolve from there.
> What do you think?
> 
> [799]

@[799] & Ivan
The good thing is as Ivan pointed out too, that it seems I misunderstood the 
analogy :) I like the github platform version as well for this community goal, 
though both platforms have their pros and cons of course.

Maybe we could start linking to each others github pages to get an initial 
network up? It's a lot of work to maintain in the long run though, but it could 
help us be aware of one another that way in the beginning? Before we later 
maybe get a page or something somewhere showing all the different channels with 
a brief introduction each? Maybe we can draft a single wiki page somewhere to 
make it more efficient? or wait, maybe we can even fork this with github? A 
master branch where multiple of long-term community users with master access 
can help moderate the github wiki list? Should be possible this way?

-- 
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/fbc1746a-0bd3-48db-a2c2-f408c60a9424%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


Re: AW: Re: [qubes-users] For community by community - A way to preserve/focus everyones work going into Qubes, bottom-up

2018-03-07 Thread Yuraeitha
On Thursday, March 8, 2018 at 3:15:13 AM UTC+1, Andrew David Wong wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> On 2018-03-07 08:48, Yuraeitha wrote:
> > It might be a good idea to have some finished thoughts /
> > discussions ready for Andrew, it'd be inhuman to expect him to read
> > everything (it's a lot to read).
> 
> Thanks. I appreciate that. :)
> 
> > it might be best to start where the least work is needed from the 
> > Qubes staff.
> 
> Yeah. Ideally, we'd like to keep the official qubes-doc PR system the
> way it currently is and have the new system be completely autonomous
> and community-run without any involvement from the Qubes staff. By way
> of analogy, think of the official system as a command-line tool and
> the community system as a user-friendly GUI frontend for that tool.
> People who either don't know how or don't want to use the command-line
> tool (i.e., submit a proper PR to qubes-doc) can instead use the GUI
> (i.e., submit content, ideas, and suggestions in any format, which the
> community then turns into proper PRs).
> 
> - -- 
> Andrew David Wong (Axon)
> Community Manager, Qubes OS
> https://www.qubes-os.org
> 
> -BEGIN PGP SIGNATURE-
> 
> iQIzBAEBCgAdFiEEZQ7rCYX0j3henGH1203TvDlQMDAFAlqgnJcACgkQ203TvDlQ
> MDA1XBAAs8dC9Ue4kwLToYNRWTIpY+se2pn8RCQ8gqfKNgVDPNO7Qb3z7lw8kERF
> KLAktV4HL4NCz8jTJTKh0bMTB2lERytYm6uenx/fYT+fACFRAB7gg7o8D4lE+g7m
> zedYznKQHg9x2Ehi+KfVDtbEHdfagDfOW5SSWixDUyK60ZYXHDivAzZkWytMc8b8
> yZq3hZZsq8GcXAoMpxWOLl9sx5TiVHN+7WVphPEXYe0wCiCwPlwY3hDznzWAFWq2
> 2h+aYjnwRKVkvMAbcxrmfSXK0Bwr+Ccr29vBzzQ/eOgWcXwjt6oShkOoFTPLSvla
> G3JAzm+15r/7KeKItQuuXVQECGJhCqaZVs6DJFsSLAxTsfg449y3i+EFZC7hkOrM
> 3glht/vfSOsFY0LChcTc+99sCZnwN/0Q7weXd/86+nn18Qh3Ce7I77nHA1PaXMt7
> +/IUM+ZB7RY9dTUsdO3Mw2/GDtOohz8Ofmywuc7yhpzLgn+pPX+WP60jKZzRIkcw
> dpvxSzYYGy5Mhc0TyjKTTqRXbZFWCyveOcfLG4r65iEkjN/Fvtr2CGhlcgaDxHN4
> J2+h4dM15AH55PqCRvKuNMfeJP+KTgDBI8X3fo/zN0bHo/bmZjr737MZkr/R+mSO
> veELCoGf0lA4iskF+dUQEsLw73PLBK0dUI7zU8WWLg4CMzJjjG4=
> =IUpz
> -END PGP SIGNATURE-

It would feel bad if causing you trouble rather than helping, I hope we will be 
able to provide help :) I can only speak for my self, but I believe others feel 
the same, feel free to correct us if we're doing something wrong with this 
community project. <-- when I say "us", it is based on my belief, but as said I 
can't speak for everyone. I mean, it would be horrible if we impacted Qubes in 
a way that you guys didn't like, after all the amazing work you guys did with 
Qubes over all these years, you guys essentially poured your souls into this. 
Consider to bring out that whip if something is off!

If I interpreted this correctly, my understanding is that it's preferred that a 
community like this to have an inviting GUI platform, so that it can easier 
gain traction and build up users, and include more people? i.e. github is not 
desired for the central community environment?

Maybe we could beta-run a volunteer run GUI based platform first before you 
decide if it should be made official on i.e. recognized on the Qubes website 
with a link? testing the waters a bit by dipping the toe in, before taking a 
full dive. With only some platform volunteers aware of it at first to test it? 
If it works, then we can always scale it up, or if it should fail, then change 
direction or start-over with a new discussion. Something like that, a beta run 
could be insightful before any final decisions are made.

I hesitate to use the forum word here, perhaps a new fresh discussion is 
warranted as for which platform to use? But if GUI is an important factor to 
include, then a forum might be the most suitable? There will always be some who 
don't like every platform though. But did I understand it correctly that the 
Qubes staff actually likes the idea of a forum, but just doesn't have the 
man-power to run it? i.e. if you had the volunteers, then this is a desired 
platform/direction seen by the Qubes staff to go? Maybe preserving the 
mailing-lists, but integrating a forum where a forum makes sense, and then keep 
the mailing-lists as they are now and have them coexist?

-- 
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/42238610-a1e0-4533-b627-25e2587a49d9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.


  1   2   3   4   5   >