Out of service...

As of today this blog will be in suspended animation until this issue can be resolved.

Blogged with Flock

My jabra finally working with bluez...

As I have hit the bottom on my coding task (a project I have been planning for the past 6 months and writing it for the last month), I needed to get my mind off of it and do something I'm good at - debugging - and what better thing to debug than getting my Jabra to work with Skype. As I gave a shot at it some time ago and wasn't happy with the results, so I tried again.

The distribution is Fedora 8 (i386) and headset is Jabra BT 500v.

The first thing I upgraded was Skype itself - from 2.0.0.27 to 2.0.0.43 (built under Fedora Core 5 - isn't it about a time to upgrade?!?!).

At first I tried with the Fedora default bluez packages (version 3.20), but no luck there. Same results as before. At least this time I was just playing with it - hoping that the Fedora team had patched something.

Oh well - back to the basics. The latest version of bluez-libs and bluez-utils is 3.28, so why not give it a try. As I'm a lazy person and the archives did not include a spec file I reused the 3.20 spec files. As I'm am apt user I used "apt-get source bluez-libs bluez-utils" but somehow it is also doable in yum. This should create 2 spec files in "/usr/src/redhat/SPECS" folder. All I need to do was to copy the source archives into "/usr/src/redhat/SOURCES" folder and mod the spec files.

Bluez-libs was pretty easy to rebuild - just edited the spec file and replaced the "Version:" from 3.20 to 3.28 and ran the "rpmbuild -ba bluez-libs.spec". This created:
Wrote: /usr/src/redhat/SRPMS/bluez-libs-3.28-1.fc8.src.rpm
Wrote: /usr/src/redhat/RPMS/i386/bluez-libs-3.28-1.fc8.i386.rpm
Wrote: /usr/src/redhat/RPMS/i386/bluez-libs-devel-3.28-1.fc8.i386.rpm
Wrote: /usr/src/redhat/RPMS/i386/bluez-libs-debuginfo-3.28-1.fc8.i386.rpm

Now a little "rpm -Uvh /usr/src/redhat/RPMS/i386/bluez-libs-3.28-1.fc8.i386.rpm /usr/src/redhat/RPMS/i386/bluez-libs-devel-3.28-1.fc8.i386.rpm" and we have a newer libs in place (the devel package is needed for building the utils packages).

The bluez-utils was a bit more complicated as I had a bad experience when building the 3.20 version last time. Namely the "--enable-all" flag did NOT work at that time so just in case I modified the configure parameters. The basics are the same - replace the "Version:" string from 3.20 to 3.28 and the "Release:" string from "6%{?dist}" to "1%{?dist}". Now for the "%configure" parameters - the first thing was to replace "--disable-obex" with "--enable-obex". I'm not sure as to why it is disabled, but just in case I need obex I have it. After the obex I also added "--enable-alsa --enable-oss --enable-hal --enable-usb --enable-glib --enable-gstreamer". Now all I needed to do was a "rpmbuild -ba bluez-utils.spec" and woala:
Wrote: /usr/src/redhat/SRPMS/bluez-utils-3.28-6.fc8.src.rpm
Wrote: /usr/src/redhat/RPMS/i386/bluez-utils-3.28-6.fc8.i386.rpm
Wrote: /usr/src/redhat/RPMS/i386/bluez-utils-cups-3.28-6.fc8.i386.rpm
Wrote: /usr/src/redhat/RPMS/i386/bluez-utils-gstreamer-3.28-6.fc8.i386.rpm
Wrote: /usr/src/redhat/RPMS/i386/bluez-utils-alsa-3.28-6.fc8.i386.rpm
Wrote: /usr/src/redhat/RPMS/i386/bluez-utils-debuginfo-3.28-6.fc8.i386.rpm

Now a little "rpm -Uvh /usr/src/redhat/RPMS/i386/bluez-utils-3.28-6.fc8.i386.rpm /usr/src/redhat/RPMS/i386/bluez-utils-alsa-3.28-6.fc8.i386.rpm" and bluez should work.

So to start the bluetooth audio service I have this script headset.py:
#!/usr/bin/python
import dbus
bus = dbus.SystemBus()
manager = dbus.Interface(bus.get_object('org.bluez', '/org/bluez'), 'org.bluez.Manager')
bus_id = manager.ActivateService('audio')
audio = dbus.Interface(bus.get_object(bus_id, '/org/bluez/audio'), 'org.bluez.audio.Manager')

In theory this could be done from command line, but some time ago I found this little snippet that works for me. Basically all it does is activate and register the service as root through the dbus and it works from regular user account.

Now for the last but not the least we have to define the headset that will be used in our home folder. The file is ~/.asoundrc and mine contains the following:
pcm.bluetooth {
type bluetooth
device "00:13:17:2B:0D:11"
profile "auto"
}

where the device is the mac address of the device.

Now - to use the headset with Skype. first I run the headset.py script from console and then run Skype and BINGO - the sound starts almost the same time Skype starts. not 40 seconds later like with version 3.20. Not bad considering the connection is crypted and wireless :)
So the next step was to try the test call - and it worked without a delay!!! Last time I had to wait up to 2 minutes for Skype to initialize the output and input and thats if the connection staid up that long.

