AW: [qubes-users] help, trying to make custom launchers

['[799]' via qubes-users]

pixel fairy wrote:

>> qubes 4.0rc3 Id like to make custom
>> launchers for two purposes [...]

Hello pixel fairy,

My suggestion is: don't spend time playing around tweaking custom . desktop 
files.
I have installed menulibre in dom0 and I am now able to tweak my menu through a 
comfortable GUI.

https://bluesabre.org/projects/menulibre/

As an additional benefit it is also very easy to hide menu items you don't need 
and you can reorder the menu.

qubes-dom0-update menulibre

If you want this additional comfort through installing additionall packages in 
dom0 is up to you - most users don't like to go this road.

You can also install menulibre by downloading the package manually.

Suggestion:
Having a default installation of menulibre in dom0 (through the Qubes Team)

Regards

[799]

-- 
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/PGMymgXLyYUSJebI-TWJ_PAgN1eBgntDq1t7Q_yL7ER3vGYeJFA_yVN8DR2ob4_w4LV0ENHfpzo106SJaDOpuNOaMXg_kmXWXDivVryNXrs%3D%40protonmail.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] help, trying to make custom launchers

[pixel fairy]

qubes 4.0rc3

Id like to make custom launchers for two purposes

1. easily run apps from custom dispvms. using shell scripts for now.

2. make alternate launchers with different icons. for example, the twitter bird 
icon in a twitter app-vm. 

tried making desktop files in ~/.local/share/applications, but they dont show 
up in menus. what else does one need to do?

-- 
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/3dd5f9d3-0a95-41db-853a-b75092983596%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] How to get to command line for dom0?

[Jean-Philippe Ouellet]

On Sat, Jan 20, 2018 at 3:46 PM, Kyle Breneman  wrote:
> I am trying to follow these steps to upgrade from Fedora 23 to Fedora 24
> (and then from 24 to 26), but I got stuck right away because I cannot figure
> out how to get to a command line window for dom0.  Can someone please tell
> me, or point to documentation which explains?  I've done several web
> searches without finding an answer.
>
> Kyle

Note that those directions are about upgrading *templates*, not dom0.
Dom0 should generally stay at the fedora release it started at,
otherwise you are asking for compatibility trouble.

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

Re: [qubes-users] Moving dom0 screenshots immediately to VMs

[Jean-Philippe Ouellet]

On Sat, Jan 20, 2018 at 4:51 AM, Alex Dubois  wrote:
> On Saturday, 20 January 2018 06:21:36 UTC, Jean-Philippe Ouellet  wrote:
>> On Fri, Jan 19, 2018 at 3:55 AM,   wrote:
>> > I've been working on a solution for this, but unfortunately there are too 
>> > many factors that I'm not familiar with.
>> >
>> > My goal is to to able to:
>> >
>> > 1) Take a screenshot using the dom0 hotkey
>> > 2) In the "Screenshot" dialogue, select a script from the "Open with:" 
>> > option
>> > 3) A text entry box that prompts me for the destination VM
>> > 4) The screenshot is sent to the indicated VM
>> >
>> > I think this can be accomplished with
>> >
>> > .desktop application file
>> > zenity
>> > qvm-move-to-vm/qvm-copy-to-vm/qvm-open-in-vm
>> >
>> > but I'm lost in the details.
>> >
>> > Current problems
>> >
>> > - I can't get dom0 to include my .desktop application files as "Open 
>> > with:" options in the "Screenshot" dialogue
>> > - I'm not sure what format the screenshot is in initially... will the 
>> > .desktop application receive a bunch of bits? Or the path to a temporary 
>> > file?
>> > - I can figure out how to pipe the screenshot if it's a file, but I don't 
>> > know how to handle a "bunch of bits" scenario
>> >
>> > Has anyone done this already? I'm aware of qvm-screenshot-tool.sh, which 
>> > looks great, but the code is too complicated for me to review and I just 
>> > need basic functionality anyway. 
>> > https://github.com/evadogstar/qvm-screenshot-tool/blob/master/qvm-screenshot-tool.sh
>>
>> This problem has already been solved, but upstreaming it was stalled
>> for some policy reasons. See here:
>> https://github.com/QubesOS/qubes-issues/issues/953
>>
>> My implementation can be found here:
>> https://github.com/jpouellet/qubes-screenshot-helper
>>
>> Regards,
>> Jean-Philippe
>
> Ah great. I like this implementation. Reviewing the code it does not seem to 
> introduce any risk and provide all the functionality required.
>
> Could you explain briefly the steps to install (after the git pull).
>
> May I also ask you for some help/pointer on a yubikey package I've done. I 
> just need to do the packaging and it may save me some time if you were to 
> give me few pointers...
>
> Project is here... the doc state that it is packages, but it is not (yet)...
> https://github.com/adubois/qubes-app-linux-yubikey
>
> Please reply in that thread if you want:
> https://groups.google.com/forum/#!topic/qubes-users/BkdTuXZZnwE

