Wednesday, December 30, 2009

Ubuntu 9.10 and GeForce 7800 GT

Note: This issue seems to affect Ubuntu 9.04 Jaunty, and Ubuntu 9.10 Karmic, in both 32-bit and 64-bit versions. I've seen some anecdotal evidence that it affects earlier releases too.

I recently set out to install Ubuntu 9.10 on my aging old home PC: an Athlon64 3800+, 2 GB RAM, decent (at the time) Asus board. Most importantly, this machine has an NVidia GeForce 7800 GT video card. To my surprise (having installed Ubuntu on numerous other machines of various age), I had a myriad of problems with the install. The symptoms were as follows:

  • Installer would freeze with corrupt looking graphics if I tried to change certain options
  • If I took all defaults in the installer, I could get the OS installed, but it would lock up (again with corrupt looking graphics on screen) when selecting my user name in gdm when X started up

Googling around at length revealed others with similar problems, and the common element was the GeForce 7800 GT video card. Related links:

I don't really know what the root cause is here, but using the above info, here's a work-around: (This assumes you got the OS installed somehow, and are now at the point where you want to login, but cannot due to X locking up.)

  1. Get to a terminal either by recovery booting to the shell (netboot), or by hitting ctrl-alt-f1 at the graphical login screen.
  2. Add the NVidia ppa to get access to their newest drivers:
    sudo add-apt-repository ppa:nvidia-vdpau/ppa
    sudo apt-get update
  3. Remove any existing NVidia driver:
    sudo apt-get purge nvidia-glx-*
  4. Install the newest driver:
    sudo apt-get install nvidia-glx-195
  5. Configure the newly installed driver:
    sudo nvidia-xconfig
  6. Reboot and you should be good to go.

Thursday, December 17, 2009

EC2, fabric, and "err: stdin: is not a tty"

Recently, I've been using fabric to script up some deployments to EC2. My EC2 server is running the 32-bit Ubuntu Jaunty 9.04 server image provided by Alestic, but I suspect this issue applies across lots of different OS variants. Fabric seems to work well, but I was getting a nuisance message when running commands on my EC2 instance: err: stdin: is not a tty. You can even see the message in action in the output of this (very useful) intro to fabric that happens to show an EC2 example.

Some searching turned up that this is a result of a command in a .profile or .bashrc on the remove host expecting the shell to be interactive, which it is not with fabric.

In my case, the culprit was /root/.profile, in particular the command mesg n. To fix the message, I wrapped the mesg call in a check for an interactive tty:
if `tty -s`; then
    mesg n

Monday, December 14, 2009

Scala Lift, Jetty 6, static content, and Virtual Directories

I have a simple web application written using the Lift framework. I am using Maven to build and test with, in the way recommended by various Lift docs (i.e. I use mvn jetty:run to launch the app). I ran into an issue when it came to serving static image content, however.

  • The app is called webapp
  • The app deploys to /webapp
  • Images are on local disk at /hdd/data/images (i.e. not in the .war)
  • Want to access images from /images (i.e. outside of the context root of the Lift app)
  • Needs to work when developing and running with Maven's jetty:run

The main issue was simply "how do I setup a virtual directory from http://server/images to /hdd/data/images on disk?" This seems trivial, but I had a really difficult time finding any straightforward docs on how to do it. My complicating requirement was that it had to work when developing with jetty:run. For "real" deployment, the images location will be manually configured, so whether this makes sense in production is not a factor here.

Long story short: you can configure the maven-jetty-plugin to load up additional "context handlers" at startup. Some decent info on this here. A context handler of type WebAppContext will do the job as far as acting like a virtual directory. Here's the config from pom.xml for the project:

            <!-- setup a simple webapp to serve our images -->
            <contextHandler implementation="org.mortbay.jetty.webapp.WebAppContext">

I make no claims about this being secure or the best way to do things, but after a lot of trial and error it does at least work.