[qubes-users] Security consideration

[Qubes]

I am curious to know other security experts thoughts on the following 
question.


For the sake of the argument the assumption is made that there will 
always be specialized applications that will need a dedicated template. 
Or to mitigate a specific security concern like the need to connect a 
template to the cloud there will be a dedicated template.


For everything else[1][2][3][4][5][6][7][8][9]...[30] however is there a 
security issue keeping everything in one template?


Other than less software means a smaller attack base. However, if for 
example an attacker uses an exploit in Firefox and compromises my appVM, 
will the fact that there is more code on the appVM equate to an even 
higher security risk. I don't think it does but i would like to know 
other opinions regarding this topic as well.


Also, a Firefox appVM wouldn't boot and run slower because it uses a 
template with 30 software packages install compared to a template that 
only has Firefox installed.


**A non-exhaustive list:**
[1] Gimp
[2] Firefox
[3] Thunderbird
[4] keepassxc
[5] Libreoffice
[6] Kodi
[7] VLC
[8] nomacs
[9] Krita
...
[30] Evince

--
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/8ff7cc3d-66ad-eb76-76c5-53583fe51f3f%40ak47.co.za.

Re: [qubes-users] Re: HCL - Lenovo X1 Carbon gen 10

[Martin Holst Swende]

On Sun, Aug 28, 2022, 1:26 AM Data Python 
wrote:

> You may want to keep your i915 driver and try:
> https://github.com/QubesOS/qubes-issues/issues/7507#issuecomment-1153081021


Interesting!

I tried it now, but unfortunately I encounter  a core dump, similar to one
person in that issue. However, I don't think I have any spelling errors,
and definitely no erroneous quote characters.

Cheers,
Martin

-- 
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/CANC2dUd7m1UGFw2dSge2sFMpuU2B_j6obtSEFu1ZGTPWWMnh8Q%40mail.gmail.com.

Re: [qubes-users] reduce font size in UI

[Franz]

On Tue, Aug 23, 2022 at 10:17 PM Andrew David Wong  wrote:

> On 8/22/22 5:42 PM, Franz wrote:
> > Hello,
> > in a higher resolution screen characters are too small in templates.
> > Nothing seems to work to increase the text size of the user interface,
> such
> > as the text in nautilus or bookmarks in firefox or brave-browser.
> >
> > I tried
> > QT_SCALE_FACTOR=1.34 application
> > and
> > gsettings set org.gnome.desktop.interface text-scaling-factor 1.5
> > No change whatsoever.
> >
> > The only one that works is dom0 using Appearance/fonts
> >
> > Is this problem related to the Qubes structure or is it just my
> inability?
> >
> > Any idea
> > Best
> > Franz
> >
>
> Have a look at this thread:
>
>
> https://forum.qubes-os.org/t/guide-xfce-global-dark-mode-in-qubes-4-0-4-1/10757
>
> While the thread is mainly about apply dark themes, I've found that the
> font changes also apply inside of templates. For example, following the
> instructions resulted in a bigger font size in Nautilus.
>
> As for web browsers, you might have to adjust that in the browser's
> settings.
>

Many thanks Andrew,

I followed the instructions of your thread and everything went dark, which
is nice, but font size remained the same even if I changed all reported
settings from 12 to 16.

Best
Franz

-- 
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/CAPzH-qCGQEWbrAmZQ83uE2wn2omr%3DmgWETReb%3DfExEDA7PSYaA%40mail.gmail.com.

Re: [qubes-users] Re: HCL - Lenovo X1 Carbon gen 10

[Data Python]

You may want to keep your i915 driver and try: 
https://github.com/QubesOS/qubes-issues/issues/7507#issuecomment-1153081021

On Monday, August 15, 2022 at 8:46:28 PM UTC+2 martin...@gmail.com wrote:

> To follow up after a bit more experimentation.
>
> - Using the boot param 'module_blacklist=i915' makes things work pretty 
> much ok. No obvious graphics glitches, it's able to play videos without 
> the fans spinning up like crazy.
>
> - The PCI device for networking seems unsupported, so usb-wifi card is 
> needed to get networking working.
>
> - I get no sounds. Pavucontrol lists "Dummy Output" as the only 
> available output device, so I guess the PCI device for sound is also not 
> supported. (My old laptop has "Built-in Audio Analog Stereo" output 
> device in pavucontrol).
>
> - I did not get the whole sys-gui-gpu thing to work sufficiently to test 
> it, not sure if there's anything left to explore in that area. Mostly I 
> think a more recent kernel is the thing that will eventually solve this.
>
> Cheers,
>
> Martin
>
> On 8/10/22 20:14, Demi Marie Obenour wrote:
> > On Wed, Aug 10, 2022 at 08:36:33AM +0200, Martin Holst Swende wrote:
> >
> > > On 8/10/22 05:10, Demi Marie Obenour wrote:
> > >> On Tue, Aug 09, 2022 at 08:11:35PM +0200, Martin Holst Swende wrote:
> > >>> Some follow-up. I tested also with a Fedora LiveCD, results are on 
> the
> > >> gist 
> > (here:
> https://gist.github.com/holiman/83c76e4cd98d087719773486a77d9112#file-fedora-live-txt
> > >>> ) .
> > >>
> > >>> The Fedora livecd worked flawlessly, both wifi-wise and 
> graphics-wise.
> > >> It
> > >>> was a fedora 36 -- whereas dom0 is still on Fedora32.
> > >>
> > >>> Is it in any way possible to try out some experimental repo where 
> dom0
> > >> is
> > >>> more recent?
> > >>
> > >> No, but I would like to know if your problems go away with
> > >> kernel-latest.  If they do not, then this means that either Xen 
> > does not
> > >> interact well with Linux’s graphics drivers, or that the Mesa 
> > version is
> > >> too old for your hardware.
> >
> >
> > > Unfortunately, they do not. I did that as the first thing after 
> > getting wifi
> > > to work, so the version 5.18.9-1 in the HCL, is kernel-latest.
> >
> > > Happy to try out any suggestion/experiment.
> >
> > 1. Does i915.enable_psr2_sel_fetch=0 help?
> > 2. What X11 driver is Xorg using?  If it is using Intel, does
> >modesetting help?  If it is using modesetting, does Intel help?
> > 3. Does HVM sys-gui-gpu work?  What about PV (not PVH!) sys-gui-gpu?
> >
> > If PV sys-gui-gpu with a dom0-provided kernel works, then the problem is
> > almost certainly old dom0 userspace: either an old X server, old Mesa,
> > or both.  If you could build modern Mesa and/or X11 for dom0 and try
> > again, that would be awesome.
>
>

-- 
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/7305ea96-7044-453e-87bf-5e2ad39d6ba2n%40googlegroups.com.

Re: [qubes-users] firefox-esr and brave-browser work, but firefox, nautilus, thunar, gnome-terminal, xterm do not

[Franz]

> > I prefer the simplicity and reliability of this type of command:
> >
> > qvm-run --dispvm=debian-11-dvm 
> >
> > E.g.:
> >
> > qvm-run --dispvm=debian-11-dvm nautilus
> >
>
>
yes  thanks this works


> In Debian, the desktop file is firefox-esr.desktop. The application is
> available using either firefox or firefox-esr.
> When you use the --service form of qvm-run it references the desktop
> files, as Andrew said.(The Debian package is also called firefox-esr,
> and `firefox` is a shell script that calls `firefox-esr`)
>
> In Debian, the desktop file for xterm is `debian-xterm.desktop`, so that's
> how you
> must address it if you use the --service form.
> Nautilus is org.gnome.Nautilus.Desktop etc.
>

Interesting,

Many thanks, my friends

-- 
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/CAPzH-qDxUX57tDdpQpdPUBny9HL3nVHNZkBMNRTuPQkmHo70Bg%40mail.gmail.com.

[qubes-users] Convert to UEFI from legacy

[MUT]

I dont remember the details of how i installed qubes, but I think it ended 
up installing in legacy mode on my uefi system.

My esp/EFI/qubes contains only :
- fonts
- grub.cfg
- grubx64.efi
- xen-4.14.3.efi
- xen-4.14.5.efi
- xen.efi

I am missing the xen.cfg if i understand correctly, so when i try to load 
xen.efi (through refind or whatnot) i get the respective "Not found" error.

My /boot however contains: 
- config-...
- efi
- grub2
- initramfs-...
- loader
- symvers-...
- System.map-...
- vmlinuz-...
- xen-4.14.5.config
- xen-4.14.5.gz

>From what i understand i need to generate the xen.cfg, and transfer some 
things from /boot/ to esp/EFI/qubes(initramfs, vmlinuz and maybe others). 
But i wanna know how to do it properly so that future updates update 
initramfs/vmlinuz, xen.cfg properly.

-- 
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/74cdce08-7448-43ae-8f2e-ba474b431857n%40googlegroups.com.

Re: [qubes-users] firefox-esr and brave-browser work, but firefox, nautilus, thunar, gnome-terminal, xterm do not

['unman' via qubes-users]

On Wed, Aug 24, 2022 at 07:12:45PM -0700, Andrew David Wong wrote:
> On 8/24/22 2:31 PM, Franz wrote:
> > Hello,
> > the following command is intended to run an application in a new DVM:
> > 
> > qvm-run --dispvm=debian-11-dvm --service qubes.StartApp+
> > 
> > If in place of  I put firefox-esr or brave-browser it works, the
> > new DVM is opened and the application works as expected.
> > 
> > But if in place of  I put firefox, nautilus, thunar,
> > gnome-terminal, xterm the DVM starts, but immediately after closes with
> > error:
> > command failed with code:1
> > 
> > Any idea to solve it or is it just a bug?
> > 
> > 
> > 
> > firefox-esr and brave-browser work, but firefox, nautilus, thunar,
> > gnome-terminal, xterm do not
> > 
> 
> You might be missing .desktop files or something for the ones that aren't 
> working. That seems to be a common problem.
> 
> I prefer the simplicity and reliability of this type of command:
> 
> qvm-run --dispvm=debian-11-dvm 
> 
> E.g.:
> 
> qvm-run --dispvm=debian-11-dvm nautilus
> 

In Debian, the desktop file is firefox-esr.desktop. The application is
available using either firefox or firefox-esr.
When you use the --service form of qvm-run it references the desktop
files, as Andrew said.(The Debian package is also called firefox-esr,
and `firefox` is a shell script that calls `firefox-esr`)

In Debian, the desktop file for xterm is `debian-xterm.desktop`, so that's how 
you
must address it if you use the --service form.
Nautilus is org.gnome.Nautilus.Desktop etc.

Some of the examples you gave have a different root cause, because of
the way that those applications work. For example, gnome-terminal will
call the gnome-terminal server and spawn an instance of the terminal.
Because of the way that disposables work, when that first call completes,
the disposable shuts down, so you never see a terminal window.
Qubes provides qubes-run-gnome-terminal to help with this.

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

Re: [qubes-users] firefox-esr and brave-browser work, but firefox, nautilus, thunar, gnome-terminal, xterm do not

[Andrew David Wong]

On 8/24/22 2:31 PM, Franz wrote:
> Hello,
> the following command is intended to run an application in a new DVM:
> 
> qvm-run --dispvm=debian-11-dvm --service qubes.StartApp+
> 
> If in place of  I put firefox-esr or brave-browser it works, the
> new DVM is opened and the application works as expected.
> 
> But if in place of  I put firefox, nautilus, thunar,
> gnome-terminal, xterm the DVM starts, but immediately after closes with
> error:
> command failed with code:1
> 
> Any idea to solve it or is it just a bug?
> 
> 
> 
> firefox-esr and brave-browser work, but firefox, nautilus, thunar,
> gnome-terminal, xterm do not
> 

You might be missing .desktop files or something for the ones that aren't 
working. That seems to be a common problem.

I prefer the simplicity and reliability of this type of command:

qvm-run --dispvm=debian-11-dvm 

E.g.:

qvm-run --dispvm=debian-11-dvm nautilus

-- 
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/1d7b3b68-bf08-c9fb-ecc2-6cb9ba9034af%40qubes-os.org.

[qubes-users] firefox-esr and brave-browser work, but firefox, nautilus, thunar, gnome-terminal, xterm do not

[Franz]

Hello,
the following command is intended to run an application in a new DVM:

qvm-run --dispvm=debian-11-dvm --service qubes.StartApp+

If in place of  I put firefox-esr or brave-browser it works, the
new DVM is opened and the application works as expected.

But if in place of  I put firefox, nautilus, thunar,
gnome-terminal, xterm the DVM starts, but immediately after closes with
error:
command failed with code:1

Any idea to solve it or is it just a bug?



firefox-esr and brave-browser work, but firefox, nautilus, thunar,
gnome-terminal, xterm do not

-- 
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/CAPzH-qBROyiSQ%3D1_L8CmSYbebuomS_4PTF9kpxBX%3DycK3ws3LQ%40mail.gmail.com.

Re: [qubes-users] reduce font size in UI

[Andrew David Wong]

On 8/22/22 5:42 PM, Franz wrote:
> Hello,
> in a higher resolution screen characters are too small in templates.
> Nothing seems to work to increase the text size of the user interface, such
> as the text in nautilus or bookmarks in firefox or brave-browser.
> 
> I tried
> QT_SCALE_FACTOR=1.34 application
> and
> gsettings set org.gnome.desktop.interface text-scaling-factor 1.5
> No change whatsoever.
> 
> The only one that works is dom0 using Appearance/fonts
> 
> Is this problem related to the Qubes structure or is it just my inability?
> 
> Any idea
> Best
> Franz
> 

Have a look at this thread:

https://forum.qubes-os.org/t/guide-xfce-global-dark-mode-in-qubes-4-0-4-1/10757

While the thread is mainly about apply dark themes, I've found that the font 
changes also apply inside of templates. For example, following the instructions 
resulted in a bigger font size in Nautilus.

As for web browsers, you might have to adjust that in the browser's settings.

-- 
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/0adc45ec-ff97-a57b-124f-a7fa7f8b0769%40qubes-os.org.

[qubes-users] reduce font size in UI

[Franz]

Hello,
in a higher resolution screen characters are too small in templates.
Nothing seems to work to increase the text size of the user interface, such
as the text in nautilus or bookmarks in firefox or brave-browser.

I tried
QT_SCALE_FACTOR=1.34 application
and
gsettings set org.gnome.desktop.interface text-scaling-factor 1.5
No change whatsoever.

The only one that works is dom0 using Appearance/fonts

Is this problem related to the Qubes structure or is it just my inability?

Any idea
Best
Franz

-- 
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/CAPzH-qB-%2B8LBMqvg%3DOOkzuHe4ixmtCuijXZNon_fb4%3DUpRsGhg%40mail.gmail.com.

Re: [qubes-users] Qubes Contrib repository

[Andrew David Wong]

On 8/21/22 8:25 AM, Steve Coleman wrote:
> On Sun, Aug 21, 2022 at 10:29 AM 'unman' via qubes-users <
> qubes-users@googlegroups.com> wrote:
> 
>> On Sat, Aug 13, 2022 at 10:02:15PM +0200, Qubes wrote:
>>
>> qubes-dom0-update --repo=qubes-contrib-dom0-r4.1-current --action=list
>>
> Q1: Is there any way to list these in a way that can actually be copied to
> the clipboard from the sys-firewall xterm?
> 
> Using ctrl-c to copy something just closes the window and there is no menu
> bar for a copy/paste operation.
> 
> Q2: Is there a configuration to get sys-firewall add the menu bar back to
> this dynamically opened xterm?
> 
> On my system this command lists the packages in a completely unreadable
> color, which is why I wanted to copy it, so I could then paste it into
> something that would strip the awful color from the list so I could
> actually read it. I'm assuming there is a terminal configuration that
> controls these default window attributes?
> 
> Q3: Or change the color for this xterm so I can actually read what I need
> to type into the next command, if I found something I wanted to install?
> 
> A way to enlarge the width of the terminal to prevent the text from
> wrapping around would also be a help.
> 
> thanks!
> 

All of those aspects of XTerm are configurable and are not Qubes-specific. You 
can simply search the web for "how to customize XTerm" to find many good guides 
that explain how to do all of this.

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/efe0a56f-77ac-8762-90cf-1ac912aab7a2%40qubes-os.org.

Re: [qubes-users] Qubes Contrib repository

[Steve Coleman]

On Sun, Aug 21, 2022 at 10:29 AM 'unman' via qubes-users <
qubes-users@googlegroups.com> wrote:

> On Sat, Aug 13, 2022 at 10:02:15PM +0200, Qubes wrote:
>
> qubes-dom0-update --repo=qubes-contrib-dom0-r4.1-current --action=list
>
Q1: Is there any way to list these in a way that can actually be copied to
the clipboard from the sys-firewall xterm?

Using ctrl-c to copy something just closes the window and there is no menu
bar for a copy/paste operation.

Q2: Is there a configuration to get sys-firewall add the menu bar back to
this dynamically opened xterm?

On my system this command lists the packages in a completely unreadable
color, which is why I wanted to copy it, so I could then paste it into
something that would strip the awful color from the list so I could
actually read it. I'm assuming there is a terminal configuration that
controls these default window attributes?

Q3: Or change the color for this xterm so I can actually read what I need
to type into the next command, if I found something I wanted to install?

A way to enlarge the width of the terminal to prevent the text from
wrapping around would also be a help.

thanks!

-- 
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/CAJ5FDnir-GW51KZjo%2BhacKudWE3%3D84GuTvYjx_v9p8%3DRdg7Oqw%40mail.gmail.com.

Re: [qubes-users] Qubes Contrib repository

['unman' via qubes-users]

