All 13 entries tagged Linux

Update a driver in an initrd file

Recently I found myself wanting to put SUSE Linux Enterprise Desktop 11 SP1 on to machine with a Sandybridge chipset. This was a problem as the e1000e driver in SLED 11 SP1 isn't new enough to support the network card in the machine. Having found an updated driver I still had the problem that I wanted to be able to do installations over the network with AutoYaST and PXE boot. That didn't work because the initrd file being used for PXE boot didn't have the new e1000e driver in. So the install failed almost immediately due to the absence of a network connection.

The solution is to make a new initrd file containing the new e1000e driver. It's far from obvious how to do this but I found the solution at http://www.sharms.org/blog/2007/11/howto-add-updated-e1000-driver-to-sled-10-sp1/ This post is basically just me duplicating the information because you can never have such information in too many places. Also I've expanded it a little bit to include instructions on how to do some bits that I had to work out. You can of course adapt the following for whatever module you might find the need to update.

First of all, make a new directory and unpack the current initrd in to it

$ mkdir -p updated_initrd/initrd_unpack
$ cd updated_initrd/initrd_unpack
$ gunzip -dc /path/to/initrd | cpio -idmuv

Now get the new version of the e1000e module. I found this in an rpm on Novell's website which I needed to download and unpack to get the driver out of it.

$ cd ..
$ wget http://drivers.suse.com/driver-process/pub/update/Intel/sle11sp1/common/i586/intel-e1000e-kmp-pae-1.2.20_2.6.32.12_0.7-1.i586.rpm 
$ mkdir rpmcontents
$ cd rpmcontents
$ rpm2cpio ../intel-e1000e-kmp-pae-1.2.20_2.6.32.12_0.7-1.i586.rpm | cpio -idv

Next copy the new driver over in to where you unpacked the initrd

$ cp lib/modules/2.6.32.12-0.7-pae/updates/e1000e.ko ../initrd_unpack/modules/
cp: overwrite `../initrd/modules/e1000e.ko'? y

Now you need to update files called modules.alias and modules.pcimap using information that you get from the depmod command. You can get the information to put in modules.alias with

$ /sbin/depmod -n $(pwd)/lib/modules/2.6.32.12-0.7-pae/updates/e1000e.ko | grep ^alias > /tmp/newaliases

Then I made a copy of the modules.alias file with the information for e1000e removed from it

$ grep  -v ' e1000e$' ../initrd_unpack/lib/modules/2.6.32.12-0.7-default/modules.alias > /tmp/modules.alias

Add the new information to that file

$ cat  /tmp/newaliases >>  /tmp/modules.alias

And then replace the original file

$ cp /tmp/modules.alias  ../initrd_unpack/lib/modules/2.6.32.12-0.7-default/modules.alias
cp: overwrite `../initrd_unpack/lib/modules/2.6.32.12-0.7-default/modules.alias'? y

The process is the same for the modules.pcimap file

$ /sbin/depmod -n $(pwd)/lib/modules/2.6.32.12-0.7-pae/updates/e1000e.ko | grep '^e1000e ' > /tmp/newpcimap
$ grep -v  '^e1000e ' ../initrd_unpack/lib/modules/2.6.32.12-0.7-default/modules.pcimap > /tmp/modules.pcimap
$ cat  /tmp/newpcimap >>  /tmp/modules.pcimap
$ cp /tmp/modules.pcimap  ../initrd_unpack/lib/modules/2.6.32.12-0.7-default/modules.pcimap
cp: overwrite `../initrd_unpack/lib/modules/2.6.32.12-0.7-default/modules.pcimap'? y

Finally, make the new initrd file

$ cd ../initrd_unpack
$ find . | cpio --quiet -o -H newc > ../initrd
$ cd ..
$ gzip -v9c initrd > initrd.gz
$ mv initrd.gz initrd
mv: overwrite `initrd'? y
$ file initrd
initrd: gzip compressed data, was "initrd", from Unix, last modified: Wed Jun 29 12:31:49 2011, max compression

