date:20180125

On Thu, January 25, 2018 10:51 pm, yreb...@riseup.net wrote:

> *by this if I ran sudo qubes-dom0-update
> --enablerepo=qubes-dom0-security-testing*once,  I take it , that
> I am still on  the Stable  Track  "repo"  so somehow  magically  I
> have the current testing Xen version (I checked and do),  but  when the
> security  Xen  goes to Stable ,  they will just be integrated  . so
> currently   I have a  combination of 1 time  security Xen and the rest is
> "current"  (Not testing) ?

Exactly!

-- 
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/07ea481657628bfab2ee108e36be7883.squirrel%40tt3j2x4k5ycaa5zt.onion.
For more options, visit https://groups.google.com/d/optout.

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

2018-01-25 Thread yrebstv

On 2018-01-24 23:20, awokd wrote:
> On Thu, January 25, 2018 2:17 am, yreb...@riseup.net wrote:
>> On 2018-01-24 15:12, Andrew David Wong wrote:
> 
>>>
>>> These packages will migrate from the security-testing repository to the
>>>  current (stable) repository over the next two weeks after being tested
>>>  by the community.
>>
>>
>> 1)
>> The latter (security) packages will migrate, I'd assume this means ?
> 
> Yes, this is the standard model for deploying all updates including
> security. They appear in testing first for bleeding edge users, then
> stable for everyone. Sometimes bugs are found in the testing phase causing
> the package to be pulled, so unless you are comfortable rolling back
> packages yourself you should leave it on stable.
> 
>> 2)
>> Where would I find the repositories in dom0 for the track I'm currently
>> using?
> 
> If you haven't changed it manually, you are on stable.
> 
>> 3)
>> after doing the 1x securitytesting repo update, how do I check which Xen
>> package is now installed?
> 
> In dom0, "dnf list installed".
> 
>> and/or  how do I bring up the  GUI
>> update manager  when it doesn't actually need to update it doesn't persist
> 
> No GUI, but in dom0 you can force it to check for updates with "sudo
> qubes-dom0-update". Might not be following your question here.

Mostly, got it.  Just the one item I'm unsure about.  @URL:
https://www.qubes-os.org/doc/software-update-dom0/

it mentions:
--
To temporarily enable any of these repos, use the
--enablerepo= option. Example commands:

sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing
sudo qubes-dom0-update --enablerepo=qubes-dom0-security-testing
sudo qubes-dom0-update --enablerepo=qubes-dom0-unstable

To enable or disable any of these repos permanently, change the
corresponding boolean in /etc/yum.repos.d/qubes-dom0.repo.
--


*by this if I ran sudo qubes-dom0-update
--enablerepo=qubes-dom0-security-testing*once,  I take it , that
I am still on  the Stable  Track  "repo"  so somehow  magically  I
have the current testing Xen version (I checked and do),  but  when the
security  Xen  goes to Stable ,  they will just be integrated  . so
currently   I have a  combination of 1 time  security Xen and the rest
is  "current"  (Not testing) ?

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

[qubes-users] I am unable to verify my image. Please help?

2018-01-25 Thread Optimal Joy

Hi. New to Qubes, just downloading it, and wish to verify my image.
I have downloaded my images and keys. Also got the master signing key.

user Downloads # wget
https://mirrors.kernel.org/qubes/iso/Qubes-R3.2-x86_64.iso && wget
https://keys.qubes-os.org/keys/qubes-release-3-signing-key.asc && wget
https://mirrors.kernel.org/qubes/iso/Qubes-R3.2-x86_64.iso.asc
...
snip
...

I have these files now in my ~/Downloads directory:

-rw-r--r-- 1 elliot elliot 1.6K Jan 25 11:21 qubes-master-signing-key.asc
-rw-r--r-- 1 root root819 Sep 20 2016 Qubes-R3.2-x86_64.iso.asc
-rw-r--r-- 1 root root 4.0G Sep 20 2016 Qubes-R3.2-x86_64.iso
-rw-r--r-- 1 root root 2.4K Nov 19 2014 qubes-release-3-signing-key.asc

I tried this command earlier to fetch the qubes-master key,
~/Downloads $ gpg2 --fetch-keys
https://keys.qubes-os.org/keys/qubes-master-signing-key.asc
gpg: requesting key from
'https://keys.qubes-os.org/keys/qubes-master-signing-key.asc'
gpg: WARNING: unable to fetch URI
https://keys.qubes-os.org/keys/qubes-master-signing-key.asc: General error

Since it wasn't working, I manually downloaded the file from the Qubes site,
however I am afraid that I only have the file, but have not imported the public
key.

When trying to verify the iso, I get the following error:

Downloads # gpg2 --verify Qubes-R3.2-x86_64.iso.asc Qubes-R3.2-x86_64.iso
gpg: Signature made Tue 20 Sep 2016 10:33:37 AM PDT using RSA key ID 03FA5082
gpg: Can't check signature: No public key

How can I download/get my Public Key manually? Or what could be wrong with my
fetch?

Help, thanks!

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

[qubes-users] Re: Please help with custom template build

2018-01-25 Thread Krišjānis Gross

On Tuesday, 23 January 2018 17:36:00 UTC, Krišjānis Gross  wrote:
> Hi, 
> 
> I am trying to build a custom installation .iso. I have an issue that I have 
> purchased a new set of hardware that does not work with the current builds of 
> qubes. I am trying to build the most updated version with hope that it could 
> work. 
> 
> I am running a Fedora linux and trying to build with these instructions: 
> https://www.qubes-os.org/doc/building-archlinux-template/
> 
> I use the ./setup to create the installation configuration. 
> 
> make install-deps goes fine.
> make get-sources goes smooth as well
> 
> but I get an error when running the mage qubes command.
> Here is what I get:
> 
> [krish@localhost qubes-builder]$ make qubes
> Currently installed dependencies:
> git-2.14.3-2.fc27.x86_64
> rpmdevtools-8.10-3.fc27.noarch
> rpm-build-4.14.0-2.fc27.x86_64
> createrepo-0.10.3-12.fc27.noarch
> debootstrap-1.0.92-1.fc27.noarch
> dpkg-dev-1.18.24-3.fc27.noarch
> python2-sh-1.12.14-2.fc27.noarch
> dialog-1.3-10.20170509.fc27.x86_64
> dpkg-dev-1.18.24-3.fc27.noarch
> debootstrap-1.0.92-1.fc27.noarch
> PyYAML-3.12-5.fc27.x86_64
> make[1]: Entering directory '/home/krish/qubes-builder'
> -> Preparing fc25 build environment
> -> Initializing RPM database...
> -> Retreiving core RPM packages...
> -> Verifying signatures...
> Filename: 
> /home/krish/qubes-builder/cache/fc25/base_rpms/acl-2.2.52-13.fc25.x86_64.rpm 
> is not signed.  Exiting!
> make[1]: *** 
> [/home/krish/qubes-builder/qubes-src/builder-fedora/Makefile.fedora:86: 
> /home/krish/qubes-builder/chroot-fc25/home/user/.prepared_base] Error 1
> make[1]: Leaving directory '/home/krish/qubes-builder'
> make: *** [Makefile:224: vmm-xen-dom0] Error 1
> 
> 
> Does anyone has an idea of what I do wrong or how to resolve this? 
> I have attached the builder.conf file that I have.

