date:20180813

I have to work with VMWare images often, so I would like them to be run in 
Qubes.
They gave me a Windows 10 and a Kali vmware virtual machines.
Many people, including myself, have tested these as working in VMWare Player.  
There isn't a problem with the source.

The vmx files only points to the images I am converting, so I don't think I am 
missing something there.

-

$ file C-Drive.vmdk
C-Drive.vmdk: VMware4 disk image

$ qemu-img info C-Drive.vmdk
image: C-Drive.vmdk
file format: vmdk
virtual size: 100G (107374182400 bytes)
disk size: 13G
cluster_size: 65536
Format specific information:
cid: 1024382763
parent cid: 4294967295
create type: monolithicSparse
extents:
[0]:
virtual size: 107374182400
filename: C-Drive.vmdk
cluster size: 65536
format:

$ qemu-img convert -f vmdk C-Drive.vmdk -O raw Win10.raw

$ file Win10.raw
Win10.raw: DOS/MBR boot sector MS-MBR Windows 7 english at offset 0x163 
"Invalid partition table" at offset 0x17b "Error loading operating system" at 
offset 0x19a "Missing operating system", disk signature 0x8d1c10fa; partition 1 
: ID=0x7, active, start-CHS (0x0,32,33), end-CHS (0x3ff,254,63), startsector 
2048, 209711104 sectors

$ qemu-img info Win10.raw
image: Win10.raw
file format: raw
virtual size: 100G (107374182400 bytes)
disk size: 12G

$ sudo fdisk -l Win10.raw 
Disk Win10.raw: 100 GiB, 107374182400 bytes, 209715200 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x8d1c10fa

Device  Boot Start   End   Sectors  Size Id Type
Win10.raw1 * 2048 209713151 209711104  100G  7 HPFS/NTFS/exFAT

--

$ qvm-create --verbose Win10 --class StandaloneVM --property virt_mode=hvm 
--property kernel='' --property memory=4096 --property maxmem=4096 --label=red 
--root-copy-from Win10.raw

When I start the VM... it boots to the Windows "Diagnostics" menu, and any 
attempts to fix/repair fail.
I have tried booting this VM to a Windows 10 iso to see if it could repair it 
too, no luck.

==

The Kali VM is similar, in that it will not boot using this convert to raw 
method.  It boots to the grub rescue menu.

The only difference between Kali and Windows VMware, is that Kali disk was 
split into a span of 8 vmdk's.  But qemu-img does create a single raw image as 
expected.

$ qemu-img convert -f vmdk *.vmdk -O raw Kali.img

$ qemu-img info Kali.img 
image: Kali.img
file format: raw
virtual size: 60G (64424509440 bytes)
disk size: 19G

$ file Kali.img 
Kali.img: DOS/MBR boot sector; partition 1 : ID=0x82, active, start-CHS 
(0x3ff,254,63), end-CHS (0x3ff,254,63), startsector 123179008, 2648064 sectors

$ sudo fdisk -l Kali.img 
Disk Kali.img: 60 GiB, 64424509440 bytes, 125829120 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xaaea4a6f

Device Boot Start   End Sectors  Size Id Type
Kali.img1 *123179008 125827071 2648064  1.3G 82 Linux swap / Solaris



I've tried qvm-start with hddisk and cdrom option.  No luck there.
I've tried using VMWare's "ovftool" to package the vm, tar extract the single 
new vmdk, then convert to raw.
I've tried converting to qcow2.  
And tried running "testdisk" to find and fix MBR and partition tables.

I can mount the images to view the file systems if I want.  But somewhere in 
the conversion (qemu-img) or the VM creation (qvm-create ... root-copy-from), 
the MBR or partitioning gets screwed up and cannot boot.  I need to boot and 
run these VMs.

But I am lost.  It would seem straight forward, as everywhere I look on the 
internet, converting to raw is pretty easy and should work in Qubes 4.

-- 
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/aeab97c6-4bab-46f5-bea9-6feb15d4eb58%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] VMWare vmdk converted to raw image files, will not boot (Linux or Windows)

I have to work with VMWare images often, so I would like them to be run in 
Qubes.
They gave me a Windows 10 and a Kali vmware virtual machines.

Many people, including myself, have tested these as working in VMWare Player.  
There isn't a problem with the source.

The vmx files only points to the images I am converting, so I don't think I am 
missing something there.

-

$ file C-Drive.vmdk
C-Drive.vmdk: VMware4 disk image

$ qemu-img info C-Drive.vmdk
image: C-Drive.vmdk
file format: vmdk
virtual size: 100G (107374182400 bytes)
disk size: 13G
cluster_size: 65536
Format specific information:
cid: 1024382763
parent cid: 4294967295
create type: monolithicSparse
extents:
[0]:
virtual size: 107374182400
filename: C-Drive.vmdk
cluster size: 65536
format: 

$ qemu-img convert -f vmdk C-Drive.vmdk -O raw Win10.raw

$ file Win10.raw
Win10.raw: DOS/MBR boot sector MS-MBR Windows 7 english at offset 0x163 
"Invalid partition table" at offset 0x17b "Error loading operating system" at 
offset 0x19a "Missing operating system", disk signature 0x8d1c10fa; partition 1 
: ID=0x7, active, start-CHS (0x0,32,33), end-CHS (0x3ff,254,63), startsector 
2048, 209711104 sectors

$ qemu-img info Win10.raw
image: Win10.raw
file format: raw
virtual size: 100G (107374182400 bytes)
disk size: 12G

$ sudo fdisk -l Win10.raw 
Disk Win10.raw: 100 GiB, 107374182400 bytes, 209715200 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0x8d1c10fa

Device  Boot Start   End   Sectors  Size Id Type
Win10.raw1 * 2048 209713151 209711104  100G  7 HPFS/NTFS/exFAT

--

$ qvm-create --verbose Win10 --class StandaloneVM --property virt_mode=hvm 
--property kernel='' --property memory=4096 --property maxmem=4096 --label=red 
--root-copy-from Win10.raw

When I start the VM... it boots to the Windows "Diagnostics" menu, and any 
attempts to fix/repair fail.
I have tried booting this VM to a Windows 10 iso to see if it could repair it 
too, no luck.

==

The Kali VM is similar, in that it will not boot using this convert to raw 
method.  It boots to the grub rescue menu.

The only difference between Kali and Windows VMware, is that Kali disk was 
split into a span of 8 vmdk's.  But qemu-img does create a single raw image as 
expected.

$ qemu-img convert -f vmdk *.vmdk -O raw Kali.img 

$ qemu-img info Kali.img 
image: Kali.img
file format: raw
virtual size: 60G (64424509440 bytes)
disk size: 19G

$ file Kali.img 
Kali.img: DOS/MBR boot sector; partition 1 : ID=0x82, active, start-CHS 
(0x3ff,254,63), end-CHS (0x3ff,254,63), startsector 123179008, 2648064 sectors

$ sudo fdisk -l Kali.img 
Disk Kali.img: 60 GiB, 64424509440 bytes, 125829120 sectors
Units: sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disklabel type: dos
Disk identifier: 0xaaea4a6f

Device Boot Start   End Sectors  Size Id Type
Kali.img1 *123179008 125827071 2648064  1.3G 82 Linux swap / Solaris



I can mount drives and/or partitions to view the file systems.  But somewhere 
in the conversion (qemu-img) or the VM creation (qvm-create ... root-copy-from)

I've tried qvm-start with hddisk and cdrom option.  No luck there.
I've tried using VMWare's "ovftool" to package the vm, tar extract the single 
new vmdk, then convert to raw.
I've tried converting to qcow2.  
And tried running "testdisk" to find and fix MBR and partition tables.

But I am lost.  It would seem straight forward, as everywhere I look on the 
internet, converting to raw is pretty easy and should work in Qubes 4.


-- 
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/25a5af10-101c-464f-8de4-a0be3336ef8a%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Android-x86 on Qubes 4

