Re: [qubes-users] Dual booting Qubes and Qubes?

['awokd' via qubes-users]

Claudia:
> My original thought was to just give each one its own directory in
> /boot/efi/EFI/, but the /boot/efi/EFI/qubes/ path seems to be hard coded
> somewhere, probably either in the grub2-efi package (which installs a
> precompiled efi binary to that directory) or in a grub2-install hook
> somewhere. Not sure which of those methods Qubes uses. At least, I
> couldn't figure out any way to persistently change the name of the EFI
> directory. Of course you could make your own directories by copying the
> files. e.g. /boot/efi/EFI/qubes{0,1}/, but when it updates (or you
> reinstall one of them), they would both try to install to
> /boot/efi/EFI/qubes/ again. And you'd have to manually change the path
> each time with efibootmgr.

This is partly what I need to do anyways on an older UEFI system. I
wrote a script that copies the updated files over to BOOTX64, and run it
after every update that touches EFI. Shouldn't be too hard to add
efibootmgr to it, and an edit to the .cfg file pointing at the
appropriate root=. Ignore the redundant .efi copies at the end; I'm
still not entirely sure which one my half broken UEFI implementation uses.

rm /boot/efi/EFI/BOOT/init*
rm /boot/efi/EFI/BOOT/vmlinuz*
cp /boot/efi/EFI/qubes/init* /boot/efi/EFI/BOOT/
cp /boot/efi/EFI/qubes/vmlinuz* /boot/efi/EFI/BOOT/
cp /boot/efi/EFI/qubes/xen.cfg /boot/efi/EFI/BOOT/BOOTX64.cfg
ls /boot/efi/EFI/qubes/xen-*.efi
cp /boot/efi/EFI/qubes/xen-*.efi /boot/efi/
cp /boot/efi/EFI/qubes/xen-*.efi /boot/efi/EFI/BOOT/
cp /boot/efi/EFI/qubes/xen-*.efi /boot/efi/EFI/BOOT/BOOTX64.efi

-- 
- don't top post
Mailing list etiquette:
- trim quoted reply to only relevant portions
- when possible, copy and paste text instead of screenshots

-- 
You received this message because you are subscribed to the Google Groups 
"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/93e03a28-1ce8-e9dd-a1f5-b6538dc6f608%40danwin1210.me.

Re: [qubes-users] wipe released diskspace of a disposable VM's

[brendan . hoar]

This script shows the approach I take for an ephemerally keyed lvm pool:

  https://pastebin.com/LDKKwsWW

Assuming you want a windows standalone work VM and one or more whonix 
disposable VMs, you just need to change the two variables in the script and 
launch it in dom0.

Be sure you know what you are doing. Review the script first.

It's hacked together, but it's been working well.

Brendan

-- 
You received this message because you are subscribed to the Google Groups 
"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/1118001c-05bb-4fe7-a45e-c7bafc6010c0%40googlegroups.com.

Re: [qubes-users] AppVMs start but zero of the apps are starting? (with logs)

[Steve Coleman]

On 2019-12-18 18:47, Stumpy wrote:

On 2019-12-19 01:16, Stumpy wrote:

On 2019-12-18 19:08, Steve Coleman wrote:

On 2019-12-18 07:57, Stumpy wrote:
Last night I noticed that I was not able to start an appvm via dom0 
(qvm-run appvm programname) so then tried to start another app in 
another appvm, nothing.
I had a bunch of things open still from earlier in the afternoon so 
figured I needed to reboot, did, and still nothing, except I dont 
have any previous apps open up so my system is barely usable.


When i try to run an app, say from the xfce menu (or directly from 
the dom0 terminal) I get the little pop up that the VM is starting, 
and it shows up in zentop and the qubes manager, but no app. I tried 
to start apps from the right click "run" option in the qubes manager 
but nothing, doesnt matter if the appvm is already running or not.


The only thing i have done in dom0 in terms of "messing around" was 
to modify the sudo vi /etc/qubes/quid.conf so that one of my appvms 
would open w/o a border (which I since undid in attempts to get 
things working) i cant think of anything else i have done in dom0?


