UEFI for QEMU now in Fedora repositories

I haven’t seen any announcement, but I noticed Fedora repositories now contain edk2-ovmf package. That is the package that is necessary to emulate UEFI in QEMU/KVM virtual machines. It seems all licensing issues having been finally resolved and now you can easily run UEFI systems in your virtual machines!

I have updated Using_UEFI_with_QEMU wiki page accordingly.


UEFI for QEMU now in Fedora repositories

glxosd and voglperf now available for Fedora in COPR

For all our gaming enthusiasts, I packaged glxosd and voglperf for Fedora and you can find them in my COPR repositories: glxosd COPR and voglperf COPR.

These tools allow you to have FRAPS-like features on Linux, i.e. show an overlay in OpenGL games/apps to display current FPS, and also capture the frame times into a file and plot them to a graph later. So you can now use it with any Linux game and fine-tune its graphics settings to match your preferred performance. Or you can see when your CPU or GPU is overheating. Or you can contribute to Open Game Benchmarks. Or something else.

This is an example of the glxosd overlay in action (don’t worry, its output is configurable):

glxosd overlay

And if you want, you can later plot the performance into such pretty graphs using this awesome glxosd analyser web page:

fps graph
frame times graph

And this is an example of the voglperf overlay (top left corner):

voglperf overlay

And a generated graph:

frame times graph

There are other similar tools which you can use, but I know about any that is generic and has all these features. There is of course the Steam FPS overlay, but you can only use it for Steam games, and it can’t log frame information. There’s also GALLIUM_HUD, but that’s only available for Gallium-enabled drivers (radeon, nouveau) and also can’t log frame information. These two new tools should work with any driver and can be used for any game/app.

You can find installation instructions in the linked COPR repos. I do not intend to move these packages to official Fedora repos, but if somebody is willing to get their hands dirty and work on that, great, please contact me and I’ll try to help.


Flattr this

glxosd and voglperf now available for Fedora in COPR

GALLIUM_HUD: FRAPS-like FPS overlay for Linux

I have long been looking for a simple way to display the current FPS in games (without direct support in the game), similar to what FRAPS or other tools do in Windows. For Linux, I haven’t had too much luck. There are not many tools for this and usually there are some problems with them – either they are not packaged and complication is difficult, or they don’t work reliably, or they can’t display FPS overlay in the game, just log to a file. But this weekend, I have finally been lucky.

I have stumbled upon an older article from Phoronix: Gallium3D Gets A Heads-Up Display For Information. Gallium3D is a graphics acceleration framework that is currently used by radeon and nouveau drivers. By simply setting an environment variable, you can get a live on-screen overlay displaying lots of useful information:


This is pretty amazing and it does exactly what I was looking for. The usage is really simple – to see the available options, just run:

$ GALLIUM_HUD="help" glxgears
Syntax: GALLIUM_HUD=name1[+name2][...][:value1][,nameI...][;nameJ...]

  Names are identifiers of data sources which will be drawn as graphs
  in panes. Multiple graphs can be drawn in the same pane.
  There can be multiple panes placed in rows and columns.

  '+' separates names which will share a pane.
  ':[value]' specifies the initial maximum value of the Y axis
             for the given pane.
  ',' creates a new pane below the last one.
  ';' creates a new pane at the top of the next column.

  Example: GALLIUM_HUD="cpu,fps;primitives-generated"

  Available names:

In Fedora 20, only basic options like fps and cpu are available. In Fedora Rawhide with newer graphics stack, there are many more options. But I’m fully content with just the basic ones. Now I can run games like this:

$ GALLIUM_HUD="fps,cpu+cpu0+cpu1+cpu2+cpu3:100" mygame

And I have pretty two graphs of FPS and CPU usage. You can run steam the same way, and then see the overlay on each game started from it. And, as a bonus, you can even run totem or vlc (with GL output) like this and see actual FPS of your video rendering 🙂