Mike Willis : 29 Jun 2011 12:42 |  Tags: Autoyast E1000E Initrd Linux Suse |  Comments (0) |  Close comments |  Report a problem

Where am I?

Writing about web page http://go.warwick.ac.uk/vpn

If you are one of those people who might be able to tell where I was when I posted this by looking at logs, you'd think I was on campus because of the IP address. Except I'm not. I'm at home. Magic? No, it is of course merely sufficiently advanced technology in the form of a VPN.

The System Requirements for Linux machines for some reason single out two distributions, presumably those known to meet the requirements listed afterword. I'm using openSUSE 11.3 which isn't on the list but it seems to work fine. The only glitch I've seen is that when the client install finished it told me "If you have GTK 2.10.0 or later, look for the icon in the notification area:" and there was no such icon, even though a quick visit to whatismyip showed the connection had worked. Selecting the Cisco client from the Application Browser resulted in the icon appearing as expected though.

One very minor gripe I have is that the client installation process doesn't bother to tell you what it's installing or where it's installing it. A quick bit of detective work reveals it puts stuff in /opt/cisco (and a .desktop file in /usr/share/applications) and there's a script called vpn_uninstall.sh in there.

Mike Willis : 07 Oct 2010 20:54 |  Tags: Linux Vpn |  Comments (0) |  Close comments |  Report a problem

18 degrees celcius and rainy

Follow-up to 9 degrees celcius from Mike's blag

Looks like the new owners of Coventry Airport have found the switch that turns the weather data feed back on.

Mike Willis : 04 Aug 2010 17:17 |  Tags: Coventry Gnome Linux Weather |  Comments (0) |  Close comments |  Report a problem

Finding the path of a Firefox profile

The other day I found myself needing to be able to determine the path of a user's Firefox profile. It was one of those tasks that seemed very simple to start with but then got more complicated the more I thought about it. Some people have more than one Firefox profile. So it needs to be determined which one is the default, which requires working it out by looking at the user's profiles.ini file. profiles.ini may contain details of one or more profiles. If it contains details of more than one profile one of them will be marked as the default, but if there is only details of one profile it won't be marked as the default. If a profile is marked as default then the line which marks it as default isn't always in the same place in relation to the other information about the profile. The path to the profile that appears in profiles.ini might be relative to the location of profiles.ini, or it might not be. In the end I realised that rather than it being a case of writing a couple of lines in the script I was writing, it was a task best suited to being broken out in to a separate script which I can re-use in future.

Anyway, in the admittedly unlikely event that you've been looking for a way to find the path to a user's Firefox profile, here's a Script to find path of default or specified Firefox profile. It's written for Linux. It will probably work on other *nix systems (e.g. Mac OS X) by changing the value of $firefoxprofiledir and maybe making a few other tweaks.

Mike Willis : 05 Feb 2010 13:00 |  Tags: Firefox Linux Path Profiles |  Comments (0) |  Close comments |  Report a problem

9 degrees celcius

The weather indicator in the top right of my GNOME desktop has been saying 9 degrees celcius for the last few days:

Which is clearly wrong. I think I've just worked out why it's not updating. A common source of weather data is airports. GNOME gets it's weather information from airports. For Coventry it uses Coventry Airport. Coventry Airport has been closed due to financial difficulties. Various sites which would usually display information from it's weather data feed all say 'no data'. So looks like the closure of Coventry Airport extends to it's weather data feed. Later on I might look at making it use an alternate data source.

Mike Willis : 15 Dec 2009 10:37 |  Tags: Coventry Gnome Linux Weather |  Comments (0) |  Close comments |  Trackbacks (1) |  Report a problem

Generating Freedesktop.org spec compliant thumbnails

A lot of Linux software that needs to generate thumbnails of an image uses the freedesktop.org thumbnail specification. This is good as it means if one application has already made a thumbnail of an image then another application can make use of it rather than generating it's own. I recently found myself looking for a way to generate such thumbnails.

