date:20180127

On Sunday, January 28, 2018 at 4:17:10 AM UTC+1, Jo wrote:
> Yes, im running the backups trough sys-usb-> extern ssd.The sys-usb is
> the default one from the installation.Im doing a complete new setup, for
> the very same reasons you mentioned.
> 
> Updating (and enabling testingrepos) was the very first thing i did.
> 
> Im using coreboot+seabios and coreboot+grub+encrypted /boot, i could try
> an installation with the original bios/firmware, however this would be
> only for testing-purposes, since it would completely break my my
> security-setup/threat-model.
> 
> They device(x230/i7/16gbram) did run qubes 3:2 so far without any
> issues.(and the very same coreboot images)
> 
> Thanks for the hint, i will play around a bit tomorrow with different
> coreboot images.
> 
> cheers.
> 
> 
> On 01/28/2018 03:56 AM, Yuraeitha wrote:
> >
> > - Are you running the backup through an AppVM? Doing backup in dom0 may 
> > cause bugs or be really slow. I believe this is involved in the 
> > python/admin code in Qubes 4, and is therefore different than it was in 
> > Qubes 3.2. So in Qubes 4, be sure to do it in an AppVM, freshly made in 
> > Qubes 4. The general idea I believe is to allow to network the backup 
> > process, that's why it was made to work in an AppVM. No attention was given 
> > to allow backup in dom0 here, probably on purpose since nothing should be 
> > done in dom0 anyway.
> >
> > - Is the template/AppVM you're using specifically to run the backup based 
> > on a Qubes 4 template/AppVM? While Qubes 3.2. AppVM's can work in Qubes 4, 
> > it's generally my experience that they are more buggy/slow, and work better 
> > if re-made in Qubes 4 and then transfer the files over. Personally I took 
> > no chances and purged all my Qubes 3.2. templates/AppVM's in favour for 
> > fresh Qubes 4 ones. Removing Qubes 3.2. templates is obvious due to likely 
> > code differences in the qubes-core-agent-* packages, etc., but the AppVM is 
> > more controversial without confirmation and based on anecdotal experience. 
> > Generally I experienced improvements by purging Qubes 3.2. AppVM's in 
> > favour for freshly Qubes 4 made ones.
> >
> > - Did you update dom0? I've also seen the qvm-create not working, but this 
> > only happens on a buggy install of Qubes 4, typically with python errors on 
> > the last step during first boot when creating default VM-configuarations 
> > and networking VM's. Generally I solved it either by re-install with 
> > different UEFI/BIOS settings, EFI/Grub settings, UEFI/BIOS update, try 
> > switch between EFI/Grub boot methods, loading different drivers. 
> >
> > Generally the most effective method to get Qubes 4 RC-1/2/3 to work on a 
> > system that I had issues with, was to unplug the drive, put it in a machine 
> > that works with Qubes. Then install Qubes, update it fully, and then put it 
> > back into the first machine again. Usually always work for me on any 
> > machine that on paper should support Qubes. Also Grub is easier to do this, 
> > as EFI paths can be a pain to adjust, they change when moving from a 
> > machine to another, while Grub does not change. Also be careful if you 
> > install on another machine, might be a good idea to remove the other drives 
> > first, just in case. Also EFI installs on a machine with existing EFI paths 
> > may cause issues. 
> > All in all in short, use Grub is recommended here, and also to unplug other 
> > drives on the install machine you use.
> >
> > Assuming you did not update dom0 due to the above bug, then once you get it 
> > updated, everything "should" work much, much better.
> >

Np's :) I hope you succeed!

I've sometimes had longer issues with the UEFI/BIOS settings. I remember once 
when I started using Qubes, I used a couple of days to figure out why I could't 
install Qubes on a z170 Asus motherboard, i5 6500 CPU. Then it turned out it 
was a UEFI/BIOS setting to allow two graphic cards (one intel onboard, the 
other extenal nvidia card). Quite frankly, I was stunned by the cause, 
sometimes it's settings we least expect to cause any problems. The mix of VT-d, 
hypervisors and other exotic things in Qubes, seems to make it more sensitive 
to some UEFI/BIOS settings.

-- 
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/043d86e4-8fec-436e-b2a1-5dc20506957e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: connect to other VMs in qubes by using vm name

On Saturday, January 27, 2018 at 3:45:28 PM UTC+1, Yoganandam Marava wrote:
> by adding forward rules at sysfirewall we can ping each other VM through ip 
> address but not using VM name.
> Is this some thing possible with Qubes 4? I am naive in networking.please 
> suggest if there is a way?
> 
> Thanks

As far as I can tell, it's pretty much the exact same thing in Qubes 4. 
Although I did not verify it, but it looks like it works the same way in Qubes 
4.

I did not quite follow what you meant by using the VM name in the Qubes 
internal networking. Are you not referring to the various Qubes-core-agent-* 
tools here? Like sending files between VM's? Sending files between VM's by a 
VM's name is not networking however. Rather it's a process that happens in dom0 
outside the VM's, transfering the files between the VM's .img files without 
allowing any moved content to touch dom0 (roughly said). I assume this is the 
kind of process you meant by "name"? Generally you'd need something like a DNS 
server between the networked VM's in Qubes if you want to replace IP's with 
names. But I don't think this was ever included in Qubes by default or 
encouraged by the developers? 

By default Qubes discourages any kind of inter-VM networking. Even the Qubes 
tools are not using networking, they're services executed outside the VM's 
reach, which include any kind of networking.

As for the inter-VM networking concept itself, you may want to create a 
separate "network" for any VM's you allow to talk together though, and a 
separate firewall VM for it too. At least in PV virtualization mode 
sophisticated attacks are possible if attacking while two or more VM's running 
at the same time, which becomes more easy if they are networked together. But 
now on HVM/PVH modes, I'm not sure if this particular kind of attack is 
possible, probably not, but it's advanced stuff. Some of these kind of attacks 
have not even been observed in the "wilds" but have been deemed "possible" 
through research. 

But maybe there are other attack vectors that discourage networked VM's to talk 
to each others. For example any attacker may more easily gain access to other 
VM's after having successfully exploited a protocol through the firewall-port, 
of the many or few internet services going through. Here it may not be 
desirable to make it easier for any attacker, although disallowing network 
between VM's probably doesn't make you immune to get attacked in other VM's, 
but at the very least it minimizes possible attack vectors.

It's also important that both VM's have proper secured firewalls in place 
between them.

So by that logic, it may be desirable to create a separate network/firewall for 
any VM's that talk to each others, and consider possible attacks to be an 
increased attack vector for any VM's you added to this parallel Qubes inter-VM 
network. However someone more knowledgeable should probably confirm first if 
this is something useful, redundant or pointless, or perhaps downright 
dangerous to do.

-- 
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/6d0c76f5-9b97-4def-a498-7f9092ab4b3f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: A few bugs in 4.0.rc3

2018-01-27 Thread Jo

Yes, im running the backups trough sys-usb-> extern ssd.The sys-usb is
the default one from the installation.Im doing a complete new setup, for
the very same reasons you mentioned.

Updating (and enabling testingrepos) was the very first thing i did.

Im using coreboot+seabios and coreboot+grub+encrypted /boot, i could try
an installation with the original bios/firmware, however this would be
only for testing-purposes, since it would completely break my my
security-setup/threat-model.

They device(x230/i7/16gbram) did run qubes 3:2 so far without any
issues.(and the very same coreboot images)

Thanks for the hint, i will play around a bit tomorrow with different
coreboot images.

cheers.


