I tried the 5.1.x test build and the problem still exists. Haven't gotten around the others yet.

Chiming in with same issues here as well.

Under -current (20180718), getting X lockups. Console goes blank, can't switch virtual terminal anymore. Can ssh in, X session is missing, 'ps fax' shows bash running on the vt X was spawned from, with nothing else on that vt.

Have tested VirtualBox 5.2.12 and 5.2.16, with and without xf86-video-virtualbox, and with and without guest additions. Only variance has been X might not crash right away.

Nothing related showing via dmesg other than notice of vbox guest modules having loaded at boot.

Noted suggestion to try test builds of vbox, though with latest posted test version being between the versions already tried (5.2.15.x) I'm not hopeful. May get to it later today. Also noted suggestion that it's tied to xorg-1.20, not sure I'll get around to the version shuffle there.

I also had this problem, but found the source and a temporary solution.
I am running VB 5.2.16 and slackware current running kernel 4.17.8.
When I ran "slackpkg upgrade-all" with all packages selected, I ended up with same black screen others have experienced. I took the brute force approach to tracking the problem as follows:


1. restore Slackware Current from the last successful image copy
2. run slackpkg upgrade-all but selecting only a few packages which I felt might succeed
3. reboot system. If the boot is successful, shut down, take a new image, then restart, and go back to step 2. If not, shut down and go back to step1.
4. Rinse and repeat until all packages are processed except those that don't.


This was tedious but it worked. I tracked down two packages which, if processed, borked the system. They were


mesa-18.1.4-x86_64-1: This is the culprit which is causing the black screen and freeze. If skipped, the GUI comes up OK. BUT, you will then find that the cursor is visible but inactive. You can't do anything. This is caused by


xf86-input-libinput-0.28.0: If this is skipped everything works OK.


Bottom line, if you skip updating these two packages, you will have a working system. However, I don't know if the prob is something in VB itself or the way these packages have been compiled.

3 members found this post helpful.

Thanks for doing the work to figure this out. I wanted to do it, but was just to lazy to give it a go. I can confirm this works, hopefully someone will submit this bug to oracle, I would, but I don't want to start yet another forum account I will never use.

hi guys,
has anybody tried virtualbox with the latest mesa in current?

Yes, I tried mesa-18.1.5-x86_64-1 on the system I used in my post above. Sadly, it does not work either.

As far as I know, the last versions of the guilty packages which actually worked are

mesa-18.0.4-x86_64-1 and
xf86-input-libinput-0.27.1

1 members found this post helpful.

As I reported earlier, I have zero issues with Slackware64-current and ktown (Plasma 5). No matter how I install it, it always works.

No sure why it's not working for y'all.

I am using a local Slackware64-current mirror created with Alien Bob's mirror-slackware-current.sh which also creates an ISO to install from. My host system is Slackware64-current, VirtualBox is 5.2.16 r123759. My most recent install was to install Slackware64-current from the ISO created from the mirror script. I excluded the KDE series as part of the install. After that was installed, I mounted the mirror, set /etc/slackpkg/mirrors to point to the Slackware64-current mirror. Ran slackpkg gpg, slackpkg update, the mirror had an update so I ran slackpkg upgrade-all. Next I installed ktown (KDE 5_18.07). I then used xwmconfig to set to plasma. Next added a user, then ran startx from that user. No problems so far.

I have also tried installing Slackware64-14.2, upgrade to -current, clean out KDE4, install ktown, then run slackpkg. Still works.

The only thing I have not done is build a custom kernel I am currently with the stock 4.14.59.

I might have neglected to mention something important, that i install the virtualbox guest additions.
If i do not, then X works to a degree, but changing resolution will usually results in a black screen of death.

Try installing the virtualbox guest additions and let us know how it works for you.

i've done some testing on my side:

I've installed a brand new slackware64-14.2 in virtualbox with all the latest updates.
Then i've built 4.14.59 kernel based on slackware64-current generic kernel config.
After a reboot into the new kernel i've installed guest additions.

Result: with the 4.14.59 kernel, i have gui (xfce) but i can't change the resolution of the guest.
the display properties program segfaults.

With 4.4.14 without the guest additions x still works, and i can change the resolution in the guest.

Updated to 4.4.144, and built guest additions, now everything works fine.
I will try to build 4.14.59 with the kernel config from 4.4.144 and see how that will work.

For what it's worth:
My host machine is Slackware64-current (has been since 14.2 release). I have been running a Slackware64-current VM within VirtualBox since shortly after 14.2 and upgrading the host before VM every week. I started experiencing X lockups within the VM after issuing startx (to enter fluxbox) about the time this thread was created resulting in the VM being limited to only a console level usability. After creating a new VM and installing Slackware64-current again via AlienBob's mini 14.2 iso and using a Slackware64-current directory as the source location I have not experienced any lockups/hangs. I have been running VB 5.2.* before the lockups started with the previous VM. All VB machines have had the guest additions installed.