Like in installing Fedora 25 on the system and perform the build procedure on 
that? 
Will give it a try. Thank You for advice!

-- 
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/5929b0fe-f056-48a6-9678-5ddeedd82c14%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Installation error: need at least 3mb more on /boot/efi

2018-01-25 Thread darklampz

Thanks for the lenghty response! Indeed the errors were python-code related, 
but it turns out the problem was in the sys-net domain not starting correctly 
because of the card reader, which was seemingly seen as a network adapter. Now 
that I fixed that everything seems to work properly and I'm loving it.
One last thing: I set qubes to update packages over tor. I immediately 
regretted 
the decision. Is there a way to download update w/o Tor?
Regards

-- 
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/969f7165-a2bd-43fd-bdf4-fffc5741999d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: i3 under Qubes 4 RC3

2018-01-25 Thread Kevin Martinsen

i3 has been working fine for me.

Did you follow the installation instructions on 
https://www.qubes-os.org/doc/i3/? Specifically: 
$ sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing 
i3-settings-qubes

What do you mean you cannot start any programs from vms? How are you trying to 
start programs? For me I have mod4+d to use dmenu. And do you mean to say that 
qvm-run works correctly?

-- 
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/b05a4107-dcf1-4ee2-9102-75d767fd063b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Qubes 4.0 Documentation

Resuming working my way through splitting up the documentation now that
the 3.2 vs. 3.3 question has been mostly settled. Some general questions:

1. Should I open an issue for tracking and move the discussion over there?
Move to qubes-devel? Keep here?
2. The command line tools in particular
(https://www.qubes-os.org/doc/vm-tools/ and
https://www.qubes-os.org/doc/dom0-tools/) seem Wrong to try to share the
same pages for 3.2 and 4.0. Not only is the selection of commands slightly
different between versions, but many have slightly different options ("-a"
vs. "a"). I'm thinking of copying all the existing pages, appending "4" so
they can be linked to directly, and putting in their own section.
Thoughts?
3. Some of these documents are pretty outdated. Should we have an Archive
link and move stuff like
https://www.qubes-os.org/doc/template/fedora/upgrade-18-to-20/ to it so it
doesn't clutter up the main Docs page?



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

[qubes-users] Save virtual machine state?

On pausing: Remember that there are some issues. For example, the VMs resume
after sleep Also, it seems it does not work well with changes of
monitor configuration.

On hibernation: This can work with standalone VMs, but it is problematic by
design on template-based (although probably possible) VMs. once you hibernate a
VM, you need to remember all the state, including the root filesystem. Unlike
traditional systems, the root device can be updated outside the VM, just by
running the TemplateVM. In such case, Qubes has to ensure that the VM won't see
the changes before reboot. Qubes has some ways to achieve this for running VMs
(you see, you don't need to shut the template-based VMs down when updating the
template), but it probably degrades some performance. Having to maintain it for
some forgotten hibernated VMs would be some unexpected source of performance
hit. So, it would be probably technically feasible (though maybe not easy), but
hard for UX.

Regards,
Vít Šesták 'v6ak'

--
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/53c68803-2ed6-433c-bafa-ee12ffc123f4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: "Qubes Air: Generalizing the Qubes Architecture" by Joanna Rutkowska

Raspberry Pi as a DVM is not that easy, but it is probably possible:

1. Let's have an image for the "VM" in your laptop.
2. Insert a SD card to the laptop and dd the image.
3. Boot Raspberry Pi.

This assumes that:

* You perform this every time you want a clean state.
* Raspberry Pi has no persistent storage outside of the SD card.
* MicroSD card cannot be hacked (e.g., Raspberry Pi cannot overwrite the 
firmware).
* Your laptop is not configured to parse anything from the card. (If it is not 
that case, it could try to compromise your laptop.)

Regards,
Vít Šesták 'v6ak'

-- 
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/8286b8c8-4b3c-4980-88a0-7bc77d87be83%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: GPU?

On January 25, 2018 5:56:41 PM GMT+01:00, "taii...@gmx.com"  
wrote:
>On 01/18/2018 04:00 PM, Alex Dubois wrote:
>Correct me if I am wrong but I don't see the issue with an apparmor 
>restricted qemu running in dom0...

Well, AppArmor might reduce the attack surface, but remember that:

1. Qubes was not intended to run QEMU in dom0 and
2. Qubes dom0 is often based on outdated Fedora. While ITL provides security 
updates for security-critical components, it does not necessarily cover all 
vulnerabilities in kernel and apparmor, because of #1.
3. Linux kernel is considered as quite weaker than Xen in terms of attack 
surface, so exploits in Linux kernel are more likely. AppArmor might mitigate 
*some* of them, but not all.

Regards,
Vít Šesták 'v6ak'

-- 
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/203975FF-A8A0-4EEF-8C0B-20AC09EC19EE%40v6ak.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: GPU?

2018-01-25 Thread taii...@gmx.com


On 01/18/2018 04:00 PM, Alex Dubois wrote:


If you have multiple GPU (i.e. integrated + NVidia), it is possible with Xen to 
do GPU pass-through (Assign the NVidia GPU to a dedicated VM) however:
- It is far from trivial and only limited setups are known to work
- The security of it is not as robust (I can't remember where I read that, I 
think it was in the GPU Pass-through page of the Xen wiki)

I have tried with limited success few years back (only one boot and was never 
able to get it back after)...


I do this all the time to play games and watch movies.

I recommend either a quality server board or a platform that has libre 
or open source firmware so that IOMMU issues can be fixed if they happen.


Correct me if I am wrong but I don't see the issue with an apparmor 
restricted qemu running in dom0...


--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To 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/b959b86d-f0b4-1f76-19d7-58493c07a3e5%40gmx.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Installation error: need at least 3mb more on /boot/efi

On Thursday, January 25, 2018 at 4:28:30 PM UTC+1, dark...@gmail.com wrote:
> I'm back and you were right! There was some efi junk on ssd that once deleted 
> let me install smoothly. Although I'm now facing another issue: when I boot 
> up for the first time, the qubes configuration goes all the way until a point 
> when it gives me a pci-related error (I'll try reproducing it again but I 
> dumbly closed the window). Anyways, the os let's me enter the desktop nd 
> I can't open VMs. This means that whatever VM I click on won't open. The only 
> VM that opens is sys-usb. 
> Regards

Were it by any chance python code errors? and happening the moment you tried to 
configure new VM's, network, etc. during the last step after first boot?

In which case, you can solve it either by identifying missing UEFI/BIOS 
settings, updating UEFI/BIOS (be sure you know what you do first, so you don't 
brick your hardware here), and lastly but not least, you can pull out the 
HDD/SSD/NMMe, whichever you use, and then put it in another computer. Install 
Qubes, fully update Qubes, and then pull the drive back out and put it back in 
your original machine. I've successfully done this a few times to bypass the 
Qubes 4 errors and other installation issues that normally are fixed with 
updates, but are not fixed in the install medium. This in particular helps in 
Qubes 4, where this step frequently happens during the last setup step on first 
boot on the Qubes 4 RC-1 / RC-2 and RC-3. Hopefully RC-4 is free of this issue.

Precausions!!

1): Using this method, it's best to only install with Grub, unless you know 
your way around UEFI/EFI install paths. If you use UEFI/EFI, then not only will 
it be tricky to regain any old EFI paths you had on the other machine, it will 
also be tricky to install on the current machine when you put it back in. If 
you on the other hand install with LegacyBIOS/Grub, then it should just work, 
plain and simple.