On 01/28/2018 03:56 AM, Yuraeitha wrote:
>
> - Are you running the backup through an AppVM? Doing backup in dom0 may cause 
> bugs or be really slow. I believe this is involved in the python/admin code 
> in Qubes 4, and is therefore different than it was in Qubes 3.2. So in Qubes 
> 4, be sure to do it in an AppVM, freshly made in Qubes 4. The general idea I 
> believe is to allow to network the backup process, that's why it was made to 
> work in an AppVM. No attention was given to allow backup in dom0 here, 
> probably on purpose since nothing should be done in dom0 anyway.
>
> - Is the template/AppVM you're using specifically to run the backup based on 
> a Qubes 4 template/AppVM? While Qubes 3.2. AppVM's can work in Qubes 4, it's 
> generally my experience that they are more buggy/slow, and work better if 
> re-made in Qubes 4 and then transfer the files over. Personally I took no 
> chances and purged all my Qubes 3.2. templates/AppVM's in favour for fresh 
> Qubes 4 ones. Removing Qubes 3.2. templates is obvious due to likely code 
> differences in the qubes-core-agent-* packages, etc., but the AppVM is more 
> controversial without confirmation and based on anecdotal experience. 
> Generally I experienced improvements by purging Qubes 3.2. AppVM's in favour 
> for freshly Qubes 4 made ones.
>
> - Did you update dom0? I've also seen the qvm-create not working, but this 
> only happens on a buggy install of Qubes 4, typically with python errors on 
> the last step during first boot when creating default VM-configuarations and 
> networking VM's. Generally I solved it either by re-install with different 
> UEFI/BIOS settings, EFI/Grub settings, UEFI/BIOS update, try switch between 
> EFI/Grub boot methods, loading different drivers. 
>
> Generally the most effective method to get Qubes 4 RC-1/2/3 to work on a 
> system that I had issues with, was to unplug the drive, put it in a machine 
> that works with Qubes. Then install Qubes, update it fully, and then put it 
> back into the first machine again. Usually always work for me on any machine 
> that on paper should support Qubes. Also Grub is easier to do this, as EFI 
> paths can be a pain to adjust, they change when moving from a machine to 
> another, while Grub does not change. Also be careful if you install on 
> another machine, might be a good idea to remove the other drives first, just 
> in case. Also EFI installs on a machine with existing EFI paths may cause 
> issues. 
> All in all in short, use Grub is recommended here, and also to unplug other 
> drives on the install machine you use.
>
> Assuming you did not update dom0 due to the above bug, then once you get it 
> updated, everything "should" work much, much better.
>


-- 
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/c472b4d1-52cd-cdba-eedc-5f27a0211d1b%40seefelder-web.de.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Can I install Qubes 4.0 rc3 on external hard drive?

On Sunday, January 28, 2018 at 2:03:35 AM UTC+1, bill...@gmail.com wrote:
> On Saturday, January 27, 2018 at 6:23:54 PM UTC-5, Yuraeitha wrote:
> > On Friday, January 26, 2018 at 8:45:43 PM UTC+1, bill...@gmail.com wrote:
> > > Thanks so much for your reply and your help.  I installed using legacy 
> > > boot and it worked fine -- in fact, I'm responding from "untrusted 
> > > firefox" right now!  I don't know if qubes comes up in the grub menu yet. 
> > >  I just got this installed, and ran it from the BIOS boot sequence 
> > > Legacy-USB option,  and I'm off for some errands myself.
> > > 
> > > However, in lieu of killing myself with UEFI, since this works, I'll 
> > > stick with it and am a happy camper.  Maybe in the next week I'll play 
> > > around more with UEFI, but I'm going to have to learn a bit more about 
> > > it, I think.
> > > 
> > > Anyway, you made my weekend!  Thanks again for your reply.
> > 
> > I'm glad you got it working! :)
> > 
> > Try run 'qubes-hcl-report' in dom0, and check if HVM, I/O MMU, HAP/SLAT, 
> > TPM, and Remapping, is working properly in your Qubes setup. The top one, 
> > HVM, as far as I know is the most important one. The lowest, remapping, 
> > should with my limited knowledge as far as I can tell, be the least 
> > important of the 5. All of them are relevant for security, and to some 
> > extent, proper working features.
> > 
> > If I'm not mistaken, I haven't ventured into these waters before, and 
> > someone might correct me here. But I believe if a Qubes (or Linux in 
> > general) uses the same partition table as UEFI/EFI (GPT), over the old 
> > out-dated MBR), then it might be possible to switch between UEFI/EFI and 
> > Legacy/BIOS without re-installing a system if retaining the modern GTR 
> > partition table. But it can be tricky if something goes wrong, especially 
> > if you have precious data you don't want to loose. Also UEFI/EFI is heavily 
> > reliant on not having a buggy motherboard firmware, which many 
> > unfortunately have. I also recall having issues not being able to restore 
> > an EFI path for Qubes 4, which used to always work on the same machine on 
> > Qubes 3.2. I'm not sure if this got fixed, it was some months back and 
> > Qubes 4 has rapidly been updated on many ways since then. But this issue is 
> > likely to be Qubes related, or at least partly Qubes related. So it's not 
> > always the hardware that is causing it, although the hardware in this case 
> > might be part-reason still.
> > 
> > Remember to take frequent AppVM backups. If you're learning with the trial 
> > and error method like I do, many things can end up going wrong. For 
> > example, burned my fingers more than a few times my self there before I got 
> > into proper backup habits. Never take that risk, it will eventually go 
> > wrong :')
> 
> I'll do that, probably next week.  Today was my "play with new linuxes" day.  
> Tomorrow is the sabbath for me, and then it's back to the grindstone.   Sigh.

uh yeah, workdays can really get in the way for these things. I have probably 
somewhat similar issues, there are so many things to catch up on. It can be 
fun, but indeed this is really time-consuming, which is already frustratingly 
in short-supply.

-- 
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/ef7549b8-2667-4514-9206-0b1afa6b0292%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: A few bugs in 4.0.rc3

On Sunday, January 28, 2018 at 3:17:05 AM UTC+1, Jo wrote:
> hello guys,
> 
> i played a bit with rc3 and came across the following bugs:
> 
> 
> qvm-backup/restore results in a complete system-shutdown, which is very
> annoying.Using the gui/ qubes-manager instead of the terminal makes no
> difference.
> 
> I will have a look into it/ try to fix it in my spare time these days.
> 
> So far, it looks like its related to fedora-26 templates(both minimal
> and regular ), but appears only with certain templates i have.
> 
> Could be coincidence, tough.
> 
> 
> qvm-sync appmenus removes the menu-entrys systemtools, logut, launch
> terminal emulator etc.
> 
> Logging out/back in does not solve the problem temporally, like in the past.
> 
> Couldnt find a solution/workaround so far, nore was i able to pin down
> exactly what triggers this bug.
> 
> 
> For any hints id be grateful, since im already setting up my new system
> for 4.0 stable.
> 
> 
> btw, have the disp-vm commands changed? qvm-create is not recognized
> anymore.
> 
> cheers.


- Are you running the backup through an AppVM? Doing backup in dom0 may cause 
bugs or be really slow. I believe this is involved in the python/admin code in 
Qubes 4, and is therefore different than it was in Qubes 3.2. So in Qubes 4, be 
sure to do it in an AppVM, freshly made in Qubes 4. The general idea I believe 
is to allow to network the backup process, that's why it was made to work in an 
AppVM. No attention was given to allow backup in dom0 here, probably on purpose 
since nothing should be done in dom0 anyway.

