[qubes-users] Re: Fullscreen Multiple Monitors not possible?
Thank you very much! The idea does make maximum sense, I think. However, without turning on full screen, there is the problem that the window - indeed created large enough to cover the full screen - will be truncated by the frame decorations. That brings issues particularly with the task bar. Once one clicks full screen, the screen gets limited to one monitor (-> "full monitor"). As far as I understand, one has the following instruments available in Qubes and freerdp: - allow_fullscreen and override_redirect_protection in guid.conf in dom0 - the trapezoid slider "floatbar" created by xfreerdp /floatbar:sticky:off,show:always As far as I can tell, no combination of these instruments can resolve the issue. In Debian, the floatbar does allow maximizing the window across multiple monitors, but not in Qubes. I nice solution might have been to accept the windows decoration and create the window slightly smaller (less height would be enough, because the top decoration is the main issue. That, however, does not seem to work because of freerdp: You need to set "xrfreerdp /multimon" but then you are unable to reduce the height. You can set a large screen, but without multimon, it does not extend accross monitors. This seems to be an endless cycle. It would be good to know, if developers intend to change this behavior or not. I can accept the security concept of not welcoming fullscreen too much. However, when this is fully possible with one monitor but not possible with two monitors, that does not seem fully consistent - either or would make sense, but the number of monitors should not be the decisive factor from a concept standpoint. Vít Šesták schrieb am Samstag, 6. März 2021 um 22:12:00 UTC+1: > I guess that the xfreerdp just creates a window that is large enough and > positioned in a way that hides the window borders. However, Qubes OS AFAIK > does not allow the positioning for security reasons. However, you can do > this yourself. It depends on your desktop environment and configuration, > there is rough howto for Xfce: > > * Adjust the window position by alt+left-click and movement. > * Adjust the window size by alt+right-click and movement. > * If needed, make the window always-on-top by Alt+Space and selecting > Always on Top. > > I am pretty sure this can be automated by xdotool or something similar. > > Regards, > Vit Sestak 'v6ak' > > On Saturday, March 6, 2021 at 8:04:32 AM UTC+1 mic...@schefczyk.net wrote: > >> Dear All, >> >> In QubesOS R4.0, I have two monitors connected to form a large screen >> made up by two monitors side by side. I would like to achieve what does >> work in Debian, for example, that is a fullscreen window covering the >> entire screen (i. e., both monitors). This is particularly useful in >> rdp-seccions using freerdp. It can be achieved using: >> >> xfreerdp /multimon >> >> This leads to a freerdp connection across multiple monitors at leaset in >> Debian GNOME. >> >> In QubesOS R4.0 it does work in principle. A window as wide as the set of >> monitors does get created. However, the fullscreen feature does not work. >> As soon as one clicks fullscreen, the window gets confined to one of the >> monitors. Of course, I did allow fullscreen as described here: >> https://www.qubes-os.org/doc/full-screen-mode/ And of corse, everything >> does work well with just one monitor connected. And yes, I do understand >> the security concept of normally not covering the entire screen but showng >> the window decorations including the VM color. >> >> Is there a way to overcome that limitation? If "fullscreen" can be made >> to work across physical monitors in general, xfreerdp /multimon should work >> as well. >> >> Thank you very much! >> >> Michael Schefczyk >> > -- 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/33a6fd49-65ca-4985-bc5e-b5ba2562fb99n%40googlegroups.com.
[qubes-users] Re: Need to fix boot process broken by kernel update. Data is safe.
Hi, Following up on my previous post: I've documented the Qubes boot process to the best of my knowledge in QUBES-BOOTUP.svg @ https://github.com/rshetye/good-karma/ It took some time to document and organize everything. Thanks, Ranjeet On Wednesday, February 10, 2021 at 12:51:56 PM UTC-6 Ranjeet Shetye wrote: > > Hi, > > I got my system up and running. > > It was a problem with the efi boot details. I had installed the latest > kernel (not manually) and that install process somehow messed up the efi > boot as it existed. After boot was broken, the console would show what it > was going to boot but the xen never loaded. Now it does. > > Thank you donoban, Bernhard, and Jinoh for the right pointers. > > I have made a list of steps that helped me gauge the situation. I will > post it within a few hours. > > Regards, > Ranjeet > > On Wed, Feb 10, 2021, 8:21 AM Jinoh Kang wrote: > >> -BEGIN PGP SIGNED MESSAGE- >> Hash: SHA256 >> >> On 2/10/21 3:05 AM, Ranjeet Shetye wrote: >> > Hi, >> > >> > Is there a standard HOWTO I can follow to fix the boot process (to go >> from a grub / xen.cfg that fails to LUKS decrypt and load unencrypted >> rootfs) >> > >> > I am reasonably knowledgeable about Linux. Gaps exist in my knowledge >> regarding BIOS and UEFI boot processes. >> > >> > Unfortunately the grub update for the kernel upgrade seems to have >> messed up the boot process. How do I figure out if it's installed for BIOS >> or UEFI mode ? >> > >> > My data is safe and LUKS encrypted . I can use a live USB to decrypt >> it, access it and I also have made 2 backup copies. >> > >> > So with nothing to lose I tried to fix the boot manually from a live >> USB including creating /etc/default/grub but situation is no better. >> > >> > Between BIOS / (UEFI) / grub2 / xen / vmlinuz / LUKS / LVM2 , I am lost >> where the fix might be. Might be grub flags, grub modules, grub defaults, >> xen cfg, EFI manager etc. Hence my question. >> > >> > Thanks, >> > Ranjeet >> >> Also note that Qubes R4.0 on UEFI does not boot via GRUB -- it boots >> directly via \EFI\qubes\xen.efi. >> >> - -- >> Sincerely, >> Jinoh Kang >> -BEGIN PGP SIGNATURE- >> >> iQJMBAEBCAA2FiEEzGktrvc/U3kFXd9AGlqQRGyEq/UFAmAj67YYHGppbm9oLmth >> bmcua3JAZ21haWwuY29tAAoJEBpakERshKv1oLIP/jjFOQkzyYlMxZWAicelCeiS >> g3k/f8Gg6L7yBEQhXdBSiFVHKz5V35VUcseLk8gqrxxrAuzSuJwRwzno/f/DR7Jk >> 9IIc6LuQNrFjSMt327wqGsXvt7i/AObT8mUHiuKI8CTZOmX5kA1COk5jE5psCWks >> pG4ahB/chbUUS6rgx0JfgitKJopHCN9MXIc+xaJJatoLeJH89rJC/Lu8hSLjYwXx >> /TQIY4MJdM/HHP2dtye/ZbR6NT7kR/f985vqreN2D+83pCjSzqUu1aZt10oh92in >> 4qxel9DkLg0plnwi2AFgLZfHNXmTkR13eoc9awW+L7nZvhZbPKZ3Kt0X/QfWNFK+ >> ThHZzLsWG+BNDU70fWkDJ137GhggfxChANLjX8ltRSgPh7ApIofYfOaoAUqXBz4j >> QF8rYp+xhR5aMIGiXVBYeThHva8P6Zy/JwMq/Bo5hl52FAUwUGl5920+t/W66iTC >> eL3UyRsO9akD5ovbEkCdhkBISy9KDsE5KkI7cKa+ccl08yyTjbLpfZ1etYbIKRSQ >> OOtE0csiByZjS7sUtmgHcbGYRXMLbJ4xQMOptjNrndcY2JM3Di4q+JX/UwAhLO52 >> VYB3zHYBnKDJai5iPFARzoCG86otjlU9/gGbx/4JjKC+SjZ1XI7gZYdfFvF+ZRBf >> OCGR9pkKQunhiNhLJ8OT >> =pSYS >> -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/142aed7a-dd7d-4fbc-bd72-4183b1f0e38fn%40googlegroups.com.
[qubes-users] Re: Fullscreen Multiple Monitors not possible?
I guess that the xfreerdp just creates a window that is large enough and positioned in a way that hides the window borders. However, Qubes OS AFAIK does not allow the positioning for security reasons. However, you can do this yourself. It depends on your desktop environment and configuration, there is rough howto for Xfce: * Adjust the window position by alt+left-click and movement. * Adjust the window size by alt+right-click and movement. * If needed, make the window always-on-top by Alt+Space and selecting Always on Top. I am pretty sure this can be automated by xdotool or something similar. Regards, Vit Sestak 'v6ak' On Saturday, March 6, 2021 at 8:04:32 AM UTC+1 mic...@schefczyk.net wrote: > Dear All, > > In QubesOS R4.0, I have two monitors connected to form a large screen made > up by two monitors side by side. I would like to achieve what does work in > Debian, for example, that is a fullscreen window covering the entire screen > (i. e., both monitors). This is particularly useful in rdp-seccions using > freerdp. It can be achieved using: > > xfreerdp /multimon > > This leads to a freerdp connection across multiple monitors at leaset in > Debian GNOME. > > In QubesOS R4.0 it does work in principle. A window as wide as the set of > monitors does get created. However, the fullscreen feature does not work. > As soon as one clicks fullscreen, the window gets confined to one of the > monitors. Of course, I did allow fullscreen as described here: > https://www.qubes-os.org/doc/full-screen-mode/ And of corse, everything > does work well with just one monitor connected. And yes, I do understand > the security concept of normally not covering the entire screen but showng > the window decorations including the VM color. > > Is there a way to overcome that limitation? If "fullscreen" can be made to > work across physical monitors in general, xfreerdp /multimon should work as > well. > > Thank you very much! > > Michael Schefczyk > -- 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/af8c7604-ef3d-4b35-b264-f2773f76e4f2n%40googlegroups.com.
Re: [qubes-users] [HCL] ASRock B550 Phantom Gaming 4/ac
Very short advice: If you want to use Ryzen 5000 series and your BIOS
version is P1.10 or lower, I suggest you to upgrade BIOS before installing
Qubes OS and before configuring the BIOS.
## Short story
After some research, I decided to update BIOS. While ASRock advertises this
MoBo to be comptabile with Ryzen 5000 series (see
https://www.asrock.com/mb/AMD/B550%20Phantom%20Gaming%204ac/index.asp#Specification
), this seems to be a half-truth. According to their changelog at
https://www.asrock.com/mb/AMD/B550%20Phantom%20Gaming%204ac/index.asp#BIOS
, the BIOS 1.20 description contains "Support AMD Ryzen™ 5000 Series
processors". So, with versions 1.00 and 1.10, you are probably out of luck.
What the BIOS change resolved:
* the rdrand issue with dnf
* the USB issues with my trackball.
One-time issues with the new BIOS version:
* When you flash the BIOS, it resets the settings, so you lose IOMMU etc.
until you configure it again.
* It has probably changed the PCI identifiers, which has caused weird
freezes when starting a VM with a PCI device assigned. Fortunatelly, in my
temporary setup, no VM with any PCI device was configured to start on boot.
If this was not my case, I would probably end up with non-bootable system
and hard debugging...
Not resolved: suspend/resume issues. Symptoms remain the same, including ,
regardless the smt configuration.
Changed: /proc/cpuinfo - at least added rdrand.
## Long story about rdrand
(You probably don't need to read this to make this MoBo working, but you
might be interested for any other reason.)
I've googled for the rdrand issue. Aside from many irelevant results (AMD's
and Intel's issues with bad randomness or Google treating "Xen" in phrase
with "AMD" as typo), I've learnt something:
1. The source that writes those errors is probably this:
https://github.com/gcc-mirror/gcc/blob/master/libstdc%2B%2B-v3/src/c%2B%2B11/random.cc
2. Found the Intel's documentation of the _rdrand32_step instruction (well,
intristic function)
https://software.intel.com/sites/landingpage/IntrinsicsGuide/#text=_rdrand32_step
via https://doc.rust-lang.org/core/arch/x86_64/fn._rdrand32_step.html . So,
the instruction can sometimes just fail without any apparent reason, and
libstdc++ tries 100 times until it fails.
3. I've tried a code that tests _rdrand32_step (adjusted version of testing
program from
https://arstechnica.com/gadgets/2019/10/how-a-months-old-amd-microcode-bug-destroyed-my-weekend/
), see the attachment. It seems to always fail in both Dom0 and DomU.
4. Interesting finding: qubes-dom0-update works well, even though it runs
dnf. I've tried to adjust the command to find the minimal difference that
causes the command to fail/succeed:
$ sudo dnf update --installroot /
Error: random_device: rdrand failed
$ sudo dnf update --installroot /var/lib/qubes/dom0-updates
Last metadata expiration check: 0:44:30 ago on Sat Mar 6 16:25:06 2021.
Dependencies resolved.
Nothing to do.
Complete!
5. Since this seems to be related to a CPU instruction which seems to be
affected by microcode/BIOS, I've decided to update the BIOS. Which seems to
have been the way to go, see above.
Regards,
Vít Šesták 'v6ak'
On Saturday, March 6, 2021 at 12:57:31 AM UTC+1 sv...@svensemmler.org wrote:
> On 3/5/21 5:48 PM, Vít Šesták wrote:
> > Well, I have to correct the claim about rdrand in Fedora 33: It does not
> > resolve the issue. The issue is a bit random, but it still appears.
>
> Hi Vít,
>
> just keep posting your findings to this thread, which is linked from
> your HCL report. So others looking at your report will then find this
> thread and see all the additional information you provide.
>
> I hope you'll be able to figure it out!
>
> Cheers,
> /Sven
>
> --
> public key: https://www.svensemmler.org/0x8F541FB6.asc
> fingerprint: D7CA F2DB 658D 89BC 08D6 A7AA DA6E 167B 8F54 1FB6
>
>
--
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/aed35ee1-097d-4558-bd00-82b3af4a5fddn%40googlegroups.com.
// SPDX-License-Identifier: GPL-2.0
/*
* Copyright (C) 2019 Jason A. Donenfeld . All Rights Reserved.
*
* Compile: `gcc -o test-rdrand -O3 -mrdrnd -std=gnu99 test-rdrand.c`
*/
#include
#include
#include
int main(int argc, char *argv[])
{
for (int j, i = 0; i < 20; ++i) {
for (j = 0; j < 1; ++j) {
uint32_t val = 0;
if (__builtin_ia32_rdrand32_step()) {
printf("RDRAND() = 0x%08x\n", val);
break;
}else{
printf("!");
}
}
if (j == 1) {
puts("RDRAND() = FAIL");
return 1;
}
}
return 0;
}
Re: [qubes-users] each dom0 update check redownload old template
Le 06/03/2021 à 11:29, evado...@gmail.com a écrit : After I remove old fedora-32 template (sudo dnf remove) qubes-dom0-update download it again to cache each time or want to process it each time. How to fix? Hello evadogstar, Is your template used by another AppVM? The [templates uninstalling documentation](https://www.qubes-os.org/doc/templates/#uninstalling) suggests also `dnf remove`, but if it failed, suggest a [manual uninstall](https://www.qubes-os.org/doc/vm-troubleshooting/#can-not-uninstall-a-vm--error-vm-installed-by-package-manager-template-vm-name). Ludovic -- 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/ba2ac2bc-3340-f9d8-e9b6-5b517e44e06f%40zyrianes.net.
[qubes-users] Re: [QubesOS/qubes-issues] Improve Clipboard Experience (#5778)
Well, since the issue was finally closed I will reply here. On 3/6/21 1:39 AM, unman wrote: > I don't understand this example - if the destination is compromised, then > why would there be a need to modify the clipboard? They just capture the > data as is and exfiltrate it - you are hosed, and the Qubes clipboard is > the least of your problems. At destination there is nothing useful to steal (at least not bitcoins) the bitcoin address is not useful for the attacker, it is a public address and private keys are in other uncompromised offline vm. What the attacker tries to do is replace your address in the clipboard to other address (controlled by him), in the hope that you paste it to someone who wants to send funds for you. I'm agree that the attacker could do a lot of additional things but many of them are more difficult, prone to fail, prone to cause detection. So I don't think it is a justification for not having a more secure clipboard and also easier to use which was the main objective. -- 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/69a9b85a-0602-591b-dd7c-5c3912f2a91b%40riseup.net. OpenPGP_signature Description: OpenPGP digital signature
[qubes-users] each dom0 update check redownload old template
Hello, After I remove old fedora-32 template (sudo dnf remove) qubes-dom0-update download it again to cache each time or want to process it each time. How to fix? Thanks Dependencies resolved. Package Arch Version Repository Size Upgrading: qubes-template-fedora-32 noarch 4.0.6-202101091318 qubes-templates-itl 1.5 G Transaction Summary Upgrade 1 Package Total size: 1.5 G DNF will only download packages for the transaction. Downloading Packages: [SKIPPED] qubes-template-fedora-32-4.0.6-202101091318.noarch.rpm: Already downloaded Complete! The downloaded packages were saved in cache until the next successful transaction. You can remove cached packages by executing 'dnf clean packages' -- 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/af13bac4-fdac-44d9-b231-e3aeb9e335afn%40googlegroups.com.