The impetus for this was gnome-appearance-properties. This is the application which allows you to do stuff like change your wallpaper. Sadly as the number of wallpapers available increases it's usability decreases to some extent. The reason for this is that the user interface is frozen until all the wallpaper thumbnails are displayed. This in itself isn't too bad, unless you have thousands of wallpapers, but if it's combined with a lack of pre-generated thumbnails the user interface is frozen until all the thumbnails have been generated. This is annoying because if there are few hundred wallpapers available thumbnail generation can take over thirty seconds even on a decent spec machine. Thirty seconds during which the user is left looking at an unresponsive interface. There is long standing bug report regarding this, that I can't currently locate, which makes the very sensible suggestion that the thumbnails should be loaded asynchronously. Hopefully at some point someone will implement that, but in the mean time I found myself wondering whether it was possible to script the generation of thumbnails in advance.

My first thought was ImageMagick and a bash script because I'm already familiar with those. As it turns out ImageMagick comes very, very close to being able to generate such thumbnails using the -thumbnail option. I say close, because whilst it inserts both the MTime and URI information required by the freedesktop.org spec, it generates the URI incorrectly by inserting one too many slashes at the start. It creates

$ convert /usr/share/pixmaps/backgrounds/cosmos/earthrise.jpg -thumbnail 128x foo.png
$ identify -verbose foo.png | grep Thumb::URI
 Thumb::URI: file:////usr/share/pixmaps/backgrounds/cosmos/earthrise.jpg

when it needs to be

 Thumb::URI: file:///usr/share/pixmaps/backgrounds/cosmos/earthrise.jpg

At time of writing this is actually fixed, but only in the svn version. If you have 6.5.7-8 or later then you should find it generates the URI properly. If you have an older version you can create the thumbnails like this:

#!/bin/bash
# makethumb - script to generate thumbnails to freedesktop.org spec
# *** Assumes GNU coreutils. ***
file=$1
saveto=~/.thumbnails/normal
tagfile=/tmp/$(basename $0)_tags
mkdir -p $saveto
thumbname=$(echo -n file://$file | md5sum| cut -d " " -f 1);
mtime=$(date +%s -r "$file")
echo "Thumb::URI={file://${file}}" >$tagfile
echo "Thumb::MTime={${mtime}}" >>$tagfile
convert -resize 128x -strip +profile "*"  $file  MIFF:- | cat $tagfile - | convert  MIFF:- "PNG:${saveto}/${thumbname}.png"
rm -f $tagfile

$ makethumb /usr/share/pixmaps/backgrounds/cosmos/earthrise.jpg

Generating thumbnails this way is quite slow though. Using

$ find  /usr/share/pixmaps/backgrounds/ -type f -exec ~/makethumb {} \;

332 thumbnails took around 1:15 in my tests, though obviously this will vary depending on the spec of the machine. I tried using a variant of the script which generated thumbnails for all the files in a given directory, so only invoking the script once instead of multiple times. There was no significant difference in speed between the two methods though.

So I started looking for some way to use GNOME's thumbnail generation capabilities. The only example I could find of doing this used Python GTK bindings and was incomplete. I've only ever cobbled together one python script before, (that was also to use GTK bindings), but I managed to put together this

#!/usr/bin/python
# makethumb.py - script to generate thumbnails using GTK bindings

import gnome.ui
import gnomevfs
import time
import sys
import os

file=sys.argv[1]

uri=gnomevfs.get_uri_from_local_path(file)
mime=gnomevfs.get_mime_type(file)
mtime=int(time.strftime("%s",time.localtime(os.path.getmtime(file))))
thumbFactory = gnome.ui.ThumbnailFactory(gnome.ui.THUMBNAIL_SIZE_NORMAL)
if thumbFactory.can_thumbnail(uri ,mime, 0):
 thumbnail=thumbFactory.generate_thumbnail(uri, mime)
 if thumbnail != None:
 thumbFactory.save_thumbnail(thumbnail, uri, mtime)  

Using that to generate thumbnails in the same manner shown above for the bash script was about ten seconds faster. However after some experimentation I put together this (updated 15/8/11 to include suggestions from comment 2):

#!/usr/bin/python
# makethumbs.py - generates thumbnails for all files in a directory

import gnome.ui
import gnomevfs
import time
import os

dir="/usr/share/pixmaps/backgrounds/"

thumbFactory = gnome.ui.ThumbnailFactory(gnome.ui.THUMBNAIL_SIZE_NORMAL)

for subdir, dirs, files in os.walk(dir):
 for file in files:
  path = os.path.join(subdir, file)
  uri = gnomevfs.get_uri_from_local_path(path)
  mime=gnomevfs.get_mime_type(subdir+"/"+file)
  mtime = int(os.path.getmtime(path))
  print uri 
  print mtime
  if thumbFactory.can_thumbnail(uri ,mime, 0):
      thumbnail=thumbFactory.generate_thumbnail(uri, mime)
      if thumbnail is not None:
          thumbFactory.save_thumbnail(thumbnail, uri, mtime) 

I found that generates 332 thumbnails in around 9 seconds. A massive difference to repeatedly invoking the makethumb.py script. I expect there are people who could provide a detailed explanation of why it's so much faster. I am not one of them.

It's also interesting to note that I've found this script generates thumbnails around three times faster than the gnome-appearance-properties creates them. Why that is I have no idea. The thumbs that result are not identical. The thumbnails generated by the Python script have the width and height of the original image embedded in them whilst the ones generated by gnome-appearance-properties do not. The ones generated by gnome-appearance-properties have a very lightly larger file size and the Channel Statistics embedded in the thumbnails are different too. However both sets of thumbnails say they were generated by GNOME::ThumbnailFactory.

Interesting as all this is, (to me anyway if it's not to you then why did you read this far?), it's all about generating thumbnails on a per-user basis. What if it was possible to have a system wide cache of per-generated thumbnails. E.g. you install a bunch of wallpapers and along with them you can install thumbnails that will be used rather than each user generating their own. The freedesktop.org thumbnail spec does cover this. So I tried creating such thumbnails. gnome-appearance-properties ignored them. When I say ignored them, I don't mean it looked at them and didn't use them, the output of strace indicates that it doesn't even look to see they exist. Which is a shame.

Mike Willis : 16 Nov 2009 12:44 |  Tags: Bash Freedesktop Gnome Gtk Imagemagick Linux Python |  Comments (3) |  Close comments |  Report a problem

zypper equivalent of yum —downloadonly

Looking at moving from yum to zypper I found myself unable to work out how to get zypper to download packages but not install them. Yum can do this with the downloadonly plugin:

yum -y update --downloadonly

According to this bug report, zypper should be able to do it but I couldn't find any explanation as to how. In the end I emailed the guy who marked that bug report as fixed and he was kind enough to reply and point me in the direction of the keep-packages option. This is a per-repo setting which means download packages are kept in cache. Knowing this a Google search took me here where it is mentioned along with the --dry-run option. So to get zypper to download updates but not install them, enable caching of packages on all repos with

zypper mr -k -all

and then use

zypper -l -y  update --dry-run

Mike Willis : 02 Feb 2009 12:28 |  Tags: Linux Opensuse Suse Yum Zypper |  Comments (0) |  Close comments |  Report a problem

Hotspot VPN vs Asus Eee PC

Writing about web page http://go.warwick.ac.uk/wireless

I've recently got my hands on an Asus Eee PC 901. I got the version which ships with Linux (Xandros heavily modified by Asus) on it since I'm that way inclined. I found that whilst it is possible to use the pre-loaded software to connect to the University's Hotspot VPN, doing so doesn't result in connection that is actually usable.

The reason for this turns out to be because the default behaviour of the included VPN client is to re-use the IP address that the Hotspot network has assigned to the machine's wireless connection for the VPN connection. The VPN server doesn't like that.

The solution is to tweak the configuration file for the VPN connection so that it uses the IP address assigned by the VPN server. Assuming there's only one VPN connection set up on the machine then the config file is /etc/ppp/peers/vpn1 and the option noipdefault needs to be added as an extra line at the end.

There's various ways to edit the file, arguable the fastest being to tap Ctrl-Alt-T which brings up an xterm window in which you can run

$ sudo kwrite /etc/ppp/peers/vpn1

After which the last few lines of the file should look like:

/home/user> tail -5 /etc/ppp/peers/vpn1
lock
noauth
nobsdcomp
nodeflate
noipdefault

Full connection guide with screenshots and such like can be found here.

Mike Willis : 20 Jan 2009 15:56 |  Tags: Eeepc Hotspot Linux Vpn |  Comments (0) |  Close comments |  Report a problem

Adding wallpapers in KDE 4, the metadata.desktop file and X–KDE–PluginInfo–Name attribute

Google bait-ish title as this is something I worked out through trial and error when I couldn't find any information about it.

Whilst poking around in KDE 4 I noticed that some wallpapers are supplied in multiple resolutions. E.g.

mike@continuity:~$ rpm -ql kdebase4-wallpapers | grep Fresh
/usr/share/wallpapers/Fresh_Morning
/usr/share/wallpapers/Fresh_Morning/contents
/usr/share/wallpapers/Fresh_Morning/contents/images
/usr/share/wallpapers/Fresh_Morning/contents/images/1024x768.jpg
/usr/share/wallpapers/Fresh_Morning/contents/images/1280x1024.jpg
/usr/share/wallpapers/Fresh_Morning/contents/images/1280x800.jpg
/usr/share/wallpapers/Fresh_Morning/contents/images/1440x900.jpg
/usr/share/wallpapers/Fresh_Morning/contents/images/1600x1200.jpg
/usr/share/wallpapers/Fresh_Morning/contents/images/1920x1200.jpg
/usr/share/wallpapers/Fresh_Morning/contents/screenshot.png
/usr/share/wallpapers/Fresh_Morning/metadata.desktop

Presumably KDE 4 picks the one that's most suitable for your screen resolution.

When I put my own multiple resolution wallpaper in to /usr/share/wallpapers I found that KDE 4 did not list it in the drop down list of available wallpapers. Eventually I worked out that it wasn't showing up because the value of the X-KDE-PluginInfo-Name attribute in the metadata.desktop file has to match the name of the directory the wallpaper is in. E.g.

mike@continuity:~$ grep X-KDE-PluginInfo-Name /usr/share/wallpapers/Fresh_Morning/metadata.desktop
X-KDE-PluginInfo-Name=Fresh_Morning

Once I made them match my wallpaper appeared in the list.

Mike Willis : 11 Jan 2009 23:13 |  Tags: Kde Kde4 Linux Wallpaper |  Comments (0) |  Close comments |  Report a problem

The joy of shell

Writing about web page http://ask.slashdot.org/askslashdot/08/11/05/2027234.shtml

There's a discussion going on Slashdot entitled "(Useful) Stupid Unix Tricks?".  (Clicking the 'Get more comments'  button at the bottom of the page a few times makes more of the discussion visible.) I love discussions like that because I nearly always pick up something useful.

A useful trick that occured to me this morning was to combine && with a kdialog yes/no prompt:

kdialog --yesno "are you sure?" && do_stuff

Of course stuff which is really useful on one Unix-like OS is sometimes useless on another. I work on Linux, but sometimes need to do something the multi user Solaris boxes such as mimosa or primrose etc and occcasionally get tripped up by differences. Though I've found changing my shell on Solaris to bash instead of the default tcsh and adding /usr/local/gnu/bin/ to the start of my $PATH helps!

Mike Willis : 06 Nov 2008 13:41 |  Tags: Bash Linux Shell Solaris Unix |  Comments (0) |  Close comments |  Report a problem