[qubes-users] Re: [qubes-devel] Re: Request for feedback: 4.9 Kernel

[Ryan Tate]

On Thursday, June 1, 2017 at 10:00:09 AM UTC-4, Pablo Di Noto wrote:
> > >> 4) General feedback on the 4.9 kernel.
> > >
> > > Oh, yeah... I have started experiencing quite annoying internet 
> > > connectivity issues, very, very difficulty to troubleshot. Symptoms are:
> > >
> > > - Web browsing fails with ERR_EMPTY_RESPONSE, pages load partially never 
> > > reaching some of the content.
> > > ...((removed for brevity))
> > > It seems pretty repeatable, and would love to provide debugging info, 
> > > although I do not know where to look for.
> > 
> > I, too, encountered this issue and was unable to find
> > the cause. Had to revert to 4.4.67-12 kernel. :(
> 
> Oh, well. I am not crazy then. :)
> Maybe being a generic bug will make it worth debugging.

I had these issues as well. Oddly, some domains would load perfectly in an 
AppVM, but then others that should be available (e.g. Google.com) would 
suddenly break, then come back 5 minutes later. Those same domains would load 
fine in curl on the netvm. This also hit non HTTP apps like email, messaging.

I was not able to revert my kernel as my wireless adapter fails under the old 
kernel. However, I was able to fix by installing the fedora 25 template and 
upgrading the stack of VMs involved (sys-net > sys-firewall > appvm) all to the 
fedora-25 template. This seems to have eliminated the constant network stalls.

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

Re: [qubes-users] Any release schedule for Qubes 4.0

[Ryan Tate]

> On Jun 20, 2017, at 11:27 AM, Reg Tiangha  wrote:
> 
> On 2017-06-20 9:06 AM, Swâmi Petaramesh wrote:
>> Hi there,
>> 
>> I've been googling here and there, and couldn't find any release
>> schedule for the upcoming qubes 4.0...
> 
> They haven't released one yet and it will be done when it's done.
> 
> Personally, I'd rather have them leave it in the oven until it's fully
> baked, rather than to rush it out and then patch heavily later.

Without disagreeing with any of this, I’ll just note that on April 30 the 
(excellent) community manager Andrew David Wong indicated "we expect to publish 
the first Qubes 4.0 release
candidate (4.0-rc1) in the next ~1-2 months.” 
https://groups.google.com/d/msg/qubes-users/kO2JqLqIQec/k1SKPO11CQAJ

Take that for what it’s worth.


-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/622D4B1E-7B37-4CE9-A1CD-98A24E059DA6%40ryantate.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Message signed with OpenPGP using GPGMail

[qubes-users] Containing Twitter sessions

[Ryan Tate]

I am perplexed by the challenge of containing Twitter use in Qubes.

With Twitter, you must be logged in to effectively read or write.

On the read side, it is a wildly promiscuous experience exposing the user to 
various untrusted sites. Indeed a key goal of using Twitter is to discover new 
sites and media.

On the write side, it is very sensitive, containing private messages, the 
ability to post public messages with significant personal reputational risks, 
and even to do lightweight out-of-band authentication for other channels.

If I had to pick from the default VMs, I would probably put Twitter in 
“untrusted” due to the risks on the read side, even though the account itself 
is sensitive and ideally you would not put such write capabilities in a "wild 
west” environment like “untrusted." Perhaps better is to just make a “twitter” 
vm to keep the damage of any compromise contained to the Twitter account 
itself. Most ideal, in the future, would be to combine this last approach with 
a Qubes browser add-on and force each non-twitter link to open in another VM, 
either disposable or the “untrusted”.

(Has anyone figured out a better approach?)

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/2ADC32CB-6F66-4E2A-8C8F-684F0B356814%40ryantate.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [qubes-users] X.org failure preventing boot, Intel graphics

[Ryan Tate]

> On May 25, 2017, at 12:48 AM, ryant...@ryantate.com wrote:
> 
> Maybe my Intel graphics are too new for this X?

So I made a fedora 23 live usb and was able to boot into fine on the same 
system. No X issues, full GUI.

So I am wondering if this is really about Xorg, since presumably this has the 
same X server as Qubes 3.2 dom0, which is also fedora 23.

Could this somehow be specific to Xen or Qubes?

I plan to continue to invest time in this, so if anyone has an idea what my 
next investigative step should be, do let me know. Thanks for reading….

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


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [qubes-users] X.org failure preventing boot, Intel graphics

[Ryan Tate]

> On May 25, 2017, at 10:25 PM, Ryan Tate <ryant...@ryantate.com> wrote:
> 
> So I made a fedora 23 live usb and was able to boot into fine on the same 
> system. No X issues, full GUI.
> 

Ah, it turns out I was able to boot when using same fedora but different 
(older) kernel (4.2.3).

Newer kernels also seem to work. My testing:

qubes3.2 kernel 4.4.14-11 graphics-no wifi-untested (fedora23)
fedora23 kernel 4.2.3-300 graphics-yes wifi-no
fedora24 kernel 4.5.5-300 graphics-yes wifi-no
fedora25 kernel 4.8.6-300 graphics-yes wifi-yes

Any clue how to get Qubes dom0 booting into a different kernel, without being 
able to actually boot into dom0 (just the boot welcome screen)?

I don’t think I’ll be able to get the NIC working given the above results but I 
could copy a different kernel onto /boot from removable media (certainly from 
rescue mode in CD). Then I imagine I’d need to change not just grub settings 
but also Xen settings somewhere? Bit out of my depth.

Thanks for any pointers.

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


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [qubes-users] X.org failure preventing boot, Intel graphics

[Ryan Tate]

On May 25, 2017, at 11:19 PM, Ryan Tate <ryant...@ryantate.com> wrote:
> 
> Ah, it turns out I was able to boot when using same fedora but different 
> (older) kernel (4.2.3).

To be clear, I still can't boot qubes, I'm just saying it seems to have more to 
do with the kernel than distro.  Just booting direct to a fedora usb stick., 
4.2.3 works as does 4.5.5 -- so I'm guessing it is something to do with the 
qubes 4.4.14 kernel. Grateful for any tips on how to swap in another kernel 
without being able to boot dom0. 

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/9397C8FC-00D0-4BBC-999F-4D8E226BC4D3%40ryantate.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] X.org failure preventing boot, Intel graphics