On Wednesday, August 8, 2018 at 9:37:53 PM UTC+8, rex mat wrote:
> After the manual install, I can boot, but ethernet can only be configured 
> from the terminal. That is still work in progress.
> You need to have an android-x86 build and check out the 7.1.2 version to 
> build a cd. I found the instruction on the web on the android-x86.org web 
> page. I recommend using the ubuntu 16.4 version mentioned as the preferred 
> build machine in a hope you avoid the pain I went through to do a build on 
> qubes. 
> 
> 
> 
> I did the following 2 changes:
> 
> 
> 
> 1. Changed 1 line in "init" inside initrd
> from:
> 
>     for device in ${ROOT:-/dev/[hmnsv][dmrv][0-9a-z]*}; do
> to:
> 
>     for device in ${ROOT:-/dev/[hmnsvx][dmrv][0-9a-z]*}; do
> That allows the XEN hard drive to be used at initialization
> 
> 
> 
> 2. I configured the kernel
> Below is the config (I hope, as I played afterwards to get a proper mouse, 
> with no avail). This config disabled a lot of things that need blobs and the 
> like to get it built:
> 
> #
> # Automatically generated file; DO NOT EDIT.
> # Linux/x86_64 4.9.109 Kernel Configuration
> #
> CONFIG_64BIT=y
> CONFIG_X86_64=y
> CONFIG_X86=y
> CONFIG_INSTRUCTION_DECODER=y
> CONFIG_OUTPUT_FORMAT="elf64-x86-64"
> CONFIG_ARCH_DEFCONFIG="arch/x86/configs/x86_64_defconfig"
> CONFIG_LOCKDEP_SUPPORT=y
> CONFIG_STACKTRACE_SUPPORT=y
> CONFIG_MMU=y
> CONFIG_ARCH_MMAP_RND_BITS_MIN=28
> CONFIG_ARCH_MMAP_RND_BITS_MAX=32
> CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MIN=8
> CONFIG_ARCH_MMAP_RND_COMPAT_BITS_MAX=16
> CONFIG_NEED_DMA_MAP_STATE=y
> CONFIG_NEED_SG_DMA_LENGTH=y
> CONFIG_GENERIC_ISA_DMA=y
> CONFIG_GENERIC_BUG=y
> CONFIG_GENERIC_BUG_RELATIVE_POINTERS=y
> CONFIG_GENERIC_HWEIGHT=y
> CONFIG_ARCH_MAY_HAVE_PC_FDC=y
> CONFIG_RWSEM_XCHGADD_ALGORITHM=y
> CONFIG_GENERIC_CALIBRATE_DELAY=y
> CONFIG_ARCH_HAS_CPU_RELAX=y
> CONFIG_ARCH_HAS_CACHE_LINE_SIZE=y
> CONFIG_HAVE_SETUP_PER_CPU_AREA=y
> CONFIG_NEED_PER_CPU_EMBED_FIRST_CHUNK=y
> CONFIG_NEED_PER_CPU_PAGE_FIRST_CHUNK=y
> CONFIG_ARCH_HIBERNATION_POSSIBLE=y
> CONFIG_ARCH_SUSPEND_POSSIBLE=y
> CONFIG_ARCH_WANT_HUGE_PMD_SHARE=y
> CONFIG_ARCH_WANT_GENERAL_HUGETLB=y
> CONFIG_ZONE_DMA32=y
> CONFIG_AUDIT_ARCH=y
> CONFIG_ARCH_SUPPORTS_OPTIMIZED_INLINING=y
> CONFIG_ARCH_SUPPORTS_DEBUG_PAGEALLOC=y
> CONFIG_X86_64_SMP=y
> CONFIG_ARCH_SUPPORTS_UPROBES=y
> CONFIG_FIX_EARLYCON_MEM=y
> CONFIG_DEBUG_RODATA=y
> CONFIG_PGTABLE_LEVELS=4
> CONFIG_DEFCONFIG_LIST="/lib/modules/$UNAME_RELEASE/.config"
> CONFIG_IRQ_WORK=y
> CONFIG_BUILDTIME_EXTABLE_SORT=y
> CONFIG_THREAD_INFO_IN_TASK=y
> 
> #
> # General setup
> #
> CONFIG_INIT_ENV_ARG_LIMIT=32
> CONFIG_CROSS_COMPILE=""
> # CONFIG_COMPILE_TEST is not set
> CONFIG_LOCALVERSION="-android-x86_64"
> CONFIG_LOCALVERSION_AUTO=y
> CONFIG_HAVE_KERNEL_GZIP=y
> CONFIG_HAVE_KERNEL_BZIP2=y
> CONFIG_HAVE_KERNEL_LZMA=y
> CONFIG_HAVE_KERNEL_XZ=y
> CONFIG_HAVE_KERNEL_LZO=y
> CONFIG_HAVE_KERNEL_LZ4=y
> CONFIG_KERNEL_GZIP=y
> # CONFIG_KERNEL_BZIP2 is not set
> # CONFIG_KERNEL_LZMA is not set
> # CONFIG_KERNEL_XZ is not set
> # CONFIG_KERNEL_LZO is not set
> # CONFIG_KERNEL_LZ4 is not set
> CONFIG_DEFAULT_HOSTNAME="android_x86_64"
> CONFIG_SWAP=y
> # CONFIG_SYSVIPC is not set
> # CONFIG_POSIX_MQUEUE is not set
> CONFIG_CROSS_MEMORY_ATTACH=y
> # CONFIG_FHANDLE is not set
> # CONFIG_USELIB is not set
> CONFIG_AUDIT=y
> CONFIG_HAVE_ARCH_AUDITSYSCALL=y
> CONFIG_AUDITSYSCALL=y
> CONFIG_AUDIT_WATCH=y
> CONFIG_AUDIT_TREE=y
> 
> #
> # IRQ subsystem
> #
> CONFIG_GENERIC_IRQ_PROBE=y
> CONFIG_GENERIC_IRQ_SHOW=y
> CONFIG_GENERIC_PENDING_IRQ=y
> CONFIG_GENERIC_IRQ_CHIP=y
> CONFIG_IRQ_DOMAIN=y
> CONFIG_IRQ_DOMAIN_HIERARCHY=y
> CONFIG_GENERIC_MSI_IRQ=y
> CONFIG_GENERIC_MSI_IRQ_DOMAIN=y
> # CONFIG_IRQ_DOMAIN_DEBUG is not set
> CONFIG_IRQ_FORCED_THREADING=y
> CONFIG_SPARSE_IRQ=y
> CONFIG_CLOCKSOURCE_WATCHDOG=y
> CONFIG_ARCH_CLOCKSOURCE_DATA=y
> CONFIG_CLOCKSOURCE_VALIDATE_LAST_CYCLE=y
> CONFIG_GENERIC_TIME_VSYSCALL=y
> CONFIG_GENERIC_CLOCKEVENTS=y
> CONFIG_GENERIC_CLOCKEVENTS_BROADCAST=y
> CONFIG_GENERIC_CLOCKEVENTS_MIN_ADJUST=y
> CONFIG_GENERIC_CMOS_UPDATE=y
> 
> #
> # Timers subsystem
> #
> CONFIG_TICK_ONESHOT=y
> CONFIG_NO_HZ_COMMON=y
> # CONFIG_HZ_PERIODIC is not set
> CONFIG_NO_HZ_IDLE=y
> # CONFIG_NO_HZ_FULL is not set
> CONFIG_NO_HZ=y
> CONFIG_HIGH_RES_TIMERS=y
> 
> #
> # CPU/Task time and stats accounting
> #
> CONFIG_TICK_CPU_ACCOUNTING=y
> # CONFIG_VIRT_CPU_ACCOUNTING_GEN is not set
> # CONFIG_IRQ_TIME_ACCOUNTING is not set
> # CONFIG_SCHED_WALT is not set
> CONFIG_BSD_PROCESS_ACCT=y
> # CONFIG_BSD_PROCESS_ACCT_V3 is not set
> CONFIG_TASKSTATS=y
> CONFIG_TASK_DELAY_ACCT=y
> CONFIG_TASK_XACCT=y
> CONFIG_TASK_IO_ACCOUNTING=y
> 
> #
> # RCU Subsystem
> #
> CONFIG_PREEMPT_RCU=y
> # CONFIG_RCU_EXPERT is not set
> CONFIG_SRCU=y
> # CONFIG_TASKS_RCU is not set
> CONFIG_RCU_STALL_COMMON=y
> # CONFIG_TREE_RCU_TRACE is not set
> # CONFIG_RCU_EXPEDITE_BOOT is not set
> CONFIG_BUILD_BIN2C=y
> CONFIG_IKCONFIG=y
> CONFIG_IKCONFIG_PROC=y
> CONFIG_LOG_BUF_SHIFT=17
>

[qubes-users] Re: X470 and IOMMU Groups...

On Thursday, August 9, 2018 at 1:30:49 AM UTC+8, 3mp...@gmail.com wrote:
> Hi everyone,
> 
> actually I'm a happy Qubes 3.2 user on Intel platform for more than a year 
> now !
> 
> I'm looking to upgrade my actual Skylake build with an AMD one with the new 
> Ryzen Pinnacle Ridge CPU (R7 2700) and installing Qubes 4.0 on the same 
> occasion. The Asrock X470 Taichi seems a really nice motherboard for it.
> 
> I've found the IOMMU Groups of this motherboard on reddit : 
> https://www.reddit.com/r/VFIO/comments/8i8yqq/iommu_groups_for_asrock_taichi_x470/
> 
> and it seems there's a big group 13 with LAN, USB and SATA controllers. I 
> wonder if the netVM and USB VM will actually be able to passthrough these 
> controllers if they are in the same IOMMU Group ?
> 
> Any Ryzen / Qubes users can confirm this works OK or this is a no go ?
> 
> Thanks for your help !

I've observed that Qubes installation rarely ever succeeds on X370 motherboards 
so I believe the same case applies to X470 motherboards with a higher chance of 
failure since it is newer. The reason for this I believe is because these 
high-end gaming motherboards have alot of functionalities/bugs that 
break/interfere with Qubes installation which is an awful letdown.

So while that mobo having separate IOMMU groups being a plus, it doesn't matter 
much when you're still in the installation phase of Qubes (Which is the real 
hard phase to overcome when it comes to Qubes).

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

[qubes-users] Re: X470 and IOMMU Groups...

On Thursday, August 9, 2018 at 1:30:49 AM UTC+8, 3mp...@gmail.com wrote:
> Hi everyone,
> 
> actually I'm a happy Qubes 3.2 user on Intel platform for more than a year 
> now !
> 
> I'm looking to upgrade my actual Skylake build with an AMD one with the new 
> Ryzen Pinnacle Ridge CPU (R7 2700) and installing Qubes 4.0 on the same 
> occasion. The Asrock X470 Taichi seems a really nice motherboard for it.
> 
> I've found the IOMMU Groups of this motherboard on reddit : 
> https://www.reddit.com/r/VFIO/comments/8i8yqq/iommu_groups_for_asrock_taichi_x470/
> 
> and it seems there's a big group 13 with LAN, USB and SATA controllers. I 
> wonder if the netVM and USB VM will actually be able to passthrough these 
> controllers if they are in the same IOMMU Group ?
> 
> Any Ryzen / Qubes users can confirm this works OK or this is a no go ?
> 
> Thanks for your help !

On a side note, I wanna ask
Do you play games/tried playing games on that Qubes 3.2 installation of yours 
by any chance?

-- 
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/23f00eb8-8f36-49c4-be7c-fa84c27677de%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Qubes OS dual boot question

2018-08-13 Thread Patrick Bouldin


> If you really want to insist on dual boot however, sad to say but I can't 
> help you with that.

Ok, 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/742a56a5-e62a-49c8-ad45-621fe69a90ab%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: HCL - Dell XPS 15 9560

2018-08-13 Thread Bill Carter

