The following will convert to PAL widescreen format.

mencoder -oac lavc -ovc lavc -of mpeg -mpegopts format=dvd -vf scale=720:576,harddup -srate 48000 -af lavcresample=48000 -lavcopts vcodec=mpeg2video:vrc_buf_size=1835:vrc_maxrate=9800:vbitrate=5000:keyint=15:aspect=16/9:acodec=ac3:abitrate=192 -ofps 25 -o "OUTPUT.mpg" "INPUT.avi"

The pulses spec is very similar to that of the hero, but with slightly less memory, leaving just 60mb left to install new apps into. For reasons best known to google, android apps cannot be installed onto the SD card which is a real shame not least for the apps market in general.

Please note that rooting a phone will not, by itself, allow you to install apps onto the SD card. For that you also need to modify the ROM, or replace it with a custom ROM.

BIG FAT WARNING
Rooting your phone will almost certainly invalidate your warranty.
It is also possible that you could brick your phone.
The instructions below are simply a blog of what I did to my phone. There are no guarantees that they will work on your phone. So if you follow these instructions and bad things happen to your phone, don’t blame me!
Remember, the risk of making your phone completely useless is yours not mine.
END OF BIG FAT WARNING

Getting root access on the phone is fairly simple.

First download superboot and Amon RA from the modaco website.

Unzip the two files into separate folders and chmod the files install-superboot-linux.sh and install-recovery-linux.sh to make them executable (e.g. chmod u+x filename).

Switch the phone off (”power off”)

Hold Volume Down and the red button and switch the phone on.

This should bring you to the USB FastBoot screen. Now attach the USB cable to the phone and PC.

As root run install-superboot-linux.sh (e.g. in ubuntu cd to the folder containing the superboot files and type sudo ./install-superboot-linux.sh)

This is enough to give you root access. However, if you also want the ability to make backups of your phone and/or install custom roms then you can also install the recovery image:

As root run install-recovery-linux.sh (e.g. in ubuntu cd to the folder containing the superboot files and type sudo ./install-recovery-linux.sh)

Once you get the successful message you can restart the phone. I waited a couple of mins, “just in case”. The only way I could find to get out of the fastboot screen was to remove the battery.

And that’s about it.

To test that you have root access you need to install a ssh client, such as ConnectBot and shell onto localhost. When you do an su to gain root access, a pop-up window should ask you if you want to allow root access or not.

If you’ve also installed the recover image then you use the quickboot icon that should now be in your apps list. This will re-boot your phone into the recovery menu where you can backup and restore images as well as a few other options.

I tried everything, google didn’t throw up anything useful, I installed later HP drivers but noting fixed it.

After a lot of head scratching ad experimenting I did notice something odd. The USB device as owned by a user I did not have permissions for. I wasn’t expecting this to be the cause of the problem because if it was due to permissions then surely the printer would not print at all?!?

I was wrong, and adding myself to the group that owned the USB device has fixed it. As this seemed quite off the wall I thought I’d share…

So, first, see where the printer is connected:

lsusb
Bus 001 Device 003: ID 0dda:2027 Integrated Circuit Solution, Inc. USB 2.0 Card Reader
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Bus 002 Device 003: ID 03f0:7d04 Hewlett-Packard Deskjet F2100 Printer series
Bus 002 Device 001: ID 1d6b:0001 Linux Foundation 1.1 root hub

So its bus 002, device 003.

Next lets have a look at that device:

ls -l /dev/bus/usb/002/003
crw-rw----+ 1 lp lp 189, 130 2009-08-30 17:25 /dev/bus/usb/002/003

So the group is lp
Next add the group lp to any users that need access to the printer. Remember to user the -a switch to append to the existing group list.

usermod -aG lp userid

You’ll then need to log off and back on for the permissions to take effect.

There are several reasons why you might want to go with PV instead of HVM. The main two that spring to mind are PV’s offer better performance/lower overhead and PV DOMU’s allow PCI passthrough. Although apparently XEN 3.4 can now do PCI passthrough with HVM, as long as you have an Intel chip with vt-d.