Set up qubes-builder [1], clone the repo into qubes-src subdir of
qubes-builder repo, then add:
COMPONENTS += your-component-name
to builder.conf, and `make your-component-name` from top level
qubes-builder dir.

Documentation on how to package your own things such that they plug
into the Qubes builder framework (via Makefile.builder) can be found
under doc/ in a checked out qubes-builder.

If you have further specific questions, feel free to ask on qubes-devel.

Regards,
Jean-Philippe

[1]: https://www.qubes-os.org/doc/qubes-builder/

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

Re: [qubes-users] Re: QSB #37: Information leaks due to processor speculative execution bugs (XSA-254, Meltdown & Sepctre)

[Jean-Philippe Ouellet]

On Thu, Jan 18, 2018 at 3:49 PM, Vít Šesták

wrote:
> On Thursday, January 18, 2018 at 7:00:42 PM UTC+1, Nik H wrote:
>> On Jan 16, 2018, at 2:56 AM, Vít Šesták <…@v6ak.com> wrote:
>> >
>> > * If an application does not mitigate Spectre and attacker finds useful 
>> > entry point, attacker can read memory of the application (but nothing 
>> > more).
>> > * If VM kernel does not mitigate Spectre and attacker finds useful entry 
>> > point, attacker can probably read memory of whole VM (but other VMs are 
>> > not affected).
>> > * If Xen does not mitigate Spectre and attacker finds useful entry point, 
>> > attacker can probably read memory of whole system.
>>
>> Can you explain why you think that Spectre can't escape the container (VM)? 
>> It seems that is the main issue, Spectre escapes the container.
>
> It depends on what you mean by VM escape. Sure, both Meltdown and Spectre are 
> about reading memory that should not be accessible. From your description 
> below, I believe you have confused those two.
>
> The reason why Spectre is much harder to actually exploit than Meltdown: For 
> Meltdown, you just use your own code to read the memory. With Spectre, you 
> have to use (and find!) a victim's code to perform innocently-looking 
> operations.
>
> Meltdown allows attacker to read any address in her address space. That's not 
> always whole physical address space, but in case of Xen PV x64 domains, it is 
> the case.
>
> Spectre allows to read the memory in a different way. Imagine the _victim_ 
> has code like this:
>
> if((i > 0) &&(i < a_length)) {
> return a[i];
> } else {
> return NULL; // or any other error code
> }
>
> This looks like a perfect code that prevents overreads and underreads. But an 
> attempt to overread/underread will affect cache. Fortunatelly, such simple 
> code is not much useful. The attacker rather needs something like this: 
> foo[bar[index]]. Even with all the proper bounds checks (that will cause the 
> code not to execute in traditional sense), attacker might try to perform 
> overflow/underflow by using index variable out of range. But CPU might try to 
> execute the branch speculatively (because the condition is usually 
> satisfied), which can cause a read of arbitrary out-of-bounds bar[index]. The 
> read of the value would be probably benign on its own, but then, it tries to 
> load data from foo array based on this value, which might cause cache fetch 
> depending on value of bar[index]. The attacker has not won yet, she has to 
> determine what part of memory was loaded into cache. This can be done using 
> timing attack.
>
> Another interesting part of Spectre is branch target injection. I remember 
> some double fetch vulnerability that can cause bad jump due to race condition 
> (TOCTOU issue). With Spectre, attacker can try to abuse this for bad 
> speculative jump even if there is no race condition possible.
>
> But my main point is that for Spectre attack, the fact that nobody has cared 
> about that when writing the software is not enough for successful 
> exploitation. Actually, one needs to find a suitable code that processes some 
> attacker's input in a suitable way. Moreover, the attacker needs some precise 
> measurement, so passing some malicious input to some queue in order to be 
> processed by code that can trigger speculative out-of-bounds read can be 
> impractical.
>
>> I read the whitepaper and what Spectre is doing is, it's accessing memory it 
>> should not have access to, and then uses a few simple tricks to extract the 
>> data it should not have access to. This happens on a processor level so any 
>> bounds checks that are outside the CPU core will not prevent that.
>
> That's true for both Spectre and Meltdown. But the fact that bounds checks 
> aren't enough does not mean that those attack cannot be mitigated in software 
> elsehow.
>
>> Given the nature of the attack, I do not think that hardware virtualization 
>> would stop this attack.
>
> If this is about Spectre, you are right, hardware virtualization does not 
> stop it on its own. For Meltdown, the situation is a bit different: Hardware 
> virtualization makes the VM not to have the address outside the VM mapped in 
> its address space. Trying to access the memory outside the VM is not 
> prevented by bounds check, it is prevented by the simple fact that they have 
> no address. Note that this AFAIU does not prevent attacking VM's kernel from 
> VM's process, it just prevents attacking hypervisor from VM.
>
>
>> I found various snippets of information hinting at this as well, but again, 
>> I'd be happy to be wrong! But, if I am right, then qubes isolation is 
>> compromised.
>
> Well, you are mostly right. But maybe we should divide it to base system 
> (e.g., Xen and dom0) and single VMs.
>
> The base system is unfortunately affected by Meltdown, because it mostly does 
> not use hardware 