I’m really excited about this. This is how I imagine a modern operating system to look like – useful features directly integrated into its core and very easily accessible (hell, it can’t get even easier than setting an environment variable!). Thanks Marek Olšák and AMD for implementing this. You really made my day.

The only drawback is that because it’s implemented in Gallium3D, it works only on Gallium3D-enabled drivers, which means opensource AMD and Nvidia drivers. No binary drivers and no Intel drivers can benefit from this. Marek explained that it had been very simple to implement this inside Gallium3D, but it would be very tricky to implement this on a level that would affect all the drivers. So there you have it, the opensource drivers now have a killer feature that proprietary drivers don’t 🙂 Just the Intel situation is unfortunate, maybe they’ll reconsider this some time in the future.


Flattr this

GALLIUM_HUD: FRAPS-like FPS overlay for Linux

KVM disk performance: raw vs qcow2 format

Some time ago I compared disk drivers performance in KVM. Today I compared different storage formats – raw and qcow2. Let’s have a look:

Test procedure: Create an empty 10 GB image, attach to VM using VirtIO driver, boot F20 Alpha Live x86_64, measure the time of installation. Repeat installation once again, this time reusing the existing image (instead of creating a new one). Do this for both formats.

Test results:

raw 1st pass          2:36
raw 2nd pass          2:38
qcow2 1st pass        2:36
qcow2 2nd pass        2:44

As you can see, the results are very much the same. It seems it doesn’t matter much which format you use.

But, qcow2 format has some nice additional features, like copy-on-write cloning. If I need to test something very quickly in my existing VM and then revert the changes back, this is the easiest way:

$ cd /var/lib/libvirt/images
$ mv f19.qcow2 f19.qcow2_orig
$ qemu-img create -f qcow2 -b f19.qcow2_orig f19.qcow2
Formatting 'f19.qcow2', fmt=qcow2 size=10737418240 backing_file='f19.qcow2_orig' encryption=off cluster_size=65536 lazy_refcounts=off
$ # Run the VM now and do your tasks
$ mv f19.qcow2_orig f19.qcow2


Flattr this

KVM disk performance: raw vs qcow2 format

Experiment with bleeding-edge GNOME using GnomeOSTree

I have just discovered GnomeOSTree (I’ve heard about it before, but never tried it). It allows you to run an absolutely fresh version of GNOME (checked out from git the very day) in a virtual machine. This is perfect for

  • experimenting with new features
  • checking whether a bug still exists in the development version
  • checking whether a bug fix is correct, without waiting for a distribution package update

I’ve just played with it for 10 minutes, so I might be missing a lot of things, but this seems to be a very useful tool for anyone testing and reporting GNOME bugs. It’s extremely easy to set up, you just download a VM disk image and import it into virt-manager. Later you can update it from inside the system. Try it!


Flattr this

Experiment with bleeding-edge GNOME using GnomeOSTree

Testers: Use more CPUs in your VMs, you’ll get more things done

Lately I’ve found out that I can speed up my Fedora 19 testing if I increase the number of CPUs assigned to the VM. This is a short blogpost about it, maybe it will help also others.

By default, this is what a default new VM in virt-manager looks like:


There is just a single CPU assigned, out of my 4 host CPUs available (Intel Core i7 processor).

In my completely unscientific benchmark, I tried changing the value and measuring how the boot time of Fedora 19 Alpha Live changes. It was measured from isolinux screen to displaying the Fedora welcome dialog. Of course I used a few warm-up starts first to make sure everything is cached and the results are not affected by the disk access. These are the results:

Fedora 19 Alpha Live boot time

Number of CPUs Boot time (seconds)
1 67
2 48
3 46
4 46

It seems that the boot process of a Live image can be well parallelized. There is a large difference between a single CPU and a dual CPU. Adding more than two CPUs doesn’t help considerably. Quite interestingly, when I tried to measure an installed system, the changes were very small:

Fedora 19 installed boot time