This article will start off where my previous “Installing a XEN hvm DOMU” left off…

The description below uses Ubuntu 9.04. If your using a different distro your mileage may vary.

Most modern kernels will already support XEN PV, but without PCI passthrough. If you don’t need to pass any PCI devices directly to the DOMU then you can skip this next bit…

To install a full xen compatible kernel, taken from Debian:
With the DOMU booted as a HVM, add the following lines to the end of /etc/apt/sources.list

# Added for Debian xen kernel
deb http://ftp.debian.org/debian/ lenny main
deb-src http://ftp.debian.org/debian/ lenny main
deb http://ftp.debian.org/debian/ lenny-proposed-updates main

Now start synaptic from the system/administration menu, and click on the reload button to refresh the package lists. Ignore the warning about the new Debian repositories not being verified.
Now hit search and enter linux-image-2.6.26-2-xen and click to install it (it will also install the modules automatically).

Now we need to edit the boot menu, to add a disk option so that pvgrub can find the disk. If you’ve installed the XEN specific kernel as above then we’ll also add an entry for that too.
Edit /boot/grub/menu.lst
To convert the standard kernel copy the code block for the first boot option and then add the root (hd0,0) line (dont just copy the whole lot below, as your uuids will differ)

title           Ubuntu 9.04, kernel 2.6.28-11-generic-PV
uuid            265b80ca-0896-48a7-913a-6f5df64776bc
root (hd0,0)
kernel          /boot/vmlinuz-2.6.28-11-generic root=UUID=265b80ca-0896-48a7-913a-6f5df64776bc ro quiet splash
initrd          /boot/initrd.img-2.6.28-11-generic
quiet

And for the Debian XEN kernel:

title           Ubuntu 9.04, kernel 2.6.26-2-xen
uuid            265b80ca-0896-48a7-913a-6f5df64776bc
root (hd0,0)
kernel          /boot/vmlinuz-2.6.26-2-xen-amd64 root=UUID=265b80ca-0896-48a7-913a-6f5df64776bc ro quiet splash
initrd          /boot/initrd.img-2.6.26-2-xen-amd64
quiet

Note that the above xen kernel and initrd are for the 64bit version, use 2.6.26-2-686 for 32bit.

While you at it you might want to install openssh-server so that you can shell onto the DOMU later.
You may also consider going with a fixed IP address so that you can find your DOMU when you want to shell onto it!
edit /etc/network/interfaces

# The primary network interface
auto eth0
iface eth0 inet static
address 192.168.1.xxx
netmask 255.255.255.0
gateway 192.168.1.1

Now we’re ready to change the config file on the DOM0, so shut down the DOMU.

Edit you XEN DOMU config file and replace:

kernel = "/usr/lib/xen/boot/hvmloader"
builder='hvm' 

with:

kernel = "/usr/lib/xen/boot/pv-grub-x86_64.gz"
extra = "(hd0,0)/boot/grub/menu.lst"

Restart your DOMU and it should boot into a PV kernel. Now you can do neat things like PCI passthrough! (I’ll knock up another blog for that…)

If you’re doing this from your DOM0 then these flags may not actually show up. Instead type xm info and look for ‘hvm’ on the virt_caps line.

For my hvm install, i’ll be installing Ubuntu 9.04 Desktop Linux.
I have copied the live CD ISO onto my XEN DOM0 and will be installing directly from the iso rather than burning the CD. I have also created a 10GB LVM logical volume to act as the disk for my new DOMU.

The following config file is used to boot the live cd (iso image). It lives in /etc/xen and as this is to become a myth frontend i’ve rather imaginatively called it mythfronted!
/etc/xen/mythfrontend:

kernel = "/usr/lib/xen/boot/hvmloader"
builder='hvm'
memory = 512
name = "mythfrontend"
vif = [ 'type=ioemu, bridge=eth0' ]
disk = ['file:/xenimages/ISO/ubuntu-9.04-desktop-i386.iso,hda:cdrom,r', 'phy:/dev/mapper/datavg-mythfrontendlv,sda,w', ]
boot="d"