[qubes-users] qubes 4.0, fedora-26 template, intermittent trouble opening an appvms file manager

[pixel fairy]

qubes 4.0 rc3 fedora-26 template

running the file manager from a menu will always start an appvm if its not 
running. but it wont always run the file manager. running terminal, or any 
other apps always works. running nautilus from terminal always works too. just 
not the file manager. but, sometimes, the file manager will work from the menu. 

-- 
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/68257294-7626-46d0-9920-232cc8cc78a6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: QSB #37: Information leaks due to processor speculative execution bugs (XSA-254, Meltdown & Sepctre)

[Vít Šesták]

On Thursday, January 18, 2018 at 2:06:08 AM UTC+1, Marek Marczykowski-Górecki 
wrote:
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> On Sun, Jan 14, 2018 at 03:24:04AM -0800, Vít Šesták wrote:
> > But it could be useful to use 32-bit stubdoms for those reasons. They do 
> > rather I/O-bound work (=> minimal performance penalty) and they don't need 
> > so much memory to utilize more than 32-bit pointers. (Also, using 32-bit 
> > pointers can make a minor performance gain.)
> > …
> > It is possible to use 32-bit stubdom on a 64-bit system?
> 
> That's interesting idea. Simon, what do you think about it?
> 


I've tried to implement this kind of protection and I'd like to report my 
failure achieve the result. Someone might be more successful. After all, I am 
not much experienced with Xen internals (I mostly configure Xen through Qubes). 
I've found there is a gzipped ELF with ioemu stubdom. Maybe replacing it with a 
32b one could do the trick. But I am not sure if it is enough, maybe this would 
just result in a 32-bit code running in 64-bit PV domain, which is not what we 
want. (I am not even sure how to check it.) I haven't found any relevant 
configuration where I could configure the stubdomain mode.

But I've decided to try to compile the stubdom and to try it. I've checked out 
the code and switched to 4.6.6 tag. The code looks promising, some parts seem 
to be ready for x86_32, despite the fact that it is no longer supported 
platform for Xen itself. I however have failed the compilation itself, 
regardless of the target architecture. I have tried debian-9. I needed few 
additional packages to pass ./configure, that's OK. (I won't name them, because 
you might miss different packages and because the error messages are pretty 
clear.) There seem to be some new warnings in GCC that make the compilation to 
fail, so I had to adjust tools/Rules.mk by adding line `CFLAGS += 
-Wno-misleading-indentation -Wno-unused-function`. This shifts me to another 
problem: command `./configure --enable-stubdom --disable-tools --disable-xen 
--disable-docs --host=x86_64 && make` results in the following error message I 
am unable to resolve:

…
make -C seabios-dir all
make[6]: Entering directory '/home/user/xen/tools/firmware/seabios-dir-remote'
  Compile checking out/src/stacks.o
src/stacks.c: Assembler messages:
src/stacks.c:635: Error: found '(', expected: ')'
src/stacks.c:635: Error: junk `(%ebp))' after expression
src/stacks.c:636: Warning: indirect call without `*'
…

Regards,
Vít Šesták 'v6ak'

-- 
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/72d9be30-473b-4840-a240-f29bea8a47ef%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: XFCE Settings menu gone

