[qubes-users] Re: Q4.0 - rc.local doesn't run automatically in AppVMs

2018-05-02 Thread NaBaCo
On 05/02/18 12:03, Ivan Mitev wrote:
> 
> 
> On 05/02/2018 11:25 AM, NaBaCo wrote:
>> On 05/02/18 09:52, 'awokd' via qubes-users wrote:
>>> On Tue, May 1, 2018 7:52 am, NaBaCo wrote:
>>>> Hello,
>>>> I have a simple command in /rw/config/rc.local the sets the keyboard
>>>> layout and shortcuts. I have made the script executable, and after
>>>> searching the internet found there's a timing problem (the system runs the
>>>> script too early), so I've added "sleep 5" to the beginning of the script.
>>>>  The script worked well in Q3.2, and runs well even now in Q4.0 when run
>>>> manually from command line, yet when I start the VMs, there's no effect.
>>>> This affects both debian-9 and fedora-26 AppVMs.
>>>> Increasing the "sleep" time didn't help.
>>>
>>> Tested this in a 4.0 debian-9 AppVM by adding to rc.local "date >
>>> /home/user/1", chmod 755 it, and it worked first try. Might want to add
>>> something similar to yours to make sure it's firing, then troubleshoot
>>> accordingly. Also check out
>>> https://www.mail-archive.com/qubes-users@googlegroups.com/msg20360.html.
>>>
>>
>> Hey,
>> I rebooted the VM after adding your line to rc.local, and indeed it
>> fires up. I'm assuming that rc.local runs before X server starts up.
>> The command I want to run is 'setxkbmap'.
> 
> As awokd pointed, rc.local starts before the X server is active.
> 
> A workaround is to use .desktop files, which would autostart after X.
> 
> See this doc (which by the way should help you with what you're trying
> to achieve with keyb layouts).
> 
> https://github.com/Qubes-Community/Contents/blob/master/docs/localization/keyboard-multiple-layouts.md
> 

Thanks Ivan, this is going to be the doc I'll change :)
The .desktop work-around is somewhat inelegant in my opinion - why not
use an already integrated feature rather then working around?

Either way, thank you very much!
--
NaBaCo.



-- 
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/pcbvc7%24iu4%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: Q4.0 - rc.local doesn't run automatically in AppVMs

2018-05-02 Thread NaBaCo
On 05/02/18 09:52, 'awokd' via qubes-users wrote:
> On Tue, May 1, 2018 7:52 am, NaBaCo wrote:
>> Hello,
>> I have a simple command in /rw/config/rc.local the sets the keyboard
>> layout and shortcuts. I have made the script executable, and after
>> searching the internet found there's a timing problem (the system runs the
>> script too early), so I've added "sleep 5" to the beginning of the script.
>>  The script worked well in Q3.2, and runs well even now in Q4.0 when run
>> manually from command line, yet when I start the VMs, there's no effect.
>> This affects both debian-9 and fedora-26 AppVMs.
>> Increasing the "sleep" time didn't help.
> 
> Tested this in a 4.0 debian-9 AppVM by adding to rc.local "date >
> /home/user/1", chmod 755 it, and it worked first try. Might want to add
> something similar to yours to make sure it's firing, then troubleshoot
> accordingly. Also check out
> https://www.mail-archive.com/qubes-users@googlegroups.com/msg20360.html.
> 

Hey,
I rebooted the VM after adding your line to rc.local, and indeed it
fires up. I'm assuming that rc.local runs before X server starts up.
The command I want to run is 'setxkbmap'.

Either way, I looked at the link you've posted and it made me think to
look inside /etc, where I found:

(fedora-26) /etc/X11/xinit/xinitrc.d/qubes-keymap.sh
(debian-9) /etc/X11/Xsession.d/90qubes-keyboard

>From my understanding it is a script that runs automatically at X server
start up, which parses the user's keyboard settings in
~/.config/qubes-keyboard-layout.rc.

The only problem was that it parses only -layout and -variant but not
-option, so I've added that capability to the script (attached), thus
allowing it to add custom key combinations for layout switching.
Then I added the necessary options in
~/.config/qubes-keyboard-layout.rc, each separated by a + sign:

