In documentation, man can find only "VMware Server supports 64-bit guest operating systems only on host machines with supported processors.". How helpful! After a bit of googling, it turns out that VT needs to be enabled and usually it is not enabled in BIOS (any reason for this?).

So let's reboot, go to BIOS, enable VT and it should work. Unfortunately not, after reboot, still same problem. I was almost given up at this point, but I decided to recheck BIOS, whether I really enabled the right thing. Yes I did, but I did not notice small note, that to apply this setting, I need to power off and on the computer. That was the trick! Now it finally works. I just wonder why it has to be so complicated...

I just set up Debian sid chroot on my computer and have to sign something inside this chroot (dpgk-buildpackage). Okay, I want it to use gpg-agent in my host system, that should not be hard. Looking at gpg man page, GPGAGENTINFO variable is used to forward information about agent socket, PID and protocol version, so I set this variable according to host system, but it still does not work, giving nothing saying error that agent is not working.

So let's debug this beast - strace reveals, that communication with agent works, but it replies "113 Server Resource Problem". Hmm, still not much useful information, but let's google for this problem. Fortunately Google reveals related Seahorse code, where man can find, that not set DISPLAY variable is causing this issue. Could not the error be more friendly, so that it tells me directly what is wrong?

There exists several howtos on the net, we can take the one on Sixxs wiki as a good starting point. Just follow the instructions and you should get it working right? Unfortunately not. Aiccu connects, IPv6 addresses are assigned, subnet is correctly distributed over network using radvd, but IPv6 connectivity does not work.

Going deeper into this issue, I found out that some packets go out, but nothing comes back. When comparing results with Aiccu set up on my Debian notebook, I noticed that packets from OpenWRT router are few bytes larger, but I didn't though it could be a reason. Unfortunately it was -- OpenWRT contains wrongly compiled Aiccu, which does not strip ethernet headers from outgoing packets and gateway then throws them out.

This is a well known bug, but unfortunately nobody fixed it for White Russian. Anyway I'm not going to reinstall whole system to Kamikaze just to make the thing work, so I compiled the Aiccu package on my own and now the tunnel works fine. If you are interested, you can get the package here.

As a first step I just wanted to make a backup of all things. Gammu can do it quite well and it's the tool I trust for this purpose:

gammu backup /tmp/phonebook.vcf
gammu backup /tmp/calendar.vcs

Now it's time to play with OpenSync. We will use setup guide and SyncML guide as a starting point. As I had in past problems with both sides - both phone and Evolution failed with some random errors, I wanted to go step by step. So I started with setting up phone to files synchronisation:

msynctool --addgroup file2phone
msynctool --addmember file2phone file-sync
msynctool --addmember file2phone syncml-obex-client

Now we need to configure file storage, just tell it where it should store the data:

msynctool --configure file2phone 1

And change path in your editor to something like:

<?xml version="1.0"?>
<config>
  <!-- directory path for file-sync -->
  <path>/home/foo/phone-backup/</path>

  <!-- should care of subdirectories (TRUE or FALSE) -->
  <recursive>FALSE</recursive>
</config>

Now the more tricky part comes, we need to set up phone end:

msynctool --configure file2phone 2

Fortunately we can use example from the SyncML guide and just fill in Bluetooth address (you can get it using hcitool scan) and channel (sdptool browse 00:b0:0b:fa:ce:00):

<?xml version="1.0"?>
<config>
  <bluetooth_address>00:b0:0b:fa:ce:00</bluetooth_address>
  <bluetooth_channel>7</bluetooth_channel>
  <identifier>Sony Ericss</identifier>
  <version>1</version>
  <wbxml>1</wbxml>
  <username></username>
  <password></password>
  <type>2</type>
  <usestringtable>0</usestringtable>
  <onlyreplace>0</onlyreplace>
  <onlyLocaltime>0</onlyLocaltime>
  <recvLimit>0</recvLimit>
  <maxObjSize>0</maxObjSize>
  <contact_db>Contacts</contact_db>
  <calendar_db>Agenda</calendar_db>
  <note_db>Notes</note_db>
</config>

And now we should be able to synchronise whole phonebook from phone to selected directory:

msynctool --sync file2phone

Okay, this works, let's try more complicated thing - include Evolution in the chain. The steps are the same, config file for phone is the same, Evolution plugin has sane defaults you usually don't have to touch:

msynctool --addgroup phone2evo
msynctool --addmember phone2evo evo2-sync
msynctool --addmember phone2evo syncml-obex-client
msynctool --configure phone2evo 1
msynctool --configure phone2evo 2

But now comes the tricky thing - Sony-Ericsson phones usually have something broken around notes (or it is broken in OpenSync, I don't care, simply synchronisation fails without this step) and we have to avoid synchronisation of them. This can be done by changing filter file in group we've created above (usually in file ~/.opensync-0.22/group2/filter.conf):

<?xml version="1.0"?>
<filter>
  <note/>
</filter>

And finally we can start the synchronisation and it should work:

msynctool --sync phone2evo

You can also GUI multisync0.90 to do the configuration and start synchronisation, but it is not much different, you also still have to edit XML files.

Basically what you get is a zip file containing several Microsoft Word documents, badly formatted text files (end of lines at each 80 chars), PDFs and some zip and tar archives. If you look to one of these archives, you will get binary graphical installer, which will install license, uninstallator and yet another set of tarballs. These tarballs finally contain binary and source packages you need to make graphics work on this platform. Maybe somebody did this to practise various ways of compressing and distributing things, but it is really amazing how many times you need to decompress several archives to actually get to the things you want.

Unfortunately at the end you will find out that libgl1-mesa-dri-psb binary (DRI driver for graphics) has no sources and Intel is not willing to give them to you. Bad luck if you have slightly different distribution than one of these which are supported (FC6, Midinux-build9, ubuntu-gutsy, ubuntu-hardy) and the provided binary simply crashes.

After some googling I found out that the problem might be in /etc/network/interfaces file, which is parsed by Network manager. Some "complex" things might confuse it. Well in my case the complex thing was calling of some script in post-up. Commenting this out magically fixes everything. Moving script to /etc/network/if-up.d/ also is not a big problem, but why the hell the Network manager thing does not tell where the problem is?

Today, after some googling I found short debugging guide on Ubuntu wiki, which quickly revealed me that "volume.ignore set to true on /org/freedesktop/Hal/devices/volume_uuid_4717_5407, not mounting". Well I didn't configure anything to be ignored, so let's dig deeper in this.

As I had no idea where this thing could be set, I again started to google and /etc/hal and /usr/share/hal seem to be the right place where to start grep. Nothing related in /etc, but too much entries in /usr. However most of them were selective for some special USB disks or partitions. But there was one which did this unconditionally - it was file /usr/share/hal/fdi/policy/gparted-disable-automount.fdi, what crap from gparted. Now I remember that I used this for formatting and partitioning something on USB and after doing all job, it crashed. So it left this piece of HAL hack inside /usr/share/hal and it was cause of anything not mounting.

Seems to be worth of reporting as a bug... Wait a moment, it's already known and some patch for it exists. Hopefully we will see this soon in unstable.

Unfortunately this is not the case, but Google works always and Jacob Emcken wrote down his configuration, so setup was quite easy. Thanks!