2: Might want to pull out any drives you got on the other machine, while 
installing Qubes, just in case anything should be written to the drives, like 
new grub configurations, etc. just to be safe, remove them. Then put them back 
in as they were when you pull the drive out you just installed Qubes on (best 
use same cables if any software is sensitive to the drive numbers). 

3: When you put it back in the old machine, and errors that were corrected 
between RC-3 and now today, will be fixed. 

I've had quite a lot of success on multiple different Qubes 4 machines using 
this method as of late.

Maybe worth a a try if you got a sparing computer around that can run Qubes?

Just keep in mind your Qubes will be exposed to unsafe hardware if the other 
machine isn't trustworthy. But for the most part, if its beween not getting 
Qubes to work, and this, then it's well worth the risk imho. Also the risk 
might be low, depending on what you pulled that machine through, and/or your 
public profile. Like probably only high profile people are heavily targeted, 
like really heavy profiles. You're probably not at much rish in this day and 
age, but you never know for sure though, but probably not big odds.

Either way, it's definitely worth it if its your last option to try.

Also your description of the issue sounds a lot like the issues I encounter, 
where it helps installing on another machine, update, and then put the drive 
back. It may be worth a shot if you got the means to do it. 

Further keep in mind if you break any still valid warrenties, and/or be sure 
you don't do something that might break your computer. Think twice, or triple, 
and ask if you got questions before doing something you're not sure about is 
doing. Just to be safer, there is always a risk when going into UEFI/BIOS 
settings, nevermind updating it which can brick your system if it breaks 
halffway or there is a corruption in your downloaded update file, poweroutages 
during UEFI/BIOS update, instability causing freezes, etc. etc.

-- 
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/c401b7fc-2dd7-486b-939e-2100b4f1cb7c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Installation error: need at least 3mb more on /boot/efi

2018-01-25 Thread darklampz

I'm back and you were right! There was some efi junk on ssd that once deleted 
let me install smoothly. Although I'm now facing another issue: when I boot up 
for the first time, the qubes configuration goes all the way until a point when 
it gives me a pci-related error (I'll try reproducing it again but I dumbly 
closed the window). Anyways, the os let's me enter the desktop nd I can't 
open VMs. This means that whatever VM I click on won't open. The only VM that 
opens is sys-usb. 
Regards

-- 
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/ecdc3fc2-b0cd-44fb-880c-b5d0305865b1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] No space left

On Thursday, January 25, 2018 at 3:29:28 PM UTC+1, beso wrote:
> On Thursday, January 25, 2018 at 4:03:16 PM UTC+2, Yuraeitha wrote:
> > On Thursday, January 25, 2018 at 2:32:38 PM UTC+1, beso wrote:
> > > On Thursday, January 25, 2018 at 1:13:53 PM UTC+2, donoban wrote:
> > > > On 01/24/2018 07:11 PM, beso wrote:
> > > > > On Wednesday, January 24, 2018 at 2:47:55 PM UTC+2, donoban wrote:
> > > > >> On 01/24/2018 09:34 AM, beso wrote:
> > > > >>> On Tuesday, January 23, 2018 at 3:53:15 PM UTC+2, steve.coleman 
> > > > >>> wrote:
> > > >  On 01/23/2018 04:55 AM, beso wrote:
> > > > > Something is eating free space in my system. It step by step 
> > > > > decreasing. I haven't found any good solution for that.
> > > > >
> > > > 
> > > >  This command should give you a clue as to where the space is going:
> > > > 
> > > >  $ sudo du -h / | sort  -g | tail -100
> > > > 
> > > > >>
> > > > >> Try reversing the sort output:
> > > > >>
> > > > >> sudo du -h / | sort  -g -r | tail -100
> > > > > 
> > > > > sudo du -h / | sort -g -r | tail -100
> > > > > du: `/proc/5947/task/5947/fd/4' ei saa kasutada: No such file or 
> > > > > directory
> > > > > du: `/proc/5947/task/5947/fdinfo/4' ei saa kasutada: No such file or 
> > > > > directory
> > > > > du: `/proc/5947/fd/3' ei saa kasutada: No such file or directory
> > > > > du: `/proc/5947/fdinfo/3' ei saa kasutada: No such file or directory
> > > > > 0 /proc/109/ns
> > > > > 0 /proc/109/net/stat
> > > > 
> > > > Ouch, try better this way:
> > > > 
> > > > cd /
> > > > sudo du -sh *
> > > > 
> > > > You should see each dir on / and its disk usage
> > > > 
> > > > then cd what you think it's using more than expected and du -sh * again.
> > > 
> > > Thank you for the answer. Actually I know generally that some of my 
> > > appvm-s are quite big and there is quite few room(about 6G). Thing I 
> > > don't understand and would like to know is that this free room is 
> > > disappearing sometimes(not always) "in my eyes"(free space checker shows 
> > > me in real time :-))
> > 
> > It may be, "possible" that discard / fstrim only partially works? For 
> > example if it works in dom0, but not in some, or all your VM's, then 
> > numbers may change, but they won't be exact. This too means some VM's can 
> > grow larger than the actual files they hold, i.e. if you once had more 
> > files in, but no longer have that much now. If it can't shrink back down, 
> > then it'll stay large. Does your VM's shrink back down too? 
> > 
> > I modified donoban's command slightly, it's a good command and it's a good 
> > advice he gives. The only reason I modified it to AppVM folder, is because 
> > it's a likely source for your disk changes, so it's a good place to start 
> > looking too in addition to overall root at "/". 
> > 
> > Try:
> > 
> > in dom0: cd /var/lib/qubes/appvms 
> > in dom0: sudo du -sh *
> > 
> > It'll show all your AppVM's and their total disk usage, it's way simpler 
> > than the "qvm-ls --format disk" dommand I gave you earlier. 
> > 
> > It's recommendable that you save these logs over some days, i.e. sudo nano 
> > and copy-paste into it, and save with ctrl+x and follow the guideline to 
> > save. 
> > 
> > By keeping these logs, you can easily narrow down where it changes in an 
> > uncontrollable manner when compared. You can even post them here if you 
> > prefer, or cross out the VM names with numbers instead if you prefer 
> > privacy (just be sure they match numbers between logs). 
> > 
> > As donoban also said, if you do this properly, you'll be able to narrow 
> > down the possible culprit. Run the commands once a day over a few days, on 
> > both "/" and "/var/lib/qubes/appvms", and keep one log for each path, for 
> > some days.
> > 
> > This way, you'll quickly narrow it down with minimal effort once a day, 
> > only requiring a bit of patience and a few quick commands daily, max 3-4 
> > minutes.
> 
> 
> Actually I haven't trimmed dom0 itself only templates/appvms/standalones. Is 
> this link https://www.qubes-os.org/doc/disk-trim/ correctway to do that?