us,il,ru + ,,phonetic + grp:alt_shift_toggle

And that worked perfectly for me.

Then, after another thought, since I want the same layout configuration
to propagate to all the VMs, I just commented out the entire script, and
added the command I wanted in the end (last line in the attached file).
That worked perfectly well too.

Solved!
Thank you for your help.

--
NaBaCo.

PS: If relevant, I'll be glad to make a PR for the script and to add
this into the official documentation.

-- 
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/pcbshl%248g5%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.


qubes-keymap.sh
Description: application/shellscript


[qubes-users] Q4.0 - rc.local doesn't run automatically in AppVMs

2018-05-01 Thread NaBaCo
Hello,
I have a simple command in /rw/config/rc.local the sets the keyboard
layout and shortcuts. I have made the script executable, and after
searching the internet found there's a timing problem (the system runs
the script too early), so I've added "sleep 5" to the beginning of the
script.
The script worked well in Q3.2, and runs well even now in Q4.0 when run
manually from command line, yet when I start the VMs, there's no effect.
This affects both debian-9 and fedora-26 AppVMs.
Increasing the "sleep" time didn't help.

Will be glad for help in debugging.

--
NaBaCo

-- 
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/pc967q%24qv0%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: HCL - Dell Inspiron 13 5387 - Qubes 4.0

2018-05-01 Thread NaBaCo
On 04/30/18 15:47, donoban wrote:
> On 04/30/18 14:20, NaBaCo wrote:
>> 1. I'm unable to start HVM from ISO's. They all crash while
>> loading.
> 
> Check 'qvm-prefs VM', kernel should be empty.
> 
>>

Did that. In most ISOs I manage to boot up to the GRUB, and begin the
boot process, and that's when it crashes.

I'll be glad to post logs if told which ones.

--
NaBaCo.

-- 
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/pc95rn%24pi9%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: Removed/renamed VMs are not completely removed from system configuration data