On Friday, June 23, 2017 at 1:49:23 PM UTC-4, David Nogueira wrote:
> On Monday, February 20, 2017 at 8:16:35 AM UTC, Stefan wrote:
> > Hi,
> > 
> > installed Qubes 3.2 on my new laptop. After some initial problems, it
> > seems to be working great!
> > 
> > After installing from the ISO image, the graphics driver was working
> > fine (at least I remember it this way), only suspend to RAM crashed the
> > machine. I updated all packages (fedora template and dom0), and after a
> > reboot, X used the framebuffer driver and did not detect the Intel
> > graphics chip :-(
> > 
> > Both problems were solved by enabling the qubes-dom0-unstable repo and
> > updating the dom0 kernel to the version provided there. Intel VGA and
> > Suspend to RAM are working fine now.
> > 
> > 
> > The nvidia chip (GTX 1050) is not supported by the nouveau driver, and I
> > didn't go through the pain (not to speak of the security concerns) of
> > manually installing the latest proprietary driver from nVidia on dom0.
> > 
> > 
> > Suspend to RAM seems to have some problem with the WLAN driver, though.
> > After some suspend cycles, WLAN won't come up again. I put the driver
> > ath10k_pci to the suspend-module-blacklist, I think this did the trick.
> > 
> > 
> > Stefan.
> Thanks for the work Stefan.
> 
> - Any chance anyone has the 4k screen? I am having issues setting a lower 
> resolution than 4k or working with HiDPI overall, what were your approaches?
> 
> - Also any luck in being able to set brightness levels?
> 
> thanks,
> David

Hi David,

Not sure if you still have this question, but I'll put the answer in anyway. To 
fix this for the 9560 UHD, put on your reading glasses and open up the Terminal 
Emulator for dom0. In your home directory, edit your .bash_profile and add the 
following three lines at the end of the file:

xrandr --newmode "1920x1080_60.00"  173.00  1920 2048 2248 2576  1080 1083 1088 
1120 -hsync +vsync
xrandr --addmode eDP-1 1920x1080_60.00
xrandr --output eDP-1 --mode 1920x1080_60.00

Finish with a "sudo reboot" and enjoy!

-- 
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/6067dffd-32e3-4d20-ae18-6d1e14f9d17d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Qubes OS dual boot question

On Tuesday, August 14, 2018 at 4:17:31 AM UTC+8, Patrick Bouldin wrote:
> I have a goal to buy a new laptop, preconfigured with Windows, and then 
> within Windows I will reallocate disk space in order to install Qubes4.0.
> 
> In the past with prior versions of Qubes that has sometimes been problematic, 
> is that fixed with 4.0 or still a problem?
> 
> Any input on how to proceed?
> 
> One data point, while I can recreate windows it's a pain in the butt to get 
> the licensing back on the machine. I can do it, but would like to avoid it.
> 
> Thanks,
> Patrick

Question: What's your purpose for using Qubes? Usually the answer is to have 
very-high level of security. This purpose however, is ultimately defeated once 
you do OS dual boot as your Qubes installation could be easily 
infiltrated/modified in the context of the Windows OS that you have dual-booted.

So I suggest having two HDDs or one HDD and one M.2/SATA PCI SSD in your laptop 
to effectively separate the Windows OS and Qubes OS(By setting a password on 
the HDD/SSD where Qubes is installed and not entering it when booting on the 
Windows OS (To effectively protect the UEFI boot partition and also a tag-team 
protection with LUKS encryption).

If you really want to insist on dual boot however, sad to say but I can't help 
you with 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/37b79503-dc99-40e1-ba10-178ce5f2f221%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: HCL - Dell XPS 15 9560

2018-08-13 Thread Bill Carter

On Saturday, February 3, 2018 at 2:06:02 PM UTC-5, hotr...@gmail.com wrote:
> On Friday, February 2, 2018 at 5:49:50 PM UTC-6, hotr...@gmail.com wrote:
> > Legacy boot 
> > needed Kernel parm modprobe.blacklist=nouveau
> 
> Hi,
> 
> Qubes 4.0 rc4 is the only OS on the machine right now. I don't use Windows!
> Set SATA to ACHI
> Set Legacy Boot node
> 
> Got "soft lockup - CPU#0 stuck for 23s!" messages and loop.
> At the blue GRUB(I think?) screen, hit tab and added 
> modprobe.blacklist=nouveau
> 
> Installation completed successfully.
> 
> So far, only spent about an hour testing.
> WIFI works,
> Video(intel GPU) and sound work.
> Startup and Shutdown work fine.
> 
> The HiDPI screen renders everything very small, been working on scaling the 
> desktop.

As Hotratz indicates:

1. Turn SecureBoot off
2. Enable Legacy ROM and Legacy Boot Mode
3. Set SATA to ACHI
4. At GRUB, hit  and enter "modprobe.blacklist=nouveau" right before the 
triple hyphens.
5. Run the install as usual

When everything comes up, the scaling is way off on the UHD models of this 
laptop. To fix this, put on your reading glasses and open up the Terminal 
Emulator for dom0. In your home directory, edit your .bash_profile and add the 
following three lines at the end of the file:

xrandr --newmode "1920x1080_60.00"  173.00  1920 2048 2248 2576  1080 1083 1088 
1120 -hsync +vsync
xrandr --addmode eDP-1 1920x1080_60.00
xrandr --output eDP-1 --mode 1920x1080_60.00

Finish with a "sudo reboot" and enjoy!

-- 
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/b6347d0c-3ac1-4875-bf74-de554c57ae31%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Incredible HD thrashing on 4.0

2018-08-13 Thread Kelly Dean

Chris Laprise writes:

> Can Qubes access all of that RAM? Look at the total_memory figure from
> 'xl info'.

Yes, it can.

One additional data point: after the typical one-minute boot time for a qube, 
it's using no swap space, and dom0 is also using no swap space, even though 
both do have swap enabled. So, memory pressure isn't the problem.

Some other qubes are using some swap space, but they were idle while I was 
timing the boot of the test qube.

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

[qubes-users] Re: Incredible HD thrashing on 4.0

On Saturday, August 11, 2018 at 3:02:31 AM UTC+8, Kelly Dean wrote:
> Has anybody else used both Qubes 3.2 and 4.0 on a system with a HD, not SSD? 
> Have you noticed the disk thrashing to be far worse under 4.0? I suspect it 
> might have something to do with the new use of LVM combining snapshots with 
> thin provisioning.
> 
> The problem seems to be triggered by individual qubes doing ordinary bursts 
> of disk access, such as loading a program or accessing swap, which would 
> normally take just a few seconds on Qubes 3.2, but dom0 then massively 
> multiplies that I/O on Qubes 4.0, leading to disk thrashing that drags on for 
> minutes at a time, and in some cases, more than an hour.
> 
> iotop in dom0 says the thrashing procs are e.g. [21.xvda-0] and [21.xvda-1], 
> reading the disk at rates ranging from 10 to 50 MBps (max throughput of the 
> disk is about 100). At this rate, for how prolonged the thrashing is, it 
> could have read and re-read the entire virtual disk multiple times over, so 
> there's something extremely inefficient going on.
> 
> Is there any solution other than installing a SSD? I'd prefer not to have to 
> add hardware to solve a software performance regression.

Same here for me, I hear lots of scratching sounds from the HDD whenever I do 
something in the laptop. Extremely worries me that the HDD might die soon 
because of it D:

-- 
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/182578a5-3cad-4dbe-9cdc-94a78cc58930%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: New CPU Bug Found

On Tuesday, August 14, 2018 at 7:44:18 AM UTC+8, jonbrown...@gmail.com wrote:
> New CPU backdoor has been found with code available here: 
> https://github.com/xoreaxeaxeax/rosenbridge
> 
> Anyone mind checking if Thinkpad 230 is affected?

Wow... things sure are going rough in the firmware/hardware/low-level 
instruction side of things

-- 
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/4a3aa75a-7ce6-4075-a7e1-a96852c5c161%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Manually remove R4.0 template vms

On Tuesday, July 17, 2018 at 2:37:05 AM UTC+8, Will Dizon wrote:
> qvm-prefs fedora-281 installed_by_rpm false
> 
> This worked perfectly.  Was even able to remove it from the existing qube 
> manager instance without reinstallation.  Thanks so much!

Thank you very much for this!

-- 
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/14243512-8e76-4fc8-a28e-0ef562adf686%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] How to change TemplateVM update method from Whonix to just another appvm?

On Wednesday, August 8, 2018 at 1:17:23 AM UTC+8, Patrick Schleizer wrote:
> Sphere:
> > So upon installation of Qubes I have set updating of TemplateVMs through 
> > Whonix but now I'm actually stuck with it and I want to change it to 
> > updating through just another AppVM.
> > 
> > Could anyone guide me to what commands I need to use in order to fix this? 
> > (I actually wish this was an option in Qubes settings UI as well)
> > 
> 
> Qubes R4?
> 
> modify:
> 
> /etc/qubes-rpc/policy/qubes.UpdatesProxy

Thank you

-- 
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/67e35a4d-c072-4006-b70f-806dcdcd4800%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Can't find a guide to setup a new fedora-28 template

Sorry for the late reply
I installed a fresh template and what happens when I assign it to Service VMs 
is that some terminal opens that's similar to what I see whenever I make a new 
Standalone VM that requires a CD-ROM/ISO to install an OS.

I recently have done upgrading fedora-26 to 27 and it works like a charm. Just 
gonna upgrade it to 28 I suppose though I do still want to know a way to make 
the fedora-28 template I installed work as it's much faster to jump to 28 than 
having to go through 27 which takes almost a whole day.

-- 
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/b50b0c65-0980-423f-99e5-74573b68adb5%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] New CPU Bug Found

2018-08-13 Thread jonbrownmasterit

New CPU backdoor has been found with code available here: 
https://github.com/xoreaxeaxeax/rosenbridge

Anyone mind checking if Thinkpad 230 is affected?

-- 
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/eeff74a1-4817-41bd-8ca3-049ac41deaf7%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Corrupted LVM Pool Metadata - no free space (recoverable?)

On 08/13/2018 05:32 PM, joevio...@gmail.com wrote:

On Monday, 13 August 2018 17:13:06 UTC-4, Chris Laprise wrote:

On 08/13/2018 04:47 PM,

[qubes-users] Re: Whonix 14 - upgrade or re-install? Whats more smooth, less troublesome?

2018-08-13 Thread smcmj