sdl=0
vnc=1
vnclisten="0.0.0.0"
vncpasswd='password'
stdvga=0
serial='pty'
usbdevice='tablet'

I find that setting usbdevice to tablet rather than mouse gives better results with a mouse than setting it to mouse.

Once you have your config file created and matching your system (i.e. pointing to the cd or iso, and file of lvm for hard disk) then we’re good to boot it:
xm create mythfrontend

If all went well then we should see it running in xm list

Now we need to connect to it’s display with vnc.
If this is the first DOMU to use vmc as a framebuffer then you should be able to run vnc to get access to the display. In the config above I have defined a password to be entered.

If you need to specify the port, then typing netstat -tap should let you see which port (probably 5900 ish).

Once you have connected to via VNC you will then be able to run the installer as usual. This should work for installing Windows as well as Linux.

After the install has completed, shutdown the new DOMU, because we need to edit the config file to remove the cd iso image and allow it to boot from it’s hard disk.

This basically means removing the cd-rom/iso section in the disk= parameter, change the device name for the hard disk from sda to xvda and removing boot=”d” completely. This should leave our config looking something like this:

kernel = "/usr/lib/xen/boot/hvmloader"
builder='hvm'
memory = 512
name = "mythfrontend"
vif = [ 'type=ioemu, bridge=eth0' ]
disk = [ 'phy:/dev/mapper/datavg-mythfrontendlv,xvda,w', ]

sdl=0
vnc=1
vnclisten="0.0.0.0"
vncpasswd='password'
stdvga=0
serial='pty'
usbdevice='tablet'

Now just start the DOMU with xm create mythfrontend
And that’s it!

There are a couple of toolsets for managing raid on Linux, raidtools and mdadm. This guide will use mdadm because imho it has better commands and features for monitoring.

Right, first you’ll need a couple of disk partitions of about the same size. These should be on separate disks or you’ll be defeating the point of raid mirroring

Raid disks appear under /dev as md0, md1 etc.
A quick way to check the status of your raid devices is to type cat /proc/mdstat

On my system this shows:
md1 : active raid1 sda2[0] sdb2[1]
96320 blocks [2/2] [UU]

md0 : active raid1 sda1[0] sdb1[1]
29294400 blocks [2/2] [UU]

Because on my system md0 and md1 are already in use, I will create this new raid as md2.

So lets assume that you have 2 partitions; /dev/sda3 and /dev/sdb3. The following command will create a raid device as /dev/md2.
mdadm --create --verbose /dev/md2 --level=mirror --raid-devices=2 /dev/sda3 /dev/sdb3

If all went well you can confirm the size/details of your new raid device:
mdadm --detail /dev/md2
/dev/md2:
Version : 00.90
Creation Time : Wed Apr 22 21:34:44 2009
Raid Level : raid1
Array Size : 458993024 (437.73 GiB 470.01 GB)
Used Dev Size : 458993024 (437.73 GiB 470.01 GB)
Raid Devices : 2
Total Devices : 2
Preferred Minor : 2
Persistence : Superblock is persistent

Update Time : Wed Apr 22 21:34:44 2009
State : clean
Active Devices : 2
Working Devices : 2
Failed Devices : 0
Spare Devices : 0

UUID : e893056a:5de3d066:4bca1532:59cc93a2 (local to host xenmaster)
Events : 0.1

Number Major Minor RaidDevice State
0 8 3 0 active sync /dev/sda3
1 8 19 1 active sync /dev/sdb3

And you cat check that it is running:
cat /proc/mdstat
md2 : active (auto-read-only) raid1 sdb3[1] sda3[0]
458993024 blocks [2/2] [UU]
resync=PENDING

md1 : active raid1 sda2[0] sdb2[1]
96320 blocks [2/2] [UU]

md0 : active raid1 sda1[0] sdb1[1]
29294400 blocks [2/2] [UU]

