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!

Diving into SQLite Using Python

...Or, The Trouble With Tuples.
(Sorry, the pun had to be made).

For the past 3-ish months, I've been teaching myself Python. I started off with Wesley Chun's Live Lessons video tutorials, and later moved on to his book Core Python, 2nd ed. It has been a satisfying ride so far. Not without tribulations of course, but things are coming along nicely.

Once I had learned enough of the basics, I jumped into writing some programs. Simple things at first of course such as number guessing games and the like-- at first taken from textbook exercises, but later also incorporating various other amateur programming challenges I found on the web.

My most recent project is a database manager application. Originally it was a response to a programming challenge posted on the Ubuntu Forums, but slowly developed into a larger and more powerful app as I decided to add more and more features not called for in the assignment.

Development of the app moved along at a steady pace until I implemented record deletion. I could successfully search the DB using a parameter entered by the user and edit the record, but when I tried to delete it I was met with the error:

ValueError: parameters are of unsupported type

This was something I had not previously encountered. After exhausting my available resources, I decided to ask for help on the Ubu-forums. I started a thread (full details about the program and the solution can be found therein) and got my answer in short notice. Essentially it was this:

I had already successfully implemented DB record editing with the statement

cursor.execute('UPDATE main SET FName=?, LName=?, age=? WHERE id=?', (dataFName, dataLName, dataAge, record))

This part of things worked without a hitch. But when, in the same function, I ran

cursor.execute('DELETE FROM main WHERE id=?', (record))

I would get the "unsupported type" error.

The problem, I learned, was with the variable "(record)" that I was passing to the SQLite statement. The data passed needs to be of type Tuple and I was not providing one. I was providing a mutable string!

I was puzzled by the fact that the edit statement worked and the delete statement did not. It dawned on me that I was inadvertently creating a Tuple in the edit statement-- this was completely a by-product of me passing multiple variables across. It just happened to be creating the tuple I needed without me realizing it. With that in mind, what I had to do was make a very small change to the delete statement in order to create a tuple. I added a comma after record so that the statement read:

cursor.execute('DELETE FROM main WHERE id=?', (record,))

And that was all it took! Lesson learned. Things are moving along nicely with this hurdle out of the way and I hope to soon be finished with the app.

A Full HDD = Trouble: A Cautionary Tale

This weekend I learned an unexpected lesson in system admin: what happens when the partition containing my /home/ folder runs out of free space.

While doing a re-installation of my system after hosing my GRUB, I backed up a few GB of documents from a location that was to be wiped out to my home folder. That extra disk consumption, combined with a large file download I initiated after brining my system back online, was enough to fill up the HDD containing the partition where my /home/ folder is located (for ease of re-installation in the event of a problem I mount a second partition to my /home/ folder).

The first thing that happened was I noticed that the file I was downloading suddenly registered a nondescript "error" at about 45% completion. After trying to re-start it a couple of times and having no joy, I decided to restart the system. Bad idea. Upon logging back in, I noticed a lot of screwy behavior: Docky, which I use in place of a bottom panel, would not start and thew a lot of errors when I tried to launch it from the command line, my Compiz settings all reverted to default, Firefox launched upon login despite me not configuring my session as such, and other seemingly unrelated problems.

After a few logouts/restarts did not alleviate any of the problems I had run into, the wheels started turning. I realized quickly what had gone wrong and confirmed in Nautilus that I had in fact run out of space on my /home/ partition. No problem, I thought, I'll free up some space by emptying the Trash. Well, guess what: when the disk is full, it is not possible to do this (I guess GNOME needs some disk space to perform the operation). When I tried to empty the trash I got a progress bar and the message "perparing", but the operation halted without anything actually being removed.

Ultimately, I was able to get out of this pinch by moving a few GB of data from /home/ to / via the command line. Once that space was freed up, I was able to empty the trash, re-arrange a few things, and everything went smoothly from there.

