I’ve just received my review copy and checked the table of contents. Several recipes looked useful considering my interest in JRuby and other non-Java JVM languages. Once I’ve completed my review I will post it here for future reference.

I received my postcard from André yesterday thanking me for becoming a Friend of Gnome. As I write this their campaign to hire a sysadmin for Gnome is about $114 away from meeting their goal!

If you also love the Gnome desktop, consider sponsoring the project. As André noted in his postcard, hackfests are an integral part of the Gnome lifecycle and many developers cannot afford to travel to one of these key events without the assistance of the Gnome Foundation. Sponsorships make it possible.

Normally I would have reverted to a previous kernel, but in this instance the machine had just been clean installed with web repositories, so it only had the broken kernel. To make matters even worse, the DNS server refused to return information about the machine, which had registered with DHCP, but hadn’t sent the host name. Since I didn’t know the IP, I couldn’t log in with SSH.

Single User mode to the rescue! This is the perfect use for a single user login. The procedure is pretty simple, as far as Linux recovery steps go.

1. Interrupt grub at startup and press ‘a‘ to edit the kernel line.
2. Remove the ‘rhgb‘ and ‘quiet‘ options and replace them with ‘single‘
3. Boot the kernel with your modified options
4. Once the kernel boots, you can run disk checks or other repair activities.
5. In this case, I wanted to continue to a normal boot prompt, which is run-level three. On Fedora and other RedHat-derived systems simply type ‘init 3‘ at the single user prompt.

The machine will immediately continue with the boot sequence, starting other necessary services. The process stops at a login prompt. Hopefully you have instructions to assist in fixing the problem from there. When you are done you can issue a ‘reboot‘ and find out if you’ve fixed the problem!

Help support the GNOME Foundation’s goal to provide a free desktop for all users – become a Friend of GNOME. Your donation will ensure that GNOME continues to be a free and open source desktop by providing resources to developers, software and education for end users, and promotion for GNOME worldwide.

The GNOME desktop is free and accessible software available in many languages. GNOME is the software of choice for programs like One Laptop Per Child, governments, and mobile phone applications.

If you are a user of Ubuntu, Fedora, or another Linux distribution which packages Gnome as the default desktop, or you use it heavily for other reasons, consider supporting a part-time employee to manage the Gnome servers. As of today the project has $5,303 to go to reach their goal.

I’m personally fond of the “Adopt a Hacker” subscription, which starts at $10 a month. I’m placing my donation today to adopt the work of ‘Johnny Jacob‘ who is working on the Evolution MAPI provider. (Technically you have to choose from a list, probably because they send you a postcard, but in spirit I’m adopting Johnny!)

Here’s my reason to support Gnome:

Since my employer made the switch to Exchange 2007, I sadly had to switch from my Ubuntu laptop back to a Macbook so I could work effectively with my coworkers. Almost a half dozen people that were managing to use Linux as our primary desktops were forced to migrate to another platform. One die-hard even used Outlook on our overworked Terminal Server via Remote Desktop so he could keep his Linux desktop. So, for me I’ve placed a personal priority on returning to my Linux desktop as soon as possible, and I can’t do that without great MAPI support. Thus, Johnny Jacob will receive my support.

So, if you have a similar story, please consider becoming a Friend of Gnome today, thanks!

[edit---]

I’ve started my subscription by adopting Gnome hacker Andre Klapper for his tireless work as bugmaster, especially as Bugmaster Emeritus on Evolution.

From my laptop I SSH’d in and discovered that the nvidia driver had oops’d and killed X11 very dead. Searching the forums led me to believe my problem was from the most recent kernel update and selecting the previous kernel from the grub screen proved to boot normally.

This is the first occasion where I’ve ever needed to blacklist an item from yum. The process is pretty simple, so I’m jotting it down here for future reference.

First, determine the package which is causing the problem, the “kernel-2.6.32.9-70″ in this case.

Note: if you have a recent clean installation, which doesn’t contain an older “safe” kernel in the grub menu you can probably still boot into single user mode.

$ rpm -q kernel

kernel-2.6.31.12-174.2.19.fc12.x86_64
kernel-2.6.31.12-174.2.22.fc12.x86_64
kernel-2.6.32.9-70.fc12.x86_64

Next, edit the /etc/yum.conf file to add the broken package to the excluded list. In this case the most recent kernel, 2.3.32.9 seems to be the problem.

$ su -c "vim /etc/yum.conf"

Add the following line to exclude this exact package. You may also use wildcards, in the form “kernel-2.3.32*” and separate items with spaces. By blacklisting the entire kernel 2.3.32 series with a wildcard you can remain on the stable 2.3.31 kernel until some of the issues are ironed out.

Remember, when blacklisting the kernel, there is more than one RPM related to the kernel. If you use akmod to build a new nvidia driver you will also need to blacklist the -headers and -devel RPMs.

