Severe Performance & Boot Issues With Laptop in 4.1

User Support
#1

I want to start this off by saying that I know for a fact that my hardware works with Qubes. It worked flawlessly with Qubes 4.0 and it meets the hardware requirements. Yes, virtualization is enabled, and yes as far as I know I am on the newest BIOS update. I have tried with and without kernel-latest, I have tried every kernel available in GRUB. I have made sure dom0 is fully up to date and even tried the testing repos to no avail.

Ever since installing 4.1 on my laptop it has basically not been usable.
-Boots take 5-20 minutes, shutdowns take 5-10 minutes.
-It’s very laggy, lots of mild graphical glitches, choppiness, text does not appear on the screen for a second or two after it is typed.
-qubes take a few minutes to start…
-sometimes, it simply doesnt boot at all. After GRUB it’s just a black screen so I have to shutdown with the power button and try again - it usually works then.

I have tried various troubleshooting techniques… I have tried turning off qube autostarts and dom0 is still poorly performing. I’ve tried mounting the LUKS volume on a live booted OS so I know it’s not an issue with the LUKS setup. I’ve tried re-installing. I have had other OSes installed and they worked fine so I know it isn’t an issue with the SSD or hardware. I have tried booting Qubes in text mode to see if anything unusual - I did not see anything unusual.

At this point I am at a loss. I don’t know what’s wrong here. I have been working to fix this issue since literally April and haven’t been able to use my laptop at all during that time. Please help me. I need there to be an actual solution. I even posted the issue on Github and didn’t get any helpful replies…

I beg anyone for some help here. At this point, I’d literally pay money for a solution.

If anyone has any input or assistance, I’d appreciate that thanks. I’d like to not have to buy a new laptop over this. :confused:

#2

When you reach the cryptsetup prompt, press ESC, then insert your decryption password as you’d normally do, just without plymouth. This way you’ll be able to see which processes take the longest.

Alternatively, if you’re already in dom0, type the following in a terminal to verify the exact times for each process:

$ systemd-analyze blame

If you have an Intel CPU you may be suffering from a known bug: here’s how you can resolve it: System unusable without nomodeset - #3 by BEBF738VD

Have you tried kernel-latest? Unable To Complete Login With New GPU - #6 by BEBF738VD

#3

For me, it’s reporting that systemd-cryptsetup@luks\*.service is taking 18 seconds, yet it’s taking over five minutes to decrypt use a detached bootloader and detached luks header?

#4

That’s likely not counted and it’s taking long because you’ve probably specified a high iteration number for the cryptsetup encryption.

#5

--iter-time 10000, key-size 512, hash sha512, and cipher is aes-xts-plain64. 500 GB drive.

#6

I’ve already tried systemd-analyze blame. Lots of it is the various service qubes, but by far the thing that takes the longest is lvm2-pvscan.

I have tried booting it after pressing esc at the LUKS decryption prompt. Again, I did not see anything significant that came up during this time, lots of things take a long time.

It’s not an Intel CPU, It’s an AMD CPU with onboard graphics as discussed in the GitHub linked.

And yes, as mentioned in the post, I have tried kernel-latest and every available kernel.

I appreciate you’re help. I’ve done a lot of the obvious stuff. Why would the lvm2-pvscan be taking this long?

#7

There are many discussions about this topic on the forum. Have you seen this guide? Workarounds for slow booting at LVM2 in Qubes OS

This is the original discussion: Why is Qubes OS booting slow?

1 Like
#8

Okay, and does this also explain why the performance is painfully bad?

And upon looking at those links, neither of them contain a solution that I can see…, just discussion of how to figure out what is the problem. I already know what is takest the longest during boot. Sure I could turn off my service vms autoistarting, but then I’d just have to start them after I booted, I dont think it’d get to the root of the issue here.

It might be worth mentioning, that on my desktop lvm2-pvscan only takes 7s and is not near being one of the longest with systemd-analyze blame. The boot on my desktop takes about a minute or less.

#9

So does anybody have a solution here hmm? This laptop is approaching 3 years old and it’s already been 6 months that I haven’t been able to use it. There has to be a solution at some point soon or else I just wasted money on my laptop at this point.

I wanted to add these are the specs of the laptop: 16GB of RAM, Lenovo Laptop, Ryzen 7 4000 Series, onboard graphics. 2020 I believe.

#10

Well, this is not an argument for help. You can use it for some other OS if Qubes isn’t good enough (you’d anyway quit Qubes, right?), or you can sell it and buy something more Qubes-friendly. Just define your priorities.

The fact is that you gave not enough info in order to be helped and you denied to try to disable autostart of your qubes to see what’s happening (I disabled it for all qubes, and put it on Session and Startup, wherever it’s possible, for example). You didn’t respond on discrete GPU, nor on using XFS or Btrfs.

We don’t know what version of Qubes you are running and what Xen version. We don’t know if you are still trying to run qubes restored from 4.0, or you tried with default setup in 4.1 too, etc…

Basically your attitude is “I tried everything (while it’s far from true) and it still doesn’t work”, simply crying for “there is actually no solution” outcome and that is obvious from you ignoring things I mentioned above. Well, what you’re looking for (subconsciously or not)…

#11

Well, this is not an argument for help. You can use it for some other OS if Qubes isn’t good enough (you’d anyway quit Qubes, right?), or you can sell it and buy something more Qubes-friendly. Just define your priorities.