This is killing me as I am not working on my work/win comp :( so any 
help would really really really be appreciated. Please let me know 
if there are any logs or something i should be posting?




This sounds very similar to a problem I have been having (at home and
at work), only your issue sounds like a much worse case of it.

Ref: Qubes 4.0.1, Fedora-30 template

When I come into work in the morning, or upon booting my workstation
at home, if I launch an app in a non-running VM (sometimes subsequent
re-launches of a VM) the app I used to initiate that VM does not come
up. The pop-up message of the starting VM appears, then nothing. The
VM gets started and the disk is whirring away, but the app never
appears. If I launch the same app again sometimes both instances of
that app appear one right after they other. Between those two
invocations I might even wait until all the disk activity settles down
and everything works fine.

If for instance I use Qubes Manager to "update qube" the window almost
never comes up the first time. The second time it will. If I start the
template first and then select "update qube" it almost always comes up
correctly, unless something is chewing up all the CPU or hitting the
disk pretty hard.

My issue seems to be related to too much activity of the AppVM's
services creating enough lag to the system that the qrexec either
times out or gets slowed down to the point of not completing the
launching of the app. This is frustrating because after the first
launch it seems to work better, so testing of why it isn't starting
clearly needs to be planned in advance. Perhaps some resources get
cached in memory the firt time so it starts that VM quicker, and thus
the qrexec doesn't time out?

I would suggest turning on the "Run in debug mode" option in the Qubes
Manager's AppVM configuration so you can collect better logging
information and see if that tells you anything. That is what I am
planning to do tomorrow morning before launching anything. I had just
turned it on for one VM this morning that sometimes acts up, and
wouldn't you know it, it has not repeated that problem launching that
VM the second time. Maybe tomorrow, or if I leave the machine alone
for a while I might get it to repeat again. I think I will make a
habit of turning on the debugging before launching any new VM's just
in case I can catch it in the act of not acting properly.


Thanks for pointing out where to turn the logging on.
Questions though, I was attempting to look through the three logs of
two different appvms but was not really sure where to start (was just
shy of 6k lines).
1) Would posting the output to like a pastebin be useful/appropriate?
2) How sensitive is the info in the logs? (In looking through them it
didnt seem like I was giving much info away but at the same time I am
barely able to make sense of most of it).

Thanks for the help, I of course want to get this figured out... I
love my qubes box, all my friends live inside it :P


Well as I have not been able to find (understand) anything wrote I 
thought I'd cross my fingers and post logs from two different appvms 
(debian and fedora). It occured to me though that if this is happening 
with all appvms, which it is, then perhaps its an issue with dom0 but 
anyway, am posting just in case. If there are dom0 logs that would be of 
use then please let me know.


https://pastebin.com/LAXPSyBc


What I see in the log that looks suspicious is:

   domain dead
   Failed to connect to gui-agent

if it connected you would have seen something like:

[   18.849522] audit: type=1130 audit(1576676114.676:22): pid=1 uid=0 
auid=4294967295 ses=4294967295 msg='unit=qubes-gui-agent comm="systemd" 
exe="/usr/lib/systemd/systemd" hostname=? addr=? terminal=? res=success'


And that "audit:" message is not anywhere in your logs, so I think your 
AppVM's 

Re: [qubes-users] wipe released diskspace of a disposable VM's

[brendan . hoar]

On Thursday, December 19, 2019 at 12:09:26 PM UTC-5, Brendan Hoar wrote:
>
> This script shows the approach I take for an ephemerally keyed lvm pool:
>
>   https://pastebin.com/LDKKwsWW
>
>
And of course, since I was in a hurry, I see typos and better possible 
edits in the explanatory text it displays after it runs.

In any case: while you can use the disk space widget to see primary pool 
data usage, I recommend you use lvs to determine your primary pool data 
usage % *and* metadata usage %. Qubes R4.1 will show both.