It depends, are you using UEFI/EFI to install Qubes? or LegacyBIOS/Grup? You 
found the right guide, but this guide is only for LegacyBIOS/Grup, and I'm not 
entirely happy with some of the commands in it, it seems a bit dangerous, but 
then again, I'm no expert. I'm also not sure if it works for Qubes 4, or only 
Qubes 3.2. Some guides still have to be updated for Qubes 4. I just find it odd 
that the "dracut -H -f" command is used, which as far as I know is related to 
the kernel installations. It seems possible to be related to fstab etc., but it 
also seems a bit overkill/dangerous without further insight into why it's used. 
Perhaps someone more knowledgeable can confirm that this works and doesn't 
break a system? I might be too careful, it's an official Qubes guide after all. 
But just to be sure and safe. 

If you're on UEFI/EFI, then it's quite a lot

Re: [qubes-users] Save virtual machine state?

2018-01-25 Thread Loren Rogers

 Original Message 
 On January 25, 2018 9:54 AM, Chris Laprise  wrote:

>On 01/24/2018 10:33 PM, Loren Rogers wrote:
>>I'm sure this has already been discussed, but is there a way to save the
>> state of a virtual machine, instead of shutting it down? I can't find
>> any info in the docs on what exactly pausing a VM does, but could this
>> be similar?
>>Thanks
>>
>
> Pausing is only in-memory stopping of the VM. Un-pausing makes the VM
> continue running.
>
> Qubes doesn't (yet) support saving to disk like hibernate. If this ever
> does become a feature it will probably be for use with HVMs in Qubes 4.x.
>
>
>
> Chris Laprise, tas...@posteo.net
>https://github.com/tasket
>https://twitter.com/ttaskett
> PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886
>


Thanks Chris - good to know. 


-- 
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/5ZBUAyYt_eU3Ii20ra0rjFzRlBDByAgXs3cNKYCUtCFWr-vUmxjOnMP1ukkKk726WxHEqlnIWrQD64stfPHMYSqWgzqkiDzctLFghn3zVdg%3D%40lorentrogers.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Save virtual machine state?

2018-01-25 Thread Chris Laprise


On 01/24/2018 10:33 PM, Loren Rogers wrote:
I'm sure this has already been discussed, but is there a way to save the 
state of a virtual machine, instead of shutting it down? I can't find 
any info in the docs on what exactly pausing a VM does, but could this 
be similar?


Thanks


Pausing is only in-memory stopping of the VM. Un-pausing makes the VM 
continue running.


Qubes doesn't (yet) support saving to disk like hibernate. If this ever 
does become a feature it will probably be for use with HVMs in Qubes 4.x.


--

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

--
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/b6a77ee9-8414-e2d6-9ffa-141c68bf7842%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Kernel Panic on a Lenovo Yoga 300 11-iby on attempt at install

2018-01-25 Thread aaq via qubes-users

Den torsdag den 25. januar 2018 kl. 14.40.14 UTC+1 skrev WolfSkin:
> On Thursday, 25 January 2018 13:36:18 UTC, WolfSkin  wrote:
> > Basically my issue is that I am getting a kernel panic when I try 
> > installing qubes-os on my laptop both in UEFI and legacy mode. 
> > The kernel panic can be seen here: https://imagebin.ca/v/3pPwokGAMAVB and I 
> > sadly can't provide a hastebin dump since I have no way to log the error in 
> > text form (at least none that I'm aware of).
> > 
> > I have followed the steps in the uefi-troubleshooting docs page, to no avail
> > 
> > Steps to reproduce:
> > - Buy this laptop
> > - Burn the iso to usb using etcher or rufus after having verified file 
> > integrity via checksums and signature
> > - Boot to the usb in uefi or legacy
> > 
> > What I expect to happen:
> > - Normal boot to the installer
> > 
> > What I get instead:
> > - Attempts to boot, manages to get to the loading bar on legacy, not even 
> > close on uefi
> > - Then kernel panic (as seen in picture)
> > 
> > Any help with this would be greatly appreciated
> 
> Since I can't edit the above afaik, this is both on R4-rc3 and R3.2

Did you try the steps from this doc page?
https://www.qubes-os.org/doc/thinkpad-troubleshooting/#instructions-to-create-usb-installation-medium-for-newer-uefi-only-thinkpads

DISCLAIMER:
I have a ThinkPad X270, but I installed in legacy mode, so I haven't tried this 
myself..

Perhaps someone with more knowledge can assist, if this fails :)

-- 
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/9df52da3-ce82-4036-92a1-a23a0f40bc17%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Kernel Panic on a Lenovo Yoga 300 11-iby on attempt at install

On Thursday, January 25, 2018 at 2:36:18 PM UTC+1, WolfSkin wrote:
> Basically my issue is that I am getting a kernel panic when I try installing 
> qubes-os on my laptop both in UEFI and legacy mode. 
> The kernel panic can be seen here: https://imagebin.ca/v/3pPwokGAMAVB and I 
> sadly can't provide a hastebin dump since I have no way to log the error in 
> text form (at least none that I'm aware of).
> 
> I have followed the steps in the uefi-troubleshooting docs page, to no avail
> 
> Steps to reproduce:
> - Buy this laptop
> - Burn the iso to usb using etcher or rufus after having verified file 
> integrity via checksums and signature
> - Boot to the usb in uefi or legacy
> 
> What I expect to happen:
> - Normal boot to the installer
> 
> What I get instead:
> - Attempts to boot, manages to get to the loading bar on legacy, not even 
> close on uefi
> - Then kernel panic (as seen in picture)
> 
> Any help with this would be greatly appreciated

Three methods for you to consider/try: 

1) Update your BIOS/UEFI, new laptops usually have a couple of versions laying 
around to be update. Just be careful, if you haven't done this before, then 
take proper precautions and read up on it, ask questions if you're in doubt, 
and don't do anything reckless, as there is the potential of bricking your 
entire machine, aka, zero value and can be thrown in the crash can. But if you 
don't do any mistakes, then it should be no problem to do, and it might very 
well fix your Qubes issues. In particular, because BIOS/UEFI errors can easily 
mess up a Qubes install.

2): Pull out the SDD/HHD/NVMe, whichever you installed on, and then insert it 
in another computer. Install Qubes on this other system. Then update it 
completely, make sure everything is up-to-date. Once that is done, move the 
drive back into the new desktop/laptop. Be sure to install with Grub, both so 
you don't mess up your other machines EFI paths (can be annoying), and also to 
avoid hassles to re-build a EFI path when returning it to the new machine. So, 
with this method, if you install with legacy/grub, you avoid any such troubles. 
Also it might be a good idea to unplug any other drives on the machine you 
install it on, just in case the installer writes to them. Then plug them back 
in once you're pulling the other drive out. I've done this about 5 times with 
Qubes, for various computers that could not install Qubes, or claimed to lack 
hardware support (which in some cases is wrong and is only corrected after 
updating under current-release), failed to load installer, or failed at the 
last step during first boot with python errors. Basically, this method solved 
quite many of my Qubes problems, in particular and foremost on Qubes 4 
installations, albeit it might help for Qubes 3.2. too.