[haaber]

On 01/21/2018 07:47 AM, 'Tom Zander' via qubes-users wrote:
> On Saturday, 20 January 2018 23:25:55 CET Unman wrote:
>> You are probably missing the desktop files from /usr/share/applications
>> You can copy the files from out of a Fedora based qube if you have one.
> 
> Ohh, smart, I didn't think about that.
> 
> I did this to get the majority of them back;
> ```
> cd
> qvm-run -p sys-net 'tar cf - /usr/share/applications' | tar xvf -
> qvm-run -p sys-net 'tar cf - /usr/share/app-info/icons/fedora/' | tar xvf -
> 
> and then you can copy or move the files from $HOME/usr/share/
> into the system dir.
> I'll add the suggestion to double check they do what they are supposed to be 
> doing (check the Exec line).
Hello,
this arrived to me with Q3.2 and I recall that it was a real pain in the
b***; I start thinking I should backup these under Q4 from time to time
:) Question: Which files / dir's do I need to backup in  dom0?  Bernhard

-- 
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/5cfbf0c0-1e3f-a9da-fad0-79fbd3978ae7%40web.de.
For more options, visit https://groups.google.com/d/optout.

Re: [qubes-users] Re: XFCE Settings menu gone

['Tom Zander' via qubes-users]

On Saturday, 20 January 2018 23:25:55 CET Unman wrote:
> You are probably missing the desktop files from /usr/share/applications
> You can copy the files from out of a Fedora based qube if you have one.

Ohh, smart, I didn't think about that.

I did this to get the majority of them back;
```
cd
qvm-run -p sys-net 'tar cf - /usr/share/applications' | tar xvf -
qvm-run -p sys-net 'tar cf - /usr/share/app-info/icons/fedora/' | tar xvf -

and then you can copy or move the files from $HOME/usr/share/
into the system dir.
I'll add the suggestion to double check they do what they are supposed to be 
doing (check the Exec line).

-- 
Tom Zander
Blog: https://zander.github.io
Vlog: https://vimeo.com/channels/tomscryptochannel


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

[qubes-users] Re: [qubes-devel] Qubes Controller as the new Qubes-Manager

[Alex Dubois]

On Saturday, 6 January 2018 00:07:00 UTC, Tom Zander  wrote:
> On Friday, 5 January 2018 23:43:58 GMT Zrubi wrote:
> > > I'll attach two sceenshots of the tool, to give you a bit of an
> > > idea of what it already does and maybe if its worth your time to
> > > compile 
> > 
> > Probably this is very subjective, but:
> > For me, the most important parts/feature of the current Qubes Manager
> > are (in order of importance):
> > 
> > - Full overview of the state of the VMs in ONE screen, without clicking.
> > The new widget is failing on this badly, just as your proposal.
> 
> My aim has so far been to show which VMs are there, which type they are and 
> if they are running. This is visible in one go. Including even which VM has 
> a high CPU usage.
> I'm not happy yet with the way that the netVM is visualized, as you say it 
> costs clicks on each VM.
> 
> > - Changing the NetVM of a given VM.
> 
> Great idea!

Tom, Thanks for putting time into this. It will be greatly appreciated by many.
On that specific point, the disposable template could have the start icons with 
the program you want, and maybe a drop down for the netVM, or tab, or just for 
a given program you can select the netVM (i.e. firefox, tor (via whonix), 
openoffice (no netvm)...
>  
> > - Starting programs from a given VM.
> 
> Fully agreed, this is what I added last week. I'm using it all the time. 
> Much more convenient than the start menu.
> 
> > - start/stop VMs
> 
> Present :)
>  
> > - attaching/detaching devices.
> 
> Yes, definitely.
> 
> > - reading VM logs.
> 
> Good to know.
> 
> > Probably these are only my personal preferences. Hence I have no time
> > to write a new manager for the Qubes 4.x I just shared my use case.
> > Feel free to ignore them if you don't like 'em 
> 
> They are excellent ideas, thanks!

Not sure if feasible but:
- launch it with a shortcut key
- execute the task (i.e. select VM, select program to launch, or command to 
execute on that VM)
- minimize automatically on task execution (plus same shortcut if no action)

> -- 
> Tom Zander
> Blog: https://zander.github.io
> Vlog: https://vimeo.com/channels/tomscryptochannel

-- 
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/0b59f740-a1be-4dd2-b543-4a43766ce474%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[qubes-users] Re: Another "Best Hardware" 4 VMs setup question.