Also, review the VMs you intend to put in the new pool. Little to no space 
is used until the VMs and associated templates are copied over to it. So in 
addition to copies of the VMs/templates, additional work you do with data 
in the new pool will use storage in the primary pool, until you remove it 
(either by exiting the script correctly or by manually removing via 
lvremove if you did not exit the script correctly).

A full pool is a dead pool.

Brendan

-- 
You received this message because you are subscribed to the Google Groups 
"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/c6c69973-3624-44de-ac28-12a5cf650df9%40googlegroups.com.

Re: [qubes-users] Qubes freezes during installation process

['awokd' via qubes-users]

Slightly Different:
> 
> I downloaded Qubes-R4.0.1-x86_64.iso from 
> https://www.qubes-os.org/downloads/#qubes-release-4-0-1 and used 
> rufus-3.8.exe to burn the ISO file on an empty 64GB USB flash drive.
> 
> After that I rebooted my computer, started it in BIOS mode and made sure to 
> run the iso file from the 64GB USB flash drive. 
> 
> Qubes OS boots up for the first time and I selected "Test this media & 
> install Qubes R4.0.1"
> 
> After that I saw some command lines and then I saw the welcome screen. 
> 
> But it said "WELCOME TO QUBES R4.0.2-rc3" instead of R4.0.1

Are you sure you didn't download the wrong ISO? Did the SHA256 digest match?
> 
> In that same welcome screen I set English (United States) as language during 
> the installation process.
> 
> I hit the continue button and after that nothing happened. It looked like it 
> is frozen. I waited a while, way longer than what the installation guide 
> incidated, but it still doesn't do anything.

Try choosing the Install option that does not test media.

-- 
- don't top post
Mailing list etiquette:
- trim quoted reply to only relevant portions
- when possible, copy and paste text instead of screenshots

-- 
You received this message because you are subscribed to the Google Groups 
"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/6ab3207f-84f1-9bd4-2e76-c7b69d6fd9fc%40danwin1210.me.

Re: [qubes-users] Trying to connect phone to Qubes os(4.0)

['awokd' via qubes-users]

Tae Hwan Kim:
> Hi.
> I am trying to connect my android phone to my work vm in qubes os. So I 
> tried this.
> 
> 1. Changed AppVM(work) to HVM because PVH mode no PCI passthrough which I 
> am trying to do.
> 2. 
> lsusb
> 
> Bus 001 Device 002: ID 1004:61f9 LG Electronics
> 3. And then I did 
> readlink  /sys/bus/usb/devices/usb1
> 
> and it returned
> ../../../devices/pci:00/:00:14.0/usb1
> 
> 4. finally
> qvm-pci attach --persistent work dom0:00_14.0

This looks valid.

> But it says "empty response" and doesn't work.
> I followed this step .
> Am I doing right? In the result of lsusb says my usb connected in Bus 001 
> so I did 
> 
> readlink /sys/bus/usb/devices/usb1 instead of usb3(in document). Did I do it 
> correctly?
> 
Is your USB controller already assigned somewhere else, like sys-usb by
default? If so, you should try to assign just the USB device to your
work qube first instead of the controller with qvm-usb (see --help for
options). If you have and it isn't working, you might need to shutdown
sys-usb before you can re-assign a controller it is using. qvm-pci by
itself will show which devices are assigned to different qubes in the
USED BY column. You will often need to include the no-strict-reset
option with USB controllers.

-- 
- don't top post
Mailing list etiquette:
- trim quoted reply to only relevant portions
- when possible, copy and paste text instead of screenshots

-- 
You received this message because you are subscribed to the Google Groups 
"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/231e7292-59c0-7507-2731-16d653573665%40danwin1210.me.

Re: [qubes-users] pool "Manual repari required"

['awokd' via qubes-users]

'Crypto Carabao Group' via qubes-users:
> Hello All,
> 
> What is the general procedure in Qubes 4, if we can open the Luks, but then 
> pool00 seems inaccessible with rdsosreport message:
> Check of pool qubes_dom0/pool00 failed (status:1). Manual repair required!

