Qt FATAL: This application failed to start because it could not find or load the Qt platform plugin "xcb"

Recently I couldn't get VirtualBox to start on my Fedora 25 desktop. I kept getting the following error whether I tried to start as root or as my regular user:

Qt FATAL: This application failed to start because it could not find or load the Qt platform plugin "xcb"
in "".

Available platform plugins are: custom-wayland, eglfs, linuxfb, minimal, minimalegl, offscreen, wayland-egl, wayland, wayland-xcomposite-egl, wayland-xcomposite-glx, xcb.

Reinstalling the application may fix this problem.
Aborted

There are a lot of hits online for this error. I tried everything, and none of it worked. Finally, I did (as root, to avoid any permissions errors):

strace -o virt_strace.out -f /usr/bin/virtualbox

on my broken box and on a working box, and used meld to compare. Everything looked normal up until the very end:

25034 lstat("/usr", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
25034 lstat("/usr/lib64", {st_mode=S_IFDIR|0775, st_size=180224, ...}) = 0
25034 lstat("/usr/lib64/qt5", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
25034 lstat("/usr/lib64/qt5/plugins", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
25034 lstat("/usr/lib64/qt5/plugins/platforms", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
25034 lstat("/usr/lib64/qt5/plugins/platforms/libqxcb.so", {st_mode=S_IFREG|0755, st_size=15960, ...}) = 0
25034 open("/usr/lib64/qt5/plugins/platforms/libqxcb.so", O_RDONLY|O_CLOEXEC) = 7
25034 fcntl(7, F_SETFD, FD_CLOEXEC) = 0
25034 fstat(7, {st_mode=S_IFREG|0755, st_size=15960, ...}) = 0
25034 fstat(7, {st_mode=S_IFREG|0755, st_size=15960, ...}) = 0
25034 mmap(NULL, 15960, PROT_READ, MAP_SHARED, 7, 0) = 0x7fa3bca1b000
25034 close(7) = 0
25034 munmap(0x7fa3bca1b000, 15960) = 0
25034 stat("/usr/lib/virtualbox/platforms/.", 0x7ffd724e43f0) = -1 ENOENT (No such file or directory)
25034 lstat("/usr", {st_mode=S_IFDIR|0755, st_size=4096, ...}) = 0
25034 lstat("/usr/lib64", {st_mode=S_IFDIR|0775, st_size=180224, ...}) = 0
25034 stat("/usr/lib64/qt5/plugins/platforms/libqxcb.so", {st_mode=S_IFREG|0755, st_size=15960, ...}) = 0
25034 write(2, "Qt FATAL: ", 10) = 10
25034 write(2, "This application failed to start"..., 326) = 326
25034 write(2, "\n", 1) = 1

After looking more closely, I saw that the permissions on /usr/lib64 were different on both boxes. Broken box looked like:

ls -ld /usr/lib64
drwxrwxr-x. 235 systemd-timesync clamupdate 180224 Jul 7 08:17 /usr/lib64

After doing:

# chown root:root /usr/lib64
# chmod 555 /usr/lib64

I was able to start VirtualBox! This had been driving me crazy because I really wanted to use this box for testing with vagrant/ansible. Now we're back in business!

BTW, I do often use kvm instead of VirtualBox, and I would prefer it because of the simplicity of kvm networking, but I've never had much luck running kvm guests as my regular user (and getting sound working consistently). VirtualBox always just works in this regard. I may have to revisit this again to see if there's been any progress.

Gnome 3 crashing (or really gdm not starting?)

On my work laptop running Fedora 22 I suddenly had this problem where (I thought) gnome 3 was crashing. I ended up working around it either by: 1) a) changing the kernel line in grub2 to boot into single-user mode b) changing the target to multi-user.target c) logging in as my user d) starting gnome 3 with 'startx' 2) a) change the default target to multi-user.target b) reboot c) login as my user on the console d) startx There were no errors in Xorg.0.log. After a week of this and fruitlessly looking through journalctl output, I realized that: a) gnome 3 probably wasn't crashing, since: i) I could start it from startx ii) I wasn't even getting the chance to login to begin with b) it was probably a problem getting gdm started I searched on google for something like '"fedora 22" gdm crash blinking screen' and found this: https://www.maketecheasier.com/fix-wayland-gdm-issue-fedora/ And edited custom.conf and uncommented the 'WaylandEnable=false' line and rebooted. That was it. Phew. I could have done a much more efficient job of debugging this, but I kept forgetting about the problem in the first place, since I was so busy at work, once I got the desktop up, I'd completely forget about the original issue until I came in again the next morning.

Preventing the packagekit refresh when installing multiple rpms

I have many occasions to install some product rpms in a specific order one-by-one. When I'm doing this, I'm often annoyed by messages like this: Loaded plugins: fastestmirror, refresh-packagekit Existing lock /var/run/yum.pid: another copy is running as pid 13570. Another app is currently holding the yum lock; waiting for it to exit... The other application is: PackageKit Memory : 165 M RSS (1.5 GB VSZ) Started: Fri Oct 30 14:46:16 2015 - 00:03 ago State : Sleeping, pid: 13570 Using the first line as a hint, I tried this: yum --disableplugin=refresh-packagekit install and was able to make this go away (although I didn't disable it for the last rpm that I installed).