from:"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

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

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.

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?

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

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?

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

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?

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?

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

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)

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)

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

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

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

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?

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?

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?

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?

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?

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?

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

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

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

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?

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

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

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?

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?

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?

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?

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?

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?

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

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!