There's not a general procedure because the failure can be for different
reasons. However, chances are the pool got corrupted with either a hard
power off or by filling it to 100%. Recovery is the same as any other
Linux running LVM thin pool. Look back in the log to see if there are
related messages. Attempt to repair- see
https://www.mail-archive.com/qubes-users@googlegroups.com/msg29882.html
for example.

-- 
- don't top post
Mailing list etiquette:
- trim quoted reply to only relevant portions
- when possible, copy and paste text instead of screenshots

-- 
You received this message because you are subscribed to the Google Groups 
"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/dc97ad39-022d-9a82-cce4-c320a4d126e3%40danwin1210.me.

Re: [qubes-users] wipe released diskspace of a disposable VM's

[brendan . hoar]

Use this one instead, previous one had a missing newline:

https://pastebin.com/JMtuns8g

Brendan

-- 
You received this message because you are subscribed to the Google Groups 
"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/1356c3ae-dbcf-4c39-8074-0300c1c5a80a%40googlegroups.com.

Re: [qubes-users] equivalent of grub kernel parameters on qubes?

[Guerlan]

On Wednesday, October 30, 2019 at 9:53:47 AM UTC-3, unman wrote:
>
> On Mon, Oct 28, 2019 at 09:36:50AM -0700, Guerlan wrote: 
> > I scrolled and couldn't find what you suggested. 
> > 
> > The contents of /boot/efi/EFI is a qubes folder which has qubes kernels 
> and 
> > xen.cfg, xen.efi 
> > 
> > On Monday, October 28, 2019 at 11:35:06 AM UTC-3, unman wrote: 
> > > 
> > > On Sun, Oct 27, 2019 at 10:07:25PM -0700, Guerlan wrote: 
> > > > I tried to locate that file on dom0 but I couldn't find. Was it 
> supposed 
> > > to 
> > > > be elsewhere? (yes, I installed with UEFI) 
> > > > 
> > > > On Sunday, October 27, 2019 at 11:59:05 AM UTC-3, unman wrote: 
> > > > > 
> > > > > On Fri, Oct 25, 2019 at 05:41:37PM -0700, Guerlan wrote: 
> > > > > > There's a quirk for laptop suspend problem that I want to try on 
> > > Qubes 
> > > > > that 
> > > > > > is the following on Ubuntu: 
> > > > > > 
> > > > > > sudo nano /etc/default/grub 
> > > > > > GRUB_CMDLINE_LINUX_DEFAULT="button.lid_init_state=open" 
> > > > > > 
> > > > > > However dom0 does not have such file. How do I pass kernel 
> > > parameters to 
> > > > > Qubes? 
> > > > > > 
> > > > > 
> > > > > I have that file but I use standard(legacy) boot. Did you install 
> with 
> > > > > UEFI? 
> > > > > If you are using UEFI, I believe you can install a EFI shell and 
> boot 
> > > > > into it to test change parameters. Or you can edit the file at 
> > > > > /boot/efi/EFI/qubes/xen.cfg to add your parameters. 
> > > > > 
> > > > > NB I dont like UEFI and dont use it, but I think that pointer is 
> > > right. 
> > > > > As always, back up any system files before you start changing 
> them. 
> > > > > 
> > > > > unman 
> > > > > 
> > > 
> > > The convention on these lists is to post at the bottom of the message, 
> > > so that a new reader can follow the sense by reading downwards. Can 
> you 
> > > try to do that? All you have to do is scroll to the bottom and 
> > > start typing. Thanks. 
> > > 
> > > So do you have /boot/efi/EFI? 
> > > What are contents? 
> > > 
> > 
> I'm starting to think you are ideologically wedded to top-posting. 
> Believe me, once you've tried bottom posting you will never understand 
> why you did this. 
> I guess your mail software outs the cursor at the top of the message 
> when you h=it "Reply". Ignore this broken piece of garbage.Take 
> control. Scroll to the bottom of the message, deleting any 
> unnecessary stuff on the way, and start typing. This will take you 
> seconds, 
> compared to the minutes, perhaps hours, that other users will spend 
> flipping between top and bottom of the message, trying to understand 
> what's going on. 
> Try it. 
>
> e in hand - look at the contents of the (*flip to top of message, 
> sighs*) xen.cfg and xen.efi files. Is one of those the one you are 
> booting from? 
> (Not being a UEFI person - is there really no grub screen?) 
>
> unman 
>


