Four weird issues

[5q8n67f2gvf]

Greetings!

Before I get into what the title is talking about, I wanted to that I love Qubes OS. I can surf the web and even open stuff outside the browser without having to fear that an undiscovered vulnerability would compromise my entire system. Qubes OS should in my opinion be the standard for security-sensitive workloads, e.g. the health sector, journalism, software development, system administration, and so on.

I am using Qubes release 4.1.2 (R4.1) as my daily driver and have noticed a few thing that bother me. I have listed them below in order of decreasing severity.
It is also worth mentioning that my Qubes install boots from UEFI (grub), and my computer has a nVidia GPU and Intel CPU (desktop computer). dom0 has all the latest updates (kernel 6.1.35-1.qubes.fc32.x86_64 and Xen 4.14.5). Some issues were also present with the older LTS (5.15) kernel - I’ll point that out below. I do not have any testing repos enabled.

1. “Glitching” desktop after logging in, sometimes seeing windows open from before shutdown (!?)

When I boot the system, reach the display manager and input my password, what happens is that, before the desktop loads, the screen “glitches” for less than half a second. By “glitch” I mean that the entire screen is covered with grainy, colorful rectangles. This happens after every boot. Sometimes I am able to see a distorted version of the default Qubes wallpaper. Now, this wouldn’t worry me so much, if it weren’t for what I have sometimes seen during the “glitches”.

When I’ve had my system freeze and crash (that’s actually the next issue) with Firefox open in a disposable qube, I’ve seen a (distorted) still of that window after the system starts up again during the aforementioned “glitch”. I am not sure how that is possible, since it dissappears once the desktop properly loads, and the qube is, of course, not running anymore after the reboot.

One time I had an even more perplexing version of the above. During the “glitch”, I saw a text editor window. The catch is that I shut the (regular) qube in which the text editor was running down manually minutes before I restarted the computer.

This leads me to believe that this state is either being saved somewhere on disk (maybe being swapped) or somehow survives a reboot in RAM. I am reluctant to share screenshots of what I’m seeing, since this “glitch” could be memory data somehow being encoded into pixels and being displayed on screen, and I wouldn’t want anyone decoding that.

This “glitching” happens with the latest kernel, but it also happened with the older LTS kernel (5.15). It has been happening for as long as I can remember.

I have tried searching for this issue on this forum and elsewhere on the Internet as well, but haven’t seen anything similar reported before.

2. Entire system freezes and crashes

Every once in a while my entire system suddenly freezes and after a few seconds it shuts down and starts back up by itself. Most of the time it happens when closing the disposable qube window, which would cause the qube to be killed and removed, but it has happened at more random moments as well. Next boot takes a bit longer, but I believe that’s because the sys-* disposables and other disposable qubes that were running before the crash need to be cleaned up before continuing.

I have gone through the journal and other log files to try to find out whether or not anything was reported before the crash, but all I have seen is that normal log output suddenly ends, followed by logs of the system starting up.

This issue happened definitely with the 5.15 kernel, I’m pretty sure it has happened at least once with the latest kernel as well.
Possibly related: QubesOS freeze, crash and reboots

3. Not powering off

This only started happening with the latest kernel. Sometimes when I shut down the computer, it wont power off. It’ll go through the normal shut down procedure, but hangs at the very last line usually shown before powering off, which is something along the lines of
nouveau ... DRM: GPU lockup - switching to software
This line is displayed during proper shut down as well, only difference is that immediately after that the computer should power off.

4. USBGuard message during boot

This also appeared with the latest kernel. Sometimes, during boot, before the disk unlock screen comes up, a message is displayed:
dracut-cmdline: Warning: The unit file, source configuration file or drop-ins of usbguard.service changed on disk. Run 'systemctl daemon-reload' to reload units.

That message is also visible when hitting ESC on the disk unlock screen to get the console/text view.
This is similar to Qubes shutdowns, but in my case, the system boots up normally. This doesn’t happen on every boot and is somewhat rare, but when it does, rebooting before unlocking the disk makes it go away.