[pixel fairy]

On Saturday, January 20, 2018 at 10:51:54 AM UTC-8, Stumpy wrote:
> I have been reading through the forum about the various recommendations 
> for hardware. The general consensus seems to be "more mem and ssd 
> drive". I am running 3.2, have 16gb mem, and a Samsung ssd drive and it 
> still takes 10 sec (timed it) to put up a terminal in a new vm. While I 

i have much faster hardware, takes 11 seconds to start an appvm, and a new 
terminal in it. 16 gigs is the sweet spot for most average uses. 8 gigs is 
tight. 

> can tolerate that I'm really wanting to explore options that can give me 
> a faster start up for apps (and appvms). Its been awhile since I bought 
> my CPU so I can't remember what it is beyond a i5, if the /proc/cpuinfo 
> is right (its a bit confusing for me as I don't understand if its 
> showing the nfo for the proc or a virtual proc?) then I have a Intel 
> Core i5-4570 CPU @ 3.20GHz and it displays for processor 0 and processor 
> 1 so I will go out on a limb and assume its a dual core?

its a 4 core,4 thread. 
https://ark.intel.com/products/75043/Intel-Core-i5-4570-Processor-6M-Cache-up-to-3_60-GHz

this shows in /proc/cpuinfo in dom0 (qubes 4). appvms default to 2 virtual 
cpus. thats what your seeing.

> 
> Considering my current setup, and the fact that I wholly plan on 
> upgrading to qubes v4 once its stable, and that I am willing to fork out 
> for a new system (though with a pretty limited budget ~500) could anyone 
> make suggestions on the most logical route to take? (hopefully not "grin 
> and bear it").
> Cheers

wait till this speculative execution mess (meltdown, specter etc) is cleared up 
before choosing or buying new hardware. 

> PS I have 30 VMs BUT don't usually run more than 10 at a time (due to 
> mem i guess) but would probably run about 15 regularly if I could.

16 gigs of ram should be ok for that, but id go for 32.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To 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/23d4d86b-1ad5-4be0-960d-cc4027d0b4b6%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: AW: Re: [qubes-users] Using fedora-26-minimal sys-vms

[haaber]

On 01/20/2018 07:53 PM, '[799]' via qubes-users wrote:
> Hello,
> 
> --- --- --- 8< --- --- ---
> # Install default minimal template in dom0
> sudo qubes-dom0-update qubes-template-fedora-26-minimal
> 
> # Clone template to keep the original template
> qvm-clone fedora-26-minimal t-sys
> 
> # Launch xterm in the new template as root
> qvm-run -u root t-sys xterm
> 
> # Install basic applications in the template VM
> sudo dnf -y install gnome-terminal terminus-fonts less vim-minimal nano
> dejavu-sans-fonts
> 
> # install basic tools
> dnf -y install sudo pciutils psmisc gnome-keyring
> 
> # Install missing packages für Sys-VMs
> dnf -y install qubes-core-agent-qrexec qubes-core-agent-systemd
> qubes-core-agent-passwordless-root qubes-core-agent-nautilus
> qubes-core-agent-networking qubes-core-agent-network-manager
> qubes-core-agent-dom0-updates pulseaudio-qubes usbutils
> 
> # Install missing drivers (to support the network devices)
> dnf -y install linux-firmware iwl7260-firmware
> 
> # install additional packages to get network manager working
> dnf install -y NetworkManager NetworkManager-wifi network-manager-applet
> wireless-tools
> 
> # shutdown template
> shutdown -h now
> 
> # Change Templates for sys-VMs in dom0
> qvm-prefs --set sys-net template t-sys
> qvm-prefs --set sys-firewall template t-sys
> qvm-prefs --set sys-usb template t-sys
> --- --- --- 8< --- --- ---

Thank you! That is vey helpful. One point is missing to my pov: known
wirelesses in "old sys-net" before moving over. In my Q4rc4 sys-net
/etc/Networkmanager/system-connections is a symbolic link to
/rw/config/NM-system-connections  that contains one file per wireless.

When following your guide until the last dnf command that same dir
1) is not a symlink but a "hard" subdir
2) is (of course) empty


If the structure were the same I'd say a qvm-copy line is missing, but
actually I do not know what this symlink is good for. Can someone
explain this to me, Please?   Bernhard

-- 
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/9a543885-55b4-68a2-a4bd-f3baa35d9bdf%40web.de.
For more options, visit https://groups.google.com/d/optout.