What do you mean “you’d anyway quit Qubes, right”? I bought this laptop precisely because its specs were compatible with Qubes and because it’s a good price. I do not desire to use another OS on this laptop as any other setups that I would desire with a different OS I already have setup on other devices. I could not sell it for the same price that I got it for, it’s already lost value from it’s initial value and I do not desire to order a new one in the mail - everything at the store is unsuited to my needs. I do not think it’s especially unreasonable to want what I already have to work considering how it worked for a year just fine. Qubes is “good enough” - it’s exactly why I’ve been trying for so long to fix it on this laptop. I use it on my desktop, it’s my desired operating system, I chose it for a reason.

The fact is that you gave not enough info in order to be helped and you denied to try to disable autostart of your qubes to see what’s happening

I already tried disabling autostart before, it did not change anything. The problem isn’t the virtual machines. The start still takes a long time and the performance is still bad even if no qubes are running.

You didn’t respond on discrete GPU

I’ve said numerous times that I’m using an onboard GPU, and I stated which laptop I am using which would imply that too. There is no option related to such in the UEFI that I can see.

nor on using XFS or Btrfs

This is the only part that I feel that I actually failed to address. I can check now, but I am using the default setup. I did not change any of these things. Whatever it uses by default is what I am using. I will check in a bit though and come back to edit this post.

We don’t know what version of Qubes you are running and what Xen version. We don’t know if you are still trying to run qubes restored from 4.0, or you tried with default setup in 4.1 too, etc…

I stated that I am using Qubes 4.1, the latest version fully updated. The qubes themselves are irrelevant. This issue happens before and after I restore from backup. I did restore some from 4.0, but I have also tried not restoring at all and these issues are still present. I have tried the default setup, tried kernel-latest, fully updated dom0, testing repos, I mention a lot of this stuff in the OP. I am running whatever the default Xen version would be on the setup that I have described.

Basically your attitude is “I tried everything (while it’s far from true) and it still doesn’t work”, simply crying for “there is actually no solution” outcome and that is obvious from you ignoring things I mentioned above. Well, what you’re looking for (subconsciously or not)…

What am I ignoring? I’d love to try it. As I mentioned in the OP, I’d pay a little money for a solution at this point.

Sorry if at any point in this message I am coming off as being rude - it is not my intention. I am a little frustrated with this whole thing as I’ve been troubleshooting this issue for over 7 months.

#12

Things like this aren’t helpful at all. I hope you’ll comprehend this. For 7 months you never mentioned which kernel version and which Xen version you are running, to name a few.

This could have nothing to do with disabling discrete GPU in BIOS and elsewhere. So, expected response would be something like “I have disabled it and I’m still having the same issue”. No one likes to deduct conclusions from other’s statements while trying to help.

Please consider to read this, maybe it will help us all to help, but to you at first.

www.catb.org/~esr/faqs/smart-questions.html

#13

Things like this aren’t helpful at all. I hope you’ll comprehend this. For 7 months you never mentioned which kernel version and which Xen version you are running, to name a few.

Nobody asked. It is various versions. Why is saying the most updated and recent version not enough? To answer your question, I have been running 6.0 on this laptop lately, I’ve stated numerous times that I’m using kernel-latest. The Xen version I will check later today along with the XFS vs Btrfs. But the thing is, these issues are present across every kernel that is available to be booted.

This could have nothing to do with disabling discrete GPU in BIOS and elsewhere.

I said this here:

There is no option related to such in the UEFI that I can see.

#14

What is the capacity of your drive?

#15

Nobody had to. Please read that link.

Because this could mean so many things, depending on enabled repos on your machine. We neither know what repos you enabled, or it was temporarily, when, or not, etc…

No, you stated that you tried kernel-latest. and kernel-latest 7 months ago isn’t kernel latest 5 months ago. Or today.

So this means that you tried every of these, because they are as well available to be booted? Where did you say so?

I’ll say once again. If you want to get helped, you have to redefine your approach, otherwise I could bet no one would be able to help. The answer is on that link which you obviously ignored.

#16

Because this could mean so many things, depending on enabled repos on your machine. We neither know what repos you enabled, or it was temporarily, when, or not, etc…

I stated that I had tried with both the normal repos and the testing repos.

No, you stated that you tried kernel-latest. and kernel-latest 7 months ago isn’t kernel latest 5 months ago. Or today.

I did try it 7 months ago and it continues to be installed and updated. But to answer the question finally it’s Xen 4.14.5 and kernel 6.0.8-1.

I have tried everything that is available to be booted after kernel-latest is installed and updated in Qubes 4.1.1. If what is on that link is those, then yes, I’ve tried them all. I’ve tried everything that GRUB shows for me.

I’ll say once again. If you want to get helped, you have to redefine your approach, otherwise I could bet no one would be able to help. The answer is on that link which you obviously ignored.

The questions link? I already have included all of the information that you have asked for here. I stated my Xen version, repos, kernel version, if I had the option to change discrete graphics in UEFI, etc.

#17

1tb

#18

Have you tried making a smaller partition when installing, maybe ~100gb, just to test if the size has any impact?

Is replacing the drive an option, just to test if it’s a compatibility issue?

#19

I will consider trying this. But it worked flawlessly with the exact same drive on Qubes 4.0. So why would it work any differently on 4.1? I will try anything at this point I guess.

Replacing the drive isn’t really an option. I want this one to work. It works fine with windows when I installed it for attempted UEFI update. It’s a laptop, replacing the drive will be annoying and isn’t something I want to pay for.

For what it’s worth, Qubes 4.1 works fine with a 1tb NVME SSD on my desktop.

Anyways, I’m gonna try a few other things I’ve found online tonight and if those don’t work I will try smaller install and report back.