3) Change UEFI/BIOS settings. Sometimes it can just be an otherwise innocent 
UEFI/BIOS setting you never would suspect is messing it up. I've spend more 
than once an hour or so adjusting UEFI/BIOS settings, in combination with above 
suggestions. More often than not by using these steps, I get Qubes running and 
working on a system that did not install otherwise. For example make sure VT-d 
is enabled, it's often disabled on new computer systems. Be sure there is no 
extra virtualization setting, some motherboards (like i.e. Asus) may have an 
extra setting, it may hide under CPU settings in the advanced menu. Be sure 
VT-d is enabled, and make sure there is no extra setting for virtualization, 
and if there is, make sure that it's enabled as well. There can be any number 
of settings that cause a kernel panic, typically though, it does seem like your 
hardware might be too new for the instlaled kernel. 

4) Qubes 3.2. comes with 4.4 kernel, iirc? It might be too old for your new 
machine. You can either use option 2) above, install on another machine, update 
it so it has a new higher version kernel, and then try put it back in your new 
machine again. Or, instead, you could try install Qubes 4 RC-3, although Qubes 
4 RC-4 "might" be out soon, but there is no news released yet whether a normal 
update is required, or if you need to re-install between Qubes 4 RC-3 and Qubes 
4 RC-4. For example between Qubes 4 RC-2 and Qubes 4 RC-3, no install was 
required, and normal updates was sufficient.

Either way, if I had to guess, the real issue is likely too new hardware on an 
too old kernel, and likely outdated BIOS/UEFI. The safest you can do, if you 
want to do the minimum risk first, is to try install Qubes 4 RC-3. If you 
succeed, then it might just be because Qubes 4 RC-3 has a newer kernel, which 
means newwer essential drivers for CPU's/RAM/Motherboard, etc. If memory 
serves, I believe Qubes 4 RC-3 comes with kernel 4.9.x. If this isn't enough, 
then you'll need to try put it in another computer, install Qubes 4, and update 
it to gain access to the recently released kernel 4.14. If you don't have 
another computer available to do this on, or you

Re: [qubes-users] No space left

2018-01-25 Thread beso

On Thursday, January 25, 2018 at 4:03:16 PM UTC+2, Yuraeitha wrote:
> On Thursday, January 25, 2018 at 2:32:38 PM UTC+1, beso wrote:
> > On Thursday, January 25, 2018 at 1:13:53 PM UTC+2, donoban wrote:
> > > On 01/24/2018 07:11 PM, beso wrote:
> > > > On Wednesday, January 24, 2018 at 2:47:55 PM UTC+2, donoban wrote:
> > > >> On 01/24/2018 09:34 AM, beso wrote:
> > > >>> On Tuesday, January 23, 2018 at 3:53:15 PM UTC+2, steve.coleman wrote:
> > >  On 01/23/2018 04:55 AM, beso wrote:
> > > > Something is eating free space in my system. It step by step 
> > > > decreasing. I haven't found any good solution for that.
> > > >
> > > 
> > >  This command should give you a clue as to where the space is going:
> > > 
> > >  $ sudo du -h / | sort  -g | tail -100
> > > 
> > > >>
> > > >> Try reversing the sort output:
> > > >>
> > > >> sudo du -h / | sort  -g -r | tail -100
> > > > 
> > > > sudo du -h / | sort -g -r | tail -100
> > > > du: `/proc/5947/task/5947/fd/4' ei saa kasutada: No such file or 
> > > > directory
> > > > du: `/proc/5947/task/5947/fdinfo/4' ei saa kasutada: No such file or 
> > > > directory
> > > > du: `/proc/5947/fd/3' ei saa kasutada: No such file or directory
> > > > du: `/proc/5947/fdinfo/3' ei saa kasutada: No such file or directory
> > > > 0   /proc/109/ns
> > > > 0   /proc/109/net/stat
> > > 
> > > Ouch, try better this way:
> > > 
> > > cd /
> > > sudo du -sh *
> > > 
> > > You should see each dir on / and its disk usage
> > > 
> > > then cd what you think it's using more than expected and du -sh * again.
> > 
> > Thank you for the answer. Actually I know generally that some of my appvm-s 
> > are quite big and there is quite few room(about 6G). Thing I don't 
> > understand and would like to know is that this free room is disappearing 
> > sometimes(not always) "in my eyes"(free space checker shows me in real time 
> > :-))
> 
> It may be, "possible" that discard / fstrim only partially works? For example 
> if it works in dom0, but not in some, or all your VM's, then numbers may 
> change, but they won't be exact. This too means some VM's can grow larger 
> than the actual files they hold, i.e. if you once had more files in, but no 
> longer have that much now. If it can't shrink back down, then it'll stay 
> large. Does your VM's shrink back down too? 
> 
> I modified donoban's command slightly, it's a good command and it's a good 
> advice he gives. The only reason I modified it to AppVM folder, is because 
> it's a likely source for your disk changes, so it's a good place to start 
> looking too in addition to overall root at "/". 
> 
> Try:
> 
> in dom0: cd /var/lib/qubes/appvms 
> in dom0: sudo du -sh *
> 
> It'll show all your AppVM's and their total disk usage, it's way simpler than 
> the "qvm-ls --format disk" dommand I gave you earlier. 
> 
> It's recommendable that you save these logs over some days, i.e. sudo nano 
> and copy-paste into it, and save with ctrl+x and follow the guideline to 
> save. 
> 
> By keeping these logs, you can easily narrow down where it changes in an 
> uncontrollable manner when compared. You can even post them here if you 
> prefer, or cross out the VM names with numbers instead if you prefer privacy 
> (just be sure they match numbers between logs). 
> 
> As donoban also said, if you do this properly, you'll be able to narrow down 
> the possible culprit. Run the commands once a day over a few days, on both 
> "/" and "/var/lib/qubes/appvms", and keep one log for each path, for some 
> days.
> 
> This way, you'll quickly narrow it down with minimal effort once a day, only 
> requiring a bit of patience and a few quick commands daily, max 3-4 minutes.


Actually I haven't trimmed dom0 itself only templates/appvms/standalones. Is 
this link https://www.qubes-os.org/doc/disk-trim/ correctway to do that?

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/2d249d6b-852d-4a08-94a0-1026703f191f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: USB3 attach problem

On Thursday, January 25, 2018 at 12:44:37 PM UTC+1, Ilpo Järvinen wrote:
> On Wed, 24 Jan 2018, beso wrote:
> 
> > On Thursday, January 25, 2018 at 5:01:00 AM UTC+2, cooloutac wrote:
> > > On Wednesday, January 24, 2018 at 2:35:14 PM UTC-5, beso wrote:
> > > > ERROR: Device attach failed: USB SuperSpeed require kernel >= 
> > > > 4.13/usr/lib/qubes/usb-import: line 71: printf: write error: Invalid 
> > > > argument
> > > 
> > > I don't have this issue on 3.2.  are you using 4.0?
> > 
> > No, I use 3.2.
> 
> Qubes usb-proxy recently gained support for USB3 [1] but perhaps it might 
> need to check that the kernel is new enough to support it?
> 
> R3.2 stable repo only has 4.9 series kernel in stable repo, whereas 
> testing has new enough kernel.
> 
> Perhaps these different experiences you see come from different kernel / 
> usb-proxy versions installed?
> 
> -- 
>  i.
> 
> 
> [1] 
> https://github.com/QubesOS/qubes-app-linux-usb-proxy/commit/5f94e1064fd5946f127e1257062756be75f92f99

