Re: [qubes-users] USB headset, how to control volume?
On Thu, Jul 16, 2020 at 10:40:47PM +0200, 'cubit' via qubes-users wrote: > Is there any way to control the sound level once it is passed to an > AppVM? It would also be nice to control my mic levels but so far > people have not complained about me being too quiet so not as > pressing. use an audiomixer app (like pavucontrol) inside the appvm. -- You received this message because you are subscribed 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20200716205237.GB210712%40priv-mua.
Re: [qubes-users] Template Installation Problem
On Fri, Jul 03, 2020 at 11:01:48AM +0200, Qubes wrote: > Using sys-whonix as UpdateVM to download updates for Dom0; this may take > some time... > error: could not delete old database at > /var/lib/qubes/dom0-updates/home/user/.rpmdbold.3146 > I don't have a /var/lib/qubes/dom0-updates/ folder that folder is in your updatevm, not dom0. just restarting the updatevm should clean things up, but means you have to download the template RPM again. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20200703093011.GB17383%40priv-mua.
Re: [qubes-users] Qubes dom0 to Debian
On Thu, Jul 02, 2020 at 07:08:27PM +0200, Joo Nasss wrote: > How to Change qubes OS dom0 to Debian? short answer: if you have to ask, you dont. longer: https://github.com/QubesOS/qubes-issues/issues/1919 -- You received this message because you are subscribed 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20200702174438.GA17383%40priv-mua.
Re: [qubes-users] USB fails to boot on one computer, but succeeds on other, and the USB listed in device selection menu's storage volume is waaay lower than it really is
On Sat, Jun 27, 2020 at 01:28:57AM -0700, Frogfessor wrote: > that it doesn't support virtualization. But, either way, I was planning to > just flash it onto a live USB anyways. But, my 64gb USB, which has been > formatted to FAT32 and has no filed on it, is said to have only about 900 > kilobytes of free storage left. When I check in Window's file manager, it you can not install qubes to a fat partition. delete the fat partition to make the space usable for qubes. you should be able to do that from the installer. > the USB I would like to download Qubes to is a 64gb SanDisk 3.0. I'm fairly > new to Linux 'n all, but please, I've spent 5 days jumping hurdle after > hurdle and researching more and more just to get to this point. ANY help i would recommend starting with a plain qubes install in this case instead of some not-recommended "creative" franken-installation. -- You received this message because you are subscribed 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20200627084636.GL137863%40priv-mua.
Re: [qubes-users] Move To a Larger Disk
On Fri, Jun 26, 2020 at 06:38:09AM -0300, Franz wrote: > Next time I would suggest a very simple and reliable backup of the old > disk, install Qubes on the new disk, restore backup on the new disk and > you'll have a clean new system with no problems. uh. even in the best case, this is a _lot_ more effort than just copying over the disk and resizing the partition. but yes. it is important to have backups and know how to restore them. i recommend borgbackup 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20200626094322.GK137863%40priv-mua.
Re: [qubes-users] Move To a Larger Disk
On Thu, Jun 25, 2020 at 10:29:33PM +, 'Matt Drez' via qubes-users wrote: > How to safely raise it to the maximum size (1TB ) and not just an > arbitrary number that's close enough? which "it"? if you bought a "1TB disk", that usualy means 931GiB. the pvresize dance means the pv is now as big as the partition/luks. > VG #PV #LV #SN Attr VSize VFree > qubes_dom0 1 141 0 wz--n- 929.32g 556.51g so 929.32g sounds about right, thats the size of your disk minus the boot partition minus some headers. > pool00 qubes_dom0 twi-aotz-- 897.98g 33.45 14.82 you can probably grow that pool some more. check "vgs" again, the VFree is now something like 6.5g? so run "lvresize -L +6g qubes_dom0/pool00" i would NOT assign the last few megabytes to a device, but keep them "free" in case i need to dig myself out of a "oops, metadata is full because i have too many snapshots" situation. -- You received this message because you are subscribed 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20200625224532.GJ137863%40priv-mua.
Re: [qubes-users] Move To a Larger Disk
On Thu, Jun 25, 2020 at 08:54:51PM +, Matt Drez wrote: > This is where I am at now (below). What would be the best course of > action. What would you if this was your mess to clean up? :) > WARNING: Device > /dev/mapper/luks-55a20051-8c1a-435e-a1c8-862493f2d576 has size of > 1948924598 sectors which is smaller than corresponding PV size of > 1949320573 sectors. Was device resized? this is a bit worrying and i am not sure how you ended up with that. to clean this up, i would try ... pvresize --setphysicalvolumesize 900g /dev/mapper/luks-55a20051-8c1a-435e-a1c8-862493f2d576 pvresize /dev/mapper/luks-55a20051-8c1a-435e-a1c8-862493f2d576 then check that the warning is gone (pvs or vgs). AFTER resolving the PV size problem, i would grow the thin pool. > VG #PV #LV #SN Attr VSize VFree > qubes_dom0 1 141 0 wz--n- 929.51g 556.70g > [@dom0 ~]$ sudo lvs qubes_dom0/pool00 > LV VG Attr LSize Pool Origin Data% Meta% Move Log > Cpy%Sync Convert > pool00 qubes_dom0 twi-aotz-- 347.98g 86.33 14.67 this suggests you resized the poolmetadata already? if you did NOT: lvresize --poolmetadatasize +1G qubes_dom0/pool00 then resize the pool itself: lvresize -L +550G qubes_dom0/pool00 then check it worked by running "lvs qubes_dom0/pool00" again, the new LSize should be 900g, and the Meta% should still be a lot smaller than the Data%. > [@dom0 ~]$ sudo df -h / > Filesystem Size Used Avail Use% Mounted on > /dev/mapper/qubes_dom0-root 1.1T 9.7G 1.1T 1% / this is unfortunate, but not critical. if you really want to shrink the FS again, look up how to shrink a ext4 FS. basicly you will have to boot from some rescue disk or live image, open the luks container + lvm, fsck and resize2fs the fs, then shrink the LV, then grow the fs again to fit. if it were my system, i wouldnt bother 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20200625214028.GI137863%40priv-mua.
Re: [qubes-users] Move To a Larger Disk
On Thu, Jun 25, 2020 at 08:05:11PM +, Matt Drez wrote: > That makes total sense. Well, I'm glad I didn't screw everything up > but now how do I reverse what I have done so I could achieve my goal? > How can I "take away" the 100% free space I assigned to root and give > it to the whole system? i am not sure you have to do anything. check with "vgs", does it still report 500+ VFree? then you can just go ahead with the "resizing pool00 meta+data" parts. if you really want to clean up the qubes_dom0-root situation... check with "lsblk -d /dev/mapper/qubes_dom0-root". does it say 500something GB? all good, nothing to do. does it say 1TB? meh, continue. check with "df -h /", does it report 500something GB total? good! IF the df-total is 500something GB, you can just lvresize qubes_dom0-root back down to something like 600GB. pick something that is 10% or so bigger than your old disk and the df-total. DO NOT try to hit the exact size! DO NOT try this if df says 1TB total! -- You received this message because you are subscribed 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20200625204225.GH137863%40priv-mua.
Re: [qubes-users] Move To a Larger Disk
On Wed, Jun 24, 2020 at 07:49:56PM +, Matt Drez wrote: > [@dom0 ~]$ sudo lvextend -l +100%FREE /dev/mapper/qubes_dom0-root this means you resized your dom0 root volume. that is probably not what you were trying to do. you can check if that worked with "df -h /" or "lsblk -d /dev/mapper/qubes_dom0-root" in dom0. > [@dom0 ~]$ sudo lvextend -l +100%FREE > /dev/mapper/luks-55a20051-8c1a-435e-a1c8-862493f2d576 it is dangerous to press random buttons when dealing with diskspace. > [@dom0 ~]$ sudo lvs qubes_dom0/pool00 > LV VG Attr LSize Pool Origin Data% Meta% Move Log > Cpy%Sync Convert > pool00 qubes_dom0 twi-aotz-- 347.98g 87.01 58.34 if you want to enlarge logical volume qubes_dom0/pool00, you should enlarge qubes_dom0/pool00, not random other devices. and it is important you enlarge the metadata volume first. something like: lvresize --poolmetadatasize +1G qubes_dom0/pool00 -- You received this message because you are subscribed 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20200625181841.GG137863%40priv-mua.
Re: [qubes-users] Updating Linux and Whonix
On Thu, Jun 25, 2020 at 11:03:19AM -0700, E. Foster wrote: > I finally got latest version of Qubes installed. thanks for the what version is that? > version displayed did not change. From reading the documentation, The > updater should have updated to Whonix 16, and Fedora 35 or 36 as indicated what documentation is that? there is no "fedora 35 or 36" yet. those are versions that will be released in 1-2 years. > Fedora 30. Would any of you have some suggestions as to how to build a fedora 30 is unsupported. you should install fedora 31 or 32 first. https://www.qubes-os.org/news/2020/04/30/fedora-31-template-available/ -- You received this message because you are subscribed 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20200625181157.GF137863%40priv-mua.
Re: [qubes-users] Move To a Larger Disk
On Wed, Jun 24, 2020 at 04:38:21PM +, Matt Drez wrote: > None of the three commands you gave showed 900+GB you can doublecheck the partition and luks device already have the right size with ... lsblk -d /dev/nvme* /dev/mapper/luks-* if these show 900+GB you are good to go with the lvm resizing. > Now, do I have to do all 3 steps in that specific order to solve the problem? and yes, you need to do at least the "resize the pv" and "resize the thin pool" (and its metadata device!) parts, i expect the "vg" will resize itself when you resize the existing pv. (so recheck with pvs/vgs/lvs after each step) -- You received this message because you are subscribed 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20200624165528.GE137863%40priv-mua.
Re: [qubes-users] Move To a Larger Disk
On Tue, Jun 23, 2020 at 04:11:56PM +, 'Matt Drez' via qubes-users wrote: > I was trying to move my Qubes to a bigger disk. I used clonezilla to > clone it. I was able to successfully boot up but Qubes was still > complaining that my disk is full. For some reason it doesn't want to > use the free disk space that's available. I have no clue how to > troubleshoot this. (please see attachment) i dont fully understand that gparted screenshot, but it looks like you resized the partition already. so whats missing is on one of the LVM layers of the stack. check with "pvs", it should list a /dev/mapper/luks-something. does that PV have the right PSize of 900+ GB? if not, google: pvresize next check with "vgs", it should list a qubes_dom0. does that vg have the right VSize of 900+ GB? if not, google: vgextend next check with "lvs qubes_dom0/pool00". does that pool lv have the right LSize of 900+GB? if not, google: resize lvm thin pool -- You received this message because you are subscribed 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20200623212414.GD137863%40priv-mua.
Re: [qubes-users] Debian10 - Reading From Proxy Failed
On Mon, Jun 22, 2020 at 04:54:18PM +, 'Matt Drez' via qubes-users wrote: > Reading from proxy failed - read (104: Connection reset by peer) [IP: > 127.0.0.1 8082] try ... qrexec-client-vm '$default' qubes.UpdatesProxy ... and/or ... (echo -e 'GET http://google.com/ HTTP/1.1\n\n' ; sleep 5) | qrexec-client-vm '$default' qubes.UpdatesProxy -- You received this message because you are subscribed 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20200622175152.GB137863%40priv-mua.
Re: [qubes-users] How to install snort or ossec Into Network vm
On Sat, Jun 20, 2020 at 11:12:51AM +0200, Joo Nasss wrote: > How can I Install Network Intrusion system for the whole system just as you would on any other fedora. (or whatever distro template you are using for your netvm) -- You received this message because you are subscribed 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20200620113843.GA137863%40priv-mua.
Re: [qubes-users] Full disk encryption in qubes - best practice for high risk environment
On Fri, Jun 12, 2020 at 12:49:04PM +, taran1s wrote: > - - set a higher encryption from qubes default to aes 512-bit full disk > encryption. a) there is no "aes 512". b) the qubes default is aes-xts-512. (which is really aes-256 with two different keys since whoever implemented it for linux read the XTS paper wrong, but it doesnt matter for security) c) check "cryptsetup luksDump /dev/yourqubesluksdev" > Is this possible to do from within running qubes or will I need to > reinstall the QubesOS and do it all fresh? most likely for the "encryption" part no change is required. so just moving /boot + grub. > cryptsetup luksChangeKey /dev/sdX with sdX to be the luks partition > like for example sd3 in case of default qubes installation procedure. > Is that case from inside of qubes too? cryptsetup can be used from inside qubes dom0, yes. i recommend adding a new passphrase first, making sure it works, then removing the old one. luks default has 8 key slots. > Are there any pros/cons of this setup? make sure to have more than one boot device for redundancy. you will have to update them all for every kernel, xen or grub update. (or accept booting your system from an old grub/xen/kernel if you end up using an outdated boot stick) -- You received this message because you are subscribed 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20200612130106.GC998%40priv-mua.
Re: [qubes-users] How to add multiple virtual hard drive to a StandaloneHVM
On Wed, Jun 10, 2020 at 10:28:22PM -0700, ramboman...@gmail.com wrote: please dont top-post here. > The reason I was specifying virtual hard drives and not partitions, is ... > functionalities it offers, I am trying to reproduce a virtual file server > containing many hard drives so I can play around with different layouts and > learn from it. for the purpose of "learning zfs" it should not matter where the block devices come from. anything from physical devices, partitions, logical volumes or even loopbacks should be the same for most practical purposes. > In VirtualBox, it is fairly straightforward to add new virtual hard drives > to a VM when needed. I'm trying to do the same thing for a StandaloneHVM, > but I have not found how to do that yet. just add them with qvm-block (or the device widget). if the actual question is how to create/manage devices under linux, consult the manpages for "losetup" and/or "lvcreate" and/or "fdisk". -- You received this message because you are subscribed 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20200611091809.GA998%40priv-mua.
Re: [qubes-users] Where to connect monitor
On Fri, Jun 05, 2020 at 08:05:50AM -0700, romandash...@gmail.com wrote: > I can passthrough GPU to *one* of the VMs for computational purposes. But > for display purposes, I still must connect my monitor to the motherboard > display port only. Correct? the question of where the physical port is is unrelated to this. if you pass a GPU to a vm, the vm can use it in whatever way it wants. -- You received this message because you are subscribed 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20200605183132.GK1079%40priv-mua.
Re: [qubes-users] Qubes won't boot
On Thu, Jun 04, 2020 at 01:45:26PM +0200, haaber wrote: > how do you use qvm-run if qubes won't boot? First step is a always > proper backup, on some external drive. That is what I wrote in my other > answer. i recommend to read what this thread is about. the user installed qubes to a new ssd and is trying to recover data from his old qubes install on a hdd. both are connected to the same computer and we already made it past the "lukeOpen and activate VG in VM" hurdles. afaict the initial "wont boot" problem was the computer having strong opinions about which of the devices it wanted to boot from. -- You received this message because you are subscribed 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20200604121724.GJ1079%40priv-mua.
Re: [qubes-users] Qubes won't boot
> On 6/3/20 10:58 PM, Boot problems wrote: > > How do I restore a mounted vm using dd? qvm-run -p HELPERVM "sudo cat /dev/mapper/qubes_dom0-vm--VMOLD--private" | sudo dd conv=sparse of=/dev/mapper/qubes_dom0-vm--VMNEW--private this assumes you have the old disk opened in HELPERVM, the old vm name is VMOLD and the new VM name is VMNEW. this needs to be run in dom0, as one line (or with a linebreak after the |) VMOLD and VMNEW can have the same name. VMNEW needs to be created and should not have been started before running this. if you started VMNEW already (or need to rerun the dd), run "blkdiscard /dev/mapper/qubes_dom0-vm--VMNEW--private" before the dd chain. the private volume for VMNEW needs to be same-or-bigger than the one of VMOLD. On Thu, Jun 04, 2020 at 01:20:43PM +0200, haaber wrote: > dd = disk destroyer. > I there is the slightest chance of error, don't use it. that is really overly pessimistic, you can completely destroy your system with pretty much any tool when used the wrong way. yes, even with firefox. -- You received this message because you are subscribed 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20200604113641.GI1079%40priv-mua.
Re: [qubes-users] Qubes won't boot
On Sun, May 31, 2020 at 04:59:43PM -0700, Boot problems wrote: > Using fdisk -l /dev/xvdi shows me 2 partitions only, a 200m EFI System > and xvdi2 a 931G Linux file system, there are no more partitions even > if I decrypt, mount and fdisk -l /dev/xvdi2 after the luksOpen, check with lvm tools: run "sudo vgs -a". (if you dont have vgs installed: "sudo dnf -y install lvm2") does it report a qubes_dom0? good. now check for logical volumes: "sudo lvs -a" _lots_ of reports, with vm names in them? good! what are the attrs on those (third column)? "Vwi---tz--"? (the important part there is: no "a" in the attrs.) then you need to activate the volume group: "vgchange -ay qubes_dom0" after that, you should have a-plenty of new devices in /dev/mapper and the vm-private-volume ones are the ones with names ending in -private. you should be able to mount these. (or just restore them with dd to new vms) -- You received this message because you are subscribed 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20200601110401.GE1079%40priv-mua.
Re: [qubes-users] Qubes won't boot
On Sun, May 31, 2020 at 01:57:24PM -0700, Boot problems wrote: > /dev/xvdi but using that it just says permission denied. so use "sudo fdisk -l /dev/xvdi" > the cryptsetup luksOpen /dev/xvdi2 name, then it says access denied, I so use "sudo cryptsetup luksOpen /dev/xvdi2 name" > can seemingly unencrypted it from the gnome-disks GUI but not mount it. it contains an lvm stack, so there will be many virtual volumes inside. after the luksOpen, check "ls -al /dev/mapper/*-private" and look for the devices with the names of your old VMs. you should be able to mount these. hint: use "sudo mount /dev/mapper/whatever-private /mnt/whatever" hint2: you will have to replace the "whatever" part there. hint3: you will have to "sudo mkdir /mnt/whatever" or create new VMs, and restore the whole private volumes with dd. > However I tried booting up the old hdd again and now it works as long > as the ssd is connected too but all my data is gone and is just a > clone of the new ssd, without the ssd connected it doesn't boot up > like before, I guess it has been formatted then, is there a way to that sounds more like you are just booting from your ssd into the fresh install. -- You received this message because you are subscribed 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20200531211905.GD1079%40priv-mua.
Re: [qubes-users] Qubes won't boot
On Sun, May 31, 2020 at 12:45:22PM -0700, Boot problems wrote: > Hello, I wanted to migrate from my old hhd to a new ssd, I installed [...] > could it be a grub issue? What can I do? assuming you were NOT reinstalling because you were compromised... - just boot your new qubes system - with the old HDD attached (directly or through USB) - check if there are partitions on it (fdisk -l /dev/hdx) - open the luks container from the HDD (google: cryptopen) - you should now have access to the lvm volume of your old system - with that access, you can create replacement vms and dd over their private volumes. see how far you can get on that list. ask more specific questions as required. -- You received this message because you are subscribed 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20200531200229.GC1079%40priv-mua.
Re: [qubes-users] Re: docker install problems on debian-10
On Sun, May 31, 2020 at 11:55:15AM +0200, haaber wrote: > Thank you! I removed my debian-9 template long ago (surprised?), but I > could re-install one for building. Just to evaluate the time-cost: how > would "downgrade" work? just install the right rpm for either kernel or debian template. so close to no effort, just a bit of download+diskspace required. they are all still in the repo, even if very outdated: https://ftp.qubes-os.org/repo/yum/r4.0/current/dom0/fc25/rpm/ check the kernel-qubes-vm-* and kernel-latest-qubes-vm-* even more versions if you look at the -testing repo: https://ftp.qubes-os.org/repo/yum/r4.0/current-testing/dom0/fc25/rpm/ minor points to consider: - make sure you pick the *qubes-vm* pkg if you want a kernel for use in appvms. - you can have as many vm-kernels installed as you have diskspace for. - if you want to use many and use automated updates, may want to crank up installonly_limit in dom0:/etc/dnf/dnf.conf and add kernel-latest and kernel-latest-qubes-vm to installonlypkgs. - depending on how you install the pkgs, you may have to use --force to make it install _older_ pkgs than already installed. -- You received this message because you are subscribed 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20200531103835.GB1079%40priv-mua.
Re: [qubes-users] Qubes don't Install on revodrive
On Sun, May 31, 2020 at 09:07:14AM +0200, Joo Nasss wrote: > Qubes 4.0.3 don't Install on revodrive > There comes an Error that ist failed to make DM RAID not familiar with revodrive, but for installing to a different kind of barely-supported storage (internal eMMC via sdhci-pci driver) i tend to just install to a USB stick (32GB+ will do, but you have to be quite patient) and dd the partitions over to the target storage. since most of the referencing (like from fstab, initrd) is done by uuid there is basicly no config adjustment required when moving the partitions around. this also allows "hybrid" modes for these "oh yeah, i botched the internal bootloader, so let me /boot from USB again while using internal luks/root volume". -- You received this message because you are subscribed 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20200531080948.GA1079%40priv-mua.
Re: [qubes-users] Updating sys-usb template
On Sat, May 30, 2020 at 09:46:57AM +0200, Zbigniew Łukasiak wrote: > > > > disable sys-usb autostart. > > > maybe "lock out" refers to a USB keyboard ? > > yes, that is how i read it, and that is what my suggestions for > > dealing with the update are about. > > Yes - I have an USB keyboard. So just to be sure - when I checkout > "start qube automatically on boot" in the sys-usb Qube Settings and > reboot - then the system will use my USB keyboard directly without any > problems? if you are entering your disk encryption passphrase during boot using an USB keyboard that means your usb keyboard is directly connected to dom0 during boot. and it will stay there until you (try to) start sys-usb. so my general recommendation for people who rely on usb keyboards in their qubes setup is to disable sys-usb autostart. (not just for replacing templates, but in general) -- You received this message because you are subscribed 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20200530101131.GZ1079%40priv-mua.
Re: [qubes-users] Updating sys-usb template
> > disable sys-usb autostart. > maybe "lock out" refers to a USB keyboard ? yes, that is how i read it, and that is what my suggestions for dealing with the update are about. -- You received this message because you are subscribed 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20200529220220.GY1079%40priv-mua.
Re: [qubes-users] USB3 Controller
On Fri, May 29, 2020 at 11:09:00PM +0200, Magali Bardet wrote: > Does anyone know what is the problem ? How can I solve it ? use "qvm-block" instead of "qvm-usb" to attach it to another qube. (or the block instead of the usb section of the device widget) -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20200529212349.GX1079%40priv-mua.
Re: [qubes-users] Updating sys-usb template
On Thu, May 28, 2020 at 09:26:34AM +0200, Zbigniew Łukasiak wrote: > My sys-usb uses a very old template. I tried some googling - but > failed to find any advice about update it without locking me out of > the system. disable sys-usb autostart. and reboot. now you can replace the sys-usb template. and try to start sys-usb with the new template. if that fails, you will have to reboot again, and retry. but basicly this reduces the problem from "locked out and need a recovery disk" to "additional unplanned reboots" (which are not that critical if you shut down all other VMs first) -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20200529200439.GW1079%40priv-mua.
Re: [qubes-users] Re: Errors during downloading metadata for repository 'fedora-modular':
On Wed, May 27, 2020 at 07:30:29AM -0700, Dave wrote: > The upgrade process for Standalone Fedora-31-work-test worked up until the > end when it complained about disk space. > *dnf --releasever= distro-sync --best* --allowerasing uh, since you do not seem to follow the fedora upgrade guide regarding space management, this result is rather ... unsurprising. to make extra space available for the update, you can use mkfs.ext4 /dev/xvdc3 mount /dev/xvdc3 /mnt/removable and add "--setopt=cachedir=/mnt/removable" to the dnf call. (thats a lot less steps than in the official docs and will cleanup itself too) -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20200527150647.GV1079%40priv-mua.
Re: [qubes-users] qubes-mirage-firewall 0.7
On Mon, May 25, 2020 at 02:23:08AM -0700, sschi...@gmail.com wrote: > On Saturday, 23 May 2020 17:24:42 UTC+2, qubeslover wrote: > Is there any plan to create a package for Qubes Dom0 repo for the future? > We are planning to collaborate with Qubes folks on packaging it. there is https://github.com/QubesOS/qubes-builder/blob/master/example-configs/mirage.conf which builds mirage firewall (and ssh-agent) as a template-vm, which reduces the problem to the more generic "how to ship/install a template" (which can be handled entirely outside dom0 already) as opposed to the very mirage-specific "how to install a vm-kernel in dom0" (which is very dom0 oriented). it actualy works well enough, i have been building+deploying all my mirage vms for more than a year this way. there are some points left to improve: 1) how to include vm-specific prefs/feats with a template pkg. this mainly needs a way for a vm-specific builder to include a file in the final rpm, and that isnt really straightforward since the rpm-builder and vm-builder are like three layers of abstraction apart. 2) "@tag:buildvm @tag:created-by-@srcvm allow" in qubesrpc-policy. the "reference srcvm in dstvm spec" part doesnt exist. 3) automated way to create the pvgrub vm-kernel entry. (probably salt) 4) polishing. (which doesnt make too much sense as long as 1-3 are open) these are not actualy required, but would make the whole thing a lot more userfriendly. -- You received this message because you are subscribed 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20200525100335.GU1079%40priv-mua.
Re: [qubes-users] which OCR software, address database and e-mail program run with the Qubes-OS operating system - welche OCR Software, Adressdatenbank sowie E-Mail- Programm mit dem Betriebssystem Qu
On Mon, May 25, 2020 at 12:08:49AM +0200, Caroline Villinger wrote: > Because I suspect that you can no longer use them with Qubes OS. > That's why I'm interested in whether there is such software in Qubes OS. for these questions, qubes is "just another linux". if you have a working solution for fedora or debian, you can most likely use it with 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/2020052434.GT1079%40priv-mua.
Re: [qubes-users] Re: Some VMs Stopped Opening Terminal
On Wed, May 20, 2020 at 02:01:21PM +, 'Matt Drez' via qubes-users wrote: > > `qvm-run gnome-terminal` > that did not work, but this one had a different error code: > `Command failed with code: 1` check the output by adding a -p: qvm-run -p gnome-terminal it might actualy tell you why it does not want to start! (or it may even work if the reason for not starting is it wanting to say something...) -- You received this message because you are subscribed 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20200520144435.GQ1079%40priv-mua.
Re: [qubes-users] feature request: qvm-print command
On Tue, May 19, 2020 at 11:14:45AM +0200, haaber wrote: > Hello there, I was thinking about the usefulness of a qvm-print command > that takes an input file, sends it to the "printing-VM" (defined in some > config file), and launches there a document viewer (defined in the > config file) in order to control parameters like duplexing, grayscale..) > or just runs plain "lp". After succesful printing it should clean up & > remove the file in the QubesIncoming folder. if your printer is not locally connected, you can just set up a dvm for printing, then use open-in-dvm. for a local printer, i would aim for a qubes-trusted-pdf hybrid that does content neutralization in a dvm, and a printing adapter vm that only accepts pixel streams and does minimal adaption for printjob parameters (duplexing,...). -- You received this message because you are subscribed 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20200519094325.GP1079%40priv-mua.
Re: [qubes-users] Re: Install of the Fedora-32 templateVM failed
On Mon, May 18, 2020 at 02:38:34PM -0700, TheGardner wrote: > [user@sys-firewall ~]$ df -h /var/lib/qubes/dom0-updates > /dev/xvda3 9.6G 8.7G 450M 96% / > sudo mkfs.ext4 /dev/xvdc3 > sudo mount /dev/xvdc3 /var/lib/qubes/dom0-updates > Do I have to change (back) somethings, after I installed the template and > removed the noarch.rpm file from dom0-updates ? xvdc is the "volatile" volume. so this change will vanish on its own the next time you restart sys-firewall. -- You received this message because you are subscribed 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20200518215202.GO1079%40priv-mua.
Re: [qubes-users] Re: Install of the Fedora-32 templateVM failed
On Mon, May 18, 2020 at 03:33:02AM -0700, TheGardner wrote: > - Setting the space up to 4096 on sys-firewall > same result the default download location in udaptevm is /var/lib/qubes/dom0-updates so with a default appvm layout that is inside the rootfs (or its overlay). you can check if this is the limiting factor by running "df -h /var/lib/qubes/dom0-updates" in your updatevm (sys-firewall). to temporarily make more space available there, you can try ... sudo mkfs.ext4 /dev/xvdc3 sudo mount /dev/xvdc3 /var/lib/qubes/dom0-updates sudo chown user.user /var/lib/qubes/dom0-updates -- You received this message because you are subscribed 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20200518105633.GN1079%40priv-mua.
Re: [qubes-users] Mistakenly deleted MBR & system partitions to install, can't boot Qubes
On Sat, May 16, 2020 at 07:25:59PM -0700, sjill...@gmail.com wrote: > nvme0n1p 953G (hd1) > nvme0n1p1 1MBIOS boot efi (hd1,1) this is WAY too small. make it at least 100M, better 500M or even 1GB. here a single set of xen+linux+initrd is about 35-40MB, and in general you want enough space for more than one, plus whatever is needed for booting your other systems. > nvme0n1p2 1GLinux Filesystem (hd1,2) > nvme0n1p3 324.8G Linux LVM(hd1,3) > 15 G Qubes-dom0-swap this indicates you manually changed the partition layout for qubes in too many ways to count, including removing the disk encrpytion. good luck 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20200517080916.GM1079%40priv-mua.
Re: [qubes-users] Installation failed to install several software and VMs
On Sat, May 16, 2020 at 06:22:20AM -0700, sarru1...@gmail.com wrote: > > you need at least one usable template, and in general for a q4.0.3 > > install that means fedora-30. > but I'm not able to connect to the internet. It's not showing sys-net, > nothing. How can I troubleshoot for an internet connection first? you need at least one useable template to get _anything_ done. what VMs do you have? what is the output of "qvm-ls"? if you dont have "fedora-30" or "debian-10", something went _massively_ wrong during the install, and it might be better you nuke the disk and do a clean install. -- You received this message because you are subscribed 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20200516145557.GL1079%40priv-mua.
Re: [qubes-users] Installation failed to install several software and VMs
> > stderr: “qubes-prefs:error: “No such domain:\’fedora-30\”” this indicates you do not have a fedora-30 template. did you deselect templates during install? you need at least one usable template, and in general for a q4.0.3 install that means fedora-30. (and the first thing you should do after install is to get fedora-31 or fedora-32) -- You received this message because you are subscribed 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20200516091307.GK1079%40priv-mua.
Re: [qubes-users] Is it possible to build any BSD template on QubesOS?
On Thu, May 14, 2020 at 06:56:56PM +0200, onelovecisco via qubes-users wrote: > In PHV mode like Fedora-31 or Debian-10. > Is the Qubes-builder capable of this? qubes-builder most certainly can not build bsd templates. but like almost any PC OS, you can install it in hvm mode, and that should give you a single graphical interface window, xl console and network access. after that basic install, you could try if that OS supports pvh mode. but that is probably an interesting can of worms. -- You received this message because you are subscribed 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20200514171541.GI1079%40priv-mua.
Re: [qubes-users] dom0:mmcblk0 regularly disappearing (usb storage mounting)
On Thu, May 14, 2020 at 06:06:43AM -0700, sairus@gmail.com wrote: > Does anyone have an idea what is wrong and how to fix it? "dom0:mmcblk0" and "usb storage" doesnt match up too well. on this computer the dom0:mmcblk0 is a pci device entirely unrelated to anything USB. check what kind of device you are actualy dealing with first. "lspci -kv" in dom0 might show something like: 00:1e.4 SD Host controller: Intel Corporation Device 9d2b (rev 21) Kernel driver in use: sdhci-pci or "lsusb -tv" in sys-usb might show something like: Port 4: Dev 3, If 0, Class=Mass Storage, Driver=usb-storage, 5000M ID 05e3:0747 Genesys Logic, Inc. -- You received this message because you are subscribed 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20200514171018.GH1079%40priv-mua.
Re: [qubes-users] Can I have Windows & Qubes on the same laptop?
On Mon, May 11, 2020 at 01:48:58AM -0700, matteochicarella...@gmail.com wrote: > Firstly, is it safe to have Windows and Qubes on the same machine? I > use VeraCrypt for full disc encryption veracrypt does not support actual full disc encryption. > Also, I've got a 2TB external HDD, would it be safer to run Qubes from > that and keep Windows on my internal drive or is that worse? if that HDD is connected via USB, i would not recommend installing qubes to it. while both "install to usb" and "install to hdd" are supported, they have major drawbacks. > I want to keep maximum security and keep Windows and Qubes seperate. this is not possible. if you multiboot, you are very far from "maximum security". > Any answers to questions or installation guidance is greatly https://www.qubes-os.org/doc/multiboot/ -- You received this message because you are subscribed 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20200511091142.GF1079%40priv-mua.
Re: [qubes-users] Re: HCL - Latitude E6230
On Sun, May 10, 2020 at 06:00:49PM -0700, Catacombs wrote: > am trying to find a USB Wireless Dongle which comes pre installed in > the Kernel. But. there is only exactly _one_ wifi usb dongle that is documented to work with qvm-usb (aka linux usbip) _and_ has a driver included in mainline kernel: ID 7392:7811 Edimax Technology Co., Ltd EW-7811Un 802.11n Wireless Adapter [Realtek RTL8188CUS] Driver=rtl8192cu, 480M https://www.amazon.de/gp/product/B003MTTJOY 2.4 GHz only, very compact, 8eur, mainline driver other usb network devices that work with qvm-usb can be found here: https://github.com/QubesOS/qubes-issues/issues/3778 -- You received this message because you are subscribed 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20200511075046.GE1079%40priv-mua.
Re: [qubes-users] LVM not using full partition size
On Sun, May 10, 2020 at 08:21:03PM +0200, jiggermas...@posteo.de wrote: > [user@dom0 ~]$ sudo vgs > VG #PV #LV #SN Attr VSize VFree > qubes_dom0 1 168 0 wz--n- 701.28g 100.00g this means the VG is already the right size. for resizing the pool, google "how to resize an lvm thin pool". it is really important you resize the metadata volume too, and probably better to do this before resizing the datavolume. going from your earlier numbers, something like ... lvresize --poolmetadatasize 1G qubes_dom0/pool00 then resizing the data volume ... lvresize -L +99G qubes_dom0/pool00 (if it complains on that step, reduce to +98G or so) i would leave any "fractional GB" leftovers free as a reserve in case i have to dig myself out of a "metadata full" situation. verify with pvs/pvs that the "Free" space is (mostly) gone, then check with lvs that pool00 now is bigger and still has a (much) lower meta% than data%. -- You received this message because you are subscribed 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20200510185016.GD1079%40priv-mua.
Re: [qubes-users] LVM not using full partition size
(please dont top post) On Sun, May 10, 2020 at 07:51:01PM +0200, jiggermas...@posteo.de wrote: > Yes, that's what I mean, mixed up terminology there. The pool has now > 584 GiB, before the reinstall it had around 670 GiB - I am wondering > where that additional 84 GiB ended up (and I need it, currently I can't > restore all my VMs). "fdisk -l" should show you how big the partition is. "pvs" should show you how big the luks device is. "vgs" should show you how big the volume group is. pvs + vgs also have a "free" column that shows if there is unused space on that level. -- You received this message because you are subscribed 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20200510180756.GC1079%40priv-mua.
Re: [qubes-users] LVM not using full partition size
On Sun, May 10, 2020 at 05:12:04PM +0200, jiggermas...@posteo.de wrote: > The partition size for the LVM correctly shows about 700 GiB, but the > root storage then only gets 584, and I am not able to set it higher. the root partition is just the root partition for dom0. if you want to see how much space is available to lvm, you need to check with "vgs" or "lvs qubes_dom0/pool00". > Where did the rest of the space end up? Did I do something wrong during for the full picture you can try "lvs -a". -- You received this message because you are subscribed 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20200510170514.GB1079%40priv-mua.
Re: [qubes-users] Re: connecting an iPhone to a AppVM - 4 non-working attempts
On Sun, May 03, 2020 at 10:01:40PM +0100, lik...@gmx.de wrote: > Signal processing controller: Intel Corporation Sunrise Point-LP Serial IO > I2C Controller #0 that is not a USB controller. > Any ideas to resolve that? make sure to attach the right device. if you are trying to assign a USB device ... ... look for one with "USB" in the name. -- You received this message because you are subscribed 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20200503213507.GE987%40priv-mua.
Re: [qubes-users] template and dependent qube show different behaviour
On Thu, May 07, 2020 at 08:30:14AM -0300, Franz wrote: > I installed into Fedora 31 template a proprietary banking rpm > application/plugin/extension which is supposed to work with the browsers > during banking tasks. This is called warsaw_setup_fedora_64.rpm this sounds like a terrible idea unless you make a separate template just for that task. > So why is it that the template and the dependent qubes do not perform the > same behavior? check if it installed anything to /usr/local or /home. rpm -ql warsaw_setup_fedora_64 > Also, any idea to fix it, considering that the banking tasks cannot be done. i would probably just install it in a separate appvm from rc.local this means no modification of the template at all, and the pkg gets reinstalled everytime the appvm used for banking is started. if that is viable depends very much on what that pkg and the software it installs are actualy doing. -- You received this message because you are subscribed 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20200507114037.GP987%40priv-mua.
Re: [qubes-users] Removing Template VMs?
On Wed, May 06, 2020 at 09:31:50PM -0700, viktor.ransm...@gmail.com wrote: > >> i recommend to keep your one-generation-outdated mainline-template > >> around (even if it is EOL) if you can spare the diskspace. > >> if you manage to wreck your new mainline template some way, it is > >> easier to recover from that with an outdated than with no template. > My understanding from reading the documentation is, that I could re-create > the deleted Template VM later in time anyhow, should the need arise ... > [vr@dom0 ~]$ sudo qubes-dom0-update qubes-template-fedora-29 this only works if you have a working template for your netvm and updatevm to run on. having two usable templates makes it much less likely both are going to break at the same time. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20200507072944.GO987%40priv-mua.
Re: [qubes-users] How to bridge a subnet ot the firewall
On Wed, May 06, 2020 at 06:17:58PM +, 'Matt Drez' via qubes-users wrote: > My problem is that I don't see their individual IP addresses in the > capture just a NAT'd address of SPS's eth0. I supposed I have to > create a bridge somehow but that's way beyond my skills. you are simply sniffing the wrong side of the SPS. sniff the downstream interface(s) instead of upstream. > Could one of you geniuses please help me with a detailed walk through? this is basic linux networking. read some primer on "linux as a router" or so. -- You received this message because you are subscribed 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20200506200649.GN987%40priv-mua.
Re: [qubes-users] Salt worm
On Wed, May 06, 2020 at 12:02:55PM +0200, haaber wrote: > > https://labs.f-secure.com/advisories/saltstack-authorization-bypass > Thanks for the source. How do you infer that this "doesn't apply" (and > maybe "did never apply") to qubes? Recall my question: where does salt the vulnerabilities are both in some networked-zeroMQ cloud-management component. which qubes is most certainly not using. > appear "under the hood" in qubes? This question seems relevant, since at > least I (almost) never invoke salt by hand. Is that not a reasonable > question? Explain. the most user-exposed part of qubes-salt is ... ... if you run qubesctl things to manage service vms. it all stays either within a vm or uses qrexec where needed. if you want to take a look, check /srv/ for the salt parts and /usr/lib/python*/*/qubessalt/ for the qubesctl parts. -- You received this message because you are subscribed 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20200506113506.GM987%40priv-mua.
Re: [qubes-users] Salt worm
sm1> Qubes uses Salt, and there's something nasty going around: sm1> https://saltexploit.com/ sm2> to be used "by hand only" we could enforce risk = 0 by the above formula sm2> and keeping fingers off salt for a while. Thanks! sm3> There was today an update for all templates related to the salt. Doesn't sm3> it include a patch? did any of you actualy bother to look at the problem? because i am 99% sure this doesnt apply to qubes. at all. (also you are several days late on this...) this seems to be the original source and contains a fairly good writeup: https://labs.f-secure.com/advisories/saltstack-authorization-bypass -- You received this message because you are subscribed 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20200506091056.GL987%40priv-mua.
Re: [qubes-users] Grub with encrypted boot
On Wed, May 06, 2020 at 06:21:00AM +, lamboicarus via qubes-users wrote: > I am wondering if anyone knows how I might install grub for use with > an encrypted boot partition, or no boot partition at all. I have > recently decided to use btrfs, and I have grub working fine. The > grub2-efi config from the qubes-dom0-unstable repo is working fine, > but it's very complex. Reading about grub on the arch-wiki, it says boot security is a very complex topic. just encrypting your /boot but keeping an unencrypted grub around that opens that /boot is not increasing your security in any meaningful way. it just adds a pile of fragility. for actual cryptographic boot security, you need a "verified" and/or "measured" boot setup. since you mentioned "efi", i would recommend an efi-heads hybrid. deploy a linux kernel with _internal_ initrd (!) as efi-verified boot payload. this way you have to do the efi-signing "just once", and from that linux kernel you can open your encrypted /boot in the "natural linux ways". if your "bios" takes measurements during boot, do tpmtotp (or similar) from the first stage linux (before unlocking your /boot) you dont even have to do any modifications to the payloads inside /boot ... so no resigning/resealing on every payload-xen/kernel update either! this setup does not involve grub at all. this is intentional. -- You received this message because you are subscribed 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20200506071648.GK987%40priv-mua.
Re: [qubes-users] Re: Password not working a day after reinstall
On Tue, May 05, 2020 at 11:36:27PM +0530, Anil wrote: > By the way, as I write this mail, the keyboarding is again acting up: > sometimes eating up space, sometimes emitting two for one key press. > It was working well the whole day. did you try asking the internet about this problem? like, reading the first google hit for "dell xps 9370 keyboard problems"? https://www.dell.com/community/XPS/XPS-13-9370-Keyboard-skips-button-presses/td-p/5835431 seems like that hardware just might be subfunctional by design in general, no "compromise" required. so for the keyboard to work, unplug _all_ cables (data, dock, power) _and_ pick a bios version that matches your current astrological alignment. if you are lucky, then it might work. changes in room temperature might require a different bios version. (that thread is pretty glorious...) -- You received this message because you are subscribed 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20200505183129.GJ987%40priv-mua.
Re: [qubes-users] Password not working a day after reinstall
On Tue, May 05, 2020 at 11:25:53PM +0530, Anil wrote: > I tried to use a USB keyboard, but of course that won't work in Qubes. that is not a "of course" qubes thing but your choice / configuration. you can use a USB keyboard with qubes if you want to, including for entering luks passphrase. > I know this is not directly a Qubes OS related question, but could it > be due to an IME exploit or something like that? There is no question if you assume a hardware/firmware level compromise, there is no real way to reuse any of the hardware in a safe way. == you have to replace _all_ hardware involved. > This kind of thing has happened before. Once the boot password was not > working, even though that too was written down. I had to call Dell you can set multiple passphrases and perhaps add a keyfile or two. make a backup of your LUKS header and store it separate from the system. if the system doesnt accept the passphrase again, check if the luks header got changed. -- You received this message because you are subscribed 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20200505181509.GI987%40priv-mua.
Re: Solved: [qubes-users] external CD writer
On Mon, May 04, 2020 at 11:21:18PM +0200, Olaf Klinke wrote: > Where in the documentation is that stated? The manpage of qvm-device > does not mention this. The only hint is that all examples of qvm-usb in > the documentation show sys-usb as backend. for example in the documentation about usb devices: https://www.qubes-os.org/doc/usb-devices/ "Note: you cannot pass through devices from dom0 (in other words: a USB qube is required)." > 3. Putting the USB keyboard in a qube can and has locked users out of > their systems. forgetting their luks passphrase and careless use of fdisk also can and has locked people out of their systems. doesnt mean we remove disk encryption or all tools that can write to a disk in the wrong place. disabling autostart for the usbvm that has your keyboard is a pretty solid way to avoid locking yourself out hard. and shooting your own foot with it every now and then tends to be educational, just like remote administration of firewalls. :D > 4. If possible, keep the input devices (and only those) attached to > dom0 while attaching all others to sys-usb. i would put _all_ usb controllers into usbvms, even the one(s) used for privileged devices. you still need to make sure that the kbd one is attached to dom0 during boot though. > Luckily I seem to have two USB controllers for my peripheral USB ports, > so I can easily separate input- from other USB-devices. Is (4) i recommend you check if this is actualy the case. there are some _really_ weird USB setups where it looks like different controllers, but it is really just multiple pci devices on the same physical controller. and usb devices plugged into the same usb port end up on one or the other "controller" depending on speed negotiated. my check would be to configure different usbvms for each controller, then plug around some devices between physical ports and see in which vm they end up, and keep notes on that. > possible/recommended? The documentation shows how to hide _all_ USB > controllers from dom0, so I assume one can also choose to hide _some_. https://github.com/QubesOS/qubes-core-admin-linux/blob/master/dracut/modules.d/90qubes-pciback/qubes-pciback.sh rd.qubes.hide_pci=01:23.3,05:67.8 google is hard? perhaps you should consult a data scientist or so? :P -- You received this message because you are subscribed 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20200504221655.GH987%40priv-mua.
Re: [qubes-users] Removing Template VMs?
On Mon, May 04, 2020 at 12:28:27PM -0700, viktor.ransm...@gmail.com wrote: > If I'd like to remove any old & **unused** Template VMs (e.g. Debian 9, > Fedora 29, etc.) all I have to do is to start the Qubes Manager, select the > template I'd like to remove - and - select 'Delete qube' ... this should not work for templates that were installed by rpm. you will have to use "rpm -e qubes-template-fedora-23" (or similar). this will also require you clean up anything depending on these templates first, like switching all VMs using them to something else, removing related dvm templates ... i recommend to keep your one-generation-outdated mainline-template around (even if it is EOL) if you can spare the diskspace. if you manage to wreck your new mainline template some way, it is easier to recover from that with an outdated than with no template. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20200504202508.GG987%40priv-mua.
Re: Antw: [EXT] Re: [qubes-users] Contradictory measures of disk space in a VM
On Mon, May 04, 2020 at 09:12:59PM +0200, Ulrich Windl wrote: > Is it possible to set a flag that makes fsck do a full filesystem > check on the next boot? > Havent found one for ext3... use tune2fs to set the current-mountcount (-C) to something bigger than the max-mountcount (check with -l, adjust with -c). reading the tune2fs documentation is recommended before use. > If the fs tools don't have that feature (yet), maybe it could be build > into initrd (some flag just causes a full fsck to be performed before > the fileystems are mounted (read-write). they do. how to trigger it depends on your initrd. reading the distro specific initrd documentation is recommended. -- You received this message because you are subscribed 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20200504201917.GF987%40priv-mua.
Re: [qubes-users] To the Qubes developers (German translation) - An die Qubes Entwickler (Übersetzung auf Deutsch)
On Sat, May 02, 2020 at 11:11:34PM -0700, Caroline Villinger wrote: > Would you be willing to give us all the files we need for the translation? https://github.com/QubesOS/ > If you agree, it would be very nice if you could give us an answer. the qubes-translation mailinglist might be a better place for this kind of topic. -- You received this message because you are subscribed 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20200503073626.GD987%40priv-mua.
Re: Solved: [qubes-users] external CD writer
On Sat, May 02, 2020 at 11:01:06PM +0200, Olaf Klinke wrote: > I presume dom0 did not recognize the drive as a USB device and hence > refuses to attach as such? `qvm-usb` yields the empty list. oh right, you just came full circle: attaching USB devices is not going to work without a usbVM. > The only remaining question is: Did I buy a shitty drive or will any > external CD writer behave this way? no, you just dont have your qubes setup properly. once you have a sys-usb ... qvm-usb should work just fine. for how to do that: see other thread. :P -- You received this message because you are subscribed 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20200502212519.GA987%40priv-mua.
Re: [qubes-users] Re: Fedora 30 approaching EOL, Fedora 31 TemplateVM available, Fedora 32 TemplateVM in testing
> was really unrisky and straightforward scripting, why did the Qubes OS > installer not offer this choice, let alone just do it? a mix of historic reasons and expecting users to do their homework. without a sys-usb, you can not really use usb devices with qubes. and _trying_ to use them will connect them to dom0, which is a decent sized can of worms. as in: usb keyboard is bad. no sys-usb is worse. and yes, it might be time to change what the installer does when seeing a usb keyboard. -- You received this message because you are subscribed 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20200502093439.GG990%40priv-mua.
Re: [qubes-users] Dividing Qubes Into Separate Networks (FAILED)
On Sat, May 02, 2020 at 03:14:42AM +, 'Zsolt Bicskey' via qubes-users wrote: > > Set the VLAN correctly? > yes, as I said if I connect a Windows latptop it works right away > > Set all parameters necessary to satisfy any port security on the switch? > Yes, same answer as above actualy, those are not "answers" at all. there is nothing in this description confirming you know how to configure a network interface under linux. since you confirmed the second port is working in general, this is unlikely to be a qubes problem. may be a whatever-your-netvm-distro-is problem. or more likely, a configuration problem. try booting whatever the distro in your netvm is off a USB stick or dvd (== without xen involved), and get the right network interface to work on the right port with that. then copy over the interface configuration to your netvm. -- You received this message because you are subscribed 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20200502080552.GE990%40priv-mua.
Re: [qubes-users] external CD writer
On Sat, May 02, 2020 at 01:23:53AM +0200, Olaf Klinke wrote: > just lacking the knowledge how different writing to a CD is from > reading from CD, on the hardware level. Is there more to burning a CD > than a single block special device? try attaching it as a USB-device instead of a block device. meaning "qvm-usb instead of qvm-block". or "lower part instead of upper part of the device widget". -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20200502074454.GD990%40priv-mua.
Re: [qubes-users] Re: Fedora 30 approaching EOL, Fedora 31 TemplateVM available, Fedora 32 TemplateVM in testing
On Fri, May 01, 2020 at 04:33:55PM -0500, Sven Semmler wrote: > So make sure to remove those from your grub/EFI config before rebooting! yes, that would be what the second qubesctl call does. there should be no need for manual config editing during this. > The USB qube will work anyway but if it's not running dom0 will have > USB. If you skip this step you won't be able to control your computer > after reboot. only during / right after reboot. once sys-usb tried to start, the controller will not return to dom0 until next reboot (or you do some ritual dancing that requires a kbd...) thats what my "disable sys-usb autostart if you rely on a USB kbd" recommendation is about. so you actualy have a kbd to fix things if you manage to wreck your sys-usb ... config, template, filesystem damage, so many ways ... -- You received this message because you are subscribed 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20200501214252.GC990%40priv-mua.
Re: [qubes-users] Re: Fedora 30 approaching EOL, Fedora 31 TemplateVM available, Fedora 32 TemplateVM in testing
On Fri, May 01, 2020 at 10:33:08PM +0200, Olaf Klinke wrote: > > > and my keyboard / mouse uses sys-usb. I need to have this appVM > > > running to use the peripheral obviously. But, since the appVM > > > running, I can't update the templateVM? if you really _need_ sys-usb (== only keyboard is USB), i would recommend disabling sys-usb autostart anyways. then replacing the template can be done on next reboot before starting sys-usb. or do that scripted shutdown/prefs/start dance. but that can be a bit tricky for various reasons. and i would recommend to try it with autostart disabled anyways, just in case. > I do not have a sys-usb, since I installed Qubes OS while using a USB > keyboard. Which domain are my USB devices attached to? The Qubes you should configure a sys-usb anyways. https://www.qubes-os.org/doc/usb-qubes/ just two qubesctl calls. (plus one qvm-prefs to disable autostart) > documentation is not explicit about that, it only says removing the > sys-usb qube will attach the devices directly to dom0. Is that the way > Qubes configures itself when installing without PS/2 keyboard? yes, your usb will be directly attached to dom0 currently. and that is not a recommended configuration. otoh, it means you dont have to worry about replacing the template. ;) some hints regarding the whole scripted replacement plan though... > qvm-stop --wait $QUBE_WITH_USB ... there is no qvm-stop. > sleep 10 10sec is _very_ optimistic for a full sys-usb boot and settling the USB situation. i would recommend something like 120sec. -- You received this message because you are subscribed 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20200501210256.GB990%40priv-mua.
Re: [qubes-users] How to mount App-VMs from Outside qubes
On Fri, May 01, 2020 at 06:18:10PM +0200, Dieter wrote: > I tried accessing data on an old qubes (3.2) drive that doesnt boot > However after decryption I only see the lvms "qubes_dom0-swap" and > "qubes_dom0-root" > reading from dom0 is no problem but how can I access the other VMs? mount the dom0 root volume check for .img files under /var/lib/qubes/ these are loop-mountable volumes you can dd them to blockdevices, or use as-is. private volumes should be usable on qubes 4.0 unless they contain fancy configuration. if you want to copy them around, beware of them being sparse files. (== unless you use some copy tooling that can handle sparse files, they will take a lot more space after copying than before) -- You received this message because you are subscribed 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20200501165357.GA990%40priv-mua.
Re: [qubes-users] Qubes Certified Desktop
On Fri, May 01, 2020 at 11:19:45AM +0530, Anil wrote: > system perhaps? Or better, some older version of NUC or other mini PC? NUCs will not allow you to do anything weird with the firmware, so no me_cleaner or coreboot or so. they work reasonably well with qubes. > I know Purism is selling a mini PC, but other than that. asrock deskmini works well for me. didnt bother with coreboot, but me_cleaner works like a charm. asrock does not seem to have firmware checksum/signature checks, and has a good recovery path, so no external hardware/flasher/soldering needed to apply me_cleaner, including for unbricking. another option would be chromeboxes. with official coreboot and linux support. but rather limited in terms of hardware choices. -- You received this message because you are subscribed 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20200501095613.GA54173%40priv-mua.
Re: [qubes-users] Contradictory measures of disk space in a VM
On Wed, Apr 29, 2020 at 03:10:48PM -0300, Franz wrote: > I tried fsck on dom0, but got the enclosed terror screen. it would have helped if you had tried to fsck the right filesystem: fsck /dev/qubes_dom0/vm-per-dec-private and if it is asking for repair a bazillion times, perhaps with -y -f (and i would keep running it with "-y -f" until at least one run is completely clean...) "how to repair a filesystem" is basic system management. the only mildly qubes-specific part about it is that the fsck needs to be done while the filesystem is not mounted, which in most cases means the vm is not running. > and for the future I'll avoid to chenge size of a running VM. I understand > it can theoretically be done, but it does not work for me. On the other > hand, it works if the VM is not running. you will run into exactly the same problems if you try to resize a damaged filesystem while the vm is not running. actualy for some constellations of resize and system, an offline resize is _more_ likely to go wrong. (it will do the resize on next vm startup, and if the resize takes longer than the vm-startup-timeout... ouch) -- You received this message because you are subscribed 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20200429182711.GL935%40priv-mua.
Re: [qubes-users] Contradictory measures of disk space in a VM
On Wed, Apr 29, 2020 at 08:11:37AM -0300, Franz wrote: > Did it with Fedora 30, but with exactly the same result > But checking other VMs I am getting the same error on some of them :(( > So this is a widespread problem. did you try to google your problem? because at this point it is starting to look less of a qubes problem, and more like generic filesystem damage. fsck+repair the volume, then resize it. consult the documentation of your favorite distro template on how to do this inside the vm. you may have to connect to the vm through "xl console" in dom0. or spawn a fsck-vm, and temporarily attach the volumes to that. https://www.qubes-os.org/doc/mount-lvm-image/ or just fsck+resize from dom0 if you consider the risk of something exploiting e2fstools through this acceptable. > May it be that this is caused by running Qubes manager / vm settings/ > increase private size when the VM is running? Sometimes I get an error on > that. It may be that this creates a problem that cannot be removed. no, online resize is completely normal and supported. -- You received this message because you are subscribed 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20200429124205.GK935%40priv-mua.
Re: [qubes-users] Contradictory measures of disk space in a VM
On Tue, Apr 28, 2020 at 03:26:44PM -0300, Franz wrote: > > a) check what the actual size is: > > dom0$ sudo lvs -a | grep yourvmname > > => whats the size of the yourvm-private volume? > did it, but there is no unit, so number are difficult to interpreter, > snapshot enclosed not sure what that means. the "g" in "18.09g" is short for "giga". and the unit is most likely "bytes". so the blockdevice is actualy the right size. > b1) if it is 18GB already, check that it is actualy 18GB inside the vm: > > yourvm$ grep xvdb /proc/partitions > same, snapshot enclosed the size is again 18.x GB. > > c1) if it is 18GB inside the VM too, you are just missing the fs resize: > > yourvm$ sudo resize2fs /dev/xvdb > Permission denied, see snapshot no idea what that means. but you are using an ancient version of resize2fs there. please try with a template/distro that is not shipping outdated versions. a fedora 30 or 31 should work. just starting the appvm once with a working template should be enough. (you could also resize the FS from dom0, but that has security implications i dont want to explain) but, yes, if your appvm has no working resize2fs, resizing the volumes is not going to work too well and could result in the symptoms you are describing. -- You received this message because you are subscribed 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20200428193750.GJ935%40priv-mua.
Re: [qubes-users] QUBES Friendly Version
and just to shred that last bit of misinformation the other two responses skipped ... On Tue, Apr 28, 2020 at 12:44:38AM +, '[NOTIFICATION]' via qubes-users wrote: > It would be great if you opened up QUBES for worldwide editing and > audit and development. https://github.com/QubesOS/ just go ahead and edit/audit/develop as much as you want... -- You received this message because you are subscribed 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20200428091505.GI935%40priv-mua.
Re: [qubes-users] Contradictory measures of disk space in a VM
On Mon, Apr 27, 2020 at 09:06:41PM -0300, Franz wrote: > So, it seems that Qubes Manager, Nautilus and df are consistent, telling > that available space is almost 5GB totally used. > > But Qubes VM settings with Private Storage Max Size of 18524 MB is totally a) check what the actual size is: dom0$ sudo lvs -a | grep yourvmname => whats the size of the yourvm-private volume? b1) if it is 18GB already, check that it is actualy 18GB inside the vm: yourvm$ grep xvdb /proc/partitions c1) if it is 18GB inside the VM too, you are just missing the fs resize: yourvm$ sudo resize2fs /dev/xvdb d1) check with df that the full size is now avail: yourvm$ df -h /rw b2) if the device in dom0 is _not_ the right size, or you dont want to bother with b1/c1/d1, just give it a bump with qvm tools again: dom0$ qvm-volume resize yourvm:private 19GiB c2) check with lvs/df that it is now the right size. (see above) this should all have happened automaticly on resize, but there is a bunch of ways/reasons why it might have not happened. for example if you resized the vm while running (which is supported) but then had a hard full-system crash/stop/reboot before shutting down the vm or the vm was running an image without resize2fs at the time of resize... -- You received this message because you are subscribed 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20200428090248.GH935%40priv-mua.
Re: [qubes-users] Boot qubes-os from net?
On Mon, Apr 27, 2020 at 11:34:30AM +0800, Sandy Harris wrote: > Can the OS be booted from the network? short answer: no. > Can I avoid the problem by booting Qubes-OS from the network? what problem? "i dont trust the vendor bios"? how would running an even more complex untrusted bios solve the problem of an untrusted bios? -- You received this message because you are subscribed 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20200427081507.GG935%40priv-mua.
Re: [qubes-users] TPM settings for Qubes OS
On Sun, Apr 26, 2020 at 01:16:42PM -0700, Harold Smith wrote: > TPM and TXT were listed as required for AEM in the recommended section, so > i'll disable TXT and TPM, I have vt-x with ept and vt-d and I;ll try again. you can also just keep them enabled. you can use the TPM for whatever you might want to use it for, assuming it is supported by linux. and TXT shouldnt do anything unless you install the magic binary intel modules in your /boot. basicly both are "dont worry about them unless you have a use for them". -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20200426202021.GF935%40priv-mua.
Re: [qubes-users] qubes AppVM nameservers
On Sun, Apr 26, 2020 at 09:17:10PM +0200, Olaf Klinke wrote: > it seems that some iptables rules are set on VM boot that redirect port > 53 requests, but I can't get iptables inside the AppVM to divulge these those rules should exist in your external netvm (sys-net), and point to the "real" nameservers as received by dhcp (or configured via netmanager). that way the individual appvms do not need to know about that part of external configuration. i have seen the rules get "lost" (actualy: point to useless IPs) on some kinds of external reconfiguration events. (like hard restarting the netvm of a vpn-vm) -- You received this message because you are subscribed 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20200426201555.GE935%40priv-mua.
Re: [qubes-users] TPM settings for Qubes OS
On Sat, Apr 25, 2020 at 05:09:46PM -0700, Harold Smith wrote: > Hello, I'm getting ready to Intall Qubes onto a machine, I can't find any > information about TPM settings, apart from that TPM is required. where did you get that impression? qubes doesnt use a TPM, much less require one. > and "intel virtualization technology", which I believe are VT-x and VT-d enable vt-x (with ept) and vt-d, those are actualy used by qubes. SLAT (vt-x with ept) is required, IOMMU (vt-d) is strongly recommended. > option for "Trusted Execution", any information about what is necessary to TXT and (old) TPM can be used by a very optional legacy boot addon named "anti evil maid". safely using AEM requires a somewhat detailed technical understanding of how it works, so you will have to do a day or two of reading if you want to try it. but it is also completely optional and can be en/disabled on an existing qubes install. if you care about boot security but dont have hardware that is supported by AEM, you could also try something like HEADS (which has its own very detailed hardware requirements) or a uefi-secureboot-linuxboot hybrid. -- You received this message because you are subscribed 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20200426080515.GC935%40priv-mua.
Re: [qubes-users] Qubes-device-applet
On Sat, Apr 25, 2020 at 06:45:11PM +0200, 'Max Andersen' via qubes-users wrote: > ert > > Hi there, > > After upgrades to latest kernel and several other updates, enabling > sound, I still need support for t your message looks incomplete/corrupted. but the most likely answer to your unasked question can be found here: https://www.qubes-os.org/doc/usb-qubes/ and the tl;dr is: sudo qubesctl state.sls qvm.sys-usb sudo qubesctl state.sls qvm.usb-keyboard with this less-official-but-strongly-recommended-by-me addon: qvm-prefs sys-usb autostart False -- You received this message because you are subscribed 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20200425171023.GB935%40priv-mua.
Re: [qubes-users] Pulseaudio update error - fedora-31
On Wed, Apr 22, 2020 at 11:29:30PM +0200, Frédéric Pierret wrote: whats with the top-posting, eh? :P > From a brief look, it's due to newer Fedora pulseaudio and our Qubes > package requires older one. I'll try to fix that soon. actualy it seems to have been fixed some days ago and is now in testing repo. > > I remember some time ago we had issues with pulseaudio on earlier > > templates, and I believe a reinstall of pakages fixed the issue. I > > can't seem to get myself out of trouble with this one on fedora-31. try ... $ sudo dnf --enablerepo=qubes-vm-r4.0-current-testing update pulseaudio-qubes ... or wait some more days for the pkgs to move on to stable repo. -- You received this message because you are subscribed 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20200422213600.GA935%40priv-mua.
Re: [qubes-users] Re: NTP and/or clock issue
On Mon, Apr 20, 2020 at 01:12:20AM -0700, l319...@gmail.com wrote: > I have tried what Matthew did and you pointed to but I still have dom0 time > an hour behing from what it supposed to be. Weird as both dom0 timedatectl > and sys-net vm how same timezone a) run "qubes-prefs clockvm" in dom0. whats the returned vm name? b) in that clockvm, run "timedatectl". are local and universal time correct? does the clock show as synchronized and ntp active? -- You received this message because you are subscribed 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20200420082739.GD1020%40priv-mua.
Re: [qubes-users] Intel Management Engine and RNG
On Fri, Apr 17, 2020 at 02:53:01PM -0700, Catacombs wrote: > I would have thought someone could suggest a more trustworthy RNG. there is no real problem with using the intel RNG. if it is as part of a proper software RNG setup. (just dont use anything handpatched by debian devs... *coughs*) > One of original means of trustworthy communications was to use two > different computers. > One was air gapped and used to write encrypted email. And later to > open and decrypt email from the online computer. how do you transfer data to/from the "secure" machine? how do you make sure the airgapped machine has enough entropy? bottomless rabbitholes full of snakes. > Which brings me to how to find a more trustworthy RNG if you dont trust the RNG, why would you trust the CPU? use 3+ different machines. like one intel, one amd, one raspi. or mix something really retro / exotic in. or build your own hardware rng from a bunch of diodes, opamps, and some leds for display. or based on a radiation counter. the more, the merrier. use each of these machines to generate a transport-grade entropy pad. print these, or write them down in case of sources that dont have printer support. i recommend hex. the quality of each individual transport pad is not critical. they just need to be unrelated to each other. exchange the transport grade pads with your communications partners, using a different path of transmission for each of the pads. or different couriers. *wiggles fronds* use pen+paper xor to manually turn the transport-pads into usage-pads and to en/decrypt transmissions. using hex notation and xor tables helps a lot with this. make sure to never ever reuse pad sequences. this way you dont have to trust the CPU(s) either. and it encourages succinct communications. -- You received this message because you are subscribed 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20200417222802.GI8973%40priv-mua.
Re: [qubes-users] Intel Management Engine and RNG
On Fri, Apr 17, 2020 at 02:06:19AM -0700, Catacombs wrote: > It is my understanding that “the “Number Generator” is on the MOBO. > Could the “Intel Management Engine” be changed to alter the RNG > to create weakened Encryption? yes. > Could the IME be altered to load malware to steal Passwords and then > to send them somewhere. yes. also: nothing new there. if your cpu is actively working against you, game over. -- You received this message because you are subscribed 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20200417092614.GH8973%40priv-mua.
Re: [qubes-users] Increase the size of disk image and root file system
On Wed, Mar 25, 2020 at 04:21:29PM +0100, GD rub wrote: > Device BootStart End Sectors Size Id Type > /dev/xvda1 *2048 29360127 29358080 14G 83 Linux > /dev/xvda2 18946048 20969471 2023424 988M 82 Linux swap / Solaris urgh! be super careful there. your xvda2 is currently overlapping / in the middle of your xvda1! that means your rootfs is currently corrupted in an _interesting_ way. if you have snapshots left for the vm from before the resize, consider keeping/reverting! (check with qvm-volume and/or lvs) if not ... i recommend deleting xvda2 (and moving swap to xvdc), then running a full fsck on xvda1 from outside the vm, or flagging it for fsck and rebooting. -- You received this message because you are subscribed 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20200325154305.GF8973%40priv-mua.
Re: [qubes-users] Increase the size of disk image and root file system
On Wed, Mar 25, 2020 at 03:12:04PM +0100, GD rub wrote: > You can't do that on the root filesystem. resize2fs is permissible only if > the partition is unmounted. actualy, no, resize2fs works just fine on a mounted filesystem. > > > Device BootStart End Sectors Size Id Type > > > /dev/xvda1 2048 18946047 18944000 *9G* 83 Linux > > > /dev/xvda2 18946048 20969471 2023424 988M 82 Linux swap / Solaris but in this case, you need to repartition first, and that is going to be a problem while things are mounted. and you will have to move the swap out of the way for resizing the root partition too... i would recommend doing the resizing from a different appVM (or dom0). -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20200325142207.GE8973%40priv-mua.
Re: [qubes-users] Associate office files to win7 VM and prevent qvm-open-in-vm pop-up
On Mon, Mar 23, 2020 at 05:48:29AM -0700, peebl...@gmail.com wrote: > asking me in which VM i want to open the file.. So it seems the command > line parameter for VM is not taken into account.. it probably is, but you need to authorize it anyways: security. > How can I fix this? https://www.qubes-os.org/doc/rpc-policy/ -- You received this message because you are subscribed 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20200323152057.GD8973%40priv-mua.
Re: [qubes-users] Re: Fedora-31 template
On Sun, Mar 22, 2020 at 05:07:44AM -0700, max via qubes-users wrote: > [max@dom0 ~]$ sudo qubes-dom0-update > --enablerepo=qubes-dom0-current-testing qubes-template-fedora-31 wrong repo. try with --enablerepo=qubes-templates-itl-testing -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20200322121354.GC8973%40priv-mua.
Re: [qubes-users] How can I recover my Qube'sVM if I cannot boot anymore ?
On Sun, Mar 22, 2020 at 11:57:38AM +0100, haaber wrote: > > Assuming you didn't make backups before the crash: You need to have a > > running Qubes system to backup VMs the normal way. > Does that mean Chris, that in case of a disaster, there is no way to > backup your data "by hand" (booting a live linux, opening the luks ..) > because of a "thin pool" mess? That sounds in first hand like a strong > argument against the use of thin pools! As you know a lot about thin > pools, could you please comment on that, Chris? thx, Bernhard thin pools are plain linux tech, nothing qubes specific. and you can back them up in whatever way you want, from whatever distro/system you want. or not back them up at all, and simply attach the disk to some other system. it is not trivial to use the _qubes_ backup tooling outside of a qubes system. but besides that, they are just blockdevices with filesystems inside. -- You received this message because you are subscribed 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/2020032231.GB8973%40priv-mua.
Re: [qubes-users] Compatibility
On Fri, Mar 20, 2020 at 11:07:55PM +, 'jrsrrs33' via qubes-users wrote: > to understandif my computer is compatible or not and in this case, > what should I install? qubes 3.2 or qubes 4.0.3? do not use qubes 3.x ... it has been deprecated for a long time now. please do use qubes 4.0.3 ... and if you can not find options in your bios to make vt-d work, use the somewhat documented workarounds. (== switch sys-net and sys-usb to virt_mode pv). while that is not an ideal configuration, it is way closer to recommended than installing qubes3. :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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20200321101614.GZ8973%40priv-mua.
Re: [qubes-users] Set Battery thresholds x230
On Wed, Mar 18, 2020 at 11:56:31AM -0300, Franz wrote: > When a laptop is always connected to power, e very good behavior to > strongly prolong battery life is to avoid charging it to 100% and limiting > it to lower threshold, perhaps 80%. i am using a (perl) script for doing this on my qubes chromebooks. trivial if you have ways to a) get the current battery level and b) control the charger (charge/idle/discharge). > The Fedora command is the following: > dnf install kernel-devel akmod-acpi_call mixing random custom kernel modules with a qubes kernel is unlikely to work. at all. even if you figure out how to install the pkgs. depending on whats in these pkgs (does it have a Kconfig and can be built out of tree?) and what parts of it you actualy need rolling your own kernel-latest pkg may work. and even if you have a working kernel+module combo it simply may not work under xen. (depends on what kind of interfaces it is using) > Is there a way to get this working without compromising security? depends on what you mean by "security" there. did you review the code already? -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20200318160811.GY8973%40priv-mua.
Re: [qubes-users] Installing templates.
On Wed, Mar 11, 2020 at 10:46:12AM -0700, redpoll...@gmail.com wrote: > I've downloaded some ubuntu templates with the .rpm extension. I have been > told by someone that I need to put the rpm file into dom0 and then install > via cli with dnf etc. this means you are giving the person who created those rpms or anyone who managed to compromise their build process or storage/distro chain full root access in your dom0 == full control over the whole system. "not recommended" -- You received this message because you are subscribed 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20200311175358.GX8973%40priv-mua.
Re: [qubes-users] Is it possible to get an app like WinAuth for Linux or what do you use for 2 step verification ?
On Sat, Mar 07, 2020 at 03:08:13PM -0800, A wrote: > Is it possible to get an app like WinAuth for Linux or what do you use > for 2 step verification ? https://www.qubes-os.org/doc/multifactor-authentication/ -- You received this message because you are subscribed 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20200307235845.GV8973%40priv-mua.
Re: [qubes-users] Obtaining genuine Qubos installer
On Thu, Mar 05, 2020 at 01:21:47PM -0500, Chris Laprise wrote: > You can also qualify the model somewhat and say that an attacker cannot > successfully infect all of your (hopefully diverse) computers, so that makes the diversity bit is important. and if its mainly about validating a download, even the most outdated/underpowered device should work. > OTOH, you may have decided to discard the above threat model because of some > intent or capability known to you. In that case, I think the Qubes community http://blog.ptsecurity.com/2020/03/intelx86-root-of-trust-loss-of-trust.html > system vendor like Insurgo or NitroKey that sell re-flashed systems and uses > anti-interception measures (like tamper-evident packaging and signatures) in i trust a randomly-bought chromebook more than any overpriced device that has "we are so secure/paranoid we walk funny" as its main selling point. -- You received this message because you are subscribed 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20200305183721.GQ8973%40priv-mua.
Re: [qubes-users] HVM sound, webcam, microphone, resolution
On Thu, Mar 05, 2020 at 05:48:36PM +, 'Ian' via qubes-users wrote:
> I've just started using Qubes and I'm trying to ease transition from
> my current virtualbox based setup by just importing my virtualbox VMs
> as HVMs.
good strategy!
> 1. Resolution above 1920x1080 (the host is 2560x1440, but xrandr only
> sees up to 1920x1080.
> 2. Sound in the HVM. Is it possible to get sound working?
actualy all of this should work "out of the box"(*).
as in, if you try xrandr or some audio playback in a hvm domain
like sys-net or sys-usb, it should "just work".
> 3. Attaching a microphone (built-in) to the HVM
> 4. Attaching a USB webcam to the HVM
you need to attach the mic (device management), and some usb devices
may not work at all with linux usbip ("cable is bad" in dmesg).
> Are any of these possible? Thank you in advance for any help.
your problem is more likely to be lack of xen/qubes support in the
kernel (if you are booting an in-vm kernel) or userland.
try firing up a regular templated appvm instead, and attaching the
mint-image to that as a blockdevice. if you only need "user data"
from the old image, copy things around (or use symlinks).
if you need the "old system", try to chroot into it.
welcome to qubes and good luck.
--
You received this message because you are subscribed 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 view this discussion on the web visit
https://groups.google.com/d/msgid/qubes-users/20200305181106.GP8973%40priv-mua.
Re: [qubes-users] Obtaining genuine Qubos installer
On Thu, Mar 05, 2020 at 03:56:55PM +, Mark Fernandes wrote: > Well that's an idea. But still what if the software you are being 'fed' is > all tampered software, so that after replacing the computer, as soon as you > use software, you are compromised again? > Purchasing a new computer can also be expensive, and still in any case, you > might find that any software pre-installed on it may have already been > compromised. welcome to "supply chain security is hard". please have a seat next to that person posting here in the last days how he doesnt trust chips from china... the end result is still: as long as you dont have a computer you trust, the whole rest of this is pointless. if you have a computer you trust, verifying a signature is a lot more useful than variations of "i bought it in a shop while wearing a fake beard, so it is certainly legit". (which applies to the hardware too!) and the point of using different sources of info on the master key is that an attacker who wants to fool you has to intercept every single one of them. if he misses even one, the game is off. and getting the master key fingerprint from many different directions/sources seems a lot more realistic than doing the same for an iso image... and you dont have to trust any one of these sources, but if you add up enough of these untrusted sources, you can still trust the end result as long as your threat model doesnt include every single of the sources conspiring against you, or being compromised by the same attacker... > Eg. suppose you are a person like Edward Snowden, and that you are a > targeted individual. Then such intensive manipulation is perhaps entirely > plausible. i am reasonably sure you are not ed snowden. (if you are: sorry. i assumed ed snowden to know what a hash and signature are.) but here is another headache: (warning: nerd-sniping and messing-with-tinfoilhats ahead) you are of course right that checking hashsums or signatures isnt 100% safe. what if there are alien quantum computers involved. lets run numbers, the "basic math" kind: the qubes 4.0.3 iso is 38646317056 bits in size. the signature is against a 256 bit hash (over 1056 bits of intermediate hashes plus some metadata). so there are about 2**38646316800 different iso images of the same size that will match this signature. or 2**38646316000 to match the intermediate hashes so you wouldnt have to bother faking the sigfile. thats close enough to "infinitely many" for me to not actualy calculate it. (hint: thats several times the estimated number of atoms in the universe) wait. who said the evil iso has to be the same size?! no one. so, aeh, there are infinite amounts of infinite piles of iso images that all match this signature! but probably even edward snowden is ok with a reasonably sized signature. because else we might as well just toss this whole internet and computer thing out the window. (and do i double down now or wait for the likely next round to mention that the qubes master key might be considered compromised because the qubes team never planned for having a senior member leave the team... *coughs* ;) please dont get me wrong, critical thinking is good, but its also important to stay somewhat reasonable about your threat model, because once you get stuck worrying about class 4+ picotech perversions, you wont get much done anymore... -- You received this message because you are subscribed 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20200305172629.GO8973%40priv-mua.
Re: [qubes-users] Obtaining genuine Qubos installer
On Thu, Mar 05, 2020 at 03:30:26PM +, Mark Fernandes wrote: > So if your computer has been compromised, the methods you suggest may be if your computer has been compromised to the point where you dont trust it to verify a signature, you need a new computer to install qubes on. once you have a computer you trust enough to install qubes on, you can use it to verify the signature. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20200305154157.GN8973%40priv-mua.
Re: [qubes-users] Obtaining genuine Qubos installer
could you please try to at least spell the name right? this is giving my inner monk a headache... On Thu, Mar 05, 2020 at 02:40:18PM +, Mark Fernandes wrote: > The only thing relevant to this topic in the guide, appears to be the > information on verifying signatures (which is of course standard practice). ... > authentic copies of the Quebos software. I've hinted at some ideas as to > how to do this, in my starting post for this topic. actualy, not the impression i am getting. if you knew how to verify a signature and what that means, pretty much all the "ideas" you listed would be obviously useless. as in, to "verify the installer/iso", all you need is to verify the signature: https://www.qubes-os.org/security/verifying-signatures/ that reduces the actual problem to "how to get/verify the qubes master key", for which suggestions are on that page, and which in general is a lot easier than trying to verify some multi-GB monster. for a lot of additional confirmations of the master key, you can use a searchengine, with/without tor, from different ISPs, ask in different chats, look at presentation slides/videos -- You received this message because you are subscribed 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20200305145618.GM8973%40priv-mua.
Re: [qubes-users] Re: Tor not connecting over DSL
On Thu, Mar 05, 2020 at 04:54:45AM -0800, Rafael Reis wrote: > Could be and MTU issue. I had trouble with Qubes, VPNs, TOR and PPOE > connection due to it’s unusual MTU size (lower than 1500). Maybe the > experts could shed some light into how Qubes deals with MTU across VMs qubes? not at all. the whole setup? depends on what kind of network setup you are using. for example a "linux" netvm is a lot better at dealing with pmtu discovery than a "mirage" one. assuming you dont "customize" the firewall the wrong ways. blocking icmp is a pretty reliable way to break 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20200305130913.GL8973%40priv-mua.
Re: [qubes-users] Usb modem passthrough error how to fix?
On Tue, Mar 03, 2020 at 12:20:57PM -0800, Eva Star wrote: > collection ticket: > > https://github.com/QubesOS/qubes-issues/issues/3778 > Thanks! Yes, exactly this issue. Can I use passthrough mode if I will > connect external 2.0 usb hub to my current notebook usb port and then > passthrough from it? > / or maybe it will be possible to attach second usb hub as pci device to > other appvm? if you have more than one pci-level usb-controller, you can (try to) assign them to different VMs, sure. but connecting some usb-to-usb hub and trying to assign that wont 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20200303203900.GK8973%40priv-mua.
Re: [qubes-users] Usb modem passthrough error how to fix?
On Tue, Mar 03, 2020 at 09:43:56AM -0800, Eva Star wrote: > Get this error. Please, how to fix? Cable is fine. It work on non virtual > environment on other machine. > [ 64.124877] usb usb1-port1: Cannot enable. Maybe the USB cable is bad? this most likely means your device is not supported by the linux usbip driver, so it will not work with qvm-usb forwarding between VMs. you should still be able to use it in sys-usb, so you may have to use sys-usb as your netvm while using that modem. this problem applies to all USB devices that try to reset the USB device, for example after loading firmware. linux-5.5.6/drivers/net/wireless/ralink/rt2x00/rt2x00usb.c: usb_reset_device(usb_dev); collection ticket: https://github.com/QubesOS/qubes-issues/issues/3778 -- You received this message because you are subscribed 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20200303180945.GJ8973%40priv-mua.
Re: [qubes-users] Where to find the directory of a attached mobile phone ?
On Sat, Feb 29, 2020 at 08:02:25AM +0100, A E wrote: > When I execute "sudo mount /dev/xvdi /mnt" in the terminal of the VM, I get > this error: “mount: /dev/xvdi/mnt: can’t find in /etc/fstab. that error doesnt match the command. one of them must be incorrect. if the error is real, it indicates you didnt put a space between the device and the target path. this part is "basic linux usage" btw, very much not qubes specific. googling "how to mount a disk in linux" (or with the distro name you are using instead of linux) might help. check what xvd* device is actualy used by running "qvm-block" in dom0. or "cat /proc/partitions" or "ls -l /dev/xvd*" in the target vm. (hint: its not the xvda/b/c/d ones, those are the system "disks", user attached devices should be xvdi, xvdj...) > And I get this with both devices. what "both devices"? -- You received this message because you are subscribed 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 view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20200229103559.GI8973%40priv-mua.
Re: [qubes-users] Benefits of Sys-Firewall
On Fri, Feb 28, 2020 at 06:00:04PM -0600, Sven Semmler wrote: > You want your sys-firewall to be separate from sys-net for the same > reason: compartmentalization. as usual "depends on your threat model". if you are into outbound-firewalling of appvms, not doing so in the appvm makes a lot of sense for the reasons you stated. but you could do that in sys-net too, entirely without sys-firewall. unless your threat model involves the same (or cooperating) attackers compromising your sys-net from the outside that want to break out of your appvm... > I hope others will correct me if I got anything wrong. looks good to me. but i would like to add some off-default-config considerations/rambling. what if your attacker has some l2-ish network linux exploit? lets take something like CVE-2018-15688 as an example. ipv6 dhcp problem, in both systemd and networkmanager. afaik no one ever really evaluated the impact on a qubes system. because ipv6 is "disabled" in the default config. but what does that mean? "ipv6 disabled in qubes" means ipv6 is disabled _within_ qubes. as in, it is actualy enabled (by default) in sys-net in some ways, just not forwarding it on the qubes-internal network links. so worst case, an attacker can compromise your sys-net, then compromise your sys-firewall, then your appvm. all with the same exploit, just having to go hop-by-hop. one way to mitigate a scenario like that is to involve something that is _very_ much not linux. like qubes-mirage-firewall. or a bsd fw. which of course is a "threat model" and "subjective considerations" thing. because one side of it is ... it makes it much more unlikely for a single attacker to have a walkthrough with a single exploit. == it makes it less likely for an attacker to compromise the whole chain. otoh ... now there are two ip stacks involved, and the mirage one certainly got a lot less eyeballing than the linux one. == it makes it more likely for an attacker to compromise part of your chain. and there are "env" factors to consider too. sure, if you dont have the ram to run separate linux based firewall vms, go ahead and dump all of it (inkl sys-usb) into sys-net. or your HW doesnt have (usable) IOMMU and you run your sys-net/sys-usb pci-vms as "pv" instead of "hvm". your overall security posture will (probably) still be better than with a plain linux (or anything else) system, even though you take some shortcuts that are not default config or recommended. qubes provides a lot of different options there, with a reasonable default config, but (depending on your threat model) going beyond that can be quite reasonable too. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20200229004951.GH8973%40priv-mua.
Re: [qubes-users] Where to find the directory of a attached mobile phone ?
On Fri, Feb 28, 2020 at 10:02:42PM +0100, A E wrote: > Thank you for your very quick response. and thanks for a good/comprehensive reply from you. > The mobile phone is listed as two devices: > 1) sys-usb: sda - Disk () > 2) sys-usb: 1-3 - ..._Mass_Storage_Device_... this is normal. go with the first one. thats the actual block device as used with qvm-block (or upper half of the gui) > In the file manager of the attached VM under /proc/partitions, I find a > file that only displays partitions with xvd... I don’t know if the attached > partitions is some of these. qvm-block will tell you the name if the device is attached. in general it will be xvdi for the first blockdevice. > Any ideas on how to proceed... ? my guess is just the "mounting it" part is missing. try "sudo mount /dev/xvdi /mnt" in the vm. then check the contents of /mnt. not you also should "sudo unmount /mnt" in the vm and detach the device though qvm-block (or gui) before unplugging the phone! there are probably more clicky or even automatic ways to do this, but i am not familiar with that kind of thing. -- You received this message because you are subscribed to the Google Groups "qubes-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to qubes-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/qubes-users/20200228213959.GG8973%40priv-mua.
