I’m running EndeavourOS + i3-wm in a virtual machine, and recently began experiencing issues with the kernel and install as a whole. On boot, the system hangs on “Loading initial ramdisk” for a good several minutes, and when I it does get to the desktop, htop states that the main Xorg process uses between 200% and 400% of my CPU (I’ve given the system 8 threads). Both the 6.0.12 Linux standard kernel bundled with the latest Endeavour install and the 6.1.10 Zen kernel acted the same way, as did booting from the “fallback initramfs” using GRUB.
Searching the problem told me to reinstall the kernels and regenerate the ramdisks, which I did through a chroot operation, but it seemed to have no effect. I then installed the LTS kernel, and it booted almost immediately and Xorg went down to an average usage of 60%. Any clue why this might be happening? I hope the answer isn’t a “well the LTS kernel is meant to be more stable,” as the difference in boot speed is enormous, especially with the revision of the kernel that came with Endeavour.
That’s right, as stated, I am running this in a virtual machine. This issue only cropped up yesterday, and before that I was booting perfectly fine from the Zen kernel.
Removing picom didn’t affect the Xorg task’s usage by much. The main issue is the abysmal boot time with the Zen/vanilla kernels, I just thought mentioning that Xorg being slower too might help identify the issue.
Our configurations are pretty much identical except mine is BIOS and yours is UEFI. Might that be causing issues with newer kernels? I’ll try the systemctl --failed and get back to you on that.
I don’t think that it should. I’m not sure why your output for systemd-analyze critical-chain is so long? Mine is instant with hardly any output. Do you have all these things set up after as mine i just installed it to check.
Your host isn’t Bios? Is the v-box install of i3 in Bios mode? Is that what you mean?
Host is UEFI, guest is BIOS.
It’s strange why the systemd-analyze critical-chain output is so long, I don’t even recognize half of the programs. Running systemctl --failed gave me the same thing you got. This particular VM is only a few days old, and this issue didn’t crop up immediately after install; it booted fine from the zen kernel for a period of time, and I didn’t make any drastic changes before it broke.
As stated, that’s with the 6.1.10-zen kernel that I reinstalled manually after the issue started appearing.
I don’t have a copy of the 6.0.12 vanilla kernel on the system anymore; do you want me to try reinstalling it and regenerating the ramdisk to investigate that further?