On Sat, Aug 13, 2022 at 10:02:15PM +0200, Qubes wrote:
> Qubes wrote:
> > I guess one way to see what is available in the contrib repo is to look
> > on [Github][1], but is there a way to list the available packages in the
> > contrib repo from cli?
> > 
> > Assuming that one has already added the contrib repo,
> > 
> > ```
> >  sudo qubes-dom0-update qubes-repo-contrib
> > ```
> > 
> > [1]: (https://github.com/QubesOS/qubes-issues/issues/7389)
> > 
> Oops, wrong URL provided,
> 
> 
> [1]: https://github.com/QubesOS-contrib
> 

qubes-dom0-update --repo=qubes-contrib-dom0-r4.1-current --action=list

-- 
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/YwJBU2L0YStzrudJ%40thirdeyesecurity.org.

Re: [qubes-users] Coreboot: Security for external monitor

[airelemental via qubes-users]

Aug 14, 2022, 7:46 PM by 169...@gmail.com:

> Hello friends,
>
> Laptop w520 thinkpad corebooted.
>
> I would like to be able to use an external monitor connected by the 
> displayport.
>
> This coreboot tutorial > https://www.coreboot.org/Board:lenovo/w520
> suggest to run the following command:
>
> sudo ./util/nvramtool/nvramtool -w hybrid_graphics_mode="Dual Graphics"
>
> I tried it in dom0, but nvramtool is not installed, so this starts alarming. 
> Looking for a way to install it found the following for Fedora:
>

You can get it from your coreboot build:
$ cd coreboot/util/nvramtool
$ make
then copy the resulting binary to dom0 in the usual way.

-- 
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/N9iEJNt--3-2%40tutanota.com.

Re: [qubes-users] Printing

[Eric W. Biederman]

Qubes  writes:

> Does anybody know which directory(ies) and or file(s) need to binded with
> bind-dirs so that i don't have to add the printer i am using in my template? I
> would like to add the printer in my VM but i need to bind the directory(ies) 
> and
> or file(s) in /rw so that my configuration sticks.

A change to /etc/cups/printers.conf is all I need to change to configure
a printer.

The file is automatically rewritten so you might need to copy in all of
/etc/cups into /rw and bind it in there.  I haven't played with that.

Eric

-- 
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/87tu6a60px.fsf%40email.froward.int.ebiederm.org.

[qubes-users] Printing

[Qubes]

Does anybody know which directory(ies) and or file(s) need to binded 
with bind-dirs so that i don't have to add the printer i am using in my 
template? I would like to add the printer in my VM but i need to bind 
the directory(ies) and or file(s) in /rw so that my configuration sticks.


--
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/1a7749c2--01ca-b128-5666f341b98c%40ak47.co.za.

Re: [qubes-users] Re: HCL - Lenovo X1 Carbon gen 10

[Martin Holst Swende]

To follow up after a bit more experimentation.

- Using the boot param 'module_blacklist=i915' makes things work pretty 
much ok. No obvious graphics glitches, it's able to play videos without 
the fans spinning up like crazy.


- The PCI device for networking seems unsupported, so usb-wifi card is 
needed to get networking working.


- I get no sounds. Pavucontrol lists "Dummy Output" as the only 
available output device, so I guess the PCI device for sound is also not 
supported. (My old laptop has "Built-in Audio Analog Stereo" output 
device in pavucontrol).


- I did not get the whole sys-gui-gpu thing to work sufficiently to test 
it, not sure if there's anything left to explore in that area. Mostly I 
think a more recent kernel is the thing that will eventually solve this.


Cheers,

Martin

On 8/10/22 20:14, Demi Marie Obenour wrote:

On Wed, Aug 10, 2022 at 08:36:33AM +0200, Martin Holst Swende wrote:

> On 8/10/22 05:10, Demi Marie Obenour wrote:
>> On Tue, Aug 09, 2022 at 08:11:35PM +0200, Martin Holst Swende wrote:
>>> Some follow-up. I tested also with a Fedora LiveCD, results are on the
>> gist 
(here:https://gist.github.com/holiman/83c76e4cd98d087719773486a77d9112#file-fedora-live-txt

>>> ) .
>>
>>> The Fedora livecd worked flawlessly, both wifi-wise and graphics-wise.
>> It
>>> was a fedora 36 -- whereas dom0 is still on Fedora32.
>>
>>> Is it in any way possible to try out some experimental repo where dom0
>> is
>>> more recent?
>>
>> No, but I would like to know if your problems go away with
>> kernel-latest.  If they do not, then this means that either Xen 
does not
>> interact well with Linux’s graphics drivers, or that the Mesa 
version is

>> too old for your hardware.


> Unfortunately, they do not. I did that as the first thing after 
getting wifi

> to work, so the version 5.18.9-1 in the HCL, is kernel-latest.

> Happy to try out any suggestion/experiment.

1. Does i915.enable_psr2_sel_fetch=0 help?
2. What X11 driver is Xorg using?  If it is using Intel, does
   modesetting help?  If it is using modesetting, does Intel help?
3. Does HVM sys-gui-gpu work?  What about PV (not PVH!) sys-gui-gpu?

If PV sys-gui-gpu with a dom0-provided kernel works, then the problem is
almost certainly old dom0 userspace: either an old X server, old Mesa,
or both.  If you could build modern Mesa and/or X11 for dom0 and try
again, that would be awesome.


--
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/2f521835-fa9c-ddd8-017f-7c36f160b9e0%40gmail.com.

Re: [qubes-users] Missing data after Qubes restore from backup

[Andrew David Wong]

On 8/14/22 8:36 AM, 'Crsi' via qubes-users wrote:
> I also checked "verify backup" -- no error reported.

Just to clarify, the "verify only" option simulates a restore operation without 
actually writing any data from the backup to disk. This has two implications:

1. This option is not at all applicable when *creating* a backup (and should 
not even appear as an option there). [There's an open issue for a "create a 
backup, then verify it" feature, but it hasn't been implemented yet: 
https://github.com/QubesOS/qubes-issues/issues/1454]

2. Enabling this option when restoring will tell you that it was successful (if 
the simulation was successful), but no data on disk will change. This means, 
for example, that restoring from an older backup first, then restoring from a 
newer backup with "verify only" enabled, will result in the older VMs still 
being the ones on your disk.

-- 
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/3a85507f-bc0c-aa0a-fc0d-afa612f1d7f6%40qubes-os.org.

[qubes-users] Coreboot: Security for external monitor

[Franz]

Hello friends,

Laptop w520 thinkpad corebooted.

I would like to be able to use an external monitor connected by the
displayport.

This coreboot tutorial https://www.coreboot.org/Board:lenovo/w520
suggest to run the following command:

sudo ./util/nvramtool/nvramtool -w hybrid_graphics_mode="Dual Graphics"

I tried it in dom0, but nvramtool is not installed, so this starts
alarming. Looking for a way to install it found the following for Fedora:

sudo dnf copr enable starlabs/coreboot-configurator
sudo dnf install coreboot-configurator nvramtool

https://support.starlabs.systems/kb/guides/coreboot-configurator
https://starlabs.systems/

But here I doubt if it is worth going forward. First I do not know this
Starlabs contributor. Do you know if they can be trusted? Second, even
admitting to trust them how may I translate this "copr enable" into Qubes
parlance, such as: something like:
sudo qubes-dom0-update copr enable starlabs/coreboot-configurator

Best
Franz

-- 
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/CAPzH-qDNpu2q21fnBf5o%3DtHsYEn5fv0uLy2aKn%3DfNpWo5ekUvw%40mail.gmail.com.

Re: [qubes-users] Missing data after Qubes restore from backup

[Rusty Bird]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

Crsi:
> However, I made sure no VM was running (my host system
> crashed previously anyways). That means there's a difference between
> powering down a VM (e.g. qvm-shutdown) and having a powered down VM due to
> crash / power loss? Am I right that the backup tool uses the LV
> `vm--private` for backup only, but my data was in
> `vm--private-snap`?

Spot on. That was the situation in R4.0.

> Then, what about showing a warning that there exists a snap of a VM in the
> qubes-backup utility (at the same place where "The VM is running, backup
> will contain its state from before its start!" is shown as well), even if a
> VM is not running currently? That would have definitively saved me.

I know it doesn't help you anymore, but R4.1 avoids the whole problem
by cleanly stopping crashed volumes when the computer is restarted:

https://github.com/QubesOS/qubes-core-admin/pull/397

Rusty
-BEGIN PGP SIGNATURE-

iQKTBAEBCgB9FiEEhLWbz8YrEp/hsG0ERp149HqvKt8FAmL5IwNfFIAALgAo
aXNzdWVyLWZwckBub3RhdGlvbnMub3BlbnBncC5maWZ0aGhvcnNlbWFuLm5ldDg0
QjU5QkNGQzYyQjEyOUZFMUIwNkQwNDQ2OUQ3OEY0N0FBRjJBREYACgkQRp149Hqv
Kt+itA/+JGWiBR8lvKB3usGW96cI8ty4BePclBivLLxN6zeC0KpAxZK14QywIgOL
o0tguMM/H4Fc+F0ueRQymYCskzo/BWJlU06Fq9Bwp+re0p6Y6o0bzmx35e/mj8mb
CrMWqboqEjFihpxGxvk5BR8PceUTWvxFGNYGPZZQejNbanbkFeTINUXzMNR/dMjX
V0cIneqQtWcsJXBEBwS8KtMh+uHgumqgG+UcdymUuBU/FvwgrmOfOTSFrW/jgNEe
MImex5y9im/xrQ4RSDCJVc+FJNvq9HGGePFccrVo9tnJ3WY4khuYEckSe2wIL/5y
8TKHe5pQMTUSCbIqGNIFBWF5cFDw3zOPXPQGDx7HMruJNTtOJXa7RzO4qgdV6rcj
KMQeWVwKyZ2KyTYqJMY7M87c8IL9DFLmzZuGIQ/yTsw40uNoMdPpNTPgdGBTO0UB
hIqvf8DL9OBbUnXOLmgVtMLp4UjNxV+6Kf2k5Qk+NZxahMblUlezHXj3B0UeLmML
HcGW5N8ln+tUIcFHcrRNqZ6uf5CoWKZ47vNpedlLKHz2mXs2U6maFqg168A8tnAM
iL/bRAit1rctIyX9R/kSvcebetQRIrY7Sci4GjlNTwcCKpXehedm7D87jgA2gIS0
Sv4eXSUPPliDZiVGp0y1utywDZVdWzu9LyS6tUrG+hnaQCB4E3o=
=h1CV
-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/YvkjBCPJK4UxzNXa%40mutt.

Re: [qubes-users] Missing data after Qubes restore from backup

['Crsi' via qubes-users]

On 8/14/22 18:09, Qubes wrote:
Doing a gracefull shutdown or the VM crashing AFAIK is the same in 
terms of the backup function as we have discussed. If your VM crashed 
the state of the data on disk would still be the same compared to 
gracefully shutting down the VM.


My VM didn't crash -- the host system did. Therefore, I suspect the 
volume `vm--private` was never updated with the content of 
`vm--private-snap`, which probably occurs only on graceful VM 
shutdown (or on VM crash, but then the host system cleans things up and 
moves it correctly). If the host crashed, then this clean-up didn't take 
place. What a bad situation, indeed.





Do you still have access to the old system to re-do the backup? 
Alternatively if you still have access to the old system you could 
manually mount the private volume of the VM and copy the data across.



Sadly, I have no access to my old drive anymore as I pointed out earlier.

--
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/4fccf43c-98dd-f116-9ae4-b92b8cf457b4%40hopfen.space.

Re: [qubes-users] Missing data after Qubes restore from backup

[Qubes]

'Crsi' via qubes-users wrote:
 > Do you often reboot your VMs? When Qubes creates a backup of a 
running VM it will do the backup using the VM state at startup. So if 
for example you started your VM (the ones with the outdated/missing 
data) 6 weeks ago, but since starting you added/edited/deleted data and 
you create a backup, without restarting the VM, the backup will not 
include those changes.



Apparently, no. However, I made sure no VM was running (my host system 
crashed previously anyways). That means there's a difference between 
powering down a VM (e.g. qvm-shutdown) and having a powered down VM due 
to crash / power loss? Am I right that the backup tool uses the LV 


Doing a gracefull shutdown or the VM crashing AFAIK is the same in terms 
of the backup function as we have discussed. If your VM crashed the 
state of the data on disk would still be the same compared to gracefully 
shutting down the VM.


Do you still have access to the old system to re-do the backup? 
Alternatively if you still have access to the old system you could 
manually mount the private volume of the VM and copy the data across.


`vm--private` for backup only, but my data was in 
`vm--private-snap`?


Then, what about showing a warning that there exists a snap of a VM in 
the qubes-backup utility (at the same place where "The VM is running, 
backup will contain its state from before its start!" is shown as well), 
even if a VM is not running currently? That would have definitively 
saved me.




--
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/e947747c-06cf-2920-2c80-2caad6b87d4d%40ak47.co.za.

Re: [qubes-users] Missing data after Qubes restore from backup

['Crsi' via qubes-users]

> Do you often reboot your VMs? When Qubes creates a backup of a 
running VM it will do the backup using the VM state at startup. So if 
for example you started your VM (the ones with the outdated/missing 
data) 6 weeks ago, but since starting you added/edited/deleted data and 
you create a backup, without restarting the VM, the backup will not 
include those changes.



Apparently, no. However, I made sure no VM was running (my host system 
crashed previously anyways). That means there's a difference between 
powering down a VM (e.g. qvm-shutdown) and having a powered down VM due 
to crash / power loss? Am I right that the backup tool uses the LV 
`vm--private` for backup only, but my data was in 
`vm--private-snap`?


Then, what about showing a warning that there exists a snap of a VM in 
the qubes-backup utility (at the same place where "The VM is running, 
backup will contain its state from before its start!" is shown as well), 
even if a VM is not running currently? That would have definitively 
saved me.


--
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/7ea76764-d1c8-7bd1-aad0-05394501e148%40hopfen.space.

Re: [qubes-users] Missing data after Qubes restore from backup

[Qubes]

'Crsi' via qubes-users wrote:

Hi,

I recently upgraded from R4.0 to R4.1 with a fresh installation.
I did make a backup of all my important Qubes to an external drive 
beforehand and everything completed successfully. I also checked "verify 
backup" -- no error reported.




Do you often reboot your VMs? When Qubes creates a backup of a running 
VM it will do the backup using the VM state at startup. So if for 
example you started your VM (the ones with the outdated/missing data) 6 
weeks ago, but since starting you added/edited/deleted data and you 
create a backup, without restarting the VM, the backup will not include 
those changes.




On the new installation, I restored all my Qubes from the backup.
When starting to work with them again, I noticed that some data was 
apparently missing from some (not all!) of the Qubes. It turned out that 
in two of the restored VMs all data of the last six weeks (!) was 
completely missing. It looked like the VM had a state like from my last 
full VM backup using the backup utility (which was exactly that six 
weeks ago).


I tried restoring the VM again -- but same result. Searching for some 
issue like that only gave me [Issue #3498]. Apparently I was hit by the 
"flaw" that the verification doesn't detect missing data.


I guess I have no chance to restore my data whatsoever, since the old 
drive was wiped. Anyhow, just posting this: does someone has a clue 
*why* that could have happened? I don't want anyone to loose their work 
of six weeks, too.




[Issue #3498]: https://github.com/QubesOS/qubes-issues/issues/3498



--
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/918289f3-1852-5433-8a74-30ab75ff022c%40ak47.co.za.

[qubes-users] Missing data after Qubes restore from backup

['Crsi' via qubes-users]

Hi,

I recently upgraded from R4.0 to R4.1 with a fresh installation.
I did make a backup of all my important Qubes to an external drive 
beforehand and everything completed successfully. I also checked "verify 
backup" -- no error reported.


On the new installation, I restored all my Qubes from the backup.
When starting to work with them again, I noticed that some data was 
apparently missing from some (not all!) of the Qubes. It turned out that 
in two of the restored VMs all data of the last six weeks (!) was 
completely missing. It looked like the VM had a state like from my last 
full VM backup using the backup utility (which was exactly that six 
weeks ago).


I tried restoring the VM again -- but same result. Searching for some 
issue like that only gave me [Issue #3498]. Apparently I was hit by the 
"flaw" that the verification doesn't detect missing data.


I guess I have no chance to restore my data whatsoever, since the old 
drive was wiped. Anyhow, just posting this: does someone has a clue 
*why* that could have happened? I don't want anyone to loose their work 
of six weeks, too.




[Issue #3498]: https://github.com/QubesOS/qubes-issues/issues/3498

--
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/ce593c3c-fa26-529c-ab09-25660ad7d597%40hopfen.space.

Re: [qubes-users] Qubes Contrib repository

[Qubes]

Qubes wrote:
I guess one way to see what is available in the contrib repo is to look 
on [Github][1], but is there a way to list the available packages in the 
contrib repo from cli?


Assuming that one has already added the contrib repo,

```
 sudo qubes-dom0-update qubes-repo-contrib
```

[1]: (https://github.com/QubesOS/qubes-issues/issues/7389)


Oops, wrong URL provided,


[1]: https://github.com/QubesOS-contrib

--
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/a93bdcf7-7d73-944b-d7b2-42d13dd8f4b0%40ak47.co.za.

[qubes-users] Qubes Contrib repository

[Qubes]

I guess one way to see what is available in the contrib repo is to look 
on [Github][1], but is there a way to list the available packages in the 
contrib repo from cli?


Assuming that one has already added the contrib repo,

```
sudo qubes-dom0-update qubes-repo-contrib
```

[1]: (https://github.com/QubesOS/qubes-issues/issues/7389)

--
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/1a1ee7ef-6333-446b-f579-00d211b4888c%40ak47.co.za.

Re: [qubes-users] Qube-Firewall: How to handle changing IPs?

[David Hobach]

I mentioned DNS pinning in the very end and posted a working solution there as 
well.
I personally use it since about back then.

--
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/f99c46ba-09d2-f811-80be-63530900943c%40hackingthe.net.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [qubes-users] Re: HCL - Lenovo X1 Carbon gen 10

[Martin Holst Swende]

On Thu, Aug 11, 2022, 3:10 PM Martin Holst Swende 
wrote:

>
> On 8/11/22 11:38, Demi Marie Obenour wrote:
>
> 3. Does HVM sys-gui-gpu work?  What about PV (not PVH!) sys-gui-gpu?
>
> I don't have a sys-gui-gpu at the moment, but will test that. This page
> (https://www.qubes-os.org/doc/guivm-configuration/) is still the most
> relevant/recent description, right?
>
> I think so?  I don’t use sys-gui-gpu myself, and I will admit that there
> are quite a few bugs when using it.  Still, if it works, then the
> possible parts of the code that could be to blame is much lower. If
> sys-gui-gpu in PV mode works, then the problem is almost certainly the
> userspace drivers (Mesa).  If sys-gui-gpu in HVM mode works, but it
> fails in PV mode, then the problem is likely in the way i915 and Xen
> interact.
>
>
> I have tested this now. When I boot, the problem remains. Opening the Qube
> Manager shows that the sys-gui-gpu qube is not running. I tried starting it
> from the manager,
> and it led to immediate black screen, requiring a hard shutdown. The logs
> for that qube are here:
>
> dom0 will kernel panic if the GPU is removed from it while in use.  I
> recommend preventing the i915 kernel module from being loaded in dom0
> via the dom0 kernel command line.
>
>
> I've tried some variants now. Disabling i915 (by moving the driver flie)
> doesn't do much. It boots up as usual, same problems, and if I try to boot
> the sys-gui-gpu qube, it blackscreens and requires hard shutdown.
>

New development: I used the boot param: module_blacklist=i915 (and the
drivers were also removed from the filesystem).

This time, there were no graphics glitches. However, the sys-gui-gpu did
not come up. I started a work -qube Firefox, thinking it maybe would
kickstart the gui vm, but no.

So maybe those gui-vm config steps do not fully enable it? I eventually
(again) tried manually starting it, with the result of immediate
blackscreen freeze.

Not sure where that leaves me? I don't even know what the whole i915 thing
is all about, what is it supposed to improve?

-- 
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/CANC2dUco%2BHrHq69a8_uKJCj-18D%2Ba_NbkQ54y5DQRsez9c4PUw%40mail.gmail.com.

Re: [qubes-users] Qube-Firewall: How to handle changing IPs?

[r . wiesbach]

Sorry, I just noticed that I missed your answer because you did not
answer me directly, but only to the list. The issue you reference to is
quite long to read and parts of it are several years old, is there
something ready for testing?

You say "less often", for my imap-server imap.web.de this semms to appen
about every second weeks I think.

Am 29.07.22 um 17:43 schrieb David Hobach:

See [1]. It happens less often than one might think though.

[1] https://github.com/QubesOS/qubes-issues/issues/5225



--
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/81d7bf81-8049-d036-ee09-fc41674f5cb9%40web.de.

Re: [qubes-users] Qube-Firewall: How to handle changing IPs?

[r . wiesbach]

Is there really no approach to fix this? What about a cron job which
checks for a change DNS resolve every now and then and updates the
ip-filter, for example?

Am 29.07.22 um 11:08 schrieb r.wiesb...@web.de:

Hi there,

many large providers use CDNs or similar structures, which results in
the same FQDN being resolved to different IPs.
Afaik the Qube-Firewall-Settings resolve a DNS entry only once (on
add/edit) and internaly use that IP. This is a problem with my
mail-provider (web.de) as well es for Updates of Thunderbird Add-Ons.
Besides workarounds like manually refreshing the firewall settings or
temporary allowing full web access: is there a fix for 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/8e612d9c-e5a2-fb2c-89de-0c4c308b013f%40web.de.

Re: [qubes-users] Re: HCL - Lenovo X1 Carbon gen 10

[Martin Holst Swende]

On 8/11/22 11:38, Demi Marie Obenour wrote:

3. Does HVM sys-gui-gpu work?  What about PV (not PVH!) sys-gui-gpu?

I don't have a sys-gui-gpu at the moment, but will test that. This page
(https://www.qubes-os.org/doc/guivm-configuration/) is still the most
relevant/recent description, right?

I think so?  I don’t use sys-gui-gpu myself, and I will admit that there
are quite a few bugs when using it.  Still, if it works, then the
possible parts of the code that could be to blame is much lower. If
sys-gui-gpu in PV mode works, then the problem is almost certainly the
userspace drivers (Mesa).  If sys-gui-gpu in HVM mode works, but it
fails in PV mode, then the problem is likely in the way i915 and Xen
interact.


I have tested this now. When I boot, the problem remains. Opening the Qube
Manager shows that the sys-gui-gpu qube is not running. I tried starting it
from the manager,
and it led to immediate black screen, requiring a hard shutdown. The logs
for that qube are here:

dom0 will kernel panic if the GPU is removed from it while in use.  I
recommend preventing the i915 kernel module from being loaded in dom0
via the dom0 kernel command line.



I've tried some variants now. Disabling i915 (by moving the driver flie) 
doesn't do much. It boots up as usual, same problems, and if I try to 
boot the sys-gui-gpu qube, it blackscreens and requires hard shutdown.


/Martin


--
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/9071b635-7798-45ee-2fe9-8e99c8172966%40gmail.com.

Re: [qubes-users] Re: HCL - Lenovo X1 Carbon gen 10

[Demi Marie Obenour]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Thu, Aug 11, 2022 at 11:30:50AM +0200, Martin Holst Swende wrote:
> 
> On 8/11/22 10:59, Demi Marie Obenour wrote:
> > On Thu, Aug 11, 2022 at 09:07:22AM +0200, Martin Holst Swende wrote:
> > 
> > >>> Happy to try out any suggestion/experiment.
> > >>
> > >> 1. Does i915.enable_psr2_sel_fetch=0 help?
> > 
> > > No, no change that I can see.
> > 
> > Okay, so that is not the problem.
> > 
> > >> 2. What X11 driver is Xorg using?  If it is using Intel, does
> > >>    modesetting help?  If it is using modesetting, does Intel help?
> > 
> > 
> > > More full logs/notes can be found at 
> > > https://gist.github.com/holiman/83c76e4cd98d087719773486a77d9112#file-dom0_testing-txt
> > > .
> > 
> > > I'm not sure how to interpret the logs, it looks to me like "intel no,
> > > modesetting yes". Not sure how/what to change here, given a nudge in the
> > > right direction I can try to explore it more.
> > 
> > That is what it looks like to me also.
> > 
> > >> 3. Does HVM sys-gui-gpu work?  What about PV (not PVH!) sys-gui-gpu?
> > 
> > > I don't have a sys-gui-gpu at the moment, but will test that. This page
> > > (https://www.qubes-os.org/doc/guivm-configuration/) is still the most
> > > relevant/recent description, right?
> > 
> > I think so?  I don’t use sys-gui-gpu myself, and I will admit that there
> > are quite a few bugs when using it.  Still, if it works, then the
> > possible parts of the code that could be to blame is much lower. If
> > sys-gui-gpu in PV mode works, then the problem is almost certainly the
> > userspace drivers (Mesa).  If sys-gui-gpu in HVM mode works, but it
> > fails in PV mode, then the problem is likely in the way i915 and Xen
> > interact.
> > 
> I have tested this now. When I boot, the problem remains. Opening the Qube
> Manager shows that the sys-gui-gpu qube is not running. I tried starting it
> from the manager,
> and it led to immediate black screen, requiring a hard shutdown. The logs
> for that qube are here:

dom0 will kernel panic if the GPU is removed from it while in use.  I
recommend preventing the i915 kernel module from being loaded in dom0
via the dom0 kernel command line.
- -- 
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmL0zgYACgkQsoi1X/+c
IsEB3w//V5thcPTmgEQhPwd4/8qSZWx3OqmvEiNDkH4Mj+Aw1mVICbMprqeyhUz0
8rlJK2sjPvZvF0xNRRuHedtdolliw/R5u0pQWoTtQ+CJd3hPJsoEXRja8lyPVYdS
UBvSNzPbsWZjCfE4uqEyHIhdEDmd53X/vvTikS9fu7x3+REdKTHd/tMR1yTB7bfw
chLg67/FFU1fgHVGQAkj3Hi2Rh8NF1uzG4VRLo0XFf0JG+M+SSb9L9MKijUkZWJZ
Qa9iuPn3wCrm9eNhWzskfatNnjh3PsYPVHH1f2X3bqH6TsGkpxbz2YyOVAp9PmDT
uvGUooDlouFfClKRPxtmkjqvnrquVbdzUgE6OdW023MgA6m5/eF8nHQYZLw3qcAz
apPwx9rjRKzRwE57saI+CFJGwuxlmD/8w9B+oWJ8bgXPcmEgmgM3rqsZrXgYM4uw
Ktq6tM1KZYbNN7naMEowPhvrMMbu2xx5OMxkQ9wZsU1HxFVY2zwAcOQttXblt5lj
VQEAUeysXvCffmrzhORqaUFuzBIX7iWoU5PCuCG2Pfb0YX9FeBhyaZlLLDA90R6m
yp4YWyNAZeq0Gfn3gZd2IVcYSdw+HjuWdYPTdhfhOA0wq5SxVt8MEtKe+ZelSSiw
bhZLV0PN+2ZLkIed5a0YM+FDnqIugLRNBMz50eeVzKAl8lInHyY=
=Gu+c
-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/YvTOBm3bzTVfto24%40itl-email.

Re: [qubes-users] Re: HCL - Lenovo X1 Carbon gen 10

[Martin Holst Swende]

On 8/11/22 10:59, Demi Marie Obenour wrote:

On Thu, Aug 11, 2022 at 09:07:22AM +0200, Martin Holst Swende wrote:

>>> Happy to try out any suggestion/experiment.
>>
>> 1. Does i915.enable_psr2_sel_fetch=0 help?

> No, no change that I can see.

Okay, so that is not the problem.

>> 2. What X11 driver is Xorg using?  If it is using Intel, does
>>    modesetting help?  If it is using modesetting, does Intel help?


> More full logs/notes can be found at 
https://gist.github.com/holiman/83c76e4cd98d087719773486a77d9112#file-dom0_testing-txt

> .

> I'm not sure how to interpret the logs, it looks to me like "intel no,
> modesetting yes". Not sure how/what to change here, given a nudge in the
> right direction I can try to explore it more.

That is what it looks like to me also.

>> 3. Does HVM sys-gui-gpu work?  What about PV (not PVH!) sys-gui-gpu?

> I don't have a sys-gui-gpu at the moment, but will test that. This page
> (https://www.qubes-os.org/doc/guivm-configuration/) is still the most
> relevant/recent description, right?

I think so?  I don’t use sys-gui-gpu myself, and I will admit that there
are quite a few bugs when using it.  Still, if it works, then the
possible parts of the code that could be to blame is much lower. If
sys-gui-gpu in PV mode works, then the problem is almost certainly the
userspace drivers (Mesa).  If sys-gui-gpu in HVM mode works, but it
fails in PV mode, then the problem is likely in the way i915 and Xen
interact.

I have tested this now. When I boot, the problem remains. Opening the 
Qube Manager shows that the sys-gui-gpu qube is not running. I tried 
starting it from the manager,
and it led to immediate black screen, requiring a hard shutdown. The 
logs for that qube are here:


https://gist.github.com/holiman/83c76e4cd98d087719773486a77d9112#file-guest-sys-gui-gpu-log 



https://gist.github.com/holiman/83c76e4cd98d087719773486a77d9112#file-guest-sys-gui-gpu-dm-log

I then switched it to PV mode. Same thing, does not startup + 
blackscreen if I start it explicitly.



>> If PV sys-gui-gpu with a dom0-provided kernel works, then the 
problem is

>> almost certainly old dom0 userspace: either an old X server, old Mesa,
>> or both.  If you could build modern Mesa and/or X11 for dom0 and try
>> again, that would be awesome.

> Left for future reference, I'm taking baby steps here :)

Valid :)



--
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/399aa34c-e872-1b9e-0cfa-da3a401c0961%40gmail.com.

Re: [qubes-users] Re: HCL - Lenovo X1 Carbon gen 10

[Demi Marie Obenour]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Thu, Aug 11, 2022 at 09:07:22AM +0200, Martin Holst Swende wrote:
> 
> > > Happy to try out any suggestion/experiment.
> > 
> > 1. Does i915.enable_psr2_sel_fetch=0 help?
> 
> No, no change that I can see.

Okay, so that is not the problem.

> > 2. What X11 driver is Xorg using?  If it is using Intel, does
> >    modesetting help?  If it is using modesetting, does Intel help?
> 
> 
> More full logs/notes can be found at 
> https://gist.github.com/holiman/83c76e4cd98d087719773486a77d9112#file-dom0_testing-txt
> .
> 
> I'm not sure how to interpret the logs, it looks to me like "intel no,
> modesetting yes". Not sure how/what to change here, given a nudge in the
> right direction I can try to explore it more.

That is what it looks like to me also.

> > 3. Does HVM sys-gui-gpu work?  What about PV (not PVH!) sys-gui-gpu?
> 
> I don't have a sys-gui-gpu at the moment, but will test that. This page
> (https://www.qubes-os.org/doc/guivm-configuration/) is still the most
> relevant/recent description, right?

I think so?  I don’t use sys-gui-gpu myself, and I will admit that there
are quite a few bugs when using it.  Still, if it works, then the
possible parts of the code that could be to blame is much lower.  If
sys-gui-gpu in PV mode works, then the problem is almost certainly the
userspace drivers (Mesa).  If sys-gui-gpu in HVM mode works, but it
fails in PV mode, then the problem is likely in the way i915 and Xen
interact.

> > If PV sys-gui-gpu with a dom0-provided kernel works, then the problem is
> > almost certainly old dom0 userspace: either an old X server, old Mesa,
> > or both.  If you could build modern Mesa and/or X11 for dom0 and try
> > again, that would be awesome.
> 
> Left for future reference, I'm taking baby steps here :)

Valid :)

- -- 
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmL0xOwACgkQsoi1X/+c
IsFd2w/+PURi2vrHaEzWaEJAS9mlUKM4gdel9oqaGuIWpOrFpNnjNSW4xuYy3HSB
j9fxftynuJgk36Fz3xza75mrGTY1HQ3ntkJmx/ABNB42YeAanElvo1ZZhLZbI4KD
8EU+EmFRTRlXZqxtvyQX3BqFDW3QTSY+dQLuNOYfe66/SfCYObWu1CeOjPT10Sdj
DtFzmzNV0vsF8bxRUGkrJRyNr6HdArRmS3a83PsaAA5KWN3vDasjNl80vBUfEJnN
yYPlVtZMdEdopAadPwXbiJ2/l9i2t6NFomm2XI8L4tHreW9BPvkf3BrAIRmnOKqw
Nwdvw8s0An9Dn1gdWJFtem9Mf8T+KYQ20aMJzTVbyamotV7vBQE+zPV5zCgjtzBP
FIZH/UOT1g3hftnzARUQ53CN7juwMAOLiFV+Nbg8IQeb4y1Anthu6qiJjJMMAkTL
mq3PNKqjWsBSk1in3C32RzUrBmSBEsuW0xw+ns/Dm5BnIuFn+0yOssbntMec/RK1
JA3HMVNpX0TY8RX85ZDH3ZoZz6RkjMxQLgJAbeQ5AkkFJgZ7xKACrphC3SAtgJgf
iW7v16IoCzwq2vnmWgEAGKYMp7zoeeOqS2DNAWrvPiHQl1CKllYBWvIIB1wWEiEM
VFJ0XfIgzr1OTRzoIos9vC5CkXyhuYm0v9HT5GWRTTgUszgvlbc=
=fOYw
-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/YvTE7Do1xCeR8rYU%40itl-email.

Re: [qubes-users] Re: HCL - Lenovo X1 Carbon gen 10

[Martin Holst Swende]

> Happy to try out any suggestion/experiment.

1. Does i915.enable_psr2_sel_fetch=0 help?


No, no change that I can see.



2. What X11 driver is Xorg using?  If it is using Intel, does
   modesetting help?  If it is using modesetting, does Intel help?



More full logs/notes can be found at 
https://gist.github.com/holiman/83c76e4cd98d087719773486a77d9112#file-dom0_testing-txt 
.


I'm not sure how to interpret the logs, it looks to me like "intel no, 
modesetting yes". Not sure how/what to change here, given a nudge in the 
right direction I can try to explore it more.




3. Does HVM sys-gui-gpu work?  What about PV (not PVH!) sys-gui-gpu?


I don't have a sys-gui-gpu at the moment, but will test that. This page 
(https://www.qubes-os.org/doc/guivm-configuration/) is still the most 
relevant/recent description, right?




If PV sys-gui-gpu with a dom0-provided kernel works, then the problem is
almost certainly old dom0 userspace: either an old X server, old Mesa,
or both.  If you could build modern Mesa and/or X11 for dom0 and try
again, that would be awesome.


Left for future reference, I'm taking baby steps here :)

Cheers

--
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/903b394e-c96a-2570-566f-cea58a217d17%40gmail.com.

[qubes-users] Re: Windows HVM Restore - Inaccessible Boot Device

[EasyMac308]

Closing the loop on this for anyone in the future.  In the end, I had to:
>From the working 4.0 host:
- Enable a local admin + login one time.
- Take a fresh backup.
On the target 4.1 host:
- Restore the backup
- in a dom0 terminal, run "qvm-prefs  qrexec_timeout 6000" 
< number is just a large, arbitrary number so Qubes doesn't shut the 
machine down when qrexec doesn't come up.
- Boot the machine 3x times.  On the third time, Automatic Repair starts.
- Logged in with the local admin.
- Attempted automatic repair - no good.
- Opened a command prompt and used diskpart to assign the boot partition to 
letter S and the Windows partition to letter C.
- used bcdboot to regenerate the boot files.
- used bcdedit to ensure the correct partition was set.
- reboot

This *still* failed on the next boot, however I was able to get into 
Windows Safe Mode.  Another reboot had me functioning normally.

On Tuesday, August 9, 2022 at 5:10:22 PM UTC-5 EasyMac308 wrote:

> Update: I was able to restore my backup to a Qubes 4.0 system and it 
> worked.  The new system is 4.1...  That gives me something else to chase 
> down.
>
> On Tuesday, August 9, 2022 at 1:44:14 PM UTC-5 EasyMac308 wrote:
>
>> Hi folks,
>>
>> I had a catastrophic failure with my Librem 14v1 and am currently trying 
>> to get everything back up and running from my latest backup onto a new 
>> machine (Dell Precision 7510), pending the return of my repaired Librem.
>>
>> My Linux App VMs all seem good, but my Windows HVM is failing to start 
>> with "Inaccessible Boot Device".  The steps I would normally take to 
>> attempt to troubleshoot a Windows machine in this state aren't working 
>> (booting from the Windows Install Media and/or some kind of PE disc).  The 
>> VM just shuts down before either come up.  Windows automatic repair fails 
>> because there's no local local admin account.
>>
>> The HVM was originally created from a Hyper-V VM whose disk was converted 
>> to qcow2 and then imported to Qubes.  It's functioned fine on my original 
>> machine since.  Backup and restore was done via the standard GUI tools 
>> within Qubes.
>>
>> One thing I've never been clear on is where the disks live once they're 
>> in Qubes.  I know it's something to do with lvm, but I'm unsure how to 
>> access them or re-export them for use in another hypervisor.
>>
>> I have access to both the recent backup I took and the disk out of the 
>> bad laptop.  Any tips would be much appreciated.  Thanks!
>>
>

-- 
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/00bb5621-64db-451a-b801-ba1cd88db87bn%40googlegroups.com.

Re: [qubes-users] Re: HCL - Lenovo X1 Carbon gen 10

[Demi Marie Obenour]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Wed, Aug 10, 2022 at 08:36:33AM +0200, Martin Holst Swende wrote:
> 
> On 8/10/22 05:10, Demi Marie Obenour wrote:
> > On Tue, Aug 09, 2022 at 08:11:35PM +0200, Martin Holst Swende wrote:
> > > Some follow-up. I tested also with a Fedora LiveCD, results are on the
> > gist 
> > (here:https://gist.github.com/holiman/83c76e4cd98d087719773486a77d9112#file-fedora-live-txt
> > > ) .
> > 
> > > The Fedora livecd worked flawlessly, both wifi-wise and graphics-wise.
> > It
> > > was a fedora 36 -- whereas dom0 is still on Fedora32.
> > 
> > > Is it in any way possible to try out some experimental repo where dom0
> > is
> > > more recent?
> > 
> > No, but I would like to know if your problems go away with
> > kernel-latest.  If they do not, then this means that either Xen does not
> > interact well with Linux’s graphics drivers, or that the Mesa version is
> > too old for your hardware.
> 
> 
> Unfortunately, they do not. I did that as the first thing after getting wifi
> to work, so the version 5.18.9-1 in the HCL, is kernel-latest.
> 
> Happy to try out any suggestion/experiment.

1. Does i915.enable_psr2_sel_fetch=0 help?
2. What X11 driver is Xorg using?  If it is using Intel, does
   modesetting help?  If it is using modesetting, does Intel help?
3. Does HVM sys-gui-gpu work?  What about PV (not PVH!) sys-gui-gpu?

If PV sys-gui-gpu with a dom0-provided kernel works, then the problem is
almost certainly old dom0 userspace: either an old X server, old Mesa,
or both.  If you could build modern Mesa and/or X11 for dom0 and try
again, that would be awesome.
- -- 
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmLz9W0ACgkQsoi1X/+c
IsGr+Q//UJPaZkdHsRSD3cGkhEA0A2faR6eKmJ8VFsVZalfp46ltQKszUrsb2zzo
nH8WsVelrODtPk46rRb177SrxOjaqbZZTQ0LZ5VooAghUfWWnYNPGepoCWqipUkd
oq4r43fIQUElxzA8bNbaPHBAFVoIwbdigL88+ZVcgysFGYdIegaYNcfWPaYVkMVd
mRDaTYgsVOlUMAdPC1KOAycRhB/DODhjnelUaeLVRcBAtNq2VrJHavvjku1gY0gK
7y4J5SI2Fm9YLsZpXBn5kMabUhgw/giqlWZ7p/IFXKPbzyVF+rab2Jji4l3oiqdy
k3kZfr3kCrcnoBivrk5P0EdwYzGZvs9GSoKXAKhRONAQ8ME8ELHq1B/HtZuVbclm
Ku0NkjNzLj/v89H+d3MNAxZdup5nsxsHdROm2m81Q2ivED9QuzY8WBEwVWkkTQPC
bC6AAir83/d9m4sk6tVbI4hVK/fBRbrpoE5rrFEIydxzPu3qvSTp1vlC7HMdvnle
4CzAHjvs20dI7J6RxfGFDI81OPb3REFvIItrS/0t448Vdg2Wjb2oJc8xlP4AZT1A
zbAcyuDG7FDOIlsdN2hkVV4SVXenPsen9utv8sn92P6HPl/zH4g7/F73HV9Ixy55
qUWXKKY4/m/ROYFaPkxewtD55062gmwRFK3kWz69gFoohohzJU8=
=j+83
-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/YvP1bc2DMVpxbYrn%40itl-email.

Re: [qubes-users] Re: HCL - Lenovo X1 Carbon gen 10

[Martin Holst Swende]

On 8/10/22 05:10, Demi Marie Obenour wrote:

On Tue, Aug 09, 2022 at 08:11:35PM +0200, Martin Holst Swende wrote:
> Some follow-up. I tested also with a Fedora LiveCD, results are on 
the gist 
(here:https://gist.github.com/holiman/83c76e4cd98d087719773486a77d9112#file-fedora-live-txt

> ) .

> The Fedora livecd worked flawlessly, both wifi-wise and 
graphics-wise. It

> was a fedora 36 -- whereas dom0 is still on Fedora32.

> Is it in any way possible to try out some experimental repo where 
dom0 is

> more recent?

No, but I would like to know if your problems go away with
kernel-latest.  If they do not, then this means that either Xen does not
interact well with Linux’s graphics drivers, or that the Mesa version is
too old for your hardware.



Unfortunately, they do not. I did that as the first thing after getting 
wifi to work, so the version 5.18.9-1 in the HCL, is kernel-latest.


Happy to try out any suggestion/experiment.

Cheers,

Martin

--
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/7c1539da-9d05-e17d-6d6c-197d2a770aa0%40gmail.com.

Re: [qubes-users] qvm-prefs default_dispvm debian-11-mu-dvm

[Andrew David Wong]

On 8/9/22 12:40 PM, Franz wrote:
> On Tue, Aug 9, 2022 at 4:33 PM Qubes  wrote:
> 
>> Franz wrote:
>>> Hello, dear friends
>>>
>>> New installation 4.1.1
>>>
>>> I am trying to set  debian-11-mu-dvm as default disp vm template for the
>>> whole system, but the command
>>>
>>> qvm-prefs default_dispvm  debian-11-mu-dvm
>>>
>>> replies
>>>
>>> qvm-prefs: error: no such domain: 'default_dispvm'.
>> Global >
>>> It seems it expects a domain to make that debian-11-mu-dvm the default
>> disp
>>> vm for that domain. But I want to make it default for the whole system,
>> not
>>> a single domain.
>>>
>>> Is there a way?
>>>
>>
>> Can you try Qubes Manager?
>>
>> With Qubes Manager open select System -> Global settings. On the new
>> window that opens the default dispvm template to use system-wide is
>> bottom right.
>>
>>
> wow, I spent four hours and my head is fuming and you solved it in 5
> minutes. Many thanks my friend
> 

For the command line, you want `qubes-prefs` instead of `qvm-prefs`. The former 
is for global settings, while the latter is qube-specific.

-- 
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/b7eba828-5a0c-0195-0ea7-528012d99a5a%40qubes-os.org.

Re: [qubes-users] Install ttf-mscorefonts-installer on debian 11

[Andrew David Wong]

On 8/9/22 7:00 AM, roger paranoia wrote:
> Hello
> 
> I would like to install ttf-mscorefonts-installer with the following
> command:
> 
> sudo apt install ttf-mscorefonts-installer
> 
> but as it privative stuff, it is not directly available in the regular
> repositories. It actually tries to connect to many urls so it can automate
> an install of those fonts.
> 
> I had the same problem with the "add-apt-repository" when trying to install
> additional repositories to the ubuntu bionic template (provided by unman)
> but I worked around the issue by manually downloaded keys from a connected
> appvm, transferring them to the template and manually adding them. It was a
> bit of a pain in the ass then but it just got worse since the "apt-key add"
> has been deprecated and now gpg is the way to do it. Is there any way to
> install the microsoft fonts and/or to install repositories that require
> wget to download keys?
> 
> Thanks in advance!
> 

Perhaps this will help:

https://www.qubes-os.org/doc/how-to-install-software/#installing-software-from-other-sources

-- 
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/d062eab4-d6d1-2827-c722-6f09eb08375f%40qubes-os.org.

Re: [qubes-users] Re: HCL - Lenovo X1 Carbon gen 10

[Demi Marie Obenour]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Tue, Aug 09, 2022 at 08:11:35PM +0200, Martin Holst Swende wrote:
> Some follow-up. I tested also with a Fedora LiveCD, results are on the gist 
> (here:https://gist.github.com/holiman/83c76e4cd98d087719773486a77d9112#file-fedora-live-txt
> ) .
> 
> The Fedora livecd worked flawlessly, both wifi-wise and graphics-wise. It
> was a fedora 36 -- whereas dom0 is still on Fedora32.
> 
> Is it in any way possible to try out some experimental repo where dom0 is
> more recent?

No, but I would like to know if your problems go away with
kernel-latest.  If they do not, then this means that either Xen does not
interact well with Linux’s graphics drivers, or that the Mesa version is
too old for your hardware.
- -- 
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmLzIakACgkQsoi1X/+c
IsHHLA//WlMdykRac3ryUTFwfm8sO3rRGGDyfNy8uIDoJ2DDRyEKqxbYFb6ZuZiS
xpxz07THDzEOIOqAQk8zJ+pj35P3R1mbkQw2J/q3xtVqxNrvI3kGVLX/MT5NM1a5
7YrjJ5cF8H279Vs2YtCR8TgmGi+RlnY1jYWWZ3p5oN5EYL96QLclj+2PEtur0Tpe
dR1kaFmRmBUnAz1/Mz9VCOn0LMWEJ0vWpDTuHcIIuSkgW4aXEyWwtyKiXwSmhUs/
feVNHeZOO8UUqlckk3e7cLnzQM8skWO4ZO0BdBZd2DNOtsFJMrx4opW00jDB0aKz
k7aLsTh7zl1+2Xx/mrMNXB5TgPhr9vt+ikWC3AK1THQ3DPF/LbT/CDxEI7SAZgBJ
fexcDFajFe2fFIVR1px20CTHtNGTj3UqX7TYFxFD3YAAB9z+KUvImNlypwxY5snK
ilNfxTLCrJYCPcatlYpDXXHAX/zm2UrhulbMfHSKPVDk4CCJSCQsv1q+0wtDCc4V
OR6vVJehDnPVcgy05lt1r9TIdCK9xZmjZBneyUNgBdP7gee9rc1owYxfOAzB4Fup
rXhloewao1p8ttizSw4FFPFJeWs+jHiNnygDuNbYxldnz6V6hFyZ4uQPIefjhDln
pBiQaEpQIcRaG0uy7XzF8VLLLfSgeNoLKPKYI3dOWCPFsSK6Hy8=
=Ux9E
-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/YvMhqRnHu850pOU%2B%40itl-email.

Re: [qubes-users] HCL - Lenovo X1 Carbon gen 10

[Sven Semmler]

Thank you Martin for your HCL report. For now I filed it as works: 'no' ... let 
us know when this becomes a 'partial' with 'troubleshooting required'.

Your report is 
[online](https://www.qubes-os.org/hcl/#lenovo_thinkpad-x1-carbon-10-21cbcto1ww_i7-1270p_integrated-graphics-iris-xe_martin-holst-swende_r4-1)
 now.

/Sven

--
 public key: https://www.svensemmler.org/2A632C537D744BC7.asc
fingerprint: DA59 75C9 ABC4 0C83 3B2F 620B 2A63 2C53 7D74 4BC7

--
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/b19b4fe6-ad28-5471-c818-0db10531107e%40SvenSemmler.org.

[qubes-users] Re: Windows HVM Restore - Inaccessible Boot Device

[EasyMac308]

Update: I was able to restore my backup to a Qubes 4.0 system and it 
worked.  The new system is 4.1...  That gives me something else to chase 
down.

On Tuesday, August 9, 2022 at 1:44:14 PM UTC-5 EasyMac308 wrote:

> Hi folks,
>
> I had a catastrophic failure with my Librem 14v1 and am currently trying 
> to get everything back up and running from my latest backup onto a new 
> machine (Dell Precision 7510), pending the return of my repaired Librem.
>
> My Linux App VMs all seem good, but my Windows HVM is failing to start 
> with "Inaccessible Boot Device".  The steps I would normally take to 
> attempt to troubleshoot a Windows machine in this state aren't working 
> (booting from the Windows Install Media and/or some kind of PE disc).  The 
> VM just shuts down before either come up.  Windows automatic repair fails 
> because there's no local local admin account.
>
> The HVM was originally created from a Hyper-V VM whose disk was converted 
> to qcow2 and then imported to Qubes.  It's functioned fine on my original 
> machine since.  Backup and restore was done via the standard GUI tools 
> within Qubes.
>
> One thing I've never been clear on is where the disks live once they're in 
> Qubes.  I know it's something to do with lvm, but I'm unsure how to access 
> them or re-export them for use in another hypervisor.
>
> I have access to both the recent backup I took and the disk out of the bad 
> laptop.  Any tips would be much appreciated.  Thanks!
>

-- 
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/0633e9e6-87e8-49ad-98ca-17c6f3096944n%40googlegroups.com.

Re: [qubes-users] qvm-prefs default_dispvm debian-11-mu-dvm

[Franz]

On Tue, Aug 9, 2022 at 4:33 PM Qubes  wrote:

> Franz wrote:
> > Hello, dear friends
> >
> > New installation 4.1.1
> >
> > I am trying to set  debian-11-mu-dvm as default disp vm template for the
> > whole system, but the command
> >
> > qvm-prefs default_dispvm  debian-11-mu-dvm
> >
> > replies
> >
> > qvm-prefs: error: no such domain: 'default_dispvm'.
> Global >
> > It seems it expects a domain to make that debian-11-mu-dvm the default
> disp
> > vm for that domain. But I want to make it default for the whole system,
> not
> > a single domain.
> >
> > Is there a way?
> >
>
> Can you try Qubes Manager?
>
> With Qubes Manager open select System -> Global settings. On the new
> window that opens the default dispvm template to use system-wide is
> bottom right.
>
>
wow, I spent four hours and my head is fuming and you solved it in 5
minutes. Many thanks my friend

-- 
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/CAPzH-qAxjn-j%3DZ_VvdH5ed9AwoQxeRr5HdzM3eMeB-QYBwgXyA%40mail.gmail.com.

Re: [qubes-users] qvm-prefs default_dispvm debian-11-mu-dvm

[Qubes]

Franz wrote:

Hello, dear friends

New installation 4.1.1

I am trying to set  debian-11-mu-dvm as default disp vm template for the
whole system, but the command

qvm-prefs default_dispvm  debian-11-mu-dvm

replies

qvm-prefs: error: no such domain: 'default_dispvm'.

Global >

It seems it expects a domain to make that debian-11-mu-dvm the default disp
vm for that domain. But I want to make it default for the whole system, not
a single domain.

Is there a way?



Can you try Qubes Manager?

With Qubes Manager open select System -> Global settings. On the new 
window that opens the default dispvm template to use system-wide is 
bottom right.


--
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/c103d976-7364-71fb-8d83-9fb9e7389826%40ak47.co.za.

[qubes-users] qvm-prefs default_dispvm debian-11-mu-dvm

[Franz]

Hello, dear friends

New installation 4.1.1

I am trying to set  debian-11-mu-dvm as default disp vm template for the
whole system, but the command

qvm-prefs default_dispvm  debian-11-mu-dvm

replies

qvm-prefs: error: no such domain: 'default_dispvm'.

It seems it expects a domain to make that debian-11-mu-dvm the default disp
vm for that domain. But I want to make it default for the whole system, not
a single domain.

Is there a way?

best
Franz

-- 
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/CAPzH-qB%3Drxkh22iNNNrFFXYtebjyA0UmcCH3gq4cTD4n-L-otw%40mail.gmail.com.

[qubes-users] Windows HVM Restore - Inaccessible Boot Device

[EasyMac308]

Hi folks,

I had a catastrophic failure with my Librem 14v1 and am currently trying to 
get everything back up and running from my latest backup onto a new machine 
(Dell Precision 7510), pending the return of my repaired Librem.

My Linux App VMs all seem good, but my Windows HVM is failing to start with 
"Inaccessible Boot Device".  The steps I would normally take to attempt to 
troubleshoot a Windows machine in this state aren't working (booting from 
the Windows Install Media and/or some kind of PE disc).  The VM just shuts 
down before either come up.  Windows automatic repair fails because there's 
no local local admin account.

The HVM was originally created from a Hyper-V VM whose disk was converted 
to qcow2 and then imported to Qubes.  It's functioned fine on my original 
machine since.  Backup and restore was done via the standard GUI tools 
within Qubes.

One thing I've never been clear on is where the disks live once they're in 
Qubes.  I know it's something to do with lvm, but I'm unsure how to access 
them or re-export them for use in another hypervisor.

I have access to both the recent backup I took and the disk out of the bad 
laptop.  Any tips would be much appreciated.  Thanks!

-- 
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/dd80d8db-ce1d-46b7-b8a1-6978fafcc660n%40googlegroups.com.

[qubes-users] Re: HCL - Lenovo X1 Carbon gen 10

[Martin Holst Swende]

Some follow-up. I tested also with a Fedora LiveCD, results are on the 
gist 
(here:https://gist.github.com/holiman/83c76e4cd98d087719773486a77d9112#file-fedora-live-txt 
) .


The Fedora livecd worked flawlessly, both wifi-wise and graphics-wise. 
It was a fedora 36 -- whereas dom0 is still on Fedora32.


Is it in any way possible to try out some experimental repo where dom0 
is more recent?



Cheers,

Martin Holst Swende

--
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/2644202c-cbd8-8f41-a18b-45e9abcc17f4%40gmail.com.

[qubes-users] Install ttf-mscorefonts-installer on debian 11

[roger paranoia]

Hello

I would like to install ttf-mscorefonts-installer with the following
command:

sudo apt install ttf-mscorefonts-installer

but as it privative stuff, it is not directly available in the regular
repositories. It actually tries to connect to many urls so it can automate
an install of those fonts.

I had the same problem with the "add-apt-repository" when trying to install
additional repositories to the ubuntu bionic template (provided by unman)
but I worked around the issue by manually downloaded keys from a connected
appvm, transferring them to the template and manually adding them. It was a
bit of a pain in the ass then but it just got worse since the "apt-key add"
has been deprecated and now gpg is the way to do it. Is there any way to
install the microsoft fonts and/or to install repositories that require
wget to download keys?

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/CANyf1M%2BWb%2Be1L0o4DcHTR8fYmuCsu%2Bbsn5ZyLR9LXtFEmozQew%40mail.gmail.com.

[qubes-users] HCL - Lenovo X1 Carbon gen 10

[Martin Holst Swende]

Hi,

I installed qubes on a brand new Lenovo X1 Carbon, but encountered a lot 
of issues.


1. The wifi is unavailable. I have no idea why, but I did boot it into 
an ubuntu live cd once, and the wifi card was found on ubuntu. This gist 
(https://gist.github.com/holiman/83c76e4cd98d087719773486a77d9112) 
contains the `lspci` and `lsusb` from both qubes and ubuntu.


On qubes, the relevant pci device is

00:14.3 Network controller: Intel Corporation Device 51f0 (rev 01)

On ubuntu, it is identified as:

00:14.3 Network controller: Intel Corporation Alder Lake-P PCH CNVi WiFi 
(rev 01)


2. Graphics is a mess. Already at the installer-stage, things were 
really bad. A drop-down window slide took on the order of seconds. I 
went through with the installation anyway, and the graphics are really 
really slow. Dropping down the upper-left menu takes ~1s, first showing 
a fragmented puzzle, and a bit later filling out the missing bits in the 
puzzle, and the menu is shown. I have a video, not sure if it's worth 
posting anywhere.


Fwiw,

- the bios does not contain any option to toggle between integrated / 
discrete graphics.


- I have not yet tested any of the tricks (i915.enable_psr2_sel_fetch=0) 
mentioned on 
https://forums.lenovo.com/t5/Fedora/Fedora-on-X1-Carbon-Gen-10/m-p/5135869?page=1. 


--
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/38e2f033-0a55-d5b6-6d33-7bcc8557e96b%40gmail.com.


Qubes-HCL-LENOVO-21CBCTO1WW-20220809-103412.yml
Description: application/yaml

Re: [qubes-users] Problems with debian-11 after VM update attempt

[Ilpo Järvinen]

On Mon, 8 Aug 2022, Ulrich WIndl wrote:

> Hi!
> 
> I have a problem 8-(
> 
> After using Qubes OS after a longer break, I tried to install all updates.
> That worked for all template VMs except debian-11. Even when re-trying after
> all the rest was updated and the system rebooted, it won't work.
> 
> Even worse I can start a debian-11-based app VM, but I cannot launch any
> program there. Even "qvm-run debian-11 gnome-terminal" fails.
> 
> I have saved the lengthy protocol of the first attempt, however (attached).
> 
> It seems the problem was:
> 
> Unpacking thunderbird (1:91.12.0-1~deb11u1) over (1:91.8.0-1~deb11u1) ...
>     dpkg: error processing archive
> /tmp/apt-dpkg-install-GfbHjN/38-thunderbird_1%3a91.12.0-1~deb11u1_amd64.deb
> (--unpack):
>  cannot copy extracted data for
> './usr/share/thunderbird/omni.ja' to
> '/usr/share/thunderbird/omni.ja.dpkg-new': failed to write (No space left on
> device)
>     dpkg-deb: error: paste subprocess was killed by signal
> (Broken pipe)
> 
> Note: It's not pool00 that is full. How can I recover from this?

The system volume of debian-11 is full? It might be possible to revert the 
changes to the template if there's an earlier snapshot of it.

Otherwise, you'll need to recover things manually. You can access the vm's 
console with xl console. You'll likely need to make some space first 
(perhaps by deleting something you can easily recreate). As soon as the 
template works almost normally, I'd try to enlarge system volume and then 
reinstall all packages that were part of the failing upgrade.

-- 
 i.

> (I'm still at Qubes OS 4.0. I wanted to install the last updates, then backup,
> then try upgrading to 4.1)
> 
> 
> Regards,
> 
> Ulrich
> 
> 

-- 
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/alpine.DEB.2.21.2208090857460.31454%40lakka.kapsi.fi.

Re: [qubes-users] Problems with debian-11 after VM update attempt

[Demi Marie Obenour]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Mon, Aug 08, 2022 at 11:29:57PM +0200, Ulrich WIndl wrote:
> Hi!
> 
> I have a problem 8-(
> 
> After using Qubes OS after a longer break, I tried to install all updates.
> That worked for all template VMs except debian-11. Even when re-trying after
> all the rest was updated and the system rebooted, it won't work.
> 
> Even worse I can start a debian-11-based app VM, but I cannot launch any
> program there. Even "qvm-run debian-11 gnome-terminal" fails.
> 
> I have saved the lengthy protocol of the first attempt, however (attached).
> 
> It seems the problem was:
> 
> Unpacking thunderbird (1:91.12.0-1~deb11u1) over (1:91.8.0-1~deb11u1) ...
>     dpkg: error processing archive
> /tmp/apt-dpkg-install-GfbHjN/38-thunderbird_1%3a91.12.0-1~deb11u1_amd64.deb
> (--unpack):
>  cannot copy extracted data for
> './usr/share/thunderbird/omni.ja' to
> '/usr/share/thunderbird/omni.ja.dpkg-new': failed to write (No space left on
> device)
>     dpkg-deb: error: paste subprocess was killed by
> signal (Broken pipe)
> 
> Note: It's not pool00 that is full. How can I recover from this?
> 
> (I'm still at Qubes OS 4.0. I wanted to install the last updates, then
> backup, then try upgrading to 4.1)

You don’t actually need to install the latest updates first, FYI.  I
suggest just upgrading.

This particular problem means that your debian-11 template’s privage
volume is full.  Growing it via the GUI should fix it.
- -- 
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmLyJMEACgkQsoi1X/+c
IsGr/BAAv8gzKK38Gdh3W7oUjp14j4XrfZpE1GNaS4N9NP8LQazlSlN0WSySnCPj
xURkVQbeYQCiG6zaqk5/6PbxqPfRbBtoL3DRe1IY6YCGacgrgT7RU7OJxTOTQLey
gD/PohysV+vMKRjq6/ACHndxxhE3u/yiV0yYueefCy70a9lHATJImLzuKor6mHr0
ycueV6SPGViZ3EZXAuSyK6saXxN8NKMIt26jcQkRn2XIoiBD0Kxu6gRAtoYwjIXw
frVejv3kJCb+nRUSHoLyUvwJR1yXzJNJzN8brXssf4xJRvE4KwlGdYr5ZLyS+Pcm
19WChtL8kU+sr8ooRjQDjqyQjXhEaEK5DySbOsM38lc+dppXLRRDbzaNg8HTUFs4
OPfN2eAaBJJLKfOQQr+VrZufxh3JnBWMytbiyqNNOsC9RJMqZkaFg1ZEFROjRVdw
QHnl2e+htCEWXFLRpHPUXynjyWTkDViOyMwgbo0gX0I6Q7ui/AhwjH5HhDUklhp7
Bf7xuq7jXoq554DIZb/y242WODd/QX9aboNm9jfy0oIXwQvGSKH4QoQkRNdE6NtS
9tvudspIfrGAxAC9jV2+M88M1BVDF8jkhzu5q0n9IMSo6Hpcv0Z4vhtJ+T0gY00l
PKH3i+Ma2WWTjnzb7uMtDMPSJULIljPStKfvK/DrHBbIjeYOkp4=
=F50T
-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/YvIkwWEwVQ8TxmPK%40itl-email.

[qubes-users] Problems with debian-11 after VM update attempt

[Ulrich WIndl]

Hi!

I have a problem 8-(

After using Qubes OS after a longer break, I tried to install all 
updates. That worked for all template VMs except debian-11. Even when 
re-trying after all the rest was updated and the system rebooted, it 
won't work.


Even worse I can start a debian-11-based app VM, but I cannot launch any 
program there. Even "qvm-run debian-11 gnome-terminal" fails.


I have saved the lengthy protocol of the first attempt, however (attached).

It seems the problem was:

Unpacking thunderbird (1:91.12.0-1~deb11u1) over (1:91.8.0-1~deb11u1) ...
    dpkg: error processing archive 
/tmp/apt-dpkg-install-GfbHjN/38-thunderbird_1%3a91.12.0-1~deb11u1_amd64.deb 
(--unpack):
 cannot copy extracted data for 
'./usr/share/thunderbird/omni.ja' to 
'/usr/share/thunderbird/omni.ja.dpkg-new': failed to write (No space 
left on device)
    dpkg-deb: error: paste subprocess was killed by 
signal (Broken pipe)


Note: It's not pool00 that is full. How can I recover from this?

(I'm still at Qubes OS 4.0. I wanted to install the last updates, then 
backup, then try upgrading to 4.1)



Regards,

Ulrich

--
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/559eaee4-852d-4610-1550-243def7d38a0%40rz.uni-regensburg.de.
Updating debian-11

Error on updating debian-11: Command '['sudo', 'qubesctl', '--skip-dom0', '--targets=debian-11', '--show-output', 'state.sls', 'update.qubes-vm']' returned non-zero exit status 20
debian-11:
  --
ID: update
  Function: pkg.uptodate
Result: False
   Comment: Problem encountered upgrading packages. Additional info follows:

result:
--
pid:
1635
retcode:
100
stderr:
Running scope as unit: run-r461182c4888745e297adf501d83cf59e.scope
setting xserver-xorg-legacy/xwrapper/allowed_users from configuration file
E: Sub-process /usr/bin/dpkg returned an error code (1)
stdout:
Reading package lists...
Building dependency tree...
Reading state information...
Calculating upgrade...
The following packages were automatically installed and are no longer required:
  bsdmainutils cpp-8 enchant geoip-database gir1.2-clutter-1.0
  gir1.2-clutter-gst-3.0 gir1.2-cogl-1.0 gir1.2-coglpango-1.0
  gir1.2-gtkclutter-1.0 gir1.2-gtksource-3.0 gir1.2-json-1.0 libasan5
  libaudio2 libbind9-161 libboost-iostreams1.67.0 libboost-system1.67.0
  libbotan-2-9 libcdio18 libcgi-fast-perl libcgi-pm-perl
  libclass-accessor-perl libclutter-1.0-0 libclutter-1.0-common
  libclutter-gst-3.0-0 libclutter-gtk-1.0-0 libcodec2-0.8.1 libcogl-common
  libcogl-pango20 libcogl-path20 libcogl20 libcroco3 libcrystalhd3
  libcupsimage2 libcwidget3v5 libdc1394-22 libdns1104 libdns1110
  libdouble-conversion1 libdvdread4 libenchant1c2a libevent-2.1-6 libexiv2-14
  libfcgi-bin libfcgi-perl libfcgi0ldbl libfluidsynth1 libgail-common
  libgail18 libgeoip1 libgspell-1-1 libgssdp-1.0-3 libgtk2.0-0 libgtk2.0-bin
  libgtk2.0-common libgtksourceview-3.0-1 libgtksourceview-3.0-common
  libgupnp-1.0-4 libgutenprint-common libgutenprint9 libhavege1 libicu63
  libigdgmm5 libilmbase23 libio-string-perl libisc1100 libisc1105 libisccc161
  libisccfg163 libisl19 libjim0.77 libkyotocabinet16v5 libllvm7 liblouis17
  liblouisutdml8 liblwres161 liblzo2-2 libmng1 libmozjs-60-0 libmpdec2 libmpx2
  libmysofa0 libnfs12 libnftables0 liboauth0 libopenexr23
  libparse-debianchangelog-perl libperl5.28 libpgm-5.2-0 libpipewire-0.2-1
  libpoppler82 libpulse-mainloop-glib0 libpython2.7 libpython3.7
  libpython3.7-minimal libpython3.7-stdlib libqpdf21 libqt5xml5 libreadline5
  libreadline7 librpm8 librpmbuild8 librpmio8 librpmsign8 libruby2.5 libsane
  libsnmp30 libsqlite0 libtagc0 libusbmuxd4 libvpx5 libx264-155 libx265-165
  libxcb-util0 linux-headers-4.19.0-17-common 

[qubes-users] ThinkPad P14s: PCI problems, no-strict-reset

[Lasse Kliemann]

Hi, fresh installation of R4.1.1 on a ThinkPad P14s (latest BIOS version) with:

[x] Use sys-net qube for both networking and USB devices

(Because I want to use USB Wifi since the built-in Wifi does not work, which is 
"Intel Corporation Wi-Fi 6 AX210/AX211/AX411 160MHz".)

'qvm-start sys-net' hits me with:

Start failed: internal error: Unable to reset PCI device :00:14.0: internal 
error: Unable to reset PCI device :00:0d.2: internal error: Unable to reset 
PCI device :00:1f.6: internal error: Unable to reset PCI device 
:00:0d.3: internal error: Unable to reset PCI device :00:0d.0: no FLR, 
PM reset or bus reset available, see /var/log/libvirt/libxl/libxl-driver.log 
for details

Remedy found by trial-and-error:

qvm-pci detach sys-net dom0:00_0d.0
qvm-pci detach sys-net dom0:00_0d.2
qvm-pci detach sys-net dom0:00_0d.3
qvm-pci detach sys-net dom0:00_14.0
qvm-pci detach sys-net dom0:00_1f.6
qvm-pci attach --persistent --option no-strict-reset=true sys-net dom0:00_14.0

Output of 'qvm-pci', reduced to relevant 5 devices:

dom0:00_0d.0 USB controller: Intel Corporation Tiger Lake-LP Thunderbolt 4 USB 
Controller
dom0:00_0d.2 USB controller: Intel Corporation Tiger Lake-LP Thunderbolt 4 NHI 
#0
dom0:00_0d.3 USB controller: Intel Corporation Tiger Lake-LP Thunderbolt 4 NHI 
#1
dom0:00_14.0 USB controller: Intel Corporation Tiger Lake-LP USB 3.2 Gen 2x1 
xHCI Host Controller  sys-net (no-strict-reset=true)
dom0:00_1f.6 Ethernet controller: Intel Corporation Ethernet Connection (13) 
I219-LM

*Question:* is this a solid setup? (It works so far.)

Documentation reads: "While using the no-strict-reset flag, do not require PCI 
device to be reset before attaching it to another VM. This may leak usage data 
even without malicious intent."

As far as I see, the Host Controller (00_14.0) is attached to sys-net once 
after the system starts and then stays attached there; that's it. Is the 
warning about leaking usage data still relevant in such a case?

Thanks.

-- 
Kind Regards / MfG
Dr. Lasse Kliemann
Westring 269, 24116 Kiel, Germany
E-Mail: la...@lassekliemann.de
Telegram / Wire: @lassekliemann
Signal / Phone: +49 162 66 88 468

Work Address:
Department of Mathematics
Kiel University
*Heinrich-Hecht-Platz 6*, 24118 Kiel, Germany
E-Mail: l.kliem...@math.uni-kiel.de

-- 
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/875yj3x3ij.fsf%40lassekliemann.de.


signature.asc
Description: PGP signature

[qubes-users] QSB-084: Split GPG: GnuPG file descriptor confusion and file existence leak

[Andrew David Wong]

Dear Qubes Community,

We have just published [Qubes Security Bulletin (QSB) 084: Split GPG: GnuPG 
file descriptor confusion and file existence 
leak](https://github.com/QubesOS/qubes-secpack/blob/master/QSBs/qsb-084-2022.txt).
 The text of this QSB is reproduced below. This QSB and its accompanying 
signatures will always be available in the [Qubes Security Pack 
(qubes-secpack)](https://www.qubes-os.org/security/pack/). More information 
about QSBs, including a complete historical list, is available 
[here](https://www.qubes-os.org/security/qsb/).

```

 ---===[ Qubes Security Bulletin 084 ]===---

 2022-08-06

  Split GPG: GnuPG file descriptor confusion and file existence leak

User action required
-

Users must install the following specific packages in order to address the
issues discussed in this bulletin:

  For Qubes 4.1, in templates and standalones:
  - qubes-gpg-split 2.0.63

These packages will migrate from the security-testing repository to the
current (stable) repository over the next two weeks after being tested
by the community. [1] Once available, the packages are to be installed
via the Qubes Update tool or its command-line equivalents. [2]


Summary


Split GPG [3] is designed to isolate private keys from the application
using them in order to protect them from being extracted and to allow
the user to retain control over when they are used. This isolation is
implemented by forwarding calls from an application in a frontend qube,
where `qubes-gpg-client` is executed, to an instance of `gpg` in a
backend qube that holds the private keys, all while allowing only
specific `gpg` options. This option filtering mechanism is designed to
reject options like `--export-secret-keys` that might leak private keys
to the frontend qube. However, it has been discovered that certain
combinations of options allow the frontend qube to access data in the
backend qube in unintended ways.

Two separate types of attack were discovered:

1. Interaction via `--command-fd` allows the frontend qube to check for
   the existence of arbitrary files in the backend qube, including files
   unrelated to GnuPG.

2. Using the same `--*-fd` option several times allows the frontend qube
   to redirect GnuPG input and output to the wrong file descriptor. This
   can be used to:

   - Corrupt files used by GnuPG. (We have confirmed this only in the
 case of `trustdb`, but other files cannot be ruled out.)
   - Issue arbitrary commands to `gpg-agent`, which can be used to
 perform actions like generating new secret keys and deleting
 existing keys.
   - Set various environment variables for the `pinentry` process,
 thereby providing an indirect avenue of attack against this
 process.

   However, our testing did not reveal any way to exploit this
   vulnerability in order to read `gpg-agent`'s responses, which means
   that certain actions, such as extracting secret keys, should not be
   possible.


Impact
---

An attacker controlling a Split GPG frontend qube can check for the
existence of arbitrary files in a backend qube, corrupt the `trustdb`
file in a backend qube, issue arbitrary commands to `gpg-agent` in a
backend qube, and issue arbitrary commands to a smart card daemon in a
backend qube. While this vulnerability can be exploited in order to
generate and delete keys in the backend qube (or on a smart card
attached to the backend qube), it is unlikely that it can be used to
exfiltrate private keys out of the backend qube (or off of a smart card
attached to the backend qube). If this vulnerability were to be chained
with a hypothetical vulnerability in `gpg-agent`, `scdaemon`, or
`pinentry` (or in one of the libraries they use), then arbitrary code
execution could be possible.


Credits


This issue was discovered by Demi Marie Obenour.

References
---

[1] https://www.qubes-os.org/doc/testing/
[2] https://www.qubes-os.org/doc/how-to-update/
[3] https://www.qubes-os.org/doc/split-gpg/

--
The Qubes Security Team
https://www.qubes-os.org/security/

```


This announcement is also available on the Qubes website:
https://www.qubes-os.org/news/2022/08/06/qsb-084/

-- 
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/6e071ed2-72ac-4d4a-57d6-da9f25017e2d%40qubes-os.org.

Re: [qubes-users] qubes update -- how to hold an old kernel ??

[David Hobach]

On 8/5/22 17:00, Peter Palensky wrote:

Update: I can use newer kernels if I remove device "Realtek Semiconductor
Co., Ltd. RTS525A PCI Express Card Reader" from sys-usb VM.
If it _is_ attached to that VM, the entire computer crashes upon sys-usb
start (when newer kernels are in use, it is fine with [very] old ones).

So I guess not having the card reader is my solution towards upgrading to
4.1.1


Hm interesting. That's quite similar to my experience [1].

Maybe some Xen code wrt attaching Express Card Readers broke?
Last somewhat good kernel for me was 5.10.109-1.

[1] https://github.com/QubesOS/qubes-issues/issues/7637

--
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/611befb7-6eb1-db83-be55-fbe84d7a441c%40hackingthe.net.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [qubes-users] qubes update -- how to hold an old kernel ??

[Peter Palensky]

Update: I can use newer kernels if I remove device "Realtek Semiconductor 
Co., Ltd. RTS525A PCI Express Card Reader" from sys-usb VM.
If it _is_ attached to that VM, the entire computer crashes upon sys-usb 
start (when newer kernels are in use, it is fine with [very] old ones). 

So I guess not having the card reader is my solution towards upgrading to 
4.1.1

On Tuesday, June 14, 2022 at 1:51:39 PM UTC+2 haa...@web.de wrote:

> Dear Marek,
> >> kernel testing would be so much easier if the xen.cfg would allow an
> >> option like default=menuselect
> >> to get a boot menu -- instead of
> >> Maybe such a function exists already? If not that would be a feature
> >> request!
> >
> > That's the main reason why Qubes 4.1 doesn't use xen.cfg at all. There
> > is standard grub, where you have menu, editor etc.
> >
>
> Brilliant. And I'd love to re-install 4.1 for that. But the 5.x kernel
> on the iso fails either on boot, or at latest while install... is there
> a grub on the 4.1-iso as well? (i.e. possibility to manually add a
> kernel like 4.19?) If so: is the procedure explained somewhere? 'Cause
> grub-hacking is very unpleasant, as well :) Thank you, 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/8539f0ef-1242-457f-b3a4-87b2e80e442dn%40googlegroups.com.

[qubes-users] Qubes OS 4.0 has reached EOL

[Andrew David Wong]

Dear Qubes Community,

As [previously 
announced](https://www.qubes-os.org/news/2022/07/04/qubes-os-4-0-eol-on-2022-08-04/),
 all releases in the Qubes 4.0 series (which includes the most recent 4.0.4 
patch release) have officially reached EOL (end-of-life) as of today, 
2022-08-04. We strongly urge all remaining Qubes 4.0 users to [upgrade to Qubes 
4.1](https://www.qubes-os.org/doc/upgrade/4.1/) immediately. As always, the 
support statuses of all Qubes OS and template releases are available on the 
[supported releases](https://www.qubes-os.org/doc/supported-releases/) page, 
and the latest release is available to download on the 
[downloads](https://www.qubes-os.org/downloads/) page.


## What should I do?

If you're already using Qubes 4.1, then no action is required on your part. 
This announcement concerns only the 4.0 minor release series.

If you're still using Qubes 4.0 (including the most recent 4.0.4 patch 
release), then you should upgrade to 4.1 immediately. You have two options:

- Perform a clean reinstallation using the latest stable [Qubes 4.1.1 
ISO](https://www.qubes-os.org/downloads/#qubes-release-4-1-1), which was 
[published on 
2022-07-18](https://www.qubes-os.org/news/2022/07/18/qubes-4-1-1/).
- Perform an [in-place 
upgrade](https://www.qubes-os.org/doc/upgrade/4.1/#in-place-upgrade) to 4.1.

Both of these options are covered in further detail in the [Qubes 4.0 to 4.1 
upgrade guide](https://www.qubes-os.org/doc/upgrade/4.1/). If you need help, 
please consult our [help and support](https://www.qubes-os.org/support/) page.


This announcement is also available on the Qubes website:
https://www.qubes-os.org/news/2022/08/04/qubes-4-0-has-reached-eol/

-- 
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/e7300db5-e1b6-c193-faad-b9d1c0ae2458%40qubes-os.org.

[qubes-users] Setting help

[Qubes]

Is there anybody out there using Krusader in a VM based on a Fedora 
template?


I have been using Krusader for a very long time and up until now mostly 
on Debian. I recently installed a Fedora based VM but i see Krusader now 
apparently does not know of any file associations. Trying to set one 
also seems to be impossible. The right click menu in Krusader doesn't 
even have the "Open with" option and right clicking on a file and 
selecting properties is of no help either. If i try and change the "open 
with" from the file properties window Krusader displays a message "Could 
not find the "keditfiletype5" executable in PATH.".


What could possibly be the cause of this behavior on Fedora?

--
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/97fcbdd9-de48-6468-4358-d42424ab1ed6%40ak47.co.za.

Re: [qubes-users] Fedora rpmfusion repos

[Qubes]

Doing "sudo dnf config-manager --set-enabled rpmfusion-free", gives me
an error, "Error: No matching repo to modify: rpmfusion-free".



This appears to be specific to the Fedora-xx-minimal template. I don't
know why, can someone give me a pointer?



Fedora minimal will not include the rpmfusion-*.repo file/repo because it's
supposed to be "minimal" while the rpmfusion are "extras". You can of
course copy the rpmfusion-*.repo files over to your minimal template if you
like. You can find these files in this path in the normal fedora template:

/etc/yum.repos.d/rpmfusion-free.repo



Yes thank you now i remember.

Here is a snip of my "sudo dnf install " with the last output,

(351/352): libreoffice-core-7.3.4.2-4.fc36.x86_64.rpm   440 
kB/s | 111 MB 04:17
(352/352): thunderbird-91.12.0-1.fc36.x86_64.rpm249 
kB/s |  97 MB 06:40


Total   711 
kB/s | 283 MB 06:47
RPM Fusion for Fedora 36 - Free 0.0 
 B/s |   0  B 00:00
Curl error (37): Couldn't read a file:// file for 
file:///etc/pki/rpm-gpg/RPM-GPG-KEY-rpmfusion-free-fedora-36 [Couldn't 
open file /etc/pki/rpm-gpg/RPM-GPG-KEY-rpmfusion-free-fedora-36]
The downloaded packages were saved in cache until the next successful 
transaction.

You can remove cached packages by executing 'dnf clean packages'.

Looking in /etc/pki/rpm-gpg there are no RPM-GPG-KEY-rpmfusion* files.

You must also copy these files from a normal Fedora template to your 
minimal template,


qvm-copy /etc/pki/rpm-gpg/RPM-GPG-KEY-rpmfusion*

--
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/862f4681-cdd8-e4dc-69b7-ba85a37b95ed%40ak47.co.za.

Re: [qubes-users] Fedora rpmfusion repos

[Steve Coleman]

On Mon, Aug 1, 2022, 9:27 AM Qubes  wrote:

> Qubes wrote:
> > Is the documentation on this [page] to enable the rpmfusion repos still
> > relevant?
> >
> > Doing "sudo dnf config-manager --set-enabled rpmfusion-free", gives me
> > an error, "Error: No matching repo to modify: rpmfusion-free".
> >
>
> This appears to be specific to the Fedora-xx-minimal template. I don't
> know why, can someone give me a pointer?
>

Fedora minimal will not include the rpmfusion-*.repo file/repo because it's
supposed to be "minimal" while the rpmfusion are "extras". You can of
course copy the rpmfusion-*.repo files over to your minimal template if you
like. You can find these files in this path in the normal fedora template:

/etc/yum.repos.d/rpmfusion-free.repo

They are generally disabled so that including them by mistake is not a
security risk. Anything in the rpmfusion repository generally carries more
risk because it is less vetted than the normal fedora repository.

>
>

-- 
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/CAJ5FDnhbCstW6U1oVFbrsnUvkE-_Bd933gLjgVxV%2BoahjVnuTQ%40mail.gmail.com.

Re: [qubes-users] Fedora rpmfusion repos

[Qubes]

Qubes wrote:
Is the documentation on this [page] to enable the rpmfusion repos still 
relevant?


Doing "sudo dnf config-manager --set-enabled rpmfusion-free", gives me 
an error, "Error: No matching repo to modify: rpmfusion-free".




This appears to be specific to the Fedora-xx-minimal template. I don't 
know why, can someone give me a pointer?


--
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/5855713c-92fd-d1a6-f287-8863a3bac92d%40ak47.co.za.

[qubes-users] Fedora rpmfusion repos

[Qubes]

Is the documentation on this [page] to enable the rpmfusion repos still 
relevant?


Doing "sudo dnf config-manager --set-enabled rpmfusion-free", gives me 
an error, "Error: No matching repo to modify: rpmfusion-free".


[page] https://www.qubes-os.org/doc/how-to-install-software/

--
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/64629933-0d2c-7f18-2f33-259c7773ef51%40ak47.co.za.

[qubes-users] VM shutdown and services

[Qubes]

Can someone help me diagnose a problem that i have that seems to be 
Qubes specific.


I use profile-sync-daemon with my web browser to run the entire browser 
profile in memory. However, when i reboot (or shutodwn -> startup) a VM 
somewhere there appears to be a timing problem with when 
profile-sync-daemon is stopped and the actual VM is stopped. Because, 
after every reboot my browser profile is corrupted. However, if i stop 
profile-sync-daemon manually before rebooting my VM, systemctl --user 
stop psd, everything runs smooth.


I am sure it has to do with profile-sync-daemon not allowed enough time 
to write the browser profile in memory out to disk before the reboot 
happens.


--
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/9cb70d8c-2cf6-df1e-1860-ec24f84fc985%40ak47.co.za.

Re: [qubes-users] Installer does not work, no templates to install

['awokd' via qubes-users]

'felix' via qubes-users:
I want to reinstall Qubes 4.1, but I cannot select any templates in the 
installer.


Qubes 4.0 and 4.1 were already running successfully on my device and 
Qubes 4.0 can still be installed successfully.


In the install menu, Fedora, Debian and Whonix are missing from the 
software selection, which is why all templates and app vm's are missing 
after the installation and only dom0 remains.


I've seen this before when the USB drive gets only partially created. 
Make sure it's large enough for the bigger 4.1 image, and if you didn't 
use DD to create it, try that route.


--
- 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/52b4dacb-a3fa-1d85-f55c-f7caf564b2f3%40danwin1210.de.

Re: [qubes-users] Re: Problems with Timesynchronization

['unman' via qubes-users]

> 
> Can you please comment on how it is possible, that 
> "ConditionPathExists=/var/run/qubes-service/clocksync was not met" - and - 
> ideally, how to resolve that issue.
> 
That suggests that you do not have the clocksync service enabled.
Set it with `qvm-service --enable QUBE clocksync` or `qvm-features QUBE 
service.clocksync 1`

-- 
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/YuZmeyeQ/YQ9JZb4%40thirdeyesecurity.org.

[qubes-users] Re: Problems with Timesynchronization

[Howard Chen]

Did you check any system errors during the update?

On Saturday, July 30, 2022 at 9:34:26 PM UTC-7 viktor@gmail.com wrote:

> Hello Community,
>
> No advice / feedback at all ?
>
> Viktor Ransmayr schrieb am Samstag, 23. Juli 2022 um 22:05:39 UTC+2:
>
>> Hello community,
>>
>> I do have issues with the timesychronization of VMs in my Qubes OS 4.1.1 
>> system.
>>
>> I was reading the information provided in [1] - and - verified that 
>> 'sys-net' is my clock VM.
>>
>> However I was not able to resolve my issues ...
>>
>> Here are the logs:
>>
>> 
>>
>> [vr@dom0 ~]$ qubes-prefs clockvm
>> sys-net
>> [vr@dom0 ~]$ 
>>
>> 
>>
>> 
>>
>> [user@sys-net ~]$ 
>> [user@sys-net ~]$ timedatectl
>>Local time: Sat 2022-07-23 19:54:36 CEST
>>Universal time: Sat 2022-07-23 17:54:36 UTC
>>  RTC time: Sat 2022-07-23 17:54:36
>> Time zone: Europe/Berlin (CEST, +0200)
>> System clock synchronized: no
>>   NTP service: inactive
>>   RTC in local TZ: no
>> [user@sys-net ~]$ 
>>
>> 
>>
>> 
>>
>> [user@sys-net ~]$ 
>> [user@sys-net ~]$ systemctl restart systemd-timesyncd
>> [user@sys-net ~]$ 
>> [user@sys-net ~]$ 
>> [user@sys-net ~]$ systemctl status systemd-timesyncd
>> ○ systemd-timesyncd.service - Network Time Synchronization
>>  Loaded: loaded 
>> (/usr/lib/systemd/system/systemd-timesyncd.service; enabled>
>> Drop-In: /usr/lib/systemd/system/systemd-timesyncd.service.d
>>  └─30_qubes.conf
>>  Active: inactive (dead)
>>   Condition: start condition failed at Sat 2022-07-23 20:06:48 CEST; 
>> 14s ago
>>  └─ ConditionPathExists=/var/run/qubes-service/clocksync 
>> was not met
>>Docs: man:systemd-timesyncd.service(8)
>> lines 1-8/8 (END)
>>
>> [user@sys-net ~]$ 
>>
>> 
>>
>> 
>>
>> [user@sys-net ~]$ 
>> [user@sys-net ~]$ cd /var/run/qubes-service
>> [user@sys-net qubes-service]$ ls
>> network-manager  qubes-network   qubes-updates-proxy
>> qubes-firewall   qubes-update-check
>> [user@sys-net qubes-service]$ 
>>
>> 
>>
>> Do you have any advice on how to continue from here - or - what else to 
>> check?
>>
>
> Can you please comment on how it is possible, that 
> "ConditionPathExists=/var/run/qubes-service/clocksync was not met" - and - 
> ideally, how to resolve that issue.
>
> With kind regards,
>
> Viktor
>
>

-- 
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/99367f6d-9f30-4602-b650-55a72d5d8aacn%40googlegroups.com.

[qubes-users] Re: Problems with Timesynchronization

[Viktor Ransmayr]

Hello Community,

No advice / feedback at all ?

Viktor Ransmayr schrieb am Samstag, 23. Juli 2022 um 22:05:39 UTC+2:

> Hello community,
>
> I do have issues with the timesychronization of VMs in my Qubes OS 4.1.1 
> system.
>
> I was reading the information provided in [1] - and - verified that 
> 'sys-net' is my clock VM.
>
> However I was not able to resolve my issues ...
>
> Here are the logs:
>
> 
>
> [vr@dom0 ~]$ qubes-prefs clockvm
> sys-net
> [vr@dom0 ~]$ 
>
> 
>
> 
>
> [user@sys-net ~]$ 
> [user@sys-net ~]$ timedatectl
>Local time: Sat 2022-07-23 19:54:36 CEST
>Universal time: Sat 2022-07-23 17:54:36 UTC
>  RTC time: Sat 2022-07-23 17:54:36
> Time zone: Europe/Berlin (CEST, +0200)
> System clock synchronized: no
>   NTP service: inactive
>   RTC in local TZ: no
> [user@sys-net ~]$ 
>
> 
>
> 
>
> [user@sys-net ~]$ 
> [user@sys-net ~]$ systemctl restart systemd-timesyncd
> [user@sys-net ~]$ 
> [user@sys-net ~]$ 
> [user@sys-net ~]$ systemctl status systemd-timesyncd
> ○ systemd-timesyncd.service - Network Time Synchronization
>  Loaded: loaded 
> (/usr/lib/systemd/system/systemd-timesyncd.service; enabled>
> Drop-In: /usr/lib/systemd/system/systemd-timesyncd.service.d
>  └─30_qubes.conf
>  Active: inactive (dead)
>   Condition: start condition failed at Sat 2022-07-23 20:06:48 CEST; 
> 14s ago
>  └─ ConditionPathExists=/var/run/qubes-service/clocksync 
> was not met
>Docs: man:systemd-timesyncd.service(8)
> lines 1-8/8 (END)
>
> [user@sys-net ~]$ 
>
> 
>
> 
>
> [user@sys-net ~]$ 
> [user@sys-net ~]$ cd /var/run/qubes-service
> [user@sys-net qubes-service]$ ls
> network-manager  qubes-network   qubes-updates-proxy
> qubes-firewall   qubes-update-check
> [user@sys-net qubes-service]$ 
>
> 
>
> Do you have any advice on how to continue from here - or - what else to 
> check?
>

Can you please comment on how it is possible, that 
"ConditionPathExists=/var/run/qubes-service/clocksync was not met" - and - 
ideally, how to resolve that issue.

With kind regards,

Viktor

-- 
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/28050d33-a4c4-4daf-8372-da94989f7644n%40googlegroups.com.

[qubes-users] Re: Problem upgrading to 4.1.1. - computer freezes

[Howard Chen]

You are in the current version of Qubes. You don't need to upgrade to 
another fedora version as it is in 32. This might be Intel ME thing to 
crash your PC. A full complete reinstallation is NOT required for your PC 
as you need to try many times in order to work. The logs that output is 
well-normal at this point on because of older components needs time to 
recognize and train overtime. However, it will cause your PC to slow down. 
Are you sure that the Intel ME in your PC turned on?

On Saturday, July 30, 2022 at 11:47:58 AM UTC-7 Votan wrote:

> Dear all,
>
> I was running on Qubes OS 4.1 with kernel 5.10.112
>
> After updating with the Qubes Update Tool, my computer did not reboot 
> anymore - it froze at the point when the password for the system needs to 
> be entered. I still have the previous version, so I can still boot into the 
> system with version 4.1.
>
> As a second step I tried to update via command line in dom0 as suggested 
> here (qubes-os.org/doc/upgrade/4.1):
>
> > sudo qubes-dom0-update -y qubes-dist-upgrade
>
> Yet I get as error message: No match found for argument: qubes-dist-upgrade
>
>
> Any idea how to debug this? When I boot into the old version, I will not 
> learn from the logs. I am stuck.
>
>
> Do I need a complete re-install?
>
> Hardware:
>
> Dell XPS 15
>
> Intel Core i7-11800H
>
> 64GB RAM
>
>
> Yours
>
> Votan
>

-- 
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/6ef6c758-51e5-420b-bd09-d7841d1341abn%40googlegroups.com.

[qubes-users] Problem upgrading to 4.1.1. - computer freezes

[Votan]

  
  
Dear all,
I was running on Qubes OS 4.1 with kernel 5.10.112
After updating with the Qubes Update Tool, my computer did not
  reboot anymore - it froze at the point when the password for the
  system needs to be entered. I still have the previous version, so
  I can still boot into the system with version 4.1.
As a second step I tried to update via command line in dom0 as
  suggested here (qubes-os.org/doc/upgrade/4.1):
> sudo qubes-dom0-update -y qubes-dist-upgrade
Yet I get as error message: No match found for argument:
  qubes-dist-upgrade


Any idea how to debug this? When I boot into the old version, I
  will not learn from the logs. I am stuck.


Do I need a complete re-install?
Hardware:
Dell XPS 15
Intel Core i7-11800H
64GB RAM



Yours

Votan
  




-- 
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/57aa6aba-cdf7-5e8a-5d7b-c914eeef4253%40posteo.de.

[qubes-users] Re: Wiki

[Howard Chen]

https://alternativeto.net/software/dokuwiki/?license=opensource

On Friday, July 29, 2022 at 8:23:00 AM UTC-7 Qubes wrote:

> Slightly off topic, but can anybody recommend good wiki software that 
> plays well with Qubes VMs?
>
> I am asking because i am having lots of issues setting up Dokuwiki, 
> perhaps there is a better one that can be recommended.
>

-- 
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/633858ba-4dc2-4487-83b3-5456c1ef686en%40googlegroups.com.

Re: [qubes-users] qvm-firewall command error

[Howard Chen]

Thanks

On Friday, July 29, 2022 at 5:26:58 AM UTC-7 unman wrote:

> On Wed, Jul 27, 2022 at 03:59:03PM -0700, Howard Chen wrote:
> > Currently, I am configuring my NetworkIT qube firewall with the 
> > qvm-firewall command in dom0 terminal. However, when I entered this, it 
> > showed this following error:
> > 
> > [Howard@dom0 ~]$ qvm-firewall NetworkIT add dsthost 10.137.0.5
>
> 
>
> You havent given a valid rule: parameters are wrong and no action given.
> Look at the manpage and qvm-firewall --help.
>
> qvm-firewall NetworkIT add accept 10.137.0.5
> OR 
> qvm-firewall NetworkIT add accept match dsthost=10.137.0.5/32
>

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

Re: [qubes-users] Qube-Firewall: How to handle changing IPs?

[David Hobach]

See [1]. It happens less often than one might think though.

[1] https://github.com/QubesOS/qubes-issues/issues/5225

--
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/46b3ee63-e024-43f7-9a87-8b11decc0d76%40hackingthe.net.


smime.p7s
Description: S/MIME Cryptographic Signature

[qubes-users] Wiki

[Qubes]

Slightly off topic, but can anybody recommend good wiki software that 
plays well with Qubes VMs?


I am asking because i am having lots of issues setting up Dokuwiki, 
perhaps there is a better one that can be recommended.


--
You received this message because you are subscribed to the Google Groups 
"qubes-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to qubes-users+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/68792d3e-2d6c-87e8-de40-5488ce1659d6%40ak47.co.za.

[qubes-users] Qubes OS Summit 2022: September 9-11 in Berlin

[Andrew David Wong]

Dear Qubes Community,

In conjunction with [3mdeb](https://3mdeb.com/), the fourth edition of our 
Qubes OS Summit will be held live this year from September 9 to 11 in Berlin, 
Germany! For more information about this event, including the CFP (which is 
open until August 29), please see: 


This announcement is also available on the Qubes website:
https://www.qubes-os.org/news/2022/07/29/qubes-os-summit-2022/

-- 
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/fd9081a3-38a7-8feb-a623-7430d4277478%40qubes-os.org.

Re: [qubes-users] qvm-firewall command error

['unman' via qubes-users]

On Wed, Jul 27, 2022 at 03:59:03PM -0700, Howard Chen wrote:
> Currently, I am configuring my NetworkIT qube firewall with the 
> qvm-firewall command in dom0 terminal. However, when I entered this, it 
> showed this following error:
> 
> [Howard@dom0 ~]$ qvm-firewall NetworkIT add dsthost 10.137.0.5



You havent given a valid rule: parameters are wrong and no action given.
Look at the manpage and qvm-firewall --help.

qvm-firewall NetworkIT add accept 10.137.0.5
OR 
qvm-firewall NetworkIT add accept match dsthost=10.137.0.5/32

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

[qubes-users] Qube-Firewall: How to handle changing IPs?

[r . wiesbach]

Hi there,

many large providers use CDNs or similar structures, which results in
the same FQDN being resolved to different IPs.
Afaik the Qube-Firewall-Settings resolve a DNS entry only once (on
add/edit) and internaly use that IP. This is a problem with my
mail-provider (web.de) as well es for Updates of Thunderbird Add-Ons.
Besides workarounds like manually refreshing the firewall settings or
temporary allowing full web access: is there a fix for 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 view this discussion on the web visit 
https://groups.google.com/d/msgid/qubes-users/e6553491-58b3-c286-9f39-7b46499b0b81%40web.de.

Re: [qubes-users] Desktop changed to grey, won't change to anything else

['Stuart Perkins' via qubes-users]

On Wed, 27 Jul 2022 10:23:44 -0500
"'Stuart Perkins' via qubes-users"  wrote:

>My setup:
>
>Lenovo T420i
>Coreboot
>Qubes OS 4.0
>xfce4 desktop
>fully encrypted disks, 250Gb SSD main, 2TBHD for the larger MV images.
>
>The problem cropped up the other day where my assigned solid color of black 
>background suddenly changed to gray.  Using the system tools, desktop to 
>change it has no effect either on solid color or background image.  Everything 
>else is working fine, but the sudden change is distressing.
>
>Stuart
>

Actually it is that xfdesktop stopped being started automatically.  Starting it 
fixes the issue, but it has to be started manually.

Stuart

-- 
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/20220728124003.0057cee4%40yahoo.com.

[qubes-users] qvm-firewall command error

[Howard Chen]

Currently, I am configuring my NetworkIT qube firewall with the 
qvm-firewall command in dom0 terminal. However, when I entered this, it 
showed this following error:

[Howard@dom0 ~]$ qvm-firewall NetworkIT add dsthost 10.137.0.5
Traceback (most recent call last):
  File "/usr/bin/qvm-firewall", line 5, in 
sys.exit(main())
  File "/usr/lib/python3.8/site-packages/qubesadmin/tools/qvm_firewall.py", 
line 198, in main
args = parser.parse_args(args, app=app)
  File "/usr/lib/python3.8/site-packages/qubesadmin/tools/__init__.py", 
line 385, in parse_args
namespace = super().parse_args(*args, **kwargs)
  File "/usr/lib64/python3.8/argparse.py", line 1768, in parse_args
args, argv = self.parse_known_args(args, namespace)
  File "/usr/lib64/python3.8/argparse.py", line 1800, in parse_known_args
namespace, args = self._parse_known_args(args, namespace)
  File "/usr/lib64/python3.8/argparse.py", line 2009, in _parse_known_args
stop_index = consume_positionals(start_index)
  File "/usr/lib64/python3.8/argparse.py", line 1965, in consume_positionals
take_action(action, args)
  File "/usr/lib64/python3.8/argparse.py", line 1874, in take_action
action(self, namespace, argument_values, option_string)
  File "/usr/lib64/python3.8/argparse.py", line 1159, in __call__
subnamespace, arg_strings = parser.parse_known_args(arg_strings, None)
  File "/usr/lib64/python3.8/argparse.py", line 1800, in parse_known_args
namespace, args = self._parse_known_args(args, namespace)
  File "/usr/lib64/python3.8/argparse.py", line 2009, in _parse_known_args
stop_index = consume_positionals(start_index)
  File "/usr/lib64/python3.8/argparse.py", line 1965, in consume_positionals
take_action(action, args)
  File "/usr/lib64/python3.8/argparse.py", line 1874, in take_action
action(self, namespace, argument_values, option_string)
  File "/usr/lib/python3.8/site-packages/qubesadmin/tools/qvm_firewall.py", 
line 78, in __call__
rule = qubesadmin.firewall.Rule(None, **kwargs)
  File "/usr/lib/python3.8/site-packages/qubesadmin/firewall.py", line 280, 
in __init__
setattr(self, rule_opt, value)
  File "/usr/lib/python3.8/site-packages/qubesadmin/firewall.py", line 297, 
in action
value = Action(value)
  File "/usr/lib/python3.8/site-packages/qubesadmin/firewall.py", line 62, 
in __init__
raise ValueError(value)
ValueError: dsthost



Can someone figure out what's going on with the code?

-- 
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/b1d98803-b12f-465b-b933-1fd2b1bcb0f2n%40googlegroups.com.

Re: [qubes-users] Desktop changed to grey, won't change to anything else

[Qubes]

The problem cropped up the other day where my assigned solid color of black 
background suddenly changed to gray.  Using the system tools, desktop to change 
it has no effect either on solid color or background image.  Everything else is 
working fine, but the sudden change is distressing.



There is an option there to "Apply to all workspaces", you didn't 
perhaps untick that so the particular workspace you are on is different?


--
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/b77ccc75-e350-ccef-1252-f8b19bb6744f%40ak47.co.za.

[qubes-users] Desktop changed to grey, won't change to anything else

['Stuart Perkins' via qubes-users]

My setup:

Lenovo T420i
Coreboot
Qubes OS 4.0
xfce4 desktop
fully encrypted disks, 250Gb SSD main, 2TBHD for the larger MV images.

The problem cropped up the other day where my assigned solid color of black 
background suddenly changed to gray.  Using the system tools, desktop to change 
it has no effect either on solid color or background image.  Everything else is 
working fine, but the sudden change is distressing.

Stuart

-- 
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/20220727102344.527b1d08%40yahoo.com.

[qubes-users] XSAs released on 2022-07-26

[Andrew David Wong]

Dear Qubes Community,

The Xen Project has released one or more Xen Security Advisories (XSAs).
The security of Qubes OS *is not affected*.
Therefore, *no user action is required*.


## XSAs that affect the security of Qubes OS (user action required)

The following XSAs *do affect* the security of Qubes OS:

- (none)


## XSAs that do not affect the security of Qubes OS (no user action required)

The following XSAs *do not affect* the security of Qubes OS, and no user action 
is necessary:

- XSA-408 (shadow mode is disabled at build time)


## Related links

- Xen XSA list: 
- Qubes XSA tracker: 
- Qubes security pack (qubes-secpack): 
- Qubes security bulletins (QSBs): 


This announcement is also available on the Qubes website:
https://www.qubes-os.org/news/2022/07/26/xsas-released-on-2022-07-26/

-- 
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/7f9ab98e-4974-2f24-1911-84eee8a1e29f%40qubes-os.org.

Re: [qubes-users] Qubes Manager not honoring colour scheme selection

[TheGardner]

that should be the solution. Did it wrong also on my first try. After 
editing the /etc/environment , it works...

a...@qubes-os.org schrieb am Dienstag, 26. Juli 2022 um 10:15:58 UTC+2:

> On 7/25/22 4:53 PM, 'taran1s' via qubes-users wrote:
> > I tried this but didn't succeed.
> > 
> > sudo qubes-dom0-update qt5-qtstyleplugins
> > sudo qubes-dom0-update
> > export QT_QPA_PLATFORMTHEME=gtk2
> > 
> > cat /etc/environment QT_QPA_PLATFORMTHEME=gtk2
> > cat: 'QT_QPA_PLATFORMTHEME=gtk2': No such file or directory
> > 
> > Qube Manager is still white ^^. Any ideas?
> > 
>
> You have to actually edit the file `/etc/environment` in order to insert 
> the string `QT_QPA_PLATFORMTHEME=gtk2` into that file, then reboot 
> afterward.
>
> P.S. -- Please avoid top-posting.
>
> > 
> > TheGardner:
> >> Thanks very much Demi Marie.
> >> Then this should be the correct way:
> >>
> >> Source & Info: https://github.com/QubesOS/qubes-issues/issues/7389
> >>
> >>
> >> Install the package qt5-qtstyleplugins with:
> >>
> >> sudo qubes-dom0-update qt5-qtstyleplugins
> >>
> >> then insert in /etc/environment:
> >>
> >> -[Start]-
> >> QT_QPA_PLATFORMTHEME=gtk2
> >> -[End]---
> >>
> >> in dom0 terminal do:
> >>
> >> export QT_QPA_PLATFORMTHEME=gtk2
> >>
> >> ---
> >>
> >> finally you can check, if all changes were set & working:
> >>
> >> [TheGardner@dom0]$ cat /etc/environment
> >> QT_QPA_PLATFORMTHEME=gtk2
> >>
> >> [TheGardner@dom0]$ echo $QT_QPA_PLATFORMTHEME
> >> gtk2
> >>
> >> [TheGardner@dom0]$ sudo dnf info qt5-qtstyleplugins
> >> Qubes OS Repository for Dom0
> >>1.9 MB/s | 3.0 kB 00:00
> >> Installed Packages
> >> Name : qt5-qtstyleplugins
> >> Version  : 5.0.0
> >> Release  : 39.fc32
> >> Architecture : x86_64
> >> Size : 1.2 M
> >> Source   : qt5-qtstyleplugins-5.0.0-39.fc32.src.rpm
> >> Repository   : @System
> >>   From repo: qubes-dom0-cached
> >> Summary  : Classic Qt widget styles
> >> URL  : https://github.com/qtproject/qtstyleplugins
> >> License  : LGPLv2 or GPLv2
> >> Description  : Classic Qt widget styles, including cleanlooks, motif,
> >> plastique, qgtk.
> >>
> >> Demi Marie Obenour schrieb am Samstag, 23. Juli 2022 um 04:07:18 UTC+2:
> >>
> >> On Fri, Jul 22, 2022 at 05:45:13PM -0700, TheGardner wrote:
> > Great! It's working now with the following steps in dom0 terminal:
> >
> > Download qt5-qtstyleplugins RPM file from:
> >
> >
> >> 
> https://kojipkgs.fedoraproject.org//packages/qt5-qtstyleplugins/5.0.0/39.fc32/x86_64/qt5-qtstyleplugins-5.0.0-39.fc32.x86_64.rpm
> >
> > Move it from your AppVM to dom0 with:
> >
> > qvm-run --pass-io  'cat
> > /home/user/Download/qt5-qtstyleplugins-5.0.0-39.fc32.x86_64.rpm' >
> >
> >> 
> /home//Downloads/qt5-qtstyleplugins-5.0.0-39.fc32.x86_64.rpm
> >
> > Install the package with:
> >
> > sudo dnf install -y qt5-qtstyleplugins-5.0.0-39.fc32.x86_64.rpm
> >>
> >> This is not safe. You can do:
> >>
> >> sudo qubes-dom0-update qt5-qtstyleplugins
> >>
> >> and it will work as with any other package.
> >>
> >> That reminds me: Marek, should we set repo_gpgcheck=1 and/or
> >> %_pkgverify_level all in dom0, to protect against mistakes like this?
> >>>
> >>
> > 
>
>

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

Re: [qubes-users] Qubes Manager not honoring colour scheme selection

[Andrew David Wong]

On 7/25/22 4:53 PM, 'taran1s' via qubes-users wrote:
> I tried this but didn't succeed.
> 
> sudo qubes-dom0-update qt5-qtstyleplugins
> sudo qubes-dom0-update
> export QT_QPA_PLATFORMTHEME=gtk2
> 
> cat /etc/environment QT_QPA_PLATFORMTHEME=gtk2
> cat: 'QT_QPA_PLATFORMTHEME=gtk2': No such file or directory
> 
> Qube Manager is still white ^^. Any ideas?
> 

You have to actually edit the file `/etc/environment` in order to insert the 
string `QT_QPA_PLATFORMTHEME=gtk2` into that file, then reboot afterward.

P.S. -- Please avoid top-posting.

> 
> TheGardner:
>> Thanks very much Demi Marie.
>> Then this should be the correct way:
>>
>> Source & Info: https://github.com/QubesOS/qubes-issues/issues/7389
>>
>>
>> Install the package qt5-qtstyleplugins with:
>>
>> sudo qubes-dom0-update qt5-qtstyleplugins
>>
>> then insert in /etc/environment:
>>
>> -[Start]-
>> QT_QPA_PLATFORMTHEME=gtk2
>> -[End]---
>>
>> in dom0 terminal do:
>>
>> export QT_QPA_PLATFORMTHEME=gtk2
>>
>> ---
>>
>> finally you can check, if all changes were set & working:
>>
>> [TheGardner@dom0]$ cat /etc/environment
>> QT_QPA_PLATFORMTHEME=gtk2
>>
>> [TheGardner@dom0]$ echo $QT_QPA_PLATFORMTHEME
>> gtk2
>>
>> [TheGardner@dom0]$ sudo dnf info qt5-qtstyleplugins
>> Qubes OS Repository for Dom0
>>    1.9 MB/s | 3.0 kB 00:00
>> Installed Packages
>> Name : qt5-qtstyleplugins
>> Version  : 5.0.0
>> Release  : 39.fc32
>> Architecture : x86_64
>> Size : 1.2 M
>> Source   : qt5-qtstyleplugins-5.0.0-39.fc32.src.rpm
>> Repository   : @System
>>   From repo    : qubes-dom0-cached
>> Summary  : Classic Qt widget styles
>> URL  : https://github.com/qtproject/qtstyleplugins
>> License  : LGPLv2 or GPLv2
>> Description  : Classic Qt widget styles, including cleanlooks, motif,
>> plastique, qgtk.
>>
>> Demi Marie Obenour schrieb am Samstag, 23. Juli 2022 um 04:07:18 UTC+2:
>>
>> On Fri, Jul 22, 2022 at 05:45:13PM -0700, TheGardner wrote:
> Great! It's working now with the following steps in dom0 terminal:
>
> Download qt5-qtstyleplugins RPM file from:
>
>
>> https://kojipkgs.fedoraproject.org//packages/qt5-qtstyleplugins/5.0.0/39.fc32/x86_64/qt5-qtstyleplugins-5.0.0-39.fc32.x86_64.rpm
>
> Move it from your AppVM to dom0 with:
>
> qvm-run --pass-io  'cat
> /home/user/Download/qt5-qtstyleplugins-5.0.0-39.fc32.x86_64.rpm' >
>
>> /home//Downloads/qt5-qtstyleplugins-5.0.0-39.fc32.x86_64.rpm
>
> Install the package with:
>
> sudo dnf install -y qt5-qtstyleplugins-5.0.0-39.fc32.x86_64.rpm
>>
>> This is not safe. You can do:
>>
>> sudo qubes-dom0-update qt5-qtstyleplugins
>>
>> and it will work as with any other package.
>>
>> That reminds me: Marek, should we set repo_gpgcheck=1 and/or
>> %_pkgverify_level all in dom0, to protect against mistakes like this?
>>>
>>
> 

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

Re: [qubes-users] Qubes Manager not honoring colour scheme selection

['taran1s' via qubes-users]

I tried this but didn't succeed.

sudo qubes-dom0-update qt5-qtstyleplugins
sudo qubes-dom0-update
export QT_QPA_PLATFORMTHEME=gtk2

cat /etc/environment QT_QPA_PLATFORMTHEME=gtk2
cat: 'QT_QPA_PLATFORMTHEME=gtk2': No such file or directory

Qube Manager is still white ^^. Any ideas?


TheGardner:
> Thanks very much Demi Marie.
> Then this should be the correct way:
>
> Source & Info: https://github.com/QubesOS/qubes-issues/issues/7389
>
>
> Install the package qt5-qtstyleplugins with:
>
> sudo qubes-dom0-update qt5-qtstyleplugins
>
> then insert in /etc/environment:
>
> -[Start]-
> QT_QPA_PLATFORMTHEME=gtk2
> -[End]---
>
> in dom0 terminal do:
>
> export QT_QPA_PLATFORMTHEME=gtk2
>
> ---
>
> finally you can check, if all changes were set & working:
>
> [TheGardner@dom0]$ cat /etc/environment
> QT_QPA_PLATFORMTHEME=gtk2
>
> [TheGardner@dom0]$ echo $QT_QPA_PLATFORMTHEME
> gtk2
>
> [TheGardner@dom0]$ sudo dnf info qt5-qtstyleplugins
> Qubes OS Repository for Dom0
>1.9 MB/s | 3.0 kB 00:00
> Installed Packages
> Name : qt5-qtstyleplugins
> Version  : 5.0.0
> Release  : 39.fc32
> Architecture : x86_64
> Size : 1.2 M
> Source   : qt5-qtstyleplugins-5.0.0-39.fc32.src.rpm
> Repository   : @System
>   From repo: qubes-dom0-cached
> Summary  : Classic Qt widget styles
> URL  : https://github.com/qtproject/qtstyleplugins
> License  : LGPLv2 or GPLv2
> Description  : Classic Qt widget styles, including cleanlooks, motif,
> plastique, qgtk.
>
> Demi Marie Obenour schrieb am Samstag, 23. Juli 2022 um 04:07:18 UTC+2:
>

On Fri, Jul 22, 2022 at 05:45:13PM -0700, TheGardner wrote:

Great! It's working now with the following steps in dom0 terminal:

Download qt5-qtstyleplugins RPM file from:



https://kojipkgs.fedoraproject.org//packages/qt5-qtstyleplugins/5.0.0/39.fc32/x86_64/qt5-qtstyleplugins-5.0.0-39.fc32.x86_64.rpm


Move it from your AppVM to dom0 with:

qvm-run --pass-io  'cat
/home/user/Download/qt5-qtstyleplugins-5.0.0-39.fc32.x86_64.rpm' >


/home//Downloads/qt5-qtstyleplugins-5.0.0-39.fc32.x86_64.rpm


Install the package with:

sudo dnf install -y qt5-qtstyleplugins-5.0.0-39.fc32.x86_64.rpm


This is not safe. You can do:

sudo qubes-dom0-update qt5-qtstyleplugins

and it will work as with any other package.

That reminds me: Marek, should we set repo_gpgcheck=1 and/or
%_pkgverify_level all in dom0, to protect against mistakes like this?

>>
>

--
Kind regards
taran1s

gpg: 12DDA1FE5FB39C110F3D1FD5A664B90BD3BE59B3

--
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/353e6a9e-5f6f-72d3-e67b-85c47511dd08%40mailbox.org.

[qubes-users] Installer does not work, no templates to install

['felix' via qubes-users]

I want to reinstall Qubes 4.1, but I cannot select any templates in the 
installer.


Qubes 4.0 and 4.1 were already running successfully on my device and 
Qubes 4.0 can still be installed successfully.


In the install menu, Fedora, Debian and Whonix are missing from the 
software selection, which is why all templates and app vm's are missing 
after the installation and only dom0 remains.


On Github an issue was reported, but closed again ( Installation: 
Anaconda: Not asking for VNC because we don't have a network #7490 ). 
However, there is no solution.


How can I fix it?


--
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/32e704e2-2b89-cd5e-618c-6d370ae3188f%40mailbox.org.

Re: [qubes-users] Qubes Manager not honoring colour scheme selection

[Andrew David Wong]

On 7/22/22 7:07 PM, Demi Marie Obenour wrote:
> [...]
> 
> That reminds me: Marek, should we set repo_gpgcheck=1 and/or
> %_pkgverify_level all in dom0, to protect against mistakes like this?

FWIW: https://github.com/QubesOS/qubes-issues/issues/7628

-- 
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/99b60f08-76a9-9973-e141-b0b18fb4bb00%40qubes-os.org.

[qubes-users] Problems with Timesynchronization

[Viktor Ransmayr]

Hello community,

I do have issues with the timesychronization of VMs in my Qubes OS 4.1.1 
system.

I was reading the information provided in [1] - and - verified that 
'sys-net' is my clock VM.

However I was not able to resolve my issues ...

Here are the logs:



[vr@dom0 ~]$ qubes-prefs clockvm
sys-net
[vr@dom0 ~]$ 





[user@sys-net ~]$ 
[user@sys-net ~]$ timedatectl
   Local time: Sat 2022-07-23 19:54:36 CEST
   Universal time: Sat 2022-07-23 17:54:36 UTC
 RTC time: Sat 2022-07-23 17:54:36
Time zone: Europe/Berlin (CEST, +0200)
System clock synchronized: no
  NTP service: inactive
  RTC in local TZ: no
[user@sys-net ~]$ 





[user@sys-net ~]$ 
[user@sys-net ~]$ systemctl restart systemd-timesyncd
[user@sys-net ~]$ 
[user@sys-net ~]$ 
[user@sys-net ~]$ systemctl status systemd-timesyncd
○ systemd-timesyncd.service - Network Time Synchronization
 Loaded: loaded (/usr/lib/systemd/system/systemd-timesyncd.service; 
enabled>
Drop-In: /usr/lib/systemd/system/systemd-timesyncd.service.d
 └─30_qubes.conf
 Active: inactive (dead)
  Condition: start condition failed at Sat 2022-07-23 20:06:48 CEST; 
14s ago
 └─ ConditionPathExists=/var/run/qubes-service/clocksync 
was not met
   Docs: man:systemd-timesyncd.service(8)
lines 1-8/8 (END)

[user@sys-net ~]$ 





[user@sys-net ~]$ 
[user@sys-net ~]$ cd /var/run/qubes-service
[user@sys-net qubes-service]$ ls
network-manager  qubes-network   qubes-updates-proxy
qubes-firewall   qubes-update-check
[user@sys-net qubes-service]$ 



Do you have any advice on how to continue from here - or - what else to 
check?

With kind regards,

Viktor

---

[1] 
https://github.com/Qubes-Community/Contents/blob/master/docs/system/clock-time.md

-- 
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/9d6644d7-4e4e-491e-a4d2-4a372304bc69n%40googlegroups.com.

Re: [qubes-users] dvm considerably slower on R4.1

[Qubes]

David Hobach wrote:

You can see your pool driver by executing `qvm-pool`.

And the latest version of my scripts will always be available at [1].

Btw somehow one gets used to the worse performance after a while...

[1] https://github.com/3hhh/qubes-performance



Thank you very much.

And i really appreciate the efforts that you have already put into 
resolving this issue. You are really helping your community 
tremendously. High five.


This is the first time i am suffering from Qubes performance issues and 
i have to say it is quite frustrating. If 4.0 wasn't going EOL next 
month i would continue using 4.0 for now.


--
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/84f172a7-449b-35a7-94ab-203f1f941b22%40ak47.co.za.

Re: [qubes-users] dvm considerably slower on R4.1

[David Hobach]

You can see your pool driver by executing `qvm-pool`.

And the latest version of my scripts will always be available at [1].

Btw somehow one gets used to the worse performance after a while...

[1] https://github.com/3hhh/qubes-performance

Mine currently looks like this:

Qubes release 4.1 (R4.1)
dom0 kernel: 5.10.109-1.fc32.qubes.x86_64
dom0 Xen: 4.14.5
VM kernel: 5.15.52-1.fc32

Xen:
  qrexec startup: 240 ms
  Qubes DB: 8800 ms
  VM handover: 8901 ms
Linux:
  kernel: 4480 ms
  system: 4298 ms
  user: 178 ms
  system critical-chain:
multi-user.target @4.298s
└─qubes-qrexec-agent.service @4.164s +133ms
  └─systemd-user-sessions.service @4.102s +31ms
└─network.target @4.092s
  └─qubes-network-uplink.service @2.638s +1.447s
└─basic.target @2.544s
  └─sockets.target @2.544s
└─dbus.socket @2.542s
  └─sysinit.target @2.531s
└─systemd-update-utmp.service @2.482s +47ms
  └─systemd-tmpfiles-setup.service @2.349s +122ms
└─local-fs.target @2.317s
  └─run-user-1000.mount @4.773s
└─local-fs-pre.target @1.427s
  └─systemd-tmpfiles-setup-dev.service @1.150s 
+276ms
└─systemd-sysusers.service @1.090s +58ms
  └─systemd-remount-fs.service @1.006s +80ms
└─systemd-fsck-root.service @771ms +233ms
  └─systemd-journald.socket @572ms
└─-.mount @519ms
  └─-.slice @519ms
  qrexec service critical-chain:
qubes-qrexec-agent.service +133ms
└─systemd-user-sessions.service @4.102s +31ms
  └─network.target @4.092s
└─qubes-network-uplink.service @2.638s +1.447s
  └─basic.target @2.544s
└─sockets.target @2.544s
  └─dbus.socket @2.542s
└─sysinit.target @2.531s
  └─systemd-update-utmp.service @2.482s +47ms
└─systemd-tmpfiles-setup.service @2.349s +122ms
  └─local-fs.target @2.317s
└─run-user-1000.mount @4.773s
  └─local-fs-pre.target @1.427s
└─systemd-tmpfiles-setup-dev.service @1.150s +276ms
  └─systemd-sysusers.service @1.090s +58ms
└─systemd-remount-fs.service @1.006s +80ms
  └─systemd-fsck-root.service @771ms +233ms
└─systemd-journald.socket @572ms
  └─-.mount @519ms
└─-.slice @519ms
  qubes.GetDate: n/a
  qubes.WindowIconUpdater: n/a
  qrexec service: 4102 ms
qrexec (1st run):
  exec time: 4602 ms (depends on clock sync)
  return: 5479 ms
qrexec (2nd run):
  exec time: -105 ms (depends on clock sync)
  return: 782 ms
Overall: 23202 ms (excl. 2nd qrexec run)

--
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/640be919-fa6e-b3b9-350f-012fe0f6549e%40hackingthe.net.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [qubes-users] Qubes Manager not honoring colour scheme selection

[TheGardner]

Thanks very much Demi Marie.
Then this should be the correct way:

Source & Info: https://github.com/QubesOS/qubes-issues/issues/7389


Install the package qt5-qtstyleplugins with:

sudo qubes-dom0-update qt5-qtstyleplugins

then insert in /etc/environment:

-[Start]-
QT_QPA_PLATFORMTHEME=gtk2
-[End]---

in dom0 terminal do:

export QT_QPA_PLATFORMTHEME=gtk2

---

finally you can check, if all changes were set & working:

[TheGardner@dom0]$ cat /etc/environment
QT_QPA_PLATFORMTHEME=gtk2

[TheGardner@dom0]$ echo $QT_QPA_PLATFORMTHEME
gtk2

[TheGardner@dom0]$ sudo dnf info qt5-qtstyleplugins
Qubes OS Repository for Dom0   
  1.9 MB/s | 3.0 kB 00:00
Installed Packages
Name : qt5-qtstyleplugins
Version  : 5.0.0
Release  : 39.fc32
Architecture : x86_64
Size : 1.2 M
Source   : qt5-qtstyleplugins-5.0.0-39.fc32.src.rpm
Repository   : @System
 From repo: qubes-dom0-cached
Summary  : Classic Qt widget styles
URL  : https://github.com/qtproject/qtstyleplugins
License  : LGPLv2 or GPLv2
Description  : Classic Qt widget styles, including cleanlooks, motif, 
plastique, qgtk.

Demi Marie Obenour schrieb am Samstag, 23. Juli 2022 um 04:07:18 UTC+2:

> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA512
>
> On Fri, Jul 22, 2022 at 05:45:13PM -0700, TheGardner wrote:
> > Great! It's working now with the following steps in dom0 terminal:
> > 
> > Download qt5-qtstyleplugins RPM file from: 
> > 
> > 
> https://kojipkgs.fedoraproject.org//packages/qt5-qtstyleplugins/5.0.0/39.fc32/x86_64/qt5-qtstyleplugins-5.0.0-39.fc32.x86_64.rpm
> > 
> > Move it from your AppVM to dom0 with:
> > 
> > qvm-run --pass-io  'cat 
> > /home/user/Download/qt5-qtstyleplugins-5.0.0-39.fc32.x86_64.rpm' > 
> > 
> /home//Downloads/qt5-qtstyleplugins-5.0.0-39.fc32.x86_64.rpm
> > 
> > Install the package with:
> > 
> > sudo dnf install -y qt5-qtstyleplugins-5.0.0-39.fc32.x86_64.rpm
>
> This is not safe. You can do:
>
> sudo qubes-dom0-update qt5-qtstyleplugins
>
> and it will work as with any other package.
>
> That reminds me: Marek, should we set repo_gpgcheck=1 and/or
> %_pkgverify_level all in dom0, to protect against mistakes like this?
> - -- 
> Sincerely,
> Demi Marie Obenour (she/her/hers)
> Invisible Things Lab
> -BEGIN PGP SIGNATURE-
>
> iQIzBAEBCgAdFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmLbV8wACgkQsoi1X/+c
> IsEEPA//XejMBSNBzh4aZJuxfWmvK1ie50x8oK7/NH8QpIEeFIWMRaZNZSs9RxVi
> cMC17g62ZSyoxb9bwwFHsF3SLxmuSvl1ucBeHSQqfS5SdkwYOeiml38bNXauryaI
> fGjVzq6CJFNSfBbhDMcskkP8wcKmBrQFXlK5yfSAZ7OL/Cv5i5yGeuXka1Ij9qLY
> 8OY/qe331pAa++n4KyJp3Qvx3/tS/ZuaKna8Tt6GincXE6RdnsvWm2iP6HfFsIRb
> lk3KSyM6fodA5uyCJGtcFAY6sJi9/5Fy8TlavMZxtv3xVQqVjZRVsKnMsld2TXnS
> qPNSwGrKa6P9Z8gMUIufcLpNlNWccP5wvAOGtcJP6xVV9ALfXUGnnBP9scd3mGqo
> 7RighrDtMdVhbxHu268iuduILHe/TWcWxpRigrOt2+oUNBD/PNAeUZkKx9slFisY
> sof5/HDNDBNnfqwCPxjtn54PEfa+biK+cWwcjC0gov06otIRskp/Cwr193kwJi/D
> K4KppbHsk1swCuQf06Cy/X2yvq67Xbe7g/HgqXrRgFPkPuWpSSpRWIeIdDaklCej
> eXvQNQRbhAk6euYHJLjV8XMW1eC06Kaeo+ZvtEwBeZlBdnfkA1VlFc+XLfb2L3L/
> 9dff6pkqjr82mS64hGB9ocDRZgx3iikD5F79OL/X/ZcTF+uC+Wo=
> =p8Nh
> -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/099870c0-b61c-4b2e-8dd8-cd0619eeca65n%40googlegroups.com.

Re: [qubes-users] Qubes Manager not honoring colour scheme selection

[Demi Marie Obenour]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA512

On Fri, Jul 22, 2022 at 05:45:13PM -0700, TheGardner wrote:
> Great! It's working now with the following steps in dom0 terminal:
> 
> Download qt5-qtstyleplugins RPM file from: 
> 
> https://kojipkgs.fedoraproject.org//packages/qt5-qtstyleplugins/5.0.0/39.fc32/x86_64/qt5-qtstyleplugins-5.0.0-39.fc32.x86_64.rpm
> 
> Move it from your AppVM to dom0 with:
> 
> qvm-run --pass-io  'cat 
> /home/user/Download/qt5-qtstyleplugins-5.0.0-39.fc32.x86_64.rpm' > 
> /home//Downloads/qt5-qtstyleplugins-5.0.0-39.fc32.x86_64.rpm
> 
> Install the package with:
> 
> sudo dnf install -y qt5-qtstyleplugins-5.0.0-39.fc32.x86_64.rpm

This is not safe.  You can do:

sudo qubes-dom0-update qt5-qtstyleplugins

and it will work as with any other package.

That reminds me: Marek, should we set repo_gpgcheck=1 and/or
%_pkgverify_level all in dom0, to protect against mistakes like this?
- -- 
Sincerely,
Demi Marie Obenour (she/her/hers)
Invisible Things Lab
-BEGIN PGP SIGNATURE-

iQIzBAEBCgAdFiEEdodNnxM2uiJZBxxxsoi1X/+cIsEFAmLbV8wACgkQsoi1X/+c
IsEEPA//XejMBSNBzh4aZJuxfWmvK1ie50x8oK7/NH8QpIEeFIWMRaZNZSs9RxVi
cMC17g62ZSyoxb9bwwFHsF3SLxmuSvl1ucBeHSQqfS5SdkwYOeiml38bNXauryaI
fGjVzq6CJFNSfBbhDMcskkP8wcKmBrQFXlK5yfSAZ7OL/Cv5i5yGeuXka1Ij9qLY
8OY/qe331pAa++n4KyJp3Qvx3/tS/ZuaKna8Tt6GincXE6RdnsvWm2iP6HfFsIRb
lk3KSyM6fodA5uyCJGtcFAY6sJi9/5Fy8TlavMZxtv3xVQqVjZRVsKnMsld2TXnS
qPNSwGrKa6P9Z8gMUIufcLpNlNWccP5wvAOGtcJP6xVV9ALfXUGnnBP9scd3mGqo
7RighrDtMdVhbxHu268iuduILHe/TWcWxpRigrOt2+oUNBD/PNAeUZkKx9slFisY
sof5/HDNDBNnfqwCPxjtn54PEfa+biK+cWwcjC0gov06otIRskp/Cwr193kwJi/D
K4KppbHsk1swCuQf06Cy/X2yvq67Xbe7g/HgqXrRgFPkPuWpSSpRWIeIdDaklCej
eXvQNQRbhAk6euYHJLjV8XMW1eC06Kaeo+ZvtEwBeZlBdnfkA1VlFc+XLfb2L3L/
9dff6pkqjr82mS64hGB9ocDRZgx3iikD5F79OL/X/ZcTF+uC+Wo=
=p8Nh
-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/YttXy5xoHaOVv7bM%40itl-email.

Re: [qubes-users] Qubes Manager not honoring colour scheme selection

[TheGardner]

Great! It's working now with the following steps in dom0 terminal:

Download qt5-qtstyleplugins RPM file from: 

https://kojipkgs.fedoraproject.org//packages/qt5-qtstyleplugins/5.0.0/39.fc32/x86_64/qt5-qtstyleplugins-5.0.0-39.fc32.x86_64.rpm

Move it from your AppVM to dom0 with:

qvm-run --pass-io  'cat 
/home/user/Download/qt5-qtstyleplugins-5.0.0-39.fc32.x86_64.rpm' > 
/home//Downloads/qt5-qtstyleplugins-5.0.0-39.fc32.x86_64.rpm

Install the package with:

sudo dnf install -y qt5-qtstyleplugins-5.0.0-39.fc32.x86_64.rpm

then insert in /etc/environment:

-[Start]-

QT_QPA_PLATFORMTHEME=gtk2

-[End]---

finally you can check, if all changes were set & working:

[TheGardner@dom0]$ cat /etc/environment
QT_QPA_PLATFORMTHEME=gtk2

[TheGardner@dom0]$ echo $QT_QPA_PLATFORMTHEME
gtk2

[TheGardner@dom0]$ sudo dnf info qt5-qtstyleplugins
Qubes OS Repository for Dom0   
  1.9 MB/s | 3.0 kB 00:00
Installed Packages
Name : qt5-qtstyleplugins
Version  : 5.0.0
Release  : 39.fc32
Architecture : x86_64
Size : 1.2 M
Source   : qt5-qtstyleplugins-5.0.0-39.fc32.src.rpm
Repository   : @System
 From repo: qubes-dom0-cached
Summary  : Classic Qt widget styles
URL  : https://github.com/qtproject/qtstyleplugins
License  : LGPLv2 or GPLv2
Description  : Classic Qt widget styles, including cleanlooks, motif, 
plastique, qgtk.

FINISHED! 
Just restart your machine and voila --> Qubes Manager in dark style!

TheGardner schrieb am Freitag, 22. Juli 2022 um 12:39:31 UTC-4:

> seems so, my dark Qubes Manager went white from 4.0 to 4.1 and I didn't 
> understand why and how to change, since today
>
> Qubes schrieb am Freitag, 22. Juli 2022 um 04:20:46 UTC-4:
>
>> Sven Semmler wrote:
>> > This is quite easy to fix by installing qt5-qtsyleplugins in dom0 and 
>> > exporting QT_QPA_PLATFORMTHEME=gtk2 in /etc/environment
>> > 
>> > --> https://github.com/QubesOS/qubes-issues/issues/7389
>> > 
>>
>> Did the Qubes Manager implementation change from 4.0 to 4.1? I am just 
>> asking because i have checked my 4.0 installation and it neither has 
>> qt5-qtsyleplugins installed nor does it have an environment variable 
>> configured for it.
>>
>> It is just really odd that this would be needed now when it wasn't 
>> needed in the past. It sounds not right having to install software in 
>> dom0, something we guard against, just to get Qubes Manager to honor 
>> dark theme settings.
>>
>> Isn't Qubes Manager a GTK application? The qt5-qtsyleplugins and the 
>> corresponding environment variable should only be necessary for Qt (KDE) 
>> style applications.
>>
>>
>>

-- 
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/d475e772-59bd-4e50-a14d-e4de0afb56b1n%40googlegroups.com.

Re: [qubes-users] dvm considerably slower on R4.1

[Qubes]

David Hobach wrote:

There can be multiple reasons for a slower 4.1 experience. Known ones are:

1. CPU runs at ~800 MHz or so [1]
2. You're a file pool user. File pools were serialized in 4.1, likely 
dropping their performance by ~30-50%. [2]

3. Possibly further issues in 4.1 [2].

[1] https://github.com/QubesOS/qubes-issues/issues/4604


If 4604 was my issue my understanding is that i would have experienced 
performance issues on 4.0 as well.



[2] https://github.com/QubesOS/qubes-issues/issues/7075


I have read through 7075 but i am still distilling the info. It does 
sound like i may be affected by the same issue.


What makes this debacle so uncomfortable is the fact that time spent 
waiting is cumulative and at the end of the day it adds up to a lot of 
time wasted.




Anyway it seems that just a few users are affected. Others report 8s VM 
startup performance or less (see forum).


I will try and make time to run some additional tests with the help of 
the scripts you provided in your detailed 7075 bug report. Would you 
mind sending me your updated scripts?






Thanks a lot for pointing these out to me.

--
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/c2bd6407-8a83-3c68-f9bf-aab1ac3fe130%40ak47.co.za.

Re: [qubes-users] dvm considerably slower on R4.1

[David Hobach]

There can be multiple reasons for a slower 4.1 experience. Known ones are:

1. CPU runs at ~800 MHz or so [1]
2. You're a file pool user. File pools were serialized in 4.1, likely dropping 
their performance by ~30-50%. [2]
3. Possibly further issues in 4.1 [2].

[1] https://github.com/QubesOS/qubes-issues/issues/4604
[2] https://github.com/QubesOS/qubes-issues/issues/7075

Anyway it seems that just a few users are affected. Others report 8s VM startup 
performance or less (see forum).

--
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/a0253a4b-57bf-cbb0-0146-d67c962c48e8%40hackingthe.net.


smime.p7s
Description: S/MIME Cryptographic Signature

Re: [qubes-users] Qubes Manager not honoring colour scheme selection

[TheGardner]

seems so, my dark Qubes Manager went white from 4.0 to 4.1 and I didn't 
understand why and how to change, since today

Qubes schrieb am Freitag, 22. Juli 2022 um 04:20:46 UTC-4:

> Sven Semmler wrote:
> > This is quite easy to fix by installing qt5-qtsyleplugins in dom0 and 
> > exporting QT_QPA_PLATFORMTHEME=gtk2 in /etc/environment
> > 
> > --> https://github.com/QubesOS/qubes-issues/issues/7389
> > 
>
> Did the Qubes Manager implementation change from 4.0 to 4.1? I am just 
> asking because i have checked my 4.0 installation and it neither has 
> qt5-qtsyleplugins installed nor does it have an environment variable 
> configured for it.
>
> It is just really odd that this would be needed now when it wasn't 
> needed in the past. It sounds not right having to install software in 
> dom0, something we guard against, just to get Qubes Manager to honor 
> dark theme settings.
>
> Isn't Qubes Manager a GTK application? The qt5-qtsyleplugins and the 
> corresponding environment variable should only be necessary for Qt (KDE) 
> style applications.
>
>
>

-- 
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/9f741701-4b4b-4703-acc9-42930722c4ban%40googlegroups.com.

Re: [qubes-users] dvm considerably slower on R4.1

[Qubes]

Qubes wrote:

Qubes wrote:
Has the 4.1 as well as 4.1.1, because I did test on both, release 
added additional overhead to the creation of a dvm?


I have identical dvm's for Firefox on 4.0 and 4.1 and on 4.1 it takes 
almost, in the region of 0.5 - 0.75 seconds almost, **double** the 
time for a new dvm to be ready for usage, 18 seconds vs 36 (both 
rounded for convenience).


That is quite a hefty difference. Is there any explanation for this 
behavior?




This really is quite an annoyance, my system has slowed down quite a bit 
in the area of dvm's and i use them intensively. Can someone help me 
understand this problem? Where must i scratch under the bonnet to 
determine why dvm creation takes so much longer on my 4.1 install 
compared to my 4.0 install. I have two identical SSD's (make, model, 
etc) one installed with 4.0 and the other with 4.1. The SSD i used for 
the 4.1 install has much less mileage on so general wear of the SSD 
should effect my 4.1 install less.




It is not only dvm creation that is slow any VM boot time has increased 
significantly.


--
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/b60b0cd6-1b52-6440-5dd2-f732f59a125b%40ak47.co.za.

Re: [qubes-users] dvm considerably slower on R4.1

[Qubes]

Qubes wrote:
Has the 4.1 as well as 4.1.1, because I did test on both, release added 
additional overhead to the creation of a dvm?


I have identical dvm's for Firefox on 4.0 and 4.1 and on 4.1 it takes 
almost, in the region of 0.5 - 0.75 seconds almost, **double** the time 
for a new dvm to be ready for usage, 18 seconds vs 36 (both rounded for 
convenience).


That is quite a hefty difference. Is there any explanation for this 
behavior?




This really is quite an annoyance, my system has slowed down quite a bit 
in the area of dvm's and i use them intensively. Can someone help me 
understand this problem? Where must i scratch under the bonnet to 
determine why dvm creation takes so much longer on my 4.1 install 
compared to my 4.0 install. I have two identical SSD's (make, model, 
etc) one installed with 4.0 and the other with 4.1. The SSD i used for 
the 4.1 install has much less mileage on so general wear of the SSD 
should effect my 4.1 install less.


--
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/84aee455-c26f-6aad-f1b4-640010959180%40ak47.co.za.