Number of CPUs Boot time (seconds)
1 29
2 27
3 25
4 27

The live image performs a lot of one-shot setup tasks during boot, that’s probably the major difference here.

I didn’t perform any further benchmarks inside the running system, for example Anaconda installation. It might be interesting to compare the installation speed with different number of processors, but I haven’t gotten to it yet (patches welcome:)). But because I boot Live images very often, at least I know that the boot process is significantly improved by using two CPUs in the VM. In my 4 CPU host system that seems as a good number. It doesn’t hog my host down too much, and if I really need it, I can run two VMs in parallel and they will fully utilize my processor potential, at the expense of my host system becoming a bit lagging.

As a side note, as I’ve found out, the default VM memory is 1024 MB. That is quite insufficient, your installation will suffer by a lot of swapping and it will take much longer. For pre-release images with debugging options enabled it might not even succeed. Usually I use 1.5 GB RAM for generic Fedora testing, and 2 GB RAM for pre-Beta testing (which includes debug kernel). With these amounts of memory I find the installation go pretty well. Of course you must have sufficient amount of memory available in your host system.

Also, don’t miss out on my previous blogpost about the speed of different disk bus drivers.

Happy testing!

Flattr this

Testers: Use more CPUs in your VMs, you’ll get more things done

How to run graphical applications with su or sudo

In this blogpost I’ll describe how to run graphical applications under a different user account in your current desktop session (i.e. without fast user switching). It involves some fiddling with the system configuration, this is not intended for general users without advanced system knowledge. The instructions are created for Fedora 18.

Everything mentioned here was discovered through a trial-and-error approach, I don’t have any expertise in this area. Some of the advice might not be fully correct. I have talked to a few qualified people and I was told that Linux doesn’t support this properly and some applications might display some glitches or not work at all. Consider this a best-effort solution – it might work perfectly for some applications, but you can’t expect it to work in general.

Some background

In my setup I have a regular user account kparal and also a second user account gamer that I use for several purposes:

  • Playing games. I use GNOME Fallback mode, so I get slightly better framerates (I have a very slow graphic card and it really makes a difference).
  • Running unknown and “not so trustworthy” tools and scripts, often downloaded somewhere from the Internet (i.e. not packaged in Fedora). I do not really expect malware in these tools, but more likely serious bugs. I like to know that the unknown script can’t delete my personal data by accident.

But using the second user account is sometimes also inconvenient:

  • If you need to transfer a piece of text (e.g. a hyperlink) from one account to the other, it involves saving it as a file, copying it and fixing permissions. Ugh.
  • If you are inside gamer session, you don’t see any notifications from your kparal‘s IM clients, mail clients, etc. You need to switch forth and back all the time to check your messages and reply.
  • If you are inside gamer session, you can’t easily access some files in your kparal home folder that you would like to, e.g. music. Just to play some background music, you need to fiddle with your data, set up permissions, etc. Boring.

Over the weekend I installed Steam. Obviously I run it under the gamer account. Not just because of performance, but also because my trust in Steam is far from being 100%. It downloads lots of external binaries and executes them. I trust Valve they are careful to not have any security incident (e.g. malware added to some of their game updates), they certainly have some security checks and policies, but how reliable are those? Does Steam executes everything inside some sandbox? I don’t know and honestly, running Steam (and dozens of third-party binaries it executes) in a separate account seems like a reasonable trade-off.

When I tried to buy a game in Steam, I needed to log in to my Moneybookers account. But my financial passwords usually consists of 20 random characters and are safely stored in a password manager in the kparal session. I got very annoyed at this point. The string is too long to remember, I was offended by the idea to write it down (what do we have technology for if I need to use paper?) and I didn’t really want to save it in a plain text file on disk. Call it a whim. So how do I transfer it? Why on earth can’t I just run steam under the gamer account inside my kparal session and copy and paste it? Windows can do it!

Well, it turns out Linux can do this too, more or less, but it needs a few tweaks. After that you can run any application under a different user account inside your desktop session. Let’s see how.