- Is the template/AppVM you're using specifically to run the backup based on a 
Qubes 4 template/AppVM? While Qubes 3.2. AppVM's can work in Qubes 4, it's 
generally my experience that they are more buggy/slow, and work better if 
re-made in Qubes 4 and then transfer the files over. Personally I took no 
chances and purged all my Qubes 3.2. templates/AppVM's in favour for fresh 
Qubes 4 ones. Removing Qubes 3.2. templates is obvious due to likely code 
differences in the qubes-core-agent-* packages, etc., but the AppVM is more 
controversial without confirmation and based on anecdotal experience. Generally 
I experienced improvements by purging Qubes 3.2. AppVM's in favour for freshly 
Qubes 4 made ones.

- Did you update dom0? I've also seen the qvm-create not working, but this only 
happens on a buggy install of Qubes 4, typically with python errors on the last 
step during first boot when creating default VM-configuarations and networking 
VM's. Generally I solved it either by re-install with different UEFI/BIOS 
settings, EFI/Grub settings, UEFI/BIOS update, try switch between EFI/Grub boot 
methods, loading different drivers. 

Generally the most effective method to get Qubes 4 RC-1/2/3 to work on a system 
that I had issues with, was to unplug the drive, put it in a machine that works 
with Qubes. Then install Qubes, update it fully, and then put it back into the 
first machine again. Usually always work for me on any machine that on paper 
should support Qubes. Also Grub is easier to do this, as EFI paths can be a 
pain to adjust, they change when moving from a machine to another, while Grub 
does not change. Also be careful if you install on another machine, might be a 
good idea to remove the other drives first, just in case. Also EFI installs on 
a machine with existing EFI paths may cause issues. 
All in all in short, use Grub is recommended here, and also to unplug other 
drives on the install machine you use.

Assuming you did not update dom0 due to the above bug, then once you get it 
updated, everything "should" work much, much better.

-- 
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/316f8658-ddba-4d9c-b1f9-4a0305415776%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Qubes 4.0-rc3 not installing on Lenovo P71

2018-01-27 Thread joeh9617

On Sunday, January 28, 2018 at 10:30:47 AM UTC+8, awokd wrote:
> On Sun, January 28, 2018 2:13 am, xxx wrote:
> > I burned the ISO to USB stick then started to install Qubes but got the
> > following:
> >
> >
> > [0.093375] ACPI Error: [\SB_.PCIO.XHC_.RHUB.HS11] Namespace lookup
> > failure, AE_NOT_FOUND (20170531/dswload-210) [0.093383] ACPI
> > Exception: AE_NOT_FOUND, During name lookup/catalog
> > (20170531/psobject-252)
> > [0.093539] ACPI Exception: AE_NOT_FOUND, (SSDT:ProjSsdt) while loading
> > table (20170531/tbxfload-220) [0.098243] ACPI Error: 1 table load
> > failures, 12 successful (20170531/tbxfload-246) [2.376031] Couldn't
> > get size: 0x800e [  137.216201] dracut-initqueue[566]:
> 
> Looks like a buggy firmware. See if your manufacturer has a bios update.
> Could maybe try turning off power saving since some messages sort of sound
> related. If you don't care about EFI, you could disable it and boot and
> install in legacy mode. If you want EFI, could try booting Refind, then
> the installer from there.

I just updated the BIOS yesterday through the Lenovo Avantage program.
Starting Windows doesn't present any problems.
I'll check out your other suggestions, 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/df3606ee-3eb1-4c6b-8f9d-a715622ac32b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Qubes 4.0-rc3 not installing on Lenovo P71

On Sun, January 28, 2018 2:33 am, Yuraeitha wrote:

>
> Awkward same-time posting x)
> But listen to awokd, he has more experience than I do.

Not that much more! Unfortunately, on these boot issues most come down to
trial and error like you said...

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

Re: [qubes-users] Qubes 4.0-rc3 not installing on Lenovo P71

On Sunday, January 28, 2018 at 3:30:47 AM UTC+1, awokd wrote:
> On Sun, January 28, 2018 2:13 am, joeh9...@gmail.com wrote:
> > I burned the ISO to USB stick then started to install Qubes but got the
> > following:
> >
> >
> > [0.093375] ACPI Error: [\SB_.PCIO.XHC_.RHUB.HS11] Namespace lookup
> > failure, AE_NOT_FOUND (20170531/dswload-210) [0.093383] ACPI
> > Exception: AE_NOT_FOUND, During name lookup/catalog
> > (20170531/psobject-252)
> > [0.093539] ACPI Exception: AE_NOT_FOUND, (SSDT:ProjSsdt) while loading
> > table (20170531/tbxfload-220) [0.098243] ACPI Error: 1 table load
> > failures, 12 successful (20170531/tbxfload-246) [2.376031] Couldn't
> > get size: 0x800e [  137.216201] dracut-initqueue[566]:
> 
> Looks like a buggy firmware. See if your manufacturer has a bios update.
> Could maybe try turning off power saving since some messages sort of sound
> related. If you don't care about EFI, you could disable it and boot and
> install in legacy mode. If you want EFI, could try booting Refind, then
> the installer from there.

Awkward same-time posting x)
But listen to awokd, he has more experience than I do.

-- 
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/1e71125b-25fc-47f8-8bac-e77bd9131743%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Qubes 4.0-rc3 not installing on Lenovo P71

On Sunday, January 28, 2018 at 3:13:47 AM UTC+1, joeh...@gmail.com wrote:
> I burned the ISO to USB stick then started to install Qubes but got the 
> following:
> 
> [0.093375] ACPI Error: [\SB_.PCIO.XHC_.RHUB.HS11] Namespace lookup 
> failure, AE_NOT_FOUND (20170531/dswload-210)
> [0.093383] ACPI Exception: AE_NOT_FOUND, During name lookup/catalog 
> (20170531/psobject-252)
> [0.093539] ACPI Exception: AE_NOT_FOUND, (SSDT:ProjSsdt) while loading 
> table (20170531/tbxfload-220)
> [0.098243] ACPI Error: 1 table load failures, 12 successful 
> (20170531/tbxfload-246)
> [2.376031] Couldn't get size: 0x800e
> [  137.216201] dracut-initqueue[566]: Warning: Dracut-initqueue timeout - 
> starting timeout scripts
> [  137.779207] dracut-initqueue[566]: Warning: Dracut-initqueue timeout - 
> starting timeout scripts
> [  138.324711] dracut-initqueue[566]: Warning: Dracut-initqueue timeout - 
> starting timeout scripts
> [  138.852226] dracut-initqueue[566]: Warning: Dracut-initqueue timeout - 
> starting timeout scripts
> [  139.395971] dracut-initqueue[566]: Warning: Dracut-initqueue timeout - 
> starting timeout scripts
> .
> .
> .
> 
> This went on for some time, so I switched off and wrote this message.
> I hope there are no serious typos coz I typed this off of a picture taken of 
> the screen.
> 
> Any hints?
> Thanks

I'm by no means an expert on the kernel, but dracut "looks" like kernel errors, 
and "ACPI" (Advanced Configuration and Power Interface) looks like a 
firmware/kernel support mismatch, either by a lack of features, lack of 
development, firmware-bug, kernel-bug, or possibly an un-updated firmware. The 
firmware should be the motherboard (BIOS/UEFI). 

You could start looking in your BIOS/UEFI after settings that may be wrong and 
require adjustments. Is VT-d enabled? Is there a second "Virtualization" that 
needs enabling, for exaple under "Advanced --> CPU" UEFI settings? There can be 
other settings too, it's hard to mention them all, but those two are the most 
important ones, which is sometimes only 1 merged setting.

