I am using Vagrant and VirtualBox for testing for my product. I had upgraded to 5.2 when it came out, but it doesn't work with Vagrant yet. So I uninstalled it (make sure you don't have any running VMs first: VBoxManager list runningvms). However, when I went to install VirtualBox-5.1, it failed with:
dnf install VirtualBox-5.1-5.1.30_118389_fedora26-1.x86_64.rpm
Last metadata expiration check: 0:33:50 ago on Thu 02 Nov 2017 01:33:06 PM CDT.
Error:
Problem: conflicting requests
- package VirtualBox-5.1-5.1.30_118389_fedora26-1.x86_64 is disabled
This was because I also had the package 'virtualbox-release' installed, which had put down a virtualbox.repo in /etc/yum.repos.d/. I guess this points at the 5.2 download, and those conflict. Not sure exactly about how the details work here.
In any case, I just removed virtualbox-release: dnf -y remove virtualbox-release, and I was then able to install VirtualBox-5.1 again (and make vagrant happy), so I could continue playing around with packer/vagrant/ansible and kickstart. Yay.
Thursday, November 2, 2017
Auto-updating Fedora with dnf-automatic
It wasn't straightforward for me to setup auto-updating on Fedora with dnf-automatic, so I thought I would document how I got it working and provide examples.
The obvious first step is to install dnf-automatic:
sudo dnf install dnf-automatic -y
The interesting bit was the next step: creating the configuration file:
The last configuration step is to enable the timers in systemd:
sudo systemctl enable dnf-automatic.timer && sudo systemctl start dnf-automatic.timer
The obvious first step is to install dnf-automatic:
sudo dnf install dnf-automatic -y
The interesting bit was the next step: creating the configuration file:
The last configuration step is to enable the timers in systemd:
sudo systemctl enable dnf-automatic.timer && sudo systemctl start dnf-automatic.timer
Friday, July 7, 2017
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.
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.
Subscribe to:
Posts (Atom)