Basic application window

If you log in using su and run a sample graphical application, it should work out of the box:

kparal@kraken ~ $ su - gamer -c gcalctool

** (gcalctool:3969): WARNING **: Couldn't register with accessibility bus: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.

** (gcalctool:3969): CRITICAL **: unable to create directory '/run/user/1000/dconf': Permission denied.  dconf will not work properly.
(repeated many times)

There are some accessibility bus warnings, but I haven’t seen any loss of functionality, so I consider them mostly harmless. The dconf errors are arguably a bug and you might lose some functionality because of that – application settings might not be loaded nor saved. If you see these errors, you should unset XDG_RUNTIME_DIR variable first:

kparal@kraken ~ $ su - gamer
gamer@kraken ~ $ unset XDG_RUNTIME_DIR
gamer@kraken ~ $ gcalctool

 ** (gcalctool:3969): WARNING **: Couldn't register with accessibility bus: Did not receive a reply. Possible causes include: the remote application did not send a reply, the message bus security policy blocked the reply, the reply timeout expired, or the network connection was broken.

At this point most of your graphical applications should work just fine (the only problem I’ve found is that the global GNOME menu doesn’t work with them). Some of their functionality can be lost however, especially if the application tries to communicate over D-Bus with other processes. According to information I gathered, you might improve the situation in certain cases if you run the application using dbus-launch:

gamer@kraken ~ $ dbus-launch your-application

I haven’t yet seen any application where this would be required, so I can’t provide any more details. Basically if you see any errors regarding D-Bus, you can expect some loss of functionality. But often you might not care, it depends on what you need to achieve with that particular application.

Using sudo instead of su

I like to use sudo instead of su, because it caches your password and it can be even configured for password-less login. However the approach is not so straightforward here and requires more tweaking. Only follow this section if su doesn’t suit your needs.

In the basic workflow, this is what you will see using sudo command:

kparal@kraken ~ $ sudo -i -u gamer gcalctool
No protocol specified

** (gcalctool:5113): WARNING **: Could not open X display
No protocol specified

(gcalctool:5113): Gtk-WARNING **: cannot open display: :0

This is because your X server permissions do not allow anyone else to connect to it (IIUIC):

kparal@kraken ~ $ xhost
access control enabled, only authorized clients can connect

If you want to use sudo instead of su, you need to allow gamer to display the window in your session. Like this:

kparal@kraken ~ $ xhost +si:localuser:gamer
localuser:gamer being added to access control list

kparal@kraken ~ $ xhost
access control enabled, only authorized clients can connect

Now try it again:

kparal@kraken ~ $ sudo -i -u gamer gcalctool

The calculator should appear just fine. The xhost command has to be executed after each session start, so I wanted to add it to ~kparal/.xprofile, but then I found out that Fedora doesn’t source that file. I added it to ~kparal/.profile instead like this:

# allow gamer to display apps on this X server
# (don't do that for local non-X and any remote connections)
if [ -n "$DISPLAY" -a -z "$SSH_CLIENT" ]; then
    xhost +si:localuser:gamer

I now used the command above to run Steam in my session and paste in the Moneybookers login credentials conveniently. Success!


I quickly found out that sound is not routed for these redirected applications. It’s a pity it doesn’t work out of the box, but fortunately it can be fixed quite easily.

First, install and run paprefs and activate Enable network access to local sound devices. I have no idea which configuration was adjusted, because nothing changed neither in ~/.pulse nor in /etc/pulse. But you can see now the pulseaudio server listening over TCP/IP for network connections. Authorization should be required, so you don’t need to be afraid of eavesdroppers.

Now, try to play some sound:

kparal@kraken ~ $ su - gamer -c paplay /usr/share/sounds/alsa/Front_Center.wav

(or just run Totem/Firefox/etc)