Am I doing things rigth now?

So, xen.cfg contains things like

default=4.19.71-1.pvops.qubes.x86_64

[4.14.74-1.pvops.qubes.x86_64]
options=loglvl=all dom0_mem=min:1024M dom0_mem=max:4096M iommu=no-igfx 
ucode=scan smt=off
kernel=vmlinuz-4.14.74-1.pvops.qubes.x86_64 
root=/dev/mapper/qubes_dom0-root rd.luks.uuid=luks-39... 
rd.lvm.lv=qubes_dom0/root rd.lvm.lv=qubes_dom0/swap i915.alpha_support=1 
rhgb quiet plymouth.ignore-serial-consoles
ramdisk=initramfs-4.14.74-1.pvops.qubes.x86_64.img
[4.19.71-1.pvops.qubes.x86_64]

which seem to be configuratioons to xen. Xen.efi gives me giant text with 
things like this:

ativesalloc_host_save_areastartup_cpu_idle_loopacpi_tb_create_local_fadt__trampoline_rel_startget_free_pirqcore2_no_vpmu_opsinject_vmceio_apic_read_remap_rteamd_iommu_setup_ioapic_remappinghpet_deinitvtd_ops_preamble_quirkvioapic_initsvm_vmexit_do_stgifree_domheap_pagesprocess_pending_softirqsnsvm_hap_walk_L1_p2mrangeset_domain_printkmcheck_initsetup_ept_dumpmapcache_vcpu_initmachine_to_phys_mapping_validautogen_entrypointsapic_versionpirq_shared__stop_bug_frames_0vcpu_restore_fpu_lazypaging_domain_initp2m_get_p2mpage_unlockdo_hvm_opdomain_pausecpufreq_gov_userspace__update_guest_eiplowmem_kbcontext_savedsvm_asid_initarch_do_vcpu_opcontinue_hypercall_on_cpuiommu_pt_cleanup_listinit_guest_l4_tablehvm_get_tsc_scaling_rationode_online_mapvmx_pin_based_exec_controlmemguard_guard_rangehvm_x2apic_msr_writevideo_flagsacpi_initialize_tablesserial_endbootsimple_strtoulldomain_unpause_by_systemcontrollercpupool_get_by_idcmci_supportmcequirk

There's no grub screen as far as I know. It boots to a log screen with very 
small resolution and them qubes password input appears

-- 
You received this message because you are subscribed to the Google Groups 
"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/fefe2ffc-e7c3-4e3f-a29c-d8e2994f50c1%40googlegroups.com.

[qubes-users] How to point(connect) to App VM from external?

[Tae Hwan Kim]

Hi all!
I am trying to use Qubes OS as a mobile development machine.

My backend server is running in work vm at localhost:4000
And I am testing my app in real device that is connected using USB cable.

The frontend client should send request to my backend server 
(localhost:4000).
For testing in real device, localhost address must be changed to real ip 
address(work vm).
So in my client.js(frontend code),

const HTTP_ENDPOINT = "http://10.137.0.15:4000/api;;
>
const httpLink = createHttpLink({ uri: HTTP_ENDPOINT});
>
const client = new ApolloClient({ link: httpLink });
>
, 
Unfortunately that address doesn't respond. I tried real ip address which 
is 192.168.1.8, But doesn't work neither.

How can I do this?

Thanks in advance.

-- 
You received this message because you are subscribed to the Google Groups 
"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/ce0e39e4-71be-404f-a6db-638fb8d989c8%40googlegroups.com.

Re: [qubes-users] Trying to connect phone to Qubes os(4.0)

[Tae Hwan Kim]

Thanks for your help.
I  just created sys-usb app vm following this guide. 

And sys-usb app vm finds phone automatically, so I just attach it to work 
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/a2d68358-474e-4a10-9fb6-edb0f07e80d7%40googlegroups.com.