I did a fresh installnot a typical template install but managed to get 
whonix 14 going. No time error anymore! Thanks Whonix/Qubes!!

Here was my experience:

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

-- 
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/f5cb5eb2-c5f0-440b-9714-c3864d301568%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Whonix 14 installation problem...using 4.0?

2018-08-13 Thread smcmj

Thanks awokd...

I ended up doing a fresh install. Similar results...however I did manage to get 
it installed.

I started again with the Whonix wiki 
instructions(https://www.whonix.org/wiki/Qubes/Install), except for me I also:

* In addition to the following: "sudo qubesctl state.sls qvm.anon-whonix" , per 
the instructions, I also ran "sudo qubesctl state.sls qvm.sys-whonix" and it 
loaded the Whonix-gw template.


Not sure it was happening in the background but waited for 1 1/2 hrs with no 
feedback after the "sudo qubesctl state.sls qvm.anon-whonix" command in Dom0.

Regardless I have it running...thanks Whonix/Qubes!

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

Re: [qubes-users] Re: yubikey password

> That's a TemplateBasedHVM and InputKeyboard is running, but (as you say) 
> not allowed - I advised creating a HVM (Standalone) and you'll see it works. 
> You refer to this case below. 

It's not InputKeyboard that is the problem, it is Qubes-Gui.  StandaloneVMs Not 
based on a Template, won't have any qubes services running.  But attaching a 
USB keyboard is also not possible.  
For my test, my AppVM (Kali) was installed from an ISO (not a template), and I 
installed Qubes services/agents from deb packages.  This allowed USB 
passthrough, but I never got the qubes-gui installed.  So it does work.

> People have reported using yubikeys in this configuration in the past. 

I have read a lot of the yubikey / qubes implementations, as I am currently 
using one.
Are you sure they are using Yubikey's "Static Password" slot?  That is the only 
component that enumerates as a USB keyboard.  The normal yubikey setup 
enumerates as a Smartcard, which is how the challenge/response works.  With 
this, there is no keyboard to attach as an input device and no keystrokes to 
manage.  You attach the USB to the AppVM, and that's it.

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

Re: [qubes-users] Re: Corrupted LVM Pool Metadata - no free space (recoverable?)

On Monday, 13 August 2018 17:13:06 UTC-4, Chris Laprise  wrote:
> On 08/13/2018 04:47 PM, 
> > Related question.
> > 
> > If I installed Qubes and used LUKS encryption (I have to run cryptsetup 
> > openLuks just to see the LVM inside)... then I add physical drives to my 
> > Volume Group, and start adding more AppVMs to the pool, that starts writing 
> > to the PV...
> > Is the data on the new drive, encrypted?
> > Can anyone forensically pull data from those new AppVMs since it wasn't 
> > originally a part of the LUKS encrypted drive?
> 
> Based on the sparse description I'd say No, the new space is not 
> encrypted. You have to add separate LUKS/dmcrypt block layers to those 
> new devices and then treat those dmcrypt block devices as the new pvs.
> 
> If you're doing this to qubes_dom0, then it could be a little tricky 
> getting all of the encrypted "pvs" to unlock at the same time during the 
> boot process. You'd need to investigate how crypttab and grub 
> accommodate that multi-volume setup.
> 
> -- 
> 
> Chris Laprise
> PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886


I would imagine it would require a longer grub entry with rd.luks attributes 
for other UUIDs.

But it seems I have an LVM over LUKS configuration... when what I want is a 
LUKS over LVM.

Here's what I have:

[root@dom0]# lsblk | grep -v "\-\-"
NAME MAJ:MIN RM   SIZE 
RO TYPE  MOUNTPOINT
sdb8:16   0   3.7T  
0 disk  
└─sdb1 8:17   0   3.7T  
0 part  
  ├─qubes_dom0-pool00_tmeta  253:10   2.1G  
0 lvm   
  │ └─qubes_dom0-pool00-tpool253:30 1T  
0 lvm   
  │   ├─qubes_dom0-pool00253:60 1T  
0 lvm   
  │   ├─qubes_dom0-root  253:40 192.6G  
0 lvm   /
  ├─qubes_dom0-pool00_meta0  253:63   0   2.1G  
0 lvm   
  └─qubes_dom0-pool00_tdata  253:20 1T  
0 lvm   
└─qubes_dom0-pool00-tpool253:30 1T  
0 lvm   
  ├─qubes_dom0-pool00253:60 1T  
0 lvm   
  ├─qubes_dom0-root  253:40 192.6G  
0 lvm   /
sr0   11:01  1024M  
0 rom   
loop0  7:00   500M  
0 loop  
sda8:00 232.9G  
0 disk  
└─sda1 8:10 232.9G  
0 part  
nvme0n1  259:00 232.9G  
0 disk  
├─nvme0n1p1  259:10 1G  
0 part  /boot
└─nvme0n1p2  259:20 231.9G  
0 part  
  └─luks-bfcca13a-213d-46ec-b156-53df348dba30253:00 231.9G  
0 crypt 
├─qubes_dom0-pool00_tdata253:20 1T  
0 lvm   
│ └─qubes_dom0-pool00-tpool  253:30 1T  
0 lvm   
│   ├─qubes_dom0-pool00  253:60 1T  
0 lvm   
│   ├─qubes_dom0-root253:40 192.6G  
0 lvm   /
└─qubes_dom0-swap253:50  23.3G  
0 lvm   [SWAP]


Even better, I should look into a RAID setup too.  
If I choose btrfs for my next install, I can avoid the LVM problems, but can I 
expand onto new physical volumes by adding more drives?

-- 
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/a43f228b-819b-449f-916e-658bfba2a128%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Corrupted LVM Pool Metadata - no free space (recoverable?)

On 08/13/2018 04:47 PM, joevio...@gmail.com wrote:

Re: [qubes-users] Corrupted LVM Pool Metadata - no free space (recoverable?)

On 08/13/2018 04:26 PM, joevio...@gmail.com wrote:

Thanks.

Is Btrfs an option when installing Qubes 4.0?

Yes.

BTW,
Qubes fully recovered.

Like last time I messed things up by filling up the LVM,
Here are the steps:

Insert a bigger drive
create PV from new drive
added PV to VG
LVmove pool00_tdata from full drive to new PV
LVextended Pool00 to give room
LVextended pool00_tmeta (this was the corrupted part)
LVconvert --repair qubes_dom0/pool00
I did try all this yesterday, but the drive I put in, had a previous Qubes 4
install. Even with deleting the partitions, it seemed to still recognize the
Volume Group information on it. And since it is also named qubes_dom0... it
really messed things up and had me going down rabbit holes with a VG with a
MISSING PV. No commands really work when in that stuck state.

The issue still remains if anything will be done with Thin Provisioning to
prevent this from happening. Last time this happened, there was no disk storage
applet. This time, there was, but I just didn't see what a vmdk file was going
to be on disk.

There is an issue opened for this IIRC, and I think the target is R4.1.

Should VMs get automatically paused when approaching the limit?

That's my initial inclination because the user may not be at the
computer to take immediate action when the space crisis occurs. But I
think the resolution will also involve moving dom0 root out of the thin
pool to a static-sized lv.

Also, should dom0 be inside the thin pool? Or would it make sense to keep it as
its own LV? Yeah, it means dom0 cannot grow with the pool, but should it?

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/9bfbe632-0d1f-19a0-719f-7deb6b918c37%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Corrupted LVM Pool Metadata - no free space (recoverable?)

Related question.

If I installed Qubes and used LUKS encryption (I have to run cryptsetup 
openLuks just to see the LVM inside)... then I add physical drives to my Volume 
Group, and start adding more AppVMs to the pool, that starts writing to the 
PV...
Is the data on the new drive, encrypted?
Can anyone forensically pull data from those new AppVMs since it wasn't 
originally a part of the LUKS encrypted drive?

-- 
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/fb9e3b7d-472e-42d6-ba46-f11f9974d0c8%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Qubes 4.0 sluggish feel

On Mon, August 13, 2018 7:34 pm, CF wrote:
> On 08/13/2018 01:14 PM, 'awokd' via qubes-users wrote:
>
>> On Mon, August 13, 2018 11:03 am, CF wrote:
>>
>>> On 08/13/2018 12:41 PM, 'awokd' via qubes-users wrote:
>>>
>>>
>>

 Have you checked the logs to see if X is using software rendering
 and/or the video driver is throwing any errors on load?


>>> I have not checked, I simply noticed that the move from 4.9.56 to
>>> 4.14.57 was bringing all the fixes for Spectre / Meltdown, and I
>>> suspect they are responsible for the 'sluggish feel' (Q3.2 here, not
>>> 4.0)
>>>
>>>
>>> I can check for rendering and video driver, which logs are you
>>> talking about exactly?
>>
>> X.org log is described here:
>> https://www.qubes-os.org/doc/intel-igfx-troubleshooting/#software-render
>> ing-or-video-lags
>>
>> If the driver is having trouble loading, you should see a related error
>> in dom0's journalctl.
>>
>>
> Journalctl was full of error, this seems to fix it, thanks

What did you have to change to fix the errors?


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

Re: [qubes-users] Corrupted LVM Pool Metadata - no free space (recoverable?)

On Monday, 13 August 2018 16:13:06 UTC-4, Chris Laprise  wrote:
> On 08/13/2018 06:48 AM, 'awokd' via qubes-users wrote:
> > On Mon, August 13, 2018 7:59 am, 
> > 
> >> Should I mount each LV
> >> and attempt to import the root.img and private.img files? How would I
> >> mount those to get to the files, and how would import to Qubes?
> > 
> > Sounds pretty FUBARd. LVs don't have .img files; if you can manage to get
> > them mounted you might be able to recover contents. Boot from some
> > recovery distribution and get the Qubes PV attached, then "mount 
> > /dev/mapper/qubes_dom0-vm--vmname--private" for example.
> 
> Thin LVs can be imaged like normal volumes, however. I would try 
> 'vgchange -ay' then 'lvchange -ay' on the drive and then look for the 
> vm*private volumes in /dev/mapper.
> 
> Once you got that, you can do stuff like this to backup:
> 
> # dd if=/dev/mapper/qubes_dom0-vm--work--private | gzip >work_img.gz
> 
> and this to restore:
> 
> #  gunzip -c work_img.gz | dd 
> of=/dev/mapper/qubes_dom0-vm--work--private conv=sparse
> 
> This example is unencrypted, so take care with the remaining backup details.
> 
> Also keep in mind that thin-provisioned lvm is still pretty young -- it 
> is NOT 'like' regular non-thin lvm, but more like a new filesystem on 
> top of regular lvm. If reliability is high on your list then Btrfs may 
> be better... it seems to be older with a lot more people using it, and 
> has more internal error-correction mechanisms (but it still isn't 
> recommended for RAID5/6). Btrfs is worth considering as an alternative.
> 
> -- 
> 
> Chris Laprise
> PGP: BEE2 20C5 356E 764A 73EB  4AB3 1DC4 D106 F07F 1886

Thanks.

Is Btrfs an option when installing Qubes 4.0?

BTW,
Qubes fully recovered.

Like last time I messed things up by filling up the LVM,
Here are the steps:

Insert a bigger drive
create PV from new drive
added PV to VG
LVmove pool00_tdata from full drive to new PV
LVextended Pool00 to give room
LVextended pool00_tmeta (this was the corrupted part)
LVconvert --repair qubes_dom0/pool00
I did try all this yesterday, but the drive I put in, had a previous Qubes 4 
install. Even with deleting the partitions, it seemed to still recognize the 
Volume Group information on it. And since it is also named qubes_dom0... it 
really messed things up and had me going down rabbit holes with a VG with a 
MISSING PV. No commands really work when in that stuck state.

The issue still remains if anything will be done with Thin Provisioning to 
prevent this from happening. Last time this happened, there was no disk storage 
applet. This time, there was, but I just didn't see what a vmdk file was going 
to be on disk.

Should VMs get automatically paused when approaching the limit?
Also, should dom0 be inside the thin pool? Or would it make sense to keep it as 
its own LV? Yeah, it means dom0 cannot grow with the pool, but should it?

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

Re: [qubes-users] Incredible HD thrashing on 4.0

On 08/13/2018 03:26 AM, Kelly Dean wrote:

Unman writes:

I don't recognise this on a somewhat under powered laptop with HDD -
definitely not "minutes at a time". Is there something significant about
the disks that you cite, or are those just examples?

Nothing significant about #21 in particular. The thrashing procs are whichever
ones handle the virtual disks for a qube that's thrashing.

System is a core i3 with 16GB RAM, and HD with about 100MB/s throughput.

Worst problems seem to be from swapping, and random times when I start a qube.

The swapping is unpredictable, but here's a typical best-case result for
starting an ordinary app qube with fedora-28 template:
T+0: start qube. Brief burst of CPU & disk activity for a second, then mostly
idle for 20 seconds.
T+20: heavy sustained disk thrashing starts.
T+40: pop-up notification that the domain has started. Thrashing continues.
T+60: thrashing abruptly stops.
That's only 1 minute, but when I'm unlucky, it can be several minutes.

How does that compare with your experience?

I don't have anything custom configured to run in the qube at startup, so all
the activity is from the template's defaults. Nothing special about fedora-28
either; I get similar results from debian-9 and whonix-ws.

Can Qubes access all of that RAM? Look at the total_memory figure from
'xl info'.

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/7a4a0c2c-7294-5a37-10d0-0615185a3073%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Qubes OS dual boot question

2018-08-13 Thread Patrick Bouldin

I have a goal to buy a new laptop, preconfigured with Windows, and then within 
Windows I will reallocate disk space in order to install Qubes4.0.

In the past with prior versions of Qubes that has sometimes been problematic, 
is that fixed with 4.0 or still a problem?

Any input on how to proceed?

One data point, while I can recreate windows it's a pain in the butt to get the 
licensing back on the machine. I can do it, but would like to avoid it.

Thanks,
Patrick

-- 
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/33514bf2-7c0f-4a0a-8534-f187921c4c67%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Qube manager has unexpectedly stopped working

On 08/13/2018 03:07 PM, rumsey.anth...@gmail.com wrote:

On Monday, August 13, 2018 at 6:28:22 PM UTC, awokd wrote:

Do not reboot. Backup everything immediately. It is bad if your thin pool
is running low, and may have caused the issue. Once that's done, it's
probably safest to reinstall...

Too late not to reboot. No lost information though, so that won't be a problem.
Just was hoping to save the time required for a reinstall.

Thanks for the info. I'll just go ahead and reinstall.

Can you tell me what I did or how to avoid this issue with the thin pool in the
future? Was I just taxing my system resources too heavily? I'll have to look
into it because I don't really even know what the thin pool is.

Thanks

Unfortunately Qubes does not have very clear warnings or preventative
measures to avoid out-of-space problems; this may be addressed in R4.1.
For now its good to keep an eye on your disk space meter.

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/ccb32cd9-5ad8-cd6a-f168-a01c74e50418%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Corrupted LVM Pool Metadata - no free space (recoverable?)


On 08/13/2018 06:48 AM, 'awokd' via qubes-users wrote:

On Mon, August 13, 2018 7:59 am, joevio...@gmail.com wrote:


Should I mount each LV
and attempt to import the root.img and private.img files? How would I
mount those to get to the files, and how would import to Qubes?


Sounds pretty FUBARd. LVs don't have .img files; if you can manage to get
them mounted you might be able to recover contents. Boot from some
recovery distribution and get the Qubes PV attached, then "mount 
/dev/mapper/qubes_dom0-vm--vmname--private" for example.


Thin LVs can be imaged like normal volumes, however. I would try 
'vgchange -ay' then 'lvchange -ay' on the drive and then look for the 
vm*private volumes in /dev/mapper.


Once you got that, you can do stuff like this to backup:

# dd if=/dev/mapper/qubes_dom0-vm--work--private | gzip >work_img.gz

and this to restore:

#  gunzip -c work_img.gz | dd 
of=/dev/mapper/qubes_dom0-vm--work--private conv=sparse


This example is unencrypted, so take care with the remaining backup details.

Also keep in mind that thin-provisioned lvm is still pretty young -- it 
is NOT 'like' regular non-thin lvm, but more like a new filesystem on 
top of regular lvm. If reliability is high on your list then Btrfs may 
be better... it seems to be older with a lot more people using it, and 
has more internal error-correction mechanisms (but it still isn't 
recommended for RAID5/6). Btrfs is worth considering as an alternative.


--

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/69368c6b-9bc6-1690-5c5b-e47c02f45b8d%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Qubes 4.0 sluggish feel

2018-08-13 Thread CF

On 08/13/2018 01:14 PM, 'awokd' via qubes-users wrote:
> On Mon, August 13, 2018 11:03 am, CF wrote:
>> On 08/13/2018 12:41 PM, 'awokd' via qubes-users wrote:
>>
> 
>>>
>>> Have you checked the logs to see if X is using software rendering
>>> and/or the video driver is throwing any errors on load?
>>>
>>>
>> I have not checked, I simply noticed that the move from 4.9.56 to
>> 4.14.57 was bringing all the fixes for Spectre / Meltdown, and I suspect
>> they are responsible for the 'sluggish feel' (Q3.2 here, not 4.0)
>>
>> I can check for rendering and video driver, which logs are you talking
>> about exactly?
> 
> X.org log is described here:
> https://www.qubes-os.org/doc/intel-igfx-troubleshooting/#software-rendering-or-video-lags
> 
> If the driver is having trouble loading, you should see a related error in
> dom0's journalctl.
> 
> 
Journalctl was full of error, this seems to fix it, 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/pksmbc%2416h%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Network not working until several minutes after login

2018-08-13 Thread Andreas Rasmussen

2018-08-13 16:50 GMT+02:00 Unman :

> On Mon, Aug 13, 2018 at 01:41:43AM -0700, Andreas Rasmussen wrote:
> > sųndag den 12. august 2018 kl. 15.38.19 UTC+2 skrev Unman:
> > > On Sat, Aug 11, 2018 at 12:13:32PM -0700, Andreas Rasmussen wrote:
> > > > Hi!
> > > >
> > > > For the last couple of months, my Qubes 4.0 install has suffered
> from a weird bug. When I login to Qubes, my network icon shows, that I'm
> connected to my wifi: No matter what VM i'm using, I cannot connect to
> anything online.
> > > >
> > > > However, if I wait a short while, perhaps 3-4 minutes, I can open
> any VM and connect to whatever I want.
> > > >
> > > > When Qubes is booting, I get a short errormessage, that Qubes is
> trying to start a nonexisting VM (which I deleted). Then it starts sys-net
> without problems. I don't know if this might be relevant for the problem?
> > > >
> > > > best regards,
> > > >
> > > > Andreas
> > > >
> > >
> > > Is it possible that you are using Whonix gateway by default, and it's
> > > taking a long time to get the Tor connections set up?
> > >
> > > What does your Qubes network setup look like?
> >
> > Hi!
> >
> > No, I've removed the Whonix gateway. My setup is the standard: AppVM ->
> sys-firewall -> sys-net. I haven't done any special configs.
> >
> > However: I've noticed that during startup, I get a short errormessage
> that Qubes is trying to start an old VM, that I've deleted approximately at
> the time this problem occured. However, since the VM is deleted, I have no
> idea how to tell Qubes to *not* try to start that non-existing VM. Any tips
> on that? :)
> >
>
> Try systemctl|grep qubes-vm , and you may see that there is a service
> attemting to start the old VM.
> If there is, you can disable it with 'systemctl disable foo'
>

