Penumbra

This weekend I picked up a copy of the Penumbra Collection. The three-part game is on sale this weekend and, since the developers were good enough to produce a native Linux version, I was eager to support them by making the purchase.

I paid for and downloaded the game, ran the installer, and launched it. This is when I ran into an issue. As soon as I launched the game, my monitor (actually the TV in the living room) went dark and gave me a message about the signal being unsupported. I had audio and heard the game intro playing, but I couldn't escape the window. My only option was to reset the computer. Great, I thought, what's wrong now? Driver issue? Do I need to tweak xorg.conf? I set about digging for an answer.

The first thing I did was install and enable dontzap so that I could at least restart X without resetting the whole computer, which did help as I ended up launching the game a few times as I tried to troubleshoot.

As an alternative to restarting X the good old fashioned way, I also did the following: when the game started and I was left with no display, I dropped into a virtual terminal (ctrl+alt+F1), ran the top command, found the PID for the game, and killed it (sudo kill -9 [PID]). However for whatever reason, I was still unable to get back to my graphical terminal after doing this and had to restart X anyway by running sudo /etc/init.d/gdm restart. So, a simple ctrl+alt+backspace was still the way to go.

Anyway, on to the information hunt. A few google searches as well as a look through the devs' Linux support forum turned up a few related or similar problems, but nobody seemed to be running into the exact problem that I was. The ones that were similar were all running Intel or ATI graphics cards (I have NVIDIA).

Normally, my first trick in troubleshooting this kind of thing is to run the program from the command line and see what errors it throws. However since I was running into a situation where I had to restart X or take the entire system down, anything displayed in Terminal would obviously be lost. So, I decided to dump any Terminal output into a log file by running:

/home/rick/PenumbraCollection/Overture/penumbra > ~/Desktop/penumbra.log

The log file contained only this:

Penumbra: Overture exited unexpectedly, please check
/home/rick/.frictionalgames/Penumbra/Overture/hpl.log
for any error messages
Also try running
ulimit -c unlimited
And re-running Penumbra and try and recreate the error
then submit the generated core file or stack trace

This output was generated only when I killed the process. I wondered to myself how there could not be any errors thrown when I launched the game. Then it hit me: there were no errors thrown because the game was running just fine! The problem was with my monitor-- the signal was unsupported, but it was receiving something. I looked in ~/PenumbraCollection/Overture/config/default_settings.cfg and found what I expected in the form of the following line:

Screen Width="800" Height="600" FullScreen="true" Vsync="false"

Cripes, I thought. It was simple all along! The 1080 TV I'm using doesn't support 800x600! Insta-facepalm. I edited the line, replacing 800 and 600 with 1920 and 1080 and viola! I had picture when I launched the game again. The problem was far more simple than I had imagined. Now I know what I'll be doing for the afternoon...

Upgrading to VirtualBox 3.0

Today, as sometimes happens, I ran into a situation where I needed to run a Windows-only app. Having recently moved over to a new laptop, I didn't have an existing virtual machine to use. What I did have was an old installation of VirtualBox 2.1

Having recently read about the release of version 3.0 of the venerable VM host, I figured now was as good of a time as any to upgrade. After modifying sources.list and importing the apt-secure key, I initiated the download:

sudo apt-get install virtualbox-3.0

I checked back a few minutes later and much to my shagrin, I was greeted with an error message about the kernel module failing to compile due to the kernel headers not being present.

This, I realized, was the first snag I had run into due to upgrading to the upstream 2.6.30 kernel to fix issues I had been having with poor 2D acceleration in Jaunty (reference).

Not prepared to give up, I headed over to the Ubuntu kernel repository where, thankfully, the 2.6.30 kernel headers were available. I grabbed and installed the appropriate deb, and ran the familiar:

sudo /etc/init.d/vboxdrv setup

And was greeted with another error:

* Stopping VirtualBox kernel module
* done.
* Recompiling VirtualBox kernel module
* Look at /var/log/vbox-install.log to find out what went wrong

The log gave me this:

Error! Your kernel source for kernel 2.6.30-020630-generic cannot be found at
/lib/modules/2.6.30-020630-generic/build or /lib/modules/2.6.30-020630-generic/source.

Silly mistake on my part this time. I had downloaded the kernel headers, but not the kernel source. I grabbed and installed the kernel source deb, and this time the kernel module compiled without a hitch.

I am installing a WinXP guest machine now.

Fallout

Recently I blogged about my misadventures with a full partition that contained my $HOME folder. I noticed not long after that episode that I still had some strange behavior, such as various program preferences not being saved and issues copying some files during a data backup.

After doing a bit of sleuthing, I concluded that in addition to the issues I wrote about at the time, my $HOME permissions had been altered. I did a bit of digging and from a few different forum threads, I plucked out a few commands that helped me to restore things back to their normal order. What I had to run was the following:

sudo umount ~/.gvfs --> unmount the GNOME Virtual File System config so that I can...

rm -r ~/.gvfs --> ...delete it, to allow...

sudo chown -R rick /home/rick --> ...everything to properly be chown-ed by me.

And finally:

chmod 755 ~ --> Set proper permissions for ~ (Read/Write/Execute for me, Read/Execute for everyone else).


Yes, some of these things can be done through Nautilus, but that method is not recommended. The reason being that Nautilus does not always handle permissions as gracefully as the trusty command line.

So there you have it, a two-part post on what how to remedy a broken system. Again, the upshot is not to let this happen to begin with!