Does your hardware support VT-d and other Qubes hardware requirements? Does 
Qubes 3.2. run on this hardware? Qubes 4 is known to be more strict to hardware 
requirements and may not work smoothly or may not even install if the hardware 
requirements or security is not correct. Qubes 3.2. is less an issue when 
missing VT-d and similar. This might also be a place to look and confirm. If 
you got Qubes 3.2. running on the machine, then try run in dom0 
"qubes-hcl-report" to see if you meet the requirements. 

However, dracut/ACPI errors doesn't strike me as errors that appear if there 
are issues with the Qubes 4 specific requirements.

You may want to try install with LegacyBIOS/Grub if you tried UEFI/EFI, or vice 
versa, whichever you did not try yet. You can also update your BIOS/UEFI to the 
newest version, however be sure you don't brick your machine. Make sure you 
know any pitfalls as it may make your motherboard break and become useless.

The kernel contains drivers too, the most essential ones, while the modules 
contain extra drivers for the kernel. These errors could also be driver issues, 
for example you may have to edit the EFI or the Grub to pick a different driver 
before starting. Unfortunately I believe you need to edit the /boot/efi/EFI.cfg 
file on the install media, but you can more easily change it live on Grub by 
hovering over the install menu, and thne press "E" key to edit the install menu 
in grub. Here you can change ACPI settings, drivers, virtulization states, 
hide/unhide hardware, and so on.

I'm not sure if it even is a driver issue, I can't see that from the logs, 
whether it can be found there or not. But it's some clues to go with, and maybe 
you can google some up to trial and error. Just be careful, for example few of 
the ACPI settings can be dangerous to your hardwaree, so double-check any 
recommendations you find on the internet. 

Also it may be worth if you can find any ACPI settings in your UEFI/BIOS too.

At any rate, I usually solve these kind of problems with trial and errors 
through experiments. Someone more knowledgeable might drop by with a better 
advice. For now though, some clues you can try start with if you did not do 
them already.

-- 
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/74168688-4fa3-4630-8052-5352536a8f82%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Qubes 4.0-rc3 not installing on Lenovo P71

On Sun, January 28, 2018 2:13 am, joeh9...@gmail.com wrote:
> I burned the ISO to USB stick then started to install Qubes but got the
> following:
>
>
> [0.093375] ACPI Error: [\SB_.PCIO.XHC_.RHUB.HS11] Namespace lookup
> failure, AE_NOT_FOUND (20170531/dswload-210) [0.093383] ACPI
> Exception: AE_NOT_FOUND, During name lookup/catalog
> (20170531/psobject-252)
> [0.093539] ACPI Exception: AE_NOT_FOUND, (SSDT:ProjSsdt) while loading
> table (20170531/tbxfload-220) [0.098243] ACPI Error: 1 table load
> failures, 12 successful (20170531/tbxfload-246) [2.376031] Couldn't
> get size: 0x800e [  137.216201] dracut-initqueue[566]:

Looks like a buggy firmware. See if your manufacturer has a bios update.
Could maybe try turning off power saving since some messages sort of sound
related. If you don't care about EFI, you could disable it and boot and
install in legacy mode. If you want EFI, could try booting Refind, then
the installer from there.

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

[qubes-users] A few bugs in 4.0.rc3

2018-01-27 Thread Jo

hello guys,

i played a bit with rc3 and came across the following bugs:


qvm-backup/restore results in a complete system-shutdown, which is very
annoying.Using the gui/ qubes-manager instead of the terminal makes no
difference.

I will have a look into it/ try to fix it in my spare time these days.

So far, it looks like its related to fedora-26 templates(both minimal
and regular ), but appears only with certain templates i have.

Could be coincidence, tough.


qvm-sync appmenus removes the menu-entrys systemtools, logut, launch
terminal emulator etc.

Logging out/back in does not solve the problem temporally, like in the past.

Couldnt find a solution/workaround so far, nore was i able to pin down
exactly what triggers this bug.


For any hints id be grateful, since im already setting up my new system
for 4.0 stable.


btw, have the disp-vm commands changed? qvm-create is not recognized
anymore.

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/893a293f-afe7-4f00-4eeb-e0d12765b3a6%40seefelder-web.de.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Qubes 4.0-rc3 not installing on Lenovo P71

2018-01-27 Thread joeh9617

I burned the ISO to USB stick then started to install Qubes but got the 
following:

[0.093375] ACPI Error: [\SB_.PCIO.XHC_.RHUB.HS11] Namespace lookup failure, 
AE_NOT_FOUND (20170531/dswload-210)
[0.093383] ACPI Exception: AE_NOT_FOUND, During name lookup/catalog 
(20170531/psobject-252)
[0.093539] ACPI Exception: AE_NOT_FOUND, (SSDT:ProjSsdt) while loading 
table (20170531/tbxfload-220)
[0.098243] ACPI Error: 1 table load failures, 12 successful 
(20170531/tbxfload-246)
[2.376031] Couldn't get size: 0x800e
[  137.216201] dracut-initqueue[566]: Warning: Dracut-initqueue timeout - 
starting timeout scripts
[  137.779207] dracut-initqueue[566]: Warning: Dracut-initqueue timeout - 
starting timeout scripts
[  138.324711] dracut-initqueue[566]: Warning: Dracut-initqueue timeout - 
starting timeout scripts
[  138.852226] dracut-initqueue[566]: Warning: Dracut-initqueue timeout - 
starting timeout scripts
[  139.395971] dracut-initqueue[566]: Warning: Dracut-initqueue timeout - 
starting timeout scripts
.
.
.

This went on for some time, so I switched off and wrote this message.
I hope there are no serious typos coz I typed this off of a picture taken of 
the screen.

Any hints?
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/a41da9e6-8ef4-43e6-ae62-babf1b1f2507%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Looking for an approach to change the borderline between /dev/xvda and /dev/xvdb

Just a heads-up for anyone else reading this thread who may want to try this 
too and is not aware of this pitfall, a warning before trying. Any mistakes 
done in the scripts can make the template unable to start applications. For 
example even if it can boot-up, applications may not start. 

So be very careful to try this on any templates that are used for something 
else, especially important stuff, like sys-net / sys-firewall, or templates 
many AppVM's are based on, making it tough to undo any user-mistakes. 
Recommendable to make a dom0: "qvm-clone template-nr template-nr-clone" before 
editing anything. Thereby only having to worry about the testing template.

-- 
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/6e9f291e-1660-46cd-98f2-56c13a1354d0%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Looking for an approach to change the borderline between /dev/xvda and /dev/xvdb