Doesn't Qubes 3.2. have access to kernel 4.14? If true, then this "might" be a 
possible reason. Qubes 4 has access to kernel 4.14. Currently Qubes 4 has 
received some qubes-usb-proxy updates, if these updates were only considered 
for Qubes 4, and not Qubes 3.2., then it might be an overlook pr. design? It's 
a lot of things to keep track of afterall, if I'm not mistaken, human error 
could easily happen here.

In which case, this update wasnt designed for Qubes 3.2. which doesn't have 
4.14 kernel yet? But I'm a bit puzzled, shouldn't 4.14 be vailaboe for Qubes 
3.2. as well? Considering meltdown, spectra, and eveything is fixed in 4.14. I 
was under the impression the reason for the unexpected sudden hasteful release 
of 4.14. was to fix spectra and meltdown.

Perhaps this is similar to the other Linux distributions that stopped working 
due to hasteful quick updates in a race to fix this issue? Only in Qubes might 
have been a less harmful mistake (if it was a mistake, I'm unable to confirm). 

In other words, it might just be a question of reversing the Qubes Proxy USB 
back to the older one, and all the dependencies that follow?

-- 
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/2f568c78-870d-4753-8676-fc81900def88%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] No space left

On Thursday, January 25, 2018 at 2:32:38 PM UTC+1, beso wrote:
> On Thursday, January 25, 2018 at 1:13:53 PM UTC+2, donoban wrote:
> > On 01/24/2018 07:11 PM, beso wrote:
> > > On Wednesday, January 24, 2018 at 2:47:55 PM UTC+2, donoban wrote:
> > >> On 01/24/2018 09:34 AM, beso wrote:
> > >>> On Tuesday, January 23, 2018 at 3:53:15 PM UTC+2, steve.coleman wrote:
> >  On 01/23/2018 04:55 AM, beso wrote:
> > > Something is eating free space in my system. It step by step 
> > > decreasing. I haven't found any good solution for that.
> > >
> > 
> >  This command should give you a clue as to where the space is going:
> > 
> >  $ sudo du -h / | sort  -g | tail -100
> > 
> > >>
> > >> Try reversing the sort output:
> > >>
> > >> sudo du -h / | sort  -g -r | tail -100
> > > 
> > > sudo du -h / | sort -g -r | tail -100
> > > du: `/proc/5947/task/5947/fd/4' ei saa kasutada: No such file or directory
> > > du: `/proc/5947/task/5947/fdinfo/4' ei saa kasutada: No such file or 
> > > directory
> > > du: `/proc/5947/fd/3' ei saa kasutada: No such file or directory
> > > du: `/proc/5947/fdinfo/3' ei saa kasutada: No such file or directory
> > > 0 /proc/109/ns
> > > 0 /proc/109/net/stat
> > 
> > Ouch, try better this way:
> > 
> > cd /
> > sudo du -sh *
> > 
> > You should see each dir on / and its disk usage
> > 
> > then cd what you think it's using more than expected and du -sh * again.
> 
> Thank you for the answer. Actually I know generally that some of my appvm-s 
> are quite big and there is quite few room(about 6G). Thing I don't understand 
> and would like to know is that this free room is disappearing sometimes(not 
> always) "in my eyes"(free space checker shows me in real time :-))

It may be, "possible" that discard / fstrim only partially works? For example 
if it works in dom0, but not in some, or all your VM's, then numbers may 
change, but they won't be exact. This too means some VM's can grow larger than 
the actual files they hold, i.e. if you once had more files in, but no longer 
have that much now. If it can't shrink back down, then it'll stay large. Does 
your VM's shrink back down too? 

I modified donoban's command slightly, it's a good command and it's a good 
advice he gives. The only reason I modified it to AppVM folder, is because it's 
a likely source for your disk changes, so it's a good place to start looking 
too in addition to overall root at "/". 

Try:

in dom0: cd /var/lib/qubes/appvms 
in dom0: sudo du -sh *

It'll show all your AppVM's and their total disk usage, it's way simpler than 
the "qvm-ls --format disk" dommand I gave you earlier. 

It's recommendable that you save these logs over some days, i.e. sudo nano and 
copy-paste into it, and save with ctrl+x and follow the guideline to save. 

By keeping these logs, you can easily narrow down where it changes in an 
uncontrollable manner when compared. You can even post them here if you prefer, 
or cross out the VM names with numbers instead if you prefer privacy (just be 
sure they match numbers between logs). 

As donoban also said, if you do this properly, you'll be able to narrow down 
the possible culprit. Run the commands once a day over a few days, on both "/" 
and "/var/lib/qubes/appvms", and keep one log for each path, for some days.

This way, you'll quickly narrow it down with minimal effort once a day, only 
requiring a bit of patience and a few quick commands daily, max 3-4 minutes.

-- 
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/e41165b7-a96a-4ec2-8318-78df25ffe486%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] No space left

2018-01-25 Thread donoban

On 01/25/2018 02:32 PM, beso wrote:
> Thank you for the answer. Actually I know generally that some of my appvm-s 
> are quite big and there is quite few room(about 6G). Thing I don't understand 
> and would like to know is that this free room is disappearing sometimes(not 
> always) "in my eyes"(free space checker shows me in real time :-))
> 

Well 6G free is really low. You should consider to use maximum 75% of a
SSD disk and ~50% for a conventional (unless  it's used only for long
term storage).

If you can't remove anything consider to buy another hard disk.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To 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/5dbe34c0-8417-75f7-6698-911c8e474610%40riseup.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: USB3 attach problem

2018-01-25 Thread beso

On Thursday, January 25, 2018 at 1:44:37 PM UTC+2, Ilpo Järvinen wrote:
> On Wed, 24 Jan 2018, beso wrote:
> 
> > On Thursday, January 25, 2018 at 5:01:00 AM UTC+2, cooloutac wrote:
> > > On Wednesday, January 24, 2018 at 2:35:14 PM UTC-5, beso wrote:
> > > > ERROR: Device attach failed: USB SuperSpeed require kernel >= 
> > > > 4.13/usr/lib/qubes/usb-import: line 71: printf: write error: Invalid 
> > > > argument
> > > 
> > > I don't have this issue on 3.2.  are you using 4.0?
> > 
> > No, I use 3.2.
> 
> Qubes usb-proxy recently gained support for USB3 [1] but perhaps it might 
> need to check that the kernel is new enough to support it?
> 
> R3.2 stable repo only has 4.9 series kernel in stable repo, whereas 
> testing has new enough kernel.
> 
> Perhaps these different experiences you see come from different kernel / 
> usb-proxy versions installed?
> 
> -- 
>  i.
> 
> 
> [1] 
> https://github.com/QubesOS/qubes-app-linux-usb-proxy/commit/5f94e1064fd5946f127e1257062756be75f92f99

What kernel it shoud be? Unstable repo has also 4.9 kernels.

-- 
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/97cc7f91-c04c-4e47-9e11-be05cde20b75%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Kernel Panic on a Lenovo Yoga 300 11-iby on attempt at install

2018-01-25 Thread WolfSkin

