Installation worked fine, but the only problem I have is the server is quite loud. Plugging in the second PSU dropped the noise considerably, but I would like it to be quieter. Googling around, I found a few suggestions to upgrade the BIOS and ESM firmware, upgrading the BIOS was simple – download the BIOS .bin file from Dell, chmod +x and run, but the ESM upgrade isn’t as simple.

I attempted downloading the ESM file from Dell , and setting the execute permission on the file, it indicated some dependencies were missing:

./spsetup.sh: Cannot find utilities on the system to execute package.
Make sure the following utilities are in the path:
sed stty cut fmt stat look lockfile tail rm mkdir mktemp chmod ls basename dirname sleep

After satisfying the dependencies ( I had to install app-arch/rpm to satisfy rpm, and mail-filter/procmail to satisfy lockfile ), I re-ran the ESM script, and received this error:

line 123: source: buildVer.sh: file not found

Apparently the reason for this error is because the script from Dell doesn’t work with bash 4 ( in bash and earlier the ‘source’ command looks in the same path as the running script, in bash 4 and later it doesn’t ).  I did try to modify the scripts and fix the bug ( ie replacing source buildVer.sh with source ./buildVer.sh ), which did fix that error, but just raised more.

In the end, I simply downloaded the CentOS-based Dell OSMA live cd. I didn’t have a screen attached to the server, however luckily it runs SSH on boot – the only problem being I didn’t have the password to the live cd. In the end, I pressed ctrl+alt+f1 , then blindly typed:

passwd
testpass
testpass

Which reset the root password, and allowed me to log in via ssh to the server. I then ran:

wget http://downloads.dell.com/esm/PE1750-ESM-LX-A37.bin
chmod +x PE1750-ESM-LX-A37.bin
./PE1750-ESM-LX-A37.bin

After a few minutes the firmware upgrade was successfully installed:

Collecting inventory...
......................................................................................................................
Running validation...

ESM

The version of this Update Package is the same as the currently installed version.
Software application name: Baseboard Management Controller
Package version: 1.84
Installed version: 1.84

The version of this Update Package is the same as the currently installed version.
Software application name: Primary System Backplane
Package version: 1.01
Installed version: 1.01

The version of this Update Package is the same as the currently installed version.
Software application name: Sensor Data Records
Package version: 0.33
Installed version: 0.33

Continue? Y/N:y
Y entered; update was forced by user
Executing update...
WARNING: DO NOT STOP THIS PROCESS OR INSTALL OTHER DELL PRODUCTS WHILE UPDATE IS IN PROGRESS.
THESE ACTIONS MAY CAUSE YOUR SYSTEM TO BECOME UNSTABLE!
..........................................................................................................................................................................................................................................................................................................................................................................................................................................................................................................
The ESM firmware update completed successfully.
Would you like to reboot your system now?
Continue? Y/N:y

After rebooting, the new firmware was installed.