On Wednesday, January 24, 2018 at 8:32:24 PM UTC+1, Chris Laprise wrote:
> On 01/24/2018 10:55 AM, Yuraeitha wrote:
> 
> > 
> > All 3 suggestions are you guys brought up are really intriguig, I'm pretty 
> > excited about this, these ideas are excellent, even better than I hoped for.
> > 
> > I'm using Qubes 4, so I assume I can't give the beta setup a try until or 
> > if it becomes available on Qubes 4. But I from my initial understanding I 
> > like the extra security it provides, although I've yet to better grasp its 
> > full potential. It seems like a pretty cool project you're working on there 
> > Chris.
> > 
> > Unfortunately I don't have much experience as a coder either, so I can't 
> > make such a script Alex, I can at most read scripts or make simple ones. 
> > But it's a pretty good idea as well, it'd be amazing if someone would want 
> > to make such a bookmark-manager and contribute it to Qubes. Maybe even take 
> > it further and storing the bookmarks outside the VM until a single bookmark 
> > is needed? Similar to keeping i.e. KeePassX in an offline VM? Though I 
> > imagine that would add further complicity, which is definitely outside my 
> > skill-set.
> 
> I'm going to test the Qubes-VM-hardening service on Qubes 4 tonight to 
> see if it needs any adjustment for the whitelisting feature to work. 
> I'll also expand on the (admittedly sparse) instructions.
> 
> If it works then its probably easier to add a service and maintain a 
> single whitelist file.
> 
> 
> > For now I'll try dwell down into the /usr/lib/qubes/init/setup-rw.sh 
> > re-mounting suggestion. It's the only one I have the skill-set and 
> > current-means to pull off on my own. It's been some long exhausting days, 
> > so hopefully I'll get around to try this tomorrow.
> > 
> > I'm currently pondering about how to change the mount points correctly 
> > though. It seems like it has similar logic to traditional Linux mounting 
> > logic, and when combined with Qubes template/appVM logic, then it seems 
> > like I can solve it with some trial and error and exploring-testing, using 
> > your post as an initial starting point. I have some leads now, it'll be 
> > interesting to look into. I'll post pack on how it goes.
> 
> Actually, you don't even need to change the mountpoint, which is done by 
> mount-dirs.sh, BTW. One example is to change the line that starts 
> 'initialize_home' to:
> 
> rm -rf /rw/home-old
> mv /rw/home /rw/home-old
> initialize_home "/rw/home" unconditionally
> 
> ...and then cp or mv files from /rw/home-old as needed.
> 
> 
> -- 
> 
> Chris Laprise, tas...@posteo.net
> https://github.com/tasket
> https://twitter.com/ttaskett
> PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886

Sorry for the delay, it was finally possible to find home-time to play with 
this (the dread of being on the road too much).

I followed your instructions, and it works beautifully!

The change from "ifneeded" to "unconditionally", is it correctly understood to 
be the one that freezes the /rw/home folder at the template: 
/usr/lib/qubes/init/mount-dirs.sh? If so, then I think I understand this part 
of it now. I might do this to all my templates, it's a pretty awesome trick, 
many thanks for sharing/helping! :)

My worries are if updates clean up these scripts though. I know it might be an 
impossible question to answer as anything is likely subject to change whenever, 
but does updates happen to these files frequently? Will the updater warn if 
there are changes? (like i.e. it does if there are changes to /etc/fstab in 
debian templates?). 

Have you considered sharing this as a guide on https://www.qubes-os.org/doc/ on 
this? Of course only if you got the time and interest. Maybe even whether your 
script adjustment can be implemented as a permanent feature of Qubes templates, 
and then people only have to move between the folders in the AppVM, and not do 
anything to the scripts in the template? That'd be pretty neat for those who 
have a hard time getting to the motor under the car's lid, so to speak. I mean, 
it's pretty smart, it even works like before if not moving anything between the 
folders, so people won't even feel any difference if not moving between the 
folders, I assume.

Will be keeping an eye out for when/if you release the VM-hardening beta for 
Qubes 4, no pressure though, can wait till/if you have the time/interest.

-- 
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/9268fb67-8353-45da-b418-a760ebc0e2b9%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Can I install Qubes 4.0 rc3 on external hard drive?

On Saturday, January 27, 2018 at 6:23:54 PM UTC-5, Yuraeitha wrote:
> On Friday, January 26, 2018 at 8:45:43 PM UTC+1, bill...@gmail.com wrote:
> > Thanks so much for your reply and your help.  I installed using legacy boot 
> > and it worked fine -- in fact, I'm responding from "untrusted firefox" 
> > right now!  I don't know if qubes comes up in the grub menu yet.  I just 
> > got this installed, and ran it from the BIOS boot sequence Legacy-USB 
> > option,  and I'm off for some errands myself.
> > 
> > However, in lieu of killing myself with UEFI, since this works, I'll stick 
> > with it and am a happy camper.  Maybe in the next week I'll play around 
> > more with UEFI, but I'm going to have to learn a bit more about it, I think.
> > 
> > Anyway, you made my weekend!  Thanks again for your reply.
> 
> I'm glad you got it working! :)
> 
> Try run 'qubes-hcl-report' in dom0, and check if HVM, I/O MMU, HAP/SLAT, TPM, 
> and Remapping, is working properly in your Qubes setup. The top one, HVM, as 
> far as I know is the most important one. The lowest, remapping, should with 
> my limited knowledge as far as I can tell, be the least important of the 5. 
> All of them are relevant for security, and to some extent, proper working 
> features.
> 
> If I'm not mistaken, I haven't ventured into these waters before, and someone 
> might correct me here. But I believe if a Qubes (or Linux in general) uses 
> the same partition table as UEFI/EFI (GPT), over the old out-dated MBR), then 
> it might be possible to switch between UEFI/EFI and Legacy/BIOS without 
> re-installing a system if retaining the modern GTR partition table. But it 
> can be tricky if something goes wrong, especially if you have precious data 
> you don't want to loose. Also UEFI/EFI is heavily reliant on not having a 
> buggy motherboard firmware, which many unfortunately have. I also recall 
> having issues not being able to restore an EFI path for Qubes 4, which used 
> to always work on the same machine on Qubes 3.2. I'm not sure if this got 
> fixed, it was some months back and Qubes 4 has rapidly been updated on many 
> ways since then. But this issue is likely to be Qubes related, or at least 
> partly Qubes related. So it's not always the hardware that is causing it, 
> although the hardware in this case might be part-reason still.
> 
> Remember to take frequent AppVM backups. If you're learning with the trial 
> and error method like I do, many things can end up going wrong. For example, 
> burned my fingers more than a few times my self there before I got into 
> proper backup habits. Never take that risk, it will eventually go wrong :')

I'll do that, probably next week.  Today was my "play with new linuxes" day.  
Tomorrow is the sabbath for me, and then it's back to the grindstone.   Sigh.

-- 
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/f7cfa1d1-2e89-4327-8c51-cf61944956bb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Anon-whonix browser fails to connect to tor in Qubes 3.2, any ideas?

2018-01-27 Thread 'Xaver' via qubes-users


I would ask on the Whonix Forum. https://forums.whonix.org/


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

Re: [qubes-users] How to get to command line for dom0?