On Thursday, 25 January 2018 13:36:18 UTC, WolfSkin  wrote:
> Basically my issue is that I am getting a kernel panic when I try installing 
> qubes-os on my laptop both in UEFI and legacy mode. 
> The kernel panic can be seen here: https://imagebin.ca/v/3pPwokGAMAVB and I 
> sadly can't provide a hastebin dump since I have no way to log the error in 
> text form (at least none that I'm aware of).
> 
> I have followed the steps in the uefi-troubleshooting docs page, to no avail
> 
> Steps to reproduce:
> - Buy this laptop
> - Burn the iso to usb using etcher or rufus after having verified file 
> integrity via checksums and signature
> - Boot to the usb in uefi or legacy
> 
> What I expect to happen:
> - Normal boot to the installer
> 
> What I get instead:
> - Attempts to boot, manages to get to the loading bar on legacy, not even 
> close on uefi
> - Then kernel panic (as seen in picture)
> 
> Any help with this would be greatly appreciated

Since I can't edit the above afaik, this is both on R4-rc3 and R3.2

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

[qubes-users] i3 under Qubes 4 RC3

2018-01-25 Thread aaq via qubes-users

Hey all,

I installed i3 when first set up my machine, but I can't seem to get it 
working..

Has anyone else experienced issues with i3?

In my case, no applets are shown in the bar and I cannot start any programs 
from VM's (any VM).

If I run qvm-ls, it shows that VM's are running, and if I try to do somethings 
like qvm-run  firefox, my CPU responds.

Just a peculiar issue, but makes i3 unusable for me nonetheless..

Any feedback appreciated :)

Cheers!

-- 
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/8a0771c6-0756-41d0-b7a7-f46cbf94b45c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Kernel Panic on a Lenovo Yoga 300 11-iby on attempt at install

2018-01-25 Thread martinschon111

Basically my issue is that I am getting a kernel panic when I try installing 
qubes-os on my laptop both in UEFI and legacy mode. 
The kernel panic can be seen here: https://imagebin.ca/v/3pPwokGAMAVB and I 
sadly can't provide a hastebin dump since I have no way to log the error in 
text form (at least none that I'm aware of).

I have followed the steps in the uefi-troubleshooting docs page, to no avail

Steps to reproduce:
- Buy this laptop
- Burn the iso to usb using etcher or rufus after having verified file 
integrity via checksums and signature
- Boot to the usb in uefi or legacy

What I expect to happen:
- Normal boot to the installer

What I get instead:
- Attempts to boot, manages to get to the loading bar on legacy, not even close 
on uefi
- Then kernel panic (as seen in picture)

Any help with this would be greatly appreciated

-- 
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/de215f32-99c2-4f3a-b561-66c67f374b0e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] No space left

2018-01-25 Thread beso

On Thursday, January 25, 2018 at 1:13:53 PM UTC+2, donoban wrote:
> On 01/24/2018 07:11 PM, beso wrote:
> > On Wednesday, January 24, 2018 at 2:47:55 PM UTC+2, donoban wrote:
> >> On 01/24/2018 09:34 AM, beso wrote:
> >>> On Tuesday, January 23, 2018 at 3:53:15 PM UTC+2, steve.coleman wrote:
>  On 01/23/2018 04:55 AM, beso wrote:
> > Something is eating free space in my system. It step by step 
> > decreasing. I haven't found any good solution for that.
> >
> 
>  This command should give you a clue as to where the space is going:
> 
>  $ sudo du -h / | sort  -g | tail -100
> 
> >>
> >> Try reversing the sort output:
> >>
> >> sudo du -h / | sort  -g -r | tail -100
> > 
> > sudo du -h / | sort -g -r | tail -100
> > du: `/proc/5947/task/5947/fd/4' ei saa kasutada: No such file or directory
> > du: `/proc/5947/task/5947/fdinfo/4' ei saa kasutada: No such file or 
> > directory
> > du: `/proc/5947/fd/3' ei saa kasutada: No such file or directory
> > du: `/proc/5947/fdinfo/3' ei saa kasutada: No such file or directory
> > 0   /proc/109/ns
> > 0   /proc/109/net/stat
> 
> Ouch, try better this way:
> 
> cd /
> sudo du -sh *
> 
> You should see each dir on / and its disk usage
> 
> then cd what you think it's using more than expected and du -sh * again.

Thank you for the answer. Actually I know generally that some of my appvm-s are 
quite big and there is quite few room(about 6G). Thing I don't understand and 
would like to know is that this free room is disappearing sometimes(not always) 
"in my eyes"(free space checker shows me in real time :-))

-- 
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/43c73ab1-74de-4872-ae7c-bb58cf9fd216%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Do allowing USB Keyboard expose to badusb attacks?

2018-01-25 Thread Matty South

On Wednesday, January 24, 2018 at 4:47:58 AM UTC-6, koto...@gmail.com wrote:
> If a USB keyboard is allowed with /etc/qubes-rpc/policy/qubes.InputKeyboard, 
> does it increase the risk for badusb kind of attacks?

Yes, it does. I asked a similar question here:  
https://groups.google.com/forum/#!topic/qubes-users/52d0rqNnVqU 

The TLDR I got is that someone is working on a "USG hardware firewall mentioned 
in issue 2518" to prevent this kind of thing. 

-- 
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/f9efbfb2-0ea4-4a06-80bc-ae3ccee33463%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: USB3 attach problem

2018-01-25 Thread Ilpo Järvinen

On Wed, 24 Jan 2018, beso wrote:

> On Thursday, January 25, 2018 at 5:01:00 AM UTC+2, cooloutac wrote:
> > On Wednesday, January 24, 2018 at 2:35:14 PM UTC-5, beso wrote:
> > > ERROR: Device attach failed: USB SuperSpeed require kernel >= 
> > > 4.13/usr/lib/qubes/usb-import: line 71: printf: write error: Invalid 
> > > argument
> > 
> > I don't have this issue on 3.2.  are you using 4.0?
> 
> No, I use 3.2.

Qubes usb-proxy recently gained support for USB3 [1] but perhaps it might 
need to check that the kernel is new enough to support it?

R3.2 stable repo only has 4.9 series kernel in stable repo, whereas 
testing has new enough kernel.

Perhaps these different experiences you see come from different kernel / 
usb-proxy versions installed?

-- 
 i.


[1] 
https://github.com/QubesOS/qubes-app-linux-usb-proxy/commit/5f94e1064fd5946f127e1257062756be75f92f99

-- 
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/alpine.DEB.2.20.1801251338050.29120%40whs-18.cs.helsinki.fi.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: How to deal with Yubikey ?

2018-01-25 Thread rob_66

On Mon, 22 Jan 2018 22:47:55 -0800 (PST)
ThierryIT  wrote:
 
> I have today to deal with two problems:
> 
> 1) I am using Yubikey to be authentified on some web site like
> Github ... 2) I am using Yubikey to stock my PGP keys and to use them
> with mainly my emails (Thinderbird+Enigmail)
> 
> What to do under Qubes to make this possible ?
> I have already sys-usb running. 

Hi.

I studied and followed
https://mig5.net/content/yubikey-2fa-qubes-redux-adding-backup-key as
well as https://mig5.net/content/yubikey-challenge-response-mode-qubes
and it works perfectly fine on Qubes 3.2, Fedora 26. And my skills
are mediocre. 

