For the third time since last night, Lubuntu, installed in a virtual machine (using virt-manager), has managed to crash, all the way back to the login screen, while using a web browser. The two crashes last night occurred when I was using Firefox, today’s crash was while using Chromium. The web browsers froze, then wham. Have no idea why it crashes, but when the login screen reappeared from today’s crash, I selected the icon to reboot it, the Lubuntu splash screen appeared, but it did not reboot. I had to select Force Off in the virt-manager GUI.
Normally, this would be installed natively, not in a virtual machine. Would these crashes be something to expect, since it’s running in a vm and not natively?
Maybe insufficient allocated memory is the cause, especially if you did not configure a swap file. You could simply try to increase the amount of memory that is reserved for the VM, and see if the problems persist.
I’ve been running many times (different kind of) (U/)Lubuntu with less than 4 GB without problem on VirtualBox. 4GB should be enough running in kvm as well. Swap should not be necessary IMHO. Maybe you created a VM with a too small harddisk volume. If the problem persists, look for clues in /var/log.
It was created with 25Gb of disk space. This may be similar to another issue that I’m having with a different VM, for which I am testing a fix for, now.
I do not know. However, the Lubuntu virtual machine, just crashed again, with the new vram setting of 262144 (256 MiB), just scrolling through these pages, everything froze, screen goes black, then the login appears again. This is the end of the log when it crashed. The log terminated at the crash.
[ 484.245] (EE) qxl(0): error doing QXL_ALLOC
[ 484.245] (EE)
[ 484.245] (EE) Backtrace:
[ 484.270] (EE) 0: /usr/lib/xorg/Xorg (OsLookupColor+0x139) [0x562a9922e2b9]
[ 484.272] (EE) 1: /lib/x86_64-linux-gnu/libc.so.6 (__sigaction+0x50) [0x7f864ad76520]
[ 484.273] (EE) unw_get_proc_name failed: no unwind info found [-10]
[ 484.273] (EE) 2: /usr/lib/xorg/modules/drivers/qxl_drv.so (?+0x0) [0x7f864a5dbb2d]
[ 484.274] (EE) unw_get_proc_name failed: no unwind info found [-10]
[ 484.274] (EE) 3: /usr/lib/xorg/modules/drivers/qxl_drv.so (?+0x0) [0x7f864a5dbfc7]
[ 484.275] (EE) unw_get_proc_name failed: no unwind info found [-10]
[ 484.275] (EE) 4: /usr/lib/xorg/modules/drivers/qxl_drv.so (?+0x0) [0x7f864a5e7a4e]
[ 484.276] (EE) 5: /usr/lib/xorg/Xorg (DamageRegionAppend+0x3aac) [0x562a9919ecac]
[ 484.276] (EE) 6: /usr/lib/xorg/Xorg (SyncVerifyFence+0x212e) [0x562a99151d9e]
[ 484.277] (EE) 7: /usr/lib/xorg/Xorg (SendErrorToClient+0x365) [0x562a990b84a5]
[ 484.277] (EE) 8: /usr/lib/xorg/Xorg (InitFonts+0x3c4) [0x562a990bc524]
[ 484.279] (EE) 9: /lib/x86_64-linux-gnu/libc.so.6 (__libc_init_first+0x90) [0x7f864ad5dd90]
[ 484.281] (EE) 10: /lib/x86_64-linux-gnu/libc.so.6 (__libc_start_main+0x80) [0x7f864ad5de40]
[ 484.282] (EE) 11: /usr/lib/xorg/Xorg (_start+0x25) [0x562a990a55f5]
[ 484.282] (EE)
[ 484.282] (EE) Segmentation fault at address 0x0
[ 484.282] (EE)
Fatal server error:
[ 484.282] (EE) Caught signal 11 (Segmentation fault). Server aborting
[ 484.282] (EE)
[ 484.282] (EE)
Please consult the The X.Org Foundation support
This seems to be a problem with the X Server (the overall window management system). Perhaps something is wrong with kvm.
QXL is the QEMU QXL video accelerator. Your problem maybe has no direct link with Lubuntu.
I advice you to try and run in VirtualBox (even if you don’t know it, or don’t like it). Getting things up and running is different, but the end result - a running VM - is the same. After a while, try to update kvm.
As usual with any layered cake, it is difficult to determine from a distance where the problem is exact. Your logfile is from the VM I guess, not from the host?
Yes, the log is from the guest (VM). The host does not crash, only the VM. I’ve never used VirtualBox, only virt-manager and Gnome Boxes.
I increased the amount of host memory by 256 MiB to accommodate the increase in vram. I found old bug reports at Red Hat and Debian showing the same crash and the suggestion was to increase the vram. Going from 64 to 256 MiB, I thought would do it.
Guess not.
From top, with an e-mail application and Chromium open, everything including LXQt is using only 784 MiB, so the overall host memory should be more than enough:
My wild guess is that you’ve ran into a bug in qemu/kvm and/or whatever is in that layered cake. To lower your frustation level, I really advice you to switch to VirtualBox. Maybe you can’t tune everything like you are used to, but on the otherhand, it might work. If you are lucky, you can use the existing kvm image
It crashed again a little while ago, with the vram on 512 MiB.
I found a web site that had definitions of the three memory settings, “ram” specifies primary memory bar size, “vram” is secondary memory bar size and “vgamem” must be a minimum value based on the screen resolution and the number of heads. I left vgamem on 16384 and now flipped the ram and vram settings so they are now 524288 for ram and 65536 for vram. After making the change to the XML file, I was advised to restart the libvirtd daemon.
My first choice for virtualization has been VirtualBox for a long time already. One of the reasons is that it allowed me in the past to move VM’s around from Linux to Windows without many problems. I am happy to say that currently nobody forces me to use Windows any longer. However, I’d been stuck to VirtualBox without realizing why exactly. It’s OK for me, but I’ve decided that future VM’s will be hosted on kvm. So, keep us posted with your experiences
With Firefox open, Thunderbird and the basesystem…
fritz@x205ta:~$ free -h
total used free shared buff/cache available
Mem: 1.9Gi 765Mi 253Mi 91Mi 889Mi 803Mi
Swap: 4.1Gi 46Mi 4.1Gi
I am running SparkyLinux btw (since my primary laptop broke down, and my older eMMc-based replacement will not boot Lubuntu 22.04 OOTB, and SparkyLinux still is able to boot from 32-bit UEFI in 32-bit mode). Figures should be the same, anyway, grosso modo.
Interesting fact: SparkyLinux running LXQt has almost the same look-and-feel as Lubuntu, but without any snaps.
With the video “ram” (primary memory) set to 512 MiB, I ran the Lubuntu VM this morning for a few hours and X did not crash.
Although Firefox 102.0 (the snap…) froze with only four tabs opened, two were on Wikipedia. While it was frozen, as X didn’t crash, I was still able to move the mouse, close Firefox and reopen it.
As for Firefox, I am tempted to remove the snap (if it’s possible to do that) and use the Mozilla Security Team or Mozilla Team PPA for Firefox and Thunderbird.
LXQt uses minimal memory, that’s one of the reasons I like and use it.
There is an excellent article somewhere in this discourse site about how to disable snaps. Don’t have the link here right now. Seems it is very possible. I’ve been considering it myself, but have fears that from time to time incompatibilities may occur, because the Ubuntu/Lubuntu repos and the Mozilla PPA are not designed, or intended to be used that way, every given moment in time.
Your X problem could be just a fine example of such a phenomena.
I am not a fan of snaps. One of the senior members of the Lubuntu council has explained in another article here, why using snaps could be a very smart thing to do, security wise
Sandboxing, containerizing… the way to go, I guess. If not, maybe we will all be forced to use the next Linux in a few years time. Not a bad thing if you like a special sort of colourful flower.
I see Sparky is based on Debian. In addition to Lubuntu - which I might now remove because of what occurred after the Firefox SNAP updated…I have created six other VM’s, all with LXQt, including Debian (via Spiral Linux image).
Interesting. I did not know Spiral. Yadc? Yet another debian clone?? I like anything with LXQt that is stable. Lubuntu is, for sure. Sparky seems to be. At least, after using it a few weeks I think it is. I will try Spiral, later this summer or beginning of fall.