In my case you can see that the raid pair is not synced yet. After about 10 minutes or so re-issuing the command shows that the raid pair are now syncing (alternatively you can try running the raid to kick start the sync by issuing mdadm --run /dev/md2):
cat /proc/mdstat
md2 : active raid1 sdb3[1] sda3[0]
458993024 blocks [2/2] [UU]
[=>...................] resync = 7.6% (35247744/458993024) finish=73.2min speed=96456K/sec

and mdadm -detail /dev/md2
/dev/md2:
Version : 00.90
Creation Time : Wed Apr 22 21:34:44 2009
Raid Level : raid1
Array Size : 458993024 (437.73 GiB 470.01 GB)
Used Dev Size : 458993024 (437.73 GiB 470.01 GB)
Raid Devices : 2
Total Devices : 2
Preferred Minor : 2
Persistence : Superblock is persistent

Update Time : Wed Apr 22 22:10:29 2009
State : active, resyncing
Active Devices : 2
Working Devices : 2
Failed Devices : 0
Spare Devices : 0

Rebuild Status : 9% complete

UUID : e893056a:5de3d066:4bca1532:59cc93a2 (local to host xenmaster)
Events : 0.3

Number Major Minor RaidDevice State
0 8 3 0 active sync /dev/sda3
1 8 19 1 active sync /dev/sdb3

At this point is should be possible to mount and use the raid device and even format it while it is being rebuilt. However, I want to put LVM on it so I’ll wait until the sync is complete…

Please note that the new raid device will most likely sow in /proc/mdstat as active (auto-read-only) until you either mount it or create an LVM volume on it (i.e. use it).

And that’s it really. You use /dev/md2 as you would any disk partition such as /dev/sda1 to format, mount or use as a PV for LVM.

So, open a file in vi as usual, hit escape and type:
:%!xxd to switch into hex mode

And when your done hit escape again and type:
:%!xxd -r to exit from hex mode.

For this example I’ll be installing CentOS5, but this should work for any red-hat based distro (please note there is a bug in fedora10 that stops it booting under xen). This example also uses the paravirtual kernel so it will work even if your CPU does not support AMD-V or intel-VT.

Right, down to business. The first thing we need to do is create a file to user as the hard disk for the DOMU. There are other options for providing hard disks to a DOMU, and I’ll cover some of them in a later guide but for this install I’ll be using a file.

The command below will create an 8GB file that will be used as an 8GB drive. The whole file will be written to disk in one go so may take a short while to complete.
dd if=/dev/zero of=/xenimages/test01/disk1.img oflag=direct bs=1M count=8192

Alternatively, you can use the command below to create the same size file as a sparse file. What this does is create the file, but only take up disk space as the file is used. In this case the file will only really take about 1mb of disk initially and grow as you use it.
dd if=/dev/zero of=/xenimages/test01/disk1.img oflag=direct bs=1M seek=8191 count=1
There are pros and cons of using sparse files. On one hand they only take as much disk as is actually used, on the other hand the file can become fragmented and you could run out of real disk if you overcommit space.

Next up we’ll mount the install CD and export it over nfs so that xen can use it as a network install.
mkdir /tmp/centos52
mount /dev/hda /tmp/centos52 -o loop,ro
Just to check the mount went OK: ls /tmp/centos52 should show the files.
Now run the export:
exportfs *:/tmp/centos5

Now we’ll create the xen config file for our new instance. The default location for xen config files is /var/xen so that’s where ours will go.
I’m going to call my VM test01, so I’ll create a file /var/xen/test01 that contains the following initial configuration:

kernel = "/tmp/centos52/images/xen/vmlinuz"
ramdisk = "/tmp/centos52/images/xen/initrd.img"
name = "test01"
memory = "256"
## disk = [ 'tap:aio:/xenimages/test01/disk1.img,xvda,w', ]
disk = [ 'file:/xenimages/test01/disk1.img,xvda,w', ]
vif = [ 'bridge=eth0', ]
vcpus=1
on_reboot = "destroy"
on_crash = "destroy"