Everything appeared ok until I tried to load up Banshee and play some music. I loaded a playlist and clicked play, and playback halted after the first five items failed to play. I launched from the command line and tried again, at which time Banshee threw the error:

GStreamer resource error: NotFound

A bit of googling suggested that Banshee's DB had become corrupted. This proved to be the case as I was importing some new media at the time I ran out of disk space. This must have happened just as data was being written to banshee.db.

So, as suggested on a few sites, I backed up and deleted the file ~/.config/banshee-1/banshee.db. Sure enough, I was able to re-import my music and successfully play it again.

Unfortunately, playlists did not go so smoothly. Before deleting the original DB I exported each playlist to an M3U file so that I could import them again after re-creating the music DB. I told Banshee to import the playlists and watched as it loaded each one-- with zero songs in each. This was a painful discovery: with about 10,000 songs in my library spread across 15 or so playlists, there was no way in hell I was going to go through re-creating them all. I was determined to find a way to fix this.

Luckily, I found one. When examining the M3U files in gedit, I noticed that for some reason Banshee had not saved the file locations properly. Rather than an absolute path of /home/rick/Music/artist/album/song, the playlist entries were /home/rick/artist/album/song. I have no idea why the /Music folder was completely left out of the file path, but I verified that this is what happened to each and every one of my playlists. A few quick "find and replace" operations later, my playlists were back in order again, and the episode had finally come to an end.

My takeaway from this? Pay attention to disk usage and don't run out of space again!

Now I just need to find out if the Banshee team are aware of the problem I ran into when exporting my playlists...

On Importing Wordpress to Blogger

One thing that held me back in moving to blogger was the lack of support for importing my old blog posts from my Wordpress blog. It's no secret that Wordpress makes migrating from blogger, but blogger doesn't make it easy to migrate in the other direction. A bit of googling turned up a few scripts and sites that supposedly could properly format my Wordpress xml file for importing, but none worked except for wxr2blogger, which finally make the task possible.

I was not able to accomplish the import after using the online converter for some reason (blogger would choke on the file, despite it being only about 53 KB in size) but thankfully, the command-line version did the trick. I ended up with 6 separate xml files, each containing a "chunk" of old posts. These imported successfully. For some reason, a couple of my posts did not show up in my dashboard, but it was easy to re-create them by snagging the HTML of each post out of the Wordpress dashboard and just re-posting them here. So, for anyone who may find this post while searching for a way to migrate from Wordpress to blogger, I recommend wxr2blogger.

Update Manager Errors - Resolved!

For a months now I've been getting a pesky error from Update Manager when checking for updates:

W:Failed to fetch http://archive.canonical.com/ubuntu/dists/intrepid/Release Unable to find expected entry main/binary-i386/Packages in Meta-index file (malformed Release file?)

This is probably something that most linux users see in some form at one time for another and while I had googled it a few times, I had not managed to resolve it. This was OK because while a bit annoying, it was not a show-stopper as I could simply dismiss the error and continue on my way.

That was, until today, when I finally got around to upgrading to Ubuntu Jaunty. The problem went from being a nuisance to a genuine problem as it caused the dist-upgrade to fail.

Determined to find a way around it, I again began by searching the Ubu-forums for simply the tail end of the error (beginning with "Unable to find..."). This time, I found a thread where someone actually had an issue similar to mine and had managed to find the issue. The problem in my case was two incomplete lines in my sources.list, namely:

deb http://archive.canonical.com/ubuntu intrepid main
deb-src http://archive.canonical.com/ubuntu intrepid main

As one person on the forums put it, "They should all end intrepid something". Sure enough, commenting out these two lines resolved the issue! How I ended up with two incomplete lines, I have no idea: as a rule I try to avoid editing sources.list by hand to avoid issues such as this one, save when adding third-party repos (which these two were not).

At any rate, the problem is solved at last and I am downloading the updates for Jaunty as I write this.