(Sending *63* bits, »variable«, you'll recognize later.)

However, Qubes' own tutorial can, of course, work flawlessly with your
set-up:

https://www.qubes-os.org/doc/yubi-key/

If you like to dig in deeper, see the discussions on Github: 

https://www.qubes-os.org/doc/yubi-key/

Best regards,
r.


-- 
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/20180125113702.770c2005.robotico%40posteo.es.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] No space left

2018-01-25 Thread donoban

On 01/24/2018 07:11 PM, beso wrote:
> On Wednesday, January 24, 2018 at 2:47:55 PM UTC+2, donoban wrote:
>> On 01/24/2018 09:34 AM, beso wrote:
>>> On Tuesday, January 23, 2018 at 3:53:15 PM UTC+2, steve.coleman wrote:
 On 01/23/2018 04:55 AM, beso wrote:
> Something is eating free space in my system. It step by step decreasing. 
> I haven't found any good solution for that.
>

 This command should give you a clue as to where the space is going:

 $ sudo du -h / | sort  -g | tail -100

>>
>> Try reversing the sort output:
>>
>> sudo du -h / | sort  -g -r | tail -100
> 
> sudo du -h / | sort -g -r | tail -100
> du: `/proc/5947/task/5947/fd/4' ei saa kasutada: No such file or directory
> du: `/proc/5947/task/5947/fdinfo/4' ei saa kasutada: No such file or directory
> du: `/proc/5947/fd/3' ei saa kasutada: No such file or directory
> du: `/proc/5947/fdinfo/3' ei saa kasutada: No such file or directory
> 0 /proc/109/ns
> 0 /proc/109/net/stat

Ouch, try better this way:

cd /
sudo du -sh *

You should see each dir on / and its disk usage

then cd what you think it's using more than expected and du -sh * again.

-- 
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/91d495ae-18c0-d286-b0e6-3caec6c1c141%40riseup.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Installation error: need at least 3mb more on /boot/efi

On Thu, January 25, 2018 10:14 am, darkla...@gmail.com wrote:
> 4.0. I'll try asap.

Sorry, thought of a third option right after hitting send...

You might have leftover junk in the EFI partition from other OSes. You
could look around in /boot/efi/EFI to see if there's anything to delete to
free up space. It's pretty easy to end up with a non-booting system if
there are other OSes on the same drive, so use caution if that's the case
(don't think it is in yours).

-- 
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/e8c41ed6b808222e0a4e4f4ad9516b8f.squirrel%40tt3j2x4k5ycaa5zt.onion.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Installation error: need at least 3mb more on /boot/efi

On Thu, January 25, 2018 9:10 am, darkla...@gmail.com wrote:
> Hi,
> as per title, when trying to install on a laptop (with new partitions
> automatically created by the installer) I get this error. I've seen
> another person with the same problem but he was upgrading qubes, qhereas
> I'm on a fresh install.
> Thanks for your help!

3.2 or 4.0? In 3.2 I believe the installer re-uses the existing EFI
partition instead of creating a new one. 4.0 might be the same. So a
couple options are:
- completely wipe the drive before installing Qubes on it (e.g. secure
erase if SSD). If that doesn't work,
- manually specify partition sizes on install. I'd set EFI at 512MB.

-- 
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/b68aa0996c307e02b9399141ff8f0ba6.squirrel%40tt3j2x4k5ycaa5zt.onion.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Please help with custom template build

On Wed, January 24, 2018 7:42 pm, Krišjānis Gross wrote:
> On Tuesday, 23 January 2018 19:36:00 UTC+2, Krišjānis Gross  wrote:

>> -> Verifying signatures...
>> Filename:
>> /home/krish/qubes-builder/cache/fc25/base_rpms/acl-2.2.52-13.fc25.x86_6
>> 4.rpm is not signed.  Exiting!

Just noticed you are using F27 for your build environment. Can you try F25?


-- 
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/d439ce9e014d0cdba2ccc4f0b8459396.squirrel%40tt3j2x4k5ycaa5zt.onion.
For more options, visit https://groups.google.com/d/optout.

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

There actually is a GUI for checking dom0 updates. In Qubes VM manager, select 
dom0 and click the update button in top toolbar. Or you can also use the 
context menu.

OTOH, in this case, the main benefit of the GUI are the notifications. The 
update process itself is usually more friendly from commandline. And you cannot 
install security-testing using GUI.

-- 
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/17ef6cbe-00d4-45ac-93e2-3220d4c01e81%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Qubes OS screensharing

Dave, why you start a new VM and not just use a loopback? Is the reason sharing
apps from multiple VMs? If si, you are at least significantly weakening
isolation. Maybe you are not keeping any, not sure. X11 was not designed for
isolation at all.

Nuno, this is probably possible, but not so trivial. You would need Grub (as
HVMs and PVs have different boot mechanisms) and you would need to adjust some
things made for PVs - probably some startup services and some X11 config files.
Those changes (especially the Grub change) would require a modification of the
template. And you would also need to reboot to change it.

I have some idea for full screensharing (considering Qubes-agnostic generic
screensharing apps):

1. Scrap the screen in dom0 and send it to a VM through Qubes RPC. It seems
that VLC can be used for that. Uncompressed video could be ideal for low
latency and lower CPU usage. Compression does not make much sense within a
physical computer. But compressed video could be also acceptable. I believe
video encoding is not a risky operation, so it can be done in dom0 without any
additional real risk.
2. In the VM, play the video in a VNC-loopback X11 session.
3. Run the screensharing app of your choice in the same X11 session.
4. Make the screensharing video fullscreen.

Of course, this would make some fractal effect when the VNC client is visible
on screen ☺

I haven't tried it yet, but it seems

Regards,
Vít Šesták 'v6ak'

--
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/624034b4-6326-4a7a-9484-1eda6bfc5bea%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

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

On Thu, January 25, 2018 2:17 am, yreb...@riseup.net wrote:
> On 2018-01-24 15:12, Andrew David Wong wrote:

>>
>> These packages will migrate from the security-testing repository to the
>>  current (stable) repository over the next two weeks after being tested
>>  by the community.
>
>
> 1)
> The latter (security) packages will migrate, I'd assume this means ?

Yes, this is the standard model for deploying all updates including
security. They appear in testing first for bleeding edge users, then
stable for everyone. Sometimes bugs are found in the testing phase causing
the package to be pulled, so unless you are comfortable rolling back
packages yourself you should leave it on stable.

> 2)
> Where would I find the repositories in dom0 for the track I'm currently
> using?

If you haven't changed it manually, you are on stable.

> 3)
> after doing the 1x securitytesting repo update, how do I check which Xen
> package is now installed?

In dom0, "dnf list installed".

> and/or  how do I bring up the  GUI
> update manager  when it doesn't actually need to update it doesn't persist

No GUI, but in dom0 you can force it to check for updates with "sudo
qubes-dom0-update". Might not be following your question here.

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

[qubes-users] Installation error: need at least 3mb more on /boot/efi

2018-01-25 Thread darklampz

Hi,
as per title, when trying to install on a laptop (with new partitions 
automatically created by the installer) I get this error. 
I've seen another person with the same problem but he was upgrading qubes, 
qhereas I'm on a fresh install.
Thanks for your help!

-- 
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/6d3554c0-f61b-48a2-9ff6-c705bbceda77%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Please help with 8th Generation Intel i5