2018-05-01 Thread NaBaCo
On 04/10/18 17:10, 'awokd' via qubes-users wrote:
> On Sun, April 8, 2018 9:01 pm, Andrew David Wong wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA512
>>
>>
>> Hi all,
>>
>>
>> I'm sending the following question at the request of Achim Patzner
>> (CCed):
> 
>> * It still tries auto-starting the "*1" VMs even though they were
>> removed * It still tries starting the "work1" VM
>> * Nevertheless work-32 is correctly launched so on renaming the flag
>> remained active.
>>
>> How [can I] get these entries out of the appropriate database again?
>> Maybe the same part of the boot process which is removing corpses of
>> dispVMs could do these plausibility checks for machines that do not exist
>> anymore. Or add a qubes-system-dbck. ```
> 
> These settings used to get stored in /var/lib/qubes/qubes.xml but don't
> see them in there for R4.0. Can you "qvm-prefs" the VMs you don't want to
> try to autostart and set to false?
> 
> 
I had the same problem, after renaming VMs restored from Q3.2.

--
NaBaCo

-- 
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/pc94mm%24jcn%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] HCL - Dell Inspiron 13 5387 - Qubes 4.0

2018-04-30 Thread NaBaCo
Installation worked well, with only EFI post-installation boot problem
that was solved with this fix:

https://www.qubes-os.org/doc/uefi-troubleshooting/#boot-device-not-recognized-after-installing

Main points:
1. I'm unable to start HVM from ISO's. They all crash while loading.

2. Since the touch screen is on the same USB controller as all the other
USB ports, it's locked inside sys-usb, meaning it's unusable. I'm not
willing to write a proxy, due to security considerations, so I'm
thinking to send the computer to Dell and ask them to reconnect it to a
separate controller.

3. I'm not using a TPM yet, but I know the laptop has such an option.

4. Suspend works very well, very fast. The only problem is post resume
screen locking, which I know is an X11 problem.

5. Hibernate doesn't work at all (when given a command there's either no
reaction or the screen locks), but I think this is done purposely on Qubes.

6. Microphone, camera, and USB pass-through to VMs works perfectly.

I had Qubes 3.2 before hand which also worked well. I had to apply the
same EFI fix after installation. At first the suspend didn't work,
freezing at resume, so I had to update the kernel (including updating it
in the BOOT folder, as written in the aforementioned fix) to fix it.

--
NaBaCo.

-- 
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/pc71hg%24unf%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.


Qubes-HCL-Dell_Inc_-Inspiron_13_5378-20180430-105707.yml
Description: application/yaml


[qubes-users] Re: 4.0 not updating dom0 nor fedora?

2018-04-30 Thread NaBaCo
On 04/16/18 16:35, cooloutac wrote:
> On Sunday, April 15, 2018 at 8:34:52 PM UTC-4, Stumpy wrote:
>> One small caveat, whonix-ws updated, everything else says there are no 
>> updates? While this is possible I am thinking its unlikely?
>> I tried to update dom0 from the terminal
>>   sudo qubes-dom0-update
>> and got
>>   /usr/lib/qubes/qubes-rpc-multiplexer: 14: 
>> /etc/profile.d/20_power_savings_disable_in_vms.sh shopt: not found
>>  /usr/lib/qubes/qubes-rpc-multiplexer: 14: 
>> /etc/profile.d/20_power_savings_disable_in_vms.sh shopt: not found
>>  No new updates available
>>  No updates available
>> For what its worth, none of them, not even whonix-ws would update until 
>> I set whonix-gw as the NetVMs, even though I had selected the option for 
>> appvms to update via tor.
>> I did open a terminal for each template and managed to do updates using 
>> apt-get for debian and whonix but not for fedora nor dom0, and not via 
>> the qubes manager "update qube" option
>> For fedora it gave the error
>>  Error: Failed to synchronize cache for repo qubes-vm-r4.0-current
>> Thoughts?
> 
> I get the same errors when updating dom0.  I think its a known issue.  I hope 
> lol.
> 
> For the fedora error,  when using whonix as updatevm you have to go into the 
> qubes-r4.repo file in /etc/yum.repos.d directory of the fedora template and 
> change everything from http to https.  
> 

I solved this, as described in the following link:

https://www.reddit.com/r/Qubes/comments/88d5hs/fresh_install_of_qubes_40_issues_and_solutions/dx4hlng

Good luck!
--
NaBaCo.

-- 
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/pc6oca%24tda%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] Re: Qubes Domains.py Widget Seems Wedged

2018-04-30 Thread NaBaCo
On 03/30/18 13:01, William Bormann wrote:
> 
> I'm seeing an oddity with this widget.  At random, some VMs show the update 
> indicator as continuously spinning.  It appears to show a VM always starting, 
> but qvm-ls in dom0 shows the VM as started.  In a nutshell, the widget seems 
> to be unsure of the VM's state.
> 
> Anyone else seeing this?  Is there a workaround/fix I can try?
> 
> Oh, I am running Qubes 4.0.
> 
> Bill Bormann
> 

I'm confirming this bug. I'm also running Q4.0. It seems to me the
widget thinks at times that the VM is stuck, showing an endless
"loading" circle, and showing the logs and kill buttons, instead of the
shutdown button.

--
NaBaCo.

-- 
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/pc6ird%24ctf%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.


[qubes-users] HVM freeze during OS installation

2018-02-07 Thread NaBaCo
Hello,
I have attempted to install OSs in an HVM using several different ISOs,
and all have frozen during the start up in the same place.
I have tried to install Kali Linux, Fedora 27, Fedora 26, Fedora 26
using the NetInstaller.

All have frozen on the following line:
x86: Booting SMP configuration:

I am running Qubes OS 3.2, on Dell Inspirion 13 with Intel Core i5 7th Gen.

I have tried playing with the boot options of the installers, including
trying to run it in text only mode (inst.text) yet with the affect.

I am unsure what logs to send, so I'll send as needed/requested.

Thanks in advance for any help,
NaBaCo.

-- 
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/p5f5nu%24tak%241%40blaine.gmane.org.
For more options, visit https://groups.google.com/d/optout.