This worked! It also made my bootproces several seconds, if not 10, faster.
Seems like the attempt to start a nonexisting VM delayed the startup of
sys-nyt/sys-firewall. Thank you!

awokd: I didn't get to try your approach, but thanks for responding!

-- 
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/CABX-jw0xc3_HYWJ%2BpkLn7paHrsA349DaT2a%2B3eEnPwGJS6FykQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Qube manager has unexpectedly stopped working

2018-08-13 Thread rumsey . anthony

On Monday, August 13, 2018 at 6:28:22 PM UTC, awokd wrote:

> Do not reboot. Backup everything immediately. It is bad if your thin pool
> is running low, and may have caused the issue. Once that's done, it's
> probably safest to reinstall...

Too late not to reboot. No lost information though, so that won't be a problem. 
Just was hoping to save the time required for a reinstall.

Thanks for the info. I'll just go ahead and reinstall.

Can you tell me what I did or how to avoid this issue with the thin pool in the 
future? Was I just taxing my system resources too heavily? I'll have to look 
into it because I don't really even know what the thin pool is.

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/9a971f77-87a1-4d66-8822-03bb96c6eb9f%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Qube manager has unexpectedly stopped working

On Mon, August 13, 2018 5:26 pm, rumsey.anth...@gmail.com wrote:
> Have had Qubes 4 running smoothly until just now.
>
>
> Upon startup Qube Manager no longer loads, and when I try to start it
> from the menu I get an error:
>
> "QubesDaemonCommunicationError: Failed to connect to qubesd service:
> [Errno 2] No such file or directory at line 9 of file
> /usr/bin/qubes-qube-manager."
>
>
> This has proven to be out of my league in terms of being able to
> troubleshoot, so I was hoping someone could point me in the right
> direction for a fix so that I don't have to wipe everything and start
> over on this machine.
>
> It may be relevant that just prior to this happening I had a warning pop
> up that had something to do with low memory in something that was called
> "LVM thin pool" or something similar to that.
>
>
> Thanks to anyone with suggestions!