exclude=kernel-2.6.32.9-70.fc12.x86_64

Here’s what my yum.conf looked like when I was done, for reference.

[main]
cachedir=/var/cache/yum/$basearch/$releasever
keepcache=0
debuglevel=2
logfile=/var/log/yum.log
exactarch=1
obsoletes=1
gpgcheck=1
plugins=1
installonly_limit=3
exclude=kernel-2.6.32* kernel-headers-2.3.32* kernel-devel-2.3.32* kernel-firmware-2.3.32*

#  This is the default, if you make this bigger yum won't see if the metadata
# is newer on the remote and so you'll "gain" the bandwidth of not having to
# download the new metadata and "pay" for it by yum not having correct
# information.
#  It is esp. important, to have correct metadata, for distributions like
# Fedora which don't keep old packages around. If you don't like this checking
# interupting your command line usage, it's much better to have something
# manually check the metadata once an hour (yum-updatesd will do this).
# metadata_expire=90m

# PUT YOUR REPOS HERE OR IN separate files named file.repo
# in /etc/yum.repos.d

Finally, remove the broken packages from the system.

su -c "yum remove kernel-2.6.32.9-70.fc12.x86_64 kernel-headers-2.6.32.9-70.fc12.x86_64 kernel-devel-2.6.32.9-70.fc12.x86_64 kernel-firmware-2.6.32.9-70.fc12.x86_64"

UPDATE 2010-04-06

I have updated this post to improve the original instructions if your system doesn’t have a previous working kernel. This recently happened to me when I clean installed a machine with the Fedora Updates repository enabled during installation.

I had failed to blacklist the related kernel RPMs such as kernel-headers, this prevents akmod from creating new drivers if you haven’t already generated them.

If you have a clean installation which contains the 2.3.32 kernel you can “yum downgrade” the packages:

su -c "yum downgrade kernel kernel-headers kernel-devel kernel-firmware"

I had some trouble downgrading the -devel package, so instead I “yum install”‘d it again and yum installed the non-blacklisted previous version alongside the blacklisted version. I then removed the broken -devel package. Make sure that you double-check that you have removed the new/offending RPMs before you restart.

rpm -qa | grep kernel

While I was updating the WordPress table names I wound up locking myself out of the system. This manifests itself as the following error when you log in:

You do not have sufficient permissions to access this page.

Luckily, the exact fix is contained here:

http://www.routeofqueue.com

Namely, there are some database table names buried in a few settings within the database. Thus it takes more than a wp-config file update to switch table names!

I am running IntelliJ IDEA on an Ubuntu 9.04 desktop at work and I’ve had troubles when the IDE attempts to run build scripts, such as Ant or Maven. Typically the scripts would fail with an error message along the lines of “unable to find ${env.APP_HOME}” when looking for a folder whose path was set by my environment variables.

I’ve troubleshot this and found that IDEA isn’t starting with any of my login environment variables when launched from the panel. When I started the IDEAPATH/bin/idea.sh script from the Terminal, everything was peachy. It only failed when I started the application with the gnome-panel or Gnome-Do.

There has been at least one bug filed about this on the IntelliJ bug tracker as best I can determine. People are often caught by this and post regularly in the Jetbrains Community Forumns. Perhaps Google will turn up this post and save a few of them the hassle.

I am also working on another post regarding integrating IntelliJ into a Gnome or KDE desktop, coming shortly.

If you are using Linux:

The fix is quite easy, prepend the shell command with ‘bash --login‘ like so:
bash --login IDEAPATH/bin/idea.sh

Once bash starts as a login shell it will read the correct configuration files and set your environment just as if you had logged in. Simple, right? If you have created a custom desktop entry simply edit it with the menu editors in Gnome or KDE.

If you are using a Mac:

A similar problem can occur, make sure you start IDEA via the application icon, and not using Spotlight, or make sure that Quicksilver has found the real application (.app) and not the startup script (.sh) when you launch it. Personally, I locked Quicksilver to the “correct” version of IDEA, since I also had several installed, and it’s worked well since.

You can add required environment variables to the launchd.conf file, which will make them available to all processes started via Spotlight.

$ sudo vim /etc/launchd.conf

Add the Java environment variables to the file.

setenv JAVA_VERSION 1.6
setenv JAVA_HOME /System/Library/Frameworks/JavaVM.framework/Versions/1.6/Home
setenv GROOVY_HOME /Applications/Dev/groovy
setenv JRUBY_HOME /Applications/Dev/jruby
setenv ANT_HOME /Applications/Dev/apache-ant
setenv ANT_OPTS -Xmx512M
setenv MAVEN_OPTS -Xmx1024M
setenv M2_HOME /Applications/Dev/apache-maven

Reboot the Mac and test your changes with export or env.