On Wednesday, January 24, 2018 at 3:30:11 AM UTC+1, Kyle Breneman wrote:
> >Note that those directions are about upgrading *templates*, not dom0.
> 
> >Dom0 should generally stay at the fedora release it started at,
> 
> >otherwise you are asking for compatibility trouble.
> 
> 
> Thanks for that clarification, Jean-Philippe.  I successfully upgraded to the 
> Fedora 26 template, but now I want to get rid of my Fedora 23 template.  How 
> do I do that?  (Or shouldn't I do that?)
> 
> 
> Kyle

Once nothing is bound to fedora-23, then you can remove it with "sudo dnf 
remove qubes-template-fedora-23" in your dom0 terminal. (Don't run it yet). Be 
sure fedora-26 works as intended before you remove the old template, i.e. test 
if internet works in sys-net and sys-firewall with the fedora-26 template. 

Run "qubes-global-settings" in dom0, switch any possible fedora-23 to 
fedora-24. Test if the changes work, in particular the dom0 update (just to be 
on the safe side). 

Then run "qvm-ls" in dom0, and detect any possible AppVM running fedora-23. 
Change it with either the GUI VM-settings for each respective AppVM, or use the 
qvm-prefs to do it. Both net same results, whichever you prefer GUI/Terminal.

A bit redundant, but you may also check if the fedora-26 can start on other 
critical VM's, if copy/transfer from/to fedora-26 VM's work, whether their 
internet works, and so on.

Once everything is untied and conirmed working, then you should be able to use 
the "dnf remove" command above mentioned initially.

Any primary templates pre-installed, or primary ones you got from the qubes 
repositories, should only be removed with "sudo dnf remove qubes-template-
'template-name'". Do never, EVER, use "qvm-remove" for these primary templates. 
If I'm not mistaken, this is still possible user-mistake to pull and the system 
won't prevent you from doing this mistake. Any templates you cannot with normal 
means re-name, has RPM update enabled, etc. are typically the ones that are 
primary and require the "sudo dnf remove".

Any template copies of the primary Qubes templates you can remove the same way 
you remove AppVM's, with "qvm-remove VM-name". Just be sure you don't use it on 
the primary ones like fedora-23, fedora-26, debian-8, debian-9, whonix-gw, and 
so on. While fedora-26-copy instead must be removed with "qvm-remove", never 
use qvm-remove on the primary ones.

Also be sure to keep a watch out for when fedora-26 has end-of-life (EoL). 
Check here https://fedoraproject.org/wiki/End_of_life for the known ones. 
Fedora-26 is still unknown, but if you check here 

Quote: "Fedora generally develops new releases over a six month period to 
provide a regular and predictable release schedule. The bi-annual targeted 
release dates are May Day (May 1st) and Halloween (October 31) making them easy 
to remember and for avoiding significant holiday breaks. Changes to this 
standard must be approved by the community-elected Fedora Engineering Steering 
Committee (FESCo)." https://fedoraproject.org/wiki/Fedora_Release_Life_Cycle

Basically, new release every 6 months, but it takes extra time to fully update 
the release to stable, including older versions having further support for a 
while afterwards. They are generally kept updated in rougly 400 days after 
first release. So be sure to check when to upgrade to fedora-27. Qubes will 
still release qubes-based-updates after fedora EoL, so you might get the 
illustion its still maintained, when it's not. Keep an aye out for these dates.

-- 
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/164a0fe6-4e9e-4d50-ba5f-f59f2fa658d5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: [qubes-project] Hosting for OpenQA instance

No one offered yet? Must be someone out there that keep some old 
desktops/laptops laying around.

Can an increase in subscription based donations be of use? For example if, say, 
10 people each donate 10 euro (or alternatively expand any current donation 
subscription with 10 euro), then it should be sufficient to solve this issue?

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

[qubes-users] Re: Can I install Qubes 4.0 rc3 on external hard drive?

On Friday, January 26, 2018 at 8:45:43 PM UTC+1, bill...@gmail.com wrote:
> Thanks so much for your reply and your help.  I installed using legacy boot 
> and it worked fine -- in fact, I'm responding from "untrusted firefox" right 
> now!  I don't know if qubes comes up in the grub menu yet.  I just got this 
> installed, and ran it from the BIOS boot sequence Legacy-USB option,  and I'm 
> off for some errands myself.
> 
> However, in lieu of killing myself with UEFI, since this works, I'll stick 
> with it and am a happy camper.  Maybe in the next week I'll play around more 
> with UEFI, but I'm going to have to learn a bit more about it, I think.
> 
> Anyway, you made my weekend!  Thanks again for your reply.

I'm glad you got it working! :)

Try run 'qubes-hcl-report' in dom0, and check if HVM, I/O MMU, HAP/SLAT, TPM, 
and Remapping, is working properly in your Qubes setup. The top one, HVM, as 
far as I know is the most important one. The lowest, remapping, should with my 
limited knowledge as far as I can tell, be the least important of the 5. All of 
them are relevant for security, and to some extent, proper working features.

If I'm not mistaken, I haven't ventured into these waters before, and someone 
might correct me here. But I believe if a Qubes (or Linux in general) uses the 
same partition table as UEFI/EFI (GPT), over the old out-dated MBR), then it 
might be possible to switch between UEFI/EFI and Legacy/BIOS without 
re-installing a system if retaining the modern GTR partition table. But it can 
be tricky if something goes wrong, especially if you have precious data you 
don't want to loose. Also UEFI/EFI is heavily reliant on not having a buggy 
motherboard firmware, which many unfortunately have. I also recall having 
issues not being able to restore an EFI path for Qubes 4, which used to always 
work on the same machine on Qubes 3.2. I'm not sure if this got fixed, it was 
some months back and Qubes 4 has rapidly been updated on many ways since then. 
But this issue is likely to be Qubes related, or at least partly Qubes related. 
So it's not always the hardware that is causing it, although the hardware in 
this case might be part-reason still.

Remember to take frequent AppVM backups. If you're learning with the trial and 
error method like I do, many things can end up going wrong. For example, burned 
my fingers more than a few times my self there before I got into proper backup 
habits. Never take that risk, it will eventually go wrong :')

-- 
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/fe19c798-c618-4887-aaae-802b8619ec8f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] clock VM

2018-01-27 Thread haaber

> On 01/27/18 22:12, haaber wrote:
>> Hello, all of my appVMs run on random times. I reall having had this
>> issue on Q3.2 but it comes back on Q4.3 - I forgot the solution in the
>> meantime. Qumes-Manager indicates sys-net is ClockVM. How do I configure
>> all AppVM's to fetch time there??  Thank you !! Bernhard
> 
> Do you have a laptop and are you suspending/resuming ? If yes, do you
> have totally random times, or is the clock lagging ? You are right it is a 
> laptop that is sometimes suspended, and yes, all
times are lagging. And they are not lagging randomly, as I first
thought: this mail-VM and dom0 for example are precisely 6h late. My
anon-whonix is exactly 1h late and sys-whonix as well (so the TOR
circuit cannot be set up due to timing errors). qvm-sync-clock (run as
root) does not change anything. This observation, together with the
entire-number of hours delta suggests that I may just need to set
timeszones in each VM correctly! I try that out ... Thank you. Bernhard

-- 
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/9c71cfcf-0c50-9152-d517-ae5181f90b55%40web.de.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] possible editing bug in default KDE setup script

I downloaded and installed KDE today, and it went fine.  Now I am upgrading the 
default fedora-25 template to fedora-26.  I've gone through the downloading and 
all, and am now at the "change default template" part.

So... I click on Applications-> System Tools -> Qubes Global Settings and 
nothing happens.  I try to find out where it's supposed to be, so I click on 
"edit application -> Application" and lo and behold, it has "/user/bin" as the 
Work Path.  I go look in /usr/bin and there it is -- and it runs fine from the 
command line.

I'm pretty confident I didn't type in /user/bin as the work path, since I had 
no clue where it lived and was looking for it.  This may be a copyediting error 
in the script for KDE installation.  Been there, done that.


billo

-- 
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/907a1fa7-1c07-48df-8256-029972f5ac52%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] clock VM

2018-01-27 Thread Ivan Mitev




On 01/27/18 22:12, haaber wrote:

Hello, all of my appVMs run on random times. I reall having had this
issue on Q3.2 but it comes back on Q4.3 - I forgot the solution in the
meantime. Qumes-Manager indicates sys-net is ClockVM. How do I configure
all AppVM's to fetch time there??  Thank you !! Bernhard


Do you have a laptop and are you suspending/resuming ? If yes, do you 
have totally random times, or is the clock lagging ? What happens when 
you run 'qvm-sync-clock' in a VM with the wrong time ?


If you had clock lags and the VM's clock gets synchronized when you run 
qvm-sync-clock, you probably have the same problem I described in issue 
#3489 ([1]).
I tried to debug it the day after I reported it, but I then noticed that 
the problem had gone away by itself (!) and all the VMs' clocks were 
synchronized. I didn't manage to replicate the bug since then so I 
closed the issue, but feel free to reopen.


[1] https://github.com/QubesOS/qubes-issues/issues/3489

--
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/8d2fe569-546e-bfae-b1c1-e67127df8c78%40maa.bz.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] ERROR: Device attach failed

2018-01-27 Thread Ilpo Järvinen

On Sat, 27 Jan 2018, beso wrote:

> On Saturday, January 27, 2018 at 4:33:47 PM UTC+2, awokd wrote:
> > On Sat, January 27, 2018 2:20 pm, beso wrote:
> > 
> > >> On Sat, January 27, 2018 6:31 am, beso wrote:
> > >>
> > >>> ERROR: Device attach failed: /usr/lib/qubes/usb-import: 37: [:
> > >>> Illegal
> > >>> number: stash: printf: I/O error.
> > >>> How to solve this problem?
> > >>>
> > 
> > > Sorry,
> > 
> > No trouble!
> > 
> > > Qubes - 3.2;
> > > Attached device - Samsung M3 Portable 1TB;
> > > Command I used to attach to one of my appVm - qvm-usb -a appvm
> > > sys-net:3-1;
> > 
> > I'm assuming the ";" at the end of sys-net:3-1 is a separator and not
> > actually part of the command you are entering, right? Has this device
> > worked before on your system or is this the first time you are trying it?
> > If it was working before, when did it start giving you the error?
> 
> Yes, that is separator here. No, it never worked.

I'd recommend you use qvm-block instead of qvm-usb (for block capable 
devices such as external HDDs). qvm-block should work even with usb3 
connected devices.

This particular error message you see is caused by a formating change in 
usbip status file for 4.9 kernels that is incompatible what 
qubes-usb-proxy expects.

There's an updated version for qubes-usb-proxy in R3.2 testing repo 
that is capable of getting past this error (but ironically, even there 
there is inconsistency between assumed status file format and what 4.9 
prints but it luckily affects only unused variables). However, qvm-usb 
will fail in R3.2 with even if this error is fixed based on the 
testing I did yesterday: usbip doesn't seem to, e.g., fall-back to 
highspeed but attempts to use superspeed that is only supported starting 
4.13 kernel and you just get a different error message.

-- 
 i.

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

[qubes-users] clock VM

2018-01-27 Thread haaber

Hello, all of my appVMs run on random times. I reall having had this
issue on Q3.2 but it comes back on Q4.3 - I forgot the solution in the
meantime. Qumes-Manager indicates sys-net is ClockVM. How do I configure
all AppVM's to fetch time there??  Thank you !! Bernhard

-- 
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/226dbaea-92bc-5229-600b-509e0348f3cd%40web.de.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Qubes 4.0 Documentation

2018-01-27 Thread Marek Marczykowski-Górecki

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On Fri, Jan 26, 2018 at 11:37:31PM -0600, Andrew David Wong wrote:
> On 2018-01-26 05:14, awokd wrote:
> > On Fri, January 26, 2018 3:36 am, Andrew David Wong wrote:
> >> On 2018-01-25 12:28, awokd wrote:
> >>> 1. Should I open an issue for tracking and move the discussion 
> >>> over there? Move to qubes-devel? Keep here?
> >> 
> >> Please open an issue in qubes-issues.
> > 
> > https://github.com/QubesOS/qubes-issues/issues/3495
> > 
> > 
> >> I agree that the tool man pages should not be shared between 3.2
> >> and 4.0 (but they probably wouldn't be anyway, due to the nature
> >> of the system just described).
> > 
> > What will be the naming convention for direct links? I can see
> > sometimes we'd want to link to the latest version of qvm-whatever,
> > and other times when we want to link to a specific major version.
> > 
> 
> We could either have different subdirectories for each version or
> include the version in the page name, as we do for some other
> version-specific pages.

I'd go with different subdirectories - it will be easier to handle (both
generate and later reference).

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

iQEzBAEBCAAdFiEEhrpukzGPukRmQqkK24/THMrX1ywFAlps18QACgkQ24/THMrX
1yyZ8Af+P6P0CjFiUiW1HdMHe5NCje/ZxjJxpSE+HXLPT/2Hr+Bhm/CjIGXS7cOr
/IO920qG3+c6EmDxBplIDCCaov5xz3jxWih5JjtRR9FUx29yCGwm9Fu2vHPiiaDJ
RvEmTFRfkGgsm3EOJ1U/j7uao7uuMPrpRmyVNyWWIKHKPk6S/DmBodVQepl7uE2Q
Mw/uXITtl3EaBfGoN/W6lnCNc0/0E6wPLUv6rsMaeSEAcihzRlrzAXDDdcNYWMQL
EWEYV/mqdXjtksqtzLMCpQwiCkuGBOhIptQjRZ3DqBPQZQm5eQH4+tbytBR63nby
tQqOXmUDWjBFdj3UuulZkQVbRUxNuw==
=6lu1
-END PGP SIGNATURE-

-- 
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/20180127194924.GF2653%40mail-itl.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Qubes 4.0 Documentation

2018-01-27 Thread 'Tom Zander' via qubes-users

On Thursday, 25 January 2018 19:28:58 CET 'awokd' via qubes-users wrote:
> 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:

Awesome!

I was thinking about the qubes docs when I saw a wiki that had a banner for 
articles (or sections) that were known to be "disputed".

I was wondering if it might be useful to have such a concept on the doc 
pages, it may invite people to actually add their knowledge.

-- 
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel


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

[qubes-users] Re: Network turns off when I close laptop lid, and I can't restart it

That was it!  Thanks, folks.  Problem is solved.

billo

-- 
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/8c86efcd-629d-4b33-97f7-2a692dd02e41%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Network turns off when I close laptop lid, and I can't restart it

2018-01-27 Thread 'MirrorWay' via qubes-users

workarounds, fixes: https://github.com/QubesOS/qubes-issues/issues/3486

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

Re: [qubes-users] Network turns off when I close laptop lid, and I can't restart it

2018-01-27 Thread haaber

On 01/27/2018 12:26 PM, billol...@gmail.com wrote:
> I recently installed Qubes 4 rc3 on my Dell laptop, and it seems to working 
> well.  However, there's a little bit of a problem with my networking.  It 
> comes up fine when I reboot the machine, and runs like a charm... but when I 
> close the laptop lid, networking turns off, and I can't figure out how to get 
> it restarted without rebooting.
> 
> I'm currently running KDE as my desktop, but it happened in the default as 
> well.
> 
> 
> I have tried the following.  In the KDE systems utilities gui, I went to 
> power management and turned off all the actions on lid closure, power 
> decline, etc. hoping to keep it from turning off at all.  That didn't seem to 
> change anything.
> 
> I wandered over to the sys-net domain and looked around.  When the network is 
> running, ifconfig shows the wireless interface wls5, as well as vif3.0,lo,and 
> ens6.  Once I close the lid, wls5 disappears though the others are unchanged.
> 
> 
> ps -ef | grep Network provides /usr/bin/NetworkManager --nodaemon and 
> sbin/dhclient with a zillion options.
> 
> after I close the lid, only /usr/bin/NetworkManager is running.
> 
> When the network goes off, I have tried 
> 
> service networking restart in sys-net domain, and I get [OK] back, but 
> nothing changes.  I tried "service network-manager restart" and "service 
> NetworkManager restart" but they come up as not existing.
> 
> So... how to I re-initialize networking and NetworkManager when the crump, 
> and how to do stop it from doing that on lid closing?
Did you check out the blacklisting section here ?
https://www.qubes-os.org/doc/wireless-troubleshooting/
Good luck! Bernhard

-- 
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/99ffd58e-c441-fc5f-5e12-ae3aaf30581c%40web.de.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Network turns off when I close laptop lid, and I can't restart it

I recently installed Qubes 4 rc3 on my Dell laptop, and it seems to working
well. However, there's a little bit of a problem with my networking. It comes
up fine when I reboot the machine, and runs like a charm... but when I close
the laptop lid, networking turns off, and I can't figure out how to get it
restarted without rebooting.