If you are lucky (unlike me), your audio now works out of the box. But if you pulseaudio daemon is restarted for any reason (it crashes or you kill it and start again), the routing no longer works and you need to re-log to your desktop session. Probably a bug. I didn’t know that, so I spent hours reading PulseAudio documentation. It’s not the most thrilling experience.

If that magic routing didn’t work for you, or you need to play audio even after PA is restarted, this is what I involuntarily discovered:

  1. You can copy ~kparal/.pulse-cookie to ~gamer/.pulse-cookie (and re-assign file ownership). That will handle authentication.
  2. Then you can forward audio by sudoing to gamer, exporting PULSE_SERVER=localhost variable and running the app you wish.

(It should be also possible to route the audio using unix sockets (instead of TCP/IP sockets), but the damned documentation is not helpful at all in achieving this task.)

Graphical acceleration

Spot two differences:

kparal@kraken ~ $ glxinfo | grep render
direct rendering: Yes
OpenGL renderer string: Mesa DRI Mobile Intel® GM45 Express Chipset


kparal@kraken ~ $ su - gamer -c glxinfo | grep render
libGL error: failed to load driver: i965
libGL error: Try again with LIBGL_DEBUG=verbose for more details.
direct rendering: Yes
OpenGL renderer string: Gallium 0.4 on llvmpipe (LLVM 0x301)

Yes, your redirected applications don’t have 3D acceleration. Here is a more detailed error message:

kparal@kraken ~ $ su - gamer
gamer@kraken ~ $ LIBGL_DEBUG=verbose glxinfo | grep render
libGL: OpenDriver: trying /usr/lib64/dri/i965_dri.so
libGL error: failed to open drm device: Permission denied
libGL error: failed to load driver: i965
libGL: OpenDriver: trying /usr/lib64/dri/swrast_dri.so
libGL: Can't open configuration file /home/gamer/.drirc: No such file or directory.
direct rendering: Yes
OpenGL renderer string: Gallium 0.4 on llvmpipe (LLVM 0x301)

I tried to run chromium-bsu and extremetuxracer, both run around 30 FPS using software rendering. Not suitable to gaming at all.

Fortunately I’ve found out the reason. It’s all about access permissions to /dev/dri/card0 file, which represents your graphics card. If you log in using a standard graphical session, some daemon (probably logind) grants you temporary rw access to that file using ACLs:

kparal@kraken ~ $ getfacl /dev/dri/card0 
getfacl: Removing leading '/' from absolute path names
# file: dev/dri/card0
# owner: root
# group: video

But if you log in using su or sudo, you are not given proper permissions. I have found two solutions. The first one is to manually add gamer‘s ACLs after each boot:

kparal@kraken ~ $ sudo setfacl -m user:gamer:rw /dev/dri/card0

This can be added for example to /etc/rc.d/rc.local in order to be executed every boot. The other approach is to add gamer to the video group, which owns the file. In this case you don’t need to execute anything else on each boot, the change is permanent.

Now your 3D applications should work correctly:

kparal@kraken ~ $ su - gamer -c glxinfo | grep render
direct rendering: Yes
OpenGL renderer string: Mesa DRI Mobile Intel® GM45 Express Chipset

The simple games I tried now run at full speed.

Please note however, that there are slight security concerns when you elevate these permissions for gamer permanently. If the account gets hacked, the attacker can access your graphics card (maybe see your display? I don’t know) or even a camera (just if you used the video group approach, because this group also controls access to the webcam) while being logged in remotely. From this reason the first approach seems a bit safer to me (limits the number of devices) and you should definitely prohibit gamer from any remote access (e.g. disable this account in your ssh server configuration).


That’s it, I can finally display graphical applications (even games) from a different user account inside my desktop session. It took me quite some time to find this all out. It’s highly probable that I did a lot of things the wrong way. Does anybody know of a tool that would handle all this setup transparently and easily? Or does anyone know a working sandbox tool that would fit these use cases? Please share your improvements in the comments. Thanks.

Flattr this

How to run graphical applications with su or sudo