Tag Archives: update

Installing a new kernel on Debian

Server, , ,

Update: If you install it using another method, the kernel can simply by updated with the standard APT update tool. However, there is a bug in the kernel update script. After the update, the USB drive is not longer recognised. It has the error sd_mod: Unknown symbol scsi_verify_blk_ioctl. To fix this, you must flash the kernel to the internal memory with (it might be needed to install flash-kernel first): sudo flash-kernel

Original post: I installed my SheevaPlug with Debian on an SD card using the alternative Debian install method. This works great, with one minor drawback: the kernel is never updated by Debian package management. Luckily, it’s not that complicated to install a new kernel. Sheeva with Linux publishes kernels for the Sheevaplug. There is also a script to update the kernel. On my Sheevaplug however, I could not use this script. The kernel is saved on a small boot partition of the SD card. This partition is too small to copy a new kernel to. Manually doing all the steps is straightforward too.

  1. By default, the boot partition of the SD card is not mounted, so mount it to /boot:
    mount /dev/mmcblk0p1 /boot
  2. Make backups of the file that will be overwritten. This include the file /boot/uImage and the folder /dev/firmware
  3. Go to Sheeva with Linux and choose a kernel, the latest will be fine. At the time I did this, this was 2.6.35.2. Download the files sheeva-*-uImage, sheeva-*-System.map, and sheeva-*-Modules.tar.gz. Just save them in your home directory
  4. Execute the following commands to extract the new modules and install the symbol table (replace {ver} with the kernel version you downloaded, e.g. 2.6.35.2):
    tar x -C / --overwrite -zf sheeva-{ver}-Modules.tar.gz
    depmod -eF /boot/sheeva-{ver}-System.map {ver}
  5. Remove the old kernel and copy the new kernel:
    rm /boot/uImage
    mv sheeva-*-uImage /boot/uImage
  6. Reboot with the command reboot

The SheevePlug should now reboot. After a minute or so, you should be able to log in again. Use the command uname -a to check if the new kernel is running. If something goes wrong, you can remove the SD card from the plug, put it in another computer and restore the backup files. I did everything from a SSH session. If you want more information (e.g. the error message during boot), you can do the upgrade over a USB terminal connection.

A script to fix Geo Mashup update

Server, ,

On one of my web logs, I use a map to display the route of my travels. Each post is geo-tagged, so places can be connected with lines. It’s a very nice feature for a travel blog, thanks to the Geo Mashup plugin for WordPress. I recently updated the Geo Mashup plugin to a new version. For this version, the locations had to be converted to the new format. The result of this upgrade was that my route was no longer correct: posts seemed randomly connected to each other.

After some investigation, I found that Geo Mashup uses a special table to link posts and location to each other. This link also has a date and time connected to it. The results are ordered using this date. During the conversion, each link had the date of the conversion. Therefore, the results were displayed random.

I wrote a quick PHP script to fix this problem. This script looks at the time the original post was made, and updates the Geo Mashup table.


// CONFIG

// username for the database
$USERNAME = 'username';

// password for the database
$PASSWORD = 'password';

// name of the database containing WordPress
$DATABASE = 'wordpress';

// host for the database (99% chance it will be localhost)
$HOST = 'localhost';

// END OF CONFIG

$link = mysql_connect($HOST,$USERNAME,$PASSWORD) or die('Cannot connect to database '.$HOST);
$x = mysql_select_db($DATABASE,$link) or die('Cannot select database '.$DATABASE);

$result = mysql_query("SELECT * FROM wp_geo_mashup_location_relationships");
while($row = mysql_fetch_assoc($result)
{
$result2 = mysql_query("SELECT post_date FROM wp_posts WHERE id=".$row['object_id']);
mysql_query("UPDATE wp_geo_mashup_location_relationships SET geo_date=\'" . $row2['post_date'] . "\'");
}

After running this script, the problem was fixed, and my map displayed the correct route.

Upgrading WordPress MU to WordPress 3.0

Server, ,

The various site on this server are powered by WordPress. Because there are multiple sites, I use WordPress MU (multi user). This fork of WordPress allows running multiple blogs from one installation, either in sub directories, or (in my case) on sub domains.

A couple of days ago WordPress 3 was released. WordPress MU is now integrated into WordPress. This is good news, because now there is only one WordPress, and I can easily upgrade to new versions, without having to wait for an updated WordPress MU version. But the first task, upgrade WordPress MU to WordPress 3.

There is a very handy auto update feature. You simply have to click a link and the update takes place, or so is the theory. That sort-of worked, but a few changes were needed. For the upgrade to succeed, the web server must have permission to write to the the directory where WordPress is installed. By default, I disabled this, and only allow writes to certain folder. Simple (temporarily) giving every one write access solved that problem:

chmod -R o+w wordpress/

After that, the upgrade went fine. A few things were needed to make everything work. First, I do not run Apache as a web server, but lighttpd. This makes permalinks and uploaded files a bit difficult. I have the following lighttpd config to make all this work:

url.rewrite-once = (
"^/(.*)?/?files/$" => "index.php",
"^/(.*)?/?files/(.*)" => "wp-includes/ms-files.php?file=$2",
"^/(wp-.*)$" => "$1",
"^/([_0-9a-zA-Z-]+/)?(wp-.*)" => "$2",
"^/([_0-9a-zA-Z-]+/)?(.*\.php)$" => "$2",
"(\?.*)$" => "index.php$1",
"." => "index.php"
)

And a few settings had to be added to the wp-config.php file. The following must be added:

define('MULTISITE', true);
define('SUBDOMAIN_INSTALL', true);

The first setting tells WordPress that I run a “multisite”, what used to be the “MU”. The second option tells WordPress that each blog has its own subdomain, as opposed to its own sub directory. Without this last line, permalinks do no work, and all links are redirected to the main site (with no subdomain).

Other that that, the upgrade went pretty fine. Actually, I’m quite impressed with how easy the upgrade of WordPress.