Issues 1 and 2 are more important than the rest, but I thought I’d list everything, since I’m already making a post.
Maybe anyone has any clues about any of these issues.
TIA!

[fsflover]

Hi @5q8n67f2gvf, welcome to the Community! I’m happy that you like Qubes OS!

@5q8n67f2gvf

Qubes OS should in my opinion be the standard for security-sensitive workloads, e.g. the health sector, journalism, software development, system administration, and so on.

Indeed, and here is a relevant discussion: Why hasn't "Qubes way" become standard?.

@5q8n67f2gvf

have noticed a few thing that bother me

Actually, it’s better to create a separate topic for every issue that you have. In this way, it’s easier for new users to find the solutions to their problems.

@5q8n67f2gvf

1. “Glitching” desktop after logging in, sometimes seeing windows open from before shutdown (!?)

I am not an expert here, but it might be related to the nVidia drivers. See this and also there should be some solutions on this forum.

[tempmail]

@5q8n67f2gvf

USBGuard message during boot

Qubes shutdowns

When a service is changed, which properly happened in the update, the command systemctl daemon-reload needs to be run. The warning just tells you it hasn’t happened, and the old version is being used. This is unlikely to result in your system rebooting. Try booting an old kernel, if your system can’t boot after an update it’s often related to the kernel. At the blue boot screen, you can use the advanced menu option to select older kernels.

[augsch]

Issue 2, and 3 are most likely to be different phenomenon from the same cause: a malfunctioning gpu driver.

Issue 1 is because the VRAM of your GPU doesn’t get correctly cleaned up, which is exactly the reason Qubes OS doesn’t utilise GPU acceleration for AppVM things. And hopefully this issue can be alleviated by installing the correct driver. But there’s probably nothing to worry about, because only dom0 can have access to the GPU.

[renehoj]

I have also noticed the issue with the vram not resetting, but it’s not a Qubes OS issue.

Tails OS mentions having the same issue, and has more information on the issue, but from what I understand it’s not easy to reliably rewrite all vram.

The Palinopsia Bug also has some information on the issue with extracting data from vram, which also shows it’s a general problem not directly related to Qubes OS.

[5q8n67f2gvf]

@fsflover

Hi @5q8n67f2gvf, welcome to the Community! I’m happy that you like Qubes OS!

Thank you for the warm welcome!

@Qubes shutdowns

systemctl daemon-reload needs to be run

This is the first thing I thought when I saw the message, but I wasn’t sure how that command is supposed to have an effect, because that message is shown before the disk is unlocked, and AFAIK systemctl daemon-reload is meant to make running systemd aware of updated service files. But I haven’t seen the message in a while and it’s not that important anyways.

@augsch

Issue 2, and 3 are most likely to be different phenomenon from the same cause: a malfunctioning gpu driver.

Most likely, yeah.

@augsch

Issue 1 is because the VRAM of your GPU doesn’t get correctly cleaned up

Now this is something I hadn’t thought about, but it makes sense.

@augsch

But there’s probably nothing to worry about, because only dom0 can have access to the GPU.

That’s exactly the kind of thinking that kept me sane all this time: that whatever it is, Qubes OS’ isolation will (probably) keep everything safe.

@renehoj

The Palinopsia Bug also has some information on the issue with extracting data from vram, which also shows it’s a general problem not directly related to Qubes OS.

This was an interesting read. Makes me wonder, whether something like this has been documented as being used by an adversary to recover data.

Thanks to everyone who replied~ Now that I know who the main culprit might be, I might give the good old integrated graphics of my CPU a try with Qubes OS, and see if that fixes these issues. I don’t think it’ll be a “downgrade”, since the GPU isn’t being utilised by appVMs directly anyways.

[renehoj]

@5q8n67f2gvf

This was an interesting read. Makes me wonder, whether something like this has been documented as being used by an adversary to recover data.

You are doing a cold boot attack which is well documented.

The vram will probably only have a single frame, and it’s not going to be easy to reconstruct, it’s not a reliable attack vector compared to dumping the system memory.