libtool: install: /usr/bin/install -c .libs/libprotocol-cli.soT /var/tmp/portage/media-sound/pulseaudio-2.0/image//usr/lib64/pulse-2.0/modules/libprotocol-cli.so
libtool: install: /usr/bin/install -c .libs/libprotocol-cli.lai /var/tmp/portage/media-sound/pulseaudio-2.0/image//usr/lib64/pulse-2.0/modules/libprotocol-cli.la
libtool: install: warning: relinking `libprotocol-simple.la'
libtool: install: (cd /var/tmp/portage/media-sound/pulseaudio-2.0/work/pulseaudio-2.0/src; /bin/sh /var/tmp/portage/media-sound/pulseaudio-2.0/work/pulseaudio-2.0/libtool  --silent --tag CC --mode=relink x86_64-pc-linux-gnu-gcc -std=gnu99 -I../src -I../src/modules -I../src/modules -pthread -DPA_ALSA_PATHS_DIR=\"/usr/share/pulseaudio/alsa-mixer/paths\" -DPA_ALSA_PROFILE_SETS_DIR=\"/usr/share/pulseaudio/alsa-mixer/profile-sets\" -march=core2 -msse4.1 -O2 -pipe -Wall -W -Wextra -Wno-long-long -Wvla -Wno-overlength-strings -Wunsafe-loop-optimizations -Wundef -Wformat=2 -Wlogical-op -Wsign-compare -Wformat-security -Wmissing-include-dirs -Wformat-nonliteral -Wpointer-arith -Winit-self -Wdeclaration-after-statement -Wfloat-equal -Wmissing-prototypes -Wredundant-decls -Wmissing-declarations -Wmissing-noreturn -Wshadow -Wendif-labels -Wcast-align -Wstrict-aliasing -Wwrite-strings -Wno-unused-parameter -ffast-math -Wp,-D_FORTIFY_SOURCE=2 -fno-common -fdiagnostics-show-option -Wl,-z,nodelete -avoid-version -Wl,-O1 -Wl,--as-needed -Wl,--no-as-needed -o libprotocol-simple.la -rpath /usr/lib64/pulse-2.0/modules protocol-simple.lo libpulsecore-2.0.la libpulsecommon-2.0.la libpulse.la -lgdbm -lcap -lrt -ldl -lm -inst-prefix-dir /var/tmp/portage/media-sound/pulseaudio-2.0/image/)
/var/tmp/portage/media-sound/pulseaudio-2.0/work/pulseaudio-2.0/src/.libs/libpulsecore-2.0.so: file not recognized: File truncated
collect2: ld returned 1 exit status
libtool: install: error: relink `libprotocol-simple.la' with the above command before installing it
make[4]: *** [install-modlibexecLTLIBRARIES] Error 1

As far as I can tell, the problem seems to be that ( on some machines, my other Gentoo machine installed the package without issue ) multiple threads are trying to access the same files at the same time and erroring. To work around this , I simply installed the package using one thread:

MAKEOPTS="-j1" emerge  media-sound/pulseaudio

The main reason to want to print to Google Cloud Print is for future compatibility with printers within Linux – it means that any ‘Cloud Ready Printer’ can be printed to without having to install possibly closed-source, or non-existent printer drivers.

It also allows printing directly to Google Docs, so you can easily print documents from work straight into your Google Docs account, making archiving documents simple, and easily accessible.

With this in mind, I was looking for a simple CUPS driver, which would allow printing via the normal printing functionality of any application, however this didn’t seem to exist… so I decided to write a CUPS backend and driver to support it.

The github project is available here , and I have produced packages for Gentoo ( Sabayon etc ), Debian ( Ubuntu, Mint etc ) , RedHat ( Fedora, Centos, SuSe etc ) and Arch Linux, with instructions here.

/usr/include/pango-1.0/pango/pango-script.h:132: error: expected declaration specifiers or '...' before 'G_CONST_RETURN'
/usr/include/pango-1.0/pango/pango-script.h:133: error: expected declaration specifiers or '...' before 'G_CONST_RETURN'
In file included from /usr/include/pango-1.0/pango/pango-script.h:138,
                 from /usr/include/pango-1.0/pango/pango-gravity.h:98,
                 from /usr/include/pango-1.0/pango/pango-types.h:91,
                 from /usr/include/pango-1.0/pango/pango-font.h:26,
                 from /usr/include/pango-1.0/pango/pango-attributes.h:25,
                 from /usr/include/pango-1.0/pango/pango.h:25,
                 from /usr/include/gtk-2.0/gdk/gdktypes.h:37,
                 from /usr/include/gtk-2.0/gdk/gdkscreen.h:32,
                 from /usr/include/gtk-2.0/gdk/gdkapplaunchcontext.h:31,
                 from /usr/include/gtk-2.0/gdk/gdk.h:32,
                 from /usr/include/gtk-2.0/gtk/gtk.h:32,
                 from avahi-ui.c:30:

After doing some research, the problem seems to be that I have recently upgraded to version 2.30.0 of dev-libs/glib, which has removed G_CONST_RETURN . I believe packages in the future will remove references to G_CONST_RETURN , but for now, the best solution is to mask ( or remove from keywords ):

=dev-libs/glib-2.30.0

and reinstall the current stable version:

=dev-libs/glib-2.28.8

.

Preparing the Virtual Machine