So - my headset is working and hopefully it will continue to work with Fedora 9 when it will be available and I hope it will be helpful to someone else.

Blogged with Flock

CentOS 5.1 kickstart lvm problems...

I have been messing around with the 5.1 kickstart for i386 for about 2 days now - as I'm not very good with python - as we need to kickstart PC-s with lvm support.

The error message states the following "An error occurred trying to format system/root_lv. This problem is serious, and the install cannot continue. Press to reboot your system."

And on tty5 (Alt + 5) another informative message "Could not stat /dev/system/root_lv --- No such file or directory. The device apparently does not exist; did you specify it correctly?"

It worked fine with the 5.0 tree, but when I wanted to kickstart with 5.1 I get an error that mkfs fails with /dev/system/root_lv and yes - there isn't a lvm path like that under the /dev.

After allot of debugging and messing around I found a workaround for it! It isn't easy nor is it for novice administrators so I would recommend just plain old install without the LVM support.

The problem is that the kickstart wont bring up lvm volumes before it tries to make a file system on them. Yes, it creates the physical volume, volume group and logical volumes, but it fails to activate them as the the LV-s are marked as created in the prep stages. This leaves us with a fully working LVM setup that is not activated and so the install crashes.

To fix the problem we need to hack the minstg2.img file in the repository. First make a backup of this file and copy it to a different folder. As I hacked it under Fedora 8 we need a package called "squashfs-tools" to unpack the image.

In the local folder run "unsquashfs minstg2.img" - this will create "squashfs-root" folder with the file system unpacked inside.

The problematic file is located "squashfs-root/usr/lib/anaconda" and the file is "fsset.py".
On line 1753 there is "self.volumesCreated = 1" - this should be changed "self.volumesCreated = 0".

Warning - watch the spacing as python is very touchy with extra or missing spaces.

Save the file and "cd ../../../../" back to the beginning.

Now we need to create and new image and for that I strongly recommend creating an image with a different name.

To create the image run "mksquashfs squashfs-root test.img" and it will create the new image.

Warning - back up the original if you have not done it for now!!!

copy the test.img the the repository server and replace the original minstg2.img with the test.img.

This should do the trick and kickstarting PC-s with LVM should work now.

As I mentioned - this is an hack not a solution, so if you have automatic mirroring and the image gets rewritten with the old one copy the test.image back.

Also this bug could be fixed in the future so this hack will get obsoleted some time...

Update: Added exact error messages and my local mirror updated the minstg2.img from upstream, so I had to copy the test.img to the minstg2.img again...

Have fun.

Blogged with Flock