Do not reboot. Backup everything immediately. It is bad if your thin pool
is running low, and may have caused the issue. Once that's done, it's
probably safest to reinstall...


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

[qubes-users] Qube manager has unexpectedly stopped working

2018-08-13 Thread rumsey . anthony

Have had Qubes 4 running smoothly until just now.

Upon startup Qube Manager no longer loads, and when I try to start it from the 
menu I get an error:

"QubesDaemonCommunicationError: Failed to connect to qubesd service: [Errno 2] 
No such file or directory at line 9 of file /usr/bin/qubes-qube-manager."

This has proven to be out of my league in terms of being able to troubleshoot, 
so I was hoping someone could point me in the right direction for a fix so that 
I don't have to wipe everything and start over on this machine.

It may be relevant that just prior to this happening I had a warning pop up 
that had something to do with low memory in something that was called "LVM thin 
pool" or something similar to that.

Thanks to anyone with suggestions!

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

Re: [qubes-users] how to connect USB to standalone HVM Kali

2018-08-13 Thread Djon Snow

понедельник, 13 августа 2018 г., 13:24:52 UTC+3 пользователь awokd написал:
> On Mon, August 13, 2018 6:36 am, Djon Snow wrote:
> > понедельник, 13 августа 2018 г., 0:05:35 UTC+3 пользователь awokd
> > написал:
> >
> >> On Sat, August 11, 2018 11:56 am, bbbenjjjami...@gmail.com wrote:
> >>
> >>> how to connect USB to standalone HVM Kali?
> >>
> >> Try cloning debian-9 to a new standalone HVM, then installing Kali on
> >> top of it.
> >
> > I tried to do so, but it does not work out, at half the load VM just
> > turns off
> 
> At which step of https://www.qubes-os.org/doc/pentesting/kali/#katoolin3_2
> or https://www.qubes-os.org/doc/pentesting/kali/#templatevm-from-debian3_2
> ?

I execute all commands, and at the very end, when the configuration of 
downloaded packages is already running, everything turns off. overload does not 
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/08e1a887-03eb-4eab-b90b-0c2b7784478b%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Windows 10 InPrivate Desktop

2018-08-13 Thread Yethal

W dniu poniedziałek, 13 sierpnia 2018 07:33:56 UTC+2 użytkownik awokd napisał:
> https://arstechnica.com/staff/2018/08/windows-10-to-get-disposable-sandboxes-for-dodgy-apps/
> 
> "Microsoft is building a new Windows 10 sandboxing feature that will let
> users run untrusted software in a virtualized environment that's discarded
> when the program finishes running."
> 
> Nice of Microsoft to finally join the party. It fails to answer what the
> untrusted software known as Windows 10 should be run in, though. Turtles
> all the way down?

Sandboxie and Bromium did that for years

-- 
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/db1c2a2f-c5d7-42f4-8cfc-90a0cda7a3cb%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Copy & Paste into anouther Domains

2018-08-13 Thread Unman

On Sun, Aug 12, 2018 at 09:41:17AM -0700, myblackcatisb...@gmail.com wrote:
> Hey,
> 
> i wrote the command promp correct in the guid.conf but wrong here sorry. 
> 
> VM Xy: }
> 
> secure_copy_sequence ="Ctrl+Shift+c;
> secure_paste_sequence ="Ctrl+Shift+v;
> 
> };
> 
> Workspace1:
> 
> If i copy the file i see a qubes Windows which show me how many byte i copy t 
> the clipboard.
> 
> After this command i change to Workspace 2 where i want paste it. But nothing 
> happened. On Workspace 2 Windows run and i try to paste the file on the 
> Desktop,there.
> 
> What iam doing wrong?
> 

You haven't confirmed if:
1. You can copy/paste in to other linux qubes.
2. You have installed the Qubes Windows Tools in to the Windows qube.

unman

-- 
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/20180813145315.2gdfyibiyrqlvimr%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Network not working until several minutes after login

2018-08-13 Thread Unman

On Mon, Aug 13, 2018 at 01:41:43AM -0700, Andreas Rasmussen wrote:
> sųndag den 12. august 2018 kl. 15.38.19 UTC+2 skrev Unman:
> > On Sat, Aug 11, 2018 at 12:13:32PM -0700, Andreas Rasmussen wrote:
> > > Hi!
> > > 
> > > For the last couple of months, my Qubes 4.0 install has suffered from a 
> > > weird bug. When I login to Qubes, my network icon shows, that I'm 
> > > connected to my wifi: No matter what VM i'm using, I cannot connect to 
> > > anything online. 
> > > 
> > > However, if I wait a short while, perhaps 3-4 minutes, I can open any VM 
> > > and connect to whatever I want. 
> > > 
> > > When Qubes is booting, I get a short errormessage, that Qubes is trying 
> > > to start a nonexisting VM (which I deleted). Then it starts sys-net 
> > > without problems. I don't know if this might be relevant for the problem?
> > > 
> > > best regards,
> > > 
> > > Andreas
> > > 
> > 
> > Is it possible that you are using Whonix gateway by default, and it's
> > taking a long time to get the Tor connections set up?
> > 
> > What does your Qubes network setup look like?
> 
> Hi!
> 
> No, I've removed the Whonix gateway. My setup is the standard: AppVM -> 
> sys-firewall -> sys-net. I haven't done any special configs.
> 
> However: I've noticed that during startup, I get a short errormessage that 
> Qubes is trying to start an old VM, that I've deleted approximately at the 
> time this problem occured. However, since the VM is deleted, I have no idea 
> how to tell Qubes to *not* try to start that non-existing VM. Any tips on 
> that? :)
> 

Try systemctl|grep qubes-vm , and you may see that there is a service
attemting to start the old VM.
If there is, you can disable it with 'systemctl disable foo'

-- 
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/20180813145040.ezhgjduggev32hku%40thirdeyesecurity.org.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: yubikey password

2018-08-13 Thread Unman

On Sun, Aug 12, 2018 at 08:59:12AM -0700, joevio...@gmail.com wrote:
> On Sunday, 12 August 2018 09:59:57 UTC-4, Unman  wrote:
> > On Fri, Aug 10, 2018 at 11:00:30AM -0700, :
> > > On Friday, 10 August 2018 11:31:08 UTC-4, Unman  wrote:
> > > > On Fri, Aug 10, 2018 at 07:39:45AM -0700, 
> > > > > Both /etc/qubes-rpc/policy/qubes.InputKeyboard and InputMouse, should 
> > > > > say something like this.
> > > > > 
> > > > > sys-usb  dom0 allow,user=root
> > > > > 
> > > > > Yes, If you have a sys-usb set up, then the USB keyboard will attach 
> > > > > there first.  More specifically, the USB Host Controller that the USB 
> > > > > keyboard is plugged into is attached to sys-usb.  But the keyboard 
> > > > > device is immediately sent to dom0 per the rpc policy.  Because a 
> > > > > keyboard that stays attached to sys-usb, can only type into sys-usb.  
> > > > > And not the interactive window you see when you open up a terminal 
> > > > > for sys-usb... but rather its own session.
> > > > > dom0 needs the keyboard and mouse.  The USB Host Controller still 
> > > > > resides in sys-usb, but the USB raw data passes to dom0 upon boot.
> > > > > 
> > > > > Unfortunately, the rpc policy is generic based on all USB devices 
> > > > > enumerating as a keyboard.  So it may not be able to selectively 
> > > > > attach a yubikey to an AppVM.
> > > > > 
> > > > 
> > > > But the point is that the yubikey will be attached to a different qube,
> > > > and can be treated as a keyboard there. This means that one can
> > > > selectively link the yubikey to distinct qubes for input there, and the
> > > > sys-usb policy will not be relevant.
> > > > The Input.Keyboard policy needs to be set for the qube to which the
> > > > yubikey is attached.
> > > 
> > > Yeah, that would be nice if it were that granular.  
> > > 
> > > I don't have my yubikey set for a static key, but let me test this with 
> > > my input stick, which is like a USB rubber ducky.  It enumerator as a 
> > > keyboard, and I have just attached it to the app VM I am typing on.
> > > I am speech to text on my phone, Bluetooth to InputStick USB and typing 
> > > into here.
> > > 
> > > It only works with, "sys-usb dom0 allow,user=root" in 
> > > /etc/qubes-rpc/policy/qubes.InputKeyboard 
> > > And it does NOT work with "sys-usb APPVM_NAME allow,user=root".
> > > No USB device attaching is needed, as the rpc rule simple allows dom0 
> > > access to sys-usb keyboard.
> > > 
> > > As I said... Keyboards need to be sent to dom0, or else it cannot type in 
> > > the GUI.  
> > > 
> > > This will work for all USB keyboards as you cannot specify Yubikey 
> > > keystrokes only type in a single AppVM.  Not the most secure... which is 
> > > why Qubes recommends PS2 keyboards if running on a desktop and using the 
> > > built in keyboard on laptops. It avoids the USB blanket rule for 
> > > keyboards going to dom0.  And since LUKS encryption passphrases are 
> > > entered after initramfs hides usb from boot process, a non-usb keyboard 
> > > is essential for full disk encryption.
> > > 
> > > All that said,
> > > it is still a much more secure option to use ykchalresp which comes with 
> > > yubikey tools.  The USB device that does this function is not the 
> > > keyboard part, and you have to explicitly Attach to the VM you want.  
> > > Also, no static key to be sniffed or accidentally typed somewhere.  I use 
> > > it for KeePass, LUKS, PAM.d login, OTP tokens, everything.  
> > > 
> > > 
> > 
> > What you say about connecting keyboards isn't quite true.
> > If you have passed the device through to a qube, then you need to set
> > the policy *for that qube*. i.e -
> >  dom0 allow, user=root
> > 
> > I don't use yubikeys so I cant speak for them, but that works for
> > keyboards. It does mean that the attached keyboard input *could* be sent to
> > any qube after user error.
> > 
> > Of course, the granularity of passthrough is currently missing, but it's 
> > possible
> > to hack this in various ways.
> > 
> > If you create a HVM and assign it a USB controller, then usb attached
> > devices can insert key strokes *without* using qubes.InputKeyboard. This
> > looks like a reasonable approach if you have more than one controller,
> > and keeps the usb keystrokes confined to the qube.
> > 
> > If you only have one controller, then you could stop the Sender service
> > in the qube, let the keyboard do it's stuff in that qube, remove the
> > yubikey, and then re-enable the service. A bit unwieldy but security
> > always comes at a price, and you could automate this with a key
> > combination.
> > 
> > It's also possible to use qrexec to directly pass keystrokes from one
> > qube to another. You can manually run the input proxy service and pipe
> > it through to another qube. I've hacked this via dom0 (poc) and it works
> > fine - you also need to process the /dev/input/event input to generate
> > keyboard input in X in the qube, but that's pretty standard. If it's of
> >

