[Bug 1178360] New: X11 Pixel Garbage in VirtualBox
http://bugzilla.opensuse.org/show_bug.cgi?id=1178360 Bug ID: 1178360 Summary: X11 Pixel Garbage in VirtualBox Classification: openSUSE Product: openSUSE Tumbleweed Version: Current Hardware: x86-64 OS: openSUSE Tumbleweed Status: NEW Severity: Major Priority: P5 - None Component: X.Org Assignee: gfx-bugs@suse.de Reporter: shundhammer@suse.com QA Contact: gfx-bugs@suse.de Found By: --- Blocker: --- With the latest Tumbleweed (at least since the middle of last week), I get half a screen full of pixel garbage in a VirtualBox VM, and the screen coordinates seem to be off. Keyboard input is also not always echoed correctly; it arrives at the application, but I only see the first one or two key presses. The machine seems to work fine otherwise; I can ssh into it and work normally. But the console diplays garbage, and that garbage is also mirrored in the little "preview" in the VirtualBox console (see screenshot). It does not make a difference if 3D acceleration is on or off in VirtualBox, or how much video RAM I allocate for the VM. It worked fine for months until early last week. After a "zypper dup" last Wednesday it broke, and I reverted the VM to a previous snapshot (and it worked again). "zypper dup" right now gave me the same pixel garbage. When I open a window (Alt-F2 "xterm", PrintScreen key), it's not centered, but near the bottom, and also not centered as it should. Notice how the Xfce screenshoter displays the correct screen content and the VirtualBox preview also the pixel garbage. [sh @ balrog-tw-dev] ~ 1 % cat /etc/os-release NAME="openSUSE Tumbleweed" # VERSION="20201030" ID="opensuse-tumbleweed" ID_LIKE="opensuse suse" VERSION_ID="20201030" PRETTY_NAME="openSUSE Tumbleweed" ANSI_COLOR="0;32" CPE_NAME="cpe:/o:opensuse:tumbleweed:20201030" BUG_REPORT_URL="https://bugs.opensuse.org" HOME_URL="https://www.opensuse.org/" DOCUMENTATION_URL="https://en.opensuse.org/Portal:Tumbleweed" LOGO="distributor-logo" [sh @ balrog-tw-dev] ~ 2 % rpm -qa | grep X libXtst6-1.2.3-2.1.x86_64 libXft2-2.3.3-1.7.x86_64 perl-XML-Twig-3.52-2.2.noarch libXau6-1.0.9-1.7.x86_64 libXfont2-2-2.0.4-1.5.x86_64 libXmuu1-1.1.3-1.7.x86_64 xorg-x11-libX11-ccache-7.6-21.7.x86_64 perl-XML-Simple-2.25-1.8.noarch perl-XML-Dumper-0.81-69.13.x86_64 libXmu6-1.1.3-1.7.x86_64 libXaw7-1.0.13-2.9.x86_64 perl-X11-Protocol-0.56-15.4.noarch libXt6-1.2.0-1.5.x86_64 libXRes1-1.2.0-1.9.x86_64 xorg-x11-Xvnc-1.10.1-6.1.x86_64 xorg-x11-server-Xvfb-1.20.9-3.1.x86_64 perl-XML-SAX-Expat-0.51-4.7.noarch libZXing1-1.1.0-3.1.x86_64 perl-X500-DN-0.29-109.3.x86_64 libX11-xcb1-1.6.12-1.1.x86_64 libXfixes3-5.0.3-1.11.x86_64 perl-XML-NamespaceSupport-1.12-1.10.noarch typelib-1_0-XApp-1_0-1.6.10-4.1.x86_64 libXrandr-devel-1.5.2-1.7.x86_64 libXrandr2-1.5.2-1.7.x86_64 libQt5Xml-devel-5.15.1-4.1.x86_64 perl-XML-LibXML-2.0206-1.1.x86_64 libXdamage1-1.1.5-1.7.x86_64 libXext6-1.3.4-1.7.x86_64 libX11-devel-1.6.12-1.1.x86_64 libX11-6-1.6.12-1.1.x86_64 libQt5XmlPatterns5-5.15.1-1.1.x86_64 libXcursor1-1.2.0-1.5.x86_64 libXi6-1.7.10-1.5.x86_64 libXdmcp6-1.1.3-1.7.x86_64 libXrender1-0.9.10-1.12.x86_64 libXxf86vm1-1.1.4-1.17.x86_64 libXinerama1-1.1.4-1.8.x86_64 perl-XML-SAX-Base-1.09-1.11.noarch perl-Cpanel-JSON-XS-4.25-1.1.x86_64 libXfontcache1-1.0.5-12.18.x86_64 perl-XML-Parser-2.46-1.4.x86_64 libXpm4-3.5.13-1.4.x86_64 libXrender-devel-0.9.10-1.12.x86_64 libXext-devel-1.3.4-1.7.x86_64 libXvnc1-1.10.1-6.1.x86_64 libXv1-1.0.11-1.11.x86_64 libXaw3d8-1.6.3-1.8.x86_64 libXcomposite1-0.4.5-1.5.x86_64 libXau-devel-1.0.9-1.7.x86_64 xorg-x11-Xvnc-module-1.10.1-6.1.x86_64 perl-XML-Writer-0.900-1.1.noarch libXss1-1.2.3-1.9.x86_64 libX11-data-1.6.12-1.1.noarch libQt5X11Extras5-5.15.1-1.1.x86_64 perl-XML-SAX-1.02-1.4.noarch libXpresent1-1.0.0-2.3.x86_64 libQt5Xml5-5.15.1-4.1.x86_64 [sh @ balrog-tw-dev] /etc/X11 5 % ls -l total 16 drwxr-xr-x 2 root root 4096 Okt 19 17:59 xdm drwxr-xr-x 3 root root 4096 Okt 15 15:12 xinit drwxr-xr-x 2 root root 4096 Okt 15 15:12 xorg.conf.d -rw-r--r-- 1 root root 938 Mär 23 2020 xorg.conf.install [sh @ balrog-tw-dev] /etc/X11 6 % cd xorg.conf.d [sh @ balrog-tw-dev] .../etc/X11/xorg.conf.d 7 % ls -l total 4 -rw-r--r-- 1 root root 440 Mär 23 2020 00-keyboard.conf -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1178360 http://bugzilla.opensuse.org/show_bug.cgi?id=1178360#c1 --- Comment #1 from Stefan Hundhammer <shundhammer@suse.com> --- Created attachment 843220 --> http://bugzilla.opensuse.org/attachment.cgi?id=843220&action=edit X11 log at /var/log/Xorg.0.log -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1178360 http://bugzilla.opensuse.org/show_bug.cgi?id=1178360#c2 --- Comment #2 from Stefan Hundhammer <shundhammer@suse.com> --- Created attachment 843221 --> http://bugzilla.opensuse.org/attachment.cgi?id=843221&action=edit sudo journalctl -b -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1178360 http://bugzilla.opensuse.org/show_bug.cgi?id=1178360#c3 --- Comment #3 from Stefan Hundhammer <shundhammer@suse.com> --- The VirtualBox host is using VirtualBox 5.2.42. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1178360 http://bugzilla.opensuse.org/show_bug.cgi?id=1178360#c4 --- Comment #4 from Stefan Hundhammer <shundhammer@suse.com> --- Created attachment 843222 --> http://bugzilla.opensuse.org/attachment.cgi?id=843222&action=edit Screenshot: Pixel garbage -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1178360 http://bugzilla.opensuse.org/show_bug.cgi?id=1178360#c5 --- Comment #5 from Stefan Hundhammer <shundhammer@suse.com> --- Created attachment 843223 --> http://bugzilla.opensuse.org/attachment.cgi?id=843223&action=edit Screenshot: Correct Xfce4 Desktop That's what it should look like (after reverting to the previous VirtualBox snapshot). -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1178360 http://bugzilla.opensuse.org/show_bug.cgi?id=1178360#c6 --- Comment #6 from Stefan Hundhammer <shundhammer@suse.com> --- Also notice the remnants of green text console messages in the pixel garbage; this looks like "OK" messages from started services during booting. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1178360 Stefan Dirsch <sndirsch@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #843220|text/x-log |text/plain mime type| | -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1178360 http://bugzilla.opensuse.org/show_bug.cgi?id=1178360#c7 Stefan Dirsch <sndirsch@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |IN_PROGRESS Flags| |needinfo?(shundhammer@suse. | |com) --- Comment #7 from Stefan Dirsch <sndirsch@suse.com> --- Nothing obvious I could spot, but Kernel was updated from 5.8 to 5.9.1 with TW 20201026. It would be worth a try to test again with a Kernel 5.8 kernel. Where still to find 5.8 kernel packages? Unfortunately I don't know. :-( -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1178360 http://bugzilla.opensuse.org/show_bug.cgi?id=1178360#c8 --- Comment #8 from Stefan Hundhammer <shundhammer@suse.com> --- Since I reverted to the previous VM snapshot that still has kernel 5.8.15, I can try to set the kernel to "protected" and upgrade all other packages. Let me try that. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1178360 http://bugzilla.opensuse.org/show_bug.cgi?id=1178360#c9 Stefan Hundhammer <shundhammer@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(shundhammer@suse. | |com) | --- Comment #9 from Stefan Hundhammer <shundhammer@suse.com> --- After locking those packages and doing a "zypper dup" with everything else, it still works fine: [sh @ balrog-tw-dev] ~ 8 % sudo zypper locks # | Name | Type | Repository --+------------------------+---------+----------- 1 | kernel-default | package | (any) 2 | kernel-default-base | package | (any) 3 | virtualbox-dmp-default | package | (any) 4 | virtualbox-guest* | package | (any) 5 | virtualbox-guest-tools | package | (any) 6 | virtualbox-guest-x11 | package | (any) 7 | virtualbox-kmp-default | package | (any) [sh @ balrog-tw-dev] ~ 9 % rpm -qa "kernel-default*" "virtualbox*" | sort -u kernel-default-5.8.14-1.2.x86_64 kernel-default-5.8.15-1.2.x86_64 virtualbox-guest-tools-6.1.14-2.1.x86_64 virtualbox-guest-x11-6.1.14-2.1.x86_64 virtualbox-kmp-default-6.1.14_k5.8.15_1-2.5.x86_64 -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1178360 http://bugzilla.opensuse.org/show_bug.cgi?id=1178360#c10 --- Comment #10 from Stefan Hundhammer <shundhammer@suse.com> --- After upgrading to the new kernel and rebooting and just locking the virtualbox* packages, it still works fine. [sh @ balrog-tw-dev] ~ 24 % sudo zypper locks # | Name | Type | Repository --+------------------------+---------+----------- 1 | virtualbox-guest* | package | (any) 2 | virtualbox-kmp-default | package | (any) [sh @ balrog-tw-dev] ~ 25 % sudo zypper dup Loading repository data... Reading installed packages... Warning: You are about to do a distribution upgrade with all enabled repositories. Make sure these repositories are compatible before you continue. See 'man zypper' for more information about this command. Computing distribution upgrade... The following 5 items are locked and will not be changed by any action: Available: virtualbox-guest-desktop-icons virtualbox-guest-source Installed: virtualbox-guest-tools virtualbox-guest-x11 virtualbox-kmp-default Nothing to do. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1178360 http://bugzilla.opensuse.org/show_bug.cgi?id=1178360#c11 Stefan Hundhammer <shundhammer@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|IN_PROGRESS |RESOLVED Resolution|--- |WORKSFORME --- Comment #11 from Stefan Hundhammer <shundhammer@suse.com> --- After upgrading the last remaining package virtualbox-kmp-default-6.1.14_k5.9.1_1-2.6.x86_64 it STILL works. But I noticed that zypper also downloaded a new kernel package while I was upgrading (see comment #10) despite having cached everything before ("sudo zypper dup --download-only"). I now have kernel-default-5.9.1-1.2.x86_64 in that VM. So maybe it was that latest kernel that fixed it. I have no other explanation to offer. !?!? -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1178360 http://bugzilla.opensuse.org/show_bug.cgi?id=1178360#c12 Stefan Hundhammer <shundhammer@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |REOPENED Resolution|WORKSFORME |--- --- Comment #12 from Stefan Hundhammer <shundhammer@suse.com> --- It just came back after "zypper dup" today. When I boot the old kernel 5.8.18 from the Grub2 prompt, it's working okay. When I boot the new kernel 5.9.1, I get the same pixel garbage. I tried recreating the initrd ("sudo mkinitrd"), but that did not change anything. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1178360 http://bugzilla.opensuse.org/show_bug.cgi?id=1178360#c13 --- Comment #13 from Stefan Hundhammer <shundhammer@suse.com> --- Created attachment 843465 --> http://bugzilla.opensuse.org/attachment.cgi?id=843465&action=edit Output of rpm -qa -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1178360 http://bugzilla.opensuse.org/show_bug.cgi?id=1178360#c14 --- Comment #14 from Stefan Hundhammer <shundhammer@suse.com> --- Created attachment 843466 --> http://bugzilla.opensuse.org/attachment.cgi?id=843466&action=edit Output of rpm -qa --last -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1178360 http://bugzilla.opensuse.org/show_bug.cgi?id=1178360#c15 Stefan Hundhammer <shundhammer@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #843221|0 |1 is obsolete| | --- Comment #15 from Stefan Hundhammer <shundhammer@suse.com> --- Created attachment 843467 --> http://bugzilla.opensuse.org/attachment.cgi?id=843467&action=edit Output of sudo journalctl -b -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1178360 http://bugzilla.opensuse.org/show_bug.cgi?id=1178360#c16 --- Comment #16 from Stefan Hundhammer <shundhammer@suse.com> --- Created attachment 843468 --> http://bugzilla.opensuse.org/attachment.cgi?id=843468&action=edit Output of sudo journalctl -b -1 (booting with kernel 5.8.18; no pixel garbage) This is not after resetting the VM to the previous state, just selecting the previous kernel 5.8.18 from the Grub2 boot menu. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1178360 http://bugzilla.opensuse.org/show_bug.cgi?id=1178360#c17 --- Comment #17 from Stefan Hundhammer <shundhammer@suse.com> --- Booting kernel 5.9.1 with safe settings from the Grub2 boot menu also resulted in pixel garbage. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1178360 http://bugzilla.opensuse.org/show_bug.cgi?id=1178360#c33 --- Comment #33 from Larry Finger <Larry.Finger@gmail.com> --- In all my testing, there are no display problems with the graphics controller set to VMSVGA. Of course, all that is with openSUSE hosts and various guests. My standard test machines are Windows XP, 7, and 10 as well as openSUSE TW, Leap 15.1 and Leap 15.2. I do have one test machine that gets other Linux distros if there are complaints. If you had a problem with a Ubuntu guest on an openSUSE host, I could look at that. Note that even VB 6.1.10 is pretty old. With 6.1.12, Oracle fixed 25 CVE exploits - the ones I mentioned earlier. I would not want to run such a system five months after those exploits have been published. I have no idea what change there might be in kernel 5.9 that would break graphics on an old host system. At least it works with the recommended VMSVGA virtual controller. It may be true that "We can't force them all to upgrade their host systems to something newer", but it is definitely true that I have little enthusiasm for debugging Ubuntu problems. I have too many problems already, including that VB may never run on hosts with kernel 5.10+. My inclination is to close this with a WONT FIX. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1178360 http://bugzilla.opensuse.org/show_bug.cgi?id=1178360#c34 --- Comment #34 from Stefan Hundhammer <shundhammer@suse.com> --- I really don't care about CVEs for this; this is purely for test machines and development. What I do care for is a stable working platform for my daily work - which Tumbleweed unfortunately is not; and Leap is too old to bother with (and the desktops unfortunately poorly maintained for lack of desktop teams). Thus the other platform. I can live perfectly well with an older VirtualBox manager on my workstation. But for developing for our next release, I do need Tumbleweed; that's what I have that VM for. And it served me well ever since the Corona crisis with subsequent home office for all of our R&D began. And at home I am the master of my own hardware, and I use what works best for me. Sure, you can close this as WONTFIX. But rest assured that in that case this will be my last bug report EVER for everything beyond my direct area of responsibility. The vast majority of bugs that I have reported in all my years at SUSE (since 1999) ended up in some unsatisfactory state anyway (WORKSFORME, WONTFIX or in unfixed limbo forever). This is not "an Ubuntu problem". This is a VirtualBox problem or (less likely) a problem with that latest kernel 5.9.1. What makes you so sure that our Leap or SLE users won't have the exact same problem when they try to run a VM with that kernel (or a later one)? -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1178360 http://bugzilla.opensuse.org/show_bug.cgi?id=1178360#c35 --- Comment #35 from Larry Finger <Larry.Finger@gmail.com> --- Tumbleweed is stable for me, even though one does not choose a rolling release for stability. I understand your frustration, but what do you expect me to do? I just installed Xubuntu 18.04 LTS in a spare partition of my host, updated it, and installed VirtualBox. Running my TW KDE VM resulted in a graphics screen with a cursor only. That was with both 5.9.1 and 5.8.4 kernels. The only thing that changed was Xubuntu instead of a TW host. Why is this an openSUSE problem? -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1178360 http://bugzilla.opensuse.org/show_bug.cgi?id=1178360#c37 --- Comment #37 from Stefan Hundhammer <shundhammer@suse.com> --- Please look at that screenshot again: https://bugzilla.opensuse.org/attachment.cgi?id=843222 The first green pixel line starts with a black portion. That is exactly how much the rest of the X11 screen is offset to the right. In the vertical dimension, the black part is exactly how much it's offset downwards. When you look at the visible part of the Xfce screenshot utility at the bottom part of that X11 screen, you will see that the screenshot it took inside that VM is correct; there is no pixel garbage, and the icons are lined up correctly at the left top corner. So for the X server inside the VM, everything is alright (AFAICS). It must be somewhere in the communication protocol between the VM guest and the host. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1178360 http://bugzilla.opensuse.org/show_bug.cgi?id=1178360#c39 --- Comment #39 from Stefan Hundhammer <shundhammer@suse.com> --- (In reply to Takashi Iwai from comment #38)
What happened between your comment 11 and comment 12?
Another "zypper dup" with more updated packages.
You showed the problem was introduced (again) there. What packages have been updated exactly and what action done?
Unfortunately, I only have a partial package list of the previous state (see comment #0). For the new state, it's the attachment from comment #13. The attachment from comment #14 contains the output of "rpm -qa --last" which includes timestamps, however: https://bugzilla.opensuse.org/attachment.cgi?id=843466 -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1178360 http://bugzilla.opensuse.org/show_bug.cgi?id=1178360#c40 Stefan Hundhammer <shundhammer@suse.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(shundhammer@suse. | |com) | --- Comment #40 from Stefan Hundhammer <shundhammer@suse.com> --- A complete shot in the dark (and, as noted before, I know nothing about kernel stuff and how all that works): https://build.opensuse.org/package/view_file/openSUSE:Factory/virtualbox/fix... Index: VirtualBox-6.1.14/src/VBox/Additions/linux/drm/vbox_ttm.c =================================================================== --- VirtualBox-6.1.14.orig/src/VBox/Additions/linux/drm/vbox_ttm.c +++ VirtualBox-6.1.14/src/VBox/Additions/linux/drm/vbox_ttm.c @@ -445,7 +445,11 @@ err_free_vboxbo: static inline u64 vbox_bo_gpu_offset(struct vbox_bo *bo) { +#if RTLNX_VER_MAX(5, 9, 0) return bo->bo.offset; +#else + return bo->offset; +#endif } This affects an offset, and the function name suggests it's related to the GPU. That might be a hint. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1178360 http://bugzilla.opensuse.org/show_bug.cgi?id=1178360#c41 --- Comment #41 from Stefan Hundhammer <shundhammer@suse.com> --- My last good snapshot (who which I reverted in the meantime) runs with Linux balrog-tw-dev.fritz.box 5.9.1-1-default #1 SMP Mon Oct 26 07:02:23 UTC 2020 (435e92d) x86_64 x86_64 x86_64 GNU/Linux i.e. kernel-default-5.9.1-1.2.x86_64 "zypper dup" would update to kernel-default-5.9.1-2.2.x86_64 . -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1178360 http://bugzilla.opensuse.org/show_bug.cgi?id=1178360#c42 --- Comment #42 from Stefan Hundhammer <shundhammer@suse.com> --- It keeps getting weirder and weirder. I did more experiments with kernel-default locked and doing "zypper dup" for all the rest. I had not realized that this would also install kernel-default-base which zypper installed to resolve the dependencies of virtualbox-kmp. That lead to being restricted to a 640x480 (standard VGA) screen resolution because virtualbox-kmp could not be properly initialized: Nov 12 14:21:12 localhost kernel: vboxvideo: Unknown symbol ttm_bo_mmap (err -2) vboxvideo: Unknown symbol ttm_bo_manager_func (err -2) vboxvideo: Unknown symbol ttm_bo_glob (err -2) vboxvideo: Unknown symbol ttm_bo_device_release (err -2) vboxvideo: Unknown symbol ttm_bo_kunmap (err -2) vboxvideo: Unknown symbol ttm_bo_device_init (err -2) vboxvideo: Unknown symbol ttm_bo_init_mm (err -2) vboxvideo: Unknown symbol ttm_bo_dma_acc_size (err -2) vboxvideo: Unknown symbol ttm_tt_init (err -2) vboxvideo: Unknown symbol ttm_bo_kmap (err -2) vboxvideo: Unknown symbol ttm_bo_init (err -2) vboxvideo: Unknown symbol ttm_bo_validate (err -2) vboxvideo: Unknown symbol ttm_bo_move_to_lru_tail (err -2) vboxvideo: Unknown symbol ttm_bo_put (err -2) vboxvideo: Unknown symbol ttm_tt_fini (err -2) vboxvideo: Unknown symbol ttm_bo_eviction_valuable (err -2) But there was no pixel garbage. Later I unlocked kernel-default, uninstalled kernel-default-base (which also uninstalled the virtualbox-* packages) and then force-reinstalled the new kernel and the virtualbox-* packages: zypper in --force kernel-default virtualbox-guest-x11 virtualbox-guest-tools virtualbox-kmp-default ...and now everything is working again: No pixel garbage, not restricted to 640x480. Somehow I feel this is a bootstrap problem of the involved packages or a binary compatibility problem: Just like previously, upgrading the packages step by step appears to work fine, while upgrading everything at once has weird side effects. virtualbox-kmp-default rebuilds the kernel module in its post-install script (and recreates the initrd with dracut). Is it possible or plausible that in certain situations it does that with the wrong kernel headers or something like that? Using the ones of the currently running kernel rather than the one that is also being installed in the same "zypper dup" run? Is it plausible that this might be only a missing dependency in the virtualbox .spec file; or a post-install script being executed at an inappropriate time, before the complete upgrade process is complete? -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1178360 http://bugzilla.opensuse.org/show_bug.cgi?id=1178360#c43 --- Comment #43 from Stefan Hundhammer <shundhammer@suse.com> --- The installation / upgrade sequence of those four critical packages was: kernel-default-5.9.1-2.2.x86_64 Do 12 Nov 2020 15:09:09 CET virtualbox-kmp-default-6.1.14_k5.9.1_2-2.8.x86_64 Do 12 Nov 2020 15:09:46 CET virtualbox-guest-x11-6.1.14-2.1.x86_64 Do 12 Nov 2020 15:11:03 CET virtualbox-guest-tools-6.1.14-2.1.x86_64 Do 12 Nov 2020 15:11:04 CET This resulted in a correctly working system. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1178360 http://bugzilla.opensuse.org/show_bug.cgi?id=1178360#c44 --- Comment #44 from Larry Finger <Larry.Finger@gmail.com> --- (In reply to Stefan Hundhammer from comment #42)
virtualbox-kmp-default rebuilds the kernel module in its post-install script (and recreates the initrd with dracut). Is it possible or plausible that in certain situations it does that with the wrong kernel headers or something like that? Using the ones of the currently running kernel rather than the one that is also being installed in the same "zypper dup" run?
If you build a kernel module with the wrong headers, the resulting code will simply not load, thus your supposition is wrong!
Is it plausible that this might be only a missing dependency in the virtualbox .spec file; or a post-install script being executed at an inappropriate time, before the complete upgrade process is complete?
The VirtualBox modules do not need to be in the initrd as they are not loaded until the file system is up and running. Nonetheless, the install system puts them in initrd. The spec process is rather complicated; however, I think it is doing the right thing otherwise. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1178360 http://bugzilla.opensuse.org/show_bug.cgi?id=1178360#c45 --- Comment #45 from Larry Finger <Larry.Finger@gmail.com> --- (In reply to Stefan Hundhammer from comment #40)
A complete shot in the dark (and, as noted before, I know nothing about kernel stuff and how all that works):
https://build.opensuse.org/package/view_file/openSUSE:Factory/virtualbox/ fixes_for_5.9.patch?expand=1
I am the author of that patch. All of those changes are needed because the kernel developers changed the API in a number of places in the 5.9 kernel. Without those changes, the modules would not build. -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1178360 http://bugzilla.opensuse.org/show_bug.cgi?id=1178360#c46 --- Comment #46 from Larry Finger <Larry.Finger@gmail.com> --- (In reply to Takashi Iwai from comment #38)
BTW, no VB package is provided on SLE.
I do ensure that the VB packages will build on SLE. Thus if a user wants to install VMs using VB, it would work. They would, of course, blow their warranty. Unfortunately, VB is rather insecure! -- You are receiving this mail because: You are on the CC list for the bug.
http://bugzilla.opensuse.org/show_bug.cgi?id=1178360 http://bugzilla.opensuse.org/show_bug.cgi?id=1178360#c47 --- Comment #47 from Larry Finger <Larry.Finger@gmail.com> --- (In reply to Stefan Hundhammer from comment #42)
virtualbox-kmp-default rebuilds the kernel module in its post-install script (and recreates the initrd with dracut). Is it possible or plausible that in certain situations it does that with the wrong kernel headers or something like that? Using the ones of the currently running kernel rather than the one that is also being installed in the same "zypper dup" run?
If you build a kernel module with the wrong headers, the resulting code will simply not load, thus your supposition is wrong!
Is it plausible that this might be only a missing dependency in the virtualbox .spec file; or a post-install script being executed at an inappropriate time, before the complete upgrade process is complete?
The VirtualBox modules do not need to be in the initrd as they are not loaded until the file system is up and running. Nonetheless, the install system puts them in initrd. The spec process is rather complicated; however, I think it is doing the right thing otherwise. -- You are receiving this mail because: You are on the CC list for the bug.
participants (1)
-
bugzilla_noreply＠suse.com