Everything is working now. I downloaded a fresh current iso and installed it in virutalbox 5.2.16. X started just fine, but after I installed guest additions the screen would turn black if tried to resize the VM. to fix that I switched the OpenGL driver to the proper humper/chromium driver. To do this you have to create a directory "mkdir /etc/ld.so.conf.d/" then add this line to your /etc/ld.so.conf file...

reboot and everything now works.

2 members found this post helpful.

Ah... perhaps I missed it. I have not been installing the VirtualBox Additions, just using the xf86-video-vboxvideo driver as it serves my purposes. One of the first things I do once Plasma is up is change my resolution to 1024x633 (monitor is 1366x768) from the default 1024x768 so the vm fits nicely with in the host without scroll bars. Never had a problem doing this. More on this later.

In the spirit of testing. I removed the xf86-video-vboxvideo driver. Installed the Additions for my installed version of VirtualBox (5.2.16). I switched resolutions from the lowest offered. 640x480 up to my monitors preferred resolution of 1366x768. There was 24 resolutions being offered by System Settings, Display:

System Settings, Display aborted a couple of times while testing. Particularly after switching to a resolution offered that System Settings, Display appeared not to like and adjusted accordingly; which resulted in a blank entry for Resolution. Closing and reopening System Settings, Display prevented that. Doing this will also let you see what the resolution was adjusted to.

Example: Selected 1280x720, System Settings, Display at first set the resolution to that, then adjusted it, leaving Resolution blank. Close/reopen System Settings, Display showed that 1280x663 was set. The original 1024x663 was no longer in the list. Selecting 1024x768 (the default resolution on first start) caused another "adjustment", closing, reopening showed the Resolution at 1024x663 and it was back in the list.

The only time I got the black screen was after selecting an available Resolution above 1366x768. Selecting that resolution resulted in an adjustment to 1352x663. At least once it resulted in a black screen with a bit of a delay compared to other times (resolutions above 1366x768 in the list) when it was instant on clicking apply.

Right now, more strangeness. The resolution on the Additions VM seems to be stuck at 1352x663. I wiped out all traces of KDE (deleted everything but .screenrc in ~) and /tmp and reboot. Startx results in a 1352x633 screen; which fits perfectly left to right edge of monitor, between the task bar (at top) and bottom edge. It look like the driver is attempting to fix to the screen. I set the resolution to 800x600, logged out, startx, the screen started at 1352x663, then changed to 800x600, then I'll darn, when back to 1352x663. Next I set to 800x600, then 1024x768, Settings didn't like that, I got the blank resolution, closing, opening Settings again show it was set to 1024x663. That setting stuck on logging out and startx again.

On thing I also noted, with the black screen the VM only responds to a Host+H or Host+R; Host+Del (Reboot), Host+Backspace no effect.

From the more on that later department. With the xf86-video-vboxdriver installed, the back screen also occurs. As with the VirtualBox Additions it appears to be only when the resolution is set to something that can't be handled, above the physical monitor preferred setting. Also similar behavior as described above in the more strangeness paragraph above when switching resolutions.

I have yet to have the screen go black once the resolution is set. The is indeed something wrong with both the VirtualBox Additions driver and the xf86-video-vboxvideo driver and Plasma. I just never encounter it, simply because I never set resolution to a higher value than my physical monitor preferred resolution. I was switching resolutions below that. I really make zero sense to me to set it higher anyway.

For now I will stick with the xf86 driver, as it comes stock with Slackware. The only advantage I see in using the VirtualBox Additions is clipboard sharing.

If anyone is still having issues, Daedra's solution worked for me, but I had to make sure the include statement was before /usr/lib64. I'd had that line at the end of /etc/ld.so.conf for yonks and never noticed that the wrong OpenGL drivers were in use until I got the black/frozen screen issue. My /etc/ld.so.conf now looks like:

and everything seems to be working properly.

in my recent tests, I found following:

xfce-live from here: http://slackware.uk/people/alien-slacklive/latest/
32-bit: vboxvideo worked, resolution 1440x900
64-bit: blank screen

bare system installed from -current with same packages selected:
same as above.
but everything is fine after revert mesa to 18.0.x

some details:
when run Xorg directly, it receive SIGSEGV and leave console blank
check with strace/gdb/valgrind, only got a callstrack list,
no idea how to dig more info...
already rebuild mesa with debug info, but nothing changed/found.
any suggestion is welcome

BTW: arch x86_64 is ok...

updated to today's 18.1.6, it's the same.