[Ryan Tate]

> On Jun 10, 2017, at 2:39 AM, Vít Šesták 
>  wrote:
> 
> Good to hear it helps. Fronm “without being able to actually boot into 
> Qubes?”, I wrongly assumed you are unable to switch to a different tty. 

This was actually a correct assumption, due to my ignorance :-) I did not know 
the "trick" of stopping boot and getting a login prompt with Ctrl-Alt-Whatever 
until after I was researching your response on the web and I stumbled on 
something on StackOverflow. So all the confusion is my fault. Thanks again.


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

Re: [qubes-users] X.org failure preventing boot, Intel graphics

[Ryan Tate]

> On May 27, 2017, at 3:35 AM, Vít Šesták 
>  wrote:
> 
> Are you able to connect the laptop via ethernet? If so, you might try 
> something like?
> 
> 1. Boot in rescue mode.
> 2. chroot
> 3. systemctl mask lightdm # this will prevent X from starting
> 4. Boot in Qubes (without X11)
> 5. Update kernel using qubes-dom0-update, ideally to the one from 
> current-testing (e.g., qubes-dom0-update 
> --enablerepo=qubes-dom0-current-testing kernel.

Thank you for this. Although it did not work as a solution “out of the box” it 
gave me some good clues on where to start. The below steps were worked out in 
fits and starts, trials and errors.

1. I booted, waited for it to hang, then hit Ctrl-Alt-F2 (or technically 
Ctlr-Alt-Fn-F2 on this machine)

2. Luckily was able to get text login from there. Logged in as root.

3. I found `systemctl mask lightdm` did not do the trick, nor did removing and 
masking display-manager. What seemed to work was `systemctl set-default 
multi-user.target`. Anyway, in the end I was trying all three and my 
recollection is that only when I tried all three did the boot proceed to the 
end without needing to be interrupted. NOTE, there was *always* an X server 
error — I think this is due to how the Qubes installer works, I am guessing it 
launches X independent of Fedora — but with these settings the rest of the boot 
proceeded.

(In my mind, letting the boot go to the end maximized the chance of being able 
to update and salvage the system. In the end, I don’t know if any of this was 
necessary; it’s possible the below would have worked simply from hitting 
Ctrl-Alt-F2.)

4. su user
qvm-create -t fedora-23 -n netvm --label purple
qubes-prefs default-netvm netvm
qubes-prefs updatevm netvm
qvm-start netvm

5. At this point I plugged in a USB-Ethernet adapter. Netvm was showing no 
connection via curl. I found my Ethernet controller via lspci and assigned to 
the netvm via (sudo?) `qvm-pci -a netvm 00:1f.6`. This was sufficient; I did 
not need to assign USB for whatever reason. Only at this point was I able to 
successfully run a curl to remote server within the netvm.

6. I was getting just "failed to synchronize cache for repo” errors when trying 
to run the qubes-dom0-update commands. So on a lark I tried `qvm-run netvm 'yum 
upgrade' -p` and installed everything suggested.

7. sudo qubes-dom0-update --enablerepo=qubes-dom0-current-testing
(Worked!)

8. Reboot

9. Qubes launched into X to finish setup. Yay. I got some kind of error twice 
but retrying eventually fixed. When I clicked Finished Configuration button in 
the lower right, I was booting into text again, so I reverted all my prior 
changes:
rm /etc/systemd/system/lightdm.service
rm /etc/systemd/system/display-manager.service
ln -s /usr/lib/systemd/system/lightdm.service 
/etc/systemd/system/lightdm.service
ln -s /usr/lib/systemd/system/lightdm.service 
/etc/systemd/system/display-manager.service
systemctl set-default graphical.target
reboot

10. Qubes launches! At this point I struggle mightily to get the USB-Ethernet 
working again, including by deleting my old netvm to make sure it wouldn’t 
interefere with sys-net, making sure sys-net has the same ethernet controller 
(yup), turning on sys-usb, resetting sys-net. I never did get it working but 
meanwhile I’m waiting for the weird Lenovo mini-ethernet adapter to come so I 
can just use the ethernet port.

11. However in the meantime it turns out I have wifi! Success.

Eager for 4.0 but in the meantime I have a nice running Qubes.

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


signature.asc
Description: Message signed with OpenPGP using GPGMail

[qubes-users] Clearly expose --mem option in HVM docs

[Ryan Tate]

Right now the HVM documentation does not prominently disclose that initial 
memory/RAM may be configured on creation of the HVM domain via --mem option 
(https://www.qubes-os.org/doc/hvm/ ).

This is mentioned only in "Converting VirtualBox VM to HVM” which is way down 
the page and on a tangential topic. Under the main prominent "Creating an HVM 
domain” it is not mentioned.

Given that the default memory allocation is a very meagre 512MB, it would be 
helpful to include a mention of the --mem option in a prominent place, 
especially since Windows is a major use case for HVM, and this page is linked 
from the Qubes Windows documentation, and this allocation will be insufficient 
for the Qubes supported version of Windows (Windows 7) not to mention any 
successors.

I’d be willing to submit a patch if people think this makes sense. The project 
guidelines discuss patches for errors in the docs but it’s not clear to me if 
patches to improve the docs are also welcome. 
(https://www.qubes-os.org/doc/doc-guidelines/ 
)

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


signature.asc
Description: Message signed with OpenPGP

[qubes-users] Re: Clearly expose --mem option in HVM docs

[Ryan Tate]

By the way, it looks like this was suggested previously, see number 3 in the 
ordered list under “Steps to reproduce” here:

https://github.com/QubesOS/qubes-issues/issues/3089

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


signature.asc
Description: Message signed with OpenPGP

Re: [qubes-users] DispVM and Word/docx - no go

[Ryan Tate]

Thank you. This fixed it perfectly. And I’ve become better acquainted with 
https://www.qubes-os.org/doc/dispvm-customization/
….which I probably should have found before!
:-)

Cheers!

> On Oct 20, 2017, at 12:34 PM, Noor Christensen <kchr+qubes-us...@fripost.org> 
> wrote:
> 
> On Thu, Oct 19, 2017 at 11:08:07AM -0400, Ryan Tate wrote:
>> In Qubes 3.2 from a fedora 25 AppVM, when I try and open a docx (Word)
>> file via DispVM via the right-click menu, I just get a directory
>> listing inside the DispVM. Instead of opening the file with
>> LibreOffice it appears to unzip the file and show the underlying dir
>> structure. (The docx format is zipped.)
>> 
>> I have LibreOffice available to the app vm via the Fedora 25 template.
>> Is there somewhere else I need to put it to make it available to the
>> DispVM? Or is this a known/expected behavior for DispVM?
> 
> First of all, you need to make sure that LibreOffice is installed in
> your DispVM.
> 
> Regenerate your DispVM image using that fedora-25 template you mentioned:
> 
>$ qvm-create-default-dvm fedora-25
> 
> When it has completed, try opening the document in a DispVM again.
> 
> -- noor
> 
> |_|O|_|
> |_|_|O|  Noor Christensen
> |O|O|O|  0x401DA1E0
> 
> --
> You received this message because you are subscribed to the Google Groups 
> "qubes-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to qubes-users+unsubscr...@googlegroups.com.
> To post to this group, send email to qubes-users@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/qubes-users/20171020163437.6d25pqhwhvckzl5j%40mail.
> For more options, visit https://groups.google.com/d/optout.

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


signature.asc
Description: Message signed with OpenPGP

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

[Ryan Tate]

This happened to me, too, I Googled around and found setting an environment 
variable would make the Settings panel/app work:

[user@fedora28vm ~] env XDG_CURRENT_DESKTOP=GNOME gnome-control-center

(I re-typed the above while looking at another machine rather than copy/paste 
hopefully no typos!)

This issue, plus the weird long list of apps on the Qubes menu submenu for 
fedora-28 templatevm scared me off using this template VM, which I created 
following the docs on the site (but I went from 26->28 directly, which docs say 
should work). So I still use fedora-26 for all but 1 appVM.

> On Aug 14, 2018, at 8:13 PM, Michael MENG  wrote:
> 
> Any luck? I idid reinstall fedora 28 template, and install "fedora 
> workstation", but still the same.
> 
> --
> You received this message because you are subscribed to the Google Groups 
> "qubes-users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to qubes-users+unsubscr...@googlegroups.com.
> To post to this group, send email to qubes-users@googlegroups.com.
> To view this discussion on the web visit 
> https://groups.google.com/d/msgid/qubes-users/fbef8f93-c1be-474e-b6ca-d2eb16f87d64%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

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


signature.asc
Description: Message signed with OpenPGP

[qubes-users] update broke whonix, can't reinstall

[Ryan Tate]

I run stock Qubes 4, no special repos or templates.

Qubes Manager was showing an update for whonix-ws and whonix-gw templateVMs. 
Update process on whonix-gw went as usual. On whonix-ws, update seemed to 
proceed fine initially but then suddenly the update window disappeared. Usually 
it prompts to hit Enter to shut down the templateVM if the update completes 
successfully. 

Following the updates, neither templateVM (nor any VMs which use them) works - 
they will launch and run but I cannot bring up any programs, not even a 
terminal. 

I tried reinstalling both templates in dom0 and, rather frustratingly, this did 
not work.

I will attempt to type part of the error since I can't copy/paste out of dom0 
(grr):

Installed package qubes-template-whonix-gw-4.0.0-201803270426.noarch not 
available
Error: No packages marked for reinstall.

Installed package qubes-template-whonix-ws-4.0.0.-201803270504.noarch not 
available.
Error: No packages marked for reintall.

Can anyone give me a clue how I might at least start a reinstall? I don't need 
the package to exactly match, I just want the current whonix-ws and whonix-gw 
installed. (And yes I have tried a straight sudo qubes-dom0-update - no new 
stuff there.)

(PS Would really like to avoid any testing or unstable branches, just want 
stock Qubes, stock templates! ...and working whonix, even if it is old)

Thanks for any help
 

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

[qubes-users] Re: update broke whonix, can't reinstall

[Ryan Tate]

On Wednesday, November 7, 2018 at 3:25:34 PM UTC-5, Ryan Tate wrote:
> On Wednesday, November 7, 2018 at 3:23:46 PM UTC-5, Ryan Tate wrote:
> > Installed package qubes-template-whonix-gw-4.0.0-201803270426.noarch not 
> > available
> > Error: No packages marked for reinstall.
> > 
> > Installed package qubes-template-whonix-ws-4.0.0.-201803270504.noarch not 
> > available.
> > Error: No packages marked for reintall.
> 
> I forgot to say which commands I used to reinstall:
> 
> sudo qubes-dom0-update --action=reinstall qubes-template-whonix-gw
> 
> and
> 
> sudo qubes-dom0-update --action=reinstall qubes-template-whonix-ws

Turns out this is a known issue for more than a year and a half :-(

https://groups.google.com/forum/#!searchin/qubes-users/action$20reinstall$20package$20not$20available%7Csort:date/qubes-users/pZfFGDsTXbc/9d94zBMXAgAJ

IMO if this isn't going to be fixed the reinstall action should simply be 
removed. At least then people would just do the thing that works - remove the 
package, install the package. Having a broken reinstall is the worst of all 
worlds.

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

[qubes-users] Re: update broke whonix, can't reinstall

[Ryan Tate]

Well, now I can't figure out how to uninstall the template. Other VMs depend on 
it. Am I supposed to just reassign all of them, and delete it? 

Obviously I tried every permutation of "action=remove" I could think of but 
none matched. I tried copy/pasting every version of the full (and short) 
package name. 

[qubes-users] Re: update broke whonix, can't reinstall

[Ryan Tate]

On Wednesday, November 7, 2018 at 3:23:46 PM UTC-5, Ryan Tate wrote:
> Installed package qubes-template-whonix-gw-4.0.0-201803270426.noarch not 
> available
> Error: No packages marked for reinstall.
> 
> Installed package qubes-template-whonix-ws-4.0.0.-201803270504.noarch not 
> available.
> Error: No packages marked for reintall.

I forgot to say which commands I used to reinstall:

sudo qubes-dom0-update --action=reinstall qubes-template-whonix-gw

and

sudo qubes-dom0-update --action=reinstall qubes-template-whonix-ws

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

[qubes-users] Re: update broke whonix, can't reinstall

[Ryan Tate]

Ah, finally I realize that whonix is in a community repo. This was not 
intuitive as I recall it coming with my Qubes 4 install (do I misremember?). 

Adding --enablerepo=qubes-templates-community seems to make it work.

So I just needed to do qubes-dom0-update  
--enablerepo=qubes-templates-community --action=reinstall 
qubes-template-whonix-gw 

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

[qubes-users] Qubes menu failing. Come on guys

[Ryan Tate]

I don't know what is going on with 4.0.1 but suddenly my machine is haywire.

The latest is everything above and below the VMs is gone from the Qubes menu. 
The bottom of the menu where I'd go to shut down just says "No applications 
found." The top where I would go to find settings, Qubes Manager, even the dom0 
Terminal is just gone. So I don't even know how to debug. I've rebooting 
several times, it keeps happening.

I know Qubes is fairly high maintenance but I had a nice groove going with 
qubes 4 finally. Whatever updates you are pushing down with 4.0.1 updates are 
breaking my workflow left and right. First whonix got borked now the Qubes menu 
is broken. I shudder to think what will be next to fail. This is frustrating. 
Some of us are actually trying to get work done in the OS.

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

Re: [qubes-users] Re: dom0 environment lost on restore

[Ryan Tate]

> On Apr 1, 2019, at 10:01 PM, Andrew David Wong  wrote:
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
> 
> On 01/04/2019 2.54 PM, Ryan Tate wrote:
>> 
>> If the wish is not “restore” but rather to copy some files — “some 
>> files and scripts that I need” — then it is up to the user to 
>> transfer these files by the usual mechanism.
>> 
> 
> What is "the usual mechanism"? The main problem with the old behavior
> was that there was no reasonable way to get the dom0 home files out of
> the backup without clobbering the current dom0 home files that you
> want to keep.

The usual mechanism would be however you would normally move files from one 
machine to another. Not the backup/restore mechanism, since he scenario of 
wanting to move some files and scripts to a new machine is not backup/restore. 

Why is file transport being shoehorned into the backup mechanism? In order for 
some people to use restore for something other than restore, I had to spend a 
bunch of time navigating through obscure folders, copying with globs and mv and 
shunting aside old dirs, restarting (multiple times), and crossing my fingers 
it would work. Shouldn’t it be users who are doing strange, non backup/restore 
things who have to jump through hoops, and people who simply want to restore 
dom0 who get helpful default behavior?

If people seem open to a change I’ll file an enhancement request.

> 

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/5ABDF147-BDAD-4F02-93DA-0FB5594669D2%40ryantate.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: dom0 environment lost on restore

[Ryan Tate]

Thanks for the thoughtful replies (I just now saw Chris' from before).
Also thank you Andrew for making a Github issue!

It sounds like there is at least some common ground on providing
smoother restore as an option, which I appreciate. If it's too much to
add code to that effect anytime soon (I know this is a small project)
I wonder if there could be some documentation just that's ok to
wholesale replace the new dom0 user home dir with the old one and
maybe giving the relevant shell command?

Personally, I expected the old dom0 to be the default and would vote
that it be the default as I wonder if these other scenarios (potential
compromised dom0, moving files to new machine) are really more common
than restore for more mundane reasons.BUT that said I think just
presenting the choice of whether to write old or new dom0 will provide
sufficient clarity for most people regardless of the default. I expect
most people look at the options pretty carefully when restoring.

Replying to some specific points:

On Tuesday, April 2, 2019 at 7:52:19 AM UTC-4, Chris Laprise wrote:
> The current method prevents an unsafe restore in the event that the
> system was reinstalled due to a compromise (or suspicion thereof). This
> change was made shortly after Qubes project started promoting the idea
> of "paranoid mode" restore, with which it fits very well.

That seems reasonable as the default if it is expected that this is
usually why people are restoring. I wonder if it's not more common
that people restore for other reasons, in which case I'd argue that
the current behavior should just be an option. But as I said above,
it's probably not a big deal - just giving people a choice would
probably lead to the right outcome.

On Wed, Apr 3, 2019 at 1:01 AM Andrew David Wong  wrote:
>
> In Qubes OS, qvm-backup[-restore] *is* the usual mechanism for moving
> dom0's home and VMs from one machine to another. This is because it is a
> violation of the Qubes security model to move files from a less trusted
> VM to dom0, and every other VM is, by definition, less trusted than
> dom0. Therefore, qvm-backup[-restore] is the only official, secure way
> to move files into dom0.

Fair point, I forgot how hard Qubes makes it to move files into dom0.

That said, I would just note --  Files from dom0 do traverse other VMs
in all the scenarios we've discussed. I expect in backup/restore
scenario they are encrypted as they transit, for example, sys-usb. But
I don't know of any reason this could not be the case for random files
you want to export -- you would encrypt in gpg symmetric mode in dom0
with a passphrase (like a backup) before qvm-move-to-vm to sys-usb or
wherever and out into the world.

Admittedly, you would then need to jump through hoops to go back into
dom0, so it can't be described as "the usual way" as I did.

> All you had to do was move everything out of the restored subdirectory:
>
>   $ mv home-restore-2019-04-01-etc/* .   # move all normal files out
>   $ mv home-restore-2019-04-01-etc/.* .  # move all hidden files out
>
> Simple, quick, and easy, with no weird hoops to jump through.
>
> Now, don't get me wrong. I understand perfectly well that it's only
> "simple, quick, and easy" _if you know what to do_ and that this will
> _not_ be obvious to many users. But that's precisely why I suggested
> that it should be an option via qvm-backup-restore and the GUI tool.
> Make it discoverable so that users can understand that there are two
> possible outcomes and choose the one they want, then do it for them.

Yes, agree, thanks for finding the common ground.

> > If people seem open to a change I’ll file an enhancement request.
> >
>
> Since I was already writing all this, I just went ahead and opened an
> issue for it:
>
> https://github.com/QubesOS/qubes-issues/issues/4946

Thanks again for doing this.

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

Re: [qubes-users] Re: dom0 environment lost on restore

[Ryan Tate]

On Wed, Apr 3, 2019 at 1:53 PM Ryan Tate  wrote:

> That said, I would just note --  Files from dom0 do traverse other VMs
> in all the scenarios we've discussed. I expect in backup/restore
> scenario they are encrypted as they transit, for example, sys-usb. But
> I don't know of any reason this could not be the case for random files
> you want to export -- you would encrypt in gpg symmetric mode in dom0
> with a passphrase (like a backup) before qvm-move-to-vm to sys-usb or
> wherever and out into the world.

As I should have suspected, using the official backup-restore tools
does get you integrity checks (and perhaps better encryption?)
compared to this more basic technique I outlined, so I'm not
suggesting anyone run out and do it.

https://www.qubes-os.org/doc/backup-emergency-restore-v4/

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

Re: [qubes-users] Can’t boot after attempting to verify backup

[Ryan Tate]

> On Apr 1, 2019, at 11:48 AM, Chris Laprise  wrote:
> 
> I think its more related to this issue:
> 
> https://github.com/QubesOS/qubes-issues/issues/4791

I think you nailed it. The first time I ran the verification, I panicked when 
it said it was extracting data, as it seemed to have already “verified” various 
VMs, and I hit cancel. Then I ran again and kept my determination to finish, 
and it seemed to work and give a happy “Finished” message. (I did not see any 
lvm alerts, but as you note, I was probably away from the machine at various 
points.)

The issue above mentions that if a prior restore fails, and then you do 
another, you  may run out of disk space. I think the equivalent happened to me, 
except instead of failing, it was cancelled (same result).

Right now I’m restoring my backup to a fresh Qubes install. At least I have my 
Qubes menu back, and fedora29, and my backup is about as fresh as one could 
hope.

Thanks for the help.

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


signature.asc
Description: Message signed with OpenPGP

[qubes-users] Re: dom0 environment lost on restore

[Ryan Tate]

> On Apr 1, 2019, at 2:26 PM, Ryan Tate  wrote:
> 
> Although the backup included dom0, and the restore as well, I have lost 
> various key settings. My xfce panel shrank and moved to the top and the 
> button size changed, for example. My desktop icons for launching applications 
> are all gone. Caps lock no longer mapped to Control. My command history is 
> gone in dom0 terminal. Clock is wrong format. Etc etc.
> 

Now I see there is a folder in my dom0 home dir called 
‘home-restore-2019-04-01-etcetc’.

But what do I do with this? I just have to manually figure out what files are 
important? :-\

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


signature.asc
Description: Message signed with OpenPGP

[qubes-users] dom0 environment lost on restore

[Ryan Tate]

I recently had to wipe my Qubes machine, resinstall, and do a full restore of 
my VMs from a very recent backup (three days old).

Although the backup included dom0, and the restore as well, I have lost various 
key settings. My xfce panel shrank and moved to the top and the button size 
changed, for example. My desktop icons for launching applications are all gone. 
Caps lock no longer mapped to Control. My command history is gone in dom0 
terminal. Clock is wrong format. Etc etc.

Is it possible to get any of these back? Were they backed up anywhere and are 
hidden for security reasons or something? And if not, what is actually, like, 
backed up when I back up dom0?

Thanks for any pointers.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/8884FCC5-8B49-42D2-B35B-36AD5C6B1F46%40ryantate.com.
For more options, visit https://groups.google.com/d/optout.


signature.asc
Description: Message signed with OpenPGP

[qubes-users] Re: Can’t boot after attempting to verify backup

[Ryan Tate]

Hmmm, looks an awful lot like this:

https://github.com/QubesOS/qubes-issues/issues/4479
https://groups.google.com/forum/#!msg/qubes-users/PR3-ZbZXo_0/wem9wbGTBgAJ
https://github.com/QubesOS/qubes-issues/issues/4857
:-\

Fwiw I am on stable, NOT testing (a question raised in that first thread).

So across these threads I am seeing ~4 other people publicly reporting same 
issue.

The solution is to reinstall (I guess?) but I see no reason to expect the issue 
would not resurface. This was just a routine update on a stable system that has 
been running Qubes for almost 2 years now. I could go to the pain of 
reinstalling from scratch, but from where I sit this seems to be some kind of 
bug.

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


signature.asc
Description: Message signed with OpenPGP

[qubes-users] Re: Can’t boot after attempting to verify backup

[Ryan Tate]

PS not an April 1 joke sadly. 

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

[qubes-users] Re: Can’t boot after attempting to verify backup

[Ryan Tate]

Looking over journalctl in emergency mode. It looks like it decrypts fine 
(“Reached target Encrypted Volumes. Reached Target System Initialization. 
Reached Target Basic System.”) 

It seems like it sees many of my vms (many “inactive ‘/dev/qubes/dom0/vm-foo’ 
[10.0GB] inherit”)

But there is
“PARTIAL MODE. Incomplete logical volumes will be processed...
Check of pool qubes_dom0/pool100 failed (status: 1). Manual repair required!”

Then soon after come the warnings I posted in my first message. 

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

[qubes-users] Can’t boot after attempting to verify backup

[Ryan Tate]

On Friday I backed up my machine and attempted to verify the backup by 
launching qubes-backup-restore (GUI interface) and ticking the verify only box. 

Is it possible this box does not work? I was a bit alarmed when qubes began 
unpacking the backup after verifying each qube, but thought perhaps it was 
checking the data.

This morning is my first time booting since then. It goes into emergency mode. 
Warnings include “dracut-initqueue timeout - starting timeout scripts” (many 
times) “Could not boot.” “/dev/mapper/qubes_dom0-root does not exist” 
“/dev/qubes_dom0/root does not exist”. 

The only thing significant I can think I did to system Friday was the backup. 
It’s possible I also ran system update before or after backup and I vaguely 
recall a dom0 update but can’t recall if it was fRiday. 

Thanks for any help. Worried it’s a wipe and restore 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 post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/ADC61334-2172-4540-AABA-8E17C6FD06ED%40ryantate.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: dom0 environment lost on restore

[Ryan Tate]

> On Apr 1, 2019, at 2:33 PM, Ryan Tate  wrote:
> 
> Now I see there is a folder in my dom0 home dir called 
> ‘home-restore-2019-04-01-etcetc’.
> 
> But what do I do with this? I just have to manually figure out what files are 
> important? :-\

I just sort of methodically copied over anything that seemed important and 
rebooted which seems to get me most of the way there.

I would like to say, I really think the wrong decision was made here:

https://github.com/QubesOS/qubes-issues/issues/2271
https://github.com/QubesOS/qubes-issues/issues/1106

The rationale for not actually restoring dom0 when dom0 is requested to be 
restored seems to be:
1.User may be restoring to a different machine from the original, which could 
obviate e.g. monitor settings. User can’t simply avoid restoring dom0 in this 
situation "because it contains some files and scripts that I need” (quote from 
issue 2271).
OR
2. user may only restore some VMs and then the dom0 restore will create false 
menus (issue 1106)

I would argue, if you ask to restore dom0, then dom0 should be restored (truly, 
not by copying over a directory, which is not a “restore”). Any glitches due 
to, for example, restoring dom0 to a different machine, are the responsibility 
of the user. User may also need to handle restoring dom0 with only partial vm 
restore, for example by purging appmenus (although ideally the restore process 
or architecture of Qubes would make partial restores happen more smoothly).

If the wish is not “restore” but rather to copy some files — “some files and 
scripts that I need” — then it is up to the user to transfer these files by the 
usual mechanism.

IMO Qubes has allowed the definition of “restore” to become a bit corrupted. To 
restore is not just to copy a directory and let the user fend for themselves. 
When I “restore”, the original state should largely come back. e.g. app menus 
in vms, xfce panel particulars, desktop particulars, etc. If I want something 
different, for example only to copy some settings over, it should be up to me 
as a user to make that happen. If the restore is imperfect, that is OK — it 
would be better to have an imperfect restore (with, for example, some phantom 
menus) than to have no restore at all, from the standpoint of user 
expectations, judging purely from myself.

Just my $.02.

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


signature.asc
Description: Message signed with OpenPGP

Re: [qubes-users] Can't set default_target to @dispvm:foo in policy

[Ryan Tate]

On Fri, Mar 8, 2019 at 7:03 PM Marek Marczykowski-Górecki
 wrote:
> > Seems like a bug?
>
> Indeed. Could you report it at
> https://github.com/QubesOS/qubes-issues/issues ?

OK, done: https://github.com/QubesOS/qubes-issues/issues/4881

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

[qubes-users] networked dvm for vault?

[Ryan Tate]

Short version: Is it a security issue to set a networked disp vm as
the default disp vm for a vaulted vm?

I have a vaulted vm (no network) and a printing dvm (limited local
network access via firewall). It would be convenient to set the
printing dvm as default disp vm for the vault so i can easily print to
network when I want to do so.

But I notice that when I launch "view in disposable vm" from
right-click menu, there is no confirmation in the GUI as there is for
qvm-move and so forth. Which makes me wonder if malicious software in
the VM could use this as an escape vector.

I read through the below document, and although some security issues
around dvms are addressed, I could not figure out the answer to my
question from it:

https://www.qubes-os.org/doc/disposablevm/

Thanks for any advice

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

Re: [qubes-users] networked dvm for vault?

[Ryan Tate]

On Thursday, March 7, 2019 at 7:24:11 PM UTC-5, unman wrote:
> The fact that you don't see a prompt suggests that you have a policy se
> to "allow" - you can check this in /etc/qubes-rpc/policy/qubes.OpenInVM
> If you change that so that it reads:
> vault $dispvm ask
> then you should see a prompt.

Thanks for this. I ended up just switching it to a vaulted dvm (which, in turn, 
I also had to set to use a vaulted dvm (itself)!)

Intrigued by your other idea of setting some strict policies on the vault(s) 
explicitly in the policy dir. Will explore.

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

[qubes-users] Can't set default_target to @dispvm:foo in policy

[Ryan Tate]

I was trying to have a qubes.OpenInVM policy that would pre-fill a target in 
the permission dialog when the destination was an inside of a certain dispvm.

Specifying the destination vm (#2 entry) in the policy works fine to specify a 
dispvm instance.

But specifying the default_target (part of #3 entry) in the policy as a dispvm 
instance fails.

For example, this WORKS:

$anyvm  @dispvm:dvm-print  ask,default_target=work

...but is not what I want.

What I want is this, but it does NOT WORK:

$anyvm  @dispvm:dvm-print  ask,default_target=@dispvm:dvm-print

The resulting dom0 prompt at the top says "Domain '@dispvm:dvm-print' doesn't 
exist".

What I expected is the dom0 prompt would have "Disposable VM (dvm-print)" entry 
pre selected.

Seems like a bug?

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

[qubes-users] Qubes backup UI stalls badly

[Ryan Tate]

Today I went to backup my machine using Qubes backup GUI and near the end (?) 
the progress bar was at 100% but the Finish button was not clickable. I waited 
maybe half an hour, an hour, and tried closing the window. I got an error 
message saying the window was not responding and asking if I wanted to force 
close. I said No. Now (maybe 15 minutes later) the window is completely blank.

I have previously been left without a bootable Qubes machine because I 
cancelled a Qubes restore. I am worried I am about to be in the same state. Is 
there anywhere I can check to see if there are big stray files left behind in 
dom0 and not cleaned up? Can I check if I’m about to have lvm issues?

Also, this is not the first time Qubes Backup has behaved oddly. I also 
commonly get it stuck at 99% for hours so I give up and force close. Other 
times, it proceeds pretty quickly to 100% and I get the Finish button clickable.

The backup is only about 90GB (uncompressed, but compressed it is somewhere 
closer to 50GB) and is coming off a speedy internal drive to a decent USB3 
external disk. No idea why I am having these issues.

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


signature.asc
Description: Message signed with OpenPGP

Re: [qubes-users] Re: Qubes 4 boot stuck at: "[ OK ] Reached target Basic System. "

[Ryan Tate]

It would be nice if someone from the Qubes team could provide at least some 
basic tips for Qubes users on how to avoid having our installations completely 
ruined by what are apparently LVM issues. This case is at least the sixth I'm 
aware of counting myself of a Qubes system totally unable to even boot and 
requiring a restore.

Every time now that I do a backup or restore I have to live in white knuckle 
fear that something might go wrong and I will lose again my system and have to 
restore again, a process that can be laborious and error prone not to mention 
simply time consuming.

Some simple instructions on how to do whatever needs to be done to keep this 
from happening -- defensively re-size dom0 or other Qubes? clear temp files out 
of certain dir used by the backup process? twiddle some settings? -- would be 
incredibly calming. I have a 1TB drive here so it seems unnecessary that my 
machine dies because of some shuffling of VM resizing issues. Can't I just 
allocate a ton of space to whatever this lvm process is?

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To post to this group, send email to qubes-users@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/7741d00a-02f8-46e9-8a14-134eb61c2448%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] How to enter ipv6 in firewall settings?

['Ryan Tate' via qubes-users]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256


I suspect this is a "dumb" question, but can't figure out the answer
after searching through the list archives:

I am unable to enter colons (from ipv6 addresses) into the firewall
whitelist on the "Firewall rules" tab of "Qube Settings" when I click
the "+" button. The resulting input box only seems to accept digits or
dots. Is there some other way to enter an ipv6 address, other than using
colons?

I am trying to whitelist all the IPs associted with a given subdomain;
the subdomain name resolves (in nslookup) to a handful of ipv4 and ipv6
addresses. Whitelisting the ipv4s alone does not seem to be getting the
job done.

Thanks for any help ...
-BEGIN PGP SIGNATURE-

iQIzBAEBCAAdFiEEld4E33dXYpZjK0nBqQc3v7v0xDoFAl2fl0wACgkQqQc3v7v0
xDrcyw/+KIYYNmy4fsyY3dgTULFgHud6eyxE3k2WbJu1iXJ73GBmP7n6p3w0E315
6s+PFfYwqdtl/7nb2YBTk5GKi6/vehiZM/7VC8e4FkhQSIXIykeYKKFsX/3I8Cyw
CdOdLKBvfg9Eg/FNV23e9EyzoPvtCgBSUHjU8hh5wAdLc+3Xg7aSCpA+I80pTQij
7xvx5hdmifAZbFbqxYWVEDarUqvhgQyegVAzsrt87p6sErEPI+l14mJei2thekbo
WllEvEO1KmTlB3asIScxSRdHklNcQLL3rchc2rF57mvVNJ2Mg4cJTSg2d0XwcNwc
ym2qBO9UTRIMzbShIoZJR0hcYkqNmIvc8EpJxCGI+287uqwCSwSCSVd2a6toeSqw
NX/2EKo3h30Hvh1PYuQYRHwHkEgYJt8Ojal6WkdPfRVXTgWxFPtNwiav3qvApkEi
hMl1ELCvXXbl6c8q0M4WL0Ip6kUX7YA17F/avkhICVuDpxnrnhM9lAgkmmkCQPdJ
lmhIsymnV9gPrcafDhqdFr2MBEc0Eh8sHt5m4pWFLRbaqsA0DA5HBnXrtJlteFHF
af65W7QU5ko2mOvD5eiST7tlIz9WKupjZmCsiCE/QVI7XroUP65nEnJszXP+p/SY
MyKErVUsrczStjM4U8BUSMU1cm29jdnCpwNlP02eIlTqMGi2pkY=
=GAeX
-END PGP SIGNATURE-

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/87imowe3kz.fsf%40ryantate.com.

[qubes-users] Re: Does qubes block usb on thunderbolt port?

['Ryan Tate' via qubes-users]

Ryan Tate  writes:
> On my ThinkPad X1 Carbon gen5, I can use my thunderbolt 3 ports fine for
> display and for power. However, Qubes does not seem to recognize a usb-c
> flash stick or a usb-c yubikey plugged into these ports

I think I got this figured out. ThinkPads apparently do not show the
USB-C controller on these Thunderbolt ports to the OS unless and until
something is physically plugged in. I was clued into this by this
thread; don't be fooled by the subject line it is about more than hubs -
see bit where the user also was not able to connect the drive directly -
https://groups.google.com/forum/#!searchin/qubes-users/usb-c$20thunderbolt%7Csort:date/qubes-users/VIqnIcubq9Y/-gmRME7qBgAJ

Per the thread above, Qubes does not (seem to) handle controllers that
pop up after boot.

When I booted with a usb-c flash drive already in the Thunderbolt port,
I was able to finally see the USB-C controller via lspci in dom0. I was
able to shut down sys-usb and attach the controller to sys-usb (Devices
tab in Qubes Settings for sys-usb) and USB-C items then became visible
when I started sys-usb again.

But, on a reboot, if no USB was plugged in to the port, sys-usb would
fail to start up at all because the controller (aka the "device" I had
attached) was no longer there. (Also, even when a usb-c item was plugged
in at boot and mounted, disconnecting the item and connecting something
else (like a displayport cable for external monitor, which worked) left
me unable to re-connect the usb-c item, but this may be because I did
not set "no-strict-reset" -- I never bothered to fiddle with that when I
realized the prior mentioned boot issue).

This is all kind of a bummer because it means that effectively I can't
use usb-c to attach anything like a storage device, yubikey, etc on this
machine with Qubes. On the other hand I realize the Thunderbolt system
generally and perhaps specifically the way Lenovo/ThinkPad machines
handle exposing USB buses on Thunderbolt raise some unique challenges.

(The one thing that I do wonder is if is neccesary for sys-usb to bail
out on boot when an assigned device is not present, maybe there could be
a system for transient but assigned devices to be allowed to come online
post boot? No idea how feasible this is.)

-- 
You received this message because you are subscribed to the Google Groups 
"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/87muaxprg6.fsf%40disp2634.

[qubes-users] Does qubes block usb on thunderbolt port?

['Ryan Tate' via qubes-users]

Does qubes block USB data on Thunderbolt ports?

On my ThinkPad X1 Carbon gen5, I can use my thunderbolt 3 ports fine for
display and for power. However, Qubes does not seem to recognize a usb-c
flash stick or a usb-c yubikey plugged into these ports (the only usb-c
ports). (The flash stick has usb-a as well, on the other side, and it
shows up fine in sys-usb when I plug it in that way.)

I poked around in the BIOS to ensure there is no BIOS issue but even at
the "no security" setting I encounter this issue.

I thought I would just double check to see if Qubes might be involved in
this issue since there are various security considerations around
Thunderbolt in play (and I couldn't quite follow prior discussions of Qubes +
Thunderbolt). I'm on 4.0.1 or
4.0.2.

Thanks for any help.


   Ryan

-- 
You received this message because you are subscribed to the Google Groups 
"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/87lfqjrxpy.fsf%40disp2634.

[qubes-users] What's your flow for new templateVM?

['Ryan Tate' via qubes-users]

Saw the new f31 templateVM (thanks for that) and just curious how 
folks generally migrate to a new templateVM.


I manually maintain this big text list of packages and just use 
that to manually update the fresh templateVM to what I 
need. There's typically also some non package installs, which I 
include basic pointers for (think downloaded rpms and so forth), 
as well as some outside repos to add (e.g. keybase). There's also 
typically some packages I forgot to put on the list, which I can 
usually suss out by going through the bash history for the old 
template, although often there's one or two that slip through the 
cracks, which I find out about eventually and it's not a huge 
deal.


I'm particularly curious if anyone does anything more 
sophisticated than that, using salt or some other automated deploy 
system to prep new template images.


Thanks for any tips!

--
You received this message because you are subscribed to the Google Groups 
"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/878shybl9a.fsf%40disp2634.

[qubes-users] Special template to isolate less trusted software?

['Ryan Tate' via qubes-users]

I've started making special templateVMs where I install less 
trusted software, typically closed source binaries or code 
distributed directly from a vendor.


I am curious if others do this and if people think it adds much 
security wise.


For example, in addition to vanilla fedora-32, where I will 
install any number of packages from the standard repos, I have -


fedora-32-zoom (the proprietary videoconferencing software)

fedora-32-slack (the group chat app, installed from their own rpm)

fedora-32-print (had to run a Brother install tool to get printer 
working, use it from my dvm-print wich is firewalled only to my 
local printer ips)


fedora-32-media (has some proprietary media hnadling software)

I just don't like the idea of putting untrusted code in a 
templateVM used by sensitive VMs. On the other hand, perhaps I 
worry too much, in theory at least I do control when any given app 
is run? The Brother install was a bash script run via sudo (!!) 
that could have done anything but the others typically go in as 
rpm files via dnf, so presumably (?) they can't just install 
untrusted services that get auto launched.


Obviously this makes updates take longer, so it's got some cost.

Is this a wise approach? Or no? Thanks for any thoughts

 Ryan

--
You received this message because you are subscribed to the Google Groups 
"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/87h7sfzqv3.fsf%40disp2634.

[qubes-users] attach encrypted usb drive as block?

['Ryan Tate' via qubes-users]

Are there any known issues attaching a LUKS encrypted USB drive as 
a block device?


If I attach the drive as a USB device it works fine, it shows up 
in nautilus in the destination VM and I can click the drive and 
enter the password.


If I attach as a block device, first it doesn't show up in 
nautilus. Then I try and follow the directions 
(https://www.qubes-os.org/doc/block-devices/) to attach the drive 
and I get an error:


[user@vault ~]$ mkdir mnt [user@vault ~]$ sudo mount /dev/xvdi mnt 
mount: /home/user/mnt: unknown filesystem type 'crypto_LUKS'. 

I get this issue whether I attach a full block device or a 
partition.


My understanding is that attaching the drive as a block device is 
significantly more secure than attaching it as a usb device. Any 
clues to where to look to figure out how to get this working? 
(This is fedora-31 and the cryptsetup and cryptsetup-luks packages 
appear to be already installed.)


Thanks for any tips

  Ryan

--
You received this message because you are subscribed to the Google Groups 
"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/87imd83rdz.fsf%40disp2634.

[qubes-users] Re: attach encrypted usb drive as block?

['Ryan Tate' via qubes-users]

Ryan Tate  writes:
If I attach as a block device, first it doesn't show up in 
nautilus.


Actually, I found that for some reason as a block device it shows 
up under "Other Locations" in the nautilus sidebar. Once I 
navigate there all is cake. Sorry for the noise.


--
You received this message because you are subscribed to the Google Groups 
"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/87eenw3q2p.fsf%40disp2634.

Re: [qubes-users] MS Office 365 in Qubes

['Ryan Tate' via qubes-users]

On Thursday, May 13, 2021 at 10:33:31 AM UTC-4 sv...@svensemmler.org wrote:

>
> https://github.com/elliotkillick/qvm-create-windows-qube 
>
> But if Office 365 Suite are the only windows apps you need I'd go for 
> CrossOver. 
>

 I'm very curious about your experience running CrossOver in Qubes Sven.

How stable and solid is it? How performant? Is it easy to get data in/out 
to other vms (via copy paste or file transfer)?

My worry is that it would be too many layers:

Qubes dom0 (Xen) -> AppVM (linux) -> CrossOver (Windows API translation) -> 
Office

But it sounds like it works for you? In Qubes?

I thought perhaps using a Win10 qube might be more direct and thus better, 
and also potentially more stable over a period of years (since you are not 
relying on Codeweavers to keep maintaining CrossOver by tracking the Win10 
API):

Qubes dom0 (Xen) -> AppVM (Win10) -> Office

but this seems to be tricky for people and the current state of qubes 
tooling on Win10 not good. So CrossOver holds some interest to me. I have 
similar issues with LibreOffice - it is a wonderful and miraculous body of 
code but I have found it is not good for collaborating with Office users 
(in my case, track changes causing crashes on both sides after several 
rounds of document exchange in Word/LibreWriter).

Thank you for any information

-- 
You received this message because you are subscribed to the Google Groups 
"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/01f38e9e-199e-48de-90cf-0e2586c59d07n%40googlegroups.com.