The main special requirement for the VirtualBox based VM is that it needs to be configured to boot from a Xen-based kernel. Obviously VirtualBox can’t boot Xen-dependant kernels, so I usually have two similarly configured kernels, one with Xen support, one without.

Compiling a Linux kernel with Xen support ( at least on Gentoo ) results in a kernel image named ‘vmlinuz’ whereas the normal kernel without Xen support creates a kernel ( assuming compressed with bzip ) called ‘bzImage’. I have a Grub config file which tries the Xen-based kernel , then falls back to the normal one if this fails. The only disadvantage to this is I have to compile a kernel twice, once with Xen support, once without, but it allows me to test a kernel with my own configuration before I upload it to the cloud:

default 0
timeout 1
fallback 1

title Xen
root (hd0,0)
kernel /boot/vmlinuz spinlock=tickless root=/dev/sda1

title Local
root (hd0,0)
kernel /boot/bzImage spinlock=tickless root=/dev/sda1

Next, remove all data which you don’t want to upload yourself ( all my sites I am hosting on the image are stored in SVN, which I will just ‘svn co’ when the instance is running ), then clean the filesystem (  by filling the empty space with zeros ) to reduce the data we have to upload:

cat /dev/zero > /tmp/zerofill
sleep 1
sync
rm /tmp/zerofill
sleep 1
sync

Power off the VM, and we can now create an image we can create an AMI from.

Creating the Image

Next, delete all the VirtualBox snapshots for the VM, so the changes get merged into the ‘root’ image – if you do not do this then you get a version of your image before snapshots have happened ( I found this out the hard way when the VM booted with software running that I had long removed ).
Convert the virtualbox VDI to a raw image ( the VDI file is found in ~/.VirtualBox/Machines/machinename/ ):

VBoxManage internalcommands converttoraw vboximage.vdi ec2.img

Compress the image, this reduced my image down from 10GB to ~400MB:

tar cjf image.tar.bz2 ec2.img

Delete the uncompressed image:

rm ec2.img

Turning the Image into an AMI

Start up a new Amazon EC2 instance ( you can use any standard EC2 Linux VM for this ), and upload the image using scp (or another method):

scp image.tar.bz2 user@imagingserver:

Through the AWS control panel, create a new EBS volume ( ideally the same size as the VirtualBox VM ) and attach it to the instance. Make a note of the volume device name ( in my case /dev/sdi ), and overwrite the EBS volume with the image we have just uploaded:

tar xf image.tar.bz2 -O | dd of=/dev/sdi bs=10M

The EC2 volume now has our VM on it. You may notice that although the data has completed being written to the disk, there is no entries in /dev for the partitions. We need to tell Linux to update it’s partition listing, simply run fdisk against the volume, print the partition table, then write the ( unchanged )  layout:

# fdisk /dev/sdi

Command (m for help): p

Disk /dev/sdi: 10.7 GB, 10737418240 bytes
255 heads, 63 sectors/track, 1305 cylinders, total 20971520 sectors
Units = sectors of 1 * 512 = 512 bytes
Sector size (logical/physical): 512 bytes / 512 bytes
I/O size (minimum/optimal): 512 bytes / 512 bytes
Disk identifier: 0xeb52e322

   Device Boot      Start         End      Blocks   Id  System
/dev/sdi1              63    20964824    10482381   83  Linux

Command (m for help): w
The partition table has been altered!

Calling ioctl() to re-read partition table.
Syncing disks.

/dev/sdi1 ( in this case ) now exists. Mount the volume to check that it looks sane, then unmount it:

mkdir /mnt/newimage
mount /dev/sdi1 /mnt/newimage
ls /mnt/newimage
...
umount /mnt/newimage

Through the AWS control panel, detach the volume, take a snapshot and make a note of the snapshot id. You can delete the volume once the snapshot is complete. Also find the correct snapshot id for your instance from this guide then register the image, replacing $SNAPSHOTID, $KERNELID, name and description with your values:

ec2-register -a x86_64 -n "Name" -d "Description" --root-device-name /dev/sda1 -b /dev/sda=$SNAPSHOTID:10:true --kernel $KERNELID

You should now be able to start the new instance and have it boot your own customized Linux EC2 AMI.