Re: [qubes-users] Whonix 14 - upgrade or re-install? Whats more smooth, less troublesome?


On 08/13/2018 07:32 AM, qubes-...@tutanota.com wrote:

Chris, which guide did you follow when installing the new whonix 14 Template as a 
"recommended whonix install procedure"? I found these two.

http://dds6qkxpwdeubwucdiaord2xgbbeyds25rbsgr73tbfpqpt4a6vjwsyd.onion/wiki/Qubes/Install#
 


https://www.qubes-os.org/doc/reinstall-template/ 


Thanks


It was a bit confusing, but from the wiki Install page I picked out 
these relevant steps for dom0 (Qubes 4.0):


$ sudo qubes-dom0-update qubes-core-admin-addon-whonix
$ sudo qubesctl state.sls qvm.anon-whonix

The second command will start the download and install, although it does 
not give much feedback.


Also, there is no need to clone old whonix-gw in the steps I mentioned 
earlier; only whonix-ws is needed. Once you have your appVMs switched 
over to whonix-ws-14 you can delete the clone.


--

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/c8938a67-4998-2681-a581-680b157c9a1b%40posteo.net.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Can't use settings in fedora 28 vm.

2018-08-13 Thread Ivan Mitev




On 08/13/2018 01:58 PM, Michael MENG wrote:
> Actually i need to add chinese input method in appvm, but there's nothing in 
> settings, i can't found Region & Language/Input Sources. How can i open the 
> gnome settings in qubes?

The following doc might help:

https://github.com/Qubes-Community/Contents/blob/master/docs/localization/keyboard-multiple-layouts.md

No idea if Chinese input packages are installed by default on your appVM
template though, you might want to check that if something doesn't work.

-- 
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/933985c7-86ec-8130-1de1-0cb6164d74ce%40maa.bz.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Qubes 4.0 sluggish feel

On Mon, August 13, 2018 11:18 am, Outback Dingo wrote:

>
> i am having 0 errors with nvidia card nothing in the logs really , yet
> still having the same issue, no updates, one tweak for performance as
> suggested helped a little but not alot

There's an option to disable Meltdown mitigations but I haven't tried it.
It will reduce security of the system. If you want to, set xpti=false
option in Xen command line (xen.gz option in grub, or options= line in
xen.cfg for UEFI).

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

Re: [qubes-users] Installation guide warnings

2018-08-13 Thread oliver . salzburg

> > The installation guide at
> > https://www.qubes-os.org/doc/installation-guide/ has a set of
> > warnings at the top. To me, it is not quite clear how much of that
> > is relevant when installing 4.0. It would be nice if that could be
> > made clearer.
> > 
> 
> Fixed.

Awesome. That helps a lot.

> > Further down, there's a warning "If you do that on Windows 10, you
> > can only install Qubes without MediaTest, which isn’t recommended."
> > It's not clear to me to what part of the process that warning
> > refers to and why it is not recommended.
> > 
> 
> Not sure about this part, sorry.

I tried to research a bit. The only thing I could find was a Reddit post asking 
about exactly the same confusion: 
https://www.reddit.com/r/Qubes/comments/8svoj5/whats_the_problem_with_using_rufus_on_windows_10/

-- 
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/3da11812-dd7c-4b09-96c1-2eca961fee00%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Whonix 14 - upgrade or re-install? Whats more smooth, less troublesome?

2018-08-13 Thread qubes-fan

Chris, which guide did you follow when installing the new whonix 14 Template as 
a "recommended whonix install procedure"? I found these two.

http://dds6qkxpwdeubwucdiaord2xgbbeyds25rbsgr73tbfpqpt4a6vjwsyd.onion/wiki/Qubes/Install#
 


https://www.qubes-os.org/doc/reinstall-template/ 


Thanks

Aug 13, 2018, 2:48 AM by tas...@posteo.net:

> On 08/12/2018 05:23 PM, Andrew David Wong wrote:
>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA512
>>
>> On 2018-08-12 14:26, 'awokd' via qubes-users wrote:
>>
>>> On Sun, August 12, 2018 6:16 pm, >>> qubes-...@tutanota.com 
>>> >>
 I am planning to move from my Whonix 13 to Whonix 14 on Qubes. My
 question is what way it should be easier, based on the Q user
 experiences. What would you propose - upgrade or re-install? Are
 there any known issues which would call for one or other way?

>>>
>>> Re-install is usually easier.
>>>
 I have few VMs based on the Whonix template with data and
 settings on it. Will the contents of these VMs remain, or will
 it be destroyed - re-install vs upgrade?

>>>
>>> Contents should remain, just set them to the new Whonix template.
>>> Make sure to back up everything first.
>>>
>>
>> The installation guide [1] states:
>>
>> "Re-installation will destroy any existing user data stored in Whonix
>> VMs, unless it is backed up first. To avoid this scenario, it is
>> possible to upgrade Whonix 13 to 14 instead of following these
>> instructions."
>>
>> This was puzzling to me, too, since TemplateVM upgrades usually don't
>> affect user data in TemplateBasedVMs. Could you shed some light on
>> this, Patrick?
>>
>
> What I did: Cloned the old whonix-ws template, switched appvms to the clone, 
> then did 'dnf remove' on the old templates and finally performed the 
> recommended whonix install procedure.
>
> Later, I was able to switch existing whonix appVMs to whonix-ws-14.
>
> -- 
>
> 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/4433888d-cbfe-8ea2-2143-1ba4a0dcae0e%40posteo.net
>  
> >
>  .
> For more options, visit > https://groups.google.com/d/optout 
> > .
>

-- 
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/LJn2jxP--3-1%40tutanota.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Qubes 4.0 sluggish feel

2018-08-13 Thread Outback Dingo

On Mon, Aug 13, 2018 at 1:14 PM 'awokd' via qubes-users
 wrote:
>
> On Mon, August 13, 2018 11:03 am, CF wrote:
> > On 08/13/2018 12:41 PM, 'awokd' via qubes-users wrote:
> >
>
> >>
> >> Have you checked the logs to see if X is using software rendering
> >> and/or the video driver is throwing any errors on load?
> >>
> >>
> > I have not checked, I simply noticed that the move from 4.9.56 to
> > 4.14.57 was bringing all the fixes for Spectre / Meltdown, and I suspect
> > they are responsible for the 'sluggish feel' (Q3.2 here, not 4.0)
> >
> > I can check for rendering and video driver, which logs are you talking
> > about exactly?
>
> X.org log is described here:
> https://www.qubes-os.org/doc/intel-igfx-troubleshooting/#software-rendering-or-video-lags
>
> If the driver is having trouble loading, you should see a related error in
> dom0's journalctl.
>
>

i am having 0 errors with nvidia card nothing in the logs really , yet
still having the same issue, no updates, one tweak for performance as
suggested helped a little but not alot


> --
> You received this message because you are subscribed to a topic in the Google 
> Groups "qubes-users" group.
> To unsubscribe from this topic, visit 
> https://groups.google.com/d/topic/qubes-users/SXkX2yQc0ug/unsubscribe.
> To unsubscribe from this group and all its topics, 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/b6334b8ded87436ddad9ccb93cbbe6ca.squirrel%40tt3j2x4k5ycaa5zt.onion.
> For more options, visit https://groups.google.com/d/optout.

-- 
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/CAKYr3zzEDfHgbwgnr9qr%2B-vbG2pbD-YRfWPocqX9FKqU4jpcQQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: Qubes 4.0 sluggish feel

On Mon, August 13, 2018 11:03 am, CF wrote:
> On 08/13/2018 12:41 PM, 'awokd' via qubes-users wrote:
>