Note that if you are installing from a different machine from your xen machine the you will need to nfs mount the install disk in order for the above config to kick off the installer. e.g.
mount IP address:/tmp/centos52 /tmp/centos52

So, lets boot the new instance and start the installer.
xm create test01
After a moment or two the console should return with something like “Started domain test01″.

Now lets connect to the console and proceed with the install:
xm console test01

Or if you prefer the previous two commands can be combined into one: xm create test01 -c.

From here on you should work through the standard text mode installer.
The points to note are:

• For installation image select “NFS image”. Then in the later nfs panel enter your PC’s IP address for the servername and /tmp/centos52 (or wherever you mounted the cd) as the directory.
• I also specified a manual IP address for my VM. I selected my routers IP for the gateway and dns server, so that I can access the internet from the VM later.
• The hard drive is named xvda, as specified in the config file. This will need to be partitioned and formatted by the installer.

The rest of the install is fairly straight forward. If in doubt just go with the defaults, although it’s probably a good idea to set a manual IP address in your subnet range so that you can easily ssh onto the VM.
Note that to release the console from your VM hold down Ctlr and press the ] key.

When the install is complete the new domain will need to be shut down (you’ll be prompted to ‘restart’ by the installer, this will in fact shut down the VM because we set the on_reboot option to destroy), and then the xen config file must be modified to allow the new VM to boot.
So, edit the config file that we created earlier and comment out the kernel and ramdisk lines. You should also change the on_crash and on_reboot actions to restart.
So the edited config file now looks like this:

## kernel = "/tmp/centos52/images/xen/vmlinuz"
## ramdisk = "/tmp/centos52/images/xen/initrd.img"
name = "test01"
memory = "256"
## disk = [ 'tap:aio:/xenimages/test01/disk1.img,xvda,w', ]
disk = [ 'file:/xenimages/test01/disk1.img,xvda,w', ]
vif = [ 'bridge=eth0', ]
vcpus=1
on_reboot = "restart"
on_crash = "restart"

Finally we can boot the new VM instance:
xm create test01 -c
and log in as root. You should also be able to ssh onto it from your network.

And that’s about it!
One last note. If you want the VM to start and stop with your xen server, just move the config file into the auto sub folder (or create a symbolic link to it).

First create some disk partitions. In this example I’ve got two identical unformatted partitions on a couple of hard drives. These appear in /dev as sda4 and sdb4. Please note your partition number will most likely be different.
Also note that it’s easy to break your system with some of these commands. You have been warned, so don’t blame me if you wipe your system out!

First make the partitions available to LVM:
pvcreate /dev/sda4
Physical volume “/dev/sda4″ successfully created

pvcreate /dev/sdb4
Physical volume “/dev/sdb4″ successfully created

Next create a volume group:
vgcreate xenimagesvg /dev/sda4 /dev/sdb4
Volume group “xenimagesvg” successfully created

We can check the size etc of the new volume group with vgdisplay:

vgdisplay xenimagesvg
— Volume group —
VG Name xenimagesvg
System ID
Format lvm2
Metadata Areas 2
Metadata Sequence No 1
VG Access read/write
VG Status resizable
MAX LV 0
Cur LV 0
Open LV 0
Max PV 0
Cur PV 2
Act PV 2
VG Size 289.52 GB
PE Size 4.00 MB
Total PE 74116
Alloc PE / Size 0 / 0
Free PE / Size 74116 / 289.52 GB
VG UUID m408F0-77d6-WXwU-ykD9-5OCB-pIkG-cSbIDP

Next, we need to create a logical volume in our new volume group:
lvcreate -n xenimageslv -L 250G xenimagesvg

The above will create a logical volume called xenimageslv in volume group xenimagesvg