I'm currently running KDE as my desktop, but it happened in the default as well.

I have tried the following. In the KDE systems utilities gui, I went to power
management and turned off all the actions on lid closure, power decline, etc.
hoping to keep it from turning off at all. That didn't seem to change anything.

I wandered over to the sys-net domain and looked around. When the network is
running, ifconfig shows the wireless interface wls5, as well as vif3.0,lo,and
ens6. Once I close the lid, wls5 disappears though the others are unchanged.

ps -ef | grep Network provides /usr/bin/NetworkManager --nodaemon and
sbin/dhclient with a zillion options.

after I close the lid, only /usr/bin/NetworkManager is running.

When the network goes off, I have tried

service networking restart in sys-net domain, and I get [OK] back, but nothing
changes. I tried "service network-manager restart" and "service NetworkManager
restart" but they come up as not existing.

So... how to I re-initialize networking and NetworkManager when the crump, and
how to do stop it from doing that on lid closing?

Thanks!

billo

--
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/b17b799e-351f-48a0-9c2f-ccc364b4ce05%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Newbie question on KDE configuration

I installed Qubes 4 rc3 yesterday and am having a great time exploring it. I'm
kind of a KDE person, so I installed KDE, and it works pretty much like a
charm, though I'm having a bit of an issue personalizing it.

If anybody can give me some aid, I'd appreciate it.

First, while KDE seems to be working well, I noticed that I can't download and
install new themes, widgets, etc. through the KDE GUI. It can't connect to the
KDE server. I'm assuming that this is because dom0 doesn't actually have a
network connection (which I think I read somewhere). It's not the end of the
world for me to download the stuff from kde.org and install it from file, but
it's more convenient to use the gui interface. What I need to know is if it is
possible or should I move on and just do it by hand.

Second, I really liked that convention in the default window manager for having
a different color for the title bar for each domain. That got lost when I
moved to KDE, though the domain is still *listed* in the title bar. I know how
to set colors in kwin on an application by application basis, but I don't know
how to do it on a domain basis. Is there a mechanism for that in KDE?

Thanks in advance!

billo

--
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/1b7feb42-45a1-4ded-8995-f3f27e64d718%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] ERROR: Device attach failed

On Sat, January 27, 2018 3:00 pm, beso wrote:
> On Saturday, January 27, 2018 at 4:33:47 PM UTC+2, awokd wrote:
>
>> On Sat, January 27, 2018 2:20 pm, beso wrote:
>>
>>
 On Sat, January 27, 2018 6:31 am, beso wrote:


> ERROR: Device attach failed: /usr/lib/qubes/usb-import: 37: [:
> Illegal
> number: stash: printf: I/O error.
> How to solve this problem?
>
>
>>
>>> Sorry,
>>>
>>
>> No trouble!
>>
>>
>>> Qubes - 3.2;
>>> Attached device - Samsung M3 Portable 1TB;
>>> Command I used to attach to one of my appVm - qvm-usb -a appvm
>>> sys-net:3-1;
>>>
>>
>> I'm assuming the ";" at the end of sys-net:3-1 is a separator and not
>> actually part of the command you are entering, right? Has this device
>> worked before on your system or is this the first time you are trying
>> it? If it was working before, when did it start giving you the error?
>>
>
> Yes, that is separator here. No, it never worked.

If you're running through an external USB hub, try a direct port. I've
also seen some people have had trouble with USB 3.0, so use a 2.0 direct
port if possible. If neither of those help, hopefully someone else will
have a better idea!



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

Re: [qubes-users] Anon-whonix browser fails to connect to tor in Qubes 3.2, any ideas?

2018-01-27 Thread code9n

Yeh, the anon-whonix app vm is routed through sys-whonix properly.  I haven't 
changed that from default.
I do route most non-whonix app vms through a vpn in a proxy vm but that all 
works as it should.
Both systems have worked independently and as expected for months.

Checking today some IP address checks in the anon-whonix app vm do come out in 
places other than Germany but they're not my vpn's servers, or my ISP's.
It's like tor is mostly working but not fully.

I'll leave this help request here and see if there are any more suggestions but 
if I have to I'll try deleting the var/lib/tor file contents  - the tor data 
file mentioned above - and if it doesn't work try re-installing all the whonix 
stuff.

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/5a5d2c4f-a3db-4579-8ed0-74e573c8e574%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] ERROR: Device attach failed

2018-01-27 Thread beso

On Saturday, January 27, 2018 at 4:33:47 PM UTC+2, awokd wrote:
> On Sat, January 27, 2018 2:20 pm, beso wrote:
> 
> >> On Sat, January 27, 2018 6:31 am, beso wrote:
> >>
> >>> ERROR: Device attach failed: /usr/lib/qubes/usb-import: 37: [:
> >>> Illegal
> >>> number: stash: printf: I/O error.
> >>> How to solve this problem?
> >>>
> 
> > Sorry,
> 
> No trouble!
> 
> > Qubes - 3.2;
> > Attached device - Samsung M3 Portable 1TB;
> > Command I used to attach to one of my appVm - qvm-usb -a appvm
> > sys-net:3-1;
> 
> I'm assuming the ";" at the end of sys-net:3-1 is a separator and not
> actually part of the command you are entering, right? Has this device
> worked before on your system or is this the first time you are trying it?
> If it was working before, when did it start giving you the error?

Yes, that is separator here. No, it never worked.

-- 
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/2b2e84f6-77f9-4d82-a72e-91e43d6c872a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] connect to other VMs in qubes by using vm name

2018-01-27 Thread Yoganandam Marava

by adding forward rules at sysfirewall we can ping each other VM through ip 
address but not using VM name.
Is this some thing possible with Qubes 4? I am naive in networking.please 
suggest if there is a way?

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/2a6cd289-246d-4489-bda5-58544d5db0fd%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] ERROR: Device attach failed

On Sat, January 27, 2018 2:20 pm, beso wrote:

>> On Sat, January 27, 2018 6:31 am, beso wrote:
>>
>>> ERROR: Device attach failed: /usr/lib/qubes/usb-import: 37: [:
>>> Illegal
>>> number: stash: printf: I/O error.
>>> How to solve this problem?
>>>

> Sorry,

No trouble!

> Qubes - 3.2;
> Attached device - Samsung M3 Portable 1TB;
> Command I used to attach to one of my appVm - qvm-usb -a appvm
> sys-net:3-1;

I'm assuming the ";" at the end of sys-net:3-1 is a separator and not
actually part of the command you are entering, right? Has this device
worked before on your system or is this the first time you are trying it?
If it was working before, when did it start giving you the error?


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

Re: [qubes-users] ERROR: Device attach failed

2018-01-27 Thread beso

On Saturday, January 27, 2018 at 3:58:35 PM UTC+2, awokd wrote:
> On Sat, January 27, 2018 6:31 am, beso wrote:
> > ERROR: Device attach failed: /usr/lib/qubes/usb-import: 37: [: Illegal
> > number: stash: printf: I/O error.
> > How to solve this problem?
> 
> Not to sound cranky, but can you review
> https://www.qubes-os.org/mailing-lists/ Discussion list guidelines?
> There's not enough information in your question to be able to answer it.
> For example: Qubes version, type of USB device, speed of USB device,
> command or method you are using to attach it, etc.

Sorry,

Qubes - 3.2;
Attached device - Samsung M3 Portable 1TB;
Command I used to attach to one of my appVm - qvm-usb -a appvm sys-net:3-1;

-- 
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/a7284e2d-3eff-4290-b28e-4746f3978853%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Anon-whonix browser fails to connect to tor in Qubes 3.2, any ideas?