>>
>> Have you checked the logs to see if X is using software rendering
>> and/or the video driver is throwing any errors on load?
>>
>>
> I have not checked, I simply noticed that the move from 4.9.56 to
> 4.14.57 was bringing all the fixes for Spectre / Meltdown, and I suspect
> they are responsible for the 'sluggish feel' (Q3.2 here, not 4.0)
>
> I can check for rendering and video driver, which logs are you talking
> about exactly?

X.org log is described here:
https://www.qubes-os.org/doc/intel-igfx-troubleshooting/#software-rendering-or-video-lags

If the driver is having trouble loading, you should see a related error in
dom0's journalctl.


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

[qubes-users] Re: Qubes 4.0 sluggish feel

2018-08-13 Thread CF

On 08/13/2018 12:41 PM, 'awokd' via qubes-users wrote:
> On Fri, August 10, 2018 3:28 pm, CF wrote:
>> On 08/10/2018 06:47 AM, Outback Dingo wrote:
>>
>>> On Thu, Aug 9, 2018 at 5:49 AM cooloutac  wrote:
>>>



 I get this problem sometimes when I update templates,   then restart
 all the vms.  Solution is to reboot the pc.  Only happens to me on
 4.0


 --

>>>
>>> nope its been rebooted numerous times, still same issue, always sluggish
>>> choppy ui, take 20+ seconds just to swtich tabs in chrome / firefox in
>>> both fedora and debian. other apps seem to take longer times loading,
>>> switching apps is the same
>>>
>>
>> Same here, I will probably switch back dom0 and all the templates / VMs
>> to the previous kernel.
> 
> Have you checked the logs to see if X is using software rendering and/or
> the video driver is throwing any errors on load?
> 
> 
I have not checked, I simply noticed that the move from 4.9.56 to
4.14.57 was bringing all the fixes for Spectre / Meltdown, and I suspect
they are responsible for the 'sluggish feel' (Q3.2 here, not 4.0)

I can check for rendering and video driver, which logs are you talking
about 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/pkrod7%24nia%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Can't use settings in fedora 28 vm.

2018-08-13 Thread Michael MENG

Actually i need to add chinese input method in appvm, but there's nothing in 
settings, i can't found Region & Language/Input Sources. How can i open the 
gnome settings in qubes?

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

Re: [qubes-users] Network not working until several minutes after login

On Mon, August 13, 2018 8:41 am, Andreas Rasmussen wrote:
> søndag den 12. august 2018 kl. 15.38.19 UTC+2 skrev Unman:
>> On Sat, Aug 11, 2018 at 12:13:32PM -0700, Andreas Rasmussen wrote:
>>
>>> Hi!
>>>
>>>
>>> For the last couple of months, my Qubes 4.0 install has suffered from
>>> a weird bug. When I login to Qubes, my network icon shows, that I'm
>>> connected to my wifi: No matter what VM i'm using, I cannot connect
>>> to anything online.
>>>
>>> However, if I wait a short while, perhaps 3-4 minutes, I can open any
>>> VM and connect to whatever I want.
>>>
>>>
>>> When Qubes is booting, I get a short errormessage, that Qubes is
>>> trying to start a nonexisting VM (which I deleted). Then it starts
>>> sys-net without problems. I don't know if this might be relevant for
>>> the problem?
>>>
>>> best regards,
>>>
>>> Andreas
>>>
>>>
>>
>> Is it possible that you are using Whonix gateway by default, and it's
>> taking a long time to get the Tor connections set up?
>>
>> What does your Qubes network setup look like?
>>
>
> Hi!
>
>
> No, I've removed the Whonix gateway. My setup is the standard: AppVM ->
> sys-firewall -> sys-net. I haven't done any special configs.
>
> However: I've noticed that during startup, I get a short errormessage
> that Qubes is trying to start an old VM, that I've deleted approximately
> at the time this problem occured. However, since the VM is deleted, I
> have no idea how to tell Qubes to *not* try to start that non-existing
> VM. Any tips on that? :)

Check journalctl in sys-net and see if there are DHCP (or other) errors?


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

Re: [qubes-users] Corrupted LVM Pool Metadata - no free space (recoverable?)

On Mon, August 13, 2018 7:59 am, joevio...@gmail.com wrote:

> Should I mount each LV
> and attempt to import the root.img and private.img files? How would I
> mount those to get to the files, and how would import to Qubes?

Sounds pretty FUBARd. LVs don't have .img files; if you can manage to get
them mounted you might be able to recover contents. Boot from some
recovery distribution and get the Qubes PV attached, then "mount 
/dev/mapper/qubes_dom0-vm--vmname--private" for example.


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

Re: [qubes-users] Re: Qubes 4.0 sluggish feel

On Fri, August 10, 2018 3:28 pm, CF wrote:
> On 08/10/2018 06:47 AM, Outback Dingo wrote:
>
>> On Thu, Aug 9, 2018 at 5:49 AM cooloutac  wrote:
>>
>>>
>>>
>>>
>>> I get this problem sometimes when I update templates,   then restart
>>> all the vms.  Solution is to reboot the pc.  Only happens to me on
>>> 4.0
>>>
>>>
>>> --
>>>
>>
>> nope its been rebooted numerous times, still same issue, always sluggish
>> choppy ui, take 20+ seconds just to swtich tabs in chrome / firefox in
>> both fedora and debian. other apps seem to take longer times loading,
>> switching apps is the same
>>
>
> Same here, I will probably switch back dom0 and all the templates / VMs
> to the previous kernel.

Have you checked the logs to see if X is using software rendering and/or
the video driver is throwing any errors on load?


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

Re: [qubes-users] Whonix 14 - upgrade or re-install? Whats more smooth, less troublesome?

2018-08-13 Thread qubes-fan

This sounds very interesting Chris. This could be the way around the "loss of 
VM data" during the install process and push the INSTALL over UPGRADE 
decission. Did you do the same with the whonix-gw too?


Aug 13, 2018, 2:48 AM by tas...@posteo.net:

> On 08/12/2018 05:23 PM, Andrew David Wong wrote:
>
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA512
>>
>> On 2018-08-12 14:26, 'awokd' via qubes-users wrote:
>>
>>> On Sun, August 12, 2018 6:16 pm, >>> qubes-...@tutanota.com 
>>> >>
 I am planning to move from my Whonix 13 to Whonix 14 on Qubes. My
 question is what way it should be easier, based on the Q user
 experiences. What would you propose - upgrade or re-install? Are
 there any known issues which would call for one or other way?

>>>
>>> Re-install is usually easier.
>>>
 I have few VMs based on the Whonix template with data and
 settings on it. Will the contents of these VMs remain, or will
 it be destroyed - re-install vs upgrade?

>>>
>>> Contents should remain, just set them to the new Whonix template.
>>> Make sure to back up everything first.
>>>
>>
>> The installation guide [1] states:
>>
>> "Re-installation will destroy any existing user data stored in Whonix
>> VMs, unless it is backed up first. To avoid this scenario, it is
>> possible to upgrade Whonix 13 to 14 instead of following these
>> instructions."
>>
>> This was puzzling to me, too, since TemplateVM upgrades usually don't
>> affect user data in TemplateBasedVMs. Could you shed some light on
>> this, Patrick?
>>
>
> What I did: Cloned the old whonix-ws template, switched appvms to the clone, 
> then did 'dnf remove' on the old templates and finally performed the 
> recommended whonix install procedure.
>
> Later, I was able to switch existing whonix appVMs to whonix-ws-14.
>
> -- 
>
> 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/4433888d-cbfe-8ea2-2143-1ba4a0dcae0e%40posteo.net
>  
> >
>  .
> For more options, visit > https://groups.google.com/d/optout 
> > .
>

-- 
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/LJmoob9--3-1%40tutanota.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] how to connect USB to standalone HVM Kali

On Mon, August 13, 2018 6:36 am, Djon Snow wrote:
> понедельник, 13 августа 2018 г., 0:05:35 UTC+3 пользователь awokd
> написал:
>
>> On Sat, August 11, 2018 11:56 am, bbbenjjjami...@gmail.com wrote:
>>
>>> how to connect USB to standalone HVM Kali?
>>
>> Try cloning debian-9 to a new standalone HVM, then installing Kali on
>> top of it.
>
> I tried to do so, but it does not work out, at half the load VM just
> turns off

At which step of https://www.qubes-os.org/doc/pentesting/kali/#katoolin3_2
or https://www.qubes-os.org/doc/pentesting/kali/#templatevm-from-debian3_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/3f412c876ece256fbf02209d56f525d2.squirrel%40tt3j2x4k5ycaa5zt.onion.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Network not working until several minutes after login

2018-08-13 Thread Andreas Rasmussen

søndag den 12. august 2018 kl. 15.38.19 UTC+2 skrev Unman:
> On Sat, Aug 11, 2018 at 12:13:32PM -0700, Andreas Rasmussen wrote:
> > Hi!
> > 
> > For the last couple of months, my Qubes 4.0 install has suffered from a 
> > weird bug. When I login to Qubes, my network icon shows, that I'm connected 
> > to my wifi: No matter what VM i'm using, I cannot connect to anything 
> > online. 
> > 
> > However, if I wait a short while, perhaps 3-4 minutes, I can open any VM 
> > and connect to whatever I want. 
> > 
> > When Qubes is booting, I get a short errormessage, that Qubes is trying to 
> > start a nonexisting VM (which I deleted). Then it starts sys-net without 
> > problems. I don't know if this might be relevant for the problem?
> > 
> > best regards,
> > 
> > Andreas
> > 
> 
> Is it possible that you are using Whonix gateway by default, and it's
> taking a long time to get the Tor connections set up?
> 
> What does your Qubes network setup look like?

Hi!

No, I've removed the Whonix gateway. My setup is the standard: AppVM -> 
sys-firewall -> sys-net. I haven't done any special configs.

However: I've noticed that during startup, I get a short errormessage that 
Qubes is trying to start an old VM, that I've deleted approximately at the time 
this problem occured. However, since the VM is deleted, I have no idea how to 
tell Qubes to *not* try to start that non-existing VM. Any tips on 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/c88c4971-8fa2-45d7-8d9c-3366908d404e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Corrupted LVM Pool Metadata - no free space (recoverable?)