Now we need to format the logical volume so that it can be used as a filesystem.
I’m going to format to ext3 using mke2fs with -j (for journalling, aka ext3):
mke2fs -j /dev/mapper/xenimagesvg-xenimageslv
mke2fs 1.41.3 (12-Oct-2008)
Filesystem label=
OS type: Linux
Block size=4096 (log=2)
Fragment size=4096 (log=2)
16384000 inodes, 65536000 blocks
3276800 blocks (5.00%) reserved for the super user
First data block=0
Maximum filesystem blocks=4294967296
2000 block groups
32768 blocks per group, 32768 fragments per group
8192 inodes per group
Superblock backups stored on blocks:
32768, 98304, 163840, 229376, 294912, 819200, 884736, 1605632, 2654208,
4096000, 7962624, 11239424, 20480000, 23887872

Writing inode tables: done
Creating journal (32768 blocks): done
Writing superblocks and filesystem accounting information: done

This filesystem will be automatically checked every 32 mounts or
180 days, whichever comes first. Use tune2fs -c or -i to override.

And finally we need to mount our new filesystem so that we can actually use it. Here I’ll add the entry into fstab so that it mounts on system startup.

Create a folder to mount the filesystem into:
mkdir xenimages

edit fstab and add the following line to mount our new lvm filesystem at system startup…
/dev/mapper/xenimagesvg-xenimageslv /xenimages ext3 errors=remount-ro 0 0

Now run mount-a to re-run fstab mounts and mount the new filesystem

Check it’s mounted with df -h:
df -h
Filesystem Size Used Avail Use% Mounted on
/dev/mapper/rootvg-rootlv
21G 4.5G 15G 24% /
tmpfs 1.9G 0 1.9G 0% /lib/init/rw
udev 10M 124K 9.9M 2% /dev
tmpfs 1.9G 0 1.9G 0% /dev/shm
/dev/md1 92M 51M 36M 59% /boot
/dev/mapper/xenimagesvg-xenimageslv
247G 188M 234G 1% /xenimages

First install Debian 5.0 (Lenny). This should also work on 4 (Etch) too.

Everything is done on the command line as root.

To build Xen from source you’ll need as fair number of dependencies. The easiest way to install them is by using the apt-get install command as below:
apt-get install bcc bin86 gawk bridge-utils iproute libcurl3 libcurl4-openssl-dev bzip2 module-init-tools transfig tgif texinfo pciutils-dev mercurial build-essential make gcc libc6-dev zlib1g-dev python python-dev python-twisted libncurses5-dev patch libvncserver-dev libsdl-dev libjpeg62-dev

If you installed the 64bit version of Debian then you’ll also need gcc-multilib for the compile to work:
apt-get install gcc-multilib

Next create a temporary folder and download the Xen source code:
mkdir xentemp
cd xentemp
wget http://bits.xensource.com/oss-xen/release/3.3.1/xen-3.3.1.tar.gz

Now extract the soucecode from the downloaded archive:
tar -xzf xen-3.3.1.tar.gz
cd xen-3.3.1

Right, now on with the compile (this will take a while…):
make world
Note, if you want USB and PCI passthrough to answer Y when prompted.

Assuming that the above compile went ok:
make dist

And now install the newly compiled kernel and tools into the system:
./install.sh

Ensure the xen deamon starts and stops with the rest of the system:
update-rc.d xend defaults 20 21
update-rc.d xendomains defaults 21 20

Create the module dependencies stuff:
depmod 2.6.18.8-xen

Update/create initramfs for the new kernel:
update-initramfs -c -k 2.6.18.8-xen

Add the new kernel to your grub boot menu:
update-grub

Reboot the system and hope that it works!
reboot

Now have a xen kernel:
uname-a
Should show a xen kernel at version 2.6.18

However on my gigabyte motherboard I was getting some boot time errors:
2.6.18 exception Emask 0×40 SAct 0×0 SErr 0×800 action 0×2

A quick google confirmed that this was due to the old kernel version, 2.6.18 and my motherboard.
So to fix the error I used synaptic to install latest xen kernel from lenny repositories…

uname -a
2.6.26-1-xen-amd64 #1 SMP Fri Mar 13 21:39:38 UTC 2009 x86_64 GNU/Linux
This resolved the error and still leaves me with xen 3.3